1. Data Warehouse—Subject‐Oriented
•Organized  around  major  subjects,  such  as  customer,  product,  sales.
•Focusing  on  the  modeling  and  analysis  of  data  for  decision  makers,  not  on  daily  operations  or  transaction  processing.
•Provide  a  simple  and  concise  view  around  particular  subject  issues  by  excluding  data  that  are  not  useful  in  the  decision  suppor  process.(EP-44)

2. Data Warehouse ‐Integrated
•Constructed  by  integrating  multiple,  heterogeneous  data  sourcesrelational  databases,  flat  files,  on‐line  transaction  records
•Data  cleaning  and  data  integration  techniques  are  applied.
Ensure  consistency  in  naming  conventions,  encoding  structures,  attribute  measures,  etc.  among  different  data  sourcesE.g.,  Hotel  price:  currency,  tax,  breakfast  covered,  etc.
When  data  is  moved  to  the  warehouse,  it  is  converted

3. Data Warehouse ‐Time Variant
•The  time  horizon  for  the  data  warehouse  is  significantly  longer  than  that  of  operational  systems.
Operational  database:  current  value  data.
Data  warehouse  data:  provide  information  from  a  historical  perspective  (e.g.,  past  5‐10  years)
•Every  key  structure  in  the  data  warehouse
Contains  an  element  of  time,  explicitly  or  implicitly
But  the  key  of  operational  data  may  or  may  not  contain  “time  element”.

4. Data Warehouse ‐Non Updatable
•A  physically  separate  store  of  data  transformed  from  the  operational  environment.
•Operational  update  of  data  does  not  occur  in  the  data  warehouse  environment.
Does  not  require  transaction  processing,  recovery,  and  concurrency  control  mechanisms.
Requires  only  two  operations  in  data  accessing:  initial  loading  of  dataand  access  of  data.

5. Data mart:
A data mart contains a subset of corporate-wide data that is of value to a specific group of users. The scope is confined to specific, selected subjects. For example, a marketing data mart may confine its subjects to customer, item, and sales.
Data marts are usually implemented on low cost departmental servers that are UNIX- or Windows/NT-based.
The implementation cycle of a data mart is more likely to be measured in weeks rather than months or years.

6. Accident, not architecture Sourced directly from operational systems
Independent data marts – generally developed by individual organisational departments, which operate in isolation. Organisations with a number of data marts will find data definitions across the data marts inconsistent and lacking in conformity.
Accident, not architecture
Sourced directly from operational systems
Redundant data
Redundant processing
Not scalable
“Doesn’t require that a business come to terms with their data and business procedures”
Data mart bus architecture - this architecture is rooted in specific business processes but the use of conformed dimensions and facts enables the incremental integration of additional data marts to form an organisation wide view of the organisation. Data is modelled dimensionally in a star schema.
Start at the ground level rather than the enterprise level – “Bottoms up” approach
Pick business processes and model them
Dimensional modeling (star schema) rather than ERD
Data marts uses “standardized, conformed dimensions”
Warehouse is “conceptual” created by the “bus” of conformed dimensions

7. Addresses need for dependent data marts
Hub and spoke architectures – the aim of this architecture is to iteratively develop, subject by subject, an enterprise wide view of data where atomic level data is maintained in the warehouse in 3rd normal form i.e. the hub. The vast majority of users will access the data from dependant dimensionally modelled data marts (spokes).
Addresses need for dependent data marts
Marts receive data from central source ‐ the warehouse
Medium and large contexts
Scalable, often enterprise‐wide
Sometimes called the Corporate Information Factory
Centralised data warehouse – this architecture is similar to the hub and spoke architecture but has no dependant data marts.
No dependent data marts
Consolidates data marts into data warehouse
Warehouse contains both atomic (detail) data and summary

8. Useful in mergers and acquisitions
Federated – the federated architecture draws upon existing decision support structures where the “data is either logically of physically integrated using shared keys, global metadata, distributed queries, and other methods”.
Low overhead
Do not rearchitect existing data structures (such as marts,warehouses, or transactional systems)
Logically or physically integrate data
Distributed queries and metadata associate the data
Access data simultaneously across multiple systems
Useful in mergers and acquisitions

11. DATA WAREHOUSE
Corporate/Enterprise-wide
Union of all data marts
Data received from staging area
Queries on presentation resource
Structure for corporate view of
data
Organized on E-R model
DATA MART
Departmental
A single business process
Star-join (facts & dimensions)
Technology optimal for data
access and analysis
Structure to suit the
departmental view of data
Figure 2-5 Data warehouse versus data mart