Export/Import Dictionary
Toad Data Modeler allows you to use dictionary items also in other models. You can simply export all of them to the .TXI file, and then import them to any model at any time. You can save the .TXI file where you want, no default path is defined.
Dictionary items are:
- User Data Types
- Dictionary Types
- Domains
Domains
They have only a logical meaning. They are not generated in DDL/SQL script. If a domain is used in attribute, only values of the domain are transferred to the attribute during the DDL script generation process.
User Data Types
They are data types defined by users and can be generated in final DDL script. User data types are not derived from data types.
Dictionary Types
They are data types that are derived from other data types. They can be generated in final DDL script.
How to Export/Import Dictionary
You want to use dictionary items of Model A in Model B:
- Open Model A.
- Select Model | Export Dictionary.
- Save the .txi file.
- Open Model B.
- Select Model | Import Dictionary.
- Select the .txi file and click Open.
|
|
Note:
- Domain Check Constraints are imported/exported too.
- It's not possible to make selection of the dictionary items for the import/export. All the dictionary items are always imported/exported at one jump.
|
Relationships
Toad Data Modeler allows you to design Entity Relationship Diagrams of specific database platforms, convert physical model from one database platform to another, create an ER Diagram directly from your database (Reverse Engineering feature), update physical models, generate DDL/SQL scripts and Change Scripts, create Dictionary Types, Views, Triggers, Functions, generate detailed documentation to your model (in HTML, RTF, PDF, XSLT formats) and much more.
This chapter describes features and functions related to Physical Data Modeling. Look around each section to get the information you need.
|
|
Note: See the sample physical model Videorental (Oracle 10g db) that is included in the installation package of Toad Data Modeler. Default location is: C:\Program Files (x86)\Quest Software\Toad Data Modeler7.3\Samples. |
Benefits of Physical Data Model
- Detailed definition of database structure, including database specific items, for example:
- Stored procedures
- Functions
- Triggers
- Views
- Materialized views
- Sequences (auto increments) etc.
- Possibility to synchronize local model with existing database.
- Possibility to specify logical names for objects (captions for tables, attributes and other objects).
- Detailed database specific information can be exported to HTML/RTF/PDF or XML/XHTML/CSV reports.
- Automatic generation of SQL code for selected objects (SQL code generation is not available in Logical and Universal Model)
- Automatic migration of PK attributes to child entities (Attributes don't migrate to child entities in Logical Model)
Notation and Cardinality
IE Notation
Cardinality
One-to-many relationship is represented by this symbol: 
One-to-one relationship is represented by this symbol: 
Parent: mandatory Child: mandatory
Parent: mandatory Child: optional
Parent: optional Child: mandatory
Parent: optional Child: optional
IDF1X Notation
Cardinality
, 
, 
zero, one or more
one or more
zero or one
Parent: mandatory Child: mandatory
Parent: mandatory Child: optional
Parent: optional Child: mandatory
Parent: optional Child: optional
See Synchronization of Not Null and Mandatory Parent for more information.
Relationship Types
Identifying Relationship
Non-identifying Relationship
Non-identifying Self-relationship
M:N Relationship
Relationship Types
Toad Data Modeler supports the following relationship types (physical model):
- Identifying
- Non-identifying
- Self-relationship for non-identifying relationship
- M:N relationship
Identifying Relationship
Primary key migrates from parent entity to child entity and there becomes a part of the primary key. It is used when the primary key of the child entity is unable to provide definite identification.
An entity, connected with a parent entity through an identifying relationship, is called "dependent" entity and is shown in a model with rounded corners.
The Order Record entity cannot exist itself. It is dependent on entities Customer and Film. Therefore the Identifying relationship is used. The Order Record entity is a dependent entity, and the Customer ID and Movie ID items are its unique record identifiers.
Non-Identifying Relationship
Primary key migrates from parent entity to child entity and does not become a part of the primary key. Non-identifying relationships are represented by dashed lines. In the dependent table, the attribute is referred to as a foreign key.
The Film ID as the unique identifier for Film is sufficient. Therefore the non-identifying relationship is used. The Genre ID is only a foreign key. The film can exist without being assigned to a genre, therefore the Film entity is an Independent entity.
Self-Relationship for Non-identifying Relationship
M:N Relationship
