Data Modeling Concepts

This section explains some basic data modeling terms and concepts. The The topics covered are:

About Data Modeling

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:

  • Defining the different classes of data.

  • Establishing a class hierarchy.

  • Defining the properties associated with a given class.

  • Determining the relationships among classes.

  • Using the CES Data Modeler to build the actual data model.

Items and Properties

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 property. The description that corresponds to a property is called a property value, or just a value.

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.

Classes and Class Hierarchy

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 classes. A class consists of one or more properties.

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 child of that class. Child classes are also called subclasses, intermediate classes, or leaf classes.

  • Intermediate classes are classes that have class properties and one or more classes below the intermediate classes.

  • The classes that are displayed at the lowest point in each branch of the hierarchy are called leaf or bottom classes.

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.

Bottom Class

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.

Folder Classes

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.

Understanding Class Labels

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

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.

Browser View

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:

  • View all the classes.

  • View the organization of the database.

  • Select the class you need.

The class hierarchy appears in the Browser View as shown.

Relationships and Pointers

CES not only stores data - it also models relationships among items in the real world.

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 pointer valid class. This is the target class for the pointer.

Direction of Pointer

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.