Schema Translation - Information Systems Reengineering, Integration and Normalization - page 111

6WHS
5HYHUVH
(QJLQHHULQJ

6WHS
6FKHPD
7UDQVODWLRQ

5HODWLRQDO
6FKHPD

&RQFHSWXDO
(550RGHO

;0/'7'
'7' *UDSK

Fig. 3.40 Architecture of translating schema from relational into XML

In order to solve the problem due to this structural difference, an arbitrary XML
view, a database object, has to be created in order to start the branching from root.
Branching from this root element are the basic classes and various constraints,
included in the DTD-graph specification. To prepare for the transformation, the
non-ordered DTD-graph node diagram must be replaced with a listing of all re-
lated components in the entity diagram. This process is “decomposition.” With the
component list, a process sequence is drawn to transform each kind of DTD-graph
component into its XML correspondence of DTD. The structural difference prob-
lem could be solved.
Figure 3.40 shows the general architecture of reengineering relational schema
into XML schema DTD.
By following the procedure in Fig. 3.40 , we translate a relational schema into an
XML schema based on a selected XML view, and then load relational data into an
XML schema. It consists of three steps:

1. Reverse engineering a relational schema into an EER model.
2. Schema translation from an EER model into a DTD-graph and DTD.
3. Data conversion from relational database to XML documents.

Step 1—Reverse engineering a relational schema into an EER model.
By use of classification tables to define the relationship between keys and at-
tributes in all relations, we can recover their data semantics in the form of an EER
model. Refer to Sect. 3.5 for details.
Step 2—Schema translation from EER model into a DTD-graph and DTD.
We can map the data semantics in the EER model into a DTD-graph according to
their data dependencies constraints. These constraints can then be transformed into
a DTD as an XML schema as shown in the following:

Rule 1: Deine an XML View Root Element in DTD
To select an XML view of the source relational schema as a root element, its rel-
evant information must be transformed into an XML logical schema including the
selected entity and all its relevant entities that are navigable.
Navigability specifies the feasibility of the traversal from an entity to its related
entities. The relationship can be directional with navigability. The process is similar
to the process when we walk the tree structure of a DTD-graph. We navigate each
relationship, then each relationship from the children table of the previous relation-
ships and so on.