Database Design – Lecture 5
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
PARENT DEPENDENT
11
RELATIONSHIP Strength
Strong (Identifying) Relationships Related entities are existence-dependent
PARENT
PK PARENT_CODE
PARENT_LNAMEPARENT_FNAME
DEPENDENT
PK,FK1 PARENT_CODEPK DEP_CODE
DEP_LNAMEDEP_FNAME
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
Plan Client
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
VENDOR
PK VENDOR_ID
NAME
PRODUCT
PK PRODUCT_ID
DESCRIPTION QUANTITY_ON_HAND MIN_REORDER_QTYFK1 VENDOR_ID
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
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
Three Types of Relationships
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
Unary (Recursive) Relationships
19
Unary (Recursive) Relationships
Note that EMP_NUM is the PK. EMP_SPOUSE is an attribute only and not an FK
20
Unary (Recursive) Relationships
Note that EMP_CODE is the PK. EMP_MANAGER is an attribute only and not an FK
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
Binary Relationships
Most common type of relationship
Types: 1:1 relationship 1:M relationship M:N relationships
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
Binary Relationships
Plan1
PK PLAN_ID
NAME DESCRIPTION
Client1
PK CLIENT_ID
NAME ADDRESS PHONE
PLAN_CLIENT
PK,FK1 PLAN_IDPK,FK2 CLIENT_ID
DATE
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
PLAN
PK PLAN_ID
NAME DESCRIPTIONFK1 CLIENT_ID
CLIENT
PK CLIENT_ID
NAME ADDRESS PHONEFK1 PLAN_ID
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
Entity Supertypes and Subtypes
Note that EMP_LICENSE, EMP_RATINGS and EMP_MED_TYPE refer to only a specific type of employee – a Pilot
EMPLOYEE
PK EMPL_NUM
EMPL_LNAMEEMP_LICENSEEMP_RATINGSEMP-MED_TYPEEMP_HIRE_DATE
27
Sub-Type - Nulls Created by Unique Attributes
28
A Generalization Hierarchy
29
Supertype/Subtype Relationship – New Pilot Table
30
Supertype/Subtype Relationship
1:1 relationship
Attributes unique to the subtype entity removed from supertype entity and renamed for subtype entity
EMPLOYEE
PK EMPL_NUM
EMPL_LNAMEEMP_HIRE_DATE
PILOT
PK,FK1 EMPL_NUM
PIL_LICENSEPIL_RATINGSPIL_MED_TYPE
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
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
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)
Top Related