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)

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

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”.

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.

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.

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

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

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

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