Chapter 2: Foundation Concepts Data Modeling and Database Design

Chapter 2: Foundation Concepts

Data Modeling and Database Design

Chapter 2 – Foundation Concepts 2

Conceptual Data Modeling

• Overall activity of attempting to represent meaning is called semantic or conceptual modeling

• The need for conceptual modeling in database design – Opportunity for enhanced user participation in the design

process

– Merits that accrue from DBMS-independent modeling

– Ease of understanding of the big picture and the consequent facilitation of maintenance of schemas and applications in the long run


Conceptual-ModelingGrammar

Conceptual-ModelingScripts

Conceptual Modeling Context

Figure 2.1 Wand and Weber (2002) Framework For Research in Conceptual Modeling

Individual DIfference Factors Task Factors

Social Agenda Factors

Conceptual-Modeling Method

Conceptual Modeling Context


Conceptual Model

A conceptual model involves: • A context, a setting in which the phenomena being

modeled transpires• A grammar that defines a set of constructs and rules for

the phenomenon• A method that describes how to use the grammar

The product of conceptual modeling is the conceptualmodeling script (e.g., an ER model, a NIAM model, a semantic object model).


Entity-Relationship (ER) Model

• Modeling grammar originally proposed by Peter Chen in 1976

• The most widely accepted data modeling grammar for conceptual design

• Chosen by ANSI in 1988 as the standard model for Information Resource Directory Systems (IRDSs)

• ER modeling grammar obeys the attributes of a semantic data modeling technique: expressiveness, simplicity, minimalism, formality, and unique interpretation


Entity-Relationship (ER) Model (continued)

• Core pieces (units) of the ER modeling grammar: (1) entities, (2) attributes, and (3) relationships


Units of the E-R Modeling GrammarEntity

• Entity type– Conceptual representation of an object type

– A set of related attributes

– Has relationship(s) with other entity types

• Base entity type; Weak entity type• Entity: An instance (occurrence) of an entity type• Entity Set: A collection (set) of entities (i.e., entity

instances) of an entity type• Entity class: A set of entity types that have shared

properties


Units of the E-R Modeling GrammarAttribute

Conceptual representation of a property of an object type – object has properties and entity has attributes


Attribute


Unique Identifier, Key Attribute and Non-Key Attribute

• Unique identifier– An attribute, atomic or composite, whose values are

distinct for each entity in the entity set

• Key attribute– Any attribute that is a constituent part of a unique

identifier is a key attribute

– A key attribute is a proper subset of a unique identifier

• Non-key attribute– Any attribute that is not a constituent part of (subset of)

a unique identifier


PATIENT

Age

Phone

AddressSSN

Medical Profile

Allergy

CodeName

Intensity

Blood

Type

Cholesterol

Sugar

HDL

LDLTriglyceride

Date_of_Birth

Pat_ID

Pat_No

Pat_Prefix

M_Int

L_Name

F_Name

Pat_Name

Height Weight

Figure 2.3 A graphical representation of an entity type PATI ENT

An Example of an Entity Type

An Example of an Entity Type (Continued)


Note various attribute characteristics in PATIENT:

• Optional simple/atomic: Date_of_ birth, Address• Optional multi-valued: Phone• Optional simple/atomic derived: Age• Mandatory composite: Pat_Name, Pat_ID• Mandatory simple/atomic that serves as a unique

identifier: SSN• Mandatory composite that serves as a unique

identifier: Pat_ID• Complex: Medical Profile


Entity and Attribute-Level Data Integrity Constraints

• Data integrity constraints (or simply integrity constraints) are rules that govern behavior of data at all times in a database

• In other words, integrity constraints are technical expressions of the rules that govern the envorinment

• They must be preserved across all three tiers of data modeling

• Some constraints cannot be expressed explicitly in an ERD and are therefore carried forward in textual form (i.e., semantic integrity constraints)


Example


Entity and Attribute-Level Data Integrity Constraints

• At the conceptual tier of data modeling, two types of data integrity constraints pertaining to entity types and attributes are specified – The domain constraint imposed on an attribute to

ensure that its observed value is not outside the defined domain

– Intra-entity constraints impose rules on groups of attributes within the same entity type

– The key (or uniqueness) constraint that requires entities of an entity type to be uniquely identifiable


Relational & Business rule Integrity Constraints

• Between entity types other constraints exist.– The referential integrity constraint imposes limits

on the number of entity occurrences that may participate in the relationship.

– The business rule constraint places other, complex, rules on the data stored in the database.


Units of the E-R Modeling Grammar Relationship Type

• Relationship Type– Conceptualization of association between object types

