1 Lecture 04 The relational data Model, Relational Constraints 1.

1

Lecture 04Lecture 04

The relational data Model, Relational The relational data Model, Relational Constraints Constraints

1

2

ObjectivesObjectives

• Relational Models Concepts

• Relational Model Notation

• Relational Constraints and Relational Database Schemas

• Update Operations and Dealing with Constraints Violations

3

Relational Models ConceptsRelational Models Concepts

• Relational data models– Introduced by Ted Codd at IBM in 1970– Provides underlying mathematical foundations– Simplicity

• Relation?– a table of values

• where– Tuple = row– Attribute = Column

Data

https://blog.udemy.com/normalization-in-database-with-example/

First Normal Form


2nd Normal Form


3rd Normal Form


4th Normal Form


14

Domains: Logical definitionsDomains: Logical definitions

A domain D refers to a set of atomic values To specify Domain:

Data-typeFormatName

Data type is used to specify the types of values in each column (attribute)

Some examples of domains: SSN: the set of valid 9-digitsUSA_Phone_Number: the set of ten-digit phone number;

(ddd)ddd-ddddWhere d DIGITS={0,1,2,…,9}

15

Relation Schema:1Relation Schema:1

A relation schema R represented by R (A1,A2,…,An) Each Ai belongs to some domain Di Dom(A1) denotes domain of A1 (i.e., all possible values related to attribute A1)

Degree of relation? Number of attributes n of its relation schema R R E.g., Student (Name, SSN, Home_phone, address, Age, GPA)

The degree of student = 6 Dom(Name)=Names Dom(SSN) =Social_security_Number Dom(Home_phone) = Local_Phone_Number Dom (Age)= [15-80] Dom(GPA)= Grade_Point_Avg …

16

Relation StateRelation State

– Relation state r of Schema R • Denoted by r(R)

• a set of n-tuples r ={t1,t2,…,tn}

• Each n-tuple t is ordered list of values– t=<v1,v2,…,vn>

» where vi { {dom(Ai)} NULL}

– t[Ai]= r.Ai =t[i] used to refer to ith value in tuple t

– relation intention (i.e., R ) vs. relation extension (i.e., r(R) )

17

Relation: Formal definitionRelation: Formal definition– Formal definition of r(R)

• r(R)(dom(A1)dom(A2)...dom(An))– i.e. r is a subset of all possible n-tuple

– X represents Cartesian product to specify all possible combination of values from the underlying domains

• Total number of all possible instance of tuples can be represented as products of cardinalities of all domain

– |dom(A1)||dom(A2)|...|dom(An)|

• Several attributes may have the same domains• Attribute names signify dirrent roles or interpretation

– E.g. USA_phone_numbers can play the role of Hm_Phone and Office_phone

18

Generic example about tuples Generic example about tuples

– E.g., • Suppose

– A = {1,2} with cardinality |A|=2 – B ={3,4}, |B|=2

• A × B = {1,2} × {3,4} = {(1,3), (1,4), (2,3), (2,4)} • B × A = {3,4} × {1,2} = {(3,1), (3,2), (4,1), (4,2)} • A = B = {1,2} then A × B = B × A = {1,2} × {1,2} =

{(1,1), (1,2), (2,1), (2,2)}

– In general,• ABB A

19

Example of RelationsExample of Relations

• FlightID = {BA101, BA220, BA430,…}• Place = {London, Paris, Bombay, Rome,…}• Time = {00:00, 00:01, …,24:00}• Vacancy ={1,…,400}• Flight_Itineray (Flightid Place Place Time

Time Vacancy)• Flight_Itinary = { (BA101, London, Paris, 13:05, 4:05,

20), (BA201, London, Paris, 13:55, 7:05, 30),…}

20

Characteristics of RelationsCharacteristics of Relations

• Ordering of Tuples in a Relations– Not Important

• Ordering of Values within a Tuple

– Important (for simplicity) if r(R) (dom(A1)dom(A2)...dom(An))

– Unimportant if we treat r(R) (dom(A1)ᴜ dom(A2) ᴜ... ᴜdom(An)) (i.e., a set of attributes) Tuple values

– Atomic – Null

• Interpretation of a relations and tuples– Tuples interpreted as facts– Relation schema interpreted as type declaration

21

Relational databases and Relational Relational databases and Relational Database SchemasDatabase Schemas

Relational database schema: a set of relation schemas S={ R1,R2,…Rm}

a set of Integrity Constraints (IC)={i1, in}

Relational database state DB of S: a set of relation states DB={r1,r2,…,rm}

CardinalityNumber of tuples in a relation

DB state Valid state vs. Invalid state

22

COMPANY Database Schema

23

23

24

