Abstract: Modeling in ERwin. Erwin Basics. Building a Logical Data Model Many-to-Many Communications erwin

Laboratory work No. 3. Database modeling using Erwin

Goal of the work– students acquire practical skills in creating logical and physical data models using CASE – development tools information systems.

Basic information

ERwin supports forward and reverse database modeling. In forward modeling, the database schema is described directly using an entity-relationship diagram. Entities in the diagram are represented by rectangles. Each rectangle can have different visual attributes. Each entity must be given a unique name. Entity names must be in the singular. This is determined by the fact that the system always operates with separate instances of the entity. In this case, individual instances of an entity are considered as objects, and entities are considered as a class of objects. If entities were described during modeling in BPwin, then they can simply be imported into ERwin. An example of a diagram with created entities is shown in the figure.

Figure 4 - Example of a diagram with created entities

Building models in ERwin

There are two possible points of view on the information model and, accordingly, two levels of the model. The first - logical level (user's point of view) means a direct display of facts from real life. For example, people, tables, departments, dogs and computers are real objects. They are named in natural language, with any word separators (spaces, commas, etc.). At the physical level of the model, the use of a specific DBMS is considered, data types (for example, integer or real number), and indexes for tables are determined.

ERwin provides the ability to create and manage these two different levels of presentation of a single diagram (model), as well as having many display options at each level. The term "logical level" in ERwin corresponds to a conceptual model.

Stages of building an information model.

entity definition;
defining dependencies between entities;
setting primary and alternative keys;
defining entity attributes;
bringing the model to the required level of normal form;
transition to the physical description of the model: assignment of correspondences entity name - table name, entity attribute - table attribute;
setting triggers, procedures and restrictions;
database generation.

Erwin creates a visual representation (data model) for the problem being solved. This view can be used for detailed analysis, refinement, and distribution of documentation needed in the development cycle. However, ERwin is far from just a drawing tool. ERwin automatically creates the database (tables, indexes, stored procedures, triggers to ensure referential integrity and other objects necessary for data management).

Creating an entity.

To add an entity to the model, you need to click on the entity button on the toolbar (Erwin Toolbox), then click on the place on the diagram where you want to place the new entity. Clicking right click mouse over the entity and selecting the Entity Editor item from the pop-up menu, you can call the Entity Editor dialog, in which the name, description and comments of the entity are defined.

Each entity must be fully defined using a text description in the Definition tab. These definitions are useful both at the logical level, since they allow you to understand what an object is, and at the physical level, since they can be exported as part of a schema and used in a real database ( CREATE COMMENT on entity_name). The Note, Note2, Note3, UDP (User Defined Properties) bookmarks are used to add additional comments and definitions to the entity.

In the Icon tab, each entity can be assigned an image that will be displayed in the model viewing mode at the icon level and an image that will be displayed at all other levels.

The UDP tab of the Entity Editor dialog is used to define user-defined properties (User - Defined Properties). When you click on the button for this tab, the User - Defined Property Editor dialog is called up (also called from the Edit/UDPs menu). It is necessary to indicate the type of object for which UDP is being created (diagram as a whole, entity, attribute, etc.) and the data type. To add a new property, click the button in the table and enter the name, data type, default value, and definition.

Creating attributes.

The next step in creating a model is to set attributes for each entity. When specifying an attribute type, it is possible to use domains. A domain is an abstract user-defined type that is assigned to any physical data type. Moreover, each domain can have its own default values and rules for validating input data. ERwin provides the ability to document all the steps involved in creating your own data types. By using the domain concept, database portability across different hardware platforms is ensured.

Figure 5 - Creating a new domain	Figure 6 - Specifying the properties of the new domain

Figure 7 - Default value for a new domain

Figure 8 - Using a domain to specify the data type of an attribute.

To describe attributes, right-click on the entity and select Attribute Editor from the menu that appears. The Attribute Editor dialog appears.

If you click on the New button, then in the New Attribute dialog that appears, you can specify the name of the attribute, the name of the corresponding one in physical model columns and domain. The attribute domain will be used when defining the column type at the physical model level.

For primary key attributes, in the General tab of the Attribute Editor dialog, you must make a mark in the Primary Key selection window.
The Definition, Note, and UDP tabs perform the same functions as when defining an entity, but at the attribute level.

To make the diagram more visual, each attribute can be associated with an icon. This can be done using the Icon selection list in the General tab.

It is very important to give the attribute the correct name. Attributes must be named in the singular and have a clear semantic meaning.

According to IDEF1X syntax, the attribute name must be unique within the model (not just within the entity!). By default, when you try to add an existing attribute name, ERwin renames it. For example, if the Comment attribute already exists in the model, another attribute (in another entity) will be named Comment/2, then Comment/3, etc.
When transferring attributes within and between entities, you can use the drag&drop technique by selecting the button in the tool palette.

To create a new relationship, select an identifying or non-identifying relationship in the tool palette (ERwin Toolbox), click first on the parent and then on the child entity.
In the tool palette, a button corresponds to an identifying relationship, a many-to-many relationship button, and a button corresponding to a non-identifying relationship. To edit the properties of a link, right-click on the link and select context menu Relationship Editor item.

In the General tab of the dialog that appears, you can set the power, name and type of connection.

Communication power (Cardinality)- serves to indicate the ratio of the number of instances of the parent entity to the number of instances of the child.
There are four types of power:

· the general case when one instance of a parent entity corresponds to 0, 1 or many instances of a child entity is not marked with any symbol;

· the symbol P marks the case when one instance of the parent entity corresponds to 1 or many instances of the child entity (zero value is excluded);

· the symbol Z marks the case when one instance of the parent entity corresponds to 0 or 1 instance of the child entity (multiple values are excluded);

· a number marks the case when one instance of the parent entity corresponds to a predetermined number of instances of the child entity.

By default, the symbol representing link strength is not shown on the diagram. To display the name, in the context menu that appears if you right-click on any place in the diagram that is not occupied by model objects, select Display Options/Relationship and then enable the Cardinality option.

Type of connection (identifying/non-identifying).

IDEF1X distinguishes between dependent and independent entities. The type of an entity is determined by its relationship to other entities. An identifying relationship is established between an independent (parent end of the relationship) and dependent (child end of the relationship) entity. When an identifying relationship is drawn, ERwin automatically converts the child relationship into a dependent relationship. The dependent entity is represented by a rectangle with rounded corners.

An instance of a dependent entity is defined only through a relationship to a parent entity. When an identifying relationship is established, the attributes of the parent entity's primary key are automatically transferred to the child entity's primary key. This operation of adding attributes to a child entity when creating a relationship is called attribute migration. In the child entity, new attributes are marked as foreign keys - (FK).

When a non-identifying relationship is established, the child entity remains independent, and the primary key attributes of the parent entity migrate to the non-key components of the child entity. A non-identifying relationship is used to connect independent entities.

An identifying connection is shown on the diagram as a solid line with a thick dot at the child end of the connection, and a non-identifying connection is shown as a dotted line.

For a non-identifying relationship, you can specify mandatory (Nulls in the General tab of the Relationship Editor dialog). In the case of a mandatory relationship (No Nulls), when generating a database schema, the foreign key attribute will receive the NOT NULL attribute, despite the fact that the foreign key will not be part of the primary key of the child entity. In the case of an optional relationship (Nulls Allowed), the foreign key can be NULL. An optional non-identifying relationship is marked with a transparent diamond on the parent entity side

Verb Phrase- a phrase characterizing the relationship between parent and child entities. For a one-to-many relationship, identifying or non-identifying, it is enough to specify a name that characterizes the relationship from parent to child entity (Parent-to-Child). For a many-to-many relationship, both Parent-to-Child and Child-to-Parent names must be specified. To display the name, in the context menu that appears if you right-click anywhere in the diagram that is not occupied by model objects, select Display Options/Relationship and then enable the Verb Phrase option.

Role name or functional name (Rolename) is a synonym for a foreign key attribute that indicates what role the attribute plays in a child entity. You can set the role name in the Rolename/RI Actions tab of the Relationship Editor dialog.

Creating keys.

Each instance of an entity must be unique and distinct from other attributes.

Primary key is an attribute or group of attributes that uniquely identifies an instance of an entity. The primary key attributes in the diagram do not require special designation - these are the attributes that are in the list of attributes above horizontal line. When adding a new attribute in the Attribute Editor dialog, in order to make it a primary key attribute, you need to enable the Primary Key checkbox at the bottom of the General tab. In the diagram, a key attribute can be added to the primary key using the attribute transfer mode (the button in the tool palette).

One entity may contain several attributes or sets of attributes that claim to be the primary key. Such applicants are called potential keys (candidate key).

Keys can be complex, i.e. containing several attributes. Complex primary keys do not require special notation - they are a list of attributes above a horizontal line. When choosing a primary key, preference should be given to simpler keys, i.e. keys containing fewer attributes.

Many entities have only one candidate key. This becomes the primary key. Some entities may have more than one possible key. Then one of them becomes the primary key, and the rest become alternate keys.

Alternative Key is a candidate key that has not become the primary key.

Each key has a corresponding index, the name of which is also assigned automatically. The key and index names can be changed manually if desired.

In the diagram, the attributes of alternative keys are denoted as (Akn.m.), where n is the serial number of the key, m is the serial number of the attribute in the key. When an alternate key contains multiple attributes, (Akn.m.) is placed after each one.

A dependent entity can have the same key from multiple parent entities. An entity can also receive the same foreign key multiple times from the same parent through multiple different relationships. When ERwin detects one of these events, it recognizes that the two attributes are the same and places the foreign key attributes on the dependent entity only once. This combination or unification of identical attributes is called unification.

There are cases when unification is undesirable. For example, when two attributes have the same names, but in fact they differ in meaning, and it is necessary that this difference be reflected in the diagram. In this case, you must use foreign key role names.

Relationships in a diagram are represented by lines going from one entity (table) to another. Each link is assigned a unique name. Related tables are divided into parent and child tables. Parent tables are displayed as rectangles with right corners, child tables – with rounded corners.

After specifying all the attributes of the data format, it is necessary to convert the created logical model into a physical one. For this it is necessary to Tools choose Derive New Model, where as Target Databases select ODBC/Generic(for use in MySQL DBMS) see Figure 9. Our model (see Figure 4) will be converted to the form see Figure 11.

Figure 9 - Converting a logical model to a physical one

Figure 10 - Physical model indicating the data format.

Figure 11 - SQL Code Generation

Exercise

1. Construct a diagram with given entities (direct modeling) for a given subject area.

2. Set attributes for each defined entity. When setting attributes, use domains.

3. Enter relationships between entities. Give your connections unique names.

4. Using the MYSQL DBMS, decide on the direct generation of a database for the information project being designed.

5. The report must contain a conceptual model and a physical database in the MYSQL DBMS.

Control questions

1. What is the difference between the logical and physical levels of representing data models using ERwin?

2. What is the difference between data models represented in the form of an entity-relationship diagram, a key-based model, and a full attribute model?

3. What are the main components of the data models presented according to the IDEF1X methodology?

The list of data types supported by the DBMS must be checked with the manufacturer

Stages of building an information model:

· definition of entities;

· determination of dependencies between entities;

· setting primary and alternative keys;

· definition of entity attributes;

· bringing the model to the required level of normal form;

· transition to the physical description of the model: assignment of correspondences entity name - table name, entity attribute - table attribute;

· setting triggers, procedures and restrictions;

· Database generation.

Erwin creates a visual representation (data model) for the problem being solved. This view can be used for detailed analysis, refinement, and distribution of documentation needed in the development cycle. However, ERwin is far from just a drawing tool. ERwin automatically creates the database (tables, indexes, stored procedures, referential integrity triggers, and other objects needed to manage the data).

Creating an entity.

To add an entity to the model, you need to click on the entity button on the toolbar (Erwin Toolbox), then click on the place on the diagram where you want to place the new entity. By right-clicking an entity and selecting Entity Editor from the pop-up menu, you can display the Entity Editor dialog, where you define the name, description, and comments of the entity.

Each entity must be fully defined using a text description in the Definition tab. These definitions are useful both at the logical level, as they allow you to understand what the entity is, and at the physical level, as they can be exported as part of a schema and used in the actual database (CREATE COMMENT on entity_name). The Note, Note2, Note3, UDP (User Defined Properties) bookmarks are used to add additional comments and definitions to the entity.

In the Icon tab, each entity can be assigned an image that will be displayed in the model viewing mode at the icon level and an image that will be displayed at all other levels.

Creating Attributes

To describe attributes, right-click on the entity and select Attribute Editor from the menu that appears. The Attribute Editor dialog appears.

If you click on the New button, in the New Attribute dialog that appears, you can specify the name of the attribute, the name of the column corresponding to it in the physical model, and the domain. The attribute domain will be used when defining the column type at the physical model level.

For primary key attributes, in the General tab of the Attribute Editor dialog, you must make a mark in the Primary Key selection window.

The Definition, Note, and UDP tabs perform the same functions as when defining an entity, but at the attribute level.

To make the diagram more visual, each attribute can be associated with an icon. This can be done using the Icon selection list in the General tab.

It is very important to give the attribute the correct name. Attributes must be named in the singular and have a clear semantic meaning.

When transferring attributes within and between entities, you can use the drag&drop technique by selecting the button in the tool palette.

Creating a connection.

To create a new relationship, select an identifying or non-identifying relationship in the tool palette (ERwin Toolbox), click first on the parent and then on the child entity.

In the tool palette, a button corresponds to an identifying relationship, a many-to-many relationship button, and a button corresponding to a non-identifying relationship. To edit the properties of a relationship, right-click on the relationship and select Relationship Editor from the context menu.

In the General tab of the dialog that appears, you can set the power, name and type of connection.

Communication power (Cardinality)- serves to indicate the ratio of the number of instances of the parent entity to the number of instances of the child.

There are four types of power:

the general case where one instance of a parent entity corresponds to 0, 1, or many instances of a child entity is not marked with any symbol;

the symbol P marks the case when one instance of the parent entity corresponds to 1 or many instances of the child entity (null value excluded);

the symbol Z marks the case when one instance of the parent entity corresponds to 0 or 1 instance of the child entity (multiple values are excluded);

The number marks the case when one instance of the parent entity corresponds to a predetermined number of instances of the child entity.

Type of connection (identifying/non-identifying).

An identifying connection is shown on the diagram as a solid line with a thick dot at the child end of the connection, and a non-identifying connection is shown as a dotted line.

Fig.1. Foreign key role names

In the example shown in Fig. 1, in the Employee foreign key Department Number entity has a role name "Where Works" which indicates what role this attribute plays in the entity. By default, only the role name is shown in the attribute list. To display the full attribute name (both the functional name and the role name), in the context menu that appears if you right-click anywhere in the diagram that is not occupied by model objects, select Display Options/Entities and then enable the Rolename/ option Attribute. The full name is shown as the functional name and base name separated by a dot (Figure 1).

It is mandatory to use role names when two or more attributes of the same entity are defined over the same scope, i.e. they have the same range of meanings, but different meanings.

Fig.2. The case of mandatory role names

In Fig. 2, the Currency Sale entity contains information about a currency exchange act in which two currencies are involved - sold and purchased. Information about currencies is contained in the Currency entity. Therefore, the Currency Sale and Currency entities must be linked twice, and the primary key - Currency Number must be migrated twice to the Currency entity as a foreign key. It is necessary to distinguish between these attributes, which contain information about the number of the sold and purchased currency (they have different meanings), but refer to the same Currency entity (they have a common range of values). In the example in Fig. 2, the attributes received the role names Sold and Purchased.

Another example of the mandatory use of role names is recursive relationships, when the same entity is both a parent and a child.

Referential Integrity (RI) Rules- logical constructs that express business rules for using data and represent rules for insertion, replacement and deletion. You can set referential integrity rules in the Rolename/RI Actions tab of the Relationship Editor dialog.

When generating a database schema based on the logical model options, declarative referential integrity rules will be generated, which must be prescribed for each relationship, and triggers that ensure referential integrity.

Fig.3. Migrating role names

In Fig. 3 there is an identifying relationship between the Team and Player entities. What happens if you delete a command? Entity instance Player cannot exist without a command (primary key attribute What team does he play on? Team number cannot take the value NULL), therefore you need to either prohibit deleting a team as long as there is at least one player in it, or delete all its players along with the team. Such removal rules (Parent Delete) are called Parent Restrict (restriction) and Parent Cascade (cascade). The entities Player and Goal, in turn, are also connected by an identifying link and, if the deletion of a player is subject to a cascade deletion rule for all records of his goals, then when a team is deleted, all players on the team and all goals scored by these players will be deleted.

Many-to-many communication is possible only at the logical data model level. Such a connection is indicated by a solid line with two dots at the ends. To add a relationship, you must first click on the button in the tool palette (ERwin Toolbox), and then click on both related entities in turn.

A many-to-many relationship should be named (Verb Phrase) by two phrases - in both directions. This makes the diagram easier to read.

Creating keys.

Each instance of an entity must be unique and distinct from other attributes.

Primary key is an attribute or group of attributes that uniquely identifies an instance of an entity. The primary key attributes in the diagram do not require special designation - they are those attributes that are in the list of attributes above the horizontal line. When adding a new attribute in the Attribute Editor dialog, in order to make it a primary key attribute, you need to enable the Primary Key checkbox at the bottom of the General tab. In the diagram, a key attribute can be added to the primary key using the attribute transfer mode (the button in the tool palette).

One entity may contain several attributes or sets of attributes that claim to be the primary key. Such applicants are called potential keys (candidate key).

Alternative Key is a candidate key that has not become the primary key.

Each key has a corresponding index, the name of which is also assigned automatically. The key and index names can be changed manually if desired.

Fig.4. Entity "Employee" with keys displayed

Foreign Keys are created automatically when a relationship connects entities: the relationships form a reference to the primary key attributes in the child entity, and these attributes form a foreign key in the child entity (key migration). Foreign key attributes are indicated by a symbol (FK) after their name (Fig. 4). Foreign key attributes Where Works. The department number (“Where Works” is the role name) of the Employee entity is a primary key (PK) attribute in the Department entity.

Domains.

A domain can be defined as a collection of values from which attribute values are derived. Each attribute can be defined on only one domain, but multiple attributes can be defined on each domain. The concept of a domain includes not only the data type, but also the range of data values. For example, you could define the Age domain as a positive integer and define the Employee Age attribute as belonging to that domain.

In ERwin, a domain can only be defined once and can be used in both the logical and physical models.

At the logical level, domains can be described without specific physical properties. At the physical level, they receive specific properties that can be changed manually. So, the “Age” domain can have the Number type at the logical level; at the physical level, the domain will be assigned the INTEGER type.

To create a domain in the logical model, use the Domain Dictionary Editor dialog. It can be called up from the Edit/Domain Dictionary menu using the button located in the upper left part of the General tab of the Attribute Editor dialog. To create a new domain in the Domain Dictionary Editor dialog:

· Click on the New button. The New Domain dialog appears;

· select the parent domain from the Domain Parent list. A new domain can be created based on a domain already created by the user, or based on an initially existing one. By default, Erwin has four predefined domains (String, Number, Blob, Datetime). The new domain inherits all the properties of the parent domain. These properties can be redefined later;

· enter the domain name in the Logical Name field. You can also specify the physical domain name in the Physical Name field. If a physical name is not specified, it defaults to the logical name;

· click on the OK button;

In the Domain Dictionary Editor dialog, you can associate a domain with an icon with which it will be displayed in the list of domains (Domain Icon), an icon with which an attribute defined on the domain will be displayed in the model (Icon Inherited by Attribute).

Each domain can be described in the Definition tab, provided with a comment in the Note tab, or a user-defined property in the UDP tab.

ERwin has a special tool that makes it much easier to create new attributes in a model using domain descriptions - the Independent Attribute Browser. This dialog is called (and hidden) using the hotkey CTRL+B. With its help, you can select a domain in the list and use the drag&drop method to transfer it to an entity. It will create a new attribute with a name that should be set in the Name Inherited by Attribute window of the Domain Dictionary Editor dialog. If the field value is not specified, the default is the domain name.

At the physical level, the Domain Dictionary Editor dialog allows you to edit the physical properties of a domain. The name of this tab depends on the selected database server. On it you can set a specific data type corresponding to the domain, rules for assigning NULL values, validation rules (rules for checking valid values) and setting a default value. Validation rules and default values must be previously described and named. To call dialogs for editing validation rules and default values, use the buttons to the right of the corresponding selection list (Valid and Default).

Functions of other tabs of the Domain Dictionary Editor dialog:

General. Specifying the Domain Parent and name assigned to the column when it is created using the Independent Column Browser. Using the Physical Only option, a domain can only be defined at the physical model level.

Comment. Adding a comment to the attribute.

UDP. User-defined properties.

Visual Basic- PowerBuilder. Setting special domain properties for code generation of the client application.

Task to complete.

Based on the previously created functional model and description of the subject area, create a logical model using the ERwin package.

Laboratory work № 7.
Erwin Basics. Preparing a physical data model for database generation

1. Purpose of the work: mastering the principles of preparing a physical data model for generating a database system catalog.

1. Study questions

Development of a relational data model inERwin.
Normalization of the physical data model inERwin.

2. Lesson plan

Knowledge control by testing (test ISE005).
Importing entities into ERwin.
Development of logical and physical data models in ERwin using methodology IDEF1X.
Normalization of the physical data model in ERwin.

Import entities into ERwin, using file Data _IS_Name. bph, and based on the resulting set of entities, develop a logical data model.

Comment: If the names of entities and attributes were created in Cyrillic (Russian), they should be rewritten in Latin characters.

Create logical and physical data models using tools ERwin.
in your folder ISE.
Normalization of the physical model should be carried out by resolving MANY-TO-MANY relationships using the button Many to Many Transform toolbars ER winTransform Toolbar.
Save the results of the work in a file
Data_model_IS_Name_IDEF1Х.er1 in your folder ISE.

An EXAMPLE of a logical model, as well as a normalized physical data model made in IDEF1X technology, is given in.

4. Technological process for completing tasks

4.1. Technological process for creating data models

4.1.1. Methodology for creating models (IDEF1X methodology)

Methodology IDEF1X used by CASE tool ERwin to build logical and physical models of information system data.

ERwin has a simple and understandable user interface for building logical and physical models of data processed by the system. IN logical model, it is permissible to create MANY-TO-MANY relationships between entities, and the attribute name ( Attribute Name) will be the attribute name in logical model, and the column name ( Column Name), if given, will be the name of the attribute in physical models.

In any of these models, you can automatically convert a MANY-TO-MANY relationship to a ONE-TO-MANY relationship.

As a result, a subordinate table will be created that decouples the MANY-TO-MANY relationship. This table will contain an embedded composite key (FK) with embedded attributes from the main tables and their corresponding data types. If you need to change the data type, this must be done manually.

The process of creating a model involves the following steps:

Creating a new model can be done from the window Computer Associates ERwin or click the create model button. In both cases, a dialog box will be displayed. Create Model – Select Template (Fig. 5.1).

In the window Create Model - Select Template you should select the option that determines the ability to create data models certain type: Logical(you can only create Logical model), Physical(you can only create Physical model) or Logical/Physical(you can create both models in parallel: and Logical , And Physical). To have more options, it is advisable to select the last option - Logical/Physical .
IN Target Database group from the list suggested in the field Database, select a database management system (DBMS) – SQL Server, and in the field Version the required version – 2000 .
In the window that appears < Main Subject Area >/display] select the type of model to be created from the list: Logical or Physical(Fig. 5.2).

In the toolbar ERwin Toolbox contains buttons that allow you to add individual fragments to the data model and edit it:

	– Select(editing the selected model object),
	– Entity(adding an entity),
	– Many - to - many Relationships(Many-to-Many relationship),
	– Identifying Relationship (identifying connection),
	– Non-identifying Relationship (non-identifying relationship).

4.1.2. Technological process for creating a logical data model

During the model creation process, entities can be introduced by importing from an entity dictionary developed in BPwin, or by creating using the button Entity on the toolbar.

Importing entities into ERwin

Notes

Entities can only be exported and imported once.
After importing entities from BPwin checkboxes Exchange with ERwin and buttons Update And Delete in the dialog box Entity and Attribute Dictionary Editor become dull. This is because you cannot change entities and attributes that BPwin shares with ERwin.

Creation of new entities.
- Click the add entities button Entity and click within the model window.
- Enter entity name and press Enter then enter attribute name essence.
- To select the desired font, follow the steps below. 1.9–1.12.
Adding new attributes.
- In the entity context menu, select the command Attributes... and in the window that appears (Fig. 5.4) click the button New.
- In the window New Attributes(Fig. 5.6) enter the attribute name in the field Attribute Name .
- Set the data type of each attribute for each entity: Text (String), Numeric (Number), Date/time (Datetime) or MEMO field (B inaryL argeOb ject, Blob) (Fig. 5.5 or Fig. 5.6) .
- Define key attributes by checking the box Primary Key in the window Attributes(Fig. 5.5) after highlighting the desired attribute in the field Attribute.

Establishing relationships between entities

Establishing a MANY-TO-MANY relationship:
- In the toolbar Erwin Toolbox press the button Many-to-many Relationship .
- Consistently click the left mouse button on the names of the entities between which you want to create a connection (Fig. 5.7).

Installation identifying ONE-TO-MANY relationships:
- In the toolbar Erwin Toolbox press the button Identifying Relationship.
- key key attribute subordinate entity (FK), located on the A LOT side (Fig. 5.8).
- A composite key is formed in the subordinate entity.

Installation non-identifying ONE-TO-MANY relationships:
- In the toolbar Erwin Toolbox press the button Non-identifying Relationship .
- Consistently click the left mouse button on the names of the entities between which you want to create a connection. The result of creating a connection will be the implementation key attribute of the main entity as non-key attribute subordinate entity (FK), located on the A LOT side (Fig. 5.9).

4.1.3. Technological process of creating a physical data model

The result of executing the command will be an automatically created physical model, in which tables will be presented instead of entities, and table fields will be presented instead of entity attributes.

In the physical model, check the data types and relationships established between tables.

4.2. Technological process of normalization of the physical data model (IDEF1X methodology)

In the window Computer Associates ERwin – )