• Binary (degree = 2); ternary (degree = 3); n-ary (degree = n); unary [recursive] (degree = 1)

• Structural constraints {Multiplicity}– Cardinality ratio or Cardinality constraint { ~ connectivity}

• 1:1 1:n n:1 m:n• Maximum cardinality

– Participation constraint• Minimum cardinality• Total participation {existence dependency}• Partial participation


n-ary Relationships

PILOT FLIGHTFlies

Figure 2.4 A binary relationship

n-ary Relationships (continued)

• Example 1.Professor Einstein teaching Physics using Introduction to Physics.

• Example 2. Professor Einstein teaching Physics using Principles of Physics.

• Example 3. Professor Einstein teaching Math using Principles of Calculus.

• Example 4. Professor Chu teaching Math using Introduction to Calculus.

PROFESSOR SUBJECT

Teaches

Figure 2.5 A ternary relationship

COURSE


• Example 1. Dr. Fields prescribes Advil to treat Sharon Moore for a headache.

• Example 2. Dr. Fields prescribes Advil to treat Michelle Li for a headache.

MEDICATION

PHYSICIAN

Prescribes

Figure 2.7 A quaternary relationship

ILLNESS

PATIENT



NURSE

Supervises

Figure 2.8 A recursive relationship


Role Names

FLIGHTPILOT

Flies

Scheduled_for

Member_of_Crew

Captain_of

Crew

Commanded_by

Figure 2.10 Role names in binary relationships

A pilot is the captain of a flight.

A flight is commanded by a pilot.

A pilot is a member of a crew.

A flight crew includes a pilot.


Structural Constraints of a Relationship Type

• Two structural constraints define a relationship type– Cardinality constraint (ratio) specifies the maximum number

of instances of an entity type that relate to a single instance of an associated entity type through a binary relationship type (i.e., 1:1, 1:n, n:m = maximum cardinality)

– Participation constraint is based on whether, in order to exist, an entity of that entity type needs to be related to an entity of the other entity type through a binary relationship type (i.e., total/mandatory or partial/optional = minimum cardinality); total participation = existence dependency


Cardinality Constraint (Ratio)

CERTIFICATION

EMPLOYEE

Certificate

m

n

Receives

Given_to

Figure 2.12 An illustration of cardinality ratio of m:n

c1

c2

c3

c4

c5

e1

e2

e3

e4

r1

r2

r3

r4

r5

r6

CERTIFICATION Certificate

ER Diagram

I nstance Diagram

EMPLOYEE


Cardinality Constraint (Ratio) (continued)

Assigned

Assigned_toCOMPUTER

EMPLOYEE

Assignment

1

1

Figure 2.14 An illustration of cardinality ratio of 1:1

c1

c2

c3

e1

e2

e3

e4

e5

r1

r2

r3

COMPUTER Assignment EMPLOYEE

ER Diagram I nstance Diagram


Cardinality Constraint (Ratio)(continued)

VEHICLE

SALESPERSON

Sales

1

n

Sells

Sold_by

Figure 2.13 An illustration of cardinality ratio of 1:n or n:1

s1

s2

s3

v1

v2

v3

v4

v5

r1

r2

r3

r4

r5

SALESPERSON Sales VEHICLE

ER Diagram I nstance Diagram


Participation Constraint

VEHICLE

SALESPERSON

Sales

Figure 2.15(a) Total participation of SALESPERSON and VEHI CLE in Sales(Every salesperson sells at least one vehicle andevery vehicle is sold by at least one salesperson)

Note: Look across mandatory participation

Sold_by

Sells

s1

s2

s3

v1

v2

v3

v4

v5

r1

r2

r3

r4

r5

Sales

I nstance Diagram

SALESPERSON VEHICLE


Participation Constraint (continued)

Figure 2.15(b) Partial participation of SALESPERSON and VEHI CLE in Sales(Some salespersons may not sell any vehicle and

some vehicles may not be sold by any salesperson)

VEHICLE

SALESPERSON

Sales

Note: Look across optional participation

Sold_by

Sells

s1

s2

s3

v1

v2

v3

v4

v5

r1

r2

r3

r4

Sales

I nstance Diagram

SALESPERSON VEHICLE

VEHICLE

SALESPERSON

Sales

1

n

Figure 2.16(a) Cardinality ratio of 1:n and total participation of VEHI CLE and total participation of SALESPERSON in Sales

Note: Look across mandatory participation

Sold_by

Sells

s1

s2

s3

v1

v2

v3

v4

v5

r1

r2

r3

r4

r5

I nstance Diagram

Sales VEHICLESALESPERSON

