Database Systems Instructor Name: Lecture-12

Contents Resolve Unary Relationship Resolve Ternary Relationship Resolve One-to-Many Unary Relationship Resolve Many-to-Many Unary Relationship Resolve Ternary Relationship Relational Model Integrity Constraints Well Structured Relations and Anomalies 2

Resolve Many-to-Many Unary Relationship Two Entities are created One for the Entity Type itself and other for Many-to-Many Relationship The primary key of the associative relation consists of two attributes, both taking their values from the primary key of the other relation Any non-key attribute of the relationship is included in the associative relation {Represent in ERD} 3

Resolve Many-to-Many Unary Relationship (a) Bill-of-materials relationships (M:N) (b) ITEM and COMPONENT relations 4

Resolve Ternary Relationship It is best to convert a ternary relationship to an associative entity in order to represent participation constraints more accurately. Firstly, we create a new associative relation. The default primary key of this relation consists of the three primary key attributes for the participating entities (sometimes additional attributes are required to form a unique primary key) These attributes then act in the role of foreign keys that reference the individual primary keys of the participating entity types . Any attributes of the associative entity type become attributes of the new relation 5

Resolve Ternary Relationship The following Fig. Represents a PATIENT receiving a TREATMENT from a PHYSICIAN The associative entity type PATIENT_Treatment has the attributes Date, Time and Results and values of these are recorded for each instance of patient treatment The primary key attributes Patient_ID, Physician_ID and Treatment_Code become foreign keys in PATIENT_TREATMENT – these are components of its primary key but do not uniquely identify a given treatment, since a patient may receive the same treatment from the same physician on more than one occasion 6

Ternary Relationship with Associative Entity 7

Resolve Ternary Relationship with Associative Entity 8

The Relational Model Was introduced in 1970 by Dr. E. F. Codd (of IBM) Commercial relational databases began to appear in the 1980s Today relational databases have become the dominant technology for database management 9

The Relational Model Data is represented in the form of tables, and the model has 3 components Data structure – data are organised in the form of tables with rows and columns Data manipulation – powerful operations (using the SQL language) are used to manipulate data stored in the relations Data integrity – facilities are included to specify business rules that maintain the integrity of data when they are manipulated 10

Relational Definitions A relation is a named, two-dimensional table of data Every relation has a unique name, and consists of a set of named columns and an arbitrary number of unnamed rows An attribute is a named column of a relation, and every attribute value is atomic. Every row is unique, and corresponds to a record that contains data attributes for a single entity. The order of the columns is irrelevant. The order of the rows is irrelevant. 11

Integrity Constraints These help maintain the accuracy and integrity of the data in the database Domain Constraints - a domain is the set of allowable values for an attribute. Domain definition usually consists of 4 components: domain name, meaning, data type, size (or length), allowable values/allowable range (if applicable) Entity Integrity ensures that every relation has a primary key, and that all the data values for that primary key are valid. No primary key attribute may be null. 12

Entity Integrity In some cases a particular attribute cannot be assigned a data value, e.g. when there is no applicable data value or the value is not known when other values are assigned In these situations we can assign a null value to an attribute (null signifies absence of a value) But still primary key values cannot be null – the entity integrity rule states that “no primary key attribute (or component of a primary key attribute) may be null 13

Referential Integrity A Referential Integrity constraint is a rule that maintains consistency among the rows of two relations – it states that any foreign key value (on the relation of the many side) MUST match a primary key value in the relation of the one side. (Or the foreign key can be null) 14

Referential Integrity How do you know if a foreign key is allowed to be null? In this example, as each ORDER must have a CUSTOMER the foreign key of Customer_ID cannot be null on the ORDER relation Whether a foreign key can be null must be specified as a property of the foreign key attribute when the database is designed 15

Referential Integrity what happens to order data if we choose to delete a customer who has submitted orders? We may want to see sales even though we do not care about the customer anymore. Three choices are possible: Restrict – don’t allow delete of “parent” side if related rows exist in “dependent” side, i.e. prohibit deletion of the customer until all associated orders are first deleted Cascade – automatically delete “dependent” side rows that correspond with the “parent” side row to be deleted, i.e. delete the associated orders, in which case we lose not only the customer but also the sales history Set-to-Null – set the foreign key in the dependent side to null if deleting from the parent side - an exception that says although an order must have a customer_ID value when the order is created, Customer_ID can become null later if the associated customer is deleted [not allowed for weak entities] 16

Well Structured Relations A well-structured relation contains minimal redundancy and allows users to insert, modify and delete the rows in a table without errors and inconsistencies Redundancies in a table (such as more than one entry for each EMPLOYEE) may result in errors and inconsistencies (anomalies) when the table is updated 3 Types of anomaly are possible, insertion, deletion and modification anomalies 17

Insertion Anomaly Insertion anomaly – looking at EMPLOYEE: A1 Fred Bloggs Info Sys Delphi A1 Fred Bloggs Info Sys VB Suppose that we want to add a new employee – the primary key for this relation is the combination of Emp_ID and Course_Title. Therefore, to insert a new row, the user must supply both these values (since primary keys cannot be null or nonexistent) This is an anomaly, since the user should be able to enter employee data without supplying course data 18

Insertion Anomaly Insertion anomaly – looking at EMPLOYEE: A1 Fred Bloggs Info Sys Delphi A1 Fred Bloggs Info Sys VB Suppose that we want to add a new employee – the primary key for this relation is the combination of Emp_ID and Course_Title. Therefore, to insert a new row, the user must supply both these values (since primary keys cannot be null or nonexistent) This is an anomaly, since the user should be able to enter employee data without supplying course data 19

Deletion and Modification Anomaly Suppose that the data for a particular employee are deleted from the table This results in losing the information that this employee completed a particular course This results in losing the information that this course was offered – deletion anomaly If employee A1 changes the department they work in, this must be recorded in both the rows of the table otherwise the data will be inconsistent – modification anomaly 20

Resolve Anomalies These anomalies indicate that EMPLOYEE is not a well-structured relation We should use normalisation theory (discussed later) to divide EMPLOYEE2 into 2 relations, one called EMPLOYEE1 and one called EMP_COURSE that keeps track of the course details 21

Database Systems - Lab What are Constraints? Types of Constraints Constraints are used to control, reference, verify (check) and restrict (allowable) Types of Constraints Column Level (inline) Table Level (out-of-line) 22

Constraint Column Level Constraints Not Null Unique Check Default Table Level Constraints Primary Key (In parent table) Foreign Key (In child table) 23

Creating Constraint Add Constraint at Table Level Creation Change and Drop Constraint using ALTER TABLE command Add Table Level Constraint Modify Table and Column Level Constraints Rename Table and Column Level Constraints Drop Table and Column Level Constraints Primary Key (In parent table) Foreign Key (In child table) 24

Creating Constraint On delete Cascade On Delete Set Null Enable/ Disable Constraints 25

Table with Constraints CREATE TABLE Show ( show_id NUMBER NOT NULL, category_id NUMBER NOT NULL, act_id NUMBER NOT NULL, venue_id NUMBER NOT NULL, showdate DATE NULL, CONSTRAINT XPKShow PRIMARY KEY (show_id), CONSTRAINT FKShow_Cat FOREIGN KEY (category_id) REFERENCES Category, CONSTRAINT FKShow_Venue FOREIGN KEY (venue_id) REFERENCES Venue, CONSTRAINT FKShow_Act FOREIGN KEY (act_id) REFERENCES Act ); 26

Table with Constraints CREATE TABLE Dept_tab ( Deptno NUMBER(3) CONSTRAINT Dept_pkey PRIMARY KEY, Dname VARCHAR2(15), Loc VARCHAR2(15), CONSTRAINT Dname_ukey UNIQUE (Dname, Loc), CONSTRAINT Loc_check1 CHECK (loc IN ('NEW YORK', 'BOSTON', 'CHICAGO'))); CREATE TABLE Emp_tab ( Empno NUMBER(5) CONSTRAINT Emp_pkey PRIMARY KEY, Ename VARCHAR2(15) NOT NULL, Job VARCHAR2(10), Mgr NUMBER(5) CONSTRAINT Mgr_fkey REFERENCES Emp_tab, Hiredate DATE, Sal NUMBER(7,2), Comm NUMBER(5,2), Deptno NUMBER(3) NOT NULL CONSTRAINT dept_fkey REFERENCES Dept_tab ON DELETE CASCADE); 27

???????????????? 28

Erroneous Relationship Receives or summarize the data, transfer, translate or calculate data 29