THE RELATIONAL DATA MODEL SECTION 4 General Concepts

THE RELATIONAL DATA MODEL

SECTION 4

General Concepts

Introduction

• E.F. Codd in 1970

• Existing databases used physical pointers

• What is the problem with pointers?

• User unaware of physical structure

• Codd proposed two data manipulation languages

• Relation model overcame problems

Fundamental Concepts

• Organizes data using tables or relations

• What is a relation?

• The following example

An ER model

Hours-per-WeekBonus-RateSkill-Type

SKILL

HAS-SKILL

1

M1

ASSIGNEDTO

M N

WORKER

Name Worker-IdHourly-

Rate

WORKER

Bldg-Id Address

Type

Quality-Level

StatusBUILDINGSUPERVISES M

No.-of-DaysStart-Date

• Recursive relationship

• Relation attribute

• Degree of relation

• Tuple

• Attribute Domain

Conceptual Model Relation Attribute

Worker –ID (Attribute) WORKER-ID

Name (Attribute) NAME

Hourly-Rate (Attribute) HOURLY-RATE

HAS-SKILL (Relationship) SKILL-TYPE

SUPERVISES (Relationship) SUPV-ID

Attributes of WORKER

WORKER TABLE

WORKER-ID NAME HOURLY-RATE SKILL-TYPE SUPV-ID

1235 M. Faraday 12.50 Electric 1311

1412 C. Nemo 13.75 Plumbing 1520

2920 R. Garret 10.00 Roofing

3231 P. Mason 17.40 Framing

1520 H. Rickover 11.75 Plumbing

1311 C. Coulomb 15.50 Electric

3001 J. Barrister 8.20 Framing 3231

attributes

rows

or

tuples

Null Values

• Might not know the value

• Null value is not a blank or zero

• Attribute may not be applicable

Keys

• Primary Key

• Key

• Functionally Determine

• Composite key

Foreign Keys

• Need not have the same name

• Recursive foreign key

• Relational database schema

• What is a foreign key?

Integrity Constraints

– No key attribute of any row in a relation may have a null value

• Referential integrity rule

– Every foreign key must either be null, or its value must be the actual value of a key in another relation

• Entity integrity rule

The Normalization Process

• Normalization

WORKER TABLE

WORKER-ID NAME SKILL-TYPE SUPV-ID BLDG-ID

1235 M. Faraday Electric 1311 312

1235 M. Faraday Electric 1311 515

1412 C. Nemo Plumbing 312




1311 C. Coulomb Electric 435

• Data Redundancy

• Data Integrity

• Update Anomaly

• Insertion Anomaly

• Decomposition of Relations

• Normal Forms

First Normal Form (1NF)

• An example not in 1NF

• All attribute values must be atomic

WORKER TABLE

WORKER-ID NAME SKILL-TYPE SUPV-ID BLDG-ID

1235 M. Faraday Electric 1311 {312, 515}

1412 C. Nemo Plumbing {312, 460, 435, 515}

1311 C. Coulomb Electric 435

Functional Dependencies

• Examples:

– FD: WORKER-ID NAME– FD: WORKER-ID SKILL-TYPE

• Definition:

– FD: A B

Second Normal Form (2NF)

• Can be violated only when a key is a composite key

• A relation is in 2NF if no nonkey attribute is functionally dependent on just part of the key

WORKER-BLDG TABLE

WORKER-ID BLDG-ID START-DATE NAME

1235 312 10/10 M. Faraday

1412 312 10/01 C. Nemo

1235 515 10/17 M. Faraday

142 460 12/08 C. Nemo

142 435 10/5 C. Nemo

•Leaving this relation in non-2NF can cause problems

• Worker name repeated

• Update anomaly

• Data inconsistency

• Insertion anomaly

• How to solve?

WORKER-BLDG TABLE

WORKER-ID BLDG-ID START-DATE

1235 312 10/10

1412 312 10/01

1235 515 10/17

1412 460 12/08

1412 435 10/5

WORKER-ID TABLE

WORKER-ID NAME

1235 M. Faraday

