We shall represent a relation as a table with columns and rows. Each column of the table has a name, or attribute. Each row is called a tuple.

Transcription

1 Logical Database design Earlier we saw how to convert an unorganized text description of information requirements into a conceptual design, by the use of ER diagrams. The advantage of ER diagrams is that they force you to identify data requirements that are implicitly known, but not explicitly written down in the original description. Here we will see how to convert this ER into a logical design (this will be defined below) of a relational database. The logical model is also called a Relational Model. We shall represent a relation as a table with columns and rows. Each column of the table has a name, or attribute. Each row is called a tuple. Domain: a set of atomic values that an attribute can take Attribute: name of a column in a particular table (all data is stored in tables). Each attribute A i must have a domain, dom(a i ). Relational Schema: The design of one table, containing the name of the table (i.e. the name of the relation), and the names of all the columns, or attributes. Example: STUDENT( Name, SID, Age, GPA) Degree of a Relation: the number of attributes in the relation's schema. Tuple, t, of R( A1, A2, A3,, An): an ORDERED set of values, < v1, v2, v3,, vn>, where each v i is a value from dom( A i ). Relation Instance, r( R): a set of tuples; thus, r( R) = { t1, t2, t3,, tm} Attributes dom(gpa) = [0.0, 12.0] dom( Name) = character string, max length 100. Name SID Age GPA CHAN Kin Ho LAM Wai Kin MAN Ko Yee LEE Chi Cheung Each row is one tuple; This instance of schema STUDENT has 5 tuples t3 = <MAN Ko Yee, , 21, 7.5> Alvin LAM

