Model Business Data

Seminars and Services We Offer to Perform this Process
Other Steps (Activities) We Can Help You With

Model Business Data

We can:

		teach you how to do this activity
	with our in-house or public seminars and e-learning

		show you how to do this activity
	with E-Coaching

lead your experts
through this
activity in a Facilitated JAD Session

Business data is any information that an organization needs to function. Data modeling identifies which data is essential and defines the context within which your organization uses and maintains the data independent of your system architecture. A data model also identifies how technological decisions restrict your ability to do what you want to do.

Business data modeling
		creates a visual image of the information components that your business needs

		is a starting point for cross-application database design

		enables the business users to assess the technological impact of business decisions

		increases the portability of the delivered solution

		establishes a baseline for communication across functional boundaries

		provides a basis for business-rules definition

		is an integral component of a repeatable development process

When should you model business data?

You should model business data independent of any information system projects. At the latest, do it before you make any information technology decisions.

Who should model business data?

Data analysts, system analysts, system designers, database analysts and business managers have to work together to create a data model.

Core+ Training for Business Systems Analysts

2-05 : How to Model and Analyze Business System Data

Overview Presentations for Management

5-30 : Business Analysis and User Acceptance Testing

Supplemental Training for Business Systems Analysts

3-30 : How to Prepare and Facilitate a Successful JAD Session

Other Products and Services

Outsourced Business Analysis

E-Coaching

JAD Facilitation

Tailored Training

Skills Assessment

The Small Project Guide



	Under Time Pressure?

	Learn how to run an efficient, effective JAD session that does this activity faster. How to Prepare and Facilitate a Successful JAD Session

	Our e-Coaching offer is a cost-effective alternative for small groups to learn these and other business systems analysis techniques at their own workplace or for follow-up after a training seminar


	your business analysis skills

	Analyze Business Problems
	Gather Prioritized Requirements
	Model and Analyze Business Processes
	Design Business Architecture
	Develop Quick Fixes
	Engineer Business Processes
	Evaluate Potential Solutions
	Engineer Test Data
	Execute Tests
	Plan Testing Activities

Requirements Solutions Group offers training as well as web-based and on-site consulting services to support a wide range of activities within the system development life cycle all targeted exclusively to the Business Analyst, Requirements Engineer and the Subject Matter Expert.

You can also visit our bookstore for the newest publications in the business systems analysis field

Entity-Relationship Diagrams

Entity-Relationship diagrams describe the data and the business relationships among the data independent of any implementation approach, technology, hardware or software.

To create a data model,
ask these four questions:

What do you need to store data about? The answers are your entities.
Examples: customer, product, account, etc.

How are these entities related? This will show the relationships among the entities.
Examples: customer buys product, transaction debits account, etc.

What is the nature of the relationship? This will identify the cardinality of the relationship.
Examples: one customer may buy many products, many transactions debit many accounts, etc.

What data do you need to store about the entities and their relationships? This will identify the attributes.
Examples: customer: name, address, phone, etc.

Entities:

Relationships:

Cardinality:

Attributes:

Data Model Rules

Entity Rules:	An entity has to occur many times to be of interest (if there is only one occurrence, it is a constant). Each occurrence of an entity has to have a unique primary key (you have to be able to identify a single instance of the entity in a group of the same entities).
Relationship Rules:	The relationships are created by business transactions. The relationships link the entities involved in the transaction. A relationship should only be represented if you need to track information about the transaction
Cardinality Rules:	Relationships between entities can be: one-to-one one-to-many many-to-many (via intersection entities) In addition, they are either mandatory or optional.
Attribute Rules:	An attribute identifies an entity, resolves a relationship with another entity or describes something about the entity. An attribute belongs to one and only one entity. An attribute can only have a single value for each occurrence.

Data Normalization

Preparation

To start normalization, you need a set of data elements with a name and a primary key.

Apply these three steps to identify the simplest set of attributes (relations) for storing the data elements.

In the end, each relation has to have a name, a unique primary key (P-KEY) and attributes.

Invoice #:
Customer Name:
Service Address:
Account#

Date Due	Amount Due

Date	Svc ID	Description	Amount

Service From:

Service To:

Translate User View into a "Relation"

Name: "Invoice"

Attributes:

P-KEY: Invoice#
Customer Name
Service Address
Account#
Date Due
Amount Due

Date
Svc ID
Description
Amount
Service From
Service To

1st Normal Form

Remove all repeating groups (lines) and create a separate set of attributes (relation). Include the primary key of the original set in this group.
Create a unique key for the new relation by combining the original set's primary key with one or more attributes that make an occurrence of the new group unique. Name the new group.

Each Invoice Can Have Multiple Services

Name: "Invoice"

Attributes:

P-KEY: Invoice#
Customer Name
Service Address
Account#
Date Due
Amount Due

~~Date~~
~~Svc ID~~
~~Description~~
~~Amount~~
Service From
Service To

Therefore We Create a New Relation

Name: "Transaction"
Attributes:	P-KEY: Invoice# P-KEY: Date P-KEY: Svc ID Service Description Amount

2nd Normal Form

Examine the relations that have more than one attribute in their key.
Remove all non-key attributes that describe only part of the key.
Create a separate relation with this part of the key as its primary key and name it.
Do not remove any key attributes from a relation.

The Transaction Relation Has Multiple Keys
The two attributes "Service Description" and "Amount" describe only the Key "Svc ID"

Name: "Transaction"
Attributes:	P-KEY: Invoice# P-KEY: Date P-KEY: Svc ID ~~Service Description~~ ~~Amount~~

Therefore We Create a New Relation

Name: "Service"
Attributes:	P-KEY: Svc ID Service Description Amount

3rd Normal Form

Examine all relations.
Remove all attributes that do not describe the primary key, create a new relation for them with a primary key and a name.
Replace the attributes in the original relation with the primary key of the new relation as a foreign key (F-KEY).
Do not remove any key attributes from a relation.

No Change to the "Service" Relation

Name: "Service"
Attributes:	P-KEY: Svc ID Service Description Amount

This is the Final "Transaction" Relation

Name: "Transaction"
Attributes:	P-KEY: Invoice# P-KEY: Date P-KEY: Svc ID

Customer Name, Account #, and Service Address Do Not Describe the Key "Invoice"

Name: "Invoice"

Attributes:

P-KEY: Invoice#
~~Customer Name~~
~~Service Address~~
F-KEY: Account#

Date Due
Amount Due
Service From
Service To

Therefore We Create a New Relation "Customer"

Name: "Customer"
Attributes:	P-KEY: Account# Customer Name Service Address