Cardinality Ratio and Participation Constraints

VEHICLE

SALESPERSON

Sales

1

n

Figure 2.16(b) Cardinality ratio of 1:n and partial participation of VEHI CLE and partial participation of SALESPERSON in Sales

Note: Look across Optional participation

Sold_by

Sells

s1

s2

s3

v1

v2

v3

v4

v5

r1

r2

r3

r4

I nstance Diagram


Cardinality Ratio and Participation Constraints(continued)

VEHICLE

SALESPERSON

Sales

1

n

Figure 2.16(c) Cardinality ratio of 1:n and partial participation of VEHI CLE and total participation of SALESPERSON in Sales

Note: Look across mandatory participation of SALESPERSON and optional participation of VEHICLE in Sales

Sold_by

Sells

s1

s2

s3

v1

v2

v3

v4

v5

r1

r2

r3

r4

I nstance Diagram



VEHICLE

SALESPERSON

Sales

1

n

Figure 2.16(d) Cardinality ratio of 1:n and total participation of VEHI CLE and partial participation of SALESPERSON in Sales

Note: Look across mandatory participation of VEHICLE and optional participation of SALESPERSON in Sales

Sold_by

Sells

s1

s2

s3

v1

v2

v3

v4

v5

r1

r2

r3

r4

r5

I nstance Diagram




NURSE

Supervises

n1

Supervisor Supervisee

n1

n2

n3

n4

n5

n6

r1

r2

r3

r4

r5

r6

NURSE Supervises

I nstance Diagram

u

u e

e

u

eu

e

u

e

Figure 2.17(a) Cardinality ratio of 1:n and partial participation of NURSE as supervisor and as supervisee in Supervises

Note: The symbols u and e in the instance diagram represent the roles Supervisor and Supervisee respectively in the ER diagram



NURSE

Supervises

n1

Supervisor Supervisee

n1

n2

n3

n4

n5

n6

r1

r2

r3

r4

r5

r6

NURSE Supervises

I nstance Diagram

u

e

e

u

u

eu

e

u

e

ue

Figure 2.17(b) Cardinality ratio of 1:n and partial participation of NURSE as supervisor and total participation as supervisee in Supervises

Note: The symbols u and e in the instance diagram represent the roles Supervisor and Supervisee respectively in the ER diagram



COURSE

Prerequisite

m n

Prerequisite_for Has_prerequisite

c1

c2

c3

c4

c5

c1

c2

c3

c4

c5

r1

r2

r3

r4

r5

Prerequisite

I nstance Diagram

COURSE COURSE

Figure 2.18(a) Cardinality ratio of m:n and partial participation of COURSE as prerequisite_f or and as has_prerequiste in Prerequisite

f

f

f

f

f

h

h

h

h

h

Note: The symbols f and h in the instance diagram represent the roles Prerequisite_for and Has_prerequisite respectively in the ER diagram



COURSE

Prerequisite

m n

Prerequisite_for Has_prerequisite

c1

c2

c3

c4

c5

r1

r2

r3

r4

r5

Prerequisite

I nstance Diagram

COURSE

f

f

f

f

h

h

h

h

Figure 2.18(b) Cardinality ratio of m:n and partial participation of COURSE as prerequisite_f or and as has_prerequiste in Prerequisite

Note: The symbols f and h in the instance diagram represent the roles Prerequisite_for and Has_prerequisite respectively in the ER diagram

hf



Putting It All Together

DEPARTMENTPROFESSOR

Heads

Figure 2.19 An attribute of a relationship in a 1:1 relationship type

Start_dt

Name

1 1

Name

Note: Since the cardinality constraint of Heads is 1:1, Start_dt can be an attribute of either PROFESSOR or DEPARTMENT instead of being an attribute of Heads

Rank

Size


STUDENTDORMITORY Occupies

Stu_no

1 n

Name

GenderName

No_of_rooms Type

Rent

Figure 2.20 An attribute of a relationship in a 1:n relationship type

Putting It All Together (continued)


STUDENTDORMITORY Occupies

Stu_no

1 n

Name

GenderName

No_of_rooms Type

Figure 2.21 Rent as an attribute of the entity type STUDENT instead of being an attribute of the relationship type Occupies as in Figure 2.20

Rent

Note: Rent cannot be an attribute of DORMITORY, the parent entity type in the relationship type Occupies



PRODUCTVENDOR Importsn m

Cost

Figure 2.22 An attribute of a relationship in a m:n relationship type

Note: Since the cardinality constraint of Imports is m:n, Cost cannot be an attribute of either VENDOR or PRODUCT instead of being an attribute of Imports



