the entire business

Logical
Operational systems
logical model for the operational system
Warehouse
logical subject specific model for the data warehouse,
models for the data marts star, snowflake,
constellation model).
Physical models
Physical implementations of the models at the database level.
r conceptual Model
Operati onal
."" .. , ........':"'-"',:,,,',,,
MOd.JI
Warehouse
The Enterprise Model
Provides neutral and logical business wide view of key
all to competitive
business
The fundamental aim of the model is to communicate, among
groups, the need for, and avai labil ity of, information
within the business.
Models
The conceptua/ mode/is high-Ievel data and process
model used to confirm the scope of project. It identifies
the major entities, relationships, and business functions
addressed .
The /ogica/ mode/(or business model) is the definition of
the data and business processes included in the system .
This model is independent of physical constraints and
considerations, such as ownership, geographic
location, technology of Implementation.
For the warehouse you do not need to build in the business
process functionality.
The physica/ mode/is description of the internal data
structures and processes used the system. This model
defines the physical implementation of the logical model.
The entity re/ationship diagram (ERD), model,
depicts data items of interest to organi zation (entiti es)
and the relationships between the entities.
Properties of the Enterprise Model
The enterprise model :
Is neutral, and as such contains business rules defined business

Defines framework for warehouse development.
Is centered around providing the business needs, rather
than the operational applications that process, and maintain the
informati on.
Is designed for data analysis rather than t ransact ion processing.
I s good point analysis; it is not intended to model for
systems design.
Provides basis for definiti ons of
used as guide to integration.
I s independent from changing business processes because it contains
business rules; changes slowly compared to

1
The Corporate Data Model
The logical model of current operational systems and their supporting
data structures.
Designed for transaction processing.
source of business rules, and contains normalized data.
corporate data model, identifies multiple data sources for the same
data element and simplifies mapping.
As each source system maps to the corporate data model, we need
mapping from the corporate data model to the data warehouse.
Identifi es data usage and meaning differences of the same data
different user groups within the organization
the use of the data and business
arranges to differences, and different uses
of the same data and business
Modeling the Warehouse
Create business model
Create dimensional model
Create physical model
Conc. ptual Mo-del
data warehouse logical model
model)
Star
Snowflake
Constellation
Components:

Attributes (Color, size, weight)
Attributes related

lattice
Facts - the of data
to the dimension tabIes keys.

I .

Pt..xil.\ct
Modeling the Warehouse
Creating Business Model

I
"['''.
lt)"
Develop normalized entity relationship model of the business
model of the data warehouse.
It is not necessary at this stage how the data is retrieved. It is
important to the structure of the information, the entities,
and relationships.
At this level the model allows you to simply see and
how the structure is easi ly changed to meet new needs.
Build in integri ty constraints to ensure the consistency of query
results
Creating Dimensional Model
Translate the ER model to dimensional model, ensuring that the
model encompasses information requirements and analysis needs.
Creating Physical Model
Translate into the physical model, balancing analysis needs with
physical performance considerations
2
the ER model to dimensional model

L OrdlD
OrdlD
LineNo
CustlD
Productld
f-
OrdSaleslD h
CustName Quantity
SalesLocation Address UnitPrice
OrderDate Phone ltemTotal
DateFi lled CreatedBy
Comments CreditcheckedBy
Credi tClerkl D
ShipA dress
steps identilied
here just
approach, and give '-- SalesmanlD
ProductlD 1-
idea 01 just
ManagerlD
ClasslD
how difficult this
ProjectedSales
process might CreatedBy
Ven orl
and how you HireDate
SKU
ProductStatus
restricting yoursell to
CreatedBy
only the data
availabIe.
1

L OrdlD
OrdlD
Li neNo
CustlD r-- CustlD
Productld 1-,
OrdSaleslD h
CustName Quantity
SalesLocation Address Unit Price
OrderDate Phone ItemTotal
DateFilled CreatedBy
Comments Credi tcheckedBy
.Routi1i CreditClerklD
ShipA dress
'-- SalesmanlD
ProductlD
1-

ClasslD
Projec edSales
CreatedBy
Ven orl
HireDate
SKU
ProductStatus
CreatedBy
11
1:
Remove all operational, derived, and denormalized data
that is used to process discrete transactions, such as
delivery instructions, processing instructions, audit
information, and user creation and update stamps.
In the example, the removed attributes identified
minus sign (-).
They include status flags and text comments, that classify
as purely operational data.
10
1

L OfdlD
OrdlD
CustlD
1-
CustlD
LineNo
OrdSaleslD 1-
Productl d
r-
CustName Quanti ty
SalesLocation Address UnitPrice
OrderDate Phone ltemTotal

