1. Lecture plan Outline of DB design process Entity-relationship model
Entities and attributes
Relationships
Jane Reid, BSc/IT DB, QMUL, 7/1/02

2. DB design process [1] Requirements collection and analysis
Users’ data requirements
Users’ functional requirements (using software engineering tools, e.g. data flow diagrams)
Jane Reid, BSc/IT DB, QMUL, 7/1/02

3. DB design process [2] Conceptual design Creation of conceptual schema
Concise description of users’ data requirements
Uses high-level conceptual data model, e.g. Entity-relationship model
Data model operations used to specify user operations from functional analysis
Compatibility check and possible modification
Jane Reid, BSc/IT DB, QMUL, 7/1/02

4. DB design process [3] Logical design / data model mapping
Uses implementation data model, e.g. relational data model
Conceptual schema transformed from high-level data model to implementation data model
Jane Reid, BSc/IT DB, QMUL, 7/1/02

5. DB design process [4] Physical design
Internal storage structures, access paths, file organisation specified
Application programs designed and implemented
Jane Reid, BSc/IT DB, QMUL, 7/1/02

6. Entity-relationship model
High-level conceptual modelling technique for DB applications
DB application = DB + associated programs
Application programs need to be designed, implemented and tested
ER model used for conceptual design of DB applications
Jane Reid, BSc/IT DB, QMUL, 7/1/02

7. Entities and attributes
An entity is an object with a physical or conceptual existence
Attributes are the particular properties which describe the entity
An individual attribute has a value
Jane Reid, BSc/IT DB, QMUL, 7/1/02

8. Simple vs composite attributes
Can be divided into smaller subparts which
Represent more basic attributes with independent meanings
Can form a hierarchy
Useful if attribute must be handled sometimes as a unit and sometimes as components
Simple (atomic) attributes are not divisible
Jane Reid, BSc/IT DB, QMUL, 7/1/02

9. Single- vs multi-valued attributes
Single-valued attributes have a single value for a particular entity
Multi-valued attributes
Have a set of values for a particular entity
May have lower/upper bounds on the number of values allowed
Jane Reid, BSc/IT DB, QMUL, 7/1/02

10. Stored vs derived attributes
Are related to another attribute
Are derivable from a stored attribute
May be derivable from related entities
Stored attributes
Are not derivable from any other source
Jane Reid, BSc/IT DB, QMUL, 7/1/02

11. Null attribute values
Used to denote value of an attribute for a particular entity which is
Non-applicable
Unknown
Exists but is missing
Not known if it exists or not
Jane Reid, BSc/IT DB, QMUL, 7/1/02

12. Complex attributes Composite attributes Multi-valued attributes
Components grouped between parentheses ()
Components separated by commas
Multi-valued attributes
Displayed between braces {}
Composite and multi-valued attributes can be nested in an arbitrary way
Jane Reid, BSc/IT DB, QMUL, 7/1/02

13. Entity types and sets [1]
An entity type is
A collection (set) of entities with the same attributes but different values for the attributes
Schema / intension for a set of entities which share the same structure
Jane Reid, BSc/IT DB, QMUL, 7/1/02

14. Entity types and sets [2]
An entity set
A collection of all entities for a particular entity type
Extension of the entity type
Entity type and associated entity set have the same name
Jane Reid, BSc/IT DB, QMUL, 7/1/02

15. Entity types and sets [3]
EMPLOYEE
Name, Age, Salary e1
(John Smith, 55, 80K) e2
(Fred Brown, 40, 30K) e3
(Judy Clark, 25, 20K)
Jane Reid, BSc/IT DB, QMUL, 7/1/02

16. Key attributes [1] Also called uniqueness constraint
Value of key attribute
Identifies each entity uniquely
Must be distinct for each entity in the collection
Unique for every extension of the entity type
Jane Reid, BSc/IT DB, QMUL, 7/1/02

17. Key attributes [2] Composite key Entity type may have
Combination of attribute values form the key
Must be minimal (no superfluous attributes)
Entity type may have
More than one key attribute
No key attribute - a weak entity type
Jane Reid, BSc/IT DB, QMUL, 7/1/02

18. Value sets of attributes
Also called “domain” of attributes
The set of values which may be assigned to that attribute for each individual entity
Not displayed in ER diagrams
Jane Reid, BSc/IT DB, QMUL, 7/1/02

19. Relationships
Implicit relationships between attributes can be converted to explicit relationships
An attribute of one entity type refers to another entity type
Jane Reid, BSc/IT DB, QMUL, 7/1/02

20. Relationship types and sets
Relationship type defines set of associations (relationship set) among entities
Relationship type and set have same name
Relationship instance associates exactly one entity from each participating entity type
Jane Reid, BSc/IT DB, QMUL, 7/1/02

21. Relationship degree Number of participating entity types:
Relationship type of degree two is binary
Relationship type of degree three is ternary
Higher degree relationships are more complex
Jane Reid, BSc/IT DB, QMUL, 7/1/02

22. Relationships as attributes
Two entity types A and B, where
Attribute a2 of entity type A indicates a link to a particular entity of entity type B
Binary relationship may be considered as:
Value set of attribute a2 is set of all B entities
Additional multi-valued attribute b3 for entity type B, whose value for each entity is the set of all A entities matching on attribute a2
Jane Reid, BSc/IT DB, QMUL, 7/1/02

23. Role names Explains what the relationship means
Indicates the role that a particular entity plays in a relationship instance
Necessary for recursive relationships
same entity type participates more than once in a relationship type in different roles
Jane Reid, BSc/IT DB, QMUL, 7/1/02

24. Relationship type constraints [1]
Structural constraints which limit combination of entities in relationship set
Cardinality ratio
Number of relationship instances an entity can participate in
Possible ratios - 1:1, 1:N, N:1, M:N
Jane Reid, BSc/IT DB, QMUL, 7/1/02

25. Relationship type constraints [2]
Participation constraints
Indicates if existence of an entity depends on its being related to another entity by relationship type
Total (existence dependency) - every entity in the total set must be related
Partial - some entities in the total set must be related
Jane Reid, BSc/IT DB, QMUL, 7/1/02

26. Relationship type attributes
Similar idea to entity type attributes
Attributes of 1:1 relationship types can be migrated to one of participating entities
Attributes of 1:N (or N:1) relationship types can be migrated to entity type at N side
Attributes of M:N relationship types cannot be migrated
Jane Reid, BSc/IT DB, QMUL, 7/1/02

27. Weak entity types [1] Does not have a key attribute
Identified by a combination of
Relationship to specific entities from another entity type (identifying/owner entity type)
Identifying relationship of weak entity type
Weak entity has total participation constraint
Some (or all) of its attribute values
Jane Reid, BSc/IT DB, QMUL, 7/1/02

28. Weak entity types [2] Normally has partial key (discriminator)
Can sometimes be represented as complex (composite, multi-valued) attribute
Not if it participates independently in other relationship types
Jane Reid, BSc/IT DB, QMUL, 7/1/02

29. ER conceptual design
Schema design is iterative and may involve refinement:
Attribute may be refined into relationship if attribute is a reference to another entity type
Attribute that exists in several entity types may be refined into an independent entity type
Inverse refinement to above
Specialisation/generalisation
Jane Reid, BSc/IT DB, QMUL, 7/1/02