']1.

Models in the Business

for t he entire business
Logical
Operational systems
Iogical for the system
Warehouse
Iogical subject spe<:ifK the data warehouse,
moclels the data marts star, snowfiake, constellation

Physical models
Physicaf implementations of the models at the database level.
I Model
Opelaliol1al sy:s.tems Warell0use
Properties of the Enterprise Model
enterprise model:
15 and as such contains business rules business
processes.
Defines framework development.
15 centered around providing information the business needs, rather than
the operational applications that enter, process, and maintain the
information.
15 designed data analysis rather than t ransaction processing.
15 good analysis; it is not intended to
systems design.
Provides basis definitions of terms.
used as guide to integration.
15 independent from changing business processes because it contains
business rules; enterprise information changes slowly compared to
operational information.

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/ business model) is the definition of the
data and business processes included in the system.
model is independent of physical constraints and considerations,
such as organizational ownership, geographic location, technology of
implementation.
For the warehouse do not to build t he business process
fundionality.
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 organization (entities) and the
relationships between the entities.
1, The Corporate Data Model
,
The logical model of current operational systems and their supporting data
structures.
Designed for transaction processing.
The source of business and contains normalized data.
corporate data model, identlfies multiple data sources the same data
element and simplifies mapping.
As each source system maps to the corporate data model, we need
mapping from t he corporate data to the data warehouse.
Identifies data usage and meaning of the same data different
user within the organization
determines the and use of the data and business rules
arranges to document differences, and different uses of the
same data and business tules
The Enterprise Model
Provides neutral and logical business wide view of key information
required all groups to operate competitive business
fundamental aim of the model is to communicate, among diverse
user groups, the need and of, information within the
business.
J data warehouse logical model (multidimensional
model)

Star
Snowflake
Constellation
Components:
Dimensions
Attributes (CoIOf, size, weight)
Attributes related
hier('l,chicillly
Fact5 . the columns of data related to
the dimension tabIes keys.
111
L
"lf\
... ,
I

'1"

/"'-


1
Modeling the Warehouse
Create business model
Create dimensional model
Create physical model
OrdlD
CustJD
OrdSall!slD
SelesLocation
OfderOate

Commenl.s

CustlD
CuslName
I
Address



8usiness Model
Develop normalized entity relationship model of t he business model of
the data warehouse.
It is not necessary at this stag how the data is retrieved. It is important
to the structure of the information, the entities, attributes, and
relationships.
t his the model allows simply see relationships and how
t he structure is easily changed to meet new needs.
Build '" integr;ty constraints to ensure the consistency of query results
Creating Dimensional Model
Transtate the ER model to dimensional model, ensuring that the model
encompasses information requi rements and analysis needs.
Creating Physical Model
-,
Translate into the physical model, balancing analysis needs with physical
performance considerationS
I 1: Removing unneccessary attributes
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.
sample ER model
CustlD
CuslName
Address
Phone
OeatedBy

steps here
just give .,,00
Idea of just .... dlfficult t!lIS
process mlgh! anc! hO....
only
data availabIe.
CuslName
Address
Phone



12
2
3: Add dec;ved data to the model.

In this step, you denormalize the and add data to reduce
the amount of processing required. In t he operational relational model,
derived data is not stored-SQL is used to create t he data, such as
summaries, at t ime.
In t he example, columns such as Total Order Valu, Discount Applied, and
Total Sales Orders have added.
13
... 2: Add element 01 time to the model .
element of t ime to the model, if it does not already exist. If time
stamp exists, extend it to include the required information.
time t ime span (giving start and end dates)
discrete value (giving point-in-time).
I n the example, Snapshot Date, reference, has
added to each entity, except the ORDER tabIe which has
Order Date that used.
Note: You also determine the final multidi mensional model and then
add the time elements afterwards. As already discussed, the approach you
take vary.
OrdlD
I
custJD
OrdSaleslD _
'Salesl ocation
j
OrderDate
..
"'Olscounl
17
17 2
*,

.

OrdSaleslD IcC;;;;"Wt N;;;;,m;;;,---j
aes Address
OrderDate Phone
...SnapshotDale
I
:ManagerlD
Pr0JecledSeles
..Snepsho!Dete
4: Mecge IIke data.
L _ ordlD
LineNo
Productld
Quantity
UnilPrtce
ItemTolal
.. SnapsholDate
whether there tabIes with data that merged and
combined key, to form view.
You data from other subject models operational systems.
This is t he most difficult step, and takes the longest You
need the of tool5 and data quality .
In the example, is added from the Inventory Item t abIe in the
Inventory application. This additionaJ informat ion is and
our mea5ure.
3
CustlD
OrdSateslD
SalesLocation
OrderDale

Discount
5
SnapsholDale
WarehouselD
OrderLeadTime
StockOut
SlockLevet
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 structures. This
involve creating tabIe5 that contain detail h\storical Information.
the example, distinct changes have made:
Two entities, Customer Detail and Salesman History, have created to
separate data that is modified frequently from data that is modifled infrequently.
1nformation from the Order tabIe is moved into the Order tabIe. Order Item
information becomes our fam (measures).
Apply contextual data in two stages
simple criteria to the data. Determine:
The structure of each attribute
11 Data encoding and metrics
11 Naming and how the attri butes to the system
Apply complex contextual criteria to the data. 1ntroduce:
11 Descriptive about the
11 such as industry profi le demograpt1lC Inrormation
example, Region ID gives some context to the Order tabIe. Now user
ascertain information about orders region.
Note: Although the Time dimension i5 not of the Corporate Model, it
must added for the complete dimensional model.



!OrdSaleslD
j Productld
RegionlD
I
saleSLocation
OrderDale

Oiscount
LlneNo

I
llemTotal
SnapshotDate
WarehouselD
I
OfderLeadTime
SlockOut
SlockLevel
21
24
4
Moving from Logical to Physical Design

Logical design is what you draw with and
design with software Designer tool before bui lding
your data warehouse.
Physical design is the development of SQL statements
to create the database.
During the physical design process, you convert the
data gathered during the logical design phase into
description of the physical database structure. Physical
design decisions mainly driven query
performance and database maintenance aspects.
Dimensions
- Static dimension tabIe
DDRelativelyeasy?
DAssignment of keys: produdion keys to DW using tabIe
DDCombination of data find key?
DCheck and relationships using
- Handling dimension changes
DDDescribed in last ledure
DDFind newest DW key given key
production keys to DW keys must updated
- Load of dimensions
OSma11 dimensions: replace
Q dimensions: load changes
25
Moving from Logical to Physical Design

this time, you have to
Entities to tabIes
Relationships to foreign key
constraints
Attributes to columns
Primary unique identifiers to
key constraints
Unique identifiers to unique
key constraints
Building Fact TabIes
types of load
-Initial load
all data now
when DW is started the first time
DOOften probIematic to get historical data
heavy -Iarge data volumes
update
OOMoy only changes since la5t load
periodicall y (,./month/weekjday/hour/ ,,) after DW start
DOless heavy data volumes
- Dimensions must updated before facts
DOThe dimension new facts must in place
DDSpecial key considerations if initial load must performed agajn
26
Construction Process

1 )Make high-Ievel diagram of sourc-destination flow
2)Test, choose and implement tool
3)Outline complex transformations, key generat ion and job sequence
every destination tabIe
Construction of dimensions
4)Construct and test static dimension
5)Construct and test change dimension
11 )Construd and test remaining dimension builds
Construction of fact tabIes and automation
7)Construd and test initial fad tabIe build
8)Construct and test incremental update
9)Construct and test aggregate build
10)Design, construd, and test automation
5