I
ProductlD r-
I
I
Clas.'1D
Proj ectedSales
Ven orl
SKU
12
3
2: Add element of time to the model .
Add element of time to the model, if it does not already exist. If
time stamp already exists, extend it to include the required
information.
time variant structure time span (giving start and end
dates) discrete value (giving single point-in-time).
In the example, Snapshot Date, for point-in-time reference, has
added to each entity, except for the ORDER tabIe which already
has Order Date that used.
Note: You also determine the final multidimensional model and
then add the time elements afterwards. As already discussed, the
approach you take vary.
3: Add derived data to the model.
13
In this step, you denormalize the structure, and add derived data to
reduce the amount of processing required. In the operational
relational model, derived data is not stored-SQL is used to create the
derived data, such as summaries, at run time.
In the example, columns such as Total Order Value, Discount Applied,
and Total Sales Orders have added.
15
(
OrdlD fj
CustlD - CustlD
OrdSaleslD -
SalesLocation Address
OrderDate Phone
3
OrdlD
+SnapshotDate
'-- SalesmanlD
ManagerlD
PrOlectedSales
+SnapshotDate
CustlD
f---
CustlD
OrdSaleslD
f-
CustName
SalesLocation Address
OrderDate Phone
+ TotalOrderValue SnagshotDate
+Discount + alCustomerOrders
'-- SalesmanlD

Projec edSales
SnagshOtDate
+ alSalesOrders
L OrdlD
LineNo
Productld
Quantity
UnitPrice
ltemTotal
+SnapshotDate
ProductlD
ClasslD
CategorylD
VenaorlD
SKU
+SnapshotDate
L OrdlD
LineNo
Productld
Quantity
UnitPrice
ltemTotal
SnapshotDate
ProductlD
ClasslD

Ven
SKU
SnagshOtDate
+ alProductsOrdered
14
f-
f--

4
4: Merge like data.
Determine whether there tabIes with data that merged
and combined key, to form view.
You merge data from other subject models operational
systems.
This is the most difficult step, and takes the longest time.
You need the of tools and data quality managers.
I n the example, information is added from the Item tabIe in
the application. This additional information is and
becomes our measure.
17
5: Segregate aggregate data if appropriate
Determine arrays (repeating groups) of data.
Create arrays of data if fixed increments known. Attributes such as
Gender, which have limited list of values, likely arrays.
Place descriptive text in separate tabIe.
Organize data frequency of update into separate data types. This
involve creating tabIes that contain detail historical
information.
In the example, two distinct changes have made:
Two entities, Customer Detail and Salesman History, have created to
separate data that is modified frequently from data that is modified
infrequently.
Information from the Order Item tabIe is moved into the Order tabIe.
Order Item information becomes facts (measures).
19
4

L OrdlD
OrdlD
LineNo
CustlD
Productl d f-;
OrdSaleslD
iCustName Quantity
saies Location iAddress UnitPrice
OrderDate I Phone ItemTotal

i SnapshotDate
Discount lTota CustomerOrders +WarehouselD
+OrderLeadTime
+StockOut
+StockLevel
-
SalesmanlD
ProductlD f-


Projec edSales

Ven
Tola SalesOrders
SKU

Tota ProductsOrdered
18
I 5
-
L OrdlD
OrdlD
CustlD
HCustlD
CustlD
LineNo
OrdSaleslD
SnapshotDate
Productld ---,
h I CustName , I

SalesLocation SnapshotDate Address

OrderDate
Phone
ItemTotal

--


Discount WarehouselD
OrderLeadTime
StockOut
StockLevel
SalesmanlD SalesmanlD
ProductlD -
JI
SnapshotDate
ClasslD
otDate
ProJectedSales

Ven

SKU

Tota ProductsOrdered
20
5
5
OrdlD
CustlD r--
CustlD
OrdSaleslD
h ICustName ,1
SnapshotDate
SalesLocation SnapshotDate
Address
OrderDate Phone

Discount
LineNo
./
Productld
Quantity
UnitPrice
ProductlD
ltemTotal
SalesmanlD f-----

SnapshotDate
SalesmanlD

WarehouselD 1 81
SnapshotDate
Ven orl
Snaps otDate
SKU OrderLeadTime
ProjectedSales


Tota ProductsOrdered
StockOut
StockLevel
6
OrdlD
CustlD H CustlD CustlD
ICustName I SnapshotDate
[RegionlD SalesLocation SnapshotDate I Address
. OrderDate Phone
I
ReglOnAddre?S I
Discount
LineNo
Productld
/ Quantity
____ / UnitPri ce
ProductlD ItemTotal
lasslD
CategorylD
VenaorlD
SKU
SnapshotDate
TotalProductsOrdered
SnapshotDate
WarehouselD
OrderLeadTime
StockOut
StockLevel
'- SalesmanlD f-- SalesmanlD
I
ManagerlD I SnapshotDate
Snaps110tDatel ProjectedSales

21
23
i Apply contextual data in two stages
Apply simple criteria to the data.
The structure of each attribute
Data encoding and metrics
Naming conventions and how the attributes to the operational system
Apply complex criteria to the data.
Descriptive information about the business
information such as industry profile and demographic information
our example, ID gives some to the Order tabIe. Now user
about orders
Note: Although the Time dimension is not part of the Corporate Model,
it must added for the complete dimensional model.
Moving from Logical to Physical Design
Logi cal design is what you draw with and
design with software Designer tool
before bui lding your data warehouse.
Physi cal design is the creation of the database
with SQL statements.
22
During the physical design process, you convert
the data gat hered duri ng the logical design phase
into descripti on of the physi cal database
structure. Physical design decisi ons mai nly
driven query performance and database
maintenance aspects.
24
6
Moving from Logical to Physical Design
At this time, you have to


I
I

to tabIes
Entitif:'5 Ind';')bl
to

key i
Attributes to
. P'imar)' KlS'i

Primary


to primary key

to
key
25
7