Top Banner
Chapter 3 Relational Relational Model Model Chapter 4 in Textbook
40

Chapter 3

Feb 24, 2016

Download

Documents

Payton

Chapter 3. Relational Model. Chapter 4 in Textbook. Database Design. Steps in building a database for an application:. Real-world domain. Conceptual model. DBMS data model. Create Schema (DDL). Load data (DML). Relational Model. - PowerPoint PPT Presentation
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Chapter 3

Chapter 3

Relational ModelRelational Model

Chapter 4 in Textbook

Page 2: Chapter 3

Database DesignDatabase Design

Steps in building a database for an application:

Real-world domain

Conceptualmodel

DBMS data model

Create Schema

(DDL)

Load data(DML)

Relational Model 2

Page 3: Chapter 3

Relational ModelRelational Model

In the relational model, all data is logically structured within relations (tables).

Relational Model 3

Page 4: Chapter 3

Relational Data StructureRelational Data Structure

4170010

4182000

4182034

4188134

4189860

4192134

StudentNo

Al-Saleh

Al-Ghanem

Al-Fahad

Saod

Rashed

Al-Fahad

LName

Amal

Nora

Laila

Amal

Rana

Rania

FName Initial

M.

A.

A.

F.

I.

M.

DOB

04-06-78

02-12-79

01-11-74

22-04-73

30-01-78

19-03-79

GPA

3.91

4.20

4.01

3.01

2.31

3.50

STUDENT

Attributes

Tuples

Car

dina

lity

Rel

atio

n

Degree

Relational Model 4

Page 5: Chapter 3

Relational Data StructureRelational Data Structure

• Relation is a table with columns & rows. Holds information about entities.

• Attribute is a named column of a relation.

• Tuple is a row of a relation.

• Degree of a relation is the number of attributes it contains.

• Cardinality of a relation is the number of tuples it contains.

Relational Model 5

Page 6: Chapter 3

Relational Data StructureRelational Data Structure

• Domain is the set of allowable values for one or more attributes. Every attribute in a relation is defined on a domain.

• Relational database is a collection of normalized relations with distinct relation names.

Relational Model 6

Page 7: Chapter 3

DomainsDomains

4170010

4182000

4182034

StudentNo

Al-Saleh

Al-Ghanem

Al-Fahad

LName

Amal

Nora

Laila

FName Initial

M.

A.

A.

DOB

04-06-78

02-12-79

01-11-74

GPA

3.91

4.20

4.01

STUDENT

StudentNo

LName

FName

Initial

Student Number

Last Name

First Name

Initial

DefinitionAttribute

DOB

GPA

Domain Name

Date of Birth

Great Point Average

Digits: size 7

Character: size 15

Character: size 15

Character: size 3

Date: range 01-01-20, format dd-mm-yy

Real: size 3, decimal 2, range 0-5

Relational Model 7

Page 8: Chapter 3

Properties of RelationsProperties of Relations

• The relation has a name that is distinct from all other relation names in the relational DB.

• Each cell of the relation contains exactly single value.

• Each attribute has a distinct name.

• The values of an attribute are all of the same domain.

• Each tuple is distinct. There are no duplicate tuples.

• The order of attributes has no significance.

• The order of tuples has no significance; theoretically.

Relational Model 8

Page 9: Chapter 3

Relational KeysRelational Keys

• Candidate key (CK) is an attribute, or set of attributes, that uniquely identifies a tuple, and no proper subset is a CK within the relation.

• Primary Key (PK) is the CK that is selected to identify tuples uniquely within the relation.

• Foreign Key (FK) is an attribute, or set of attributes, within one relation that matches the CK of some relation. Used to represent relationship between tuples of two relations.

Relational Model 9

Page 10: Chapter 3

Relational KeysRelational Keys

4170010

4182000

4182034

4188134

4189860

StudentNo

Al-Saleh

Al-Ghanem

Al-Fahad

Saod

Rashed

LName

Amal

Nora

Laila

Amal

Rana

FName Initial

M.

A.

A.

F.

I.

DOB

