Create a Schema

The first step in capturing data about a client is to create a DS schema. This section provides an example of how to create a basic schema that defines the capture of some general client data.

The DS stores data collected from users during online screening and intake of applications. The contents of the DS are dynamically definable by way of a schema definition. The requirements for capturing and storing any data about a client can be complex but with appropriate schema design, this data can be efficiently managed over its lifetime.

For the purposes of this example, the requirement is to capture the following:

Table 1. Client Data to Capture
Attributes	Type
First name	String
Middle name	String
Last name/Family name	String
Gender	Male/Female
Date of Birth	Date

There is a minimum set of definitions required in a schema. For a schema to be used in IEG, the following is required:

Inclusion of Base Domains
Inclusion of IEG Domains
A root entity

For more information on the minimum set of definitions required, see the Creating Datastore Schemas guide.

The schema would look something like this before adding new content such as the Person entity described above:

Figure 1. Starting Schema

<xsd:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 
  xmlns:d="http://www.curamsoftware.com/BaseDomains">
  <xsd:import namespace="http://www.curamsoftware.com/BaseDomains"/>
  <xsd:include schemaLocation="IEGDomains"/>
  <xsd:element name="Application">
    <xsd:complexType>
      <xsd:sequence minOccurs="0">
    </xsd:sequence>
    </xsd:complexType>
  </xsd:element> 
</xsd:schema>

The content of the schema indicates that it is an XMLSchema that imports BaseDomains schema and includes the IEGDomains schema. The first element called Application is the root entity for the schema. IEG requires that the root entity is always called Application.

The IEGDomains schema contains the domains required to define the attributes of entities to be used with IEG. The types of the attributes must be derived from the IEG Domains rather than the base domains. A Person entity can be defined to represent a client as follows:

Figure 2. Person Entity

<xsd:element name="Person">
  <xsd:complexType>
    <xsd:attribute name="firstName" type="IEG_STRING"/>
    <xsd:attribute name="middleName" type="IEG_STRING"/>
    <xsd:attribute name="lastName" type="IEG_STRING"/>
    <xsd:attribute name="gender" type="IEG_GENDER"/>
    <xsd:attribute name="dateOfBirth" type="IEG_DATE"/>
  </xsd:complexType>
</xsd:element>

There are a couple of things to note about the above addition for an entity like person:

Like relational database tables, an ID field is required and a key is defined for this table using this unique ID.
The person entity is added as a child entity of the root entity.

The schema to capture basic information about a person can be defined as follows:

Figure 3. Basic Schema

<xsd:element name="Application">
  <xsd:complexType>
    <xsd:sequence minOccurs="0">
       <xsd:element ref="Person" minOccurs="0" 
                                maxOccurs="unbounded"/>
    </xsd:sequence>
  </xsd:complexType>
</xsd:element>
<xsd:element name="Person">
  <xsd:complexType>
    <xsd:attribute name="personID" type="d:SVR_KEY"/>
    <xsd:attribute name="firstName" type="IEG_STRING"/>
    <xsd:attribute name="middleName" type="IEG_STRING"/>
    <xsd:attribute name="lastName" type="IEG_STRING"/>
    <xsd:attribute name="gender" type="IEG_GENDER"/>
    <xsd:attribute name="dateOfBirth" type="IEG_DATE"/>
  </xsd:complexType>
  <xsd:key name="Person_Key">
    <xsd:selector xpath="./Person"/>
    <xsd:field xpath="@personID"/>
  </xsd:key>
</xsd:element>

Once the schema has been defined you can then create a script to use the schema.