Migration of Keys
In Logical model, keys do not migrate from parent entities to child entities. In Logical model, only logical information is available. The relationships have only a logical meaning (-> FKs do not migrate). However, in Physical model the information on foreign keys is necessary. Therefore when you convert your logical model to a physical model, foreign keys will be displayed properly in the physical model.
Linking Method
Before you start the LER to PER conversion, you can select a linking method in relationships in your LER model. See the following example and the differences after the conversion to PER model:
Example: Department entity has two unique identifiers (non-identifying relationship).
a) UI1 has been selected.
Result after Conversion to Physical Model
- Department ID FK is now in the Employee table (child table).
- Alternate key has been created in the PER model automatically.
b) UI2 has been selected in LER model.
|
|
Note: In previous Toad Data Modeler versions, during conversion to physical model, primary key was always selected for the relationship as a parent key. Now you can select also alternate key (e.g. UI2) and opposite foreign unique identifiers. |
Result after Conversion to Physical Model
- Department ID and Department Name FKs are now in the Employee table (child table).
- Alternate key has been created in the PER model automatically.
See the Relationship Properties dialog | Foreign Keys tab in PER model after conversion:
LER to PER Conversion - Self-Relationship
If there is a self-relationship in LER model, the entity has two columns, both of the same name (primary key), in converted PER model. Other modifications are necessary.
Possible solution: You can define a name for the propagated attributes in LER model before the conversion. Open the Attribute Properties dialog | General tab | enter the name to the Propagated Name box.
If this box is empty, Toad Data Modeler will behave standardly (two columns of the same name in PER model).
|
|
Note: It is also possible to set a self relationship attribute name and caption for PER model in Settings | Options | Physical Model | Self Relation Attribute Name, Caption. |
Inheritance
Inheritance is a special abstract object which can be used in early phases of database development to visualize the inheritance process.
However, Inheritance is only supported in Logical Model. When converting Logical Model to Physical Model, Toad Data Modeler resolves Inheritance one of the three ways:
- Single Table
- N - 1 Tables
- N Tables
Before you convert your Model, you have the option to pick one of the three ways to resolve all Inheritance objects:
- Double-click the Inheritance and select tab Generation.
- In the Physical Implementation area, select any of available options:
a) Single Table - Parent Inherits All Children
The conversion output is the following:
b) N - 1 - Each Child Inherits the Parent
The conversion output is the following:
c) N Tables - Physical Model Matches Logical
The conversion output is the following:
|
|
Note:
Single Table Generation (Parent Inherits All Children), Discriminator for Child Entities is Set - After the conversion, a check constraint will be created in parent entity in PER model. This check constraint determines conditions for setting Not Null value of attributes taking into account options set in Discriminator.
- Inheritance Exclusive, N - 1 Generation (Each Child Inherits the Parent) - During the conversion, all attributes of parent entity will be passed to child entities and triggers will be created in the child entities. These triggers determine creation of new items in child entities. - Rule: it is not possible that two child entities with the same key of parent entity would exist.
- N Tables Generation (Physical Model Matches Logical) - Instead of inheritance, relationship (identifying by default) will be created between parent and child entities in PER model.
- Inheritance conversion - Relationship names are made unique in physical model.
- N - 1 Tables - Each Child Inherits the Parent: Relationship name_number (e.g. Relationship1_1, Relationship1_2)
- N Tables - Physical Model Matches Logical: Parent Entity Name_Child Entity Name
|
Defaults
Toad Data Modeler allows you to design and maintain a logical model giving a complete picture of the business area. Logical model is independent of the database platform and is much simpler than physical model. It uses objects such as inheritance, valid values or M:N relationships. From the Logical ER (LER) diagram, you can build a Physical ER (PER) diagram of the selected database platform (LER to PER conversion).
|
|
Note:
- This topic contains information on objects and functions that are specific for logical modeling. General information and other features applicable in Logical model as well as in Physical model are contained and described in other sections of this Help file. See e.g. the "Model Objects" chapter, "Model Explorer" topic etc.
- See the sample logical model Employee that is included in the installation package for Toad Data Modeler. Default location is: C:\Program Files\Quest Software\Toad Data Modeler\Samples.
|
To create a logical model
Select File | New | Model |Logical Data Model tab.
Benefits of Logical Data Model
Logical Data Model allows you to model inheritances in entity relationship diagrams. Universal Data Model and Physical Data Model do not support this feature.
Specifics of Logical Data Model
- There are three methods how inheritance can be resolved when converting to physical model.
- Attributes do not migrate to child entities.
- It is not possible to define database specific items in Logical Model, for example sequences/autoincrements etc.
- You can define Valid Values in logical model (will be converted to physical model).
Benefits of Super and Sub Types
In Logical Model you can define database structure in various ways. See the pictures below. Both of them show a structure modeled in Logical Model and both the models will result in the identical output when converted to Physical Model. The difference is that Model A uses Super and Sub Types while Model B doesn't use inheritance at all.
Model A - Utilizing Super and Sub Types
Model B - Lacking Super and Sub Types
This example shows:
- That you can create logical models in different ways and achieve the same result after conversion to physical model.
- That you can be more productive when using inheritance. For example, you only need to change the Last Name attribute once in the first model. Without using inheritance in model B, you have to change it four times.
- How much “readable” the first model is compared to the second one.
- How important is to select appropriate inheritance resolution when converting your logical model to physical.
- That creating logical models without inheritance has minimal benefits compared to using inheritance.
Disadvantage
The main disadvantage of logical modeling is that direct synchronization with existing database is not possible. Only physical models of specific database platforms and versions may be synchronized with an existing database. Therefore, if you want to synchronize your logical model, you need to convert it to the physical model first.
Defaults
To add a default
Select Model | Model Items | Defaults and click Add in the Defaults dialog.
To edit a default
Select Model |Model Items | Defaults and double-click the selected default or click Edit.
|
|
Note: You can also edit/rename/delete defaults in Model Explorer | Defaults folder | Right-click the selected default. |
To select a default for attributes
- Open the Attribute Properties dialog of the selected attribute | General tab.
- From the Default Rule box, select a default or write your own default to the Default box.
|
|
Note: You can define defaults for domains too. |
