Chat now with support
Chat with Support

Toad Data Modeler 7.2 - User Guide

Introduction User Interface Models and Model Objects
Physical Data Model
Entity Relationship Diagram Objects Basic Database Design Advanced Database Design
Universal Data Model Logical Data Model Working with Model Objects
Features and Tools
Application Variables Export/Import DDL Script Generation Graphics Model Actions Print Create New Project Reports Reverse Engineering Scripting and Customization About Templates Tips and Tricks Toad for Oracle Integration Toad Intelligence Central (TIC) Integration Tools Version Control
Options and Configuration Databases
Amazon Redshift 1.0 IBM DB2 LUW 9.5 IBM DB2 LUW 9.7 IBM DB2 LUW 10.1 IBM DB2 LUW 10.5 IBM DB2 LUW 11.1 IBM DB2 z/OS 10 IBM DB2 z/OS 11 Greenplum 4.1 Greenplum 4.2 Ingres 9.3 Ingres 10.0 EDB Postgres Advanced Server 10 Microsoft Access 2007/2010 Microsoft Azure SQL Database V12 Microsoft SQL Server 2005 Microsoft SQL Server 2008 Microsoft SQL Server 2012 Microsoft SQL Server 2014 Microsoft SQL Server 2016 Microsoft SQL Server 2017 Microsoft SQL Server 2019 MySQL 5.0 MySQL 5.1 MySQL 5.5 MySQL 5.6 MySQL 5.7 MySQL 8.0 Oracle 10g Oracle 11g Release 1 Oracle 11g Release 2 Oracle 12c Release 1 Oracle 12c Release 2 Oracle 18c Oracle 19c PostgreSQL 9.0 PostgreSQL 9.1 PostgreSQL 9.2 PostgreSQL 9.3 PostgreSQL 9.4 PostgreSQL 9.5 PostgreSQL 10 PostgreSQL 11 PostgreSQL 12 SQLite 3.7 Sybase ASE 15.5 Sybase ASE 15.7 SAP ASE 16.0 Sybase IQ 15.2 Sybase SQL Anywhere 11 SAP SQL Anywhere 17 Teradata 13 Vertica Database 8.0
Copyright Legal Notices

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


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:

  1. Open Model A.
  2. Select Model | Export Dictionary.
  3. Save the .txi file.
  4. Open Model B.
  5. Select Model | Import Dictionary.
  6. Select the .txi file and click Open.


  • 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.


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.2\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



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



,  ,   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

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating