Example: Associating Data with RTIM
A Microsoft® SQL Server™ 2000 Meta Data Services repository contains data expressed as objects and relationships, along with their respective property values. The following figure shows some typical data for employees, projects, and subprojects. More details about this figure are provided later in this topic.
Mapping Real-World Data to RTIM objects
The preceding figure includes all the typical kinds of data you will find in a Meta Data Services repository. You can use the figure to understand the classes in the repository object architecture. In the figure, you can see instances of the following classes.
| Class | Description |
|---|---|
| Repository | Describes a repository session. The figure as a whole represents an instance of the Repository class. |
| RepositoryObject | Describes a repository object. The figure shows 12 objects, one of which is the root object; each additional instance is a dot. |
| ReposRoot | Describes the root object. The root object is the top-level object in a repository from which navigation begins. The root object can have any number of relationships with other objects. The figure shows seven such relationships. |
| Relationship | Describes an association between two objects. The figure shows 15 relationships; each relationship is an arrow. |
| RelationshipCol | Describes a set of similar relationships. The items in a relationship collection must have the same source, and the relationships must be the same type
For example, consider the relationships between Projects and Subprojects. The Genome project is related to Research Design and to Splicing Algorithms. Both relationships have the same source (Genome) and the same type (includes), thereby meeting the criteria for a relationship collection. Consider a second relationship collection: the set of Mike's assignments to subprojects. In the figure, this relationship collection appears as a pair of arrows emerging from the dot representing Mike. |
| TargetObjectCol | Describes a set of objects. For example, one set of objects is the set of subprojects on which Mike works; the set contains two items. |
Drilling Down into Relationship Roles
Understanding roles in a relationship is one of the more difficult aspects to information modeling. The following section draws out some of the complexity of relationships by expanding on the example.
Same Object in Same Role
In the relationship collection shown in the following figure, every relationship uses the object describing Mike as the performer of the work on a subproject. The object describing Mike is the origin object in this relationship.
In contrast, the set of relationships shown in the following figure does not constitute a collection because there is no object that all the relationships use in the same role. In fact, the relationships have no object in common, regardless of role.
Common Object in Different Roles
The following figure shows employees and their managers.
The set of relationships shown in the following figure does not constitute a valid relationship collection.
Every relationship in the preceding figure is of the same relationship type, the manages type. All the relationships have an object in common: the object describing Frank. One relationship, however, has Frank in the role of person being managed, whereas the other relationships have Frank in the role of person who is managing someone else. Because the relationships do not all use the same object in the same role, they do not constitute a valid relationship collection.
The three relationships in the following figure do constitute a valid collection because Frank is in the manager role for all three relationships.
