1. Chapter 3: The relational data Model, Relational Constraints Csci455 reza@aero.und.edu Hassan Reza, PhD. Copyright ©2014 1

2. Scholarship Announcement North Dakota Dollars for Scholars is pleased to offer new scholarships to benefit your students. The Information Technology Council of North Dakota has partnered with Bank of North Dakota to offer $1,000 scholarships to students majoring in Computer and Information Technology Sciences (including programing, data processing, web design, system analysis, networking, computer engineering, simulator maintenance, etc.). The application deadline is April 1. Students can apply online at northdakota.dollarsforscholars.org. To be eligible, college students must have graduated from a North Dakota high school with an active Dollars for Scholars chapter. Please contact Laura at 701.328.5702 or lentzel@nd.gov.lentzel@nd.gov 2

3. Objectives 3 Relational Models Concepts Relational Model Notations Relational Constraints Relational Database Schemas Update Operations and Dealing with Constraints Violations

4. Relational Models Concepts 4 Relational data models –Introduced by E.F. Codd at IBM in 1970 –Provides underlying mathematical foundations –Simplicity –Commercial Systems using RDBMS include DB2, Orcale, MySQL, etc

5. relation Relation? –A table consists of collection of tuples (row) –Each tuple represents a relationship among values attributes (columns) –A relationship among n-values is mathematically represented by an n-tuple (row in table) 5

6. Domains: Logical definitions 6 o A domain, say, D refers to a set of permissible atomic values o Some examples of domains: o SSN: the set of 9-digits o USA_Phone_Number: the set of 10-digit phone number; (ddd)ddd-dddd o Where o d  DIGITS={0,1,2,…,9}

7. Relation Schema:1 7 o A relation schema R represented by R (A 1,A 2,…,A n ) o Each A i belongs to some domain D i o Dom(A 1 )= domain of A 1 o ( i.e., all possible values related to attribute A 1 ) o Degree of relation? o Number of attributes n of its relation schema R o E.g., Student (Name, SSN, Home_phone, address, Age, GPA) o The degree of student = 6 o Dom(Name)=Names o Dom(SSN) =Social_security_Number o Dom(Home_phone) = Local_Phone_Number o Dom (Age)= [15-80] o Dom(GPA)= Grade_Point_Avg …

8. Relation State 8 –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 i 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 i th value in tuple t – Relation intention (R ) vs. relation extension r(R)

9. Figure 3.1 9

10. Relation: Formal definition 10 –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 is Cartesian product operation – Used 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 their roles or interpretation –E.g. »USA_phone_numbers can play the role of HM_Phone and Office_phone

11. Generic example about tuples –E.g., Suppose –A = {1,2} with cardinality |A|=2 –B ={3,4}, with cardinality |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 11

12. Example of Relations 12 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),…}

13. Characteristics of Relations 13 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

14. Figure 3.1 14

15. Fig.3.2 15

16. Relational databases and Relational Database Schemas 16 o Relational database schema: o a set of relation schemas S={ R 1,R 2,…R m } o a set of Integrity Constraints (IC)={i 1, i n } o Relational database state DB of S: o A set of relation states DB={r 1,r 2,…,r m } o Cardinality o Number of tuples in a relation o DB state o Valid state vs. Invalid state

17. 17 COMPANY Database Schema

18. 18

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

20. Model-based constraints 20 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

21. Schema-based Constraints (or explicit) 21 Constraints that can be specified on the schema using DDL/SQL –Domain Constraints –Key Constraints –Constraints on Null –Entity Integrity Constraints –Referential Integrity Constraints

22. Domain Constraints 22 –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.: atomic data type Integer real char Boolean …

23. Key Constraints: Super Key 23 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

24. Keys 24 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

25. CAR table with two candidate keys – LicenseNumber chosen as Primary Key 25

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

27. Schema-based Constraints: Entity Integrity (EI) 27 Entity Integrity (EI) –Primary Key (PK) cannot be NULL Because PK is used to identify a tuple in a relation –Entity Integrity + Key Constraints are specified on individual relation

28. Schema-based Constraints: Referential Integrity (RI) 28 –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

29. Referential Integrity (RI): 2 29 Works with notion of Foreign key(FK) 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

30. Referential Integrity 30 MINT EMPLOEE FNAMELNAMESSNBDATEADDRESSSEX SUPERSSN DNO DEPT DEPT_LOC SNAMEDNUMMGRSSNMSDATE DNUMDLOC

31. 31 Complete Referential Integrity Constraints for COMPANY database

32. Semantics integrity constraints 32 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)

33. Other Types of Constraints 33 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)

34. Update operations and constraints violations 34 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

35. The Insert operation 35 Insert allows new tuple t to be inserted into database Insert may violate –Referential Integrity (if FK of t refers to none-existing tuple 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)

36. Examples: Insert 36 Examples (see fig.3.6): 1.Insert into Employee NOT OK because this operation violates the Entity integrity constraint (Null for PK). Operation is rejected!!!

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

38. 38

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

40. 40

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

42. The delete Operations 42 Delete –May violate Referential Integrity In case, the tuple being deleted is referenced by FKs from other tuples

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

44. 44

45. 45 Complete Referential Integrity Constraints for COMPANY database

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

47. 47 Complete Referential Integrity Constraints for COMPANY database

48. 48

49. Example 3: Delete 49 –Delete Employee with SSN=‘333445555’ NOT OK because a tuple is referred by – EMPLOYEE, –DEPARTMENT –WORK_ON –DEPENTED Referential Integrity violation!

50. 50

51. Options for delete 51 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

52. The Update (modify) operations 52 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, –Any attribute that is not PK nor FK can be modified without any problem

53. About Project: First Delivery 53 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?

54. Delivery 54 The delivery should include –A statement of need and feasibility –A description of the systems' technical environment –A list of requirements (i.e., services) and constraints that apply to each – A set of usage scenarios (use cases) that provide some insights into the use of the system –Any prototype developed to better define requirements

55. Analysis and conflict resolutions 55 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 it is 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?

56. Requirements Specification 56 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

57. In class Quiz 57 What is the difference between a key and a super key?