Book Artic Designer PDF

2.
Oracle Designer I: ER-Diagrams 2-1
Part 2: ER-Diagrams
in Oracle Designer
References:
• Barker: CASE*Method, Entity Relationship Modelling.
Addison-Wesley, 1990, ISBN 0-201-41696-4, ca. $61.
• Koletzke/Dorsey: Oracle Designer Handbook, 2nd Edition.
ORACLE Press, 1998, ISBN 0-07-882417-6, ca. $40.
• A. Lulushi: Inside Oracle Designer/2000.
Prentice Hall, 1998, ISBN 0-13-849753-2, ca. $50.
• Oracle/Martin Wykes: Designer/2000, Release 2.1.1, Tutorial.
Part No. Z23274-02, Oracle, 1998.
• Oracle Designer Model, Release 2.1.2 (Element Type List).
• Oracle Designer Online Help System.
• Oracle Designer Forum:
[http://forums.oracle.com/forums/thread.jspa?messageID=2386897]
• Oracle Developer Tools:
[http://www.oracle.com/technology/products/developer-tools/index.html]
• Teorey: Database Modeling & Design, 3rd Edition.
Morgan Kaufmann, 1999, ISBN 1-55860-500-2, ca. $32.
• Elmasri/Navathe: Fundamentals of Database Systems, 2nd Ed.,
Appendix A, “Alternative Diagrammatic Notations”.
• Rauh/Stickel: Konzeptuelle Datenmodellierung (in German), Teubner, 1997.
Stefan Brass: Datenbanken II A Universität Halle, 2008

2. Oracle Designer I: ER-Diagrams 2-2
Objectives
After completing this chapter, you should be able to:
• write a short paragraph about Oracle Designer.
What is it, what are its main components, and how does it support
the design and development of database application systems?
• draw ER-diagrams in the graphical syntax of Oracle

Designer.
With and without actually using the tool. You should also be able to
read such diagrams, and to enumerate the supported ER-constructs.
• explain the difference between the global DB sche-

ma and the views contained in single diagrams.
• explain the role of the repository.

Overview
' $
1. Oracle Designer
& %
2. Entities and Relationships
3. Multiple Diagrams for one Schema
4. Attributes, Domains, Advanced Constructs
5. Repository Reports, Rep. Object Navigator

Oracle Designer (1)
• Oracle Designer is a CASE tool.

CASE = Computer Aided Software Engineering. It was earlier called
Oracle CASE*Designer, then renamed to Designer/2000 and is now
called Oracle Designer.
• Some people also call it “documentation tool”.

The main goal of database design tools is to collect all design infor-
mation (documents) in one place.
• Oracle Designer is a large software package that

helps to design databases and application programs
(together: DB Application Systems).
It is not a database system.

Oracle Designer (2)
• E.g., it contains a graphical editor for ER-diagrams,

called the “Entity-Relationship Diagrammer”.
But that is not more than 10% of the entire tool.
• Not all design information that Oracle Designer

manages is visible in the diagrams.
E.g. when one clicks on an entity type, a dialog box opens that permits
to store further information.
• Oracle Designer can also be used to design data-

bases for non-Oracle systems.
Oracle’s application programming tools are specially supported, but
the pure DB design works well for other systems.

Oracle Designer (3)
• Oracle Designer supports the following types of dia-

grams for modelling system requirements:
Business Process Diagrams
Entity-Relationship Diagrams
Dataflow Diagrams
Function Hierarchy Diagrams
• In addition, there are two types of design diagrams:
Server Model Diagram (Relational DB Schema)
Module Diagram (Application Programs)

Oracle Designer (4)
• Oracle Designer has also tools that generate

relational schemas from ER-schemas (Database
Design Transformer),
It can also produce DDL code (schema definitions) for DBMS
from other vendors, not only Oracle.
first-cut application programs (Application De-

sign Transformer).
Code can be generated for stored procedures/triggers (PL/SQL),
Oracle Developer (Forms), Oracle Report Builder (produces re-
ports in PDF and HTML format), Oracle Application Server (web
interface consisting of PL/SQL Procedures), C++, Visual Basic,
MS Help.

Oracle Designer (5)
• Oracle Designer has also tools for capturing and

reverse engineering the design of an existing DB.
This takes the information from (a) the data dictionary of an Oracle
DB, or (b) from DDL files, or (c) via ODBC calls.
• Also the design of certain pre-existing application

programs can be extracted and added to the Desi-
gner information.
• Oracle Designer has also tools for creating reports
about the design (design documents) out of the
collected information, cross-referencing tools, etc.

Oracle Designer (6)
• All Designer tools are integrated: E.g. entities crea-

ted with the ER-Diagrammer can be referenced in
dataflow diagrams.
• Oracle Designer supports work in all phases of the
system development lifecycle.
Tools supporting only the first phases are called “Upper CASE Tools”.
In contrast, physical design information, storage information, database
users etc. can be specified in Oracle Designer so that the database
can be completely generated out of the collected information. Also a
large part of application program development can already be done
inside Oracle Designer.

Oracle Designer (7)
• Oracle Designer supports groups of designers de-

veloping a database application system together.
This is based on the multi-user features of the underlying database
system. If the “Broadcast Server” is installed, users are automatically
notified when objects in their diagrams are changed by other users.
• It also has support for version management.

This was significantly extended in version 6i.
• UML is not supported in Oracle Designer.

There was an extension of Oracle Designer called “Object Database
Designer” (ODD) which supported a subset of UML. It was shipped
e.g. with Designer 2.1.2, but it is not being further developed and not
included in Designer 6i. Oracle JDeveloper supports UML.

Oracle Designer (8)
• Oracle Designer runs only on Windows.

• From the Tutorial:
“Oracle Designer is a software tool for analyzing busi-
ness requirements and for designing and generating cli-
ent/server systems that meet those requirements. Oracle
Designer incorporates support for business process mode-
ling, systems analysis, software design and system genera-
tion.”
“Oracle Designer provides a multi-user repository and is
closely integrated with Oracle Developer, Oracle’s client
/ server development toolset. In this way, Oracle Designer
allows organizations to design and rapidly deliver scalable,
client/server systems that can adapt to changing business
needs.”

Oracle Designer (9)
• Oracle Designer is not further developed by Oracle,

although Designer 10g (10.1.2.4) is a supported
product, and there are Open Source / Third Party
tools developed for it.
Oracle Designer Extension Builder was released in March 2007.
• Oracle is committed to long-term support of Oracle

Designer (also Oracle’s own E-Business Suite was
developed with Oracle Designer).
There is a large investment in the meta data stored in Oracle Designer
(e.g. database schemas, design documentation). At some point in the
future Oracle will probably develop a tool for migration to JDeveloper.

Oracle Designer (10)
• Oracle sees JDeveloper (UML and Java/J2EE) as

the long-term replacement, although it admittes
that currently Designer is more powerful for da-
tabase modeling and generation than JDeveloper.
Forms, Reports, Designer are now called the “Traditional Tools”.
Java, SOA, and Web 2.0 are the marketing headlines for the newer
tools. However, the Oracle Application Server supports both, and also
the integration of programs developed with both approaches.
• The problem is that new Oracle DBMS features

are not supported in Oracle Designer.


Repository (1)
• Oracle Designer stores the design information not

in files, but in an Oracle database.
Also the diagrams are stored in the database. Whereas one can design
also non-Oracle databases, the design information must be kept in an
Oracle database.
• The set of all tables etc. used for storing this in-
formation is called the repository.
The Designer 2.1.2 repository contains 1532 objects, of which are
107 tables, 273 views, 149 indexes, 64 constraints, 17 triggers, 9 se-
quences, 472 packages, 510 package bodies.
In Designer 6i, the repository consists of 5549 (6i Release 1) or
5561 (Release 2 and 3) objects. Release 1: 392 tables, 757 indexes,
720 views, 1008 constraints, 1025 triggers.

Repository (2)
• A repository is similar to a data dictionary (system

catalog).
It also contains meta-data (data about data, e.g. table and column
names of another database are data in the repository database).
• Whereas a data dictionary contains only the rela-

tional schema, the repository contains all design
information, including, e.g. ER-diagrams and app-
lication program designs.
Also, a data dictionary contains meta-data of the database itself. The
repository contains information about a different database (that still
needs to be constructed).

Repository (3)
Schema:
Repository Tables etc.

defined by Oracle
Instance: ?
Schema:
Design Data entered defines- Tables etc.

e.g. via ER-Diagrammer of the goal database
Instance: ?
Data entered by the

user of the goal DB

Repository (4)
• Design data about several projects (each in several

versions) can be stored in the same repository.
In Oracle Designer, projects are called “Application Systems”
(the goal of the project: database + application programs).
• In order to use Oracle Designer, one needs an ac-

count on the DB in which the repository is stored.
• The user who has installed the repository under
his/her account is called the repository owner.
He/She can give access to the repository to other users of the same
database. This is done with the repository administration utility (RAU)
and the repository object navigator (RON), see Appendix C.

Repository (5)
• The different tools are integrated, because they all

store and retrieve their information from the com-
mon repository.
• The multi-user features are also in part inherited
from the underlying database system.
Longer term locks are managed by flags in the repository tables.
• Oracle Designer is user-extensible: The Repository

has a documented application program interface.
It consists of view definitions and PL/SQL procedures.
See also below for user-defined properties.

Repository (6)
• E.g. developers can write their own style-checker

for ER-diagrams using the information stored in the
repository.
• The technical way to learn about Oracle Designer
is to understand the database schema (“meta mo-
del”) defined by Oracle for storing design informa-
tion in the repository.
Actually, besides a tutorial and the quite extensive online help, the only
documentation shipped with Designer 2.1.2 explains the repository
API and the meta model.

Repository (7)
• Prior to version 6i, the repository was used only for
Oracle Designer, and had no version control.
• Then there was a big change:
Oracle Repository and the Software Configurati-
on Manager (Oracle SCM) became an indepen-
dent product (part of the Developer Suite),
which was intended for arbitrary software pro-
jects, and used e.g. in JDeveloper 9i and 10g.
Version control (branching / merging versions)
and configuration management was added.

Repository (8)
• However, it seems that many software developers
preferred CVS or subversion.
• Therefore, starting from JDeveloper 10.1.3, the
built-in support for Oracle SCM was removed.
• Bugfixes in SCM 10g are still done, it remains a
supported product, but no new features are added.
• Nevertheless, one cannot fully understand the re-
pository from its use in Oracle Designer alone.
Some features of the Repository are not used in Oracle Designer
(e.g., folders, see below). This might be confusing, because they are
available in general repository tools (applied also in Oracle Designer).

Repository (9)
• Version control in the repository can be enabled or
disabled.
It is installed with version control disabled. The repository owner can
enable it, but then it can never be disabled again.
• A workarea is a view on the repository that contains

only one version of selected repository objects.
A workarea specification definies which object version is visible in a
workarea. It contains also a prioritized list of configurations included.
Workareas can be private (belong to a single used only) or shared.
• With version control disabled, there is only a single

workarea, the “Global Shared Workarea”.

Repository (10)
• Objects in the repository are structured into con-
tainers (like a directory tree in the file system).
• Containers can be of two types:
Application System: Only this type is supported
for modelling elements in Oracle Designer.
The name “Application System” for a container type might seem
strange. It has historical reasons: In older versions of the Designer,
the repository could store several application systems (projects).
Folder: Intended for uploading standard files to

the repository.
Folders are supported by the core repository, application systems
are available only after the Designer is installed.

Meta Model (1)
• For the repository, Oracle defined

Element types (such as entity, attribute, relati-
onship end, unique identifier) and for each ele-
ment type a number of properties.
There are about 200 different element types.
Association types (i.e. relationships between ele-

ment types, e.g. “function entity usage”)
There are 39 different association types.
Text types (e.g. description, PL/SQL block).

There are 38 different text types.

Meta Model (2)
• The element types are distinguished in

Primary Access Controlled Elements (PAC),
e.g. table definition.
PACs are owned directly by a container.
Secondary Access Controlled Elements (SAC),

e.g. column definition (owned by a PAC).
• If a PAC is copied or deleted, all depending SAC
elements are copied or deleted, too.
• Version control applies at the PAC level.

Meta Model (3)
• The Repository Object Navigator (RON) can be

used to view and edit most of the properties of the
repository elements.
• Also direct SQL access to the views is possible, up-
dates can be done via the API PL/SQL procedures.
• Tools like the ER-Diagrammer give a nicer interface
to a subset of the information that can be accessed
with RON.
Actually, the graphical data (position of entities) cannot be accessed
with RON. But one can e.g. edit attributes of entities.

Meta Model (4)
• The complete meta model is defined under

Programs → Repository 6i Doc → Model
Reference
• E.g., entity types have the following properties:
OWNING_CONTAINER: Name of application system
(or version), to which this entity belongs.
NAME: Name of the entity type (singular form).
PLURAL: Plural form of the name (table name).
SHORT_NAME: Shorthand for the entity type name
(used in generated foreign key column names).

Meta Model (5)
• Properties of entity types, continued:

TYPE OF: Name of superclass (if this is a subclass).
INITIAL_VOLUME: Initial number of entities of this
type.
ANNUAL_GROWTH_RATE: Expected increase (in %) in
the number of entities per year.
VOLUME: Average number of entities of this type.
MAXIMUM VOLUME: Maximal number of entities of
this type.

Meta Model (6)
• Properties of entity types, continued:

DATAWAREHOUSE_TYPE: “Dimension” or “fact” (only
for data warehouse applications).
DESCRIPTION: Explanation of the meaning of the
entity type (definition).
NOTES: Annotation for the database designers.
• All of these properties correspond to fields in the
dialog box that contains the entity data.
This dialog box also permits to specify attributes. “Attribute” is ano-
ther element type of the meta model with its own set of properties.

Meta Model (7)
• Standard properties of all element types:

ID
DATE_CREATED
CREATED_BY
DATE_CHANGED
CHANGED_BY
NUMBER_OF_TIMES_MODIFIED
ELEMENT_TYPE_NAME
TYPES
CHECKOUT_VERSION

Meta Model (8)
• The view CI_ENTITIES has the following columns:

ANNUAL_GROWTH_RATE
CHANGED_BY
CREATED_BY
DATAWAREHOUSE_TYPE
DATE_CHANGED
DATE_CREATED
ELEMENT_TYPE_NAME
ID
Meta Model (9)
• Columns of CI_ENTITIES, continued:

INITIAL_VOLUME
INSTANTIABLE_FLAG
IRID
IVID
MAXIMUM_VOLUME
NAME
NUMBER_OF_TIMES_MODIFIED
PLURAL
Meta Model (10)
• Columns of CI_ENTITIES, continued:

SHORT_NAME
SUPERTYPE_REFERENCE
TYPES
USER_DEFINED_PROPERTY_0
...
VOLUME
Meta Model (11)

• IRID: Internal Repository ID, identifier in the object
tree (unique within workarea).
Different versions of the same object have the same IRID.
• IVID: Internal Version Identifier, unique over all ver-

sions of all objects.
• The view CI_ENTITIES may return several versions
of an entity.
• Calling the PL/SQL procedure
jr_context.set_workarea(’hworkarea_namei’);
restricts the views to this workarea.
Meta Model (12)

Example for SQL-Query to the Repository:
• Print the names of all entities in the application
system called “brass”:
SELECT E.NAME
FROM CI_ENTITIES E, CI_FOLDER_MEMBERS M,
CI_APPLICATION_SYSTEMS A
WHERE M.MEMBER_OBJECT = E.IRID
AND M.FOLDER_REFERENCE = A.IRID
AND A.NAME = ’brass’
• CI_... are views and public synonyms.
Try: SELECT * FROM ALL_CATALOG WHERE OWNER = ’PUBLIC’ AND
TABLE_NAME LIKE ’CI\_%’ ESCAPE ’\’ (gives 385 rows).

Meta Model (13)
• The repository is user-extensible: One can add pro-

perties to existing element types, and it is also pos-
sible to add element types, association types, and
text types.
This is done with the Repository Administration Utility (RAU).
• So if one thinks that there is other important infor-

mation that should be recorded about entity types
(or other design elements), it is possible to extend
Oracle Designer in that way.

New Application System

• Design Information (like ER-diagrams) is organized
in application systems (and possibly folders).
To create a new application system, do the following:
(1) Start the ER-Diagrammer.
(2) Select File→New from the menu.
(3) The “Choose Container” dialog box appears. However, all choices
are empty. Choose the list symbol to the right of the selection field.
(4) The “Select Object” dialog box appears. Press “Create” button.
(5) The “Select Type” dialog box appears. Choose “Application Sy-
stems”. Press “Ok”.
(6) A “New Application System” appears back in the “Select Object”
dialog box. Click on it and enter your own name. Press Return.
(7) Now you are back in the “Choose Container” dialog box and the
application system that you just created should appear as the selected
option. Click the “Ok” button.

Overview
1. Oracle Designer
' $

& %

ER-Model Variants
• Variants of the ER-Model differ in:

The selection of ER modeling constructs.
See next page for the ER constructs supported in Oracle Designer.
The notation used for these constructs.

E.g. softboxes are used for entities, and the “crowsfoot”/“chicken
feet” notation for cardinalities.
The possibility to model also behaviour:

Methods/Operations supported by the entities.
This is typical for object-oriented approaches. Oracle Designer
has other tools for modeling this (Process Diagrams, Dataflow
Diagrams).

Supported ER-Constructs (1)

Oracle Designer supports the following ER-constructs:
• Binary relationships including recursive ones.
• The most important cardinalities.
0 and 1 as minimum, 1 and ∗ as maximum. The cardinality (1, ∗)
on both sides of the relationship is excluded (insertion would be too
difficult). In the repository, arbitrary min-max cardinalities can be spe-
cified, but they are not shown in the diagrams.
• Optional attributes (null values).

• Domains for attributes.
Domains are similar to user-defined data types, however, they are only
names for the standard datatypes of the DBMS. See below.

• Constraints on attribute values.

• Keys of entity types.
• Weak entities.
I.e. using a relationship as part of the key of entities.
• Disjoint and total specialization.

• Mutually exclusive relationships.
• Non-transferable relationships.
• Various additional information about entities.
E.g. synonyms, expected sizes, comments, further documentation.


Oracle Designer does not support these ER-constructs:
• Ternary etc. relationships.
As explained below, one can always replace relationships by “associa-
tion entities” and binary relationships.
• Relationship attributes.
Also in this case, one must turn the relationship into an (association)
entity with two binary relationships without attributes.
• Multivalued/structured attributes.
Multivalued attributes can be handled with weak entities. For struc-
tured attributes, the components can be declared as attributes.
• Non-disjoint specialization.

Entities and Attributes (1)
• The Oracle tool uses a “softbox” (rectangle with

rounded corners) for entity types.
• Attribute names are written into this box:
' $
INSTRUCTOR
# NAME
* ROOM
◦ PHONE
& %
• Attributes which are mandatory (not null) are mar-

ked with *, optional attributes with ◦.

• Key attributes are marked with #.

Attributes marked with # together constitute the primary key.
Key attributes are automatically mandatory, no * is needed.
• Oracle Designer allows to customize what is dis-

played, e.g. it is possible not to show attributes.
This is useful e.g. in order to get an overview of a large schema.
• More information is stored about entities which is

not graphically displayed.
One can open a dialog box with additional entity properties.
• Entity type names must be unique in the schema.

• In earlier versions, one could mention an example

entity at the bottom of the entity type box:
' $
INSTRUCTOR
# NAME
* ROOM
◦ PHONE
e.g. Brass
& %
• This is a nice idea, but it is no longer supported.

Of course, one can and should mention an example in the description
of the entity type (not shown in the diagram).

Relationships (1)
• Relationships are marked by lines between the en-

tity boxes (no diamond).
• The form of the line (dashed or solid) and the line
end (simple or crowsfoot) describe the cardinalities:
' $ ' $
INSTRUCTOR teacher of
HH

COURSE
taught by H
& % & %
• This is very illustrative: One instructor can teach

many courses, but each course is only taught by
one instructor (see below).

Relationships (2)
• Relationships have two names (seen from each of

the ends): The “from name” and the “to name”.
The relationship names correspond to the role names of entities used
in the “diamond” notation at least for recursive relationships.
• Just as a relationship between people, relationships

are “both way”: This is reflected in the two names.
• The same names can be used for different relati-
onships (they do not have to be globally unique).
Only between the same two entity types there cannot be two relati-
onships that agree in both, to and from name.


Notation for Cardinalities (1)
• In the first DB course, the (min,max)-notation for

cardinatities was introduced:
H
HH
(0, ∗)

HH
H (1, 1)
Instructor teaches Course
HH
HH
HH
H
HH
H
• An instructor entity can be related to any number

of course entities (between 0 and arbitrarily many).
• A course entity must be related to exactly one in-
structor entity (minimally 1 and maximally 1).

• As maximum cardinalities, only 1 and * are com-

mon. The maximum cardinalities on both sides clas-
sify a relationship as
Many-to-many (N:M): “*” on both sides.
One-to-many (1:N): “*” and “1”.
One-to-one (1:1): “1” on both sides.
• The example is “one-to-many” from instructor to
course, i.e. one instructor can teach many courses.
The maximum cardinality “*” is written on the instructor side (i.e. the
“one” side): The (min,max)-cardinalities on the instructor side descri-
be the outgoing edges from a single instructor (number of courses).

• As minimum cardinalities, only 0 and 1 are common:

The minimum cardinality “0” means optional (or
partial) participation in the relationship:
Not every instructor must teach a course.
The minimum cardinality “1” means mandatory
(or total) participation in the relationship:
Every course must be taught by an instructor.
• A relationship can be optional on both sides, op-
tional on one side and mandatory on the other, or
mandatory on both sides (difficult for insertions).

• The notation used in Oracle Designer can represent

the common maximum cardinalities (1 and ∗).
• For the maximum cardinality “∗” on the instructor
side, a crowsfoot is drawn on the course side:
H
H
( , ∗ ) ( , )
H

HH
HH
Instructor HH teaches

H
H

H
Course
HH
H
H
' $ ' $
INSTRUCTOR teacher of
HH

COURSE
taught by H
& % & %

• If the maximum cardinality should be “1” on the

instructor side (each instructor can teach only one
course), no crowsfoot is drawn on the course side:
H
HH
( , 1 )
H ( , )
HH
Instructor HHteaches Course

HH
H
H
HH
H
H
' $ ' $
INSTRUCTOR teacher of COURSE

taught by
& % & %

• The notation used in Oracle Designer can represent

the common minimum cardinalities (0 and 1).
• For the minimum cardinality “0” on the instructor
side, a dashed line is drawn on the instructor side:
H
H
( 0 , ) ( , )
H

HH
HH

H
H

H
Course
HH
H
H
' $ ' $
teacher of
INSTRUCTOR
HH

COURSE
taught by H
& % & %

• For the minimum cardinality “1” on the instruc-

tor side (each instructor must teach at least one
course), a solid line is drawn on the instructor side:
H
H
( 1 , ) ( , )
H

HH
HH

H
H

H
Course
HH
H
H
' $ ' $
teacher of
INSTRUCTOR
H

COURSE
taught by H
H
& % & %

Checking Cardinalities (1)
• If the role names of the relationship (“teacher of”,

“taught by”) are chosen rigorously, natural langua-
ge sentences that explain the cardinalities can be
automatically generated.
“Each (and every) INSTRUCTOR may be
teacher of one or more COURSES.”
“Each (and every) COURSE must be taught by
one and only one INSTRUCTOR (ever).”
Phrases in parentheses only emphasize, but don’t change the mea-
ning. They can be left out.

• “May be” indicates optional participation, “must

be” is used for mandatory participation.
Oracle Designer knows the plural form of every entity type, as re-
quired for generating these sentences. Some design reports that the
“Repository Reports” utility produces contain such sentences.
• Note that both sentences are needed to completely

describe the relationship.
• However, it is sometimes difficult to choose relati-
onship names that fit into this pattern.
They must consist of a noun (role) and a preposition. For verbs like
“teaches” a slightly different pattern would be needed.

• Such sentences can be shown to domain experts

(future users) who cannot read ER-diagrams.
• This is a way of validating the database schema
(checking it for correctness).
Keys and other constraints could be validated in the same way.
• Actually, one can even produce a question form and

let the user check whether it is true:
Each and every course must be taught by
one and only one instructor, is that true?
yes no

Cardinalities (1)
• The toolbar has nine different relationship types.

The first is “many to one (mandatory to optional)”:
H
HH
(1, 1) (0, ∗)
HH
H
HH
Course
HH

taught by
H
H
Instructor
HH
H
HH
H
• In Oracle Designer:
' $ ' $
COURSE H
HH
taught by INSTRUCTOR

teacher of
& % & %

Cardinalities (2)
• The next is “many to one (optional to optional)”:

H
H
HH
(0, 1)
H
HH (0, ∗)
Course HH taught by Instructor
H
H
HHH

HH
H
H
• In this case, a course has not necessarily a teacher

assigned.
' $ ' $
COURSE H
HH
taught by INSTRUCTOR

teacher of
& % & %

Cardinalities (3)
• Many to one (optional to mandatory):

H
H
HH
(0, 1) H
HH (1, ∗)
Course HH taught by Instructor
H
H
H HH

HH
H
H
' $ ' $
COURSE H
H
taught by
H INSTRUCTOR

teacher of
& % & %
Here an instructor must teach at least one course, and can teach any
number of courses. A course does not require an instructor, but can
have at most one.

Cardinalities (4)
• Many to one (mandatory to mandatory):

H
HH

(1, 1) (1, ∗)
H
HH
H
Inv Item H belongs to Invoice
HH
HH
H
HH
H
H
H
' $ ' $
INV_ITEM H
HHfor INVOICE

composed of
& % & %
Every invoice item belongs to exactly one invoice. An invoice can

consist of several items, but must consist of at least one.

Cardinalities (5)
• Many to many (mandatory to optional):

H
H
HH
(1, ∗) H
HH (0, ∗)
Order HH placed for Product
H
H
H HH

HH
H
H
' $ ' $
ORDER H
HH
placed for
PRODUCT
HH

subject of H
& % & %
Every purchase order must be for at least one product, but can be for
many products. One product can be ordered in many purchase oders.
There can be new products that are not yet ordered.

Cardinalities (6)
• Many to many (optional to optional):

H
H
HH
(0, ∗) H
HH (0, ∗)
Student takes Course
H

HH H

HH
H
HH
H
H
' $ ' $
STUDENT H
HH
registered for

COURSE
H

taken by HH
& % & %
• This is the most general relationship:

A student can take any number of courses (including zero), a course
can be taken by any number of students (again including zero).

Cardinalities (7)
• Many to many (mandatory to mandatory):

H
H
HH
(1, ∗) H
HH (1, ∗)
Student takes Course
H

HH H

HH
H
HH
H
H
• This is not supported in Oracle Designer.

• It would be very difficult to insert entities.
A student cannot be inserted without a course, and a course cannot
be inserted without a student. In general, when one defines cardina-
lities, one should think about elementary transactions. Which inserti-
ons/deletions must happen together such that the cardinality requi-
rements are satisfied at the end of the transaction? If the transaction
is too complicated, the cardinality requirements should be relaxed.

Cardinalities (8)
• One to one (mandatory to optional):

H
HH

(1, 1) H (0, 1)
H
HH
Department
H
HH led by HH Employee
H
HH
H
H
H
' $ ' $
DEPARTMENT led by EMPLOYEE

head of
& % & %
Every department is led by exactly one employee, an employee can be

head of at most one department.

Cardinalities (9)
• One to one (optional to optional):

H
HH
(0, 1) (0, 1)
HH
H
HH
Man
HHmarried to
H
HH

H
Woman
H
HH
H
' $ ' $
MAN married to WOMAN

married to
& % & %

Cardinalities (10)
• One to one (mandatory to mandatory):

H
HH
(1, 1) (1, 1)
HH
H
HH
Student has ID Card
H
HH
H
HH
H
HH
H
' $ ' $
STUDENT identified by ID CARD

owned by
& % & %
• Uncommon. Consider merging the two entities.

Recursive Relationships
• Oracle Designer does support recursive relation-

ships (between two entities of the same type).
' $
COURSE H
H
H
has precondition

& %
AA
A
is precondition for
• Oracle Designer actually displays recursive relation-

ships with a three-quarter circle (“swine ear”).

Overview
1. Oracle Designer

' $

& %

Multiple ER-Diagrams (1)
• Real World Database Schemas are often very large

(hundreds to thousands of entity types).
• If one produces only one diagram with all entity
types on it, one can use it as a wallpaper.
• It would be very difficult to find something on such
a large diagram.
• Even as a means for getting an overview or for
orientation purposes it would be useless.
The only use of such a large diagram is to get an impression of the
size and complexity of the database schema.

• Therefore, the schema must be split into several

diagrams.
• Oracle Designer (and similar CASE tools) distin-
guish between
the global database schema (stored in the repo-
sitory)
the subset of the information that is shown on a
particular diagram.

• The same entity type can be shown in more than

one diagram.
Since the entity types are connected by relationships, and often form
a connected graph, it is necessary to duplicate nodes (entity types) if
one wants to split the diagram and still show all edges (relationships).
• Also the same relationship can be shown on more

than one diagram, but this happens less frequently.
• It is possible that entity types or relationships in
the repository are not shown in any diagram.
This is probably only a temporary condition or may even be an error
(garbage left over from a deleted diagram).

• When using the ER-Diagrammer, one must distin-

guish between
Creating a new entity type: This will automati-
cally insert the entity type into the repository.
Including an entity type that already exists in the
repository into a diagram.
• Entity type names must be unique within an appli-
cation system (global schema in the repository).
If one tries to create an entity type with the same name as one that
already exists in the repository, one gets an error message.

• Relationships must be uniquely identified by the two

entity types and the “to” and “from” names.
Again, if one tries to re-create a relationship that still exists in the
repository, one gets an error message.
• When deleting an entity type or a relationship, one

must distinguish between
deleting it only from a single diagram,
deleting it from the diagram and the repository.
From time to time, one should search with the Repository Object
Navigator or the Repository Reports Utility for entity types and
relationships that were deleted from the diagrams but still exist
in the repository.

• Changes to an entity type done in one diagram will

be semi-automatically reflected in other diagrams.
If an entity or relationship is changed in the repo-
sitory, outdated versions still contained in other
diagrams will be marked with a red bullet.
There is a special command to update entities
or relationships on the diagrams from the repo-
sitory.

Overview
1. Oracle Designer

' $

& %

Entity Properties (1)
• By double clicking on an entity in a diagram, one

opens the “Edit Entity” dialog box.
• It gives access to the properties of the entity, its at-
tributes (including constraints for attribute values),
unique identifiers (keys), and synonyms.
• In this way, much more information can be stored
about the entity type than what is actually shown
on the diagram.
It is possible to customize what is shown in the diagram, e.g. all
attributes, only mandatory attributes, only the primary key attributes,
or no attributes.

• The dialog box has several tabs/pages:

Definition (name, plural, short name, etc.)
Synonyms (alternative names)
UIDs (keys and weak entity identification)
Attributes (list of all attributes)
Attribute Detail (one page for each attribute)
Attribute Values (constraints)
Text (documentation, notes).



“Definition” Page:
• Names of an entity (Short name, Name, Plural).
• Super class: “type of” (if this is a subclass).
• Expected number of entities of this type.
This information is important for physical design.
The initial, average, and maximum volume (number of entities) can
be specified, as well as the annual growth rate (in percent). The
meaning is a bit unclear, e.g. whether maximum is increased by the
annual growth rate, and over which time interval the average is taken.
• Datawarehouse type (if DW application).

“Fact” vs. “Dimension” tables (see below).



“Synonyms” Page:
• Alternative names for the entity can be defined.
• It is an important task in database design to check
whether things named differently by different users
are really the same concept.
• The Oracle DBMS permits to define synonyms for
tables and other database objects (not in SQL-92).
• However, it is also possible to treat synonyms only
as part of the design documentation, and not to
reflect them in the final relational schema.


“Text” Page:
• Textual descriptions/definitions of entities and at-
tributes can be stored (in ASCII or HTML).
• Also “Notes” about entities and attributes can be
stored, and the system can be extended to allow
other text types.
• These texts will be part of the design documen-
tation which can be generated by the “Repository
Reports” Utility.
In Oracle, comments can also be stored in the data dictionary.



“Attributes” Page:
• Here the entity attributes can be declared with the
following information:
Name
Sequence number to define the order in which
the attributes will be displayed (see below).
Domain, Data Type/Format (see below).
Is this attribute optional (i.e. possibly null)?
Is this attribute part of the primary key?
A short comment on the attribute.
• Possible attribute formats (data types) are

CHAR, DATE, IMAGE, INTEGER, MONEY, NUMBER, PHOTOGRAPH,
SOUND, TEXT, TIME, TIMESTAMP, VARCHAR2, VIDEO.
• Not all of these data types exist in Oracle or all the
other supported goal systems.
• It is a task of the logical design phase to map the
data types used in the conceptual schema to data
types supported in the selected DBMS.
E.g. IMAGE, VIDEO, and SOUND would be mapped to a binary large object
in Oracle (BLOB). The database design transformer contains mappings
for various systems.

• Some types (e.g. CHAR, VARCHAR2, NUMBER) require a

maximal length, some (e.g. NUMBER) also the number
of decimal places after the point (precision, “dec”).
• Instead of defining the data types for every attribu-
te separately, one should use domains (see below).
• If the sequence number is left blank, one gets the
default attribute sequence: (1) primary key attribu-
tes, (2) mandatory attributes, (3) optional attribu-
tes. Each group is alphabetically sorted.
The alphabetical order is usually not what is intended.



“Attribute Detail” Page:
• This tab has one page for each attribute.
The attribute is selectable in the “Name” drop-down list.
• Each page contains all the information defined in

the corresponding row of the “Attributes” table,
plus more (see next two transparencies).
Parameters shown on both pages are automatically updated on both
pages when they are changed on one.
• No syntax checks are done on e.g. the derivation

formula (any text can be entered, not only SQL).
Also the default value is not checked against the type.

• Information on the “Attribute Detail” page:

Physical design information: average length and
percentage of entities having a non-null value.
Units for the attribute (e.g. “kg”, “cm”, “in”).
A derivation formula/algorithm if this attribute
is derived.
A condition when this attribute can be used.
E.g. “Flight Hours” is defined if/only if (?) “Job” is pilot. E.g. on-
ly associate and full professors can have a value in the column
TENURE_SINCE.

• Information on the “Attribute Detail” page:

A representation for a null value if the DBMS
does not support null values.
This would be strange for a modern DBMS.
A default value (to simplify data entry).

If the entities/rows should be sorted by this at-
tribute, the relative priority of this sort criterion
and order (asc/desc).



“Attribute Values” Page:
• On this page, restrictions for the values of an attri-
bute can be defined (e.g. for “enumeration type”
attributes).
• One can define all possible values of an attribute:
Value
Sequence number
E.g. for printed documentation, menus in application programs.
Abbreviation
Meaning (help text)

• Already in the ER-design, information is collected

that later can be used for the generation of appli-
cation programs (forms for inserting data).
• Alternatively, one can define an interval of legal
values.
“Value” is the lower limit, “High Value” the upper limit. In general,
the union of set of intervals is possible (by using several rows with
“Value” and “High Value”), but this is hardly ever used.



“UIDs” Page:
• On this page keys (unique identifiers) can be defi-
ned.
• More than one key can be declared, but exactly one
must be marked as primary key.
Primary key information entered on this page is automatically reflec-
ted on the “Attributes” pages.
• The Designer does not prevent that a primary key

attribute is optional (which is illegal in SQL).
• Each key/unique identifier must be named.

• Not only attributes, but also relationships can be

used as a means for identification.
Entity types that use this are also called weak entity types, see below.
• E.g. if instructors had a relationship to depart-

ments, and the UID consists of this relationship
and the instructor name, there can be instructors
with the same name in different departments.
The foreign key that contains the ID of the department together with
the instructor name becomes a composed key of the instructor. This
works only for relationships with a (1, 1)-cardinality, e.g. on the many
side of a one-to-many relationship. The Designer does not check this.

Domains (1)
• Often different attributes should have the same da-

ta type, i.e. especially the same length. E.g.:
Years: Year an instructor got tenure, Year a cour-
se is offered, Year a student was admitted, etc.
URLs: Links to homepages of courses, instruc-
tors, departments.
Last Names: Of students, instructors, staff.
• It would be strange if some years are stored with
two digits, others with four, or student names can
be longer than instructor names.

Domains (2)
• Characteristics such as the maximal length of all

kinds of URLs should be defined only once.
• This ensures greater consistency in the schema,
especially when later changes are done (e.g. at-
tribute length increases).
• In Oracle Designer, one can define data types of
columns indirectly via domains:
Column -
Domain -
Data Type
“Homepage” “URL” “VARCHAR(80)”

Domains (3)
• One first defines a domain and then assigns this

domain to one or more attributes.
Instead of directly defining the data type details for the attributes.
That would have to be done for each attribute separately, while with
the domain the details are defined only once and used in possib-
ly many attributes. In Oracle Designer, domains are defined under
“Edit → Domains”.
• If a domain definition changes, one can propagate

this change to all attributes having this domain.
In Oracle Designer, this is done only semi-automatically. One must
call “Utilities → Update Attributes in Domain”.

Domains (4)
• Different domains may have same data type.

• E.g. last names of customers and names of cities
may both be VARCHAR(20), but it makes no sense to
compare them. Different domains should be used.
One should consider attributes of different domains as uncomparable
(unless declared as subtype).
• A domain can be seen as a “shorthand” for a stan-

dard data type, but with a specific meaning, diffe-
rent from other domains.

Domains (5)
• Domains can be used to capture the information

which attributes should be comparable.
This requires logical domain names, e.g. CITY, not VC20.
• The SQL-92 standard has a similar notion of do-

mains (without the restriction that columns of dif-
ferent domains cannot be compared).
This is not implemented in Oracle 8. But when domains are defined
in the Designer, they might be partially mapped to SQL domains in
other DBMS. Oracle 8 has PL/SQL types which could also be used.
But for consistent schema changes, it is already helpful that they are
supported in the Designer.

Domains (6)
• Domain names can often be used as attribute na-

mes. This makes joinable attributes very clear.
• Some designers have a set of standard domains,
which they always use.
E.g. names of length 10, 20, 40, descriptions of size 2000, email/URL
of size 250, ZIP codes, SSN, boolean values, etc. Selecting from a
set of predefined standard domains can be done faster than consi-
dering every attribute in isolation. In some projects, only a “domain
administrator” is allowed to create a new domain.
• However, this at least partially contradicts the idea

of logical domains.


Domains (8)
• The dialog box for defining domains has four tabs:

“Definition”: list of all defined domains.
“Detail”: one page per domain.
“Values”: for defining enumerated types etc.
“Text”: contains descriptions, notes, etc.
• In principle, the same parameters can be set as in
the attribute definitions.
• Whether an attribute is optional and whether it is
part of the key can only be defined in the entity
definition dialog.

Domains (10)
Format/Attribute vs. Datatype/Column:
• A domain definition contains information at the
ER-level (Format) as well as about the implemen-
tation (Datatype).
The documentation also mentions that the datatype can also be used
for application program variables, but then it depends on the program-
ming language. The type system of languages like C are quite different
from the SQL type system.
• E.g. “IMAGE” can be selected on the conceptual le-

vel, but it is implemented as a “BLOB”.
BLOB: “Binary Large Object”. The Datatype selector contains all da-
tatypes of Oracle as well as some types from other systems.

Domains (11)
Dynamic List:
• If this is checked, the possible values will be retrie-
ved at runtime from a lookup table.
This makes it easy to change the possible values of the enumeration
type later: One can simply insert a new value into the lookup table.
• Otherwise, they will be hardcoded (e.g. as CHECK-

constraint in the CREATE TABLE statement).
While an ALTER TABLE statement to change the constraint is not too
difficult (but not that several attributes in different tables might ha-
ve to be changed), the possible values might also be hardcoded in
application programs.

Weak Entity Types (1)
• If a relationship contributes to the identification,

there is a bar across the connecting line:
' $
' $
ROOM
BUILDING
home of # NUMBER
# NAME
HH
H
∗ TYPE
◦ YEAR BUILT contained in
◦ CAPACITY
& %
& %
• A room is identified by building and room number,

e.g. “Crawford Hall 169”.

• Different buildings of the university can have rooms

with the same number.
• When translated into tables, the key of the ROOMS
table will be composed from the building name and
the room number.
The building name in addition will be a foreign key that references
the BUILDINGS table.
• Entity types that must borrow key attributes from

other entity types are called “weak entity types”.
In the Oracle Designer documentation, this name is not used. One
simply declares a relationship as part of a UID for an entity type.

• It would be a bad design to explicitly replicate the

key attribute of the referenced table:
' $
' $
Wrong! ROOM
BUILDING # NAME
home of
# NAME # NUMBER

HH
H
◦ YEAR BUILT contained in ∗ TYPE

& % ◦ CAPACITY
& %
• Now the constraint is needed that a room with na-

me X is always related to a building with name X,
so that the relationship is actually redundant.
• In general, advanced constructs in the ER-model

are often introduced in order to avoid certain com-
mon kinds of constraints.
Or at least to specify these constraints graphically instead of as text
and permit a special implementation. If one would translate the above
schema where name and number are explicitly defined as key attribu-
tes into the relational model, one would get two copies of “Name”:
A second copy is introduced as foreign key in order to implement the
relationship (see below). Now with the constraint it becomes clear
that the two copies can be merged.
• Weak entity types are often used in master-detail

relationships, e.g. for an invoice and its line items.

• A weak entity type is existence-dependent on its

parent entity type (BUILDING in this case): If a
building is sold and removed from the database, all
rooms in it should be automatically removed.
For weak entity types, it is quite typical that in the resulting relatio-
nional schema “DELETE CASCADES” is defined for the foreign key that
implements the relationship.
• It is often a design decision how one selects a key:

If rooms have a number that it unique over all buil-
dings, the “Room” entity type is no longer weak.

• One can use a relationship for identification only

if there is at most one related entity (cardinality
(1, 1) or (0, 1)):
On the many side of a one-to-many relationship.
On both sides of a one-to-one relationship.
If there were several related entities, one would need set-valued attri-
butes (not supported in the standard relational model).
• At least for primary keys, the participation in the

relationship must be mandatory.
Primary key attributes cannot be null.

• There are two places to specify that a relationship

contributes to the identification of the entity:
In the entity definition, tab UIDs.
In the relationship definition.
In the “Edit Relationship” dialog box, one can also change the
optionality (minimum cardinality) and degree (maximum cardina-
lity) for each end, change the role name, and store a description
or notes for each relationship end.


Association Entity Types (1)
• Weak entity types can have more than one parent.

• Weak entity types with two (or more) parent types
are sometimes called “association entity types”, be-
cause they are similar to a kind of relationship bet-
ween the parent entity types.
• E.g. suppose that we need a relationship attribute:
HH
(0, ∗) HH
H (0, ∗)
Student HHsolved Exercise
HH
H
H
HH
@ H @
@ @
@ @

Name
Email
Points

No

MPoints

Association Entity Types (2)
• Oracle Designer does not support relationship attri-

butes. However, one can turn the relationship into
an association entity type:
' $
' $
STUDENT
author of
# NAME

HH
H
◦ EMAIL submitted by
& % SOLUTION
' $
∗ POINTS
EXERCISE
subject of
# NUMBER

HH
H
* MPOINTS for & %

& %


Fixed Relationships (1)
• A relationship can be marked as non-transferable:

' $ ' $
CUSTOMER responsible for

to

HH
H
INVOICE
& % & %
• In this way, an invoice cannot be disconnected from

a customer and connected to another customer.
• I.e. the foreign key attribute (customer number in
the invoice) is non-updatable.
Oracle Designer allows the “non-transferable” sign also on the other
side of the relationship. Semantics unclear (?).

Fixed Relationships (2)
• It might be a good idea to collect non-updatability

information for arbitrary attributes, but Oracle De-
signer does not allow that.
However, one can extend it in this way. It also has cross-referencing
tools which show CRUD (create, retrieve, update, delete) information
for all entities based on the business functions.
• Non-Updatability is a simple kind of dynamic cons-

traint, which refers not to single database states
as a normal static constraint, but to pairs of DB
states.
Another example is “Salaries cannot decrease.”

Specialization (1)
• Two or more entity types may have attributes or

relationships in common.
• Then it might be useful to create a generalized
entity type, which contains only the common cha-
racteristics, and abstracts from the differences.
• Or, some attributes or relationships may apply to
only a subset of the entities. Then creating a spe-
cialized entity type for this set should be considered.
• Inheritance (“is-a” relationships) and subclasses are
also a useful feature of object-oriented languages.

Specialization (2)
' $ ' $
INSTRUCTOR COURSE
teacher of
# NAME # CRN

H
H
H
taught by
∗ EMAIL ∗ TITLE
' $ & %
' $
FACULTY member of COMMITTEE
H
HH

∗ PROF TYPE

H
HH
# CNAME
& %
composed of
& %
' $
EXTERNAL
◦ AFFILIATION
∗ ADDRESS
& %
& %

Specialization (3)
• In the above example:

Instructors are faculty members (i.e. long-term
employees of the university) or external teachers
which are paid for the course only.
For all instructors, name and email address is
stored.
For faculty members, in addition the professor
type (Assistant, Associate, Full) is stored.
For external instructors, their affiliation and ad-
dress is stored.
Specialization (4)
• Example, continued:
Both types of instructors can teach courses.
Only faculty members can serve on committees.
• In general, specialization can be distinguished in:
Disjoint: It is not possible that an instructor is at
the same time a faculty member and an external
teacher. Oracle Designer only supports this case.
Overlapping: Objects of the superclass can be in
more than one subclass at the same time (then
they do not have a unique type: uncommon).

Specialization (5)
• Specialization can also be:

Total: Every instructor must be a faculty mem-
ber or an external teacher.
Partial: Elements of the superclass are not ne-
cessarily contained in one of the subclasses.
• Oracle Designer normally uses total specialization
(but one can always create an “Other” subclass).
• However, when one generates tables, one can also
select that the supertype is instantiable (meaning
partial specialization).

Specialization (6)
• Total and disjoint specialization means that the set

of entities of the superclass is partioned into the
instances of the subclasses.
It is very difficult to find information like “Oracle Designer supports
only non-overlapping and total specialization” in the documentation.
E.g. it is not mentioned in the online help, the manuals are anyway
either too short or only interface lists, and books like the Oracle
Designer Handbook assume that you know ER-modelling. Only the
book by Barker clearly states this. Looking at the translation into
tables also shows that a non-overlapping and total specialization is
assumed. I later learnt about the option for the Database Design
Transformer which gives you partial specialization, but anyway the
wrong place: If such an option is really to be used, it must be offered
in the ER-Diagrammer.

Specialization (7)
• Subclasses can themselves have subclasses.

In the ER-Diagrammer, one creates a subclass by creating an entity
type within the boundaries of another entity type (the superclass).
• In general, one can create a tree of entity types.

When specialization is total, real instances only exist at the leaves of
the tree. All other classes in the tree simply have the union of the
members of their subclasses.
• Multiple inheritance is not supported in Oracle De-

signer.
Multiple inheritance means that an entity type has more than one
superclass, and inherits attributes and relationships from all of them.

Specialization (8)
• It makes no sense to define primary key attributes

for a subclass: All attributes and the key constraint
are inherited from the superclass.
If the key uniquely identifies all members of the superclass, it especially
uniquely identifies the members of the subclass.
• Of course, it is possible to declare additional (se-

condary) keys for the subclasses.

Specialization and Null Values
• In principle, one could avoid optional attributes with

specialization: E.g. “Instructor” has a subclass “In-
structor with Home Phone Number”.
• When there are n attributes that can independently
be null, one would need 2n subclasses. Then this
method is clearly not useful.
• However, when there is a group of attributes which
can only be together null, or together not null, one
should consider using a subclass.
Constructs like specialization reduce the need for constraints.

Generalization
• The specialization process starts with the super-

class, discovers that some attributes apply only to
a subset of the entities, and constructs subclasses.
• Vice versa, in generalization the subclasses are iden-
tified first, and then the discovery of common attri-
butes leads to a superclass. The result is identical.
• Some authors use the term generalization or cate-
gorization if the subclasses have keys of their own,
and their union should be considered, e.g. for defi-
ning a relationship.

Arcs (1)
• By linking two or more relationships with an arc,

one can specify that they are mutually exclusive:
' $
@@ ' $
COURSE @
v
taught by
FACULTY MEMBER
H
HH

teacher of

& %
' $
v
taught by
EXTERNAL INST
H
HH

teacher of

& %
& %
• I.e. a course is either taught by a faculty member

or by an external instructor, but not by both.

Arcs (2)
• This is similar to defining two subclasses of courses:

Courses that are taught by a faculty member.
Courses taught by an external instructor.
• Alternatively, this corresponds to a generalization
of faculty members and external instructors.
One would use this model e.g. if external instructors and faculty mem-
bers already have different keys of their own, and there is no natural
key for their generalization. This is not a good example: The name
or SSN would do. The classical example in the literature are invoices
which can be sent to persons or companies.

Arcs (3)
• In general, arcs might help when for various reasons

specialization is too restricted.
• Using arcs in the ER-Diagrammer is a bit tricky.
Arcs are created by selecting at least two relationship ends and then
clicking on the “create arc” symbol in the toolbar (or the Utilities
menue). You must select the relationship ends, not the relationships
(click on the role names). Use Ctrl-click to select the second end.
In order to remove a relationship from an arc, select the arc by clicking
on the line between the two relationships (this is a bit difficult). Then
select the relationship end(s) you want to remove and select “Remove
from Arc” on the toolbar or the Utilities menu. If an arc remains only
for one relationship, I do not know how to select it. In this case, use
the Repository Object Navigator, drill down to the relationship, and
delete the “1” in the field “In Arc”.

Overview
1. Oracle Designer

' $

& %

Repository Reports (1)
• Design documentation can be printed from the in-

formation gathered with the ER-diagrammer.
• Diagrams can be printed with the ER-Diagrammer.
• Textual documentation can be generated with the
“Repository Reports Utility”.
• The goal is that Oracle Designer manages all design
information (in the repository).
Ideally, one writes no documents with Word or LATEX, but enters all
information into the repository, and then prints all documentation
with the Repository Reports Utility.

• There are predefined reports at different level of

detail. Many reports have parameters, e.g. whether
to include all entities or only a specified subset.
• Reports can be shown on screen, written to a file,
or directly printed. Possible output formats include
HTML and PDF.
• Oracle applies its own “Oracle Developer Reports”
Report Generator. One can use this tool to develop
one’s own reports.

• Of course, automatically generated documentation

has a very regular structure and is very dry to read,
but it is easy to look up the information one needs.
• Also, it depends on the designers, how much textual
comments they store about entities, relationships,
and attributes.
• Sometimes, it might be easier to find the infor-
mation in the repository with Oracle Designer, but
customers expect the usual printed documentation.


• Reports listed under Entity/Relationship Modelling:

Entity Definition
One page per entity (with attributes).
Entities and their Attributes

Overview table, one line per attribute.
Attribute Definition
Half a page per attribute, attributes are sorted by entity types, a
new page is started for a new entity type.
Attributes in Domain
Table with one row per attribute in a domain, ordered by domain.

• Entity/Relationship Modelling Reports, continued:

Entity Model Reference
One (or more) pages per Entity, includes use in business functions.
Function to Entity Matrix

CRUD information for all entity types accessed by a function.
Function to Attribute Matrix

Detailed CRUD information.
System Glossary
Descriptions of entity types.

• Reports listed under “Quality” do style checks or

find certain errors that can exist during the design
process but should be removed before the relational
schema is generated:
Entity Completeness Checks
This lists entities that have no attributes, no description, no keys
(UIDs), or that are not used by any function.
Quality Checking of Relationships

This lists “uncommon” relationships, namely many-to-many re-
lationships and one-to-one relationships. Some designers believe
that they should manually translate many-to-many relationships
into association entities. I do not share this view.

Rep. Object Navigator (1)
• The global schema (all defined entities and relati-

onships) can only be seen in the Repository Object
Navigator (RON).
Each diagram allows only to see and edit the entities and relationships
contained in that diagram.
• The global schema is used for the translation into

the relational model, and for printing reports.
It happens that entity types remain in the repository that were already
deleted on the diagrams. These can be found with RON.

• RON has a navigator window (on the left) and a

property palette (on the right).
The navigator window has the standard interface for browsing tree-
structured data (expand/collapse subtree). Subtrees correspond to
directories. There are a lot of options for selecting what to display
(one can define filter conditions).
• Objects can be created or deleted and properties

can be changed also in RON.
One must use “Save uncommitted data” in the file menu to save the
changes to the repository. If one has changed the data with another
tool (e.g. the ER-Diagrammer) while RON was open, one must use
“requery all” to reload the information from the repository.


• In Designer 2.1.2, the main categories were:

Reference Data Definition (contains domains)
Enterprise Modelling
Entity/Relationship Modelling (ER-diagrams)
Dataflow Modelling
Function Event Modelling
Type Modelling
C++ Object Generation
Server Model Definition (contains tables)

• Main categories in Designer 2.1.2 RON, continued:

File/Record Definition
Module Design
Database and Network Design
Sets
• It seems that in Designer 6i, many of the element
types of the meta model can appear, but only non-
empty containers are shown by default.
To see all containers, go to “Navigator→Show/Hide”, select “Always”
for “Objects”. Then quit RON and start it again.


• Designer 6i has a lot of sections/folders.
Assumptions, Business Functions, Business Terminology, Business
Units, Cluster Definitions, Communities, Critical Success Factors, Da-
ta Items, Dataflow Diagrams, Datastores, Diagrams, Documents, Do-
mains, Entities, Entity-Relationship-Diagrams, Externals, Files, Func-
tion Hierarchy Diagrams, Java Class Definitions, Key Performance In-
dicators, Languages, Locations, Materialized View Definitions, Matrix
Diagrams, Module Diagrams, Modules, Nodes, Non-Persistent Queu-
es, ODD Diagrams, Objectives, Oracle Collection Types, Oracle Da-
tabases, Oracle Object Types, Other Databases, PL/SQL Definiti-
ons, Persistent Queues, Preference Sets, Preferences, Problems, Pro-
cess Events, Process Models, Queue Table Definitions, Record Files,
Records, Reusable Lists of Values, Reusable Module Components,
Sequence Definitions, Server Model Diagrams, Source Files, Storage
Definitions, Synonyms, Table Definitions, Transformation Mapping
Sets, User Defined Sets, View Definitions, Usages, Inclusions.

• The section “Entities” lists all defined entity types.

• If one expands an entity, one gets:
Attributes
Relationships
Unique Identifiers
Synonyms
Sub Entities (subclasses)
Usages (e.g. links to business functions, table)
Inclusions (e.g. links to diagrams)

• It is possible to define “Filters”, i.e. simple queries

that determine what is actually shown.
E.g. one can select the “Entities” section and then the menu item
“Navigator→Filter”. Select the radio button “Data”, not “Headings”.
Then one can enter conditions for the name, plural, short name,
and supertype of the entity type, as well as conditions for the data
volumes (Initial, Average, Maximum, Annual Groth Rate), and the
datawarehourse type. The comparison for the text fields is done with
“LIKE”, so one can use “%” and “_” as usual.
• One can also specify the sort order e.g. within the
“Entities” section. and select which properties are
shown in the proterty palette.

Book Artic Designer PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Book Artic Designer PDF

Uploaded by

Copyright:

Available Formats

2.

Oracle Designer I: ER-Diagrams 2-1

Stefan Brass: Datenbanken II A Universität Halle, 2008

• draw ER-diagrams in the graphical syntax of Oracle

• explain the difference between the global DB sche-

Stefan Brass: Datenbanken II A Universität Halle, 2008

2. Entities and Relationships

3. Multiple Diagrams for one Schema

4. Attributes, Domains, Advanced Constructs

5. Repository Reports, Rep. Object Navigator

Stefan Brass: Datenbanken II A Universität Halle, 2008

Oracle Designer (1)

• Oracle Designer is a CASE tool.

• Some people also call it “documentation tool”.

• Oracle Designer is a large software package that

Stefan Brass: Datenbanken II A Universität Halle, 2008

Oracle Designer (2)

• E.g., it contains a graphical editor for ER-diagrams,

• Not all design information that Oracle Designer

• Oracle Designer can also be used to design data-

Stefan Brass: Datenbanken II A Universität Halle, 2008

Oracle Designer (3)

• Oracle Designer supports the following types of dia-

Stefan Brass: Datenbanken II A Universität Halle, 2008

Oracle Designer (4)

• Oracle Designer has also tools that generate

 first-cut application programs (Application De-

Stefan Brass: Datenbanken II A Universität Halle, 2008

Oracle Designer (5)

• Oracle Designer has also tools for capturing and

• Also the design of certain pre-existing application

Stefan Brass: Datenbanken II A Universität Halle, 2008

Oracle Designer (6)

• All Designer tools are integrated: E.g. entities crea-

Stefan Brass: Datenbanken II A Universität Halle, 2008

Oracle Designer (7)

• Oracle Designer supports groups of designers de-

• It also has support for version management.

• UML is not supported in Oracle Designer.

Stefan Brass: Datenbanken II A Universität Halle, 2008

Oracle Designer (8)

• Oracle Designer runs only on Windows.

Stefan Brass: Datenbanken II A Universität Halle, 2008

Oracle Designer (9)

• Oracle Designer is not further developed by Oracle,

• Oracle is committed to long-term support of Oracle

Stefan Brass: Datenbanken II A Universität Halle, 2008

Oracle Designer (10)

• Oracle sees JDeveloper (UML and Java/J2EE) as

• The problem is that new Oracle DBMS features

Stefan Brass: Datenbanken II A Universität Halle, 2008

Stefan Brass: Datenbanken II A Universität Halle, 2008

• Oracle Designer stores the design information not

Stefan Brass: Datenbanken II A Universität Halle, 2008

• A repository is similar to a data dictionary (system

• Whereas a data dictionary contains only the rela-

Stefan Brass: Datenbanken II A Universität Halle, 2008

Repository Tables etc.

Design Data entered defines- Tables etc.

Data entered by the

Stefan Brass: Datenbanken II A Universität Halle, 2008

• Design data about several projects (each in several

• In order to use Oracle Designer, one needs an ac-

first-cut application programs (Application De-

Folder: Intended for uploading standard files to

Association types (i.e. relationships between ele-

Text types (e.g. description, PL/SQL block).

Secondary Access Controlled Elements (SAC),

The notation used for these constructs.

The possibility to model also behaviour: