XML
  Home arrow XML arrow Page 2 - One-One, One-Many and Many-Many Relations ...
Dev Articles Forums 
ADO.NET  
Apache  
ASP  
ASP.NET  
C#  
C++  
ColdFusion  
COM/COM+  
Delphi-Kylix  
Design Usability  
Development Cycles  
DHTML  
Embedded Tools  
Flash  
Graphic Design  
HTML  
IIS  
Interviews  
Java  
JavaScript  
MySQL  
Oracle  
Photoshop  
PHP  
Reviews  
Ruby-on-Rails  
SQL  
SQL Server  
Style Sheets  
VB.Net  
Visual Basic  
Web Authoring  
Web Services  
Web Standards  
XML  
Mobile Linux 
App Generation ROI 
IBM® developerWorks 
Sun Developer Network 
Weekly Newsletter
 
Developer Updates  
Free Website Content 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us Get Paid 
Request Media Kit
Contact Us 
Site Map 
Privacy Policy 
Support 
 USERNAME
 
 PASSWORD
 
 
  >>> SIGN UP!  
  Lost Password? 
XML

One-One, One-Many and Many-Many Relations in XML Schema
By: Jagadish Chaterjee
  • Search For More Articles!
  • Disclaimer
  • Author Terms
  • Rating: 4 stars4 stars4 stars4 stars4 stars / 9
    2006-04-24

    Table of Contents:
  • One-One, One-Many and Many-Many Relations in XML Schema
  • Implementing a “One to One” relation in XML Schema: schema explained
  • Implementing a “One to One” relation in XML Schema: a sample XML document
  • Implementing a “One to Many” relation in XML Schema: the schema
  • Implementing a “One-Many” relation in XML Schema: a sample XML document
  • Implementing a Many to Many relation in XML Schema: the schema

  • Rate this Article: Poor Best 
      ADD THIS ARTICLE TO:
      Del.ici.ous Digg
      Blink Simpy
      Google Spurl
      Y! MyWeb Furl
    Email Me Similar Content When Posted
    Add Developer Shed Article Feed To Your Site
    Email Article To Friend
    Print Version Of Article
    PDF Version Of Article
     
     
    ADVERTISEMENT


    One-One, One-Many and Many-Many Relations in XML Schema - Implementing a “One to One” relation in XML Schema: schema explained


    (Page 2 of 6 )

    This section explains the schema introduced in the previous section.  Instead of explaining it all at once, let me explain it part by part.  Let us consider the following fragment:

          <xs:complexType name="typePersonal">
                <xs:sequence>
                      <xs:element name="Empno" type="xs:int" />
                      <xs:element name="FirstName"
     type="xs:string" />
                      <xs:element name="LastName" type="xs:string" />
                      <xs:element name="DOB" type="xs:date" />
                </xs:sequence>
          </xs:complexType>

    The above code fragment defines a new user-defined complex type named “typePersonal.”  It internally contains four elements, namely “Empno,” “FirstName,” “LastName” and “DOB.”  There exists another code fragment very similar to the one above:

          <xs:complexType name="typeAddress">
                <xs:sequence>
                      <xs:element name="Empno" type="xs:int" />
                      <xs:element name="Street" type="xs:string" />
                      <xs:element name="City" type="xs:string" />
                      <xs:element name="ZIP" type="xs:string" />
                </xs:sequence>
          </xs:complexType>

    The above code fragment defines a new user-defined complex type named “typeAddress.”  It internally contains four elements, namely “Empno,” “Street,” “City” and “ZIP.”  The above two are simply “data types.”  We need to declare elements based on the above user-defined data types. Let us consider the following code fragment:

    <xs:element name="Employee" maxOccurs="unbounded">
          <xs:complexType>
                <xs:sequence>
                      <xs:element name="PersonalDetails"
     type="typePersonal" maxOccurs="1" minOccurs="1" />
                      <xs:element name="AddressDetails"
     type="typeAddress" maxOccurs="1" minOccurs="0" />
                </xs:sequence>
          </xs:complexType>
    </xs:element>

    Within the above code fragment, you can observe that I defined a new element called “Employee” (which typically handles both of the previously defined data types).  Within this element, I defined two more elements, “PersonalDetails” and “AddressDetails” based on the user-defined complex types explained previously.  What about our primary keys?  They are defined as follows: 

                <xs:key name="PK_Employee">
                      <xs:selector xpath=".//Employee" />
                      <xs:field xpath="PersonalDetails/Empno" />
                </xs:key>
                <xs:key name="PK_Employee_Address">
                      <xs:selector xpath=".//AddressDetails" />
                      <xs:field xpath="Empno" />
                </xs:key>

    The following code fragment enforces the one to one relation between “PersonalDetails” and “AddressDetails:”

    <xs:keyref name="EmployeeAddressDetails" refer="PK_Employee">
          <xs:selector xpath=".//AddressDetails" />
    <xs:field xpath="Empno" />
    </xs:keyref>

    It happened to be a one to one relation, as the Foreign Key (or the element “Empno” in “AddressDetails”) itself is a primary key!

    More XML Articles
    More By Jagadish Chaterjee


       · Hello guys, this is another extension to the XML Schema series. Enjoy it.
     

    XML ARTICLES

    - Datatypes and More in RELAX NG
    - Providing Options in RELAX NG
    - An Introduction to RELAX NG
    - Path, Predicates, and XQuery
    - Using Predicates with XQuery
    - Navigating Input Documents Using Paths
    - XML Basics
    - Introduction to XPath
    - Simple Web Syndication with RSS 2.0
    - Java UI Design with an IDE
    - UI Design with Java and XML Toolkits
    - Displaying ADO Retrieved Data with XML Islan...
    - Widget Walkthrough
    - Introduction to Widgets
    - The Why and How of XML Data Islands






    © 2003-2008 by Developer Shed. All rights reserved. DS Cluster 5 hosted by Hostway
    Stay green...Green IT