This is the abstract parent (which we can't
query) for the things we can query that are its
subtypes. An Abstract Entity represents things in
the model that can own Attributes. These are
either Views or Entities.

We have to query both Views and Entities to get a
complete answers to many questions involving
Attribute ownership.

This is the abstract parent (which we can't
query) for some of the things we can query that
are its subtypes (or their subtypes).

It represents things in the model that are
included as part of Subject Areas and can be
parents or children for Relationships.

Abstract Model Node is either:
Subtype Symbol or Abstract Entity

An Abstract Object is the ultimate supertype
accessible for ERwin queries. It includes a
reference for everything in the model that has an
Id@ and Type@ attribute. 

Even though you can query Abstract Object, you
can't really join using any column other than Id@
so it is about useless.

The prefix EM0 references a design level to
ERwin. Basically, it means that every attribute in
the parent M0 Entity can be directly referenced
from the EM0 level. Note that it is a zero, not
the letter 'O'

The Logical Entity subtype references all
entities that are part of the logical stored
display. This includes entities that are tagged as
logical only as well as entities that are both
logical and physical. Use it in queries where you
want to know about entities that appear in logical
diagrams.

The prefix EM0 references a design level to
ERwin. Basically, it means that every attribute in
the parent M0 Key Group can be directly referenced
from the EM0 level. Note that it is a zero, not
the letter 'O'

The Logical Key Group subtype references all key
groups that are part of the logical stored
display. This includes key groups that are tagged
as logical only as well as key groups that are
both logical and physical. Use it in queries where
you want to know about key groups that appear in
logical diagrams.

The prefix EM0 references a design level to
ERwin. Basically, it means that every attribute in
the parent M0 Relationship can be directly
referenced from the EM0 level. Note that it is a
zero, not the letter 'O'

The Logical Relationship subtype references all
relationships that are part of the logical stored
display. This includes relationships that are
tagged as logical only as well as relationships
that are both logical and physical. Use it in
queries where you want to know about relationships
that appear in logical diagrams.

The prefix EM0 references a design level to
ERwin. Basically, it means that every attribute in
the parent M0 Entity can be directly referenced
from the EM0 level. Note that it is a zero, not
the letter 'O'.

The Physical Entity subtype references all
entities that are part of the physical stored
display. This includes tables that are tagged as
physical only as well as entities that are both
logical and physical. Use it in queries where you
want to know about tables that appear in the
physical model.

The prefix EM0 references a design level to
ERwin. Basically, it means that every attribute in
the parent M0 Key Group can be directly referenced
from the EM0 level. Note that it is a zero, not
the letter 'O'

The Physical Key Group subtype references all key
groups that are part of the physical stored
display. This includes key groups that are tagged
as physical only as well as key groups that are
both logical and physical. Use it in queries where
you want to know about key groups that appear in
physical diagrams.

The prefix EM0 references a design level to
ERwin. Basically, it means that every attribute in
the parent M0 Relationship can be directly
referenced from the EM0 level. Note that it is a
zero, not the letter 'O'

The Physical Relationship subtype references all
relationships that are part of the physical stored
display. This includes relationships that are
tagged as physical only as well as relationships
that are both logical and physical. Use it in
queries where you want to know about relationships
that appear in physical diagrams.

The ERwin metamodel treats subtypes as objects
that belong to a different design level. The
objects at design level M0 can use subtypes to
specify objects at design level EM0. The subtype
is a filter for a particular class of M0 level
objects. The EM0 level can participate in all the
same relationships as the M0 level objects. 

A Logical Attribute is an Attribute that can
appear on a logical display. This includes
attributes that are both logical and physical and
those that are tagged as Logical Only. If you
select * from EM0.Logical Attribute you will get
all the attributes of the parent Attribute
including those related to physical
characteristics.

The ERwin metamodel treats subtypes as objects
that belong to a different design level. The
objects at design level M0 can use subtypes to
specify objects at design level EM0. The subtype
is a filter for a particular class of M0 level
objects. The EM0 level can participate in all the
same relationships as the M0 level objects. 

A Physical Attribute is an Attribute that can
appear on a physical display. This includes
attributes that are both logical and physical and
those that are tagged as Physical Only. If you
select * from EM0.Physical_Attribute you will get
all the attributes of the parent Attribute
including those related to logical
characteristics. For example, the name
characteristic of a Physical Attribute is its
logical name.

An Entity To Entity Relationship links two
instances of an Entity or two different Entities.
The Relationship Type may be Identifying or
Non-Identifying.

An Entity to Entity Relationship always has a
Parent Key Group which describes a primary key or
an alternate key for the Parent Entity of the
Relationship. It also has an FK Key Group which
describes the Foreign Key for the Child Entity of
the Relationship.

An Entity to View Relationship links a parent
Entity to a child View. This means that the child
View derives one or more columns from the parent
Entity or uses columns from the parent Entity to
determine the content of the child View.

There is never an FK Key Group associated with an
Entity to View Relationship.

There may be a PK Key Group associated with an
Entity to View Relationship if the View had a
where clause requiring a key join.

