DBMS. Relational Model. Module Title?

Transcription

1 Relational Model

2 Why Study the Relational Model? Most widely used model currently. DB2,, MySQL, Oracle, PostgreSQL, SQLServer, Note: some Legacy systems use older models e.g., IBM s IMS Object-oriented t concepts have recently merged in object-relational model Informix, IBM DB2, Oracle 8i Early work done in POSTGRES research project at Berkeley XML (semi-structured)models emerging??

3 Relational Model Concepts The relational Model of Data is based on the concept of a Relation. A Relation is a mathematical concept based on the ideas of sets. The strength of the relational approach to data management comes from the formal foundation provided by the theory of relations.

4 Relational Model Concepts The model was first proposed by Dr. E.F. Codd of IBM in 1970 in the following paper: "A Relational Model for Large Shared Data Banks," Communications of the ACM, June The above paper caused a major revolution in the field of Database management and earned Ted Codd the coveted ACM Turing Award.

5 Introduction Relational model was first proposed in 1970 by Dr E F (Ted) Codd. Purpose: Achieve program/data independence The structure of the database is stored separately in the system catalog from the access of the application programs. Treat data in a disciplined way (data is ordered rows and column) Apply rigor of mathematics (sum: total marks) manipulating a set of records at a time Use of set theory Improve programmer productivity (join, union, cross product)

6 What is a Relational Database? A relational database is made up of tables (relations) in which data are stored. A table (relation) is a 2-dimensional structure made up of columns (attributes) and rows (tuples).

7 TABLE 1. A relation is a table of values ** column Employee ENum EName Dept Hire_date 204 R. B. Jones E21 11/01/1999 table row 1917 M. R. Brent E21 10/10/2003 relation tuple The "ENum" column

8 FORMAL DEFINITIONS Each row in the EMPLOYEE table may be referred to as a tuple in the table and would consist of four values, e.g.: <1917, "M. R. Brent", "E21", "10/10/2003">. A relation (table) may be regarded as a set of tuples (rows). Employee ENum EName Dept Hire_date 204 R. B. Jones E21 11/01/ M. R. Brent E21 10/10/2003

9 The ROWS of a TABLE 2. No two rows in a table can be the same (i.e., they can't have identical values) Employee ENum EName Dept Hire_date row tuple 204 R. B. Jones E21 11/01/ M. R. Brent E21 10/10/2003 table relation

10 The COLUMNS of a TABLE The columns of a table are also called attributes of the relation. The attribute help in interpreting the meaning of the values The attribute names will be useful in searching the table. For example: Find all EName where Dept=E21. In plain English, that would be Employee ENum EName Dept Hire_date 204 R. B. Jones E21 11/01/ M. R. Brent E21 10/10/2003 Attributes

11 Relational Database Terminology Record or Tuple: Each row in the relation. Attribute: Each column in the relation. Domain: The set of allowable values for a column. Degree: The number of columns in a relation. Cardinality: The number of rows in a relation.

12 Relational Database: Definitions Relational database: a set of relations. Relation: made up of 2 parts: Schema : specifies name of relation, plus name and type of each column. E.g. g Students(sid, name, login, age, gpa) Instance : a table, with rows and columns. #rows = cardinality #fields = degree Can think of a relation as a set of rows or tuples. i.e., all rows are distinct

13 Properties of Relations There are no duplicate tuples. This property follows from the fact that the body of the relation is a mathematical set (i.e., a set of tuples), and sets in mathematics by definition do not include duplicate elements. If a "relation" contains duplicate tuples, then it is not a relation.

14 Tuples are unordered (top to bottom). Sets in mathematics are not ordered. So, even if a relation A's tuples are reversely ordered, it is still the same relation. Thus, there is no such thing as "the 5th tuple" or the last tuple. In other words, there is no concept of positional addressing.

15 Attributes are unordered (left to right). This property follows from the fact that the heading of a relation is also defined as a set. There is no such thing as "5th attribute" or the last attribute.

16 All attribute values are atomic. At every row-and-column position within the table, there always exists precisely one value, never a list of values. Or equivalently, relations do not contain repeating groups. A relation satisfying this condition is said to be in First Normal Form.

17 Rules to convert E-R to Relational model: An entity type turns into a relation table: Give it a sensible name avoid reserved words and no spaces in attribute names. Choose appropriate Names, which are self-explanatory. Each attribute turns into a column/field in the relation: Keep the attribute domains you will need them later when you implement the schema in Oracle. The primary key of the entity is the primary key of the table: It can be composite if required. It can never be null.

18 Transforming Entity Sets and Their Attributes EMPLOYEE EMPID[PK] NAME SALARY

19 The above ER Model is translated into the following relational design: EMPLOYEE (empid, name, salary)

20 Transforming 1:1 Relationships EMPLOYEE 1:1 AUTO

21 Transforming 1:1 Relationships EMPLOYEE( EmpNum, Name, Phone,...) AUTO( AutoId, Model, Year, Color,..., EmpNum) or EMPLOYEE( EmpNum, Name, Phone,..., AutoID) AUTO( AutoID, Model, Year, Color,...) In both cases, we would want to enforce referential integrity i by requiring that the value of a foreign key in one relation/table appear as the value of a primary key in the other relation/table.

22 Transforming One to Many Relationships TEACHER 1:N STUDENT

23 Transforming One to Many Relationships TEACHER( TeacherName, Phone_no, no, Dept) STUDENT( StudentId, StuName,..., TeacherName) Transformation Rule: The primary key of the entity set on the "One" side sdeof the relationship eato pbecomes esa foreign oeg key eyof the eentity tty set on the "Many" side of the relationship.

24 Transforming Many to Many E-R Relationships STUDENT M:N CLASS

25 Transforming Many to Many E-R Relationships STUDENT( StudentNum, StuName, Phone,...) CLASS( ClassNum, ClassName,...) STU-CLASS( StudentNum, ClassNum) RULE: Create a new relation, called an Intersection relation, whose only (unless there is also an attribute belonging to the relationship) attributes will be a composite primary key consisting of the primary keys of the entity set participants in the relationship.

26 Keys Keys are a way to associate tuples in different relations Keys are one form of integrity constraint (IC) Enrolled sid cid grade Carnatic101 C Reggae203 B Topology112 A History105 B Students sid name login age gpa Jones jones@cs Smith smith@eecs Smith smith@math FORIEGN Key PRIMARY Key

27 Foreign Keys, Referential Integrity Foreign key : Set of fields in one relation that is used to `refer to a tuple in another relation. Must correspond to the primary key of the other relation. Like a `logical pointer. If all foreign key constraints are enforced, referential integrity is achieved (i.e., no dangling references.)

28 Candidate Keys

29 Keys in A candidate key is an attribute (or set of attributes) that uniquely identifies a row. A candidate key must possess the following properties: Unique identification - For every row the value of the key must uniquely identify that row. Non redundancy - No attribute in the key can be discarded without destroying the property of unique identification. A super key is any set of attributes that uniquely identifies a row. A super key differs from a candidate key in that it does not require the non redundancy property.

30 Keys in A primary key is the candidate key which h is selected as the principal i unique identifier. Every relation must contain a primary key. The primary key is usually the key selected to identify a row when the database is physically implemented. For example, a part number is selected instead of a part description.

31 Enforcing Referential Integrity Consider Students and Enrolled; sid in Enrolled is a foreign key that references Students. What should be done if an Enrolled tuple with a non-existent student id is inserted? (Reject j it!) ) What should be done if a Students tuple is deleted? Also delete all Enrolled tuples that refer to it? Disallow deletion of a Students tuple that is referred to? Set sid in Enrolled tuples that refer to it to a default sid? (In SQL, also: Set sid in Enrolled tuples that refer to it to a special value null, denoting `unknown or `inapplicable.) Similar issues arise if primary key of Students tuple is updated.

32 DATA INTEGRITY CONSTRAINTS: A constraint helps us to implement business rules in the database. Type of constraints: Not Null: Attribute value is must. E.g. Studentname, address. Unique: Attribute value should be different or not same. E.g. Rollno. Primary Key: Attribute which is Unique + Not null. E.g. Rollno. It is an attribute or set of attributes, which uniquely identifies the record in a relation. This is also known as the entity integrity rule.

33 DATA INTEGRITY CONSTRAINTS: Check : Data has to follow some condition or rule. E.g. bank balance amount should not be less than 5 Student marks not greater than 100