1. Database Design – Lecture 5 Conceptual Data Modeling – adding attributes

2. 2 Lecture Objectives How to correctly define attributes for an entity Determining the key structure of an entity Refining relationships between entities based on Business Rules

3. 3 Attributes Characteristics of entities In Chen model, attributes are represented by ovals and are connected to entity rectangle with a line Each oval contains the name of attribute it represents In Crow’s Foot model, attributes are written in attribute box below entity rectangle

4. 4 Attributes ERD Notation

5. 5 Attributes Should be meaningful Rule of thumb is to prefix attribute with entity name i.e. CUSTOMER_NAME versus NAME Can be single valued An attribute that can have only a single value i.e. social insurance number Can be multivalued An attribute that can have many values i.e. an employee has many skills

6. 6 Derived Attributes Attribute whose value may be calculated (derived) from other attributes Need not be physically stored within database Can be derived by using an algorithm Can show in the conceptual model

7. 7 Derived Attributes

8. 8 Primary Keys Should uniquely identify each entity instance Can not be nulls Should preferably be numeric Should have the minimum number of attributes possible

9. 9 Composite Primary Keys To satisfy M:N relationship When identifying a weak entity

10. 10 RELATIONSHIP Strength Existence dependence Entity’s existence depends on the existence of one or more other entities Obvious here that a DEPENDENT can not exist without a PARENT Characteristic: strong relationship, with dependent entity being a weak entity, the parent entity being a strong entity

11. 11 RELATIONSHIP Strength Strong (Identifying) Relationships Related entities are existence-dependent Primary key of parent entity is part of the primary key of the child entity In Visio, denote the identifying (solid line) relationship by selecting Identifying in the Database Properties

12. 12 RELATIONSHIP Strength Existence independence Entity can exist apart (independent) from one or more related entities A PLAN can exist whether there is a CLIENT or not Characteristic: weak relationship, strong entities

13. 13 RELATIONSHIP Strength Weak (non-identifying) relationships One entity is not existence-independent on another entity Primary key of parent entity is not part of the primary key of the child entity In Visio, denote the non-identifying (dashed line) relationship by selecting Non- identifying in the Database Properties

14. 14 Relationship Participation Optional : One entity occurrence does not require a corresponding entity occurrence in a particular relationship Mandatory : One entity occurrence requires a corresponding entity occurrence in a particular relationship

15. 15 Relationship Degree Indicates number of associated entities or participants Unary relationship Association is maintained within a single entity Binary relationship Two entities are associated Ternary relationship Three entities are associated

16. 16 Three Types of Relationships

17. 17 Unary (Recursive) Relationships Relationship can exist between occurrences of the same entity set Naturally found within a unary relationship Can be 1:1; 1:M or M:N

18. 18 Unary (Recursive) Relationships

19. 19 Unary (Recursive) Relationships Note that EMP_NUM is the PK. EMP_SPOUSE is an attribute only and not an FK

20. 20 Unary (Recursive) Relationships Note that EMP_CODE is the PK. EMP_MANAGER is an attribute only and not an FK

21. 21 Unary (Recursive) Relationships Note that CRS_CODE is PK of the COURSE table. In the PREREQ table, CRS_CODE and PRE_TAKE are PK and FK (composite primary key)

22. 22 Binary Relationships Most common type of relationship Types: 1:1 relationship 1:M relationship M:N relationships

23. 23 Binary Relationships 1:1 relationship: PK from each table becomes FK of the related table 1:M relationship: PK from the ‘1’ table becomes FK of the ‘M’ table M:N relationship: Create a bridge table PK of the bridge table is a composite primary key made up of the PK of each of the related tables Bridge table may also contain additional attributes

24. 24 Binary Relationships Bridge Table needed. It will contain the primary keys from the other two entities as its primary key – a composite primary key. These primary keys will also be foreign keys at the same time

25. 25 Entity Supertypes and Subtypes Generalization hierarchy Depicts a relationship between a higher-level supertype entity and a lower-level subtype entity Supertype entity Contains the shared attributes Subtype entity Contains the unique attributes Supertype and its subtype(s) maintain a 1:1 relationship

26. 26 Entity Supertypes and Subtypes Note that EMP_LICENSE, EMP_RATINGS and EMP_MED_TYPE refer to only a specific type of employee – a Pilot

27. 27 Sub-Type - Nulls Created by Unique Attributes

28. 28 A Generalization Hierarchy

29. 29 Supertype/Subtype Relationship – New Pilot Table

30. 30 Supertype/Subtype Relationship 1:1 relationship Attributes unique to the subtype entity removed from supertype entity and renamed for subtype entity

31. 31 Developing an ER Diagram Database design is iterative rather than linear or sequential process Iterative process Conceptual Model: Entities, Relationships Logical Model: Entities, Attributes, Relationships, PKs and FKs identified

32. 32 Developing an ER Diagram Building an ERD usually involves the following activities: Create detailed narrative of organization’s description of operations Identify business rules based on description of operations Identify main entities and relationships from business rules Develop initial ERD Identify attributes and primary keys that adequately describe entities Revise and review ERD

33. 33 Summary Entity relationship (ER) model Uses ERD to represent conceptual database as viewed by end user ERM’s main components: Entities Attributes Relationships Includes connectivity and cardinality notations M:N relationship is valid at conceptual level (providing there is not an attribute that represents the intersection of the two entities)