Database Design – Lecture 4

Conceptual Data Modeling

2

Lecture Objectives That key questions need to be

answered when gathering requirements That a conceptual relational database

model’s basic components are entities and relationships among entities

How relationships between entities are defined and refined and how those relationships are incorporated into the database design process

How ERD components affect database design and implementation

3

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

4

Developing an ER Diagram

Building an ERD continued: Identify attributes and primary keys that

adequately describe entities Revise and review ERD

5

Discovering Entities

Requirements gathering – focusing on data: Interview end users Review existing documentation (forms,

reports) Brainstorming Overview of the business Questionnaires Review system documentation

Functional/non-functional requirements Work flow diagrams Data flow diagrams Use case descriptions

6

Discovering Entities

Use a technique like ‘noun filtering’ Look for nouns that describe data Similar nouns can be grouped into an

entity Some nouns will become attributes

7

Sample Conceptual Model - ERD

This is a preliminary conceptual model. Model shows entities without attributes or

relationships.

8

Entity

Corresponds to a table and not to a row in the relational environment

Can be strong or weak Entity name is a noun

9

Entity can be strong or weak Strong Entity (existence

independent) Does not depend on the existence of some other entity to exist Each entity occurrence of a strong entity is uniquelyidentifiable using the primary key attributes of that entity type

Can identify each Plan based on a plan code and can identify each Client by a client code. Therefore, both are strong entities.

Entity

Plan ClientWeak relationship (non-identifying)

10

Entity

Entity can be strong or weak Weak Entity (existence

dependent) Does depend on the existence of some other entity in order to exist Cannot identify each occurrence of the Dependent. We can onlyIdentify the Dependent byKnowing the Parent,through the primarykey of the Parent.

PARENT DEPENDENT

Can identify each parent based on a primary key (therefore it is a strong entity type) and can only identify each dependent only by knowing the Parent. Therefore dependent is a weak entity.

11

Relationship Participation

Optional participation One entity occurrence does not require

corresponding entity occurrence in particular relationship

Mandatory participation One entity occurrence requires

corresponding entity occurrence in particular relationship

12

Relationship Participation

13

Relationship Participation

14

Summary

Entity relationship (ER) model Uses ERD to represent conceptual database as

viewed by end user ERD’s main components:

Entities Relationships

Includes connectivity and cardinality notations Connectivities and cardinalities are based on

business rules In ERD, M:N relationship is valid at conceptual

level