1412 C. Nemo

The tables are projections of the previous table

Third Normal Form (3NF)

• A relation is in 3NF if for every FD: X Y, X is a key

WORKER TABLE

WORKER-ID SKILL-TYPE BONUS-RATE

1235 Electric 13.50

1412 Plumbing 13.00

1311 Plumbing 13.00

Note. FD: WORKER-ID SKILL-TYPE

Also note . FD: WORKER-ID BONUS-RATE

•But there is one more functional dependency

•Thus is the relation in 3NF?

•Problems if not in 3NF?

• Skill type’s bonus rate is repeated

• Update and deletion anomalies

• Insertion anomaly

WORKER-SKILL TABLE

WORKER-ID SKILL-TYPE

1235 Electric

1412 Plumbing

1311 Plumbing

•Boyce-Codd Normal Form

•Transitive dependencies

SKILL-BONUS TABLE

SKILL-TYPE BONUS-RATE

Electric 13.50

Plumbing 13.00

Plumbing 13.00

Transforming a Conceptual Model to a Relational Model• Conceptual models provide an accurate

representation

• Few systems exist on which conceptual models are implemented

• A conceptual model consists of– Entities/objects, relationships, and attributes

Transforming Entity Sets and Attributes

• Can transform this conceptual model into a relation as follows: PERSON (SIN, Sex, DOB)

PERSON

SIN Sex DOB

