Any data service — physical or logical — can be placed in a model diagram. Model diagrams show:
The basic structure of data returned by each data service within the model.
Any functions associated with that data service.
Any relationships between data services.
The main purpose of the diagram is to help you envision meaningful subsets of the model, but it can also be used to define new artifacts or edit existing artifacts.
Objectives
After completing this lesson, you will be able to:
Create model diagrams and add data source nodes to the diagram.
Confirm relationships inferred during the Import Source Metadata process.
Define new relationships between data services and modify relationship properties.
Overview
Model diagrams show how various data services are related. Models can represent physical data services, logical data services, or a combination.
Each physical model entity represents a single data source. In the case of relational sources, you can automatically generate physical models that are representative of data sources. After being generated, physical data services can be integrated with other physical or logical sources in the same or new models. Physical model types use a key icon to identify primary keys.
Logical data model entities, which are discussed in detail in the Data Service Developer's Guide, represent composite views of physical and/or logical models.
Within the model diagram, data services appear as boxes. Relationships are represented by annotated lines between two data services. Each side of the relationship line represents the role played by the nearest data service. The annotations for each relationship include the following:
Target Role Name. By default, the target role name reflects the name of its adjacent data service. You can modify the target role name to better express the relationship, which is particularly useful when there are multiple relationships between two data services.
Cardinality. A relationship can be zero-to-one (0:1 or 1:0), one-to-one (1:1), one-to-many (1:n) or many-to-many (n:n). For example, a customer can have multiple orders, therefore, the relationship should be 1:n (customer:orders).
Directionality. A relationship can be either unidirectional or bidirectional. If unidirectional, data service a can navigate to data service b but b does not navigate to a. If bidirectional, data service a can navigate to b and b can navigate to a.
A data service's navigation functions determine the relationship's cardinality and directionality. Arrowheads indicate possible navigation paths.
ALDSP model diagrams are very flexible; they can be based on existing data services (and corresponding underlying data sources), planned data services, or a combination. Using models you can easily manage multiple data services as well as identify needs for new data services. You can also create and modify data service types directly in the modeler and inspect data services.
Figure 5-1 Model Diagram for Physical Data Services
5.1 Creating a Basic Model Diagram for Physical Data Services
Modeling data services begins by adding individual data services to a diagram.
Objectives
In this exercise, you will:
Create a diagram that you will use to model relationships between physical data services.
Add the ApparelDB and CustomerDB physical data services to the model diagram.
Confirm relationships "captured" during the Import Source Metadata process.
Instructions
Create a new folder in the DataServices project and name it Models.
Create a new folder in the Models folder and name it Physical.
Create a blank model diagram, by completing the following steps:
Right-click the Physical folder.
Choose New Model Diagram.
Select Data Service Model Diagram as shown in Figure 5-2.
Figure 5-2 Create Model Diagram
Enter ApparelDB_Physical_Model in the File name field.
Click Create. A blank workspace opens. You can use that workspace to construct your model diagram.
Add the ApparelDB and CustomerDB physical data services to the model by dragging and dropping the following data service files from the Application pane into the model:
Data Service File
Location
CUSTOMER_ORDER.ds
DataServices\ApparelDB
CUSTOMER_ORDER-LINE_ITEM.ds
DataServices\ApparelDB
PRODUCT.ds
DataServices\ApparelDB
ADDRESS.ds
DataServices\CustomerDB
CREDIT_CARD.ds
DataServices\CustomerDB
CUSTOMER.ds
DataServices\CustomerDB
Notice that relationships between some data services already exist. These relationships were automatically generated during the Import Source Metadata process, and are based on the foreign key relationships defined in the underlying database.
Figure 5-3 Physcial Data Services Model Diagram
5.2 Modeling Relationships Between Physical Data Sources
The next step in data service modeling is to define additional relationships, beyond any relationship that was automatically generated during the import source metadata process.
A relationship is a logical connection between two data services, such as the CUSTOMER and CUSTOMER_ORDER data services. A relationship exists when one data service retrieves data from another, by invoking one or more of the other data service's functions.
A data service's navigation functions determine the relationship's cardinality and directionality. Arrowheads indicate possible navigation paths. Directionality can be either one directional or bidirectional.
Objectives
In this exercise, you will:
Define a relationship between the CUSTOMER and CUSTOMER_ORDER nodes, thereby creating a navigational function between the two nodes.
Modify the relationship properties to enable a "1:0 or many" relationship.
Instructions
Drag and drop the top-level CUSTOMER element onto the top-level CUSTOMER_ORDER element. The Relationship Properties dialog box opens.
In the Relationship Properties dialog box, modify the cardinality properties of the CUSTOMER and CUSTOMER_ORDER data services, by completing the following steps for the CUSTOMER node:
Select 0 from the Min occurs drop-down list.
Select n from the Max occurs drop-down list.
The relationship cardinality is now "1:0 or many" between the CUSTOMER and CUSTOMER_ORDER data services. In other words, one customer can have none, one, or any number of orders.
Click Finish.
Note:
In subsequent lessons, you will use additional features of the Relationship Properties dialog box to customize relationship properties.
Figure 5-4 Relationship Properties -- Cardinality
Note:
It may take a few seconds to generate the relationship line.
Figure 5-5 New Relationship Between Customer and Customer_Order Data Services Defined
Save all your files using the File Save All command.
Open CUSTOMER.ds in Design View. The file is located in the DataServices\CustomerDB folder.
Confirm that the CUSTOMER data service includes a new relationship with the CUSTOMER_ORDER data service, using the getCustomer_Order() function.
Figure 5-6 CUSTOMER Data Service Showing Added Relationship Function
Open CUSTOMER_ORDER.ds in Design View. The file is located in DataServices\ApparelDB.
Confirm that the CUSTOMER_ORDER data service includes a new relationship with the CUSTOMER data service, using the getCustomer() function.
Figure 5-7 CUSTOMER_ORDER Data Service Showing Added Relationship Function
(Optional) Create a relationship between CUSTOMER and CREDIT_CARD data services.
(Optional) Close all open files.
Lesson Summary
In this lesson, you learned how to:
Create model diagrams and add data source nodes to the diagram.
Confirm relationships inferred during the Import Source Metadata process.
Model Diagram. 