An Entity to View Relationsship links one one
parent Entity with one child View.

A parent Entity can be linked to any number of
child Views via Entity to View Relationships.

A child View can be linked to any number of
parent Entities via Entity to View Relationships.

Subtype of Key Group for Foreign Keys. This is
the type of group that describes the child
attributes that serve as a foreign key pointer to
a parent key group belonging to the parent entity
for the relationship.

To navigate to a FK Key Group from a
Relationship:
join M0.Key_Group FK_Key_Group
 on Relationship.Id@ =
FK_Key_Group.Relationship_Ref
This won't work for Parent to Subtype
Relationship or any of the View Relationships
because they don't have foreign key connections.

For a given FK Key Group there is one
Relationship.
For a given Relationship there are zero or one FK
Key Group.

Inverted Index key group. The purpose of this
type of key group is to provide a way to describe
optimizing indexes in a database environment like
that of Oracle. Netezza uses a different
organizationsl strategy so we no longer use these
to generate indexes.

An ERwin Attribute contains all relevant
information about a Logical Attribute and a
Physical Column.

An Attribute is owned by one Abstract Entity
An Abstract Entity may own any number of
Attributes

An attribute is a child of one Domain
A Domain may be parent to any number of
Attributes

An (FK) Attribute has one Parent Attribute 
A Parent Attribute may have any number of Child
(FK) Attributes

Data_Movement_Source provides a place to record
the characteristics you specify when you complete
the General and Definition tabs of a Data
Warehouse Sources dialogue box. For each
Data_Movement_Source (which is specified by a
Source Name) you can also assign a System Name and
a Host Name.
This is useful for classifying complex source
systems and for clarifying source systems that
consist of various software packages that often
serve as input to data warehouse applications.

Data_Movement_Column provides a place to record
information that you enter when you specify the
contents of the Columns: listbox in the Detail tab
of the Data Warehouse Sources dialogue box or
import a .csv file or other source for the
information.
It is the most granular level of the Data Source
Structure. Normally it describes a column in a
Data Movement Source table or spreadsheet.

Data_Movement_Table provides a place to record
information that you enter when you specify the
contents of the Tables: listbox in the Detail tab
of the Data Warehouse Sources dialogue box or
import a .csv file or other source for the
information.

The Data Sources Ref table is an implementation
of a vector datatype that links an Attribute a
Transform_Scratch_Object with all of its data
source columns. The basic link is from an
Attribute to one or more Data Movement Columns.
The link is established when you use the Data
Warehouse Source Selector dialogue box to select
one or more columns from the Available Sources:
dropdown list as Selected Data Sources: for a
column. You get to the Data Warehouse source
Selector dialogue box by selecting the ... button
on the Data Source tab of the Columns dialogue
box.

For a given Attribute there are zero or more Data
Movement Columns linked via Data Sources Ref.
For a given Data Movement Column there are zero
or more Attributes linked via Data Sources Ref.

In our model each attribute is assigned a Domain
in order to provide standard definitions for
column data types. 

For a given Domain there may be zero or one
Parent Domain
For a given Parent Domains there can be any
number of children.

For a given Domain there may be any number of
Attributes.
For a given Attribute there are zero or one
Domain.

M0.Entity is the detail level for information
about an entity including all table information.

History Information provides access to the Types
of history specified in the History Options tab of
the Model Properties page in ERwin. It specifies
the creation times of various objects in the
model.

A Key Group provides a basis for keeping track of
attributes used as identifiers, indexes and
linkages within and among entities. There is a key
group for each primary key and alternate key of an
entity. There is also a key group for each
inverted index specified for an entity. And there
is a key group for each foreign key relationship
between and among entites. 

There is no key group for any relationship that
involves a View.

A Key Group Member provides a way to describe the
behavior of an attribute that participates as a
member of a key group. This includes information
about which key group it is part of and how it is
organized relative to other members of the same
key group.

A Key Group Member links one Key Group with one
Attribute. 
For a given Key Group there can be any number of
Key Group Members each of them linking to one
attribute.

For a given Attribute there can be any number of
Key Group Members each of them linking to one Key
Group

Referenced Entities Ref defines the association
betwee .Subject Areas and Abstract Model Nodes. 

For a given Subject Area there may be any number
of Abstract Model Nodes.
For a given Abstract Model Node there may be any
number of Subject Areas.

Note: For our purposes an Abstract Model Node is
an Entity, a Subtype Symbol or a View.

A Relationship describes the association between
two or more occurrences of one or more Abstract
Model Nodes. It provides a place to keep track of
forward engineering rules and various kinds of
definitions

A Relationship has one Parent Abstract Model Node
which can be an Entity, a Subtype Symbol or a View

An Abstract Model Node can be the parent of many
Relationships.

A Relationship has one Child Abstract Model Node
which can be an Entity, a Subtype Symbol or a View

An Abstract Model Node can be the child of many
Relationships.

A Subject Area is a collection of model objects.
In a non-trivial model it makes sense to partition
large  models into sets of related model objects.
Usually the basis for grouping things into a
subject area involves business or application
related things that make sense as a group.

