Process Model and Data Model

Dr. Md. Rakibul Hoque

University of Dhaka
 Learning Objectives
 Draw data flow diagrams following specific rules and guidelines
that lead to accurate and well-structured process models
 Use data flow diagrams as a tool to support the analysis of
information systems
 Event Modeling and DFD
 Explain the role of conceptual data modelling in the overall
analysis and design of an information system
 Describe the information gathering process for conceptual data
modelling
 Describe how to represent an entity-relationship model and be
able to define the terms: entity type, attribute, identifier,
multivalued attribute, and relationship
 Process models
 Process model
 A formal way of representing how a business system operates

 Illustrates the activities that are performed and how data moves

among them
 Process models are diagrams that map the movement of data between
processes. It is used to organize and document a system’s processes.
 Flow of data through processes
 Logic
 Policies
 Procedures
 Process modeling – graphically representing processes that capture,
manipulate, store, and distribute data between a system and
components within a system.
 Deliverables for Process Modeling

 A common technique for creating process models is known as Data Flow

Diagram (DFD)
 Context DFD

 Scope of the system

 DFD of the system

 Which processes move and transform data

 Thorough descriptions of each DFD component/D F Ds of current

logical system
 Allows analysts to understand the current system

 Abstract this system to show how new system should meet users

requirements
 Data Flow Diagrams (DFDs)
Data flow diagram (DFD) – a process model used to
depict the flow of data through a system and the work or
processing performed by the system. Synonyms are
bubble chart, transformation graph, and process model.
 The DFD has also become a popular tool for business
process redesign.
Despite their name, data flow diagrams are not primarily
concerned with data (entity/relationship diagrams)
• DFDs are concerned with where and what data flows
into, within, and out of the system, but more particularly
with how it is processed along the way
 Data Flow Diagrams (DFDs)

 Data flow diagram:

 Primary tool for representing system’s
component processes and flow of data between
them
 Offers logical graphic model of information flow
 High-level and lower-level diagrams can be used
to break processes down into successive layers
of detail
 Data Flow Diagrams (DFDs)
 Graphically characterize data processes and flows in a business system
 Depict:
 System inputs
 Processes
 Outputs
 Represent both physical and logical systems
 Useful for depicting purely logical information flows
 D F Ds that detail physical systems differ from system flowcharts
which depict details of physical computing equipment
 Only four symbols are used
 Definitions and Symbols of DFD
 Data flow – shows movement of data from one point to another. Described as data in
motion.
 Data store – data at rest, which may take the form of many different physical
representations
 Process – work or actions performed on data so that they are transformed, stored,
or distributed
 Source/sink – origin and/or destination of data; sometimes referred to as external
entities and may consist of:
 Another organization or unit that sends/receives data to system being analyzed

 A person supported by the system being analyzed

 Another IS that is exchanging information with the system being analyzed

Comparison of DeMarco and Yourdon with
Gane and Sarson DFD Symbol Sets
 Definitions and Symbols of DFD

• Processes are numbered and named; the name

should be an action (i.e. a verb or, more usually, a
verb phrase)
• Data stores are numbered and named, with an
appropriately descriptive noun or noun phrase
• Data flows are not numbered but are named to
indicate what data is flowing (using a noun or noun
phrase)
• Sources/Sinks are not numbered but are named with
a noun or noun phrase
Definitions and Symbols of DFD
Definitions and Symbols of DFD
 Rules Governing Data Flow
Diagramming
Rules Governing Data Flow Diagramming
Process:
A. No process can have only outputs. It would be making data from nothing (a
miracle). If an object has only outputs, then it must be a source.
B. No process can have only inputs (a black hole). If an object has only inputs, then it
must be a sink.
C. A process has a verb phrase label.
Data Store:
D. Data cannot move directly from one data store to another data store. Data must be
moved by a process.
E. Data cannot move directly from an outside source to a data store. Data must be
moved by a process that receives data from the source and places the data into the
data store.
F. Data cannot move directly to an outside sink from a data store. Data must be
moved by a process.
G. A data store has a noun phrase label.
 Rules Governing Data Flow
Diagramming

Rules Governing Data Flow Diagramming

Source/Sink:
H. Data cannot move directly from a source to a sink. It must be moved by a
process if the data are of any concern to our system. Otherwise, the data flow
is not shown on the D F D.
I. A source/sink has a noun phrase label.
 Rules Governing Data Flow
