Database Reference
In-Depth Information
attributes for each entity, as described in Chapter 6; when you build the
model, you'll enter each of these attributes—with its data types (including
precision and scale, when applicable) and nullability—into the entity ob-
ject in the model.
When compiling attribute lists for an entity, you need to conduct one
specific bit of analysis. You need to compare attribute lists between related
entities to be sure that any attributes being stored as a specific data type
and length are consistent with attributes of other entities storing the same
type of information. This is the perfect use of domains in your data model.
For example, if you define a first_name domain and use it everywhere you
need a first name, you will ensure that the types and lengths are consistent.
Here's another example: If you are storing mobile phone numbers for ven-
dors and for customers, make sure you use the same format.
Although these two attributes are unrelated, it's a good idea to be con-
sistent. In that way, when development of the physical model starts, as well
as application development, no one has to remember that the mobile
phone number format is different from table to table. Because the data
types used in the tables are based on the data types used in the data model,
it is the modeler's responsibility to be as consistent as possible.
Relationships Documentation
Now that you know the entities you have created and their specific attri-
butes, it's time to start listing the relationships between them. You need to
list the relationships for each entity; in this way, as you create the model
you are simply typing in the relationship parameters, without trying to dis-
cover and define relationships on the fly.
First, start with obvious relationships—Customers to Orders, Orders
to Order Details, and so on. For each relationship, note the parent/child,
the cardinality, and whether or not it is mandatory or identifying. After
those are defined, start working through defining relationships between
subtypes and supertypes, and many-to-many relationships using tertiary
entities.
Although listing every relationship between every entity in the MVM
model would be wasteful (you'll find the complete model in Appendix B),
it's important to give a sample. Table 7.2 outlines the relationship informa-
tion that you should document and list.
Search WWH ::




Custom Search