• The transformation: SALE (Amount, Product-#)

• The problem? SALE (Sale-#, Amount, Product-#)

SALE

Amount Product-#

Transforming Models Without External Keys

Summarization:

• If no attribute can be identified as a key, then an attribute is added to the relation with the understanding that its values uniquely identify entity instances.

• An entity set with attributes can be transformed using the entity set as the relation’s name, and the entity attributes as the relations attributes. If any attribute can be used as key, then it becomes the relations key.

Transforming Specialization Entity Sets

PERSON

SIN Name Address

MARRIEDPERSON

Spouse

• What to do with MARRIED PERSON?

MARRIED-PERSON (SIN, NAME, ADDRESS, SPOUSE)

Foreign Key: SIN References PERSON

Transforming Relationships

• One-One

• Three ways depending on the relationships cardinality

CUSTOMERCHEQUINGACCOUNT

HAS-ACCOUNT

1 1

CUST-# NAME ADDRESS CH-AC-#

• Have two relations

CUSTOMER (CUSTOMER-#, NAME ADDRESS) CHEQUING-ACCOUNT (CH-AC-#)

• How to relate the two relations? CUSTOMER (CUSTOMER-#, NAME ADDRESS, CH-AC-#) CHEQUING-ACCOUNT (CH-AC-#, CUSTOMER-#)

• The problem? CUSTOMER (CUSTOMER-#, NAME ADDRESS) CHEQUING-ACCOUNT (CH-AC-#, CUSTOMER-#, BALANCE)

Foreign Key: CUSTOMER-# References CUSTOMER

• One-Many


HAS-ACCOUNT

1 M


CHEQUING-ACCOUNT (CH-AC-#, CUSTOMER-#, BALANCE)


CUSTOMER (CUSTOMER-#, NAME, ADDRESS)

• Many-Many


HAS-ACCOUNT

N M


•Must establish an Intersection RelationCUSTOMER (CUSTOMER-#)

CHEQUING-ACCOUNT (CH-AC-#)

HAS-ACCOUNT (CUSTOMER-#, CH-AC-#)


CH-AC-# References CHEQUING ACCOUNT

CHEQUING ACCOUNT RELATION

CH-AC-#-#

CA888

CA777

CA999

HAS-ACCOUNT RELATION

CUSTOMER-# CH-AC-#

2222 CA999

2222 CA888

3333 CA777

1111 CA777

1111 CA888

• The Relations

CUSTOMER RELATION

CUSTOMER-#

1111

2222

3333

Transforming Aggregate Entity Sets

PRODUCT COUNTRYIS –SOLD-INN M

Quantity

PRODUCT (PRODUCT-#)

COUNTRY (COUNTRY-NAME)

IS-SOLD-IN (PRODUCT-#, COUNTRY-NAME, QUANTITY)

Foreign Key: PRODUCT-# References PRODUCT

COUNTRY-NAME References COUNTRY

SALESPERSON

SOLD-BY

QuantityPRODUCT COUNTRYIS –SOLD-INN M

• Relating IS-SOLD-IN to SALESPERSON

•Resulting Relational Model

PRODUCT (PRODUCT-#)


SALESPERSON (SALESPERSONNUMBER)

IS-SOLD-IN (PRODUCT-#, COUNTRY-NAME)

SOLD-BY (PRODUCT-#, COUNTRY-NAME, SPN, QUANTITY)

•Problems?

• Essentially a Three-Way Relationship

PRODUCT (PRODUCT-#)


SALESPERSON (SPN)

SOLD (PRODUCT-#, COUNTRY-NAME, SPN,QUANTITY)

Foreign Key: PRODUCT-# References PRODUCT

COUNTRY-NAME References COUNTRY

SPN References SALESPERSON

QuantityPRODUCT COUNTRYSOLDN M

SALESPERSON

M

Transforming Recursive Relationships

•Could do the following:WORKER (WORKER-ID, NAME, HOURLY-RATE, WORKER-ID)

•Instead:WORKER (WORKER-ID, NAME, HOURLY-RATE, SUPV-ID)

Foreign Key: SUPV-ID References WORKER

WORKER WORKERSUPERVISES1 M

Hourly-Rate

Worker-IdName

WORKER

WORKER-ID NAME HOURLY-RATE SUPV-ID

1235 M. Faraday 12.50 1311

1412 C. Nemo 13.75 1520

2920 R. Garret 10.00

3231 P. Mason 17.40

1520 H. Rickover 11.75

1311 C. Coulomb 15.50

3001 J. Barrister 8.20 3231

Transforming Example:Name

CHARGE

CLIENT

ASSESSED-FOR

Title

Address

PROJECTTotal

Invoice-Date

Invoice-#

PERFORMED-FOR

1

M

M

1

DescriptionAmount

SERVICESUPPLY-CHARGE

Consultant

CLIENT

Title

Address

Name

PROJECTTotal

Invoice-Date

Invoice-#

PERFORMED-FOR

1

M

•Project and Client Entity Sets

CLIENT (CLIENT-NAME, CLIENT-ADDRESS)

PROJECT (PROJECT-#, CLIENT-NAME, PROJECT-TITLE, TOTAL-CHARGE, INVOICE-#, INVOICE-DATE)

Foreign Key: CLIENT-NAME References CLIENT

•Charge and Service Entity Sets

CHARGE (CHARGE-#, PROJECT-#, AMOUNT, DESCRIPTION)

SERVICE (CHARGE-#, PROJECT-#, CONSULTANT)

Foreign Key: CHARGE-#, PROJECT-#, References CHARGE

DescriptionAmount

CHARGE

SERVICE

Consultant

•What about the Assessed-For Relation and the Entity Supply-Charge?

ASSESSED-FOR

1

SUPPLY-CHARGE

M

DescriptionAmount

CHARGE

SERVICE

Consultant

CLIENT

Title

Address

Name

PROJECTTotal

Invoice-Date

Invoice-#

PERFORMED-FOR

1

M

Why Bother with a Conceptual Model?

• Why create a conceptual model at all?

• Complexity

CLIENT (CLIENT-NAME, CLIENT-ADDRESS)

PROJECT (PROJECT-#, CLIENT-NAME, PROJECT-TITLE, TOTAL-CHARGE, INVOICE-#, INVOICE-DATE)

Foreign Key: CLIENT-NAME References CLIENT

CHARGE (CHARGE-#, PROJECT-#, AMOUNT, DESCRIPTION)

SERVICE (CHARGE-#, PROJECT-#, CONSULTANT)

Foreign Key: CHARGE-#, PROJECT-#, References CHARGE

•Consider this example

Documents

THE RELATIONAL DATA MODEL SECTION 4 General Concepts