Diagramming
Rules Governing Data Flow Diagramming
Data Flow:
J. A data flow has only one direction of flow between symbols. It may flow in both directions
between a process and a data store to show a read before an update. The latter is usually
indicated, however, by two separate arrows because these happen at different times.
K. A fork in a data flow means that exactly the same data goes from a common location to two
or more different processes, data stores, or sources/sinks (this usually indicates different
copies of the same data going to different locations).
L. A join in a data flow means that exactly the same data come from any of two or more
different processes, data stores, or sources/sinks to a common location.
M. A data flow cannot go directly back to the same process it leaves. There must be at least
one other process that handles the data flow, produces some other data flow, and returns the
original data flow to the beginning process.
N. A data flow to a data store means update (delete or change).
O. A data flow from a data store means retrieve or use.
P. A data flow has a noun phrase label. More than one data flow noun phrase can appear on a
single arrow as long as all of the flows on the same arrow move together as one package.
Incorrect and Correct Ways to
Draw DFDs
Differences Between Sources/Sinks and
Processes (An Improperly Drawn DFD
Showing a Process as a Source/Sink)
 Differences Between Sources/Sinks and
Processes (A DFD Showing Proper Use of a
Process)
 Developing DFDs
 Make a list of business activities and use it to determine various
 External entities

 Data flows

 Processes

 Data stores

 DFDs start with the requirements definition

 Generally, the DFDs integrate the use cases
 Names of use cases become processes
 Inputs and outputs become data flows
 “Small” data inputs and outputs are combined into a single flow
 Developing DFDs

 Create a context diagram that shows external entities and

data flows to and from the system. Do not show any
detailed processes or data stores.
 Create a child diagram for each of the processes in
Diagram 0.
 Draw Diagram 0, the next level. Show processes, but keep
them general. Show data stores at this level.
 Decompose level 0 processes into level 1 diagrams as
needed; decompose level 1 processes into level 2
diagrams as needed; etc.
 Validate DFDs with user to ensure completeness and
correctness
 Developing DFDs

 Check for errors and make sure the labels you assign to
each process and data flow are meaningful.
 Develop a physical data flow diagram from the logical data
flow diagram. Distinguish between manual and automated
processes, describe actual files and reports by name, and
add controls to indicate when processes are complete or
errors occur.
 Partition the physical data flow diagram by separating or
grouping parts of the diagram in order to facilitate
programming and implementation.
 Developing DFDs
(Context Diagram)

 Context diagram – overview of an organizational

system that shows the system boundaries, external
entities that interact with the system, and the major
information flows between the entities and the system.
 It shows the context into which the business process fits
 Context diagram is the first DFD in every business
process
 The highest level in a data flow diagram
 Developing DFDs
(Context Diagram)
 Shows the overall business process as just one process (process 0)
 It shows what sources & sinks interact with the system, and what data
they exchange with it
 Shows all the external entities that receive information from or contribute
information to the system
 The system is represented as a whole as a single process – a “black box”
 Contains only one process, representing the entire system
 Developing DFDs
(Context Diagram)
 All external entities, as well as major data flows are shown
 External entities should not be connected to one another
 A data store must be connected to at least one process
 Data stores never appear on context diagrams; they are internal to the system
 The process is given the number 0
 The “0” process/system must have at least one input and at least one output
 Sources/sinks must have at least one data flow connecting them to the “0” process/system
 Sources/sinks are never connected to each other by data flows, only to the “0”
process/system
 Developing D F Ds
(Context Diagram)

• Source/sinks should always be named in the

singular since they represent types of thing
that can interact with the system (e.g.
“customer” rather than “customers”)
• Similarly, data store names should also be
singular (e.g. “member details” or “member
file” rather than “members details” or
“members file”)
Context Diagram of Food-Ordering
System
 Developing DFDs
(Level-0 diagram)
 The context diagram tells us nothing about the
internals of the system, just about its interaction
with its environment.
 Level-0 diagram – DFD that represents a system’s
major processes, data flows, and data stores at a
high level of detail
 DF D Rules

 The inputs to a process are different from the

outputs of that process

 Objects on a D FD have unique names
 Level 0 Diagram

 The explosion of the context diagram

 Shows all the major processes that comprise the
overall system – the internal components of process 0
 Shows how the major processes are interrelated by
data flows
 Shows external entities and the major processes with
which they interact
 Adds data stores
Level-0 DFD of Food-Ordering
System
 Data Flow Diagram

 Two important concepts related to data flow

diagrams:
 Decomposition

 Balancing
 Decomposition of DFDs
