There are usually two types of forms: template drivers and mode drivers.
1 template driver
In a template-driven map, there is no mapping between the document structure and the database structure in advance, but is used to use the method of embedding the template within the command statement, let the data transmission middleware processes the template. For example, the following template is embedded in the element:
The Following Flights Have Available Seats:
SELECT Airline, FltNumber, Depart, Arrive from
Flights
We Hope One of these Meets Your Needs
When the data transmission middleware processes the document, each Select statement will be replaced by the respective execution results to get the following XML format:
The Following Flights Have Available Seats:
ACME
123
DEC 12, 1998 13:43
DEC 13, 1998 01:21
...
We Hope One of these Meets Your Needs
This map-driven mapping can be flexible. For example, some products allow you to replace the content you want (including parameters in Select) in any result set, not simply simply in the example above. In addition, it also supports the use of programming, such as cyclic and conditional judgment structures. There are also a parameterization of the SELECT statement, such as passing the parameters by HTTP.
Currently, the template-driven mapping only supports the conversion from a relational database into an XML document.
2 model driver
In a model-driven map, the data model corresponding to the XML document structure will be explicitly or implicitly mapped into the structure of the database, and vice versa. Its disadvantage is that flexibility is not enough, but it is easy to use because it is based on a specific data model to map, and it is usually possible to achieve many conversion work for users. Since the result of converting data from the database into XML, according to the single model,
Therefore, in this manner, in this manner, the flexibility in the system of the template-driven system is typically combined.
Data views in XML documents typically have two models: Table models and specific data object models. Other models may sometimes appear. For example, by adopting ID and IDREF properties, an XML document can be used to specify a graphic. However, many existing middleware do not support these models.
2.1 Table Model
Many middleware packages are converted between XML and relational databases. It looks like an XML model as a single table or a series of forms. That is, the structure of the XML document is similar to the following example, where in the case of a single table, does not appear:
...
...
...
...
...
The term "table" is understood to be a single result set (when converting data from the database), or a separate table or updatable view (when converting data from XML). If the data needs from multiple result sets (when the data is from the database) or a collection of a series of tables (when the data to the database) is reached, the XML document contains a deeper nesting element, then similar The conversion is almost impossible.
2.2 Specific Data Object Model
The second universal data model in the XML document is a tree structure of a particular data object. In this model, the element type usually corresponds to the object, and the content model, attribute, and PCDATA in XML correspond to the properties of the object. This model directly maps to object-oriented databases and hierarchical databases, of course, with traditional object-relational mapping technology and SQL
3 Generate DTD and its mutual inverse process from the structure of the database
When converting data between XML documents and databases, a universal problem is: How to generate XML DTD from the structure of the database, if the database is generated from the XML DTD. In short, this is a very direct operation, but the resulting result is usually some distance from the expectations of many users.
(Note that this is usually one-time operation, while most applications, especially all vertical applications combine the collection of known DTDs and relational SCHEMAs. Obvious special case is to store random XML documents in relational databases or Publish relational data into an XML document; in the back, DTD is not obvious.)
Each of the types of a single value and a sub-element type containing only PCDATA content are newly created a column (field) in this table. If the child element type or attribute is optional, the field is allowed to be empty.
For each multi-value attribute or more only the child element type of PCDATA content, a separate table is established to save their values, and the primary keywords of their parent tables are connected to the parent table.
For each sub-element, these sub-elements itself include elements or mixed content, using keywords in the parent table to the child element table.
The following is a process that generates an XML document from the structure of the relational database (simplified):
For each Table, create a new element.
Each of the columns in the table establish an attribute or only a child element containing PCDATA
For each column containing the main key value in the primary key / foreign key, create a new child element.
For example, the following process (simplified) describes how to generate a relational structure from one DTD:
For each element type containing an element or mixed content, a new table and a primary key field.
For each element type containing the mixed content, create a separate table, where the data is stored, and links to the parent table through the parent element master key.
Each single-value attribute for this element is and only the resulting data content, only one sub-elements appear, and a field is created in the table. If the element type or attribute is optional, you can set the field as a null value.
For each multi-value attribute and multiple sub-elements, create a separate table to store values, and link to the parent table through the parent element master key.
The parent element table and sub-element table are connected to each of the sub-elements of each element or mixed.
The following process (simplified) describes how to generate a DTD from a relational structure:
For each form, create a new element;
For each field in the table, create a new property or a sub-element that contains the data.
The relationship between the primary key / foreign key to provide the primary key in each table field is new.
Unfortunately, there are still some defects in these processes. For example, there is no method in the DTD predetermined data type or field length. Because any pre-definition (eg, by reading a document or other document containing more "type" documents or other documents, an error is generated when reading a document that exceeds the word length content. (Long-term strategy is to use the data type of XML Schema document.) Simply, when Generating DTD from a relational structure, there is no way to pre-determine the order or field of the child element "should" appear (such as line identification inside the database) Whether it is fully converted.
Name conflicts may occur in both cases.
Although there is such a defect, these methods can still be well laid a starting point between relational structure and DTD.
