Erwin

(A data modeling and design tool)

• Oracle COE, LGS Ltd
 Introduction
• Is a data modeling tool to design data models for
transactional databases using ER data model

• It also provides data modeling based on dimensional data

model

• Using Erwin we can prepare

– Logical Data Model (for user / client)
– Physical Data Model (for development)
– Database Script (for development)
– Physical Database (for development)
 Logical Data Model
• Is prepared for user / client to let them know about database design approach
• Client / User recommends changes for things defined improperly or missed
• Designer has to incorporate the changes and again send it to user. This process
continues until user approves the logical model. Generally within 2-3 attempts
logical model must get approved. Otherwise re-analysis has to be done
• This model has to be without using technical terms from database or operating
system etc. This model includes only following four things
– Entities
– Relations
– Attributes
– Business Rules (Constraints / Validations)
• Once logical data model is approached that includes all technical terms related
database system
 Physical Data Model
• This is a blue print for database but it is not database. Using this model we prepare
DB for specific database system. For Ex Erwin supports about 40+ database
systems
– Semi RDBMS – FoxPro, dBase
– RDBMS – Oracle, SQL Server
– File systems
• Logical Data Model and Physical Data Model will never be same since presentation
(Logical) and Implementation (Physical) are never same
• Physical Data Model has following three types of functionalities
– Database Designing (By Designer)
– Backend Programming (Procs, Funcs, Pkgs & Triggers) (By Designer)
– Objects Properties Settings (By DBA)
• Partitions
• T/S
• Object Storage Parameters
• Single Schema or Multiple Schema
• Etc.
 ERwin Tasks
Erwin provides three basic tasks

• 1. Forward Engineering: This term is used when we design a new database

from scratch
– Logical Model  Physical Model  Database

• 2. Reverse Engineering: This term is used when we restructure and

existing database to support new functionalities required by the user
– Database  Physical Model  Logical Model

• 3. Complete Compare: This is to reflect the changes either side (database

to Model and vice versa)
 Model Components
• A model is a container object and it is prepared using one or more
‘SUBJECT AREA’

• One subject area named ‘MAIN’ is created by default and it is MUST

• This subject area keeps all objects from all other subject areas

• So this subject area can be referred as ‘INTEGRATED MODEL’ or

‘COMPLETE MODEL’

• Other subject areas prepared for specific domain or module of the system
 Model Components – Contd..

A subject area is collection two other objects:

• 1.Display: It is nothing but a page or a canvas on which other physical objects are
pasted for display purpose

• Every subject area will have at least one display but there is no limit on maximum
display objects

• A display can show the objects at different levels (Max 5 levels are available). But
each display will include all the objects of subjects area
– Ex: If subject area has 50 entities (referred as object) and 5 display. All display will be showing
all 50 objects, only level of display can be changed

• 2.Other Objects are like entities, relations, attributes, business rules at logical
model level and tables, views, synonyms, sequences etc at physical model level
Model Components – Contd..
Model

Is collection of

Subject Area(s)

Is/Are collection of

Display Object(s) Other Object(s)

Are fastened on
 Model Components – Contd..
DataBase

Model A
Main Subject Area
Subject Area A
Display A
T1
Display 1
T1 T2 T3
T1
DB-A
T1
T2
Display B
T2
T2
T1 T2 T3
T3

Subject Area B

Display 2
T1 DB-B
Logical Link
T1 T3
T3
 Type of relations supported by ERwin
• Identifying Relation
– Used for 1-1 and 1-M relation based entities
– PK of parent entity is used as FK into child entity and FK also becomes part of PK within child entity
– So, In this case child entity will have composite PK

VISA
person PASSPORT
PK VISA_NO
PK PERSON_ID PK PASSPORT_NO
PK,FK1 PERSON_ID
PK,FK1 PERSON_ID
PK,FK1 PASSPORT_NO
PERSON_NAME
PERSON_DOB ISSUE_DT
ISSUE_DT
EXPIRY_DT
EXPERY_DT

• Non-Identifying Relation
– Used for 1-1 and 1-M relation based entities
– PK of parent entity is used as FK into child entity but it remains only as FK and doesn't become part of PK
within child entity
– So in this case child entity need not have composite PK
PERSON PASSPORT
VISA
PK PERSON_ID PK PASSPORT_NO
PK VISA_NO

PERSON_NAME ISSUE_DT
ISSUE_DT
PERSON_DOB EXPIRY_DT
EXPERY_DT
FK1 PERSON_ID
FK1 PASSPORT_NO

• Many-to-Many relation
• ERwin creates an additional entity referred as ‘ASSOCIATION ENTITY’ to relate both the base
entities but this entity appears in physical model and not in logical models
 Relation Cardinality
• It defines the relation at record level between
two entities and there are four cardinalities
possible
– For each parent record…zero or one or more child
records
– For each parent record…zero or one records
– For each parent record…one or more child records
– For each parent record…exact number of child
records (1 week-7 days)
 Relational Integrity
• It defines dependency of parent and child entities / tables for
data manipulation

Parent Entity Child Entity

INSERT None Restricted

DELETE Restricted / Cascade None

UPDATE Restricted / Cascade Restricted

(If PK is updated) (If FK is updated)
• My Notes
For M-M (many-to-many relation)
– Model  Mode Properties Generate Auto transfer
• Relation Type => Identifying, Non Identifying
• Properties for Entities, Attributes & Relation
– Verb Phrase (is identified By / Identifies)
• Cardinality =>(1-Zero, One or More; 2-One or More)
• Business Rules
• Forward Engineering (Tools FE  Oracle Schema Creation)
• Reverse Engineering (Sync Activities)
• Volumetric for a subject => for setting properties ( For DBA)
• Data Browser => For Technical People
• Report Builder => For client
• Procedures => Not much sophisticated functionality
• Pre & Post scripts => For create user & table space etc. Before model these scripts
are to be generated. Post scripts at end of code
• RI (Referential Integrity) Triggers => maintain the integrity between two related
tables
Questions