|
This section explains some basic data modeling terms and concepts. The The topics covered are: |
|
CES stores data in a relational database. In a relational database, data is stored in a data model. The data model defines a structure for storing and organizing the data. In addition, the data model defines relationships among the types of data in your system. The key feature that differentiates the CES system from other technical information management systems is that the structure of the CES database is flexible. Unlike other systems, CES does not have a hard-coded data model. As a result, you can easily integrate your organization's internal data with the data provided by ENOVIA V5 VPM, or you can create an entirely new data model that meets your needs more effectively. The process of modeling your data for use in the CES system includes the following basic tasks:
|
|
A unit of information stored in the database is called an item, or an object. In general, an item in the database represents something in the real world. For example, if your CES application tracks information about employees, then the employee John Doe is an example of an item. An item in the database
consists of the information used to describe the corresponding item in the
real world. Each characteristic used to describe an item is called a For example, an item that describes an employee might include properties, such as Employee ID number, Employee Name, and Age. The values for these properties might be 1228, John Doe, and 35. |
|
CES is based on
object-oriented principles of classification and property inheritance. As
a data modeler, this means that you must organize the data into For example, the CES application that stores employee information could include a class called Employees with the properties Employee ID, Employee Name, Age, and other information. Some classes include other
classes. A class inherited from another class is called a
Classes and subclasses are organized in to a structure called a class hierarchy or a classification scheme. This hierarchy appears in the Brower View so that it is easier for users to access what they need. It facilitates usage of property inheritance. For example, to organize employee data, you can create an Employee class with subclasses to distinguish between salaried and hourly employees, and to distinguish between permanent and temporary hourly employees. The following diagram illustrates the example. To represent the data, you can create a class hierarchy. For details, see Class Hierarchy.
|
|
Your database might comprise several levels of classes and subclasses. However, only those classes appearing at the bottom of the class hierarchy can define an item. These classes are called bottom classes. Therefore, if you are entering new items in to the database, you must enter thee items in to the bottom classes. Bottom classes inherit the properties of all the classes along a given branch of the tree, so only these classes contain all the information necessary to fully describe an item. |
|
A class hierarchy can also contain a special kind of class called a folder class. A folder class has no class properties and no objects; it is simply an organizing tool that has child classes below it. Although folder classes do not have class properties, they propagate all parent class properties to the folder's subclasses. Folder classes can also be searched. Before you make a folder class, make sure that you will not need class properties at that level. |
|
A Class Label is a case-insensitive string that identifies a class and appears in the Browser View. The Class Label must be unique. Therefore, you cannot use case to differentiate between classes that have the same Class Label. For example, you cannot create two classes called Supplier, and SUPPLIER. |
|
Property Inheritance ensures that the properties of a parent class apply to its child classes in a class hierarchy. For example, a parent class Employees might have two child classes, namely Salaried and Hourly. The child classes might have many properties in common, such as Employee ID, Name, Address, and Age. Attaching these properties to the Employee class ensures that the Salaried and Hourly child classes inherit these properties. Inheritance increases the speed of the data modeling process, because it limits the number of times you need to create new class properties. In the above example, you could create a separate Employee ID property for each of the classes. Instead, property inheritance promotes a more efficient method of creating the property only once, in the Employee class. |
|
The Employee class must be an intermediate class and not a folder class to be able to create properties. Folder classes do not have properties. |
|
The basic structure of your data model becomes the basis for the class hierarchy that the user sees in the CES Data Modeler Browser View. In the Browser View, you can:
The class hierarchy appears in the Browser View as shown.
|
|
CES not only stores data - it
also models For example, you might want to model the relationship between employees and their dependents. You can do this by creating two classes, one for dependents and another for employees. You can connect the two classes with a pointer. Pointers are like class properties except that they refer to objects in another class in the database. To establish the relationship between the employee and one or more dependents, you create a pointer in the Dependents class that refers to the Employee class. The class being pointed to is
called the |
![]() |
A single pointer can indicate a one-to-one relationship or a many-to-one relationship between items. When the pointer indicates a many-to-one relationship between the classes involved, the direction of that pointer is crucial. The pointer is always associated with the class containing many objects that are related to a single object in another class. In the example given in the earlier figure, one employee can be related to many dependents. Therefore, the pointer is associated with the Dependents class and points to the Employee class. |