Chapter 3: The relational data Model, Relational Constraints Csci455 Hassan Reza, PhD. Copyright ©2014 1.

Slides:



Advertisements
Similar presentations
Relational Database. Relational database: a set of relations Relation: made up of 2 parts: − Schema : specifies the name of relations, plus name and type.
Advertisements

The Relational Model. Introduction Introduced by Ted Codd at IBM Research in 1970 The relational model represents data in the form of table. Main concept.
SQL Lecture 10 Inst: Haya Sammaneh. Example Instance of Students Relation  Cardinality = 3, degree = 5, all rows distinct.
Copyright © 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 3 The Basic (Flat) Relational Model.
Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Slide 5- 1.
1 Relational Model. 2 Relational Database: Definitions  Relational database: a set of relations  Relation: made up of 2 parts: – Instance : a table,
The Relational Model Lecture 3 Book Chapter 3 Relational Data Model Relational Query Language (DDL + DML) Integrity Constraints (IC) From ER to Relational.
Chapter 5 The Relational Data Model and Relational Database Constraints Copyright © 2004 Pearson Education, Inc.
Database Systems Chapter 5 ITM 354. Chapter Outline Relational Model Concepts Relational Model Constraints and Relational Database Schemas Update Operations.
Chapter 5 The Relational Data Model and Relational Database Constraints.
Database Systems Relational Model Concepts Toqir Ahmad Rana Database Management Systems 1 Lecture 17.
CONSTRAINTS AND UPDATES CHAPTER 3 (6/E) CHAPTER 5 (5/E) 1.
Database Architecture The Relational Database Model.
Chapter 5 Relational Model Concepts Dr. Bernard Chen Ph.D. University of Central Arkansas.
Exam 2 Review Dr. Bernard Chen Ph.D. University of Central Arkansas.
CS 380 Introduction to Database Systems (Chapter 5: The Relational Data Model and Relational Database Constraints)
1 Lecture 04 The relational data Model, Relational Constraints 1.
Relational Model Session 6 Course Name: Database System Year : 2012.
1 The Relational Data Model, Relational Constraints, and The Relational Algebra.
Content Resource- Elamsari and Navathe, Fundamentals of Database Management systems.
Relational Data Model. A Brief History of Data Models  1950s file systems, punched cards  1960s hierarchical  IMS  1970s network  CODASYL, IDMS 
Copyright © 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 3 The Relational Data Model and Relational Database Constraints.
Database Management COP4540, SCS, FIU Relational Model Chapter 7.
CG084&085 / / 1 The Relational Data Model Properties of Relations Keys and Constraints.
Topic 5 The Relational Data Model and Relational Database Constraints Faculty of Information Science and Technology Mahanakorn University of Technology.
Instructor: Churee Techawut Basic Concepts of Relational Database Chapter 5 CS (204)321 Database System I.
DatabaseIM ISU1 Fundamentals of Database Systems Chapter 5 The Relational Data Model.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 5- 1.
10/9/20151 The Relational Data Model TCU Database Systems Last update: September 2004 Reference: Elmasri 4 th edition, chapter 5.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 5- 1 Week4 Relational Model and Relational Database Constraints Relational Model Concepts.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Chapter 5 The Relational Data Model and Relational Database Constraints.
1 CSE 480: Database Systems Lecture 5: Relational Data Model.
METU Department of Computer Eng Ceng 302 Introduction to DBMS The Relational Data Model and Relational Database Constraints by Pinar Senkul resources:
Chapter 6 The Relational Data Model and the Relational Algebra.
FALL 2004CENG 351 File Structures and Data Management1 Relational Model Chapter 3.
Relational Data Model Ch. 7.1 – 7.3 John Ortiz Lecture 3Relational Data Model2 Why Study Relational Model?  Most widely used model.  Vendors: IBM,
Slide Chapter 5 The Relational Data Model and Relational Database Constraints.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Chapter 3 The Basic Relational Model.
Riyadh Philanthropic Society For Science Prince Sultan College For Woman Dept. of Computer & Information Sciences CS 340 Introduction to Database Systems.
1 CS 430 Database Theory Winter 2005 Lecture 4: Relational Model.
CSE314 Database Systems Lecture 3 The Relational Data Model and Relational Database Constraints Doç. Dr. Mehmet Göktürk src: Elmasri & Navanthe 6E Pearson.
Relational Model E.F. Codd at IBM 1970 Chapter 3 (ed. 7 – Chap. 5)
The relational model A data model (in general) : Integrated collection of concepts for describing data (data requirements). Relational model was introduced.
CS34311 The Relational Model. cs34312 Why Relational Model? Currently the most widely used Vendors: Oracle, Microsoft, IBM Older models still used IBM’s.
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe CHAPTER 5 The Relational Data Model and Relational Database Constraints Slide 1- 1.
Lecture 03 Constraints. Example Schema CONSTRAINTS.
Chapter 3 The Relational Model. Objectives u Terminology of relational model. u How tables are used to represent data. u Connection between mathematical.
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe.
LECTURE TWO Introduction to Databases: Data models Relational database concepts Introduction to DDL & DML.
1 The Relational Data Model David J. Stucki. Relational Model Concepts 2 Fundamental concept: the relation  The Relational Model represents an entire.
1 CS122A: Introduction to Data Management Lecture #4 (E-R  Relational Translation) Instructor: Chen Li.
The Relational Data Model and Relational Database Constraints.
CENG 351 File Structures and Data Management1 Relational Model Chapter 3.
4/28/2017 Chapter 5 The Relational Data Model and Relational Database Constraints.
Chapter 3 The Relational Data Model and Relational Database Constraints Copyright © 2004 Pearson Education, Inc.
Copyright © 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 3 The Relational Data Model and Relational Database Constraints تنبيه.
Copyright © 2004 Pearson Education, Inc.
4/20/2018.
376a. Database Design Dept. of Computer Science Vassar College
The Relational Data Model
The Relational Data Model and Relational Database Constraints
The Relational Data Model and Relational Database Constraints
CS4222 Principles of Database System
12/7/2018.
Database Systems The Basic (Flat) Relational Model
The Relational Data Model and Relational Database Constraints
4/8/2019.
INSTRUCTOR: MRS T.G. ZHOU
5/12/2019.
Copyright © 2004 Pearson Education, Inc.
Presentation transcript:

Chapter 3: The relational data Model, Relational Constraints Csci455 Hassan Reza, PhD. Copyright ©2014 1

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 or 2

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

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

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

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}

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 …

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)

Figure 3.1 9

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

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

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),…}

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

Figure

Fig

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 COMPANY Database Schema

18

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

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

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

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 …

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

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

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

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

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

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

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

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

31 Complete Referential Integrity Constraints for COMPANY database

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)

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)

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

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)

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!!!

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

38

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

40

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

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

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

44

45 Complete Referential Integrity Constraints for COMPANY database

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

47 Complete Referential Integrity Constraints for COMPANY database

48

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

50

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

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 = to O.K –Update the DNO of the EMPLOYEE tuple with SSN = to 1 OK –Update the DNO of the EMPLOYEE tuple with SSN = to 27 Not OK, because RI violation –Update the SSN of the EMPLOYEE with SSN= to Not OK, because it violate PK and RI In general, –Any attribute that is not PK nor FK can be modified without any problem

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?

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

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?

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

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