The accompanying example exhibits an uncomplicated well fashioned XML file. It could be entered by using a basic text editor and also one of the XML editors that you can buy. Whenever composing the document away, the file-name should certainly end with .xml. For example: “human.xml” or “yourFileName.xml”.
[human]
[gender]
male
[/gender]
[born]
18 July 1990
[/born]
[hairColour]
Blonde
[/hairColour]
[/human]
Inside illustration previously mentioned, the [human] ... [/human] element includes three other elements and each of these consist of textual content. Because the three elements happen to be between your opening and closing human element tags it means that they will be 'child elements' of human.
These child elements give to us particular information on the parent element. In this situation this lets us know that the human is "male", was born "18 July 1990" and has "Blonde" hair. XML permits us to structure our data collections in a very logical, hierarchy that makes sense.
The very content provided by the child elements inside the above illustration can probably be generated available using attributes. I will be talking about these in my next tutorial.
Loads of info is available on XML for those who would want to know more. For the definitive guide, visit www.W3.org.
Friday 17 February 2012
Thursday 9 February 2012
The Way To Map An XML Database Through An XML Schema
Designers commonly come across the necessity to modify the manner in which they work with their databases, it's usually the situation when say, being a programmer you could be creating a web app or possibly a software project and you find you need to alter your data mid flow, as an example, changing from xml data to a relational database. I have often worked on projects when the aims have changed and in some cases, new technologies have been announced which has required the need for some other data methodology.
Having successfully operated such change in large projects, the procedure itself is in no way a horrible one; the chief challenge is in mapping the data layout involving the sender and the destination data.
A sensible way to achieve this is to try using an xml schema (xsd for short), basically an xml schema is a approach to describe the structure and content of an xml data source. The schema sets out the foundations of an xml file, a lot like a DTD. Therefore the schema will set out to define the elements, attributes, child elements, order and quantity of child elements etc that can appear in the xml data source.
To be able to map your xml database, you can employ the following techniques, at the present time there isn't any one desired system or indeed procedure to follow, the below solutions can be viewed as a series of valid steps. I'd also add that the method you take will probably be manipulated through your own particular circumstances, like the nature and kind of data you wish to map.
Element To Table Mapping
Transforming xml elements into relational database tables can be the most rational route to take, however it's not absolutely the best, its suitability will probably be determined by your data. For instance, mapping an element right into a database table will certainly convert the columns to element attributes or the element content into children and so on.
To map a target element to a relational database table, simply just setup the mapping node to get the pertinent rows from your database, then fill the target elements with values out of your database.
Element To Column Mapping
Mapping elements to columns in your relational database is recommended in case you have very simple elements containing only text string, if your elements is made up of further elements or attributes, your mapping is unlikely to be a success. By default, an element or even attribute of uncomplicated type, maps to the column with the exact same name in the table.
In the illustration below, the <Person.Person> element is of complex type and, subsequently, maps by default to the Person.Person table in the selected database. The attributes (BusinessEntityID, FirstName, LastName) of the <Person.Person> element are of simple type and map by default to columns with the same names in the Person.Person table.
<xsd:schema xmlns:xsd=".org/2001/XMLSchema"
xmlns:sql="urn:schemas-mysite-com:mapping-schema">
<xsd:element name="Person.Person" >
<xsd:complexType>
<xsd:attribute name="BusinessEntityID" type="xsd:string" />
<xsd:attribute name="FirstName" type="xsd:string" />
<xsd:attribute name="LastName" type="xsd:string" />
</xsd:complexType>
</xsd:element>
</xsd:schema>
Attribute To Column Mapping
Attribute to column mapping is more efficient if you would want to map the attributes into columns inside your relational database tables, matching them to their given elements. The exemption is where you have only a given number of possible attribute values, on this case it may be far better to have different tables for the elements needing each attribute type.
Let’s say you've got an element designated “brick”, which has an attribute designated “colour”, plus the attributes can only be “red” or “grey”, you might manage this step by setting two tables, one for red bricks and the other for grey bricks.
Having successfully operated such change in large projects, the procedure itself is in no way a horrible one; the chief challenge is in mapping the data layout involving the sender and the destination data.
A sensible way to achieve this is to try using an xml schema (xsd for short), basically an xml schema is a approach to describe the structure and content of an xml data source. The schema sets out the foundations of an xml file, a lot like a DTD. Therefore the schema will set out to define the elements, attributes, child elements, order and quantity of child elements etc that can appear in the xml data source.
To be able to map your xml database, you can employ the following techniques, at the present time there isn't any one desired system or indeed procedure to follow, the below solutions can be viewed as a series of valid steps. I'd also add that the method you take will probably be manipulated through your own particular circumstances, like the nature and kind of data you wish to map.
Element To Table Mapping
Transforming xml elements into relational database tables can be the most rational route to take, however it's not absolutely the best, its suitability will probably be determined by your data. For instance, mapping an element right into a database table will certainly convert the columns to element attributes or the element content into children and so on.
To map a target element to a relational database table, simply just setup the mapping node to get the pertinent rows from your database, then fill the target elements with values out of your database.
Element To Column Mapping
Mapping elements to columns in your relational database is recommended in case you have very simple elements containing only text string, if your elements is made up of further elements or attributes, your mapping is unlikely to be a success. By default, an element or even attribute of uncomplicated type, maps to the column with the exact same name in the table.
In the illustration below, the <Person.Person> element is of complex type and, subsequently, maps by default to the Person.Person table in the selected database. The attributes (BusinessEntityID, FirstName, LastName) of the <Person.Person> element are of simple type and map by default to columns with the same names in the Person.Person table.
<xsd:schema xmlns:xsd=".org/2001/XMLSchema"
xmlns:sql="urn:schemas-mysite-com:mapping-schema">
<xsd:element name="Person.Person" >
<xsd:complexType>
<xsd:attribute name="BusinessEntityID" type="xsd:string" />
<xsd:attribute name="FirstName" type="xsd:string" />
<xsd:attribute name="LastName" type="xsd:string" />
</xsd:complexType>
</xsd:element>
</xsd:schema>
Attribute To Column Mapping
Attribute to column mapping is more efficient if you would want to map the attributes into columns inside your relational database tables, matching them to their given elements. The exemption is where you have only a given number of possible attribute values, on this case it may be far better to have different tables for the elements needing each attribute type.
Let’s say you've got an element designated “brick”, which has an attribute designated “colour”, plus the attributes can only be “red” or “grey”, you might manage this step by setting two tables, one for red bricks and the other for grey bricks.
Subscribe to:
Posts (Atom)