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

2. 2 Objectives Relational Models Concepts Relational Model Notation Relational Constraints and Relational Database Schemas Update Operations and Dealing with Constraints Violations

3. 3 Relational 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

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

5. First Normal Form https://blog.udemy.com/normalization-in-database-with-example/

6. 2nd Normal Form https://blog.udemy.com/normalization-in-database-with-example/

7. 3rd Normal Form https://blog.udemy.com/normalization-in-database-with-example/

8. 3rd Normal Form https://blog.udemy.com/normalization-in-database-with-example/

9. 3rd Normal Form https://blog.udemy.com/normalization-in-database-with-example/

10. 4th Normal Form https://blog.udemy.com/normalization-in-database-with-example/

11. 4th Normal Form https://blog.udemy.com/normalization-in-database-with-example/

12. 4th Normal Form https://blog.udemy.com/normalization-in-database-with-example/

13. 4th Normal Form https://blog.udemy.com/normalization-in-database-with-example/

14. 14 Domains: Logical definitions  A domain D refers to a set of atomic values  To specify Domain: Data-type Format Name  Data type is used to specify the types of values in each column (attribute) Some examples of domains: SSN: the set of valid 9-digits USA_Phone_Number: the set of ten-digit phone number; (ddd)ddd-dddd Where d  DIGITS={0,1,2,…,9}

15. 15 Relation Schema:1  A relation schema R represented by R (A 1,A 2,…,A n )  Each Ai belongs to some domain Di  Dom(A 1 ) denotes domain of A 1  ( i.e., all possible values related to attribute A 1)  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. 16 Relation State –Relation state r of Schema R Denoted by r(R) a set of n-tuples r ={t 1,t 2,…,t n } Each n-tuple t is ordered list of values –t= »where v i  { {dom(A i )}  NULL} –t[A i ]= r.A i =t[i] used to refer to ith value in tuple t – relation intention (i.e., R ) vs. relation extension (i.e., r(R) )

17. 17 Relation: Formal definition –Formal definition of r(R) r(R)  (dom(A 1 )  dom(A 2 ) ...  dom(A n )) –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(A 1 )|  |dom(A 2 )| ...  |dom(A n )| 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. 18 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, A  B  B  A

19. 19 Example 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. 20 Characteristics of Relations Ordering of Tuples in a Relations –Not Important Ordering of Values within a Tuple –Important (for simplicity) if r(R)  (dom(A 1 )  dom(A 2 ) ...  dom(A n )) –Unimportant if we treat r(R)  (dom(A 1 ) dom(A 2 )... dom(A n )) (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. 21 Relational databases and Relational Database Schemas  Relational database schema:  a set of relation schemas S={ R 1,R 2,…R m }  a set of Integrity Constraints (IC)={i 1, i n }  Relational database state DB of S:  a set of relation states DB={r 1,r 2,…,r m }  Cardinality Number of tuples in a relation  DB state  Valid state vs. Invalid state

22. 22 COMPANY Database Schema

23. 23

24. 24 Categories of DB Constraints Constraints can be divided –Model-based constraints –Schema-based constraints –Application-based constraints

25. 25 Model-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. 26 Schema-based Constraints (or 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. 27 Domain Constraints A value of each attribute A i must be an atomic value from dom(A i ) –No object or complex data type is allowed Nested tables are not OK –E.g., of atomic data type Integer real char Boolean …

28. 28 Key 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. 29Keys 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. 30 CAR table with two candidate keys – LicenseNumber chosen as Primary Key

31. 31 Schema-based Constraints: NOT NULL Constraint NOT NULL Constraint This condition satisfies when an attribute, A i, has some value E.g. if student tuple must have a valid, then Name of STUDENT is required to be NOT NULL

32. 32 Schema-based Constraints: Entity 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. 33 Schema-based Constraints: 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. 34 Referential 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. 35 Referential Integrity MINT EMPLOEE FNAMELNAMESSNBDATEADDRESSSEX SUPERSSN DNO DEPT DEPT_LOC SNAMEDNUMMGRSSNMSDATE DNUMDLOC

36. 36 Complete Referential Integrity Constraints for COMPANY database

37. 37 Semantics 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. 38 Other 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. 39 Update operations and constraints violations 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. 40 The 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. 41 University ExampleWorksIn EmployeeDepartment SinceStatus WorksIn CREATE TABLE WorksIn ( name CHAR(20), -- attribute Employee SSN INTEGER (10), -- role (key of Employee) DOB DATE, -- attribute Address CHAR(30), -- attribute Department DeptId CHAR (4), -- role (key of Department) PRIMARY KEY (SSN), -- since an Employee works in at most one Department FOREIGN KEY (SSN) REFERENCES Employee (Id), Department FOREIGN KEY (DeptId) REFERENCES Department )

42. 42 Example 1: Insert 1.Insert into employee NOT OK : This operation violates the Key constraint, rejected !!!

43. 43 Example 2: Insert Examples (see figure on slide 34): 1.Insert into Employee NOT OK: this operation violates the Entity integrity constraint (Null for PK), rejected!!!

44. 44

45. 45 Example 3: Insert 1.Insert into employee NOT OK: Violates RI because DNO=7 does not exist; rejected!!!

46. 46

47. 47 Example 4: Insert 1.Insert into employee OK: Satisfies all constraints; Accepted!!!

48. 48 The delete Operations Delete –may violate Referential Integrity, if the tuple being deleted is referenced by FKs from other tuples

49. 49 Example1: Delete –Delete the Works_On tuple with ESSN=‘999887777’ and PNO = 10 OK

50. 50

51. 51 Complete Referential Integrity Constraints for COMPANY database

52. 52 Example 2: Delete –Delete the employee tuple with SSN=‘999887777’ NOT OK because tuples in Works_On refer to this tuple (RI violation)

53. 53 Complete Referential Integrity Constraints for COMPANY database

54. 54

55. 55 Example 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. 57 Options 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. 58 The 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. 59 Projects

60. 60 About Project: First Delivery. March 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. 61 Delivery 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. 62 Analysis and conflict resolutions 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. 63 Requirements 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