Model Usage

Usage Scenario: Creating Metadata That Represents a DBMS

This usage scenario describes the metadata that defines a DBMS server. You must use metadata types from several SAS Metadata Model submodels to define a DBMS server, including the Software Deployment Submodel, the Resource Submodel, and the Relational Submodel. This example focuses on the metadata types that describe the DBMS and that define the server context of SAS that will be used to access the DBMS data.

Requirements

This usage scenario assumes that the user has a general understanding of the Software Deployment Submodel, the Resource Submodel, and the Relational Submodel of the SAS Metadata Model.

Creating Objects That Represent a DBMS

Figure 1 shows the metadata objects that are required to access tables from a DBMS.

[Figure 1. The metadata objects that are required to access a DBMS.]

Figure 1. The metadata objects that are required to access a DBMS.

The ServerComponent metadata type represents installed and configured software, such as the Oracle DBMS in this scenario. The ServerContext metadata type defines an application context by grouping non-homogeneous servers that can access the same resources. Resources include file system directories, database schemas, and SAS libraries, which are represented by metadata types that are subtypes of the DeployedDataPackage metadata type. If the software is configured as a server, as it is in this example, the information used to access the server is described by a subtype of the Connection abstract metadata type. This scenario stores client connection information in a SASClientConnection metadata object. Other Connection subtypes include the COMConnection, OpenClientConnection, and TCPIPConnection.

In Figure 1, the Oracle DBMS ServerComponent metadata object has a SourceConnections association (numbered 1) with the SASClientConnection metadata object. The SourceConnections association references a list of connection objects that can be used by other software to access the server. There can be many connection objects, including objects of the other Connection subtypes. For example, there could be OpenClientConnection objects that contain OLE DB connection information and JDBC connection information, in addition to the SASClientConnection object. The Connection abstract metadata type defines several attributes that describe supported protocols. The CommunicationProtocol= attribute contains a value such as APPC or TCPIP that describes the communication protocol used to access the component. The ApplicationProtocol= attribute contains a value such as HTTP, RMI, Bridge, or SHARE. Each connection object has a Source association with one and only one ServerComponent object.

The ServerComponent and ServerContext metadata objects have a DataPackages association (numbered 2) to the DeployedDataPackage metadata objects that they can access. ServerComponent has a DataPackages association to a DatabaseSchema metadata object. The ServerContext object has a DataPackages association to a SASLibrary metadata object.

A SASLibrary metadata object can be associated with a single DatabaseSchema metadata object. This association (UsingPackages) is numbered 4 in the figure. When a SAS library is associated with a database schema, it needs connection information for the server. SASLibrary has a LibraryConnection association (numbered 5) to a SASClientConnection object.

There is a subtype of the DeployedDataPackage metadata type called RelationalSchema that has an association to DataTable metadata objects. The SASLibrary and DatabaseSchema metadata types are subtypes of RelationalSchema. The association (numbered 3) is inherited from RelationalSchema. It is called Tables. The PhysicalTable metadata object inherits this association from the DataTable. This example uses PhysicalTable to define the objects because the objects represent actual tables in a DBMS or file system.

Top of Page