Term
| Attribute into an entity type |
|
Definition
| When a database should contain more than just the identifier of an entity, this transformation is useful |
|
|
Term
| Splitting Compound Attributes |
|
Definition
| Splitting this can facilitate search of the embedded data; want to keep it in the same entity as much as possible |
|
|
Term
| Entity type into two entity types and a relationship |
|
Definition
| Useful to record a finer level of detail about an entity |
|
|
Term
| Weak entity into a strong entity and change the associated identifying relationships into nonidentifying relationships |
|
Definition
| Transformation that makes it easier to reference an entity type after conversion to a table design; after conversion, a reference to a weak entity will involve a combined foreign key with more than one coumn, which is most useful for associative entity types, especially associative entity types representing M-way relationships |
|
|
Term
| Add historical details to a data model |
|
Definition
| Adding these may be necessary for legal requirements as well as strategic reporting requirements; can be applied to attributes and relationships; when applied to a relationship, it typically involves changing a 1-M relationship into an associative entity type and a pair of identifying 1-M relationships |
|
|
Term
| Entity type into a generalization hierarchy |
|
Definition
| Should be used sparingly; may be useful if there are multiple attributes that do not apply to all entities and there is an accepted classification of entities |
|
|
Term
|
Definition
| Include jusitification for design decisions involving multiple feasible choices and explanations of subtle design choices. Don't use documentation just to repeat the info already contained in an ERD. You also should provide a description for each attribute especially where an attribute's name does not indicate its purpose. As an ERD is developed, you should document incompleteness and inconsistency in requirements. |
|
|
