Information Technology Reference
In-Depth Information
XML Document
DTD Graph
DTD Graph
XML Document
<Student
Sid = “S01”
Home = “RM 111”
Home_Phone = “25111222”
/Student>
<Student
Sid = “S02”
Home = “RM 111”
Home_Phone = “25111222”
/Student>
Sid
Home
<Address
Home = “RM 111”
Home_Phone = “25111222”>
<Student
Sid = “S01”/>
<Student
Sid = “S02”/>
Student
Address
Home
Home Phone
Home Phone
</Address>
Sid
Student
a
b
Fig. 9.16 An XML document a without BCNF, b in BCNF
For example: Fig. 9.16 a shows the resultant non-BCNF element definition trans-
formed from a non-BCNF object type. Due to the original object type is not in BCNF,
an XML document may suffer from redundancy caused by non-key FDs. In this
case,itistheFDHome→HomePhonethatcausestheredundancy.Decomposing
the object type results in two BCNF object types and their corresponding element
definitions are shown in Fig. 9.16 b. Note that the redundancy has been removed.
Case Study:
The following shows data requirements and its data semantics in brackets:
(a) Employee can be a spouse of another employee (unary relationship).
(b) A department has only one department head (one-to-one relationship).
(c) An instructor may be under a department (partial participation).
(d) An instructor can be either Full Time or Part Time (disjoint generalization).
(e) A full time instructor has a retirement plan (one-to-one relationship).
(f) A part time instructor has an hourly wage (one-to-one relationship).
(g) A course consists of lectures and laboratories (aggregation).
(h) Many courses are taught by many instructors (many-to-many cardinality).
(i) A tutor is tutoring students for a course (ternary relationship).
(j) A tutor can either be a lecturer or a professor (disjoint generalization).
(k) An employee can both be an instructor and a department head (overlap gen-
eralization).
Figure 9.17 provides sample data occurrences with data redundancy illustrated
Search WWH ::




Custom Search