Tutorials: Working with Hierarchical Models

Go Up to Introduction

ER/Studio models information using Entity Relation Diagrams. You can convert these diagrams directly into relational models that represent relational databases. Data assets such as MongoDB, JSON, and Google BigQuery have hierarchical structures. These hierarchical structures also employ denormalization to improve performance with repeated substructures.

Data Architect converts relational logical models to denormalized hierarchical structures and vice versa using feature wizards including Generate Database, Reverse Engineer, Import from File, and Compare/Merge. To make this process repeatable, logical data models are enhanced to include additional information to help with this process.

Specifying Containment in the Logical Model

In the following logical data model diagram, notice that some lines display Parent contains Child or Child contains Parent. This allows you to specify how objects are embedded in any hierarchical physical models generated from it. This also drives both the Generate Physical Model and Compare/Merge wizards.

You can set two properties in the Relationship Editor to control this relationship.

• Containing. Select this option to contain one object within another as a Nested Object.
• Parent is Container. Select this object to denote the direction of containment.

Generating the Physical Model (MongoDB)

The Generate Database wizard differs for each target platform, but for MongoDB models, there are the options as shown in the following image.

You can remove propagated Foreign Key properties from generated objects or make them as native fields, which may be useful later to connect objects together elsewhere via code.

The How should Collections be created from Logical Entities option lets you choose how you want to create Collection. The following options are available:

• Convert All Entities. Use this option to make all logical entities into Collections.
• Convert Entities with PKs. Use this option to make all logical entities with primary keys into Collections.
• Leave All as Nested Objects. Use this option to make all logical entities into Nested Objects.
• Convert if Not Contained. Use this option to take a rules-based approach as detailed below.

Understanding the Convert if Not Contained option

If you select Convert if Not Contained, the generator wizard uses the following steps:

1. For each entity in the logical model, create an object. Primary key attributes become standard fields.
2. Logical relationship lines generate either a referencing relationship or a containment relationship.
3. For each generated object, the wizard reviews whether the object has a containing relationship from any other object. If it does, it becomes a Nested Object. If not, it becomes a top-level Collection.
4. All Collections are given a surrogate primary key "_id".
5. For referencing relationships, primary keys are propagated.

For the above logical model, we would generate the following model using this logic.

Notice the following traits in the above model:

• Note the borders of the objects. Collections have square corners and Nested Objects have rounded corners.
• We created four Collections: book, patron, library, and publisher. The other entities have generated Nested Objects.
• The entities section and chapter are nested inside book.
• address is fully denormalized as nested objects inside publisher, library, and book.
• checkout is nested inside book, but retains references to the Collections library and patron.

Understanding why you didn't get what you wanted

Once you generate your physical models, you will see a structure of objects with Collections and Nested Objects based on the rules used by the wizard. If you don't get what you expect, you have the following options:

1. Modify the Containment properties in the logical model and use the Compare/Merge between the logical and physical to propagate the changes.
2. Modify the Physical model directly. Use the Switch Object Class tool on the Insert tab of the ribbon bar to convert a Collection to a Nested Object and vice versa. You can then propagate changes back to the logical model.

Using the Rolled-Up View

The object view is useful to understand the reuse of objects and to edit the cardinality to Nested Objects. You can also select a "rolled up" rendering of the model that makes it easier to visualize the hierarchical nature of the model. To access this view

1. On the Diagram tab of the ribbon bar, select Diagram/Display Options.
2. On the Object tab, select Roll Up Contained Objects.

The MongoDB model we generated above now looks like this:

Notice that the Nested Objects are rolled up into the parents.

Rapidly creating a Hierarchical Physical Model

You may want to bypass the process of creating a logical model and jump straight to creating a physical model. You can use compare/merge functionality to later create your logical model.

To rapidly create a Hierarchical Physical Model

1. Create a new model, and then add an entity into the logical model.
2. Generate a Physical model for the MongoDB platform.
3. Insert objects onto the physical model directly using the Insert tab on the ribbon bar.
4. Insert fields directly into the objects just using the keyboard by pressing Shift while right-clicking inside of the object. This action opens a text box.
5. Type the name of the field, and then press the Enter key. A dialog appears allowing you to select the data type of the field.
6. Select string, and then press Enter to create the field. A new text box appears.
7. Type a name, and then press Enter.
8. In the datatype selection box, select Object and select the array checkbox.
9. Press Enter. A dialog appears allowing you to create a new reusable Nested Object.
10. Click Yes.
11. In the next new field, specify a name for the new field but before you press Enter, press the Tab key. This action indents the field, making a field of the object you just created. Now press Enter, and then specify the data type of the field.

As you build up your model you can move or copy fields across the model using the Move tool to move fields or with the Control key to copy fields.

See Also

• Tutorial: Denormalizing the Physical Model
• Developing the Physical Model
• Transforming Model Objects from Logical to Physical