04-06-78

02-12-79

01-11-74

22-04-73

30-01-78

GPA

3.91

4.20

4.01

3.01

2.31

STUDENT

D001

D002

D003

DeptNo

Computer Science

Business Administration

Science

Department Name

Build # 20

Dept

D001

D001

D002

D003

D001

Location

Build # 45

Build # 6

DEPARTMENTPrimary Key

Foreign Key

Relational Model 10

Page 11: Chapter 3

DB RelationsDB Relations

• Relation schema is a named relation defined by a set of attributes.

If A1, A2, .., An are a set of attributes, then relation schema R1 is: R1 (A1, A2, .., An)

• Relational schema is a set of relation schemas, each with a distinct name.

If R1, R2, .., Rn are a set of relation schemas, then relational schema R is: R = {R1, R2, .., Rn}

Relational Model 11

Page 12: Chapter 3

Relation SchemaRelation Schema

4170010

4182000

4182034

4188134

4189860

StudentNo

Al-Saleh

Al-Ghanem

Al-Fahad

Saod

Rashed

LName

Amal

Nora

Laila

Amal

Rana

FName Initial

M.

A.

A.

F.

I.

DOB

04-06-78

02-12-79

01-11-74

22-04-73

30-01-78

GPA

3.91

4.20

4.01

3.01

2.31

STUDENTDept

D001

D001

D002

D003

D001

STUDENT (StudentNo, Lname, Fname, Initial, DOB, GPA, Dept)

Relational Model 12

Page 13: Chapter 3

Relation SchemaRelation Schema

D001

D002

D003

DeptNo

Computer Science

Business Administration

Science

Department Name

Build # 20

Location

Build # 45

Build # 6

DEPARTMENT

DEPARTMENT (DeptNo, Department Name, Location)

Relational Model 13

Page 14: Chapter 3

ER Relational ModelER Relational Model

Page 15: Chapter 3

Relational ModelRelational Model

• Represent each entity type with a relation.

• Entity type attributes become the relation attributes.

STUDENT (StudentNo, Lname, Fname, Initial, DOB, GPA, Dept)DEPARTMENT (DeptNo, Department Name, Location)

Entity TypeEntity Type

Relational Model 15

Page 16: Chapter 3

Relational ModelRelational ModelA weak entity type relation must include its key and its strong entity type PK as a FK. The combination of the two keys form the PK of the weak entity.

Weak Entity TypeWeak Entity Type

EMPLOYEE

EmpNoLName FName

DOBDepNo FName

DEPENDENThas

EMPLOYEE (EmpNo, Lname, Fname, DOB)DEPENDENT (DepNo, EmpNo, FName)

Relational Model 16

Page 17: Chapter 3

Relational ModelRelational Model• Identify an entity type (S) (preferably total participator).• Include the PK of the other entity (T) as a FK in S.• Add attributes that describes the relationship to S.

1:1 Relationship1:1 Relationship

BRANCHmanageEMPLOYEE

EMPLOYEE(EmpNo, Lname, Fname, DOB)BRANCH(BrnNo, Name, EmpNo, StartDate, EndDate)

1 1

(0,1) (1,1)

StartD EndDEmpNoLName FName

DOBName

BrnNo

Relational Model 17

Page 18: Chapter 3

Relational ModelRelational Model• Identify a participating entity type (S) on the m-side.• Include the PK of the other entity type (T) as a FK in S.• Add attributes that describes the relationship to S.

1:M Relationship1:M Relationship

BRANCHallocateEMPLOYEE

EMPLOYEE(EmpNo, Lname, Fname, DOB, BrnNo)BRANCH(BrnNo, Name)

M 1

EmpNoLName FName

DOBName

BrnNo

Relational Model 18

Page 19: Chapter 3

Relational ModelRelational Model• Create a relation R to represent the relationship.•Include the PK of participating entity types (T & S) as FK in R. The combination of the two FK will form the PK of R.• Add attributes that describes the relationship to R.

M:N RelationshipM:N Relationship

PROJECTwork-onEMPLOYEE