Categories of DBCategories of DBConstraintsConstraints

• Constraints can be divided– Model-based constraints – Schema-based constraints– Application-based constraints

25

Model-based constraintsModel-based constraints

• Refers to the constraints associated with model itself– Examples

• Ordering of tuples in the relations (i.e., sets)

• No duplicated tuples allowed

• Ordering of values within a tuple

26

Schema-based Constraints (or Schema-based Constraints (or explicit)explicit)

• Constraints that can be specified on the schema using DDL/SQL– Domain Constraints– Key Constraints – Constraints on Null – Entity Integrity Constraints– Referential Integrity Constraints

27

Domain ConstraintsDomain Constraints A value of each attribute Ai must be an atomic value

from dom(Ai)

– No object or complex data type is allowed• Nested tables are not OK

– E.g., of atomic data type• Integer• real • char • Boolean• …

28

Key Constraints: Super KeyKey Constraints: Super Key• By definition, a relation is a defined as a set of tuples

– All tuples of a set must be distinct

• Super key?

– A subset of attributes of R having a uniqueness property– Attributes can be redundant

• E.g., {SSN, Name, Address}– One such a set of attributes are called super key (SK) – To be super key (SK) the following condition MUST hold:

• For any two distinct tuples t1 and t2 r(R) , t1[SK]t2[SK] is true• SK specifies uniqueness property that no two distinct tuples in any state r(R)

can have the same value of SK

29

KeysKeys• Key?

– A SK without redundancy

• SK + minimality constraint

– e.g. {SSN}

• A key can be SK but SK cannot be a Key

– Determined from the meaning of the attributes

– The property of key is time-invariant

• Candidate Key?

– A relation schema having more than one key

– E.g., SSN, student ID, Engine Serial number?

• Primary Key?– A designated candidate key– E.g., SSN

30

CAR table with two candidate keys CAR table with two candidate keys – LicenseNumber chosen as Primary – LicenseNumber chosen as Primary

KeyKey

31

Schema-based Constraints: NOT Schema-based Constraints: NOT NULL ConstraintNULL Constraint

NOT NULL Constraint• This condition satisfies when an attribute, Ai,

has some value• E.g.

• if student tuple must have a valid, then Name of STUDENT is required to be NOT NULL

32

Schema-based Constraints: Entity Schema-based Constraints: Entity Integrity (EI)Integrity (EI)

• Entity Integrity (EI)– Primary Key (PK) can not be NULL

• Because PK is used to identify a tuple in a relation

– Entity Integrity + Key Constraints are specified on individual relation

33

Schema-based Constraints: Schema-based Constraints: Referential Integrity (RI) Referential Integrity (RI)

– Referential Integrity (RI)• specified between two relations • used to maintain the consistency among tuples of

the two relations• Comes from relationships among the entities

represented by the relation schema

34

Referential Integrity (RI): 2Referential Integrity (RI): 2• Works with notion of Foreign key• Foreign key (FK)?

– Primary key of one table used as an attribute in another table

• E.g. DNO is PK in Department used as FK in Employee

– If base table T1 includes a FK matching the PK of some base table T2, then every value of FK in T1 must either

• be equal (or match) the corresponding value of PK in some record of T2

• be wholly null

• DDL provides facilities to specify these constraints

35

Referential IntegrityReferential Integrity

MINT

EMPLOEE

FNAME LNAME SSN BDATEADDRESS SEX SUPERSSN DNO

DEPT

DEPT_LOC

SNAME DNUM MGRSSNMSDATE

DNUM DLOC

36

Complete Referential Integrity Constraints for COMPANY database

37

Semantics integrity constraintsSemantics integrity constraints

• A general constraints– Difficult to specify– Enforced on DB using application program – or using assertions/triggers of Constraint

Specification language (SQL CREATE ASSERTION/TRIGGER)

– Examples of constraints• The salary of an employee should not exceed the salary

of the employee’s supervisor (AKA action based constraints)

38

Other Types of ConstraintsOther Types of Constraints

• Other type of constraints include– Functional dependency (FD) constraints

• Establishes a functional relationship among two sets of attributes X and Y in R

• Used by normalization process to improve the quality of relational design (individual tables)

39

Update operations and constraints Update operations and constraints violationsviolations

• The main operation of DB can be divided

– Updates

– Retrievals

• Relational Algebra and Calculus are used to retrieve the data

• What happened to database when update operations are performed?

• Update operations– Insert

– Delete

– Update (modify)

• Update Operations and Integrity Constraints

40

The Insert operationThe Insert operation

• Insert allows new tuple t to be inserted into database• Insert may violate

– Referential Integrity (if FK of t refers to none-existing t in referenced relation)

– Entity Integrity (if PK of t is NULL)

