Entity Relationship Modeling - Business Rules
(Page 5 of 21 )
Now, we have suddenly gotten the opportunity to define a business rule here! This definition WILL result in a constraint in the complete database, at the end of the design phase, like this:
PROMPT Creating Check Constraint on
'TRANSACTIONS'
ALTER TABLE TRANSACTIONS
ADD (CONSTRAINT AVCON_1071502401_VALUE_000 CHECK (VALUE BETWEEN 0.01 AND 999999.99)).
But we are too far into design now: Let us step back, and look at how we can define a type-domain as well:
Since we have the legal range constraint defined, we should be able to reduce the length of the domain. Since the MONEY domain is attached to the transaction amount attribute in some transaction, changes in the domain have immediate impact. I will stress this. Relate all attributes to its domain, like this:
The best advice I can give is - Do not settle for tools that do not support most of your development cycle.
Relations
Relations are the bonds between entities. They tell about certain rules that apply if you want to insert, update or delete occurrences (rows) from what later becomes tables. Relations also tell us much about the logic connections between entities. In the physical design of the database, relationships become constraints that govern how you are allowed to manipulate data in the different tables. The relationships are there to enforce referential integrity. This refers to the internal logic of your system and ensures that your objects are referring to actual items in tables.
Relations, as we use them in analysis, are in some ways in contrast to what is allowed when you physically transform the ER model to a physical, live database. This is due to the fact that in analysis, we model the business, but in design, we have to abide by laws of the database system. This is all, again, to enforce referential integrity; securing that your database does not get corrupt.
Next: Three types of relationships >>
More Development Cycles Articles
More By Alf A. Pedersen
/ 49 
