Database Design

Lessons 2 & 3Database Models, Entities, Relationships

Database Design Conceptual

Analysis What

Logical Design How

Physical Build

Data Information

An Entity

Something of significance to business about which data must be known

A name for the things that you can list A single name of noun Entities have Instances

Occurrences of entities Rows

Entities vs. Instance Entities can be:

Tangible, like Person or Product Nontangible, like skill level An event, like concert, graduation,

wedding Instance examples:

Animal entity instances like, Dalmatian, Siamese cat, cow, tiger

Car entity instances like, sedan, station wagon, SUV, convertible

Examples

Entity = Product New York = instance Director can be either an entity or

instance – context is important

Attributes

Entities have Attributes Single-value property, detail of an

entity Piece of information that describes,

qualifies, quantifies, classifies and/or specifies an entity

Property of an entity Attributes have a data type

Attributes

Describe an entity Attribute vs. attribute value

color vs. blue animal type vs. dog

Can have one and only one value at a given point in time

One or more attributes must be defined as a unique identifier (UID)

Unique Identifier (UID)

Used to distinguish one instance of an entity from another Example: Student ID as a UID for

student entity part number as a UID for product entity Social security number (UID) for

employee Denote with a #

Attributes Must be a single-values at any point

in time Should be stored in one and only one

entity Values have data type Example: entity CAR may have

attributes “model” & “color” (values of “beetle”, “green”)

An attribute may change over time

Attribute

Volatile may change with time, like age should look for non-volatile attributes

like birth date rather than age

Mandatory vs. Optional email address mandatory for EMPLOYEE

if modeling email application email address optional for CUSTOMER is

modeling an online catalog

Entity relationship diagram (ERD)

Visual way to display business requirements

Tool used in design stage Used to react to, validate, and correct

data in database Entities should be “implemetation-

free”

Relationship Represents something significant to a

business Expresses how entities are mutually related Always exist between entities Always have two perspectives Is named at both ends Between two entities (or one entity and

itself) Have an optionality Have a degree or cardinality

Conventions Entities appear as all capital letters and

singular Relationships are italicized Entities are placed in soft boxes (rounded

corners) Examples:

EMPLOYEE hold JOBs JOBs are held by EMPLOYEEs PRODUCTs are classified by a PRODUCT TYPE PRODUCT TYPE classifies a PRODUCT

Optionality of relationships

A relationship adds a link between entities

Relationships come from business rules

Is it a mandatory or optional relationship

Optionality of relationships Are either Mandatory or Optional

Mandatory value is a REQUIRED field Use MUST to describe Denoted with an * and a solid line

Optional value may be supplier or not Use MAY to describe Denoted with a ° and a dashed line

Example: Each DEPARTMENT must have one or more

EMPLOYEEs Each DEPARTMENT may have one or more

EMPLOYEEs

Identifying Relationships Cardinality or Degree of relationship

Describes how many? Use ‘one and only one’ or ‘one or more’

use crow foot to denote ‘one or more’ in ERD Examples:

Each DEPARTMENT may have one or more EMPLOYEEs

Each EMPLOYEE must be assigned to one and only one DEPARTMENT

See ERD on next slide

ERD

Entities use soft boxes

DEPARTMENT# ID

o nameo location

EMPLOYEE#ID

* first name* last name

o telephone numbero salary

* job

hire

assigned to

Examples:

Each SEAT may be sold to one or more PASSENGERs this example accounts for overbooking

Each PASSENGER may purchase one and only one SEAT

Entity naming Name must be unique Create a description of the entity (be

explicit) Be aware of homonyms

Market = 16 to 25 years Market = Europe, Asia etc.

Avoid reserved words Remove the relationship name from

the entity name

ERD conventions - summary

Entities go in soft boxes Entity names are singular and written

in all capital letters Attributes go under Entity # is a UID (unique identifier – Key) * mandatory attribute o optional attribute

ERD conventions - summary

Relationships are lines (optionality) solid are mandatory dashed are optional

Lines terminations express cardinality “single toe” denotes “one and only one” “crow’s foot” denotes “one or more”

Example

Each HAIRSTYLIST may work on one or more CLIENTs

Each CLIENT must be assigned to one and only one HAIRSTYLIST

See next slide to ERD

ERD diagram

List entity and attributes

HAIRSTYLIST# id

* first name*last name* address

* phone number* social-security number

* salary

CLIENT# client number

* first nameo last name

o phone number

work on

assigned to

Conventions

Not a strict requirement (can reverse) this crow is flying east

this crow is flying south

Matrix Diagram 3.4

TRAVELER COUNTRY LANDMARK

TRAVELER Visit Have seen

COUNTRY Visited by The location of

LANDMARK Seen by Located in

ERD

TRAVELER COUNTRY

LANDMARK

visit

visited by

have seen

seen by

the location of

located in

Previous ERD

Note ERD included optionality and cardinality

Note there are several M:M relationship. This is a valid relationship, but discussed in later chapters