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

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)