Download 2. Entity Relationship Diagrams

Silesian University of Technology
Computer Science Department
DATABASE LABORATORY
Relational Database Schema Design
Entity Relationship Approach
Author
Piotr Bajerski
Version 2.0
Gliwice 2003
Contents
1. INTRODUCTION ...................................................................................................................................................3
2. ENTITY RELATIONSHIP DIAGRAMS .............................................................................................................4
2.1. ENTITIES .............................................................................................................................................................5
2.2. RELATIONSHIPS ...................................................................................................................................................5
2.3. ATTRIBUTES ........................................................................................................................................................5
2.4. N-ARY RELATIONSHIPS ........................................................................................................................................5
2.5. WEAK ENTITY .....................................................................................................................................................7
3. SAMPLE PROJECT ...............................................................................................................................................7
4. EASYCASE ............................................................................................................................................................ 12
4.1. CREATING AND MANAGING PROJECTS ............................................................................................................... 13
4.2. CREATING CHARTS ............................................................................................................................................ 14
4.3. ADDING ENTITIES AND RELATIONSHIPS ............................................................................................................. 14
4.4. NAMING ENTITIES AND RELATIONSHIPS ............................................................................................................ 15
4.5. CHANGING OR DELETING A CHART OBJECT NAME ............................................................................................. 15
4.6. CONNECTING SYMBOLS ..................................................................................................................................... 16
4.7. DEFINING RECORDS ........................................................................................................................................... 17
4.8. CREATING COLUMNS ......................................................................................................................................... 17
4.9. DEFINING COLUMN PROPERTIES ........................................................................................................................ 19
4.10. DISPLAYING DETAILS IN ENTITY RELATIONSHIP DIAGRAMS............................................................................. 20
4.11. DATABASE SCHEMA GENERATION ................................................................................................................... 20
5. BIBLIOGRAPHY .................................................................................................................................................. 20
2
1. Introduction
Fig. 1 shows fundamental activities that are common to different approaches to database design. The first
step deals with gathering requirements – describing what a system under construction should do and
within which constraints it must work. This stage concerns static aspect (data) as well as dynamic aspect
(processes transforming data) of the system and it is difficult to treat the aspects separately. In the
subsequent phases of the system development different models are used for data and processes modeling.
This instruction concerns only data modeling.
Logical data model, usually graphically presented as an Entity Relationship Diagram (ERD), shows how
the processed information is organized without giving thought how the model will be implemented.
Therefore, there can be constructions such as supertype/subtype or many-to-many relationships, which
cannot be explicitly implemented on a RDBMS. On a logical data model only entities, relationships and
attributes related to the problem domain are shown.
Requirements
Logical data model
(e.g. Entity Relationship
Diagram)
Physical data model
(e.g. Entity Relationship
Diagram with some
restrictions)
Scripts in SQL Data
Definition Language
RDBMS
Fig. 1. Process of relational database schema design
3
A physical data model describes how the designed data structures will be implemented on the given
RDBMS. It contains only constructions that can be explicitly implemented on the given RDBMS: tables,
columns, views, keys, foreign keys, and constraints. On a physical data model all relationships are implemented as foreign keys.
A physical data model can be easily transformed into a script containing statements in SQL DDL (Data
Definition Language) describing database objects that are to be created on the RDBMS. Such description
is called the database schema. As the contents of the script maps in relation 1:1 to the physical data model
we can tell that the physical data model is a visual representation of the database schema.
2. Entity Relationship Diagrams
Entity Relationship Diagrams (ERD) are a graphical approach to database modeling. There are many
notations used on Entity Relationship Diagrams expressing the same key ideas by different geometric
symbols. The three principal components of an ERD are:
 Entities
 Attributes
 Relationships
In this instruction only Chen notation is presented. An example of Chen notation is shown on fig. 2. The
main features that distinguish Chen notation from other notations (such as Oracle or Martin) are:
 relationships are represented by a separate symbol (diamond),
 n-ary relationships (n entities may participate in a relationship) are supported,
 attributes have a separate symbol on the diagram,
 connections should be annotated with cardinality, as opposed to being shown symbolically,
 entities that are dependent on others entities for their existence (weak entities) have a distinct symbol.
Entity
Key Attribute
Attribute
Relationship
Multi-Valued Attribute
Fig. 2. Sample Entity Relationship Diagram in Chen notation
4
2.1. Entities
In Entity Relationship models there is a similar dichotomy like in Object-Oriented approach: class versus
object. However, the terminology is not so precise. The type versus instance dichotomy is denoted by two
pairs of terms: entity set and entity or entity and entity instance. In the instruction object’s type will be
called entity and the object itself will be called entity instance.
An entity represents a group of similar objects about which information is to be stored or collected. An
entity has a significant purpose or characteristic within the system being modeled.
An entity is depicted by a rectangle (fig. 2) and may be qualified by one or more attributes.
2.2. Relationships
A relationship represents a significant association or interaction involving one or more entities. It has a
verb name and may have attributes. Relations between entities may be of 1:1 cardinality, which means
one entity instance participates in a relationship with one other entity instance. Alternatively, they may be
relationships of 1:N cardinality, where an entity instance participates in a relationship with more than one
other entity instance, or relationships of M:N cardinality where several entity instances participate in a
relationship with several others.
A relationship is depicted by a diamond (fig. 2).
A relationship cannot stand alone and must be connected to at last two entities or twice to the same entity.
2.3. Attributes
Attributes represent data elements describe entities and relationships. Each attribute is named. Usually
names of attributes are required to be unique. Most attributes have a single value. However, an attribute
may have a set of values for the same entity instance. Such an attribute is called multi-valued attribute.
An attribute is depicted by a circle (fig. 2). A multi-valued attribute is depicted by double-walled circle.
On the laboratory, to simplify the projects, attributes ought to be placed in entity rectangles and multivalued attributes should be implemented as relationships of cardinality M:N to dictionary entities.
2.4. n-ary relationships
Sometimes we must remember relation between more than two entities. Suppose that a company X
providing IT specialist ordered a database. A client pays company X, which in turn pays the employee.
They need to store information that, for example, a client wanted a half time network administrator and
such a specialist was sent. One person can work for several companies at the same time holding different
positions. It can even happen that the same person holds two different positions at the same company. We
can of course associate Employee entity with Company entity using M:N relationship, Employee entity
with Position entity using M:N relationship, and Company entity with Position entity using M:N
relationship. All of it is true but we do not know what position was held by the given employee working
for the given company and where should we attach the information about fee. Fig. 3. shows the solution
5
based on of n-ary relationship. Financial data would be attached to the relationship works for as. The
cardinality NM stands for many (as M and N).
Fig. 3. Example of n-ary relationship
A multi-way relationship can be converted into an entity and collection of binary 1:N relationships without losing any information. Fig. 4. shows an example of weak entity – a contract cannot exist without
Company and Employee and under the assumption that contract numbers are given by the hiring company
contract identifies itself only inside the company.
Fig. 4. The result of converting the n-ary relationship from the fig. 3 into an entity
6
2.5. Weak entity
A weak entity can only exist when it is connected to another entity. A weak entity is dependent upon only
a single instance of the entity to which it is connected, and can therefore have only a 1:1 or 1:N relationship to that entity. Weak entities are also entities that do not have key attributes of their own and are
therefore dependent on another entity. This implies that it may not be possible to distinguish between
some entity instances because the combinations of values of the entity instances can be identical. A weak
entity has a partial key that is defined to be a set of attributes that can be used to uniquely identify weak
entities related to the same owner entity.
A weak entity is represented by a double-walled rectangle (see fig. 4).
3. Sample project
Let us consider the following problem (which is, of course, only a simplification of reality):
A small medical company ordered a project of a database that should facilitate managing: patient personal
and contact data, basic data about working physicians and information about appointments. Every patient
has social security number, which is unique. Also name, address and telephone should be stored for
patients. Physicians are identified by doctor numbers that they receive after passing final exams. Also
name, address and telephone should be stored for physicians. A patient is examined by one physician at a
time. Patients are not assigned to doctors but directed to ones that are available. It must be remembered
which physician examined the patient during appointment, which diseases were diagnosed and which
drugs were prescribed. It is very important to store assigned doses: how much, how often and for how
long the drug should be taken. There should be a catalog of drugs containing following information: drug
code, drug name, composition, contraindication, side effects, and manufacturer.
Further inquiry revealed that it would be useful to store description of symptoms and standard treatment
as well as information on drugs that are recommended for a given disease and doses that are typically
used. Also interactions among drugs would be of interest. It can be simplified that only interactions between pairs of drugs will be stored.
7
Fig. 5. Logical data model showing only entities and relationships
The first step is to identify entities. Next, they should be connected with relationships. The results are
shown on fig. 5.
8
Fig. 6. Logical data model with attributes
After that, attributes are attached to entities and relationships (as records components). The enhanced
diagram is shown on fig. 6. Information on doses of a particular drug prescribed to a given patient is an
attribute of the relationship between entities Patient and Drug.
Afterwards relationships with cardinality 1:N are implemented as foreign keys and relationships with cardinality M:N are exploded into records (fig. 7). Now the diagram depicts all tables and their columns that
will be created in a database.
9
Fig. 7. Physical data model
SQL script creating tables for the example:
CREATE TABLE PATIENTS
(SOCIAL_SECURITY_NO
NAME
ADRESS
TELEPHON
PRIMARY KEY (SOCIAL_SECURITY_NO));
CREATE TABLE PHYSICIANS
(DOCTOR_NO
NAME
ADRESS
CHAR
CHAR
CHAR
CHAR
(30) UNIQUE NOT NULL,
(50) NOT NULL,
(100),
(20),
CHAR (6) UNIQUE NOT NULL,
CHAR (50) NOT NULL,
CHAR (100),
10
TELEPHON
PRIMARY KEY (DOCTOR_NO));
CHAR (20),
CREATE TABLE APPOINTMENTS
(APPOINT_ID
INTEGER UNIQUE NOT NULL,
PATIENT_SOC_SEC_NO
CHAR (30) NOT NULL,
APPOINT_DOCTOR_NO
CHAR (6) NOT NULL,
APPOINT_DATE
DATE NOT NULL,
APPOINT_TIME
TIME NOT NULL,
SYMPTOMS
CHAR (200) NOT NULL,
NOTES
CHAR (200),
PRIMARY KEY (APPOINT_ID),
FOREIGN KEY (PATIENT_SOC_SEC_NO) REFERENCES PATIENTS,
FOREIGN KEY (APPOINT_DOCTOR_NO) REFERENCES PHYSICIANS);
CREATE TABLE DRUGS
(DRUG_CODE
DRUG_NAME
COMPOSITON
CONTRAINDICATION
SIDE_EFFECTS
MANUFACTURER
PRIMARY KEY (DRUG_CODE));
CHAR
CHAR
CHAR
CHAR
CHAR
CHAR
(12) UNIQUE NOT NULL,
(70) UNIQUE NOT NULL,
(200) NOT NULL,
(200) NOT NULL,
(200) NOT NULL,
(200) NOT NULL,
CREATE TABLE DISEASES
(DISEASE_CODE
DISEASE_NAME
SYMPTOMS
TREATMENT
PRIMARY KEY (DISEASE_CODE));
CHAR
CHAR
CHAR
CHAR
(12) UNIQUE NOT NULL,
(100) NOT NULL,
(200) NOT NULL,
(200) NOT NULL,
CREATE TABLE RECOGNIZED_DISEASES
(RCGN_APPOINT_ID
INTEGER NOT NULL,
RCGN_DISEASE_CODE
CHAR (12) NOT NULL,
PRIMARY KEY (RCGN_APPOINT_ID, RCGN_DISEASE_CODE),
FOREIGN KEY (RCGN_DISEASE_CODE) REFERENCES DISEASES,
FOREIGN KEY (RCGN_APPOINT_ID) REFERENCES );
CREATE TABLE PRESCRIBTIONS
(PRESCRIPTION_ID
INTEGER UNIQUE NOT NULL,
PRESC_APPOINT_ID
INTEGER NOT NULL,
PRESC_DRUG_CODE
CHAR (12) NOT NULL,
DOSE
NUMERIC (12,6) NOT NULL,
MEASURE_UNIT
CHAR (3) NOT NULL,
FREQUENCY
CHAR (30) NOT NULL,
PERIOD
CHAR (20) NOT NULL,
PRIMARY KEY (PRESCRIPTION_ID),
FOREIGN KEY (PRESC_DRUG_CODE) REFERENCES DRUGS,
FOREIGN KEY (PRESC_APPOINT_ID) REFERENCES );
CREATE TABLE DRUG_CURES_DISEASE
(CURE_DISEASE_CODE
CURE_DRUG_CODE
CHAR (12) NOT NULL,
CHAR (12) NOT NULL,
11
TYPICAL_DOSE
NUMERIC (12,6),
MEASURE_UNIT
CHAR (3) NOT NULL,
TYPICAL_FREQUENCY
CHAR (30),
TYPICAL_PERIOD
CHAR (20),
PRIMARY KEY (CURE_DISEASE_CODE, CURE_DRUG_CODE),
FOREIGN KEY (CURE_DRUG_CODE) REFERENCES DRUGS,
FOREIGN KEY (CURE_DISEASE_CODE) REFERENCES DISEASES);
CREATE TABLE DRUG_INTERACTIONS
(DRUG_CODE1
CHAR (12) NOT NULL,
DRUG_CODE2
CHAR (12) NOT NULL,
DESCRIPTION
CHAR (200),
PRIMARY KEY (DRUG_CODE1, DRUG_CODE2),
FOREIGN KEY (DRUG_CODE2) REFERENCES DRUGS,
FOREIGN KEY (DRUG_CODE1) REFERENCES DRUGS);
4. EasyCASE
EasyCASE is a simple CASE tool. The abbreviation CASE stands for Computer-Aided Software Engineering and denotes software tool, which supports analysis, design, implementation, testing and evolution
of software systems. EasyCASE supports data modeling as well as process modeling, however, in this
instruction we deal only with the former.
A typical sequence of activities in EasyCASE during data modeling and database schema generation
contains following steps:
1. Drawing and naming entities on the ERD.
2. Associating entities using relationships.
3. Creating records for entities and relationships (only for M:N and n-ary relationships).
4. Creating attributes (components) for each record.
5. Defining primary, foreign and alternate keys.
6. Choosing schema generation options (the target database determines which data types are available
when you define components).
7. Creating component definitions.
8. Generating relational database schema (in SQL DDL).
Because of the limitations of EasyCASE and problems with managing diagrams with too many objects
attributes must be defined as record components (not as separate graphical objects as in classical Chen
notation) and relationships with cardinality 1:N must not be “exploded” into records. This is caused by
the fact, that EasyCASE generates separate table schemata for each record and does not merge tables with
the same key. So if you define two records with the same key (e.g. the first for an entity and the second
for a 1:N relationship which is attached to this entity with the end with cardinality N), EasyCASE will
generate two CREATE TABLE statements and the optimization (joining the tables schemata) will have to
be carried out manually.
12
4.1. Creating and managing projects
EasyCASE stores all charts, records, elements, and text files associated with a system design, in a single
project directory. Project directories are the same as Windows directories and subdirectories. When you
create a new project, EasyCASE creates a new directory. To create a new project:
1. Open the Project dialog box by choosing Project... from the File menu.
2. Enter the path and directory name in the Directory text box.
3. To accept the name, click on the Open button.
4. Because this is a new project, EasyCASE displays a message informing you that the project directory
does not exist, and asks you if you would like to create it.
5. To create the directory, click on OK.
Next EasyCASE displays the Create New Project Configuration dialog box where you configure the new
project. EasyCASE helps ensure consistency in the type of charts you use in a project by letting you select
methodologies for process and data modeling. Once you have selected them, EasyCASE will let you create only those types of charts that are supported by the methodologies.
Fig. 8. Configuring a new project
The procedure described below for configuring a new project assumes you have just created a new project
directory and have chosen to open the new project:
1. After entering a new project directory path and name and clicking on Open in the Project dialog box,
EasyCASE displays the Create New Project Configuration dialog box (fig. 8).
2. Enter a project name. The name can be up to 32 characters long and can use any standard ASCII
characters.
13
3. Select Chen notation (the Data Model Methodology list box). As the laboratory is limited to data
modeling, the process model doesn't matter.
4. EasyCASE will automatically create filenames for new charts and text files. If you want to provide
your own filenames, check the Allow User File Name Override option.
5. If you want to require object names for all objects you place on charts, check the Require Object
Names option. If you select this option, you must name an object when you place it on a chart.
6. If you want to allow duplicate names for all objects on all chart types, select the Allow Duplicate
Names option.
7. To accept the settings, click on the OK button.
4.2. Creating charts
To draw entities and relationships you must first create a chart of type Entity Relationship Diagram:
1. Choose New... from the File menu or click on the New Chart button in the Toolbar.
2. EasyCASE displays the New Chart dialog box (fig.9).
3. Select Entity Relationship Diagram from the Chart Type list box.
4. Enter a chart name. The name may be up to 32 characters long. This field is required.
5. EasyCASE proposes a file name for the new chart. If you have selected the Allow User File Name
Override option under Project Preferences, you can enter a different filename. However, you cannot
change the filename extension.
6. To accept the new chart information, click on OK.
7. EasyCASE checks to ensure the chart name and filename are not already being used for another chart.
If the names are not assigned to another chart, EasyCASE removes the dialog box and displays the
new blank chart. If the names are already assigned to another chart, EasyCASE displays a message
informing you that you must select different names.
Fig. 9. Creating a new chart
4.3. Adding entities and relationships
To add an entity or a relationship to a chart, select its symbol from the Objects menu or the Objects
Palette (fig. 10) and click on the desired location. EasyCASE draws the symbol at the default size and
aligns it with the nearest center cross on the drawing grid. Symbols can overlap, but they cannot occupy
the same center cross.
14
Edit mode
Entity
Weak Entity
Split Entity
Relationship
Identifying Relationship
Attribute
Primary Key Attribute
Foreign Key Attribute
Muli-Valued Attribute
Derived Attribute
Association
Subtype / Supertype
Text Block
Fig. 10. Object palette used on ERD in Chen notation in EasyCASE
If the Prompt for Name option (located in the Editor Preferences dialog box) is on, EasyCASE will display the Name Object dialog box. If the Repeat Object Placement option (located in the Editor Preferences dialog box) is on, you can continue adding symbols by moving the mouse pointer and clicking the
left mouse button. To stop adding symbols, press the ESC key, or click on the Select icon in the Objects
Palette, or select another object. If the Repeat Object Placement option is off, you must select a symbol
type each time you want to add a symbol.
4.4. Naming entities and relationships
When you add a symbol to a chart and name it, you identify the symbol to the data dictionary. Any number of symbols can have the same name. Names can be up to 32 characters long. If you delete an object,
the name is also deleted.
To name a symbol:
1. Select the symbol and choose Name... from the Edit menu or pop-up menu, or click on the Name
button in the toolbar.
2. EasyCASE displays the Name Object dialog box.
3. Enter a name in the Chart Object Name field, or select an existing name from the combo box.
4. When you click on OK, EasyCASE closes the dialog box and places the name inside the object if it is
a symbol, or next to the object if it is a connection.
4.5. Changing or deleting a chart object name
As you develop a chart, you may find it necessary to change an object name, or delete the name entirely.
To change or delete an object's name, you use the Name Object dialog box. When you change or delete an
15
object's name, EasyCASE breaks the link between the object and the data dictionary entry. It does not
delete the data dictionary entry. This makes sense if you recall that a data dictionary entry may be used by
more than one object.
To change an object's name:
1. Select the object.
2. Choose Name from the Edit menu or Edit pop-up menu, or click on the Name button in the toolbar.
EasyCASE displays the Name Object dialog box. The list box in the dialog box displays all existing
names for the selected object type.
3. Enter a new name or select a name from the list.
The deletion of object's name is carried out analogically.
4.6. Connecting symbols
Connections on a chart of type ERD are called associations. An association is depicted by a line and joins
a pair of symbols (e.g. an entity with a relationship).
When you add a connection to a chart, EasyCASE uses the line style set in the Chart Preferences dialog
box. Diagonal lines (unpiped) take the shortest distance between the source and destination symbols.
Piped connections use horizontal and vertical line segments. If you try to add a connection that violates
the methodology rules for the chart, EasyCASE displays a message box telling you that you cannot complete the connection. On ERD only connections between entity and relationship symbols, entity and attribute symbols, and relationship and attribute symbols are allowed.
To add a connection between two symbols:
1. Choose an association object from the Objects menu or Object Palette.
2. Select the source symbol on the chart by clicking inside the symbol. EasyCASE displays a number of
small boxes called "exit ports" around the symbol. The connection can exit the symbol at any of the
ports.
3. Select an exit port by pointing to it with the mouse pointer and clicking the left mouse button. The
ports will disappear except the one you selected. You are ready to draw the connection to the
destination symbol.
4. Move the mouse pointer to the destination symbol. Do not hold down the left mouse button. As you
move the pointer, EasyCASE draws the connection.
5. Display the entry ports on the destination symbol by clicking the left mouse button inside the symbol.
6. Select the entry port by moving the mouse pointer to the port and clicking the left mouse button.
EasyCASE draws the connection and adds handles at the ends and center of each line segment. You
can now edit the connection if you wish.
The point where two line segments join and change direction is called a way point. Way points are always
located on a minor dot of the drawing grid. When you select a connection, EasyCASE displays handles at
the way points and the midpoint of each line segment. You can drag the handles to change the route of a
connection.
If you are in the process of adding a connection and change your mind, you can press the ESC key to
cancel the operation. You can add line segments to a connection by clicking with the left mouse button as
16
you move the mouse pointer from the source symbol to the destination symbol. Any time before selecting
the destination symbol, you can delete the last way point in a connection by clicking the right mouse button. You can delete line segments back to the exit port by continuing to click the right mouse button.
4.7. Defining records
An entity symbol is linked ("explodes") to a record in the data dictionary that defines the structure of the
database table. In Chen notation also relationships with cardinality M:N and n-ary relationships should be
linked to a record. The record defines the name of the database table and index, if any, and provides a list
of the columns of the table. Each column is defined by a component name (up to 32 character in length)
and refers to an element in the data dictionary. An element is used to provide additional detail about a
field such as its type, length, constraints, and format.
To link entities (or relationships) to record definitions:
1. Choose Define Child... from the Edit menu or Edit pop-up menu, or click on the Define Child button
in the Toolbar. EasyCASE displays the Define Child dialog box (Fig. 11).
2. Choose Record from the Child Type list box. EasyCASE automatically fills in the Child Name field
using the name of the entity.
3. Accept the default name, or select a name from the list, or enter a new name in the Child Name field.
4. Click the OK button to approve the settings in the dialog box and return to the chart.
5. To explode down to the record, choose Goto Child from the Explodes menu. EasyCASE displays the
Record DDE Screen dialog box.
Fig. 11. Exploding an entity or relationship into a record
4.8. Creating columns
Columns corresponding to attributes of entities or relationships should be entered as record components.
A component name should be the name of an element data dictionary entry (DDE). You can type in a
name, or select a name from the Component Name list box. If you enter a new component name, you will
have to create an entry in the data dictionary for the component, by exploding down to an element data
dictionary entry. The components are shown in the list area in the order they are created.
17
To insert a new component name (fig. 12):
1. Move the cursor to the place in the list of components where you want to add the new component
name. If the list is blank, skip Step 2 below.
2. Click on the Insert button to create a blank line before the selected component.
3. Move the mouse pointer to the Component Name combo box and press the left mouse button.
4. Type in a name or select a name from the combo box.
5. To add the name to the list, click on the blank line in the component list. EasyCASE adds the name to
the list.
Fig. 12. Defining record components (columns)
To add a component name at the end of the list use the Append button. To delete a component, select the
component and click on the Delete button at the right edge of the dialog box.
After you have defined the columns, you can specify which columns form the primary key, alternate keys,
or foreign keys. To designate one or more columns as the primary key:
1. Select a component from the component list with the mouse or with the up and down arrow keys.
EasyCASE displays the component information in the edit boxes above the list.
2. Enter a "Y" in the Key text box.
3. Click on the component name in the list to update the information.
4. To create a composite primary key, select another column and repeat the steps above.
18
In EasyCASE foreign keys must be implemented manually by adding columns and linking them to tables.
When you designate a column as an alternate key or foreign key, you use a two-letter code and an optional number from 1 to 99. The codes for the keys are:
 AK – Alternate Key
 FK – Foreign Key
To create composite foreign or alternate keys, you give two or more columns the same number.
A foreign key must be linked to the table (record) from which it originates:
1. Select the column forming the foreign key to be linked from the component list.
2. Click on the Link button. EasyCASE displays the Name Object dialog box.
3. Select a record from the Name list box. Note the record must already exist. You cannot type in a new
record name.
4. To accept the record name, click on OK.
4.9. Defining column properties
Defining record components tells the Schema Generator what columns to create in the schema. However,
the Schema Generator needs more information to create those columns, such as name, data type, length,
constraints, and format. You use the Element Editor dialog box to enter these properties.
Fig. 13. Defining element (column) properties
To create element definitions:
1. Select a component name in the Record DDE Screen dialog box.
2. Click on the Explode button (or double-click on the component name). The Element Editor dialog
box appears (fig. 13). If the component you select doesn't already exist in the data dictionary,
EasyCASE creates it.
19
3. Move the cursor to the Name text box and enter the name of the field as it should appear in the database. You can enter up to 32 characters in this text box. However, you should enter only as many
characters as the target database supports.
4. Move the cursor to the Length text box and enter the field length.
5. Move the cursor to the Type list box and select one of the predefined data types. The current Schema
Type setting determines the list of available data types.
6. Choose element data constraint from the Constraint list box.
7. Enter optional information in the Format, Misc #1, and Misc #2 text boxes provided for your use.
These text boxes are free form and can contain any type of information.
8. Click the OK button to create or update the current element and return to the chart.
4.10. Displaying details in entity relationship diagrams
EasyCASE gives you several options for displaying entity details in the Chart Editor. For example, you
can have the Chart Editor display a record name as well as the names of the record components. You can
also display more detailed information such as columns names, types, and lengths. You can display
details for all elements of the components of each entity or only the elements of those components defined as primary keys.
4.11. Database schema generation
After you create an ERD, link each entity to a record, and define elements that determine the structure of
database tables, you can generate the database schema following instructions given below:
1. Determine the statements you want to insert in the schema file using Options from the Schema menu.
2. Specify the path for the schema output files. The Schema Generator produces one or more files, depending on the schema type you want to generate and whether or not you want the Schema Generation Status Report sent to a file. By default the files are written to the project directory. You can
change this using Path... from the Schema menu.
3. Save the current diagram in the Chart Editor.
4. Choose Generate from the Schema menu to run the Schema Generator.
5. If the schema already exists, EasyCASE displays the message box. Note that EasyCASE stores only
one set of schema files per chart. Each time you generate a schema, it overwrites the previous schema
files. To overwrite the existing schema files, click the OK button.
6. View or print the generated schema. The Schema Viewer window is divided into two parts. The top
part displays the schema. The bottom part displays the log of the generation process, showing errors
that occurred during the process.
5. Bibliography
Ullman J.D., Widow J.: A First Course in Database Systems. Prentice-Hall International 1997
EasyCASE 4.1 User's Guide. Evergreen CASE Tools 1994
EasyCASE 4.1 Schema Generator User's Guide and Tutorial. Evergreen CASE Tools 1994
EasyCASE 4.1 Methodology Guide. Evergreen CASE Tools 1994
EasyCASE 4.1 Online Help
20