(Level-1 Diagram)

 Functional decomposition – iterative process of breaking

the description of a system down into finer and finer detail,
which creates a set of charts in which one process on a
given chart is explained in greater detail on another chart
 Example: We could break down Process 1.0 into the

following tasks:
1. Receive customer order

2. Transform order into meaningful form for kitchen

3. Transform order into a printed receipt for the

customer
4. Transform order into goods sold data

5. Transform order into inventory data

 Decomposition of DFDs
(Level-1 Diagram)

 Generally, level 1 diagram is created for every major process on

the level 0 diagram
 Level-1 diagram – result of decomposition of a Level-0 diagram

 Process 1 on the level 1 DFD may be expanded into

(sub)processes 1.1, 1.2 … and data stores D1.1, D1.2 … etc
 Rule of thumb—No D F D should have more than about seven
processes
 Result makes the D F D crowded and difficult to understand
Level-1 Diagram Showing the Decomposition
of Process 1.0 from the level-0 Diagram for
Food-Ordering System
Level-1 Diagram Showing the Decomposition
of Process 4.0 from the level-0 Diagram for
Food-Ordering System
 Level 2 Diagrams

 Shows all processes that comprise a single process

on the level 1 diagram
 Shows how information moves from and to each of
these processes
 Level 2 diagrams may not be needed for all level 1
processes
 Correctly numbering each process helps the user
understand where the process fits into the overall
system
Level-2 Diagram Showing the Decomposition
of Process 4.3 from the Level-1 Diagram for
Process 4.0 for Food-Ordering System
Developing DFDs
 DATA FLOW DIAGRAM FOR MAIL-IN
UNIVERSITY REGISTRATION SYSTEM

The system has three processes: Verify availability (1.0), Enroll student (2.0), and
Confirm registration (3.0). The name and content of each of the data flows appear
adjacent to each arrow. There is one external entity in this system: the student.
There are two data stores: the student master file and the course file.
 An Example

• Suppose we are developing a process

model for a taxi allocation system
• First things first: what is the system
purpose and boundary?
– The system purpose is to accept requests
from customers and allocate taxis to service
those requests, issuing the relevant pickup
details to the appropriate taxi drivers
 An Example

The boundary:
– From the description of the system
purpose it seems reasonably clear that
customers and taxi drivers are outside
the system
– Other actors (e.g. staff who accept
customer requests) are inside the system
Taxi Allocation System:
Context Diagram
Taxi Allocation System:
Level 0 DFD
 Taxi Allocation System –
Problem?

• Can you see any problem(s) with the previous

model?
• One might be:
– How do we know when a pickup has been
completed? Currently there is no way in the
system to record this fact
• An appropriately modified model might look like
this …
Taxi Allocation System:
Level 0 DFD
Taxi Allocation System:
Level 1 DFD
 An Unbalanced Set of DFDs

(a) Context Diagram (b) Level-0 Diagram

 Example of Data Flow Splitting
(a) Composite Data Flow (b) Disaggregated Data Flow
 Using DFDs as Analysis Tools

 Gap analysis – process of discovering discrepancies

between two or more sets of DFDs or discrepancies
within a single DFD
 Inefficiencies in a system can be identified through DFDs
 D F Ds are useful for modeling processes in business
process reengineering (BPR)
IBM Credit Corporation’s Primary
Work Process Before BPR
 IBM Credit Corporation’s
Primary Work Process After BPR
Electronic Commerce Application: Process
Modeling Using Data Flow Diagrams

 Process modeling for Pine Valley Furniture’s

WebStore:
 Completed J AD session

 Began translating the WebStore structure into

data flow diagrams

 Identified six high-level processes
 System Structure of the WebStore and
Corresponding Level-0 Processes
WebStore System Processes
• Main Page Information Display (minor/ no processes)
– Product Line (Catalog) 1.0 Browse Catalog
2.0 Select Item for Purchase
 Desks 3.0 Display Shopping Cart
 Chairs 4.0 Check Out Process Order
 Tables 5.0 Add/Modify Account Profile
6.0 Order Status Request
 File Cabinets Information Display (minor/no processes)
– Shopping Cart
– Checkout
– Account Profile
– Order Status/History
– Customer Comments
• Company Information Blank

• Feedback Blank

• Contact Information Blank

Level-0 for the WebStore
Typical Errors That Can Occur in a
Data Flow Diagram
 Features Common of Logical and
Physical Data Flow Diagrams

Design Feature Logical Physical

What the model How the business How the system will be implemented (or
depicts. operates. how the current system operates).
What the processes Business activities. Programs, program modules, and manual
represent. procedures.
What the data stores Collections of data Physical files and databases, manual files.
represent. regardless of how the data
are stored.
Type of data stores. Show data stores Master files, transition files. Any processes
representing permanent that operate at two different times must be
data connected by a data store.
collections.
System controls. Show business controls. Show controls for validating input data, for
obtaining a record (record found status), for
ensuring successful completion of a
process, and for system security (example:
journal records).
Logical Data Flow Diagram Example
Physical Data Flow Diagram Example
 Event Modeling and Data Flow
Diagrams

 An input flow from an external entity is sometimes called

a trigger because it starts the activities of a process
 Events cause the system to do something and act as a
trigger to the system
 An approach to creating physical data flow diagrams is to
create a data flow diagram fragment for each unique
system event
 Event Response Tables

 An event table is used to create a data flow diagram by

analyzing each event and the data used and produced by the
event
 Every row in an event table represents a data flow diagram
fragment and is used to create a single process on a data
flow diagram
 An Event Response Table for an
Internet Storefront
Event Source Trigger Activity Response Destination
Customer logs Customer Customer Find customer record and verify Welcome Customer
on number and password. web page
password Send Welcome web page
Customer Customer Item Find item price and quantity Item Customer
browses items information available. Response
at Web Send Item Response web page. web page
storefront
Customer Customer Item purchase Store data on Order Detail Record. Items Customer
places item into (item number Calculate shipping cost using Purchased
shopping and quantity) shipping tables. Update customer web page
basket at Web total. Update item quantity on hand.
storefront
Customer Customer Clicks “Check Display Customer Verification Blank
checks out Out” button on Order web page. web page
web page
Obtain customer Customer Credit card Verify credit card amount with Credit card Credit card
Payment information credit card company. Send. data company
Customer Customer
feedback
Send customer Blank Temporal, Send customer an email confirming Blank Customer
email hourly shipment.
 Conceptual Data Modeling

 Conceptual data model – detailed model that

captures the overall structure of organizational data
and is independent of any database management
system or other implementation considerations
 Usually done in parallel with other requirements

analysis
 Most organizations today do conceptual data

modeling using E-R modelling.

 All team member work done and stored in a

repository
 The Conceptual Data Modeling
Process

 Develop a data model for the current system

 Develop (or purchase) a new conceptual data model
that includes all requirements for the new system
 During design, final data model matched with systems
inputs/outputs and translated into a physical design
 Project repository links all design and data modeling
steps taken during the SDLC
 Gathering Information for
Conceptual Data Modeling
 A data model is a collection of conceptual tools for describing
data, data relationship, data semantics and consistency
constraints.
 Two perspectives on data modeling:
 Top-down approach – derives the data model from an

intimate understanding of the business

 Bottom up approach – process of gaining an
understanding of data. It derives the data model by
reviewing specific business documents (computer displays,
reports, form)
 Requirements Determination
Questions for Data Modeling
Requirements Determination Questions for Data Modeling

1. What are the subjects/objects of the business? What types of people, places, things,
materials, events, etc. are used or interact in this business, about which data must be
maintained? How many instances of each object might exist?—data entities and their
descriptions
2. What unique characteristic (or characteristics) distinguishes each object from other
objects of the same type? Might this distinguishing feature change over time or is it
permanent? Might this characteristic of an object be missing even though we know the object
exists?—primary key
3. What characteristics describe each object? On what basis are objects referenced, selected,
qualified, sorted, and categorized? What must we know about each object in order to run the
business?—attributes and secondary keys
4. How do you use these data? That is, are you the source of the data for the organization, do
you refer to the data, do you modify it, and do you destroy it? Who is not permitted to use
these data? Who is responsible for establishing legitimate values for these data?—security
controls and understanding who really knows the meaning of data
5. Over what period of time are you interested in these data? Do you need historical trends,
current “snapshot” values, and/or estimates or projections? If a characteristic of an object
changes over time, must you know the obsolete values?—cardinality and time dimensions of
data
 Requirements Determination
Questions for Data Modeling

Requirements Determination Questions for Data Modeling

