1 Constraints and Updating Hugh Darwen CS252.HACD: Fundamentals of Relational Databases Section 7: Constraints.

Slides:



Advertisements
Similar presentations
Relational Algebra Part II
Advertisements

Copyright © Cengage Learning. All rights reserved.
Copyright: ©2005 by Elsevier Inc. All rights reserved. 1 Author: Graeme C. Simsion and Graham C. Witt Chapter 3 The Entity-Relationship Approach.
Jeopardy Q 1 Q 6 Q 11 Q 16 Q 21 Q 2 Q 7 Q 12 Q 17 Q 22 Q 3 Q 8 Q 13
0 - 0.
DIVIDING INTEGERS 1. IF THE SIGNS ARE THE SAME THE ANSWER IS POSITIVE 2. IF THE SIGNS ARE DIFFERENT THE ANSWER IS NEGATIVE.
ADDING INTEGERS 1. POS. + POS. = POS. 2. NEG. + NEG. = NEG. 3. POS. + NEG. OR NEG. + POS. SUBTRACT TAKE SIGN OF BIGGER ABSOLUTE VALUE.
SUBTRACTING INTEGERS 1. CHANGE THE SUBTRACTION SIGN TO ADDITION
MULT. INTEGERS 1. IF THE SIGNS ARE THE SAME THE ANSWER IS POSITIVE 2. IF THE SIGNS ARE DIFFERENT THE ANSWER IS NEGATIVE.
Addition Facts
Fourth normal form: 4NF 1. 2 Normal forms desirable forms for relations in DB design eliminate redundancies avoid update anomalies enforce integrity constraints.
Introduction to Relational Database Systems 1 Lecture 4.
5NF and other normal forms
Active database concepts
Relational data integrity
Normal forms - 1NF, 2NF and 3NF
Data Definition and Integrity Constraints
1 Relational Algebra Hugh Darwen (invited lecturer) CS319: Relational Algebra (revisited, reviewed, revised,
1 Introduction to Relational Databases Hugh Darwen CS252.HACD: Fundamentals of Relational Databases.
1 Database Design Issues, Part I Hugh Darwen CS252.HACD: Fundamentals of Relational Databases Section.
1 Relational Algebra, Part III, and Other Operators Hugh Darwen CS252.HACD: Fundamentals of Relational.
1 Relational Algebra, Principles and Part I Hugh Darwen CS252.HACD: Fundamentals of Relational Databases.
Dr. Alexandra I. Cristea CS 319: Theory of Databases: C3.
1 Values, Types, Variables, Operators Hugh Darwen CS252.HACD: Fundamentals of Relational Databases Section.
Dr. A.I. Cristea CS 319: Theory of Databases: FDs.
1 Predicates and Propositions Hugh Darwen CS252.HACD: Fundamentals of Relational Databases Section 3:
Dr. Alexandra I. Cristea CS 252: Fundamentals of Relational Databases: SQL5.
SQL: The Query Language Part 2
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide
ABC Technology Project
© Abdou Illia MIS Spring 2014
Functional Dependencies and Normalization for Relational Databases
Addition 1’s to 20.
25 seconds left…...
Test B, 100 Subtraction Facts
Week 1.
12 System of Linear Equations Case Study
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Chapter 6 The Relational Algebra.
Equivalence Relations
Relational Database. Relational database: a set of relations Relation: made up of 2 parts: − Schema : specifies the name of relations, plus name and type.
1 Database Design Issues, Part II Hugh Darwen CS252.HACD: Fundamentals of Relational Databases Section.
Database Management Systems, R. Ramakrishnan and J. Gehrke1 The Relational Model Chapter 3.
Cs3431 Constraints Sections 6.1 – 6.5. cs3431 Example CREATE TABLE Student ( sNum int, sName varchar (20), prof int, CONSTRAINT pk PRIMARY KEY (snum),
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.
Database Architecture The Relational Database Model.
Chapter 6 Relations. Copyright © 2004 Pearson Addison-Wesley. All rights reserved.6-2 Topics in this Chapter Tuples Relation Types Relation Values Relation.
Chapter 6 Relations. Topics in this Chapter Tuples Relation Types Relation Values Relation Variables SQL Facilities.
Databases Illuminated
Lecture 2 The Relational Model. Objectives Terminology of relational model. How tables are used to represent data. Connection between mathematical relations.
The Relational Model These slides are based on the slides of your text book.
Relational Data Model, R. Ramakrishnan and J. Gehrke with Dr. Eick’s additions 1 The Relational Model Chapter 3.
Chapter 9 Integrity. Copyright © 2004 Pearson Addison-Wesley. All rights reserved.9-2 Topics in this Chapter Predicates and Propositions Internal vs.
Chapter 3 The Relational Model. 2 Chapter 3 - Objectives u Terminology of relational model. u How tables are used to represent data. u Connection between.
R ELATIONAL D ATA M ODEL Joe Meehean 1. R ELATIONAL D ATA M ODEL Data stored as a set of relations really just tables Tables related to one another through.
1 The Relational Model. 2 Why Study the Relational Model? v Most widely used model. – Vendors: IBM, Informix, Microsoft, Oracle, Sybase, etc. v “Legacy.
FALL 2004CENG 351 File Structures and Data Management1 Relational Model Chapter 3.
Unit III. Views A table that is derived from other tables Considered as a virtual table Does not store data.
Logical Database Design (1 of 3) John Ortiz Lecture 6Logical Database Design (1)2 Introduction  The logical design is a process of refining DB schema.
Chapter 2 Introduction to Relational Model. Example of a Relation attributes (or columns) tuples (or rows) Introduction to Relational Model 2.
Chapter 2: Intro to Relational Model. 2.2 Example of a Relation attributes (or columns) tuples (or rows)
CS34311 The Relational Model. cs34312 Why Relational Model? Currently the most widely used Vendors: Oracle, Microsoft, IBM Older models still used IBM’s.
Lecture 03 Constraints. Example Schema CONSTRAINTS.
Chapter 3 The Relational Model. Why Study the Relational Model? Most widely used model. Vendors: IBM, Informix, Microsoft, Oracle, Sybase, etc. “Legacy.
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke1 The Relational Model Chapter 3.
1 CS122A: Introduction to Data Management Lecture #4 (E-R  Relational Translation) Instructor: Chen Li.
CENG 351 File Structures and Data Management1 Relational Model Chapter 3.
STRUCTURE OF PRESENTATION :
STRUCTURE OF PRESENTATION :
Introduction to Relational Databases
Presentation transcript:

1 Constraints and Updating Hugh Darwen CS252.HACD: Fundamentals of Relational Databases Section 7: Constraints and Updating

2 Constraints Constraints express the integrity rules for a database. Enforcement of constraints by the DBMS ensures that the database is at all times in a consistent state. A constraint is a truth-valued expression, such as a comparison, declared as part of the logical schema of the database. The comparands of a constraint are typically relation expressions or invocations of aggregate operators. But the commonest kinds of constraint are expressed using special shorthands, like KEY, FOREIGN KEY, IS_EMPTY.

3 KEY Constraints StudentIdCourseIdMark S1C185 S1C249 S2C149 S3C366 S4C193 EXAM_MARK ( ( EXAM_MARK GROUP { Mark } AS Marks WHERE COUNT ( Marks ) > 1 ) { } ) = RELATION { } { } The constraint shown below is a uniqueness constraint, meaning that no two distinct tuples can match on both StudentId and CourseId. { StudentId, CourseId } is a superkey of EXAM_MARK

4 When a Superkey Is a Key If no proper subset of superkey K is a superkey, then K is a key. So { StudentId, CourseId } is in fact a key of EXAM_MARK, and is in fact the only key of EXAM_MARK. In general a relvar can have several keys, in which case it is sometimes useful to nominate one of them as being the primary key. For that reason, keys are sometimes referred to as candidate keys. When a primary key is nominated, any other keys are called alternate keys.

5 The KEY Shorthand Traditionally, a KEY constraint is declared as part of the definition of the relvar to which it pertains, thus: VAR EXAM_MARK BASE RELATION { StudentId SID, CourseId CID, Mark INTEGER } KEY { StudentId, CourseId } ;

6 Multiple Keys abc Recall PLUS (a + b = c): Not a variable, of course, but we can still observe that {a, b}, {a, c} and {b, c} are all keys. We might even nominate {a, b} to be the primary key (for psychological reasons only).

7 Degenerate Cases of Keys The entire heading can be a key. In that case it is the only key (why?). The empty set can be a key. In that case it is the only key (why?). What special property is implied by such a key?

8 Foreign Key Constraints StudentIdName S1Anne S2Boris S3Cindy S4Devinder S5Boris StudentIdCourseId S1C1 S1C2 S2C1 S3C3 S4C1 IS_CALLEDIS_ENROLLED_ON KEY { StudentId }Every StudentId value here must also appear in IS_CALLED { StudentId }

9 Inclusion Dependency FOREIGN KEY { StudentId } REFERENCING IS_CALLED included in declaration of IS_ENROLLED_ON is shorthand for: IS_CALLED { StudentId } IS_ENROLLED_ON { StudentId } Such constraints in general are sometimes called inclusion dependencies. An inclusion dependency is a foreign key if the heading common to the two comparands is a key of the referenced relvar.

10 A Special Case of Inclusion Dependency Consider: TABLE_DUM r { } RELATION { } { } r { } In Tutorial D we can write this as IS_EMPTY ( r ). Also: r1 r2 IS_EMPTY ( r2 MINUS r1 ) r2 NOT MATCHING r1

11 IS_EMPTY Example StudentIdCourseIdMark S1C185 S1C249 S2C149 S3C366 S4C193 EXAM_MARK This might be subject to the constraint: 0 Mark 100 IS_EMPTY ( EXAM_MARK WHERE Mark 100 )

12 Generalisation of Inclusion Dependency IS_EMPTY ( r1 NOT MATCHING r2 ) E.g., to express that foreign key in IS_ENROLLED_ON: IS_EMPTY ( IS_ENROLLED_ON NOT MATCHING IS_CALLED ) But now the operands can be arbitrary relation expressions, without the restrictions of FOREIGN KEY.

13 Exclusion Dependency? IS_EMPTY ( r1 MATCHING r2 ) E.g., to enforce disjointness of part-time and full-time employees: IS_EMPTY ( PART_TIMER MATCHING FULL_TIMER) Equivalently: IS_EMPTY ( FULL_TIMER MATCHING PART_TIMER)

14 Constraint Declaration In Tutorial D (in addition to KEY specifications written inside relvar declarations): CONSTRAINT name expression ; E.g.: CONSTRAINT Marks_out_of_100 IS_EMPTY ( EXAM_MARK WHERE Mark 100 ) ; And to cancel this constraint: DROP CONSTRAINT Marks_out_of_100 ;

15 Relational Update Operators In theory, only assignment is needed. For example, to enrol student S5 on course C1: IS_ENROLLED_ON := IS_ENROLLED_ON UNION RELATION { TUPLE { StudentId SID ( S5 ), CourseId CID ( C1 ) } } ; But thats not always convenient, and not easy for the system to do the update quickly, either.

16 INSERT, UPDATE, DELETE The following shorthands are universally agreed on: INSERT, for adding tuples to a relvar UPDATE, for updating existing tuples in a relvar DELETE, for removing tuples from a relvar loosely speaking!

17 INSERT In Tutorial D: INSERT relvar-name relation-expression ; E.g. INSERT IS_ENROLLED_ON RELATION { TUPLE { StudentId SID ( S5 ), CourseId CID ( C1 ) }, TUPLE { StudentId SID ( S4 ), CourseId CID ( C4 ) }} ;

18 UPDATE In Tutorial D: UPDATE relvar-name [ WHERE … ] attribute-updates ; E.g. UPDATE EXAM_MARK WHERE CourseId = CID ( C1 ) Mark := Mark + 5 ; When it was decided that the exam for C1 had been a little too difficult, perhaps. Everybody who sat the exam gets 5 more marks.

19 DELETE In Tutorial D: DELETE relvar-name [ WHERE condition ] ; E.g. DELETE IS_CALLED WHERE Name = NAME ( Boris ) ; (Did we mean to do that? theres more than one Boris!)

20 An Occasional Problem with Updating Suppose the following constraints are in effect: In IS_ENROLLED_ON: FOREIGN KEY StudentId REFERENCES IS_CALLED CONSTRAINT Student_on_course IS_ENROLLED_ON { StudentId } IS_CALLED { StudentId } ; We cant enrol a student before we have named her and we cant name her before we have enrolled her on some course. Impasse?

21 Proposed Solution to The Impasse Multiple assignment: updating several variables simultaneously. In Tutorial D: INSERT IS_CALLED RELATION { TUPLE { StudentId SID ( S6 ), Name NAME ( Zoë ) } }, INSERT IS_ENROLLED_ON RELATION { TUPLE { StudentId SID ( S6 ), CourseId CID ( C1 ) } } ;

22 A Note on Multiple Assignment INSERT IS_CALLED RELATION { TUPLE { StudentId SID ( S6 ), Name NAME ( Zoë ) } }, INSERT IS_ENROLLED_ON EXTEND IS_CALLED WHERE Name = NAME (Zoë ) ADD (CID(C1) AS CourseId) {StudentId, CourseId } ; Would the following have the same effect? No! The second INSERT cannot see Zoë.