1 lecture 04 the relational data model, relational constraints 1
TRANSCRIPT
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
https://blog.udemy.com/normalization-in-database-with-example/
2nd Normal Form
https://blog.udemy.com/normalization-in-database-with-example/
3rd Normal Form
https://blog.udemy.com/normalization-in-database-with-example/
3rd Normal Form
https://blog.udemy.com/normalization-in-database-with-example/
3rd Normal Form
https://blog.udemy.com/normalization-in-database-with-example/
4th Normal Form
https://blog.udemy.com/normalization-in-database-with-example/
4th Normal Form
https://blog.udemy.com/normalization-in-database-with-example/
4th Normal Form
https://blog.udemy.com/normalization-in-database-with-example/
4th Normal Form
https://blog.udemy.com/normalization-in-database-with-example/
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
Example 2: InsertExample 2: Insert
• 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
Example 3: InsertExample 3: Insert
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
Example 4: InsertExample 4: Insert
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
Complete Referential Integrity Constraints for COMPANY database
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
Complete Referential Integrity Constraints for COMPANY database
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