Database Reference
In-Depth Information
Two types of business rules are usually enforced in the data model.
Data format
This includes any requirements that a given type of data have a spe-
cific length, type of character, and specific order of characters.
Examples include date and time formats, user name and password
fields, and alphanumeric value constraints (e.g., no letters in a Social
Security Number field).
Data relationships and integrity
Relationships that require the association of data from one entity
with another are business rules in a data model. For example, all or-
ders must be associated with a customer, or all outgoing shipments
must have shipping details. Another example is the requirement
that multiple records be updated if a single piece of information is
changed—for example, updating the ship date of a shipment auto-
matically updates similar fields in order summary tables.
Other business rules can be implemented in the database, but that is
usually discussed on a per project basis and is always subject to the capa-
bilities of SQL Server. For our purposes, simple data integrity rules are
being implemented in MVM via relationships based on primary keys and
foreign keys.
Building the Model
At this point in the design process, we've evaluated existing systems, inter-
viewed employees, and compiled documentation on all the data relevant to
the system we are modeling. We've even generated lists of potential enti-
ties and their attributes, as well as the relationships between them. Now it's
time to begin assembling the data model.
In this section, we start placing entities and their attributes in our dia-
gram and identifying and labeling our keys and relationships. We also re-
view the cardinality of those relationships and ensure that we've correctly
labeled them. We also document and label our domains and ensure that
our model is readable and accurate based on our requirements.
 
 
Search WWH ::




Custom Search