It facilitates discussion. A picture is worth a thousand words.
It forms important ideal system documentation.
It takes into account government regulations and laws
It forms a sound basis for physical database design
All of the above.
Distinguish one entity from another
Distinguish one instance of an entity from all other instances of that entity
Distinguish all entities in a database
They describe, qualify, quantify, classify, or specify an entity.
They are often adjectives.
They have a data type such as a number or character string.
They must be single valued unless they belong to more than one entity.
Transferability, degree, name
Name, optionality, degree
A UID bar, a diamond, an arc
Name, optionality, arcs
3 or more entities
2 entities (or one entity twice)
3 or more attributes
Each CUSTOMER must be the buyer of one or more ITEMS.
Each CUSTOMER must be the seller of one or more ITEMS.
Each CUSTOMER may be the maker of one or more ITEMS.
Each CUSTOMER may be the producer of one or more ITEMS.
Instances that belong to two subtypes of the same supertype may be modeled as a one-to-one relationship between the two subtypes
Subtypes inherit the relationships and attributes of the supertype
Subtypes may have no more than 2 levels of nesting
Supertype and subtype entities must be mutually exclusive
They capture all of the needs, processes and required functionality of the business.
They are easily implemented in the ERD diagram.
The data modeler must focus on structural rules, because they are easily represented diagrammatically and eliminate other rules that involve extra procedures or programming.
Both A and C are true.
All employees must belong to at least one department.
Buildings to be purchased by the business must be current with earthquake building code.
All overdue payments will have an added 10 % late fee.
All products will have a selling price no less than 30 % greater than wholesale.