Something To Think About

• Think of each entity type and relationship type as a separate table for right now

• For example:

Vendor

VenID VenName

1 Joe Inc

2 Bill Inc

Supplies

VenID ProdID Cost

2 25 7

1 24 8

1 25 7

Product

ProdID ProdName

23 Soup

24 Noodles

25 Chocolate


Base/Strong vs. Weak Entity Types

BUILDING APARTMENTContains

Bldg_no

No_of_floors

Size

Vacancy

1 N

Apt_no

No_of_bedrooms

Sqr_ft

No_of_bathrooms

Rent


Base/Strong vs. Weak Entity Types (continued)

• Base (or strong) entity types are those where the entities have independent existence (i.e., each entity is unique)– A base entity type has a unique identifier

• Weak entity types are those where entities have a dependent existence (i.e., duplicate entity instance may be present)– A weak entity type does not have a unique identifier

• A weak entity type has an “identifying relationship” with an identifying parent entity type

• A weak entity type has a “partial key” – also known as a “discriminator”


Partial Key (Discriminator) Defined

Partial Key - An attribute, atomic or composite, in a weak entity type, which in conjunction with a unique identifier of the parent entity type in the identifying relationship type, uniquely identifies weak entities is called the partial key of a weak entity type.

BUILDING APARTMENTContains

Bldg_no

No_of_floors

Size

Vacancy

1 N

Apt_no

No_of_bedrooms

Sqr_ft

No_of_bathrooms

Rent

Building Data SetBldg_no #Floors Size (sq. ft) VacancyS51 3 15425 6S52 1 3250 N51 3 15425 6N52 3 16250 4

APARTMENT Data Set*Apt_no #bedrooms #bathrooms Size (sq. ft) Rent 11 1 1 600 830 12 1 1 660 850 21 2 930 985 22 1 1 600 830 11 1 1 600 830*The first four apartments listed are located in Building Number S51 while the fifth apartment is located in Building Number N51.

Figure 2.23 Weak entity type: an example

Sample Data Sets for BUILDING and APARTMENT


Exercises

Draw a data model for each of the following problems:• A farmer can have many cows, but a cow belongs to only one

farmer.• A nation can have many states and a state many cities.• A patient can have many physicians, and a physician can have

many patients.• A dairy farmer has several herds of cows. He has assigned each

cow to a particular herd. In each herd, the farmer has one cow that is his favorite.

For each data model, identify cardinality ratio, participation constraints, as well as domain and key constraints!


Vignette 1


COLLEGESizeName

Location

Name

Credit_hr

Course#

Course

QualificationEmp_id

Experience

Instructor

Figure 2.28a The entity type COLLEGE

Vignette 1 (continued)


Semantic Problems:

A college offers many courses and also has several instructors.

The attribute Name occurs twice in the COLLEGE entity type.



COLLEGESizeName

Location

Course_name

Credit_hr

Course#

Course

QualificationEmp_id

Experience

Instructor

Figure 2.28b I nstructor and Course as multi-valued attributes of the entity type COLLEGE



Another semantic problem:

An instructor is capable of teaching a variety of courses, but this is not shown in Figure 2.28b.



COLLEGESizeName

Location

Course_name

Credit_hr

Course#

Course

QualificationEmp_id

Experience

Instructor

Can_teachn1

Figure 2.28cA syntactically incorrect relationship between I nstructor and Course in COLLEGE



Syntactic problem:

While Figure 2.28c depicts a relationship between courses and instructors, a syntactical rule of the ER modeling grammar is violated. A relationship between attributes of an entity type is not permitted in the grammar.



COLLEGESize

NameLocation

Course_name

Credit_hr

Course#

Qualification

Emp_id

Experience

Can_teachn1

Figure 2.28d A syntactically correct relationship between I NSTRUCTOR and COURSE

INSTRUCTOR

COURSE

Employs1

m

Enrollment

Term

Year

Qtr#

Name



The syntactic error in Figure 2.28c is corrected by modeling COURSE and INSTRUCTOR as independent entity types related to the COLLEGE entity type, and establishing a relationship between the COURSE and INSTRUCTOR entity types.

In addition, since courses are offered every term, Term is modeled as an optional multi-valued attribute of COURSE.



COLLEGESize

NameLocation

Course_name

Credit_hr

Course#

Qualification

Emp_id

Experience

Can_teachn1

Figure 2.28e A syntactically incorrect m:n relationship between I NSTRUCTOR and Term

INSTRUCTOR

COURSE

Employs1

m

Enrollment

Term

Year

Qtr#

Scheduledmn

Name



COLLEGESize

NameLocation

