Concepts Guide
|
 |
 |
|
 |
 |
This section discusses how you can use modeling to build a data services layer. The following topics are covered:
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.
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.
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:
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:
|
|
|