6. Are all instances of each object the same? That is, are there special kinds of each object
that are described or handled differently by the organization? Are some objects summaries or
combinations of more detailed objects?—supertypes, subtypes, and aggregations
7. What events occur that imply associations among various objects? What natural
activities or transactions of the business involve handling data about several objects of the
same or a different type?—relationships and their cardinality and degree
8. Is each activity or event always handled the same way or are there special
circumstances? Can an event occur with only some of the associated objects, or must all
objects be involved? Can the associations between objects change over time (for example,
employees change departments)? Are values for data characteristics limited in any way?—
integrity rules, minimum and maximum cardinality, time dimensions of data
 Introduction to E-R Modeling

 Entity-relationship data modeling (E-R model) –

detailed, logical representation of the entities,
associations, and data elements for an organization
or business area.
 Set of entities about data objects are stored in repository
project dictionary, or data modeling software
 Repository is the mechanism that links the data, processes,

and logic models of an information system

 Data elements included in the data flow diagram (D F D)

must appear in the data model and vice versa

 Each data store in a process model must relate to business

objects represented in the data model

 Introduction to E-R Modeling

 The purpose of E-R diagramming is to capture the richest

possible understanding of the meaning of the data
necessary for an information system or organization.

 The E-R model is expressed in terms of:

 Entities in the business environment
 Relationships among those entities
 The attributes (properties) of both the entities and their
relationships
 Entity
 Entity – person, place, object about which the organization
wishes to maintain data. An entity may be concrete, such as a
person or a book, or it may be abstract, such as loan, or a
holiday, or a concept.
 An entity has its own identity that distinguishes it from each other
entity.
 Person: Employee, Student, Patient

 Place: Store, Warehouse

 Object: Machine, Building

 Concept: Account, Course

 Attributes
 Attribute – named property or a characteristic of an entity that
is of interest to the organization. An attribute name is a noun
and should be unique. To make an attribute name unique and
for clarity, each attribute name should follow a standard
format. Similar attributes of different entity types should use
similar but distinguishing names.
 Student: Student_ID, Student_Name, Address, Cell

 An attribute definition:
 States what the attribute is and possibly why it is important

 Should make it clear what is included and what is not

included
 Contains any aliases or alternative names

 States the source of values for the attribute

 Types of Attributes

 Types of attributes:
 Required versus Optional Attributes
 Simple versus Composite Attribute
 Single-Valued versus Multivalued
Attribute
 Derived Attributes
 Identifier Attributes
 Required vs. Optional Attributes

Required – must have a value for every Optional – may not have a value for
entity (or relationship) instance with every entity (or relationship) instance
which it is associated with which it is associated
 Simple vs. Composite
Attributes
 Simple
 When an attribute is not possible to divided into
subparts. Each entity has a single atomic value for the
attribute. For example, city, country.
 Composite
 Composite attributes can be divided into subparts i.e.
other attributes. The attribute may be composed of
several components. For example:
 Address(Apt#, House#, Street, City, State, ZipCode, Country),
or
 Name(FirstName, MiddleName, LastName).
 Example of a composite
attribute
Composition
may form a
hierarchy
where some
components
are
themselves
composite.
 Single-Valued versus Multivalued
Attribute

 Single-valued – when there exist a single value

for a particular entity. Example: Student_ID
 Multi-valued
 An entity may have multiple values for that
attribute. Example: Phone_Number
 Derived Attributes

 Derived – The value of this type of attribute can be

derived from the values of other related attributes
or entities.
 age attribute in customer entity set where there is
a attribute named date-of-birth. date-of-birth may
be referred to as a base attribute, or a stored
attribute. The value of a derived attribute is not
stored, but is computed when required.
 Identifiers Attribute (Keys)

 Identifier (Key)–an attribute (or combination

of attributes) that uniquely identifies
individual instances of an entity type
 Simple versus Composite Identifier
 Candidate Identifier–an attribute that could
be a key…satisfies the requirements for
being an identifier
 Choose Identifiers that
 Will not change in value
 Will not be null
77
 Value Sets (Domains) of
Attributes
 Each simple attribute is associated with a
value set
 E.g., Lastname has a value which is a
character string of upto 15 characters
 Date has a value consisting of MM-DD-YYYY
where each letter is an integer
 A value set specifies the set of values
associated with an attribute
 Value Sets (Domains) of
Attributes
 Null Value: An attribute can take a null value
when an entity does not have a value for it.
1. Not applicable – middle name
2. Unknown – a. missing – the value does exist
but we do not have that information - name
– b. not known – do not know
whether or not the value actually exist
Common Example: apartment no.
Two Entities, EMPLOYEE e1 and
COMPANY c1 and their attributes
 Relationships
 Relationship – A relationship is an association among several entities. A depositor
relationship associates a customer with each account that he or she has.
 A relationship name is a verb phrase in the present tense
 Relationship guidelines:
 Explain importance and why it is important

 Give examples to clarify action

 Explain any optional participation

 Explain reason for any explicit maximum cardinality other than many

 Explain any reasons for participation restrictions

 Explain the extend of history that is kept in the relationship

 Explain whether an entity instance involved in a relationship instance can transfer participation

to another relationship instance

 Degree of a Relationship

 Degree – number of entity types that participate in a

relationship
 Unary relationship – relationship between one entity type;
also called a recursive relationship
 Binary relationship – relationship between instances of
two entity types. This is the most common type of
relationship encountered in data modeling. (Also called a
recursive relationship.)
 Ternary relationship – simultaneous relationship among
instances of three entity types
 Relationship types of degree n are called n-ary
Unary relationship
Binary relationship
 NOTATION for E-R diagrams
 The E-R diagram can express the overall logical
structure of a database graphically. Such a
diagram consists of the following major
components:
 Rectangles, which represent entity sets
 Ellipses/ ovals, which represent attributes
 Diamonds, which represent relationship sets
 Lines, which link attributes to entity sets and entity sets
to relationship sets
 Each key attribute is underlined
 NOTATION for E-R diagrams

 Double ellipses/ ovals, which represent multivalued

attributes
 Dashed ellipses/ ovals, which denote derived attributes
 Double lines, which indicate total participation of an entity in
a relationship set
 Double rectangles, which represent weak entity set
 Double diamond, identifying relationship set for weak entity
set
NOTATION for E-R diagrams
 Initial Conceptual Design of Entity
Types for the COMPANY Database
Schema

 Based on the requirements, we can identify four initial

entity types in the COMPANY database:
 DEPARTMENT
 PROJECT
 EMPLOYEE
 DEPENDENT
 Their initial conceptual design is shown on the following
slide
 The initial attributes shown are derived from the
requirements description
 Initial Design of Entity Types:
EMPLOYEE, DEPARTMENT, PROJECT,
DEPENDENT
 Refining the COMPANY database
schema by introducing relationships

 By examining the requirements, six relationship types are

identified
 All are binary relationships( degree 2)
 Listed below with their participating entity types:
 WORKS_FOR (between EMPLOYEE, DEPARTMENT)
 MANAGES (also between EMPLOYEE, DEPARTMENT)
 CONTROLS (between DEPARTMENT, PROJECT)
 WORKS_ON (between EMPLOYEE, PROJECT)
 SUPERVISION (between EMPLOYEE (as subordinate),
EMPLOYEE (as supervisor))
 DEPENDENTS_OF (between EMPLOYEE, DEPENDENT)
 E-R DIAGRAM – Relationship Types
are:
WORKS_FOR, MANAGES, WORKS_ON, CONTROLS, SUPERVISION, DEPENDENTS_OF
 Discussion on Relationship
Types
 In the refined design, some attributes from the initial entity types
are refined into relationships:
 Manager of DEPARTMENT -> MANAGES
 Works_on of EMPLOYEE -> WORKS_ON
 Department of EMPLOYEE -> WORKS_FOR
 etc
 In general, more than one relationship type can exist between
the same participating entity types
 MANAGES and WORKS_FOR are distinct relationship types
between EMPLOYEE and DEPARTMENT
 Different meanings and different relationship instances.
 Some of the Automated Database Design Tools
(Note: Not all may be on the market now)

COMPANY TOOL FUNCTIONALITY

Embarcadero ER Studio Database Modeling in ER and IDEF1X
Technologies
DB Artisan Database administration, space and security management

Oracle Developer 2000/Designer 2000 Database modeling, application development

Popkin Software System Architect 2001 Data modeling, object modeling, process modeling,
structured analysis/design
Platinum Enterprise Modeling Suite: Erwin, Data, process, and business component modeling
(Computer BPWin, Paradigm Plus
Associates)
Persistence Inc. Pwertier Mapping from O-O to relational model

Rational (IBM) Rational Rose UML Modeling & application generation in C++/JAVA
Resolution Ltd. Xcase Conceptual modeling up to code maintenance
Sybase Enterprise Application Suite Data modeling, business logic modeling
Visio Visio Enterprise Data modeling, design/reengineering Visual Basic/C++
The COMPANY Conceptual Schema in
UML Class Diagram Notation
Human Resource Schema
Thank
You