Course_name

Credit_hr

Course#

Qualification

Emp_id

Experience

Can_teachn1

Figure 2.28f A syntactically correct m:n relationship between I NSTRUCTOR and TERM

INSTRUCTOR

COURSE

Employs1

m

Enrollment

Scheduledn

Year

Qtr#

m

TERM

Name



Figure 2.28f is good, but the fact that courses are offered over the four terms, and in each term one or more of the courses are offered, is yet to be incorporated in the ER diagram.

In addition, the business rule that the same course is never taught by more than one instructor in a specific term is not incorporated in the conceptual model either.



COLLEGESize

NameLocation

Course_name

Credit_hr

Course#

Qualification

Emp_id

Experience

Can_teachn1

Figure 2.28g A syntactically incorrect 1:n relationship between I nstructor and Off ered

INSTRUCTOR

COURSE

Employs1m

Enrollment

Scheduled

n

Quarter

YearQtr#

m

TERM

Offered

Assigned

m

nn

1Name




Note that a syntactic error is created in the attempt to convey the business rule that says the same course is never taught by more than one instructor in a specific term.

It is illegal to express a relationship between the relationship type Assigned and another relationship type Offered.


COLLEGESize

Name

Location

Name

Credit_hr

Course#QualificationEmp_id

Experience

Can_teachn1

Figure 2.28h A syntactically correct 1:n relationship between I NSTRUCTOR and OFFERI NG

INSTRUCTORCOURSE

Employs1

m

Enrollment

Scheduled

n

Quarter

YearQtr#

m

TERM

Assigned

n

1

Name

OFFERING

Has

Has

n

m

1

1



Vignette 3


VENDOR

PART

Supplied_by

Rating

Phone#Name

WeightSizeName

1 n

Figure 2.30a Semantic errors in PART and VENDOR

Part#

Color

Design

Qlty_std

CostRaw_material

Prod_planPrice

Delv_sch

PRODUCTION_PLAN

As_per

Time_tblMach_seqPlan#1 m

Capacity

Part_id



VENDOR

PART

Supplied_by

Rating

Phone#

NameWeightSize

Name

1 n

Figure 2.30b Semantic errors in PART and VENDOR in Figure 2.30a corrected

Part#Color

Design

Qlty_std

CostRaw_material

Prod_planPrice

Delv_sch

PRODUCTION_PLAN

As_per


Capacity

Corrected semantic errors:• Phone# in VENDOR is a multi-valued attribute.• Part# and Name are two distinct unique identifiers of PART.



VENDOR

PURCHASED_PART

Supplied_by

Rating

Phone#

NameWeightSize

Name

1 n

Figure 2.30c Entity type PART in Figure 2.30b split into two entity types

Part#Color

Design

Qlty_std

PriceDelv_sch

PRODUCTION_PLAN

As_per

Time_tblMach_seqPlan#

1 m

Capacity

MANUFACTURED_PART

NameWeightSize

Part#Color

Design

Qlty_std

Cost Raw_materialProd_plan

Note: Every entity of the PURCHASED_PART entity set must have a value for either Part# or Name



VENDOR

PURCHASED_PART

Supplied_by

Rating

Phone#

Name

1 n

Figure 2.30d PART-May_have-SUB_PART modeled

Part#Price

Delv_sch

PRODUCTION_PLAN

As_per

Time_tblMach_seq

1 m

Capacity

MANUFACTURED_PART

Part#


PART

NameWeightSize

Part#Color

Design

Qlty_std

Purchased

Manufactured

SUB_PART

Name Weight

SizePart#

Color

Design

Qlty_std

May_have

11

1

1 1

n



VENDOR

PURCHASED_PART

Supplied_by

Rating

Phone#

Name

1 n

Figure 2.30e PART-Sub_part as a recursive relationship

Part#Price

Delv_sch

PRODUCTION_PLAN

As_per

Time_tblMach_seqPlan#

1 m

Capacity

MANUFACTURED_PART

Part#


PART

NameWeightSize

Part#Color

Design

Qlty_std

Purchased

Manufactured

Sub_part

11

1

1

1

May have

n

Is a



VENDOR

Supplied_by

Rating

Phone#

Name

1 n

Figure 2.30f PART-Sub_part as a recursive relationship – An alternative design

PRODUCTION_PLAN

As_per


Capacity

PART

Name

WeightSize

Part#Color

Design

Qlty_std

Sub_part1

May have

n

Is a

Cost

Raw_material Prod_plan

Manufactured

Price

Delv_sch

Purchased


Documents

Chapter 2: Foundation Concepts Data Modeling and Database Design