Database Reference
In-Depth Information
multivalue dependency, interrelation dependency, and intravalue dependency, except time-related
dependency. hese rules can be identiied by examining business requirements and restrictions.
he above DK/NF deinition says that by enforcing the key constraints and domain constraints,
all the constraints on the table should be automatically enforced.
he procedure to create a DK/NF table starts with the determination of business require-
ments and constraints observed from a business process. hen, all the business requirements
will be fulilled by enforcing the keys and domains in the tables. Even though the DK/NF
converting process is complicated and is depending on the speciic requirements of a business
process, proper use of the DK/NF converting process will help you understand the database
design t heor y.
3.3.3 Denormalization
For a database used in a decision support system, fully normalized DK/NF tables may not always
be desirable. In a decision support system, the data in a table are rarely modiied. he main task for
a decision support system is to search for data that meet certain criteria. Using not fully normal-
ized tables can improve search performance. For example, by using the STUDENT_CLASS table
displayed in Table 3.3, once a student is selected based on a given student ID, you will get other
information about the student, such as the student's advisor and the grades for his/her classes,
at the same time. If tables with a higher level of normalization are used, the search will have to
go through tables such as STUDENT, STUDENT_CLASS, CLASS, FACULTY_CLASS, and
FACULTY to get the information that meets a given search criterion. For the purpose of informa-
tion presentation, it is better to use the STUDENT_CLASS table in Table 3.3 so that the faculty
and class information related to a student can be retrieved at once without searching other tables.
In general, for a decision support system, you can get information faster if low-level normalization
tables are used.
In this section, we have looked at the normalization process. After the table structures are
normalized, we are ready to convert the data model to a relational database.
3.4 Transferring Data Model to Relational Database
In the previous sections, you learned how to get better structured tables by using normalization.
his section is about converting a data model to a relational database.
A data model consists of components such as entities, attributes, and relationships. In the
process of transforming a data model to a relational database, you need to represent these compo-
nents with corresponding objects in a relational database. With the selected database management
system (DBMS), you can transform a data model to a relational database by performing the fol-
lowing tasks:
◾
Represent the entities as tables in a relational database.
◾
Represent the attributes as columns.
◾
Represent the relationships with foreign keys and primary keys.
◾
Specify domains by enforcing constraints on columns when creating tables with a DBMS.
In the following subsections, you will accomplish these tasks.