EMPLOYEE(EmpNo, Lname, Fname, DOB)PROJECT(ProjNo, Name)Work-on(EmpNo,ProjNo, hours)

M N

hoursEmpNoLName FName

DOBName

ProjNo

Relational Model 19

Page 20: Chapter 3

Relational ModelRelational Model• Create a relation R to represent the relationship.•Include the PK of the participating entities as FK in R. The combination of all FK form the PK of R.• Add attributes that describes the relationship to R.

n-ary Relationshipn-ary Relationship

SUPPLIERcontractBUSINESS

BUSINESS(BizNo) LAWYER(LawNo) SUPPLIER(SupNo)contract(BizNo, SupNo, LawNo, StartDate, EndDate)

Lawyer

StartD EndDBizNo

LawNo

SupNo

Relational Model 20

Page 21: Chapter 3

Relational ModelRelational Model

Include its simple components in the relation.

Composite AttributeComposite Attribute

EMPLOYEE

emp_noname DOB

LNameinitial FName

EMPLOYEE(EmpNo, Fname, initial, Lname, DOB)

Relational Model 21

Page 22: Chapter 3

Relational ModelRelational Model• Suppose A is a relation that contains the multivalued attribute.• Create a relation R to represent the attribute.• Include the PK of A as FK in R.•The PK of R is the combination of the PK of A (FK) & the multivalued attribute.

MultiValue AttributeMultiValue Attribute

EMPLOYEE

EmpNoDOB

Tel_no

EMPLOYEE(EmpNo, DOB)TELEPHONE(EmpNo, tel_no)

Relational Model 22

Page 23: Chapter 3

EER Relational ModelEER Relational Model

Page 24: Chapter 3

• Suppose specialization with subclasses (S1, S2, .., Sm) & a superclass C.

• Create a relation L to represent C with PK & attributes.

• Include the unshared attributes for each subclass Si, 1 i m.

• Add discriminator in L to distinguish the type of each tuple.

Mandatory / NonDisjointMandatory / NonDisjoint

Relational Model 24

Page 25: Chapter 3

SECRETARY TECHNICIAN ENGINEER

EMPLOYEE( EmpNo, Fname, Lname, DOB, Salary,TypingSpeed,TGrade, EngType, Secretary Flag, Technician Flag, Engineer Flag )

EMPLOYEE

EmpNo

Fname

LName

DOB

Salary

o

TypingSpeed EngType

TGrade

Relational Model 25

Mandatory / NonDisjointMandatory / NonDisjoint

Page 26: Chapter 3

• Suppose specialization with subclasses (S1, S2, .., Sm) & a superclass C.

• Create a relation Li, 1 i m, to represent each combination of super/subclass.

Relational Model 26

Mandatory / DisjointMandatory / Disjoint

Page 27: Chapter 3

SECRETARY TECHNICIAN ENGINEER

SECRETARY(EmpNo, Fname, Lname, DOB, Salary,TypingSpeed)

TECHNICIAN(EmpNo, Fname, Lname, DOB, Salary,Tgrade)

ENGINEER(EmpNo, Fname, Lname, DOB, Salary, EngType)

EMPLOYEE

EmpNo

Fname

LName

DOB

Salary

d

TypingSpeed EngType

TGrade

Relational Model 27

Mandatory / DisjointMandatory / Disjoint

Page 28: Chapter 3

• Suppose specialization with subclasses (S1, S2, .., Sm) & a superclass C.

• Create a relation L1 to represent C with PK & attributes.

• Create a relation L2 to represent all subclasses Si, 1 i m.

• Add discriminator in L2 to distinguish the type of each tuple.

Relational Model 28

Optional / NonDisjointOptional / NonDisjoint

Page 29: Chapter 3

SECRETARY TECHNICIAN ENGINEER

EMPLOYEE(EmpNo, Fname, Lname, DOB, Salary)

SUB-EMP(EmpNo, TypingSpeed,TGrade, EngType,

Secretary Flag, Technician Flag, Engineer Flag)

EMPLOYEE

EmpNo

Fname

LName