Although we normally think of a Subject Area as
being made up of a collection of entities, in the
ERwin metamodel it is a collection of Abstract
Model Nodes. (An Abstract Model Node is an Entity,
a Subtype Symbol or a View.) For a given Subject
Area there may be any number of Abstract Model
Nodes linked via M0.Referenced Entities Ref. 

For a given Abstract Model Node there may be any
number of Subject Areas linked via M0.Referenced
Entities Ref.

For a given Subject Area there may be any number
of Relationships linked via M0.Referenced
Relationships Ref as long as the Abstract Model
Node referenced by the Parent Entity Ref or the
Abstract Model Node referenced by the Child Entity
Ref or both are also in the Subject Area.

For a given Relationship there may be any number
of Subject Areas linked via M0.Referenced
Relationships Ref as long as the Abstract Model
Node referenced by the Parent Entity Ref or the
Abstract Model Node referenced by the Child Entity
Ref or both are also in the Subject Area.

A Subtype Symbol is an Abstract Model Type that
is included in Subject Areas and can participate
in Relationships.

A Subtype Symbol can be the Parent Entity Ref or
the Child Entity Ref in a Relationship but it
cannot be both parent and child for a single
relationship.

It is important to understand how Subtype Symbols
work if you need to follow a path from a child to
a parent entity via the intervening relationships.
This can be critical when you are designing and
debugging Forward Engineering Templates (fet).

The Aggregation_Type table exposes the ownership
relationships between rows in the Object_Type
table.

Example Usage:
select  tran(Owning_Object_Ref)
           ,tran(Owned_Object_Ref)
           ,Name
from M1.Aggregation_Type
where tran(Owning_Object_Ref) = 'Attribute'
  and  tran(Owned_Object_Ref) not like '%Oracle%'

   and  tran(Owned_Object_Ref) not like
'%SQLServer%'

Association Type is a many to many relationship
linking Property Type and Object Type. Depending
on the Property Type the relationship has a
different meaning. 

Example for Reference Property Types:
For a given Reference Property_Type there may be
any number of Object_Types that can be referenced
by the ID@ column of the Vector Table via
Association_Type.

For a given Object_Type there can be any number
of Property_Types that identify the Vector Table
for a given Object_Type via Association Type.

Example for UDP Property Types
For a given UDP Property Type there is normally
one Object Type linked via Association Type.
For a given Object Type ther may be any number of
UDP Property Types linked via Association Type.

-- Meta Query Property Type Ref Vector
Participants.qry
select Name
         ,tran(Participating_Object_Ref)  'Vector
Attribute Owner (Id@)'
         ,tran(Referenced_Type_Ref)   
'Referenced type (Value@)'
from M1.Property_Type
join M1.Association_Type
  on Id@ =Participating_Property_Ref
where Tag_Is_Reference = 'T'
  and tran(Data_Type) = 'Short Id Vector'
order by Name
             ,tran(Participating_Object_Ref)

The OBJECT_TYPE table contains information about
the types of objects permitted in a CA ERwin DM
model. In other words, rows in this table will
correspond to tables exposed by the M0 schema.

The PROPERTY_TYPE table contains information
about the types of properties permitted in a CA
ERwin DM model. In other words, rows in this table
will correspond to columns on M0 tables (for
scalar properties) or to M0 tables (for vector
properties). -- official pitch.

So far the Property Type table has been useful
for understanding Vector Properties and User
Defined Properties. 

It is the only place anywhere that gives you a
lever into even discovering what Vector Properties
exist and what they reference. The Name of the
Property_Type is the name of the Vector table in
the Meta Model. The Referenced_Type_Ref tells you
the Object that is referenced by the Value@ column
of the Vector Table.

It was only through the use of this reference
that we were able to even find the name of the
Data_Sources_Ref table that is essential for
linking Attributes to their Data_Movement_Column
references which in turn link to
Data_Movement_Table and Data_Movement_Source
tables. It was the key to the kingdom as far as
that goes.

A Parent To Subtype Relationship is the first
part of a two part Relationship to describe a
Supertype/ Subtype structure. It links an Entity
playing the role of supertype to a Subtype Symbol 
that will, in turn be linked to one or more
Entities playing the role of Subtype.

Parent to Subtype Symbol is a kind of Subtype
Symbol used to link a parent supertype entity to a
Subtype Symbol.

Subtype of Key Group for Primary and Alternate
Keys. These are the key groups describing unique
identifiers that may serve as parent key groups
for relationshipes. 

For a given PK AK Key Group there may be any
number of Relationships.
For a given Relationship there is always one PK
AK Key Group.

An Entity playing the role of a Subtype Entity
participates in a Subtype Symbol related
Relationship as the Child Entity Ref.

A Subtype FK Key Group always points to a Subtype
to Child Relationship which, in turn links to the
Supertype PK Key Group for the Subtype. The
Subtype FK Key Group describes the foreign key in
the subtype that is inherited from the primary key
of the Supertype Entity with the role names used
by the Subtype.

