Database Design for Smarties: Using UML for Data Modeling
Learn UML techniques for object-oriented database design.
TABLE OF CONTENTS Database Design for Smarties: Using UML for Data Modeling
Living by the Rules
Rules are everywhere in a relational database; they're just hard to see. When you create a column with a certain data type, you're imposing a domain constraint. When you add a PRIMARY KEY clause, you're enforcing an object identity constraint. When you make a column refer to another one in a REFERENCES clause, you're imposing a foreign key constraint. When you add an AFTER INSERT trigger, you're adding a complex integrity constraint or business rule.
The first part of this chapter has dealt with many of the basic constraints:
-
Domain constraints: Types, domains, CHECK constraints, and NOT NULL constraints
-
Primary key constraints: Implicit and explicit object identity
-
Uniqueness constraints: Candidate keys and alternate OIDs
-
Foreign key constraints: Associations, multiplicity, and aggregation
There are other business rules you need to enforce in your database besides these structural ones. These constraints appear in your UML data model as constraint boxes associated with the appropriate things you want to constrain. See the Chapter 7 section "Complex Constraints" for details on expressing constraints in the UML OCL or in SQL.
Class Invariants
When you have a constraint on a class, it is usually an expression that asserts a class invariant over the attributes of the class. A class invariant is a logical expression that an object of the class must satisfy at all times (the truth of the expression does not vary with the state of the object).
Transforming your class into a table creates...
Copyright Academic Press 1999 under license agreement with Books24x7
