1 / 38

Riyadh Philanthropic Society For Science Prince Sultan College For Woman

Riyadh Philanthropic Society For Science Prince Sultan College For Woman Dept. of Computer & Information Sciences CS 340 Introduction to Database Systems (Chapter 5: The Relational Data Model and Relational Database Constraints). Outline Introduction Informal Definition

norina
Download Presentation

Riyadh Philanthropic Society For Science Prince Sultan College For Woman

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Riyadh Philanthropic Society For Science Prince Sultan College For Woman Dept. of Computer & Information Sciences CS 340 Introduction to Database Systems (Chapter 5: The Relational Data Model and Relational Database Constraints)

  2. Outline • Introduction • Informal Definition • Formal Definition • Attributes, Domains, & Relations • Characteristics of Relations • Relational Model Constraints • Relational Databases and Relational Database Schemas • Update Operations & Dealing With Violations

  3. Introduction • The relational model was first introduced by Ted Codd of IBM • research in 1970. • The relational model uses the concept of a mathematical relation. • A mathematical relation concept is based on the ideas of sets. • It has been the dominant technology since the 1980s.

  4. Informal Definition • Each relation resembles a table of values. • A relation may be thought of as a set of rows or columns. • Each row represents a collection of related data values. • Each row represents a fact that corresponds to a real-world entity or • relationship. • Each row has a value of an item(s) that uniquely identifies the row • in the table. • Each column is called by its name or column header or attribute • name. • All values in a column are of the same data type.

  5. Formal Definition • The table is called a relation. • A row is called a tuple. • A column header is called an attribute. • A domain is the set of possible values for an attribute. Relation Attribute Department Dnumber Dname Location 1 Accounting New York 2 Research Dallas 3 Sales Chicago 4 Operations Boston Domain for location: New York, Dallas, Chicago, Boston, Manchester, London, etc Tuple

  6. Attributes, Domain, & Relations • No composite or multivalued attributes are permitted. • This property is known as the First Normal Form. • The domain of values for an attribute contains only atomic values. • A common method of specifying a domain is to specify a data type • from which the data values forming the domain are drawn. • Each domain is given a name, datatype, & format. • E.g. Name = SALARY, datatype = integer, format = 5 digits.

  7. Attributes, Domains, & Relations • The degree of a relation is the number of attributes n of its relation • schema. Degree = 4 Department Dnumber Dname Location Phone 1 Accounting New York 749-1111 2 Research Dallas null 3 Sales Chicago null 4 Operations Boston null

  8. Attributes, Domains, & Relations

  9. Characteristics of Relations • Ordering of tuples in a relation: the tuples are not considered to • be ordered, even though they appear to be in the tabular form. • Ordering of values within a tuple: the attributes in R and the • values in t are considered to be ordered. (although, a more general • definition of relation does not require this ordering). • Values and nulls in the tuples: all values are considered atomic. A • special null value is used to represent values that are unknown. • Interpretation (Meaning) of a Relation: a relation schema can be • interpreted as: • A declaration or a type of assertion. • A predicate.

  10. Characteristics of Relations Ordering of tuples

  11. Characteristics of Relations • Ordering of values • The following two tuples are equal: • t=< {Name,Dick Davidson},{Ssn,422-11-2320}, {Home_phone,Null}, {Address,3452 Eign Road}, {Office_Phone,749-1253}, {Age,25}, {Gpa, 3.53}> • t= <{Address,3452 Eign Road}, {Name,Dick Davidson},{Ssn,422-11-2320},{Age,25}, {Office_Phone,749-1253}, {Gpa, 3.53},{Home_phone,Null}>

  12. Characteristics of Relations • Values and nulls in the tuples • Each value in a tuple is considered to be atomic (i.e. it is not divisible into components). Hence the composite or multi-valued attributes are not allowed. This model is called Flat Relational Model. This assumption is called the first Normal Form. • Multi-valued attributes are represented by separate relations • Composite attributes are represented only by their simple component attributes in the basic relational model. • Null values are used to represent values of attributes that are unknown, unavailable, or not applicable to a tuple. A special value NULL is used for these cases.

  13. Characteristics of Relations • Interpretation (Meaning) of a Relation • The relation schema can be interpreted as: • A declaration or a type of assertion i.e. some relations may represent facts about entities, whereas other may represent facts about relationships. • e.g. The first tuple in fig. 1 asserts the fact that there is a STUDENT whose Name is Benjamin Bayer, Ssn is 305-61-2435, Age 19 and so on. • A relation schema MAJORS (Student_Ssn, Department_code) asserts that students major in academic disciplines. • A predicate which means the values in each tuple are interpreted as values that satisfy the predicate.e.g. The predicate STUDENT(name, Ssn, ...) is true for the five tuples in relation STUDENT of Fig.1. These tuples represent five different facts in the real world. Any other combination of values makes the predicate false.

  14. Relational Model Constraints • Inherent model-based constraints: constraints that are inherent • in the data model. • Schema-based constraints: constraints that can be directly • expressed in the schemas of the data model, typically by • specifying them in the DDL. • Application-based constraints: constraints that cannot be • directly expressed in the schemas of the data model, and hence • must be expressed and enforced by the application programs.

  15. Inherent Model-based (implicit) Constraints • Ordering of tuples in a relation is not important. • Ordering of values within a tuple is important. • Arelation cannot have duplicate tuples. • Interpretation (Meaning) of a Relation. Every relation represents facts about entities or relationships.

  16. Schema-Based (Explicit) Constraints • Include: • Domain constraints. • Key constraints. • Constraints on nulls. • Entity integrity constraints. • Referential integrity constraints.

  17. Domain Constraints • It specifies that within each tuple, the value of each attribute must • be an atomic value from the domain. • The data types associated with domains: integers, real • numbers, characters, booleans, strings, ...etc.

  18. Also superkeys • Key Constraints • Super key: a set of attributes SK of R such that no two tuples in • any valid relation instance will have the same value for SK. • Key: a “minimal” superkey; that is, a superkey from which we can • not remove any attribute(s) and still have the uniqueness constraint • hold. • E.g. CAR (State, Reg#, SerialNo, Make, Model, Year) • Has two keys: • Key 1 = {State, Reg#}. • Key 2 = {SerialNo}. • {SerialNo, Make} is a superkey but not a key. • If a relation has several candidate keys, one is chosen arbitrary to • be the primary key.

  19. Key Constraints • It specifies that no two tuples can have the same value for their • primary keys.

  20. Constraints on Null values • Specifies whether null values are or are not permitted. Ex: if every STUDENT tuple must have a valid, non-NULL value for the Name attribute, then the Name of STUDENT is constrained to be NOT NULL.

  21. Entity Integrity Constraints • The primary key attributes PK of each relation schema R in S cannot have null values in any tuple. This is because primary key values are used to identify the individual tuples. • t[PK]  null for any tuple t in r(R) • If PK has several attributes, null is not allowed in any of these attributes • Other attributes of R may be constrained to disallow null values, even though they are not members of the primary key.

  22. Referential Integrity Constraints • A constraint involving two relations • The previous constraints involve a single relation. • Used to specify a relationship among tuples in two relations: • The referencing relation and the referenced relation.

  23. Referential Integrity Constraints • It is used to maintain the consistency among tuples in the two relations (the referencing relation and the referenced relation). • Tuples in the referencing relation have attributes FK (foreign • key) that reference the primary key attribute PK of the • referenced relation. • The value in the foreign key of the referencing relation can be • either: • A value of an existing primary key value of the corresponding • primary key in the referenced relation. Or, • A null.

  24. Referential Integrity Constraints (Example) CUSTOMER ORDER CustomerID CustomerName Foreign Key OrderID OrderDate CustomerID

  25. Relational Databases and Relational Database Schemas • A relational Database schema S is a set of relation schema S= { R1,R2,…Rm} and a set of integrity Constraints IC. • A relational Database State DB of S is a set of relation states DB= { r1,r2,…rm} such that each ri is a state of Ri and such that the ri relation states satisfy the integrity constraints specified in IC. • A database state that does not obey all the integrity constraints is called an invalid state, and a state that satisfies all the constraints in IC is called a valid state.

  26. Relational Databases and Relational Database Schemas • Attributes that represent the same real world concept may or may not have identical names in different relation. ( Ex: Ssn and Super-ssn, Dnumber and Dnum ) • Attributes that represent different concepts may have the same name in different relations.

  27. COMPANY Database Schema

  28. One Possible Database State for COMPANY

  29. Referential Integrity Constraint for COMPANY

  30. Update Operations & Dealing With Violations • The operations of the relational model can be categorized into • retrievals and updates. • Update or modification operations: • Insert. • Delete. • Update.

  31. The Insert Operation • Used to provide a list of attribute values for a new tuple. • Can violate the: • Domain constraints: if a value given doesn’t appear in the • domain. • Key constraints: if a key value already exist in the relation. • Entity integrity constraints: if the primary key of the new tuple • is null • Referential integrity constraints: if a foreign key value refers to a • non existent tuple. • When violation occurs the default option is to reject the insertion. • (or correct the reason for rejection)

  32. The Insert Operation • DEPARTMENT • INSERT (1.5, Marketing, Los Angeles) into DEPARTMENT • INSERT (1, Marketing, Los Angeles) into DEPARTMENT • INSERT (null, Marketing, Los Angeles) into DEPARTMENT DeptNO DName Location 1 Accounting New York 2 Research Dallas 3 Sales Chicago 4 Operations Boston

  33. The Delete Operation • Can violate only the referential integrity constraint if the tuple being • deleted is referenced by the foreign key(s) from other relation. • To specify deletion, a condition on the attributes of the relation • selects the tuple(s) to be deleted. • Three options are available if deletion causes a violation: • To reject the deletion. • To attempt to cascade the deletion by detecting tuples that • reference the tuple that is being deleted. • To modify the referencing attribute values causing violation by • either setting it to null or changing it to reference another valid • tuple.

  34. The Delete Operation • DEPARTMENT EMPLOYEE DeptNO DNname 1 Accounting 2 Research EmplNO ... DeptNO 111 ... 1 222 ... 2 Deleting this tuple violation of referential integrity

  35. The Update Operation • Used to change the values of an attribute(s) in a tuple of R. • It is necessary to specify a condition on the attribute(s) of the • relation to select the tuple(s) to be modified. • Updating an attribute that is neither a primary key nor a foreign key • causes no problems. DBMS needs only to check the datatypeand • domain. • All issues of insert & delete apply if updating a primary key or a • foreign key.

  36. The Update Operation Any of the other constraints may also be violated, depending on the attribute being updated: - Updating the primary key (PK): • Similar to a DELETE followed by an INSERT • Need to specify similar options to DELETE - Updating a foreign key (FK): • May violate referential integrity

  37. In-Class Exercise (Taken from Exercise 5.16) Consider the following relations for a database that keeps track of student enrollment in courses and the books adopted for each course: STUDENT(SSN, Name, Major, Bdate) COURSE(Course#, Cname, Dept) ENROLL(SSN, Course#, Quarter, Grade) BOOK_ADOPTION(Course#, Quarter, Book_ISBN) TEXT(Book_ISBN, Book_Title, Publisher, Author) Specify the foreign keys for this schema, then draw a relational schema diagram.

  38. Answer: The schema of this question has the following four foreign keys: 1. the attribute SSN of relation ENROLL that references relation STUDENT, 2. the attribute Course# in relation ENROLL that references relation COURSE, 3. the attribute Course# in relation BOOK_ADOPTION that references relation COURSE, and 4. the attribute Book_ISBN of relation BOOK_ADOPTION that references relation TEXT.

More Related