Skip navigation.
Downloads | Product Documentation | Support

Concepts Guide

# Modeling and a Service-Oriented Architecture

This section discusses how you can use modeling to build a data services layer. The following topics are covered:

- Addressing Complexity with Modeling
- Modeling Data With XML Schema
- Modeling Data Services

# Addressing Complexity with Modeling

Generally, modeling helps to mitigate the complexity of large, intricate systems. In Liquid Data, modeling is no different. It provides a visual, representational view of data resources. It can present a high-level view of a complex system or it can break a complex problem into smaller pieces.

Modeling helps you to organize and document data services. It enables you to bridge the gap between the complexity of the underlying physical data landscape, on the one hand, and a logical, intuitive data model exposed by data services, on the other.

Modeling is generally the first step in developing a data services layer. It provides a roadmap for the development of the data services to be built on top of physical data resources.

The Liquid Data Modeler (shown in Figure 4-1) is a visual modeling tool for creating, managing, and modifying data services. You can create data services and define the relationships between them directly in the modeler.

Figure 4-1 Model Diagram

# Modeling Data With XML Schema

Like a dictionary does for a language, a schema defines the vocabulary, rules, and conventions for representing information in a system. Liquid Data uses the XML Schema language to model data. XML Schema (a standard, XML-based schema definition language) gives Liquid Data a way to define normalized data, enabling consuming applications to use the data without regard for the inherent differences of its various underlying source representations.

Each data service has a data type, a named data shape defined in XML Schema. The schema defines the content, that is, the elements, attributes, and types of the data. For example:

>     <xs:element name="CUSTOMER">
>        <xs:complexType>
>           <xs:sequence>
>              <xs:element name="CUSTOMERID" type="xs:int"/>
>              <xs:element name="CUSTOMERNAME" type="xs:string" />
>              ...
>           </xs:sequence>
>        </xs:complexType>
>     </xs:schema>

An XML schema file, named with a `.xsd` extension, is automatically generated when you import the metadata of a physical data source. For logical data services, you can create the schema by hand. In any case, an XML schema definition must exist for any information that you want to be made available as a data service.

A data service is validated against its associated schema at design time. Design-time validation prevents query development mistakes. At runtime, physical data service data is validated as well. Runtime schema checking ensures the validity of information returned by query execution.

The XQuery Editor helps you to create schemas for logical data services. As a starting point, you can associate the schema to a data service from an existing data source, such as a physical data source (and save the schema with a different name). Once you have saved and associated the new schema from the editor, you can change field names, remove fields, and so on, from the graphical, Design View editor.

# Modeling Data Services

Just as it does for database design, data modeling helps to ensure the optimal design of your data services layer. Modeling lets you analyze and develop data services efficiently and in a way that most effectively resolves a complex data landscape into a sensible, business-level data model. Modeling also serves to document data services for use by others.

Physical data services can be considered the building blocks for logical data services. In the case of a relational data source, for example, importing metadata results in a data service being created for each table.

Modeling not only represents the data services in your Liquid Data implementation, it also captures the relationships between the data services. A relationship is a logical connection between two data services, such as between a customer data service and an orders data service.

The directionality of a relationship can be either:

- One way, in which data service a can navigate to data service b but b does not navigate to a.
- Two way, in which data service a can navigate to b and b can navigate to a.

Relationships are manifested in a data service by navigation functions. By traversing the relationship a client application can acquire data from a related data service from an instance of the current data service (for example, to get the orders that belong to a particular customer). Similarly, the Order data service may have a function that gets the customer associated with a particular order. This is an example of a two-way relationship.

A relationship—and, by extension, the navigation function derived from them—serves these purposes:

- It advertises a logical connection between data elements.
- It streamlines client programming by supporting the acquisition of related data from a single data service instance. For a code example, see A First Look at SDO on page 6-3.
- It encapsulates the details of how the logical connection of a relationship is physically manifested, that is, its key mappings, the nesting hierarchy, and so on.