– Key constraint (if a key of t is already exist)

– Domain constraint (undefined type)

41

University Example

WorksInWorksInEmployeeEmployee DepartmentDepartment

Since Status

CREATE TABLE WorksInWorksIn ( name CHAR(20), -- attribute SSN INTEGER (10), -- role (key of EmployeeEmployee) DOB DATE, -- attribute Address CHAR(30), -- attribute DeptId CHAR (4), -- role (key of DepartmentDepartment) PRIMARY KEY (SSN), -- since an Employee works in at most one Department FOREIGN KEY (SSN) REFERENCES Employee (Id), FOREIGN KEY (DeptId) REFERENCES DepartmentDepartment )

42

Example 1: InsertExample 1: Insert

1. Insert <‘John, J, Smith’,‘NULL’, 1960-04-05, 6357 Main Street, Charlotte, NC, M, 28221, 4> into employee

NOT OK : This operation violates the Key constraint, rejected !!!

43


• Examples (see figure on slide 34):1. Insert <‘Gordon’, H, ‘Chris’, Null,1978-05-04,

6357 Main Street, Fargo, ND, M, 38000, Null, 4> into Employee

NOT OK: this operation violates the Entity integrity constraint (Null for PK), rejected!!!

44

44

45


1. Insert <‘Gordon’ , D, ‘Chris’, 666777888, 960-04-05, 6357 Main Street, Fargo, ND, M, 38000, 98765432, 7> into employee

NOT OK: Violates RI because DNO=7 does not exist; rejected!!!

46

46

47


1. Insert <Cecilla, F, Kolonsky’,677678989, 1960-04-05, 6357 Windy lane, Katy, Tx, F, 28000, null. 4> into employee

OK: Satisfies all constraints;

Accepted!!!

48

The delete OperationsThe delete Operations

• Delete – may violate Referential Integrity, if the tuple

being deleted is referenced by FKs from other tuples

49

Example1: DeleteExample1: Delete

– Delete the Works_On tuple with ESSN=‘999887777’ and PNO = 10

• OK

50

50

51


52

Example 2: DeleteExample 2: Delete

– Delete the employee tuple with SSN=‘999887777’• NOT OK because tuples in Works_On refer to this

tuple (RI violation)

53


54

54

55

Example 3: DeleteExample 3: Delete

– Delete Employee with SSN=‘333445555’• NOT OK because a tuple is referred by

– EMPLOYEE,

– DEPARTMENT

– WORK_ON

– DEPENTED

• RI violation!

56

56

57

Options for deleteOptions for delete• Reject deletion (aka restrict)

– Simply reject the operation

• Attempt to cascade the deletion– Attempt to delete the referencing tuples

• Modify the referencing attribute values– Uses set null or set default to modify the

referencing attribute values that cause the violation

58

The Update (modify) operationsThe Update (modify) operations• Used to change the values of one or more attributes in a tuple• E.g.

– Update the SALARY of the EMPLOYEE tuple with SSN =999887777 to 28000

• O.K– Update the DNO of the EMPLOYEE tuple with SSN =999887777 to 1

• OK– Update the DNO of the EMPLOYEE tuple with SSN =999887777 to 27

• Not OK, because RI violation– Update the SSN of the EMPLOYEE with SSN=9999887777 to 987654321

• Not OK, because it violate PK and RI

• In general,– an attribute that is not PK nor FK can be modified without

any problem

59

Projects

60

About Project: First Delivery About Project: First Delivery ..

March 10, 2015March 10, 2015

• Analysis and Specification– Introduction

• What the proposed system is all about?

• What is to be accomplished?

• How the system or product fits into the needs of the business?

• How the users interact with system?

61

Delivery PresentationsDelivery Presentations

• The delivery should include– A statement of need and feasibility

– A description of the systems' technical environment

– A list of requirements or services and domain constraints that apply to each

– a set of usage scenarios that provide some insights into the use of the system

– Any prototype developed to better define requirements

62

Analysis and conflict Analysis and conflict resolutionsresolutions

• Ask the following questions– Is each requirement consistent with overall objective for

the system?• Do any requirement conflict with other requirements?

– Have all requirements been specified?– Is the requirement really needed or does it represent an

add-on feature that may not be essential to the objective of the system?

– Is each requirement clear?– Is each requirement testable, once implemented?

63

Requirements SpecificationRequirements Specification

• Requirements Specifications– Created at the end of analysis task

• Specification can be– A written document

– A graphical model

– A formal mathematical model

– A collection of usage scenarios

– a prototype

– any combination of the above

1 Lecture 04 The relational data Model, Relational Constraints 1.

Documents

Transcript of 1 Lecture 04 The relational data Model, Relational Constraints 1.