2C.1 Relational Database Desi g n L L E E S S S S O O N N : : 2 2 C C C C O O L L L L A A B B O O R R A A T T E E Relational Database Desi g n 2C.2 2C.3 Relational Database Desi g n K K N N O O W W L L E E D D G G E E B B Y Y T T E E Collaborate Lesson 2C / Slide 1 of 25©NIIT Collaborate Knowledge Byte In this section, you will learn about the following: • Domains • Fourth Normal Form • Other Normal Forms In this section, you will learn about the following: Domains Fourth Normal Form Other Normal Forms Relational Database Desi g n 2C.4 Domains Collaborate Lesson 2C / Slide 2 of 25©NIIT Collaborate Domains • A domain is a set of data values that are of the same type. • Every value in an attribute must be drawn from the underlying domain. However, every value in the domain may not appear in the table. • Domains are primarily conceptual and no current RDBMS supports this concept in the complete sense. • A relation is a collection of domains and consists of two parts, a heading and a body. • A change in a relation implies that either a new domain is added to the collection of existing domains, or a domain that originally defined the relation no longer exists. A domain is a set of data values that are of the same type. In other words, a domain is a pool of values from which the actual values for an attribute are drawn. For example, consider a domain CITIES that contains the names of all cities. CUSTOMER and PRODUCT are two tables, both of which have an attribute that holds the names of cities. Attribute CITY in the CUSTOMER table holds the names of cities where the customers are based. Attribute CITY in the PRODUCT table holds the names of the cities where the products are manufactured. Both these attributes draw their values from the CITIES domain. 2C.5 Relational Database Desi g n Domains and Attributes Every value in an attribute must be drawn from the underlying domain. However, every value in the domain may not appear in the table. In the above figure, some cities that are in the domain do not exist in the attributes. However, later, any of these values may exist in the attributes as they are valid values. Domains are primarily conceptual and no current RDBMS supports this concept in the complete sense. A relation is a collection of domains and consists of two parts, a heading and a body. The heading part consists of a fixed set of attributes. The body part consists of rows that may change with time. The attributes of a relation are fixed. If an attribute is added or an existing attribute is removed from a relation, the relation is no longer the same. Such a change implies that either a new domain is added to the collection of existing domains, or a domain that originally defined the relation no longer exists. CITY New York Dallas Texas PRODUCT New York San Francisco Miami Dallas Miami San Francisco Las Vegas Texas New York Washington Disneyland Hollywood Philadelphia CUSTOME R PRODUCT DOMAIN: CITIES Relational Database Desi g n 2C.6 Fourth Normal Form Collaborate Lesson 2C / Slide 3 of 25©NIIT Collaborate Fourth Normal Form • If a relation has many-to-many relationships with two or more relations, then the attributes of all the three or more relations cannot be depicted in the same relation. • When you model such situations in a relational database, you will either have redundant data or use null values. • A condition that requires duplication of values and thus enforces mutual independence of multivalued attributes is called multivalued dependency. 2C.7 Relational Database Desi g n Collaborate ©NIIT Collaborate Fourth Normal Form (Contd ) • You can use fourth normal form (4 NF) to remove multivalued dependencies. • A table is in 4 NF if it is in 3 NF and has no multivalued dependencies. • To apply 4 NF, you need to put all multivalued attributes in individual tables containing the key to which the attribute values apply. Lesson 2C / Slide 4 of 25 According to 1 NF, a relation cannot have multivalued attributes. This means that for one value of an attribute there cannot be multiple values of another attribute. However, in real world, there might be situations where multivalued attributes are required. For example, in a university, a faculty member is assigned multiple courses and committees. Also, in a health insurance system, an employee has many dependents. When you model such situations in a relational database, you will either have redundant data or null values. For example, for the university database, the following figure depicts the FACULTY table that uses the above concept. FACULTY FACULTY- NAME COURSE COMMITTEE Chris 125 Admissions Chris 125 Examinations Chris 126 Admissions Relational Database Desi g n 2C.8 FACULTY- NAME COURSE COMMITTEE Chris 126 Examinations Chris 127 Admissions Chris 127 Examinations Table with Multivalued Dependency Such a condition that requires duplication of values and thus enforces mutual independence of multivalued attributes is called multivalued dependency. Multivalued dependency is a constraint on tables like functional dependency. It is clear that multivalued dependency requires duplication of data values. Therefore, in normalization, you need to remove multivalued dependencies. To do this, you can use the fourth normal form (4 NF). A table is in 4 NF if it is in 3 NF and has no multivalued dependencies. To apply 4 NF, you need to put all multivalued attributes in individual tables containing the key to which the attribute values apply. The above table can be normalized as follows: FAC-COURSE FACULTY- NAME COURSE Chris 125 Chris 126 Chris 127 FAC-COMMITTEE FACULTY- NAME COMMITTEE Chris Admissions Chris Examinations 4 NF Tables Both the above tables are in 4 NF because the multivalued attributes, COURSE and COMMITTEE, are now in tables by themselves. The primary keys of each of the above tables consist of both the attributes present in the table. This means that the primary key 2C.9 Relational Database Desi g n of the FAC-COURSE table consists of FACULTY-NAME and COURSE. The primary key of the FAC-COMMITTEE table consists of the FACULTY-NAME and COMMITTEE. Other Normal Forms Collaborate ©NIIT Collaborate Other Normal Forms • Some constraints like business rules result in the need for fifth normal form (5 NF). • For a table to be in 5 NF, it has to be in 4 NF and should abide by some business rules. • The purpose of 5 NF is to have tables that cannot be further decomposed. • If the business rule does not exist, then there is no need of 5 NF. • In addition to 5 NF, there is another normal form called the domain-key normal form (DKNF). • A table is in DKNF if every constraint on the table is a result of the definitions of domains and keys. Lesson 2C / Slide 5 of 25 The normal forms 2 NF, 3 NF, and 4 NF are the results of functional dependency and multivalued dependency. There are some other constraints like business rules that result in the need for fifth normal form (5 NF). For a table to be in 5 NF, it has to be in 4 NF and should abide by some business rules. The purpose of 5 NF is to have tables that cannot be further decomposed. Let us now understand 5 NF with an example. Relational Database Desi g n 2C.10 Consider the following table: This table indicates that the Computer Science department offers the subjects CS150, CS103, and CS104. These subjects are taken by different students. Here, the business rule is that a subject cannot be taken by all the students and a student cannot take all the subjects. The above table does not illustrate multivalued dependency because the columns SUBJECT and STUDENT are not independent. Both these columns are related to each other and have important information in them. Therefore, this table cannot be decomposed in the following two tables without losing information about the subjects taken by a student. DEPT-SUB (DEPARTMENT, SUBJECT) DEPT-STUD (DEPARTMENT, STUDENT) However, we can decompose the above table in the following three tables without losing any information. DEPT-SUB Department Subject Mathematics MA520 Computer Science CS150 Computer Si CS103 Department Subject Student Mathematics MA520 Ron Floyd Computer Science CS150 Nancy Drew Computer Science CS103 Charlie Burton Computer Science CS104 Ron Floyd Chemistry CH894 Chris Laurel Physics PH654 Mary Peterson [...]... the given table structure to optimize data storage Collaborate Relational Database Design Lesson 2C / Slide 13 of 25 2C.22 Collaborate Challenge (Contd ) The table structure is as follows: Position cPositionCode vDescription iBudgetedStrength siYear iCurrentStrength vSkill ©NIIT 2C.23 Collaborate Lesson 2C / Slide 14 of 25 Relational Database Design Collaborate Challenge (Contd ) Sample data for the... database Collaborate Lesson 2C / Slide 18 of 25 Relational Database Design Collaborate Challenge (Contd ) 7 ©NIIT Which of the following rules should be followed to create a good database design? a Each table should have an identifier b Columns that accept NULLs should be avoided c Each table should store data for multiple types of entities d The repetition of values or columns should be avoided Collaborate. .. only a single part.” What type of relationship is this? Draw an E/R diagram to depict the relationship Collaborate Solutions to Challenge 1 Entities: SUPPLIER, PARTS Relationship: SHIP (or SHIPMENT) SHIP SUPPLIERS ©NIIT Collaborate Relational Database Design PARTS Lesson 2C / Slide 22 of 25 2C.34 Collaborate Solutions to Challenge (Contd ) 2 Use normalization and break the table as follows: Position... affected or you might lose data integrity Therefore, to avoid these risks, it is better to use 3NF However, if the above risks can be avoided, you can use BCNF ©NIIT Collaborate Relational Database Design Lesson 2C / Slide 10 of 25 2C.18 Collaborate FAQs (Contd ) Q What is the difference between a weak entity and a subentity? Ans: A weak entity depends upon a regular entity for its existence whereas... entity from which it is derived A weak entity on the other hand has attributes that are different from those of the regular entity on which it is dependent ©NIIT 2C.19 Collaborate Lesson 2C / Slide 11 of 25 Relational Database Design Collaborate FAQs (Contd ) Q What is the difference between a subtype and a supertype? Ans: The difference between a subtype and a supertype entity is best understood with... result of the definitions of domains and keys Relational Database Design 2C.12 FROM THE EXPERT’S DESK Collaborate From the Expert’s Desk • ©NIIT This section will introduce the following: • Best practices for the primary key • Tip on generalization • FAQs on data models, E/R diagrams, and normalization Collaborate Lesson 2C / Slide 6 of 25 In this section, you will learn about best practices for the primary... 18 Team Leading MS- Office Interpersonal 20 20 20 18 18 18 Communication Team Leading Presentation 21 18 Convincing Collaborate Relational Database Design Communication Presentation Team Leading Communication Presentation Convincing Planning Communication Lesson 2C / Slide 15 of 25 2C.24 Collaborate Challenge (Contd ) 3 4 ©NIIT 2C.25 State whether true or false: Attributes may acquire further attributes... and printed in the salary slip The following three tables are used for this query- MonthlySalary, Employee, and EmployeeReferrals The table structures are as follows: Collaborate Lesson 2C / Slide 16 of 25 Relational Database Design Collaborate Challenge (Contd ) Employee cEmployeeCode vFirstname vLastName cCandidateCode vAddress cCity cZip cCountryCode cPhone vQualification dBirthDate cSex cCurrentPosition... dResignationDat e cSocialSecurityN o ©NIIT MonthlySalary cEmployeeCode mMonthlySalary dPayDate EmployeeReferr als cEmployeeReferrr alNo cEmployeeCode cCandidateCode Collaborate Relational Database Design Lesson 2C / Slide 17 of 25 2C.26 Collaborate Challenge (Contd ) 5 6 ©NIIT 2C.27 However, since the table structures are large, it is necessary to improve the performance of this query by modifying the... models, E/R diagrams, and normalization 2C.13 Relational Database Design Best Practices Primary Key Collaborate Best Practices Primary Key • The primary key should be numeric • The primary key should have only one column • The primary key should not change over time • The primary key should be meaningless ©NIIT Collaborate Lesson 2C / Slide 7 of 25 Some best practices that you can follow for the primary . Relational Database Desi g n K K N N O O W W L L E E D D G G E E B B Y Y T T E E Collaborate Lesson 2C / Slide 1 of 25©NIIT Collaborate Knowledge Byte In this section, you will learn about the following:. Normal Form Other Normal Forms Relational Database Desi g n 2C.4 Domains Collaborate Lesson 2C / Slide 2 of 25©NIIT Collaborate Domains • A domain is a set of data values that are of the same. CUSTOME R PRODUCT DOMAIN: CITIES Relational Database Desi g n 2C.6 Fourth Normal Form Collaborate Lesson 2C / Slide 3 of 25©NIIT Collaborate Fourth Normal Form • If a relation has many-to-many relationships