DOB

Salary

o

TypingSpeed EngType

TGrade

Relational Model 29

Optional / NonDisjointOptional / NonDisjoint

Page 30: Chapter 3

• Suppose specialization with subclasses (S1, S2, .., Sm) & a superclass C.

• Create a relation L to represent C with PK & attributes.

• Create a relation Li to represent each subclass Si, 1 i m, and include the PK.

Relational Model 30

Optional / DisjointOptional / Disjoint

Page 31: Chapter 3

SECRETARY TECHNICIAN ENGINEER

EMPLOYEE(EmpNo, Fname, Lname, DOB, Salary)SECRETARY(EmpNo, TypingSpeed)TECHNICIAN(EmpNo, Tgrade)ENGINEER(EmoNo, EngType)

EMPLOYEE

EmpNo

Fname

LName

DOB

Salary

d

TypingSpeed EngType

TGrade

Relational Model 31

Optional / DisjointOptional / Disjoint

Page 32: Chapter 3

Relational ModelRelational ModelERER ER Model Relational Model

Entity Type1:1 or 1:M Relationship TypeM:N Relationship Typen-ary Relationship TypeSimple attributeComposite attributeMultivalued attributeValue setKey attribute

RelationFKRelation & 2 FKRelation & n FKAttributeSimple component attributeRelation and FKDomainPK

Page 33: Chapter 3

Question – Mapping EER

Page 34: Chapter 3

ViewsViews

User View: Describes that part of database that is relevant to a particular user or application area. (i.e. subset of the database)

Relation View: Essentially some subset of the relations, usually called “view”.

34Relational Model

Page 35: Chapter 3

Views Views

Base relation is a named relation corresponding to an entity in the conceptual schema, whose tuples are physically stored in the DB.

View is a derived relation. Virtual, may not exist, but dynamically derived from one or more base relations.

- The only information about a view that is stored in the database is its structure.

The external model can consist of both conceptual level relations (base relations) and derived views.

Relational Model 35

Page 36: Chapter 3

Views Views

4170010

4182000

4182034

4188134

StudentNo

Al-Saleh

Al-Ghanem

Al-Fahad

Saod

LName

Amal

Nora

Laila

Amal

FName Initial

M.

A.

A.

F.

DOB

04-06-78

02-12-79

01-11-74

22-04-73

GPA

3.91

4.20

4.01

3.01

STUDENTDept

D001

D001

D002

D003

4170010

4182000

4182034

4188134

StudentNo GPA

3.91

4.20

4.01

3.01

STUDENT_GPA

View

BaseRelation

Relational Model 36

Page 37: Chapter 3

Purpose of ViewsPurpose of Views

• Provides security mechanism by hiding parts of the DB from certain users.

• Customize data to user’s needs, so that the same data can be seen by different users in different ways.

• Simplify complex operations. It allow you to work with data from different tables simultaneously.

• Supports logical data independence.

Relational Model 37

Page 38: Chapter 3

Relational IntegrityRelational Integrity

Data integrity refers to the validity, consistency, and accuracy of the data in the database.

Integrity rules are constraints that apply to all instances of the DB.

Two integrity rules for the relational model:

- Entity integrity- Referential integrity

Relational Model 38

Page 39: Chapter 3

Relational IntegrityRelational Integrity

Entity Integrity: Ensures that there are no duplicate records within the table. In a base relation, no attribute of a PK can be null.

Referential Integrity: If a FK exists in a relation, either the FK value must match a CK value of some tuple in its home relation or the FK value must be wholly null.

Enterprise constraints: rules specified by the users or DBA of the DB based on the ways an organization perceives and uses its data. (e.g.number of staff working in a branch is at most 20)

Relational Model 39

Page 40: Chapter 3

Summary of Relational ModelSummary of Relational Model

• Relational database.

• Relation, attribute, tuple, degree, cardinality.

• Primary Key, Foreign Key.

• Relation schema, Relational database schema.

• Relational Integrity, Entity Integrity, Referential Integrity, Enterprise Constraints.

• Views.

Relational Model 40