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

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. 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. Attributes
ERD Notation

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. 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. Derived Attributes

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. Composite Primary Keys
To satisfy M:N relationship
When identifying a weak entity

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. 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. 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. 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. 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. Binary Relationships Most common type of relationship Types:
1:M relationship
M:N relationships

16. Binary Relationships 1:1 relationship: 1:M 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

17. 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

18. 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

19. 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

20. Summary Entity relationship (ER) model
Uses ERD to represent conceptual database as viewed by end user
ERD’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)