A type of Subtype Symbol used to link a Subtype
Symbol to a Subtype Entity in a Relationship.

A Subtype To Child Relationship is the second
part of a two part Relationship to describe a
Supertype/ Subtype structure. It links a Subtype
Symbol that is linked to an entity playing the
role of supertype in a different relationship to
an Entity playing the role of subtype for this
one. 

For a given Subtype To Child Relationship there
is one Subtype Symbol that links to the supertype
Entity for the whole thing. 
For a given Subtype Symbol there may be any
number of subtype Entities.

A Subtype to Child Relationship refers to the PK
AK Key Group of the supertype Entity. 

For a given Subtype To Child Relationship there
is one FK Key Group that describes the foreign key
portion of the Subtype Entity. For a given FK Key
Group there are zero or one Subtype To Child
Relationships.

An Entity playing the role of Supertype in a
multityping relationship. It always plays the role
of Parent Entity for a Relationship linking to a
Subtype Symbol.

A PK Key Group for the Supertype Entity in a
multityping Relationship. For a given Supertype
all of its Subtypes use the same Supertype PK Key
Group.

A View Source Entity is one that serves as a
source for one or more columns in a View. Since a
PK AK Key Group is not necessarily linked to the
Entity To View Relationship, it is problematic to
identify the access path to the view from the
Entity. Normally you can assume it will be a key
or an alternate key.

In order to find which attributes from the Source
Entity are used by a view, select the Attribute
from the View and navigate to the Parent Attribute
Ref which will have a pointer to the Source Entity
in its Owner@ column.

A View to View Relationship links a  parent View
to a child View. This means that the View derives
one or more columns from the parent View or uses
columns from the parent View to determine the
content of the child View.

There is never any Key Group associated with a
View to View Relationship.

A View to View Relationsship links one one parent
View with one child View.

A parent View can be linked to any number of
child Views via View to View Relationships.

A child View can be linked to any number of
parent Views via View to View Relationships.

Standard reference to type. If you could actually
write a query against Abstract Model Node it would
include:
tran(Type@)  = Entity
tran(Type@)  = View

Standard reference to type. If you could actually
write a query against Abstract Model Node it would
include:
tran(Type@)  = Entity
tran(Type@)  = Subtype Symbol
tran(Type@)  = View

The name of the Abstract Model Node. Presumably
this will be the same as the name of an instance
of a subtype Entity, Subtype Symbol or View.

Same as Comment in subtype Entity, Subtype Symbol
or View

The ID of the object in the model. This is the
short ID of an object, which is unique in the
model, but may change from session to session.

The name of the object. For a dual object, this
will be the logical name.

The long ID of the object. This is the permanent
ID assigned to each object in a CA ERwin DM model.

Standard Identifier for an Entity. This is the
standard Id@ used for all descendents of abstract
model objects.

Standard Identifier for an Entity. This is the
standard Id@ used for all descendents of abstract
model objects.

Indicates whether the Logical Only box has been
checked for the entity.
Values:
  'T' - box has been checked.
 blank - box is not checked
  'F' - box was unchecked
This comes from the Logical Only checkbox on the
Entities dialogue box invoked by clicking on the
Entity Properties... option.

Indicates whether or not the Logical Key Group is
owned by a Logical Only Entity or in the case of
type FK the parent relationship is tagged as
Logical Only.
Values:
  T - Logical Only
  F - Changed from Logical Only 
null - not set

The identifier for the Relationship. This is the
standard Id@ used for all descendents of abstract
model objects.

Indicates that the relationship appears only on
the logical stored display.

Standard Identifier for an Entity. This is the
standard Id@ used for all descendents of abstract
model objects.

Indicates whether the Physical Only box has been
checked for the table.
Values:
  'T' - box has been checked.
 blank - box is not checked
  'F' - box was unchecked

Indicates whether or not the Physical Key Group
is owned by a Physical Only Entity or in the case
of type FK the parent relationship is tagged as
Physical Only.
Values:
  T - Physical Only
  F - Changed from Physical Only 
null - not set

The identifier for the Relationship. This is the
standard Id@ used for all descendents of abstract
model objects.

Indicates that the relationship appears only on
the physical stored display for a subject area.

Indicates whether the Logical Only box has been
checked for the Logical Attribute.
Values:
  'T' - box is checked.
 blank - box is not checked
  'F' - box was unchecked

Indicates whether the Physical Only box has been
checked for the Column
Values:
  'T' - box is checked.
 blank - box is not checked
  'F' - box was unchecked

Attribute(s) of "Entity To Entity Relationship"
Entity

The identifier for the Relationship. This is the
standard Id@ used for all descendents of abstract
model objects.

Pointer to the Parent Entity Reference for the
Relationship.

Pointer to the Child Entity Reference for the
Relationship.

Pointer to the Key Group that describes the
primary key or an alternate key for the
relationship.

Attribute(s) of "Entity To View Relationship"
Entity

Pointer to the Parent Entity (Table) which
provides one or more columns to the View.

The Child Entity for an Entity to View
Relationship is a View.

Pointer to the Relationship that links the FK Key
Group to its parent PK AK Key Group.

Pointer to the Entity or View that owns the
Attribute.

Pointer to the Domain used as a basis for
establishing the logical and physical data types
for the Attribute.

If the Attribute is a foreign key this points to
the highest level parent Attribute of the foreign
key. Note that the Parent Attribute may or may not
have a different name.

Normally the Name is the same as the logical
attribute name. If there is no logical incarnation
of the attribute the name may be a macro-like
reference or simply the word Name.

This is the name that you normally see as the
logical name.
If there is no logical incarnation of the
attribute the name may be a domain reference. 

This column contains either a physical Attribute
name or a copy of the macro for generating an
abbreviated physical Attribute name. Be careful.
To expose a useful name, use the tran function:
  tran(Physical_Name)

This contains the contents of what you enter as
the Transform Comment when you specify the Data
Sources for a Column.

Use it to specify details of a transform.

Indicates whether the Logical Only box has been
checked for the attribute.
Values:
  'T' - box has been checked.
 null- box is not checked
  'F' - probably means box was unchecked
Use the following query to unambiguously test
this column:
  nvl(Is_Logical_Only,'F')

Indicates whether the Physical Only box has been
checked for the column.
Values:
  'T' - box has been checked.
 blank - box is not checked
  'F' - probably means box was unchecked
Use the following query to unambiguously test
this column:
  nvl(Is_Physical_Only,'F')

This is the Column Name you see listed in the
physical diagram containing the table that owns
the attribute. It may be hard coded or it may have
been generated by an abbreviating macro.

The Logical Data Type of the Attribute. This
should normally be the same as the Physical Data
Type.

The Physical Data Type of the Attribute. This
should be the same as the Logical Data Type.

Indicates whether an Attribute can be null.
Values:
   0 - Null
   1 - Not Null

The ordinal position of the Attribute within the
logical Entity. 

This will be null for Physical Only Attributes.

The ordinal position of the Column within a Table
displayed at the column level (with the primary
key at the top separated from the rest of the
columns).

The ordinal position of the Column within a Table
displayed at the physical order level. On a
reverse-engineered model this will exactly match
the column order in the database.

The logical Entity definition for the Attribute.

Indicates that the Attribute should not appear in
a Logical Stored Display.
Values:
    T  -  Don't display in logical
respresentation
    F  -   Display in logical respresentation

Indicates that the Attribute should not appear in
a Physical Stored Display.
Values:
    T  -  Don't display in physical
respresentation
    F  -   Display in physical respresentation

This will be replaced by Names of the actual list
of UDPs that you have defined for Logical
Attributes preceded by Attribute_Logical_.

This will be replaced by Names of the actual list
of UDPs that you have defined for Physical
Attributes preceded by: Attribute_Physical_.

The name of the Data_Movement_Source. This may be
the name of an existing system, a software package
or anything else that provides data for the
warehouse. 
This comes from the Source Name: list box in the
Data Warehouse Sources dialogue box.

Data_Movement_Source_System contains whatever you
entered in the System Name: panel of the Source
Information section of the Data Movement Source
panel.

Source: Host Name: text box in the General tab of
the Data Warehouse Sources dialogue box.
As a convention, this is a convenient place to
specify 'Netezza' for databases such as RDS.

The DBMS of the source. This is selected from a
dropdown list so there is no way to enter
databases such as Netezza that ERwin does not
directly support.
Source: DBMS Type: dropdown list in the General
tab of the Data Warehouse Sources dialogue box.

The definition for the data source. This is a
useful place to put warnings, caveats and all
that.
Source: Definition: text box in the Definition
tab of the Data Warehouse Sources dialogue box.

For a Data_Movement_Source this is normally the
name of the model.

The name of the Source Column. 
This comes from the  Name section of Columns:
listbox in Detail tab of the Data Warehouse
Sources dialogue box.
This may be entered in the dialogue box or
imported from a .csv  file or other source.

The definition of the source column. 
This comes from the Comment section of the
Columns: listbox in the Detail tab of the Data
Warehouse Sources dialogue box.
This may be entered in the listbox or imported
from a .csv  or other source.

The physical data type of the source column. This
can be especially important if the datatype of the
source column is different from that of the target
Attribute.Physical_Data_Type.
This comes from the Datatype section of the
Columns: listbox in the Detail tab of the Data
Warehouse Sources dialogue box.
This may be entered in the dialogue box or
imported from a .csv  or other source.

The ERwin Identifier for the row that represents
the Table that includes this Data_Movement_Column
as a Data Source.

The ERwin Identifier for the row that represents
a Table that is a Data Source.

The name of the table that you specify in the
Tables: listbox of the Detail tab of the Data
Warehouse Sources dialogue box or import from a
.csv file or other source.

Pointer to the Data_Movement_Source that owns the
Data_Movement_Table. This link is established when
you specify a table name in the Tables: list box
for a particular Source Name: in the Data
Warehouse Sources dialogue box.

Attribute or Transform_Scratch_Object that is the
owner of the Data Sources Ref

Sequencer for the list of source columns for the
parent Attribute. This is the discriminator for
the Data_Sources_Ref vector attribute

The ERwin identifier for a Domain. This is the
standard Id@ used for all descendents of abstract
model objects.

Id of the owner of the Domain. Normally this will
be 1 which resolves to EBI Master

Pointer to the parent Domain for the current
Domain. This provides the path for the
hierarchical domain reference in ERwin.

The Domain Name. Normally this is the same as the
User Formatted Name.

The logical Domain Name. In every case this is
the same as Name.

The Logical Data Type associated with the Domain.
In practice, this is the same as the Physical Data
Type.

The Physical Data Type associated with the
Domain. In practice, this is the same as the
Logical Data Type.

Standard Identifier for an Entity. This is the
standard Id@ used for all descendents of abstract
model objects.

The name of the entity. This will normally be the
logical name of the entity. In fact, if the entity
was created as a logical/physical entity and it
was later changed to physical only, this attribute
will still contain the original logical name. In
the case of Physical Only entities created as
tables it will be the Physical Name.

Indicates whether or not an entity/ table should
be generated. Logical only entities normally have
a value of 'F' so be careful with this.
Values:
  T - Do not generate
  F - Generate

Indicates whether the Logical Only box has been
checked for the entity.
Values:
  'T' - box has been checked.
 null- box is not checked
  'F' - probably means box was unchecked
Use the following query to unambiguously test
this column:
  nvl(Is_Logical_Only,'F')

Indicates whether the Physical Only box has been
checked for the table.
Values:
  'T' - box has been checked.
 blank - box is not checked
  'F' - probably means box was unchecked
Use the following query to unambiguously test
this column:
  nvl(Is_Physical_Only,'F')

For Oracle, this is the owner name. It can be
included in ddl by specifying the owner option in
the Other Options tab of the forward engineering
option set.

This column contains either a physical table name
or a copy of the macro for generating a physical
table name. Be careful. 

If you want to bullet-proof your queries use:
  tran(Physical_Name)

Unknown.

Indicates whether or not the Entity should be
shown in a logical stored display.

Indicates whether or not the Table should be
shown in a Physical stored display.

The physical table name. This may be hard coded
or the result of the naming macro transforming the
logical name to a physical one.

All User Defined Properties (UDPs) are included
as columns in the metamodel. Logical UDPs have the
prefix 
    Entity_Logical_
followed by the UDP name.

All User Defined Properties (UDPs) are included
as columns in the metamodel. Physical UDPs have
the prefix 
    Entity_Physical_
followed by the UDP name.

Standard Identifier for an Entity. This is the
standard Id@ used for all descendents of abstract
model objects.

Name for the row. This is typically something
like History_Event_nnnn where nnnn is a serial
number of some kind.

The path to the object that is of concern to this
row in History Information.

Model_Name
Model_Name.Entity_Name
Model_Name.Entity_Name.Attribute_Name

The time that the owning object was created. This
is a string like:
Thursday 20 March 2013:12:45:17

Description of how the History Information got
here.

Examples:
Created in Current Model
Migrated Foreign Key from xxxxx

Code for the type of History Event that triggered
this row in History Information. These come from
the checklist for the model in the Model
Properties Window.

select tran(History_Event_Type) 
from History_Information
     produces one or more of the following:
Created in the model
Created from a model source
Linked to a model source
Transformed
Migrated as a foreign key (FK)
Reverse engineered from a database
Imported from a previous version of ERwin DM
Split
Created by reversing a Transfom
Created by resolving a Transform
Imported via DB level compare
Imported from another model
Imported from a script file
Imported via the API

Pointer to the Entity that is the owner of the
Key Group.

The ERwin assigned name for the Key Group. It is
common practice to ignore this and use a more
meaningful Constraint Name as a reference.

You can use the Constraint Name to provide a
useful reference for Constraints on a table when
you generate ddl. You can assign each Key Group a
name that provides a meaningful reference to the
Table in the case of primary and alternate keys
and to the Tables that participate in the
relationships that establish foreign keys. A
common practice is to specify child table_parent
table_FK as a name for foreign key constraints.

This is an indicator to let the forward
engineering process determine whether to generate
an index.for the Key Group.

Indicates whether the Key Group should be
generated as a Constraint by the forward
engineering process.

Indicates whether the Key Group provides a unique
reference for the owning Table. This is normally
true for PK and AK key groups.

Indicates whether this Key Group describes the
primary index for the owning Entity for a Teradata
database.
Values:
   T  - Primary Index
 null - Does not apply

Key Group Type provides a code and a reference
that is itself a component of an alternate key for
the Key Group. The first two characters actually
identify the type. Except for type PK this may be
followed by a number that makes it unique within
the owning Table.

Type        Meaning
   PK         Primary Key
   AKn       Alternate Key
    IEn       Inverted Index (legacy Oracle)
    IFn        Foreign Key

Pointer to the Key Group that owns this Attribute
as a Key Group Member

Pointer to the Attribute that is a member of this
Key Group.

The Physical Name of the Attribute that is a Key
Group Member. This is preferable to the Name
attribute because it is always present in a
non-macro format.

The order in which the member occurs as part of a
logical key group. This will be null for physical
only indexes.

The order in which the key group member occurs as
part of a Physical Index key group. This will be
null for logical only key groups.

Attribute(s) of "M0.Referenced Entities Ref"
Entity

Subject Area Identifier that along with Sequence
Number forms the key for Referenced Entities Ref.

The Sequence Number, along with the Subject Area
Id provides a unique identifier for Referenced
Entities Ref.

Standard Identifier for an Entity. This is the
standard Id@ used for all descendents of abstract
model objects.

Attribute(s) of "M0.Referenced Relationships Ref"
Entity

Pointer to the Subject Area that owns the
Referenced Relationships Ref.

Serializer to simulate vector sequence for list
of Relationships.

Pointer to the Relationship that belongs to the
Subject Area pointed to by Id@

The identifier for the Relationship. This is the
standard Id@ used for all descendents of abstract
model objects.

Pointer to the Key Group describing the
identifiers for the Parent Node in the
Relationship. 
Relationship Type:
2 - Identifying Relationship
     This points to the Key Group that forms part
of the identifier for a Child Entity.
7 - Foreign Key Relationship
      This points to the Key Group that forms the
source for the Foreign Key group i n the Child
Entity.
9 - Subtype Relationship
     This always points to the Identifying Key
Group of the parent Entity for the Subtype
Relationship
16 - View Relationship
This will be null for View to View Relationships.

It may reference a PK Key Group if it is required
for a join that creates the view.

Relationship Type
  2  Identifying Relationship
  7  Foreign Key Relationship
  9  Subtype related relationship
      Parent Entity to Subtype Symbol
      Subtype Symbol to Child Entity
 16 View Relationship

User Formatted Name is a name present in every
relationship that kind of makes sense as a
referent for the relationship. It is the only
sensible name that you can get from the
Relationship itself.

The definition that appears in the relationship
in the logical stored display.

The Comment that appears in the physical stored
display for the relationship.

The text on the relationship line that may appear
on the logical stored display. This supports
multiple names for a relationship. We choose one
or the other, not both.

User Defined Property:
Role Name for Foreign Key Constraint. The last
character of the Role should be an underscore.
If there is more than one relationship between
the same two entities the Role is inserted in the
FK Constraint Name to distinguish one from the
other.

Example: Role = origin_
FK Constraint Name: shipment_origin_sic

Indicates whether the forward engineering process
should generate this relationship in the ddl.
Values Meaning
    F      Generate
    T      Do not generate

For Relationships involving Views this is the
Alias for the parent Entity or View name.

This will be replaced by Names of the actual list
of UDPs that you have defined for Logical
Relationships.

This will be replaced by Names of the actual list
of UDPs that you have defined for Physical
Relationships.

Subject Area Identifier. This is the standard Id@
used for all descendents of abstract model
objects.

Name of the Subject Area.
This comes from the New... or Rename... buttons
on the Subject Areas Dialogue box which take you
to a New Subject Area or Rename Subject Area
dialogue box.

The definition for the subject area. 
This comes from the Definition tab of the Subject
Areas dialogue box.

The name of the modeler who is responsible for
the Subject Area.
This comes from the Author : text box in the
General tab of the Subject Area dialogue box.

The date and time that the Subject Area was
created in the model.

The date and time of the last modification to the
subject area.

Indicates whether this subject area is the main
subject area.
Values:
   T - There is only one main subject area
blank
  or    Everything else.
null

Indicator to filter dangling relationships from
the Forward Engineering process. Dangling
relationships are foreign key pointers to entities
that are not in the current subject area.
Values:
    T - don't include dangling relationships
    F - Generate foreign key constraints for all
FK's.
This comes from a checkbox named Filter Dangling
Relationships from Schema Gen that is on the
General tab of the Subject Areas dialogue box.

The Name is always the same as the name of the
parent entity for relationships that the Subtype
Symbol participates in.

This is the physical name of the parent Table for
relationships that the Subtype Symbol participates
in.

Attribute(s) of "M0.Transform_Scratch_Object"
Entity

If there is a named constraint for the data
movement column it will be here.

Standard Identifier for the View. This is
inherited from an Abstract Object.

The (logical) Name for the View. Even though
Views only exist in the physical incarnation of
the model they have a logical name.

The Name of the View as it appears in the
physical stored display for the subject area.

This is the SQL that populates the View. It is in
the form of a select statement as modified by the
various clauses.
The SQL statement is populated by the Forward
Engineering Template that is currently specified
by the options set for the model. 

Radio buttons on View definition
Follows Select on query as in:
  select distinct . . .

Value Meaning
     1   All
     2   Distinct
     3   Unique

Indicates whether to use User Defined SQL or
Where Clause.

The query entered by whoever created the view to
specify its creation. This is a long text column
that is copied directly to the SQL column with no
validation.

The Where Clause from the View specification.
This is used to create the query in the SQL
column.

The definition you enter for the View. It is
called  a Comment in the ERwin View specification.

Indicates to the ddl generator to create or
replace an existing View.

This is the specification for the Group By clause
in the generated SQL

This is the having clause that normally follows a
group by in a query. It works as advertised.

If there are User Defined Properties for the View
they will follow this format::
     View_Physical_UDP_Name
where UDP_Name is replaced by the actual UDPs you
have specified for the model. They are always
physical for views.

Normally the name is formatted as follows:
Owning_Object__owns__Owned_Object

Pointer to the owning object.
--Example
Attribute owns History_Information
Attribute is the owning object

Pointer to the owned object.
--Example
Attribute owns History_Information
History_Information is the owned object

Reference to the Property Type that is linked to
an Object Type via Association Type. 
   property_type.ID@

Reference to the Object Type that is linked to a
Property Type via Association Type.
   object_type.Id@

The name for the many to many association.
Normally this is in the following format:
     Attribute__has__Name
     Attribute__has__Note
     Attribute__has__NullOptionType
     . . .

The Name of the Object Type. Each name is the
name of a Table in the metamodel. 
Note:
The tables that represent Vector Attributes are
not considered as objects.

Basically, if an Object Type is a subtype of
something else the something else is specified
here.

Example:
Entity                          > Abstract Entity

Abstract Entity            > Abstract Model Node
Abstract Model Node  > Abstract ERwin Object
Abstract ERwin Object >Abstract Object

Former constraints on the depth of ownership
references for Object Type.

For example for Subtype Symbols the Tag Legacy
Ownership Depth is 5. This means you could have up
to 5 levels of subtyping.

Name of the Property Type. 

Note: Tag Is Locally Defined = 'T'
Every UDP will have its name as a property
type with dot naming conventions
Examples:
 Entity.Logical.Logical UDP Name
 Entity.Physical.Physical UDP Name

Note: Tag Is Reference = 'T'
If Data Type = Short Id 
then Name = Attribute Name
ex: Parent_Attribute_Ref
If Data Type = Short Id Vector
then Name = Vector Table Name
ex: Referenced_Entities_Ref

Indicates a Logical Property Type
Values: 
  T
  F
null

Indicates a Physiical Property Type
Values: 
  T
  F
null

If there is a definition for the Property Type
this is it. This is normally present for User
Defined Property Types but otherwise it is not
present.

If Tag Is Locally Defined = 'T'
then the Property Type is a UDP

The UDP Data Type. This is just a number with no
tran function to explain it.
Here are the values and the type from the UDP
dropdown list.
Value   Type   
   1        Int     
   2        Text  
   3        Date
   4        Command  ?
   5        Real
   6        List

Whatever default value you specify. Some are
automatic. 
For example: 
Date will default to the current date unless you
change it.
Int will default to 0
Real will default to 0
List will default to the first item in the list

The order of the Property Type as it appears in
the referenced Object Type via the Association
Type relationship.

For example, if the Property Type is a UDP, then
this is the sequence of the UDP in the UDP
dictionary for an object. If you have four UDP's
for a logical entity then this is their sequence
in the UDP dictionary.

If the Tag UDP Data Type = 6, List, then this is
the list of possible values for the UDP.

Indicates that the Property Type is a Reference. 

Values:
   T  -   The Property Type is a Reference type
   F  -    Not a Reference Property Type

This is extremely important for identifying what
is referencing what for Value@ type references and
especially for Vector references.

If you select tran(Referenced_Type_Ref) it will
tell you what kind of object is being referenced.
This is one way to discover the vector tables such
as Referenced_Entities_Ref and Data_Sources_Ref
that are essential for navigating the meta model.
It is only present when Tag Is Reference = 'T'

When Tag Is Reference = 'T'
the values are:
    Short Id                Attribute Ref
    Short Id Vector     Vector Table Ref

When Tag Is Locally Defined = 'T
the value is:
     String

Standard Identifier for an Entity. This is the
standard Id@ used for all descendents of abstract
model objects.

Attribute(s) of "Parent To Subtype Relationship"
Entity

The identifier for the Relationship. This is the
standard Id@ used for all descendents of abstract
model objects.

Standard Identifier for an Entity. This is the
standard Id@ used for all descendents of abstract
model objects.

Standard Identifier for an Entity. This is the
standard Id@ used for all descendents of abstract
model objects.

Identifier for the FK Key Group that is the
parent of the Subtype FK Key Group.

Pointer to the Subtype To Child Relationship that
links this FK Key Group to its Parent Supertype PK
Key Group.

Attribute(s) of "Subtype To Child Relationship"
Entity

The identifier for the Relationship. This is the
standard Id@ used for all descendents of abstract
model objects.

Standard Identifier for an Entity. This is the
standard Id@ used for all descendents of abstract
model objects.

Standard Identifier for an Entity. This is the
standard Id@ used for all descendents of abstract
model objects.

Standard Identifier for an Entity. This is the
standard Id@ used for all descendents of abstract
model objects.

Pointer to the Parent View for the View to View
Relationship

Pointer to the Child View for the View to View
Relationship.