Presentation is loading. Please wait.

Presentation is loading. Please wait.

The Relational Database Model

Similar presentations


Presentation on theme: "The Relational Database Model"— Presentation transcript:

1 The Relational Database Model
Chapter 3 The Relational Database Model Database Systems: Design, Implementation, and Management, Seventh Edition, Rob and Coronel

2 In this chapter, you will learn:
That the relational database model takes a logical view of data The relational model’s basic components are relations implemented through tables in a relational DBMS How relations are organized in tables composed of rows (tuples) and columns (attributes) <SKIP> Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

3 In this chapter, you will learn (continued):
About relational database operators, the data dictionary, and the system catalog How data redundancy is handled in the relational database model Why indexing is important <SKIP> Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

4 A Logical View of Data view data logically rather than physically.
The use of logically independent tables is easier to understand. simpler and more effective database design methodologies. Relational database model’s structural and data independence enables us to view data logically rather than physically. *** The logical view allows a simpler file-like concept of data storage. The use of logically independent tables is easier to understand than hierarchical and network predecessors. Logical simplicity yields simpler and more effective database design methodologies. Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

5 Entities and Attributes
A Logical View of Data Entities and Attributes An entity is a person, place, event, or thing for which we intend to collect data. Each entity has certain characteristics known as attributes. <SKIP? Probably already covered by here> Entities and Attributes An entity is a person, place, event, or thing for which we intend to collect data. University -- Students, Faculty Members, Courses Airlines -- Pilots, Aircraft, Routes, Suppliers Each entity has certain characteristics known as attributes. Student -- Student Number, Name, GPA, Date of Enrollment, Data of Birth, Home Address, Phone Number, Major Aircraft -- Aircraft Number, Date of Last Maintenance, Total Hours Flown, Hours Flown since Last Maintenance Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

6 Entities and Attributes
A Logical View of Data Entities and Attributes A grouping of related entities becomes an entity set. E.g. The STUDENT entity set contains all student entities.. <SKIP? Probably already covered by here> Entities and Attributes A grouping of related entities becomes an entity set. The STUDENT entity set contains all student entities. The FACULTY entity set contains all faculty entities. The AIRCRAFT entity set contains all aircraft entities. Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

7 Tables and Their Characteristics
A Logical View of Data Tables and Their Characteristics table contains a group of related entities -- i.e. an entity set. A table is also called a relation. Logically, looks like a table – rows and columns <SKIP? Probably already covered by here> Tables and Their Characteristics A table contains a group of related entities -- i.e. an entity set. The terms entity set and table are often used interchangeably. (table used a lot more) A table is also called a relation – more precise than table – theory of relational DBs based on mathematical theory – involving relations Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

8 Tables and Their Characteristics (continued)
<create student table handout and use to illustrate all of this><already discussed 1-3> 4 – is important (seems obvious, but could student have two majors? What do we do then?) 5 – numeric, character, date, logical 6 – domain is type + possible values – e.g. gpa is real number between 0 and 4, class is fr, so, jr, sr 9 – e.g. student id. Entity integrity rule – primary keys must not contain “Null”s – null is “no value” – not blank; could mean unknown value, missing value, not applicable Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

9 Tables and Their Characteristics (continued)
<SKIP – use my univ> Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

10 Controlled redundancy
Makes the relational database work Tables within the database share common attributes that enable the tables to be linked together Primary key of one table is referenced by foreign key in another table Multiple occurrences of values in a table are not redundant when they are required to make the relationship work Redundancy exists only when there is unnecessary duplication of attribute values referential integrity - all foreign key values MUST match existing tuple The primary key of one table appears again as the link (foreign key) in another table. E.g. student id in enrollments references student id in student table referential integrity - MUST have it for all foreign keys - If the foreign key contains a value then there is a matching tuple in the related table (foreign key having null value is not a violation) Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

11 Keys (continued) <SKIP – show with Univ>
Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

