|
You are provided with a visual modeling environment for the data model of an application, and also reverse database engineering. This chapter shows you how to depict the object models by using Entity Relationship Diagram and how to reverse database, and describes how the data model maps to the object model.
In this chapter:
An entity is an object in the business or system with well-defined characteristics which are represented by columns showing what information can be stored. In relational databases, an entity refers to a record structure, i.e. table.
A data model provides the lower-level detail of a relational database of an application. It shows the physical database models and their relationships in an application. An entity relationship diagram can be used to describe the entities inside a system and their relationships with each other; the entity relationship diagram is also known as a data model.
Visual modeling for data models is supported, not only by creating a new data model, but also by transforming from an object model. Reversing the existing relational model into data models is also supported. As object-relational mapping is automated, object model can thus be generated from the data model by reversing the existing database.
The following section describes how to reverse the relational model into data models and depict the data models using the Entity Relationship Diagram.
Entity relationship diagram is a graphical representation of a data model of an application. It acts as the basis for mapping the application to the relational database.
You are provided with three ways to create an Entity Relationship Diagram.
![]() |
|---|
| Figure 18.1 - To create an ERD |
![]() |
|---|
| Figure 18.2 - Create Entity Diagram on Diagram Navigator |
A new Entity Relationship Diagram pane is displayed.
![]() |
|---|
| Figure 18.3 - Entity icon button |
An icon representing the entity element is added to the diagram.
Entity Specification dialog box is displayed, you can modify the entity properties and constraints.
![]() |
|---|
| Figure 18.4 - Entity Specification dialog |
![]() |
|---|
| Figure 18.5 - Create a columns |
A new column is added, type the column name and type in the form of "column_name: type". You can also edit the column name by double-clicking the column name or by pressing the F2 button.
Column Specification dialog box is displayed, you can modify the column name and properties, such as type.
![]() |
|---|
| Figure 18.6 - Entity Specification (Columns Tab) |
You can add relationship to the entities in one of the two ways:
![]() |
|---|
| Figure 18.7 - "One-to-one Relationship -> Entity" resource-centric |
A line indicating a connection between the two entities is shown.
You can edit the relationship specification in the following way:
Relationship Specification dialog box is displayed, you have to modify the relationship properties, Phrase and Cardinality.
![]() |
|---|
| Figure 18.7 - relationship Specification dialog |
Once you assign a primary key to a column of an entity, a foreign key column is automatically added to all entities associated with it.
An ERD is created.
![]() |
|---|
| Figure 18.8 - Entity Relationship Diagram |
You can create an Entity Relationship Diagram by reverse engineering an existing relational database.
![]() |
|---|
| Figure 18.9 - To Reverse Database |
The Database to Data Model dialog box is displayed.
Select the language of the project from the drop-down menu, either Java or C#, and then click Next > to proceed to Step 2.
![]() |
|---|
| Figure 18.10 - Database to Data Model dialog |
You can configure the database connection for the desired database to be reversed.
![]() |
|---|
| Figure 18.11 - Database Configuration |
All the available tables found from the connected database are listed.
![]() |
|---|
| Figure 18.12 - Selecting Tables |
An Entity Relationship Diagram is automatically generated and displayed. It can be found under the Diagram Navigator.
![]() |
|---|
| Figure 18.13 - The ERD formed by the reverse entities |
You can generate the ERD from a class diagram by synchronization if there is a class diagram.
![]() |
|---|
| Figure 18.14 - Synchronize to Entity Relationship Diagram |
![]() |
|---|
| Figure 18.15 - Synchronize to ERD by click on popup menu |
![]() |
|---|
| Figure 18.16 - The ERD formed by the reverse entities |
An Entity Relationship Diagram is generated and can be found under the Diagram Navigator.
![]() |
|---|
| Figure 18.17 - The ERD formed by the reverse entities |
If a relationship with cardinality of many at one end, a corresponding collection class will be used for handling its multiple cardinality. You can specify an index column to sort the collection.
![]() |
|---|
| Figure 18.18 - Open the relationship specification |
Relationship Specification dialog box is displayed.
![]() |
|---|
| Figure 18.19 - Relationship specification dialog |
| You can select Create Column from the drop-down menu to create a new index column for sorting. |
As the primary key is unique, the generation of primary key is supported. The ID Generator is specialized for generating a primary key value at runtime.
![]() |
|---|
| Figure 18.20 - To open Column specification |
Column Specification of the primary key is displayed.
![]() |
|---|
| Figure 18.21 - Column specification dialog |
| If the ID Generator is specified as either sequence, seqhilo or hilo, you have to enter the key for the sequence/table name. |
In generalization, the superclass distributes its commonalities to a group of similar subclasses. The subclass inherits all superclass's attributes and it may contain specific attributes. The entities within the hierarchy are combined into one single entity containing all the attributes and a discriminator column. The discriminator contains a unique value which is used for identifying the entity which hierarchy it belongs to.
You are allowed to define the discriminator in the entity and discriminator value in the classes.
You can add a new column acting as the discriminator column for an entity.
![]() |
|---|
| Figure 18.22 - Create a column |
![]() |
|---|
| Figure 18.23 - Enter the column name and type |
![]() |
|---|
| Figure 18.24 - Open the column specification |
Entity Specification dialog box is displayed.
![]() |
|---|
| Figure 18.25 - Column Specification dialog |
You can specify the discriminator value for each sub-class.
![]() |
|---|
| Figure 18.26 - To open ORM Class Detail/td> |
![]() |
|---|
| Figure 18.27 - Class Specification dialog |
In a one-to-many relationship, a collection is used for handling the multiple objects such that it is simpler to retrieve each object from the collection one by one.
The idea of Array Table is promoted which allows users to retrieve objects in the form of primitive array, instead of a collection when handling a data column with cardinality of many.
You are allowed to create an array table in the entity and define an array type in the classes.
You can create an Array Table for the Entity with a column containing more than one instance of data.
![]() |
|---|
| Figure 18.28 - Entities with one-to-many relationship |
In the above case, the phonebook has a contact entry for each contact person. Each contact person may have more than one phone numbers. A one-to-many relationship between contact entry and contact phone can be built.
![]() |
|---|
| Figure 18.29 - Convert to Array Table |
![]() |
|---|
| Figure 18.30 - Warning message for the constraints are not satisfied |
The conversion to Array Table is completed and the entity for the data column is stereotyped as Array Table.
![]() |
|---|
| Figure 18.31 - Entity are converted to Array Table |
A class with an attribute of array type modifier means that the attribute may contain more than one data; thus it implies the idea of Array Table.
You can define the array type for the attribute in one of the two ways:
![]() |
|---|
| Figure 18.32 - To Add a attribute |
![]() |
|---|
| Figure 18.33 - Enter the attribute name and type |
![]() |
|---|
| Figure 18.34 - Open specification |
The Class Specification dialog box is displayed
Attribute Specification is displayed.
![]() |
|---|
| Figure 18.35 - Attribute Specification dialog |
In a one-to-one identifying relationship, an entity may be a subordinate of the related entity; that is, the subordinate entity has columns which also belong to its superior entity in the real world situation.
The idea of Split Table with stereotype of Partial is also promoted, which allows developers to optimize the size of database, and minimizes the redundant persistent classes for handling one-to-one identifying relationship. In order to reduce the risk of appending a new column to an existing database table, Split table supports developers to add new columns to the partial table with a one-to-one identifying relationship linked to the existing table.
You are allowed to split the entity into two and convert the subordinate entity to be a Partial Table in a one-to-one identifying relationship.
You can split an entity into two associated with a one-to-one identifying relationship.
You can activate the Split Table dialog box in one of the two ways:
![]() |
|---|
| Figure 18.36 - To split table |
![]() |
|---|
| Figure 18.37 - "One-to-One Relationship -> Partial Table" resource-centric |
Split Table dialog box is displayed.
![]() |
|---|
| Figure 18.38 - Split Table dialog |
An entity stereotyped as Partial is created.
![]() |
|---|
| Figure 18.39 - The split entities with one-to-one relationship |
You can convert an entity to a Partial Table in a one-to-one identifying relationship.
![]() |
|---|
| Figure 18.40 - Convert to a partial table |
The entity is stereotyped as Partial.
![]() |
|---|
| Figure 18.41 - The entity is convert to a partial table |
Copying SQL statements from the ERD entities is provided. It allows the developers to copy the SQL statements from the entity relationship diagram easily such that developers can use and modify the SQL statement on the database directly.
In order to copy the SQL statement, you must configure the database setting in advance as the SQL statements will be generated according to the default database server type.
![]() |
|---|
| Figure 18.42 - To open database configuration |
Database Configuration dialog box will be displayed. Refer to the descriptions in the Database Configuration chapter for information on how to configure the database.
| SDE-VS will only provide you the function of copying SQL if the default database connection is set. |
| If there are multiple database settings, the SQL statements will be generated for all these database servers. |
There are two database settings selected in the working environment.
![]() |
|---|
| Figure 18.43 - Set 2 database setting |
![]() |
|---|
| Figure 18.44 - To copy a SQL |
| You can select Create Table(s), Drop Table(s), Select, Insert, Update and Delete from the Copy SQL submenu to directly copy the SQL statements to clipboard. |
![]() |
|---|
| Figure 18.45 - Generate SQL dialog |
You are allowed to copy the SQL statements from the Generate SQL dialog box.
You can specify the scope on the ERD to generate the SQL statements.
You can specify one of the three scopes:
As copying SQL without specifying scope, SQL statements will be generated for all components including both entities and relationships on the ERD.
Example:
![]() |
|---|
| Figure 18.46 - Generate SQL for specified scope |
![]() |
|---|
| Figure 18.47 - Generate SQL dialog |
As copying SQL with specifying a particular scope, SQL statements will be generated only for the components included in the specified scope.
Example:
![]() |
|---|
| Figure 18.48 - Copy a SQL statement for create table |
As copying SQL with connection lines, SQL statements for Create Constraint(s) and Drop Constraints(s) will be generated.
Example:
![]() |
|---|
| Figure 18.49 - Copy Statemenet for create constraint |
Create Constraint :
Drop Constraint :
Object Relational Mapping (ORM) is supported which maps data models to object models and vice versa.
Mapping between objects to relational database preserves not only the data, but also the state, foreign/primary key mapping, difference in data type and business logic. Thus, you are not required to handle those tedious tasks during software development.
All entities map one-to-one to persistent classes in an object model.
Example:
![]() |
|---|
| Figure 18.50 - Mapping entities to classes |
In the above example, the Customer Entity map one-to-one the Customer Class as the Customer instance can store the customer information from the Customer Entity.
Since all entities map one-to-one to persistent classes in an object model, columns in turn map to attributes in a one-to-one mapping. All specialty columns such as computed columns and foreign key columns are ignored during the transformation.
Example:
![]() |
|---|
| Figure 18.51 - Mapping columns to attributes |
In the above example, the following table shows the mapping between the columns of the Customer Entity and the attributes of the Customer Class.
| Customer Entity | Customer Class |
|---|---|
| CustomerID | CustomerID |
| CustomerName | CustomerName |
| Address | Address |
| ContactPhone | ContactPhone |
The column data type automatically maps to an appropriate attribute type of object model.
Example:
![]() |
|---|
| Figure 18.52 - Mapping data types |
In the above example, the following table shows the mapping between data types
| Customer Entity | Customer Class |
|---|---|
| int (10) | int |
| varchar(255) | String |
A table shows the data type mapping between Object model and Data model.
| Data Model | Object Model |
|---|---|
| Bigint | Long |
| Binary | Byte[] |
| Bit | Boolean |
| Blob | Blob |
| Varchar | String |
| Char | Character |
| Char(1) | Character |
| Clob | String |
| Date | Date |
| Decimal | BigDecimal |
| Double | Double |
| Float | Float |
| Integer | Integer |
| Numeric | BigDecimal |
| Real | Float |
| Time | Time |
| Timestamp | Timestamp |
| Tinyint | Byte |
| Smallint | Short |
| Varbinary | Byte[] |
As the columns map to attributes in a one-to-one mapping, primary key columns in the entity map to attributes as a part of a class.
Example:
![]() |
|---|
| Figure 18.53 - Mapping primary key |
In the example, the primary key of entity Product, ProductID maps to an attribute ProductID of the class Product.
Relationship represents the correlation among entities. Each entity of a relationship has a role, called Phrase describing how the entity acts in it. The phrase is attached at the end of a relationship connection line. The phrase maps to role name of association in the object model.
There are two types of relationships in data model mapping to object model - identifying and non-identifying.
Identifying relationship specifies the part-of-whole relationship. It means that the child instance cannot exist without the parent instance. Once the parent instance is destroyed, the child instance becomes meaningless.
Non-identifying relationship implies weak dependency relationship between parent and child entities. There are two kinds of non-identifying relationships, including optional and mandatory. The necessity of the parent entity is "exactly one" and "zero or one" in the mandatory and optional non-identifying relationship respectively.
Since the identifying relationship specifies the part-of-whole relationship, it map to composite aggregations which implies that the part cannot exist without its corresponding whole.
Example:
![]() |
|---|
| Figure 18.54 - Mapping identifying Relationship |
In the above example, the identifying relationship between the entities of EmergencyContact and Student maps to composition aggregation.
Since non-identifying relationship implies weak relationship between entities, it maps to association.
Example:
![]() |
|---|
| Figure 18.55 - Mapping non-identifying relationship |
In the above example, non-identifying relationship between entities Owner and Property maps to association between Classes of Owner and Property.
Cardinality refers to the number of possible instances of an entity relate to one instance of another entity. The following table shows the syntax to express the Cardinality.
Table shows the syntax expressing the Cardinality
| Type of Cardinality | Description |
|---|---|
| Zero or one instance | |
| Zero or more instances | |
| Exactly one instance | |
| One or more instances |
Table shows the typical mapping between Entity Relationship Diagram and Class Diagram.
| Entity Relationship Diagram | Class Diagram |
|---|---|
![]() |
![]() |
For each many-to-many relationship between entities, a Link Entity will be generated to form two one-to-many relationships in between. The primary keys of the two entities will automatically migrate to the link entity to form the primary/foreign keys.
Example:
![]() |
|---|
| Figure 18.56 - Mapping Many-to-many relationship |
In the above example, SDE-VS generates the link entity once a many-to-many relationship is setup between two entities. To transform the many-to-many relationship, the many-to-many relationship maps to many-to-many association.
The Array Table is promoted to allow users retrieve objects in the form of primitive array.
When transforming an array table, the array table will map to an attribute with array type modifier.
Example:
![]() |
|---|
| Figure 18.57 - Mapping Array Table to Collection of Object |
In the above example, the phonebook has a contact entry for each contact person. Each contact person may have more than one phone numbers. The array table of ContactEntry_Phone maps into the phone attribute with array type modifier in the ContactEntry class.
The following table shows the shift from data model to object model terminology.
| Data Model Term | Object Model Term |
|---|---|
| Entity | Class |
| Instance of an entity | Object |
| Relationship | Association |
| Supertype/subtype | Generalization |
| Column | Attribute |
| Phrase | Role |
| Cardinality | Multiplicity |
|
|
|||||||