Database Management Systems

Data ModellingBy Nickkisha Farrell, BSc IT, Dip Ed

February 2014

2

IN THIS PRESENTATION

What is data modelling?

Creating a Data Model

How to draw Entity Relationship Diagrams

ERD: Problem and Solution

Types of data Models

Entities, Attributes, Relationships and Cardinality

3

INTRODUCTION

• In order ultimately to design databases to support an organization, one should have:

• a clear understanding of how the organization is structured

• how it functions• understand its components, what they do and how

they relate to each other.• There must be a way of recording (diagramming)

the business

• This is the principle of DATA MODELING.

4

DATA MODELLING

• Process used to define and analyze data requirements needed to support the business processes, so that anomalies and inconsistencies may be eliminated during the physical database design.

• Therefore, the process of data modeling involves professional data modelers working closely with business stakeholders, as well as potential users of the information system.

5

DATA MODELLING

The analysis of data objects and their relationships to other data objects.

• Types of data models:

1. Conceptual: describes WHAT the system contains

2. Logical: describes HOW the system will be implemented, regardless of the DBMS

3. Physical: describes HOW the system will be implemented using a specific DBMS

6

TYPES OF DATA MODELS

• Entity-Relationship (E-R) Models• The most common method for database modelling

• Only addresses data and relationships• Classic, simplest

• Best for deriving a sound table design• Basis for most other modeling approaches

• UML (unified modeling language)• Class models• Goes beyond data, also models behaviors

7

ENTITY RELATIONSHIP DIAGRAMS

• a graphical representation of the logical structure of a database

• identifies the concepts or entities that exist in a system and the relationships between those entities

• help the database analyst/designer gains a better understanding of the information to be contained in the database.

• facilitate documentation of the database design lifecycle.

• used to communicate the logical structure of the database to users .

8

ENTITY

• Entity• Generalized category

representing person, place, thing on which we store and maintain information

• Entity Names become Table Names

• E.g. Department, Employee

9

ATTRIBUTE

•Attributes:• Specific characteristics of

each entity, e.g.:• DEPARTMENT - name,

address• EMPLOYEE - id, name,

contact number

Primary key

Atomic

CompositeMulti-valuedDerivedTy

pes

of

Att

ribute

s

PRIMARY KEY ATTRIBUTES

• Attribute whose value is unique for every entity instance• Every entity MUST have a PK• Designate by:

• Placing as first attribute in the entity• Underline• Label using "PK“

• Must be values that are:• Unique for every possible record• Do not change• Best practice: numeric with no blank spaces or

formatting characters

UniversityStudent

PK StudentID

StudentName StudentDOB StudentAge

ATOMIC AND COMPOSITE ATTRIBUTES

• Atomic attribute: represents a single data value• Eg: 17, “Melissa", 11/25/1997

• Composite attribute: can be decomposed into atomic attributes

• “Melissa K. Jones"• “VC100 Murrays Vilage, Kingstown, SVG"• Should be decomposed as much as possible when

storing in a database

COMPOSITE ATTRIBUTES

• Decompose into atomic components for:• Sorting• Searching• Formatting

StudentStudent_ID

Student_NameStudent_Address

Student_DOBStudent_Class

Student_First_NameStudent_MIStudent_Last_Name

Student_Address_Line_1Student_Address_Line_2Student_CityStudent_StateStudent_CountryStudent_Postal_Code

MULTI-VALUED ATTRIBUTES

• Can have multiple values for the same entity

StudentStudent_ID (PK)

Student_First_NameStudent_Last_Name

Student_AddressStudent_DOB

Student_Phone1Student_Phone2

EmployeeEmployee_ID (PK)

Employee_First_NameEmployee_Last_Name

Employee_AddressEmployee_DOB

Employee_Dependent1Employee_Dependent2

HANDLING MULTI-VALUED ATTRIBUTES

• If it has a definite maximum number, leave as a repeating attribute

• If the upper limit is variable, make a new entity

StudentStudent_ID

Student_First_NameStudent_Last_Name

Student_AddressStudent_DOB

Student_Phone1Student_Phone2

EmployeeEmployee_ID

Employee_First_NameEmployee_Last_Name

Employee_AddressEmployee_DOB

Employee_Dependent1Employee_Dependent2

DependentDependent_ID

Dependent_Name

has

DERIVED ATTRIBUTES

• Value that can be derived from other attributes• Student_Age = 17 (DOB = 04/26/1997, current date is

04/30/2014)

• Store the underlying data values from which you can derive the attribute value …

• Examples: • DOB => Age

• … unless the underlying values can change!• PRODUCT_PRICE, COURSE_CREDITS

16

RELATIONSHIPS

• Relationship:• A data relationship is

a natural association that exists between one or more entities.

• E.g. Employees belong to departments. 

Relationships always connect two entities

17

CARDINALITY

• Cardinality:• Defines the number of occurrences of one entity for a

single occurrence of the related entity. • E.g. a department may have one or more employees,

but an employee can belong to only one department. 

• Ordinality :• Closely linked to cardinality. • Describes the relationship as either mandatory or

optional. • Specifies the absolute minimum number of

relationships. • When the minimum number is = zero, relationship is optional• When the minimum number is > than zero , relationship is

mandatory

18

HOW TO CREATE ERDs

1. Identify Entities  Identify the roles, events, locations, tangible things or concepts about which the end-users want to store data. 

2. Find Relationships  Find the natural associations between pairs of entities using a relationship matrix.

3. Fill in Cardinality  Determine the number of occurrences of one entity for a single occurrence of the related entity. 

4. Identify Attributes  Determine the information details (fields) which are essential to the system under development. 

5. Define Primary Keys  Identify the data attribute(s) that uniquely identify one and only one occurrence of each entity. 

6. Draw Key-Based ERD  Eliminate Many-to-Many relationships. Draw ERD and include primary and foreign keys in each entity. 

7. Draw fully attributed ERD 

Adjust the ERD from step 7 to account for entities or relationships discovered in step 8. 

10. Check Results  Does the final Entity Relationship Diagram accurately depict the system data? 

19

ERD NOTATION

• Crows Foot Notation

Entity

Relationship

Attribute

20

ERD NOTATION

• Chen Notation - Cardinality

Entity

RelationshipUniversityStudent

PK StudentID

StudentName StudentDOB StudentAge

Primary key

Entity

Attributes

21

ERD NOTATION

• Bachman Notation - Cardinality

Entity

Relationship

DATA MODEL RELATIONSHIPS

• Specify the number of instances of one entity that can be associated with instances of a related entity

• There are three types of data model relationships:1:M

• One to Many

1:1• One to One

M:M• Many to

Many

ONE TO MANY RELATIONSHIP EXAMPLE

Video_ID Video_Title Video_Format

1000 The Princess Bride DVD

1001 Sideways Bluray

1002 Just Visiting DVD

1003 Crash Bluray

Store_ID Store_Name Store_Address

1 Northside 3233 Wisconsin St.

2 Southside 4211 Golf Road

StoreStore_IDStore_NameStore_Address

Video

Video_IDVideo_TitleVideo_Format

Rents

ONE TO ONE RELATIONSHIP EXAMPLE

Spouse_ID Spouse_Name

52 Ryan, Judy

53 Redmann, Rudy

Customer_ID

Customer_Name

Customer_Address

1 Ryan, Paul 5454 Hyde Court

2 Myers, Mary 112 Birch Place

CustomerCustomer_IDCustomer_NameCustomer_Address

SpouseSpouse_IDSpouse_Name

Has

MANY TO MANY RELATIONSHIP EXAMPLE

Customer

Customer_IDCustomer_NameCustomer_Address

Video

Video_IDVideo_Title

Rents

ERD MODEL EXAMPLE

UniversityStudent

PK StudentID

StudentLastName StudentFirstName StudentMI StudentDOB

UniversityCourse

PK CourseID

CourseName CourseTitle

EnrollsIn

UniversityInstructor

PK InstructorID

InstructorLastName InstructorFirstName InstructorOffice

ServiceProject

PK ProjectID

ProjectDescription ProjectStartDate

AdvisesCompletes

27

NOW ITS YOUR TURN

•SCENARIO

• A company has several departments. Each department has a supervisor and at least one employee. Employees must be assigned to at least one, but possibly more departments. At least one employee is assigned to a project, but an employee may be on vacation and not assigned to any projects. The important data fields are the names of the departments, projects, supervisors and employees, as well as the supervisor and employee number and a unique project number. 

28

SOLVING THE PROBLEM

1. Identify Entities• The entities in this system are Department, Employee, Supervisor

and Project. One is tempted to make Company an entity, but it is a false entity because it has only one instance in this problem. True entities must have more than one instance. 

  Department

Employee Supervisor

    Project

Department

  is assigned 

run by   

Employee belongs to     works onSupervisor runs      Project   uses 

2. Find Relationships 

We construct the following Entity Relationship Matrix:   

29

SOLVING THE PROBLEM3. Fill in Cardinality 

From the description of the problem we see

that: •Each department has exactly one supervisor. 

•A supervisor is in charge of one and only one

department. 

•Each department is assigned at least one employee. 

•Each employee works for at least one department. 

•Each project has at least one employee working on

it. 

•An employee is assigned to 0 or more projects. 

30

SOLVING THE PROBLEM

4. Identify Attributes • The only attributes

indicated are:• Department names• projects• supervisors • employees• supervisor number• employee number• project number

5. Define Primary Keys 

• The primary keys are:

• Department Name• Supervisor Number• Employee Number

Project Number

6. Draw Key-Based ERD 

31

7. Draw fully attributed ERD 

PROBLEM SOLVED

32

SUMMARY• ER Modeling models information conceptually

• Based on functional business needs

• “What”, not “How”

• Diagrams provide easy means of communication for both analyst and user

• When creating ERD the most important steps are:• Define entities• Define attributes• Define relationships

• Identify relationship cardinality (1:1, 1:M, M:M)

33

REFERENCES

• Gillenson, Mark L.,2012, Fundamentals of Database Management Systems / Mark L. Gillenson.—2nd ed., John Wiley and sons inc

• http://users.csc.calpoly.edu/~jdalbey/308/Lectures/HOWTO-ERD.html

• http://www.darkopetrovic.com/pdf/Data-Modeling-and-Relational-Database-Design.pdf