2 NOTES: 1. The tuples in an instance of a relation are not considered to be ordered putting the rows in a different sequence does not change the table. 2. Once the schema, R( A1, A2, A3,, An) is defined, the values, v i, in each tuple, t, must be ordered as t = <v1, v2, v3,, vn> Integrity Constraints Each relational schema must satisfy the following four types of constraints. A. Domain constraints Each attribute Ai must be an atomic value from dom( Ai) for that attribute. The attribute, Name in the example is a BAD DESIGN (because sometimes we may want to search a person by only using their last name. B. Key Constraints Superkey of R: A set of attributes, SK, of R such that no two tuples in any valid relational instance, r( R), will have the same value for SK. Therefore, for any two distinct tuples, t1 and t2 in r( R), t1[ SK]!= t2[sk]. Key of R: A minimal superkey. That is, a superkey, K, of R such that the removal of ANY attribute from K will result in a set of attributes that are not a superkey. Example CAR( State, LicensePlateNo, VehicleID, Model, Year, Manufacturer) This schema has two keys: K1 = { State, LicensePlateNo} K2 = { VehicleID } Both K1 and K2 are superkeys. K3 = { VehicleID, Manufacturer} is a superkey, but not a key (Why?). If a relation has more than one keys, we can select any one (arbitrarily) to be the primary key. Primary Key attributes are underlined in the schema: CAR( State, LicensePlateNo, VehicleID, Model, Year, Manufacturer)

3 C. Entity Integrity Constraints The primary key attribute, PK, of any relational schema R in a database cannot have null values in any tuple. In other words, for each table in a DB, there must be a key; for each key, every row in the table must have non-null values. This is because PK is used to identify the individual tuples. Mathematically, t[pk]!= NULL for any tuple t r( R). D. Referential Integrity Constraints Referential integrity constraints are used to specify the relationships between two relations in a database. Consider a referencing relation, R1, and a referenced relation, R2. Tuples in the referencing relation, R1, have attributed FK (called foreign key attributes) that reference the primary key attributes of the referenced relation, R2. A tuple, t1, in R1 is said to reference a tuple, t2, in R2 if t1[fk] = t2[pk]. A referential integrity constraint can be displayed in a relational database schema as a directed arc from the referencing (foreign) key to the referenced (primary) key. Examples are shown in the figure below: EMPLOYEE ENo Name Address DeptNo SupENo DEPT Dno DName Locn MgrENo

4 ER-to-Relational Mapping Now we are ready to lay down some informal methods to help us create the Relational schemas from our ER models. These will be described in the following steps: 1. For each regular entity, E, in the ER model, create a relation R that includes all the simple attributes of E. Select the primary key for E, and mark it. 2. For each weak entity type, W, in the ER model, with the Owner entity type, E, create a relation R with all attributes of W as attributes of W, plus the primary key of E. [Note: if there are identical tuples in W which share the same owner tuple, then we need to create an additional index attribute in W.] 3. For each binary relation type, R, in the ER model, identify the participating entity types, S and T. For 1:1 relationship between S and T Choose one relation, say S. Include the primary key of T as a foreign key of S. For 1:N relationship between S and T Let S be the entity on the N side of the relationship. Include the primary key of T as a foreign key in S. For M: N relation between S and T Create a new relation, P, to represent R. Include the primary keys of both, S and T as foreign keys of P. 4. For each multi-valued attribute A, create a new relation, R, that includes all attributes corresponding to A, plus the primary key attribute, K, of the relation that represents the entity type/relationship type that has A as an attribute. 5. For each n-ary relationship type, n > 2, create a new relation S. Include as foreign key attributes in S the primary keys of the relations representing each of the participating entity types. Also include any simple attributes of the n-ary relationship type as attributes of S.

5 Formal Relational Database Design We have seen the informal procedure to map the ER model into a logical model (relational database schema). How do we know that this is a good schema? We shall now study the formal theory which can help us to understand (a) what is a good relational database design, (b) why it is good, and (c) how do we design good relational database schemas. To do so, we shall learn the concepts of Functional dependencies and Normal forms. We shall use our EMPLOYEE-DEPARTMENT-PROJECTS example. To give us some motivation, let us first see what kinds of problems can arise if we fail to design the database properly. 1. Redundant Information in Tuples and Update Anomalies Consider a (poorly) designed database where the Employee and Department information is planned in one table, and the Employee and Project information in another table: EMPLOYEE_DEPT SSN LName Address DNumber DName BDate MgrSSN EMPLOYEE_PROJ SSN PNumber Hours LName PName PLocation Problems: (a) Information is stored redundantly -- repeated information wasted storage. For example, if 5 employees work for Department number 4, then the department name and manager's SSN for Department 3 is stored 3 times in the table.

6 (b) Insertion anomalies. When we enter the record for a new employee, we must specify ALL data fields for his department correctly. For example, if a new employee joins Dept 5, then we must ensure that the data entered for Dept 5 in the new record is consistent with the data for Dept 5 in all earlier records of other employees of Dept 5. (c) Deletion Anomalies. If a dept has one employee working in it, and we delete the information of this employee, then the information of the department is also lost. We may not want this to happen. (d) Modification Anomalies. If we modify a value, we must make the entire table consistent very carefully. For example, if an employee changes departments from Dept 5 to Dept 4, then his entire record must be changed, not just his DNumber field. If a department changes its manager, the entire table must be scanned and modified. In other bad DB designs, several other problems can occur. The most important ones include the following: 2. Null values in Tuples Consider a DB design: STUDENT( SID, Name, Phone, , SocietyName, MembershipNo) which is used to store student information. For all students who did not join any society, the last two attributes will contain NULL values. If there are many such students, then this will be considered as a poor DB design, and it would be better to store information in two relational schemas: STUDENT( SID, Name, Phone, ), MEMBERSHIP( SID, SocietyName, MembershipNo). In general, we should design tables which have the fewest NULL value entries. If an attribute has NULL value very frequently in a table, it should be placed in a separate table (along with the primary key). 3. Spurious (false) Tuples To avoid anomalies and null values in tuples, most DBs must be designed to store data by using several tables. However, at any given time, we may need some information that is partly contained in two or more different tables. When we combine the information contained in two separate tables, in other words, when we JOIN the two tables, some care must be taken, other wise we may get some misleading (or FALSE) information. I will illustrate the problem of spurious tuples with the example of a poorly designed Projects-Parts- Suppliers database:

7 PROJECT_PARTS SUPPLIER_PARTS ProjectNo PartNo SupplierNo PartNo Qty Proj1 P1 S1 P1 10 Proj2 P1 S2 P2 25 Proj2 P2 S2 P1 20 Suppose we are interested to know: Which suppliers supplied the parts for Proj2? Obviously this information can only be obtained by somehow combining the information in the two tables (why?). The common link between the two tables is the PartNo (assume that PartNo uniquely identifies the part). From PROJECT_PARTS, we can easily see that Proj2 uses P1 and P2. P2 is supplied by S2 (from tuple-2 of SUPPLIER_PARTS). However, which supplier supplied P1 to Proj2? If we match the PartNo in tuple-2 of PROJECT_PARTS with PartNo in SUPPLIER_PARTS, then we get two matches: tuple-1 S1, and tuple-3 S2. However, from this, we cannot conclude that both S1 and S2 supplied parts P1 to Proj2 (why?). In the above example, we say that JOINING the information of the two tables created some false information; in other words, if we use the above DB design to store data, some information that we know is actually getting lost. We call such JOIN s that create information loss as LOSSY-JOINS. A good database design must guarantee LOSSLESS JOIN operations on its tables. The above examples are obviously simple; however, a real DB may have tens of tables, with many attributes in each. Some tables may have created as an extension of a previously existing DB. How can we guarantee that the DB will not have any possibility of such errors? There is a logical process that allows us to design good databases: it is called normalization. We now study normalization. Functional Dependencies Normalization depends on identifying logical relationships between data, called Functional dependencies (FDs), and Keys. FDs are constraints between the attributes of relations in the universe of discourse.

8 Definition: A set of attributes, X, functionally determines a set of attributes Y if the value of X determines a unique value for Y. This is written as: X Y. The implication of the statement X Y is that, for any two tuples, t1 and t2, if t1[ X] = t2[ X], then t1[ Y] = t2[ Y]. Examples of FD's: {SSN} {Employee name} {Employee SSN, Project Number} {Hours per week} If K is a key of R, then K functionally determines all attributes of R. Inference Rules for FD's Given a set of FDs, we can infer other FDs that will also be true. Such inference requires proof, based on the use of the above definition of FD, and some logical reasoning. Armstrong's Inference Rules: A1. (Reflexive). If Y X, then X Y A2. (Augmentation). If X Y, then XZ YZ (Note: XZ denotes X U Z, the union of the sets of attributes X and Z). A3. (Transitive). If X Y and Y Z, then X Z Using A1, A2 and A3, we can also prove some additional useful inference rules: A4. (Decomposition). If X YZ, the X Y and X Z A5. (Union). If X Y and X Z, then X YZ A6. (Pseudotransitive). If X Y and WY Z, then WX Z

9 Equivalence of sets of FDs: Two sets of FDs, F and G are said to be equivalent if every FD in F can be inferred from G, and every FD in G can be inferred from F. Minimal set of FDs: A set of FDs is minimal if it satisfies the following conditions. (a) Every dependency in F has a single attribute for its RHS (right hand side). (b) We cannot remove any dependency from F, and have a set of dependencies equivalent to F. (c) We cannot replace any dependency, X A, in F with a dependency, Y A, where Y X, and still have a set of dependencies equivalent to F. In general, we know the following to be true: (1) Every set of FDs has an equivalent minimal set; and (2) There can be several equivalent minimal sets. The First Normal Form (1NF) A relational schema is in 1NF if it does not contain any composite attributes, multi-valued attributes, and nested relations. It is possible to convert any schema that is not in 1NF into one or more schemas that are in 1NF: STUDENT_COURSES Composite Multi-valued SID 0401 Name John Smith SemYr Fall 05 Courses ie110, ie215 Not 1NF 0402 Jane Doe Fall 05 ie110, ie317 STUDENT_COURSES_1NF SID Lname Fname Sem Yr Course 0401 Smith John Fall 05 ie Smith John Fall 05 ie215 1NF 0402 Doe Jane Fall 05 ie Doe Jane Fall 05 ie317

10 EMPLOYEE_PROJECTS Composite Projects SSN Lname Fname ProjNo Hours 1123 Smith John P1 P Not 1NF 3312 Doe Jane P2 P EMPLOYEE EMP_PROJECTS SSN Lname Fname SSN ProjNo Hours 1123 Smith John 1123 P Doe Jane 1123 P2 5 1NF P2 P Second Normal Form (2NF). 2NF uses the concepts of FDs and the primary key. Definitions: Prime Attribute: An attribute that is a member of the primary key. Full functional Dependency: A FD, Y Z, where the removal of ANY attribute from Y means that the FD will not hold true any more. Examples: {SSN, PNumber} Hours is a Full FD, since neither {SSN} Hours, nor {PNumber} Hours is true. {SSN, PNumber} EName is NOT a Full FD, since {SSN} EName is also true. Second Normal Form: A relational schema, R, is in 2NF if every non-prime attribute A in R is fully functionally dependent on the primary key.

11 Consider a DB storing information about employees, projects, and what project each employee works on. The schema EMP_PROJ below attempts to store all this data in one table. The arrows denote the FD s in the schema. You can easily check that a table constructed with this schema will result in many anomalies. We can use the definition of 2NF above to break this schema into a set of three schemas which are in 2NF. EMP_PROJ SSN Pnumber Hours EName PName PLocation EMP_PROJ1 SSN PNumber Hours EMP_PROJ2 SSN EName EMP_PROJ3 PNumber PName PLocation The Third Normal Form ( 3NF) The third normal form ensures that a schema design does not contain any transitive FD s. Transitive Functional Dependency is an FD Y Z that can be derived from two FDs Y X and X Z. Examples: SSN MgrSSN is a transitive dependency, because SSN DNumber, and DNumber MgrSSN. SSN LName is NOT a transitive dependency, since there is no attribute X, such that SSN X, and X LName. Third Normal Form: a relational schema is in 3NF if it is in 2NF, and no non-prime attribute A in R is transitively dependent on the primary key.

12 Below is an example of a schema that is not in 3NF, and how to decompose it into a pair of 3NF relational schemas. EMP_DEPT SSN EName Address Dno DName MgrSSN EMP_DEPT1 SSN EName Address Dno EMP_DEPT2 DNo DName MgrSSN For most applications, achieving 3NF as defined above will provide an acceptable logical design. However, note that the entire process above is dependent on the (arbitrary) selection of primary keys from all possible candidate keys. There is a broader definition of 3NF which considers the existence of multiple candidate keys. General Normal Form Definitions The general 1NF definition is identical to the one before. A relational schema is in 2NF if it is in 1NF, and if every non-prime attribute A in R is fully functionally dependent on every key of R. The general 3NF definition requires our earlier definition of superkeys ( a superkey of R is a set of attributes which contain a key of R). A relational schema R is in 3NF if whenever a FD X A holds in R, then either X is a superkey of R, or A is a prime attribute of R.

13 Example: Consider a simplified database for Government records on land sales in different districts. Each lot of land has a unique ID number for the territory. Within each district, each lot is also assigned a lot#, which is unique in the district. Further, the tax rate to be paid is determined by the district. Finally, the government controls the cost of land to be uniform across the territory, so that the price can be determined by the area of the lot. LOTS PropertyID District Lot# Area Price TaxRate 1NF FD1 FD2 FD3 FD4 LOTS1 PropertyID FD1 FD2 District Lot# FD4 Area Price 2NF LOTS2 District TaxRate 3NF LOTS1A LOTS1B PropertyID FD1 FD2 District Lot# Area Area Price Notice: there are two candidate keys: { PropertyID} and { District, Lot#}. 2NF: TaxRate is partially dependent upon the candidate key { District, Lot#}, due to FD3. Hence we break this schema into two parts to achieve 2NF, as shown.

14 3NF: LOTS2 is already in 3NF according to the general definition. However, LOTS1 violates the general definition of 3NF, since by FD4, Area -> Price. However, (a) Area is not a superkey of LOTS2; AND, (b) Price is not a prime attribute of LOTS2. Therefore we further break LOTS1 into LOTS1A and LOTS1B to achieve 3NF. Acknowledgements: The notes have been based (with minor modifications) on lecture notes of Prof Navathe, as distributed by Dr. Kamal Karlapalem for COMP231, HKUST.