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