12 Keys (continued) <SKIP – show with Univ>
Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

13 Nulls Nulls: No data entry Not permitted in primary key
Should be avoided in other attributes Can represent An unknown attribute value A known, but missing, attribute value A “not applicable” condition Can create problems when functions such as COUNT, AVERAGE, and SUM are used Can create logical problems when relational tables are linked Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

14 Integrity Rules < show univ – what would be a violation>
Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

15 Keys Consists of one or more attributes that determine other attributes Primary key (PK) is an attribute (or a combination of attributes) that uniquely identifies any given entity (row) Key’s role is based on determination If you know the value of attribute A, you can look up (determine) the value of attribute B E.g. Student # is PK for STUDENT. If you know a student’s student #, you can look up their name, etc in the STUDENT table Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

16 Keys A determines B – knowing the value for A means you can look up (determine) the value for B. The attribute B is functionally dependent on A if A determines B. More technically, but less clearly: An attribute B is functionally dependent on an attribute A if, all rows in the table that agree in value for attribute A must also agree in value for attribute B A Primary key should Functionally Determine all of the other attributes in a table How do you know what FDs are true? From Business Rules !!!! e.g. Student id determines student last name (but not vice versa!!) Notation: Student ID  last name (second definition in book (in greenish box) is less clear) (third definition in book – in another greenish box) – this basically means that you can find the value for attribute B if you know the value for attribute A – I.e. that you can look it up (you can use the primary key value to look up all of the other values !! (since it uniquely identifies records in the table !!!)) Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

17 Keys An attribute that is (all or) part of a key is known as a key attribute. A multi-attribute key is known as a composite key. If the attribute (B) is functionally dependent on a key (A) but not on any subset of that key, the attribute (B) is fully functionally dependent on (A). e.g. time, room, semester, year is a composite key for section <skip – save for when we deal with normalization> (this can only be an issue if the key is composite – all non-composite functional dependencies are full functional dependencies)(FDs don’t have to involve keys (in a good design they should), this should deal with composite attributes not just composite keys) Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

18 Keys (continued) <SKIP>
Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

19 Keys (continued) <too soon>
… Superkey may have excess attributes. E.g. student ID, last name is a superkey (but so is student ID by itself) … (no redundancies) … (chosen – candidate keys not chosen are “alternate keys”) … does not have to be unique – what retrievals will be done frequently? Might create a secondary key for – not really a logical concept … FK already covered Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

20 Integrity Rules (continued)
<SKIP> Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

21 Integrity Rules (continued)
<SKIP> Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

22 Relational Database Operators
Relational algebra Defines theoretical way of manipulating table contents using relational operators Use of relational algebra operators on existing tables (relations) produces new relations Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

23 Relational Algebra Operators (continued)
UNION INTERSECT DIFFERENCE PRODUCT SELECT PROJECT JOIN DIVIDE Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

24 Relational Algebra Operators (continued)
Union: Combines all rows from two tables, excluding duplicate rows Tables must have the same attribute characteristics Intersect: Yields only the rows that appear in both tables Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

25 Relational Algebra Operators (continued)
Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

26 Relational Algebra Operators (continued)
Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

27 Relational Algebra Operators (continued)
Difference Yields all rows in one table not found in the other table — that is, it subtracts one table from the other Product Yields all possible pairs of rows from two tables Also known as the Cartesian product Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

28 Relational Algebra Operators (continued)
Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

29 Relational Algebra Operators (continued)
Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

30 Relational Algebra Operators (continued)
Select Yields values for all rows found in a table Can be used to list either all row values or it can yield only those row values that match a specified criterion Yields a horizontal subset of a table Project Yields all values for selected attributes Yields a vertical subset of a table Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

31 Relational Algebra Operators (continued)
Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

32 Relational Algebra Operators (continued)
Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

33 Relational Algebra Operators (continued)
Join Allows information to be combined from two or more tables Real power behind the relational database, allowing the use of independent tables linked by common attributes Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

34 Relational Algebra Operators (continued)
Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

35 Relational Algebra Operators (continued)
Natural Join Links tables by selecting only rows with common values in their common attribute(s) Result of a three-stage process: PRODUCT of the tables is created SELECT is performed on Step 1 output to yield only the rows for which the AGENT_CODE values are equal Common column(s) are called join column(s) PROJECT is performed on Step 2 results to yield a single copy of each attribute, thereby eliminating duplicate columns Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

36 Relational Algebra Operators (continued)
Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

37 Relational Algebra Operators (continued)
Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

38 Relational Algebra Operators (continued)
Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

39 Relational Algebra Operators (continued)
Natural Join: Final outcome yields table that Does not include unmatched pairs Provides only copies of matches If no match is made between the table rows the new table does not include the unmatched row Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

40 Relational Algebra Operators (continued)
Natural Join (continued): The column on which the join was made - that is, AGENT_CODE - occurs only once in the new table If the same AGENT_CODE were to occur several times in the AGENT table, a customer would be listed for each match Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

41 Relational Algebra Operators (continued)
Equijoin Links tables on the basis of an equality condition that compares specified columns of each table Outcome does not eliminate duplicate columns Condition or criterion to join tables must be explicitly defined Takes its name from the equality comparison operator (=) used in the condition Theta join If any other comparison operator is used Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

42 Relational Algebra Operators (continued)
Outer join: Matched pairs are retained and any unmatched values in other table are left null In outer join for tables CUSTOMER and AGENT, two scenarios are possible: Left outer join Yields all rows in CUSTOMER table, including those that do not have a matching value in the AGENT table Right outer join Yields all rows in AGENT table, including those that do not have matching values in the CUSTOMER table Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

43 Relational Algebra Operators (continued)
Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

44 Relational Algebra Operators (continued)
Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

45 Relational Algebra Operators (continued)
DIVIDE requires the use of one single-column table and one two-column table Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

46 Relational Algebra Operators (continued)
Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

47 The Data Dictionary and System Catalog
Provides detailed accounting of all tables found within the user/designer-created database Contains (at least) all the attribute names and characteristics for each table in the system Contains metadata—data about data Sometimes described as “the database designer’s database” because it records the design decisions about tables and their structures Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

48 A Sample Data Dictionary
Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

49 The Data Dictionary and System Catalog (continued)
Contains metadata Detailed system data dictionary that describes all objects within the database Terms “system catalog” and “data dictionary” are often used interchangeably Can be queried just like any user/designer-created table Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

50 Relationships within the Relational Database
E-R Diagram (ERD) Rectangles are used to represent entities. Entity names are nouns and capitalized. Diamonds are used to represent the relationship(s) between the entities. The number 1 is used to represent the “1” side of the relationship. The letter M is used to represent the “many” sides of the relationship. <SKIP - most of this already covered. Could consider skipping most of the rest of this chapter because it mostly belongs with chapt 4> … ALL-CAPS that is. By convention, singular – STUDENT rather than STUDENTS … relationship name is usually a verb (possibly passive STUDENT is enrolled in SECTION) and lowercase Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

51 Relationships within the Relational Database
1:M relationship Relational modeling ideal Should be the norm in any relational database design M:N relationships Cannot be implemented as such in the relational model M:N relationships can be changed into two 1:M relationships 1:1 relationship May be rare in any relational database design Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

52 The 1:M Relationship Relational database norm
Found in any database environment Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

53 The 1:M Relationship (continued)
Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

54 The 1:M Relationship (continued)
<NOTE THE 1:M relationship – Painter 123 painted 3 paintings, but painting has only one painter <SKIP – do SECTION – PROFESSOR (M:1) – show our tables; draw the E/R NOTE – FK goes on Many side Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

55 The 1:M Relationship (continued)
Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

56 The 1:M Relationship (continued)
Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

57 The 1:1 Relationship One entity can be related to only one other entity, and vice versa Sometimes means that entity components were not defined properly Could indicate that two entities actually belong in the same table As rare as 1:1 relationships should be, certain conditions absolutely require their use Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

58 The 1:1 Relationship (continued)
Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

59 The 1:1 Relationship (continued)
Professor and Department really are distinct entities The Business Rules say: A dept has exactly one chair (who is a professor) A professor chairs no more than one dept (some professors do not chair any dept) Their FK uses employee # and is put in the Dept table – since all depts will have a chair and not all professors will be chairs Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

60 The M:N Relationship Can be implemented by breaking it up to produce a set of 1:M relationships Can avoid problems inherent to M:N relationship by creating a composite entity or bridge entity Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

61 The M:N Relationship (continued)
Many:Many relationship takes a little work to put into a relational DB – we will break this down into two 1:M relationships (soon) <I’ve been using SECTION, not CLASS> <SKIP? – have probably already shown> Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

62 The M:N Relationship (continued)
Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

63 The M:N Relationship (continued)
DONE THE WRONG WAY !! Creates redundancies – see time and room multiple times – extra storage – and risk of inconsistencies – remember my advisees!!!!! <Handout already created??? > Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

64 The M:N Relationship Do not fit naturally into a RDBMS
Access doesn’t even allow you to specify them Can be implemented by breaking it up to produce a pair of 1:M relationships create a composite (or bridge) entity – with relationships to each of the initially identified entities Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

65 Linking Table Implementation of a composite entity
Yields required M:N to 1:M conversion Composite entity table must contain at least the primary keys of original tables Linking table contains multiple occurrences of the foreign key values Additional attributes may be assigned as needed Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

66 The M:N Relationship (continued)
<USE MINE? > Extra table – what I have called ENROLLMENTS Middle entity (table) is called composite entity or bridge entity - the bridge entity contains the primary keys of the main entities as foreign keys. The PK could be composite of the foreign key, or an invented attribute (usually not as good) The middle table is sometimes called a linking table, or possibly a cross reference table Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

67 The M:N Relationship (continued)
Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

68 The M:N Relationship (continued)
Can show all entities and their relationships in one diagram <Handout? > Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

69 The M:N Relationship (continued)
… corresponding relational schema <SHOW IN ACCESS > Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

70 Data Redundancy Revisited
Data redundancy leads to data anomalies Such anomalies can destroy the effectiveness of the database Foreign keys Control data redundancies by using common attributes shared by tables Crucial to exercising data redundancy control Sometimes, data redundancy is necessary <SKIP due to time> Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

71 Data Redundancy Revisited (continued)
<SKIP due to time> Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

72 Data Redundancy Revisited (continued)
<SKIP due to time> Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

73 Indexes Arrangement used to logically access rows in a table Index key
Index’s reference point Points to data location identified by the key Unique index Index in which the index key can have only one pointer value (row) associated with it Each index is associated with only one table <SKIP> Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

74 Indexes (continued) <SKIP>
Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

75 Codd’s Relational Database Rules
In 1985, Codd published a list of 12 rules to define a relational database system The reason was the concern that many vendors were marketing products as “relational” even though those products did not meet minimum relational standards Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

76 Codd’s Relational Database Rules (Continued)
<SKIP> Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

77 Summary Tables are basic building blocks of a relational database
Keys are central to the use of relational tables Keys define functional dependencies Superkey Candidate key Primary key Secondary key Foreign key <SKIP> Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

78 Summary (continued) Each table row must have a primary key which uniquely identifies all attributes Tables can be linked by common attributes. Thus, the primary key of one table can appear as the foreign key in another table to which it is linked The relational model supports relational algebra functions: SELECT, PROJECT, JOIN, INTERSECT, UNION, DIFFERENCE, PRODUCT, and DIVIDE. Good design begins by identifying appropriate entities and attributes and the relationships among the entities. Those relationships (1:1, 1:M, and M:N) can be represented using ERDs. <SKIP> Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel


Download ppt "The Relational Database Model"

Similar presentations


Ads by Google