1. Database Management COP4540, SCS, FIU Relational Model Chapter 7

2. Database Management COP4540, SCS, FIU Relational Model Concepts The relational model represents database as a collection of relations. Informally, each relation looks like a table. Each row in the table represents an entity instance or a relationship instance.

3. Database Management COP4540, SCS, FIU Relational Definitions Relation –Every relation has a unique name. –Every attribute value is atomic. –Every row is unique. –Attributes in tables have unique names. –The order of the rows is irrelevant. –The order of the columns is irrelevant. (as long as the correspondence between attributes and values is maintained.

4. Database Management COP4540, SCS, FIU Example of relation and table

5. Database Management COP4540, SCS, FIU Relational Definitions (2) Domain –A domain D is a set of atomic values. –A domain is usually given a name, data type, and format. –Each attributes may have its own domain. –It is possible for several attributes to have the same domain but with different roles. –Examples (Page 197)

6. Database Management COP4540, SCS, FIU Relational Definitions (3) Tuple: a record in a relation ( a row in the table) Attribute: a column in a relation. View: a collection of attributes from several relations. (Actually a kind of query to database). NULL values –The values of some attributes with a particular tuple may be unknown.

7. Database Management COP4540, SCS, FIU Terms and Notations A relation schema R –denoted by R(A 1, A 2, …, A n ), is made up of a relation name R and a list of attributes A 1, A 2, …, A n. –The domain of attribute A i is denoted by dom(A i ) –The degree of a relation is the number of attributes n of its relation schema. A relation (or relation state) r of the relation schema R(A 1, A 2, …, A n ), also denoted by r(R), is a set of n-tuples r ={t 1, t 2, …, t m } where t =

8. Database Management COP4540, SCS, FIU Terms and Notations (2) An n-tuple t in a relation r(R) is denoted by t =, where v i is the value corresponding to attribute A i. –Both t[A i ] and t.A i refer to the value v i in t for attribute A i –Both t[A u, A v, …, A z ] and t.(A u, A v, …, A z ) refer to the subtuple of values from t corresponding to the attributes specified in the list.

9. Database Management COP4540, SCS, FIU Terms and Notations (3) The letters Q, R, S denote relation names. The letters q, r, s denote relation states. The letter t, u, v denote tuples. In general, the name of relation schema also indicates the current set of tuples in that relation. An attribute A can be qualified with the relation R to which it belongs by R.A because all attributes names in a particular relation must be distinct.

10. Database Management COP4540, SCS, FIU Domain Constraints Allowable values for an attribute. –Atomic –Data type –Subrange –Enumerated type.

11. Database Management COP4540, SCS, FIU Keys in a Relation Each relation has at least one KEY. A KEY uniquely identifies a tuple. A KEY can be one attribute or a combination of multiple attributes. Primary Key & Candidate Key. Indicate a key by underlining the key attributes. Entity Integrity –No primary key attribute may be null.

12. Database Management COP4540, SCS, FIU Referential Integrity & Foreign keys Foreign key A set of attributes FK in relation R 1 is a foreign key of R 1 that references R 2 if it satisfies the following two rules: 1. The attributes in FK have the same domain(s) as the primary key attribute PK of R 2 2. A value of FK in a tuple t 1 of the current state r 1 (R 1 ) either occurs as a value of PK for some tuple t 2 in the current state r 2 (R 2 ) (in this case we have t 1 [FK] = t 2 [PK]) or is null. Note that a foreign key can refer to its own relation. Referential Integrity –A rule that states that either a foreign key value must match a primary key value in the other relation or else the foreign key value must be null.

13. Database Management COP4540, SCS, FIU Examples of Foreign keys EMPLOYEE DEPARTMENT EMPLOYEE(SSN, Name, Bdate, Salary, DeptNo, SuperSSN) DEPARTMENT(Dname, Dnum, Manager)

14. Database Management COP4540, SCS, FIU Well-Structured Relations PROF(ID, COURSE_Title, Salary, Date) Insertion Anomaly: Insertion of a new record encounters unreasonable restrictions. –E.g. The example relation requires the knowledge of course data in order to enter a new professor. This is, of course, not a good design of relations.

15. Database Management COP4540, SCS, FIU Well-Structured Relations (2) PROF(ID, COURSE_ID, Text, Salary, Date) Deletion Anomaly: Loss of information due to deletion. –E.g. The example relation can lead to loss of information on the text of courses when a professor is deleted.

16. Database Management COP4540, SCS, FIU Well-Structured Relations (3) PROF(ID, COURSE_ID, Text, Salary, Date) Modification Anomaly: Change of data contents may lead to inconsistent data. –E.g. When a professor is given a raise, all rows pertaining to the professor must be modified; otherwise, the same professor will have different salaries.

17. Database Management COP4540, SCS, FIU Representing attributes in ODL A direct conversion of classes in ODL into relations –All properties of the class are attributes. –The type of attributes are atomic. What about non-atomic attributes? – Problem: ODL allows attribute types build from structures and collection types. –Structure: make one sub-attribute for each field. –Set: make one tuple for each member of the set.

18. Database Management COP4540, SCS, FIU Example class Drinkers (key name) { attribute string name; attribute Struct Addr {string street, string city, int zip} address; attribute Set phone; }; Note that the key for the class (name) is not the key for the relation. Name in the class determines a unique object, including a unique set of phones. Name in the relation does not determine a unique tuple. Tuples are not identical to objects.

19. Database Management COP4540, SCS, FIU Decompose Relations? One option is to get phone into a separate relation (with name). The database would look like: Advantages: 1. Avoids redundancy in address components. 2. Handles the case where someone has no phone. Disadvantage: Harder to answer queries that jump between two relations, e.g., “what city is phone 650-725-4802?”

20. Database Management COP4540, SCS, FIU A Design Problem class Family { attribute Set parents; attribute Set children; }; 1. What is the key? 2. How should we represent a family with two parents and three children? 3. What if we use “Array ” (Suppose the size of the array is 2) to define “parents” ?

21. Database Management COP4540, SCS, FIU Representing Single-valued Relationship Single-valued relationship –Do not use collection type when define relationship. –Actually one-one or many-one relationship. For a single-valued relationship R from classes C 1 to class C 2, 1. Create two relations T 1 and T 2 for the classes C 1 and C 2 respectively. 2. Add the key attributes of T 2 into T 1. 3. What if there is no KEY?

22. Database Management COP4540, SCS, FIU Representing Multi-valued Relationship Single-valued relationship –Use collection type when define relationship. –Actually one-many or many-many relationship. For a single-valued relationship R from classes C 1 to class C 2, 1. Create two relations T 1 and T 2 for the classes C 1 and C 2 respectively. 2. Add the key attributes of T 2 into T 1. 3. More redundancy occurs.

23. Database Management COP4540, SCS, FIU Representing Relationship in One Direction For one-one relationship and many-many relationships, we can chose to express the either direction. For one-many and many-one relationships, we should chose to represent the many-one relationship since it comes with less redundancy.