Using the AMBER Data Repository to Analyze, Share and - Iaria.org

18 Pages·2009·4.88 MB·English

by  Marco Vieira

Marco Vieira, University of Coimbra, Portugal
Tutorial The AMBER Project
•  Assessing, Measuring and Benchmarking
Resilience in computer systems and
Using the AMBER Data Repository
components (AMBER)
to Analyze, Share and Cross-exploit
•  Coordination Action supported by the
Dependability Data
European Commission in the 7th FP
•  Coordinating and advancing research in
Marco Vieira
resilience measurement and benchmarking in
[email protected]
University of Coimbra, Portugal computer systems and infrastructures
The Second International Conference on Dependability (DEPEND 2009)
Athens/Glyfada, Greece, June 18,2009
DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 2
Current challenges AMBER objectives
•  Quality of measurements •  State-of-the art survey
•  Integration of the human and technical •  Research agenda
components of the analysis
•  Data repository
•  Dynamic and adaptive systems and networks
•  Others:
•  Integration with the development processes – Dissemination events (workshops, panels, etc)
– Benchmarking tools
– Training material
DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 3 DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 4
This Tutorial… Problems
•  How to analyze the usually large amount of
raw data produced in dependability evaluation
Learn how to use the
experiments?
AMBER Data Repository •  How to compare results from different
experiments or results of similar experiments
to analyze and share data
across different systems?
from dependability – Different and incompatible tools, data formats, and
setup details…
evaluation experiments
•  How to share raw experimental results among
research teams?
DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 5 DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 6
DEPEND 2009
1
Marco Vieira, University of Coimbra, Portugal
Current situation ADR Vision and objectives
•  The situation today is not good!!! •  Vision
•  Spreadsheets and other specific tools to – Become a worldwide repository for
dependability related data
analyze results
•  Key objectives:
– Not standard and difficult to build
– Provide state-of-the-art data analysis
•  Difficult to compare data and generalize
– Allow data comparison and cross-exploitation
conclusions
– Facilitate worldwide data sharing and
•  Researchers share final results and conclusions dissemination
– Papers, mainly •  Potential tool to increase the impact of
– Raw data is not shared research
DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 7 DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 8
Data analysis approach Outline
•  Repository to analyze, compare, and share 1. Business Intelligence
results
•  Use a business intelligence approach:
2. Data Warehousing & OLAP
– Data warehouse to store data
– On-Line Analytical Processing (OLAP) to analyze
data 3. Using DW to analyze dependability related data
– Data mining algorithms to identify (unknown)
phenomena in the data
4. The AMBER Data Repository
– Information retrieval for data in textual formats
•  Adopt the same life cycle of BI data
DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 9 DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 10
What is Business Intelligence?
•  Business Intelligence (BI):
– Getting the right information, to the right
decision makers, at the right time
•  BI is an enterprise-wide platform that
1. Business Intelligence
supports, data gathering, reporting, analysis
and decision making
•  BI is meant to:
–  Fact-based decision making
–  “Single version of the truth”
•  BI includes reporting and analytics
DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 12
DEPEND 2009
2
Marco Vieira, University of Coimbra, Portugal
Five classic BI questions Typical BI technologies
•  ETL Tools (Extract, Transform, and Load)
•  Repositories
•  What happened? Past
– Data Warehouse
•  What is happening?
•  Why did it happen? Present •  Analytical tools
•  What will happen? – Reporting and querying
Future
– OLAP
•  What do I want to happen?
– Data mining
•  Information retrieval
DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 13 DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 14
Many proprietary products Some open source/free producs
ACE*COMM Microsoft SAS Institute •  Eclipse BIRT Project:.
Ab Initio Microsoft Analysis Services Siebel Systems •  Freereporting.com:
Actuate PPerorfcolarmritayn cePoint Server 2007 Spotfire (now Tibco) •  JasperSoft:
CCoybmeArQrcuhe ry OracHley pCeorripoonr Satoiolunt ions StatSoft •  OpenI:
Dimensional Insight Corporation SPSS •  Palo (OLAP database):
IBM Applix PPaennotarhaom a Software Telerik Reporting •  Pentaho:
Cognos Pervasive Teradata •  RapidMiner
IInnefotSrmoaftt ica PPiRloEt LSYoTftIwSa re, Inc. Thomson Data Analyzer •  SpagoBI:
Information Builders PQrloikstepcehro Business Suite •  Weka
LogiXML SAP Business Inf. Warehouse
LucidEra Business Objects •  Some products from big companies can be used freely
MicroStrategy OutlookSoft
DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 15 DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 16
What is a Data Warehouse?
•  Big database that stores data for decision
support
•  Built from the operational data collected from
2. Data Warehousing transactional DB and other operational systems
Operational DB
& OLAP & other systems Data Warehouse
Users
Users
DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 18
DEPEND 2009
3
Marco Vieira, University of Coimbra, Portugal
Basic DW components Data volume
•  Less than 20 GBytes
Data warehouse Users
Operational DB
(presentation servers) – Small dimension; runs in a PC
Ad hoc •  From 20 to 100 GBytes
queries
Legacy systems – Medium dimension; needs a powerful workstation
Reports
•  From 100 Gbytes to 1 TBytes
Data
Sprefialdessh, e..e. ts, Staging Spaepcpifs ic – Large dimension; needs a powerful server,
Area
normally with parallel processing
Models and
other tools •  More than 1 TBytes
External sources
– Very large dimension; massive parallel processing
DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 19 DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 20
Some characteristics Temporal dependency
•  Temporal dependency •  The data is collected over time
– Do not represent a specific moment
•  Non volatile
– Represents the history
•  Target oriented
•  A temporal reference must be associated to all
•  Data integration and consistency data in the database
•  Designed for queries
DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 21 DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 22
Non volatile Target oriented
•  The data in the DW is never updated •  The data warehouse must only store data
relevant for decision support
•  The DW stores historic data (historic memory)
collected from the operational databases •  Many operational data (needed for everyday
management) is not relevant for the DW
•  After being load (from the operational
databases) there is only one operation:
– Queries
DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 23 DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 24
DEPEND 2009
4
Marco Vieira, University of Coimbra, Portugal
Data integration and consistency Designed for queries
•  In a operational environment the information •  After being load the
may be stored in different locations using data never changes:
different representations – Only queries are The data must be stored
allowed in such a way that
improves performance
•  That data must be integrated and made
•  DW stores a large
consistent before being load in the DW
amount of data
Multidimensional view
Partial denormalization
DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 25 DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 26
Dimensional model The multidimensional model
•  Typical model in operational databases: E/R •  Facts stored in a multidimensional array
•  The dimensional model follows a different •  The dimensions are used to index the array
approach
•  Usually built using data from operational
– Stores the same data
databases Sales
– D•a Etaa soyr tgoa unnizdeartsiotann dis user oriented Store Lisbon 2
Coimbra
• Very good performance for queries Milk
•  Data Warehouses built over complex E/R Product SuOgairl 5 3
models never succeed Coffee
Jan Feb Mar Apr
Date
DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 27 DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 28
Star model Facts
•  The typical dimensional model is a star •  Represent the business measures
structure with:
•  The most useful facts are:
– A central table with facts
– Numbers
– Several dimensions tables describing the facts
– Additives
Dimension 1 Dimension 3
ID_dim 1 ID_dim 3
Facts Table
Attri... butes IIDD__ddiimm 12 Attri... butes
ID_dim 3
ID_dim 4
Fact 1
DiImD_ednismio n2 2 Fac... t 2 DiImDe_ndsimio n4 4
Attri... butes Fact n Attri... butes
DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 29 DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 30
DEPEND 2009
5
Marco Vieira, University of Coimbra, Portugal
Facts table Dimensions
•  Comprises several numeric attributes (facts) •  Each dimension represents a business
and foreign keys to the dimensions parameter
•  Normalized table – Time, clients, products, etc
•  Represent a entry point for the analysis of the
•  Relationships M:1 with the business
facts
dimensions
•  Represent different point-of-views for the
•  Contains normally a large number of records
analysis of the facts
•  Represents typically 95% of the space used
by the DW
DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 31 DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 32
Dimension tables Star schema example
•  Strongly denormalized Stores
Time
– For performance
ID_time
Day Store
•  Dimensions have hierarchies Day_of_week
Week_of_year Sale ID_store
– Datatryib ute Ms onth  Year  … Contain a large set of MTYreoiamnr tehs ter IIIDDD___tpsitrmoorede u ct NLDAoairsecmtaare li c t
Units_sold Num_tellers
•  Typically comprise a small number of records Product PSaulrec_hvaasleu_ec ost
ID_product Num_Clients
(when compared to the facts table) Name
Type
Brand
Category
Pack
Description
DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 33 DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 34
Low level queries User interfaces
ID_tiTmime e •  Explore data in Data Warehouses
Day Store
Day_of_week – Typical OLAP tools
Week_of_year Sales ID_store
MTYreoiamnr tehs ter IIIDDD___tpsitrmoorede u ct NLDAoairsecmtaare li c t ••  ADcactae spsr ethsee nrtealatiotionn uasl inegn gtainbele uss, inggra SphQicLs , reports, etc
Product UPunritcsh_assoel_dc ost Num_tellers • Targeted for ad-hoc queries
Sale_value
INDa_mper oduct Num_Clients – Other tools
Type
Brand select avg (sale_value x units_sold) • Data mining
Category
Pack from sale, time, product • Modeling
Description
where JOIN_TABLES
group by brand, month
DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 35 DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 36
DEPEND 2009
6
Marco Vieira, University of Coimbra, Portugal
Queries - Slice and Dice Drill-Down & Roll-Up
Drill-Down Roll-up
Most generic category
Sales by time and
product Sales by store and
brand
Intermediate category
Most detailed category
Full Detail
DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 37 DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 38
Steps for the design of the star
Time: Drill-Down & Roll-Up
model
Drill-Down ALL Roll-up 1.  Identify the business process/activity
TWrMiYemeeokeans rtt ehr 234...   ••  IIDddeeeDPfnnrianottyiideff,yy u Wt chttthhe,e eeeC kd afd,aa tMiemtcagotoes ngr ntyrhsa,, i…no…un lsa rity Do dneop(te ofnpoderrs gateoitn o ttnhhaalet tddhaatte aa bmaaovsdaeiesll, afbillee s, etc)
•  Store, City, …
Day
DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 39 DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 40
Example – Retail sales Retail sales – Business data
•  Set of stores belonging to the same enterprise •  Where to collect the data?
– POS - point of sales
•  Goal: Analysis of sales
– Operational database
•  Each store has several departments (food, •  What to measure?
hygiene and cleaning, etc) – Sales
•  Sells thousands of products •  Goals?
– Maximize the profit
•  Products are identified using a unique number
– Maximum sales price possible
– Lower costs – More clients
DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 41 DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 42
DEPEND 2009
7
Marco Vieira, University of Coimbra, Portugal
Retail sales – Facts Retail sales – Dimensions
•  Examples of relevant decision support facts: •  Main dimensions:
– Number of units sold – Product x Store x Time
– Acquisition costs
•  Are there other relevant dimensions?
– Sale value
– Supplier? – Promotions? – Client?
– Number of clients that bought the product
– Employee responsible for the store on that day?
•  Question: is it possible to obtain base data
•  It is normally possible to add extra dimensions
(from the operational system) for these facts?
•  All the dimensions have a 1:M relationship
with the facts
DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 43 DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 44
Retail sales Granularity
•  Example: record the daily sales for all products
ID_product
ID_product ID_time
description ID_store ID_store – Analyze in detail (price, quantity, etc) the products
full_description ID_promotion name
SpbKaracUkn_adng eu_msibzeer upnuirtcsh_asoseld_ cost sscttiootyrr ee__nsturmeebt_eard dress sold every day, in each store, …
subcategory sale_value store_county •  Retail sales granularity:
category num_Clients store_state
dpdweaieepcitgka_hratyttgm pe_ee tnytp e IdDat_et ime ID_promotion sssstaatoolleerrssee____drzmeiipsgat inroaincg te r – Products x Store x Promotion x Day
weight_unit_of_measure day_of_week number store_phone •  The granularity defines the detail of the DW and
units_per_retail_case day_number_in_month name store_FAX
ucansietss__ppeerr__sphailplepti ng_case dwaeye_kn_unmumbebre_ro_viner_aylela r ttyyppee__padrivceer_triseedm ent fplhooorto__pplarnoc_etysspien g_type has a strong impact in the size
shelf_width_cm week_number_overall type_poster finance_services_type
sshheellff__hdeeipgthht__ccmm Mquoanrtther Tpryopme_octoiounp_ocnoss t flairsstt__roepmeondeedl__ddaattee •  The granularity must be adjusted to the
……... fiscal_period start_date store_sqft
yheoalird ay_flag e…nd…_.d..a te gfrroozceenr_ys_qsqftf t analysis requirements
………. meat_sqft
……...
DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 45 DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 46
Retail sales – Details Retail sales – Details
ID_pro•d uMct andatory dimension that ID_product
IdfuDels_lc_prdrieposdtciuorcnipt tion IIIDDD___tspitrmooreme ordteieopnp reensdeenntsc yth e DW tInDeam_mseto rpe oral IdfuDels_lc_prdrieposdtciuorcnipt tion • Must chaIIIDDDr___atspitcrmoortemee ortiizone the products InDam_seto re
SpbsuKarbacUknca_adtng eeug_mosribyzee r upsanuliretc_shv_aasos•luel d_Me c ousts t describe time sscsatttiootosyrrr eee ___snsctouerumeneebtt_yena rd dbreyss SpbsuKarbacUknca_adtng eeug_mosribyzee r amsa sneaegne upsmabnulireytec_s hv_ntaashostlue led_e c obstu siness sscstttiootoyrrr eee___nsctourumenebtt_yea rd dress
category num_Clietnhtse business managsteorme_setatne t category num_Clients store_state
department store_zip department • Must contain the attributes that store_zip
pdwwuaineeeciiittggk_shhat_yttgp _peeu_ern t_yirtpe_etoa fi_l_mceaasesu re IdddDaaatyy_e__t ionmfu_emw beeekr_ in_month • IssyInn Duantm_myptebphr eoriem cotatiicolnl y m gaennneerra tesssssdaatttooolleerrr sseeei_____ndrmpFeiA hsgaaotXinronai necg te r pdwwuaineeeciiittggk_shhat_yttgp _peeu_ern t_yirtpe_etoa fi_l_mceaasesu re IdddDaaatyy_e__t• ion mfuIa_etmw rbieeseekr _ raien _lsmetovrnotahn ngt lfyo rd InnDepuam_mnopebr oseormtr emotrioiano lriz qeude ries sssssaatttooolleerrrsseee_____drmpFeiAhsgaotXinronai necg te r
ucansietss__ppeerr__sphailplepti ng_case dwaeye_kn_unmumbebre_ro_viner_aylela r • It ttyyisppee __npadroivceter _tgriseedem nenet rated frfplohooomrto__p pltarhnoc_eetyss pien g_type ucansietss__ppeerr__sphailplepti ng_case dwaeye_kn_utnamumbbeblree_ro_ vi(newr_aylelha ri ch is attyylppsee__opadr ivtcyeer_ptriseiedcm aenlt in fplhooorto__pplarnoc_etysspien g_type
sshheellff__wheidigthht__ccmm wMeoenkt_hn umber_overall optTyypepeer__pacootsutipeoro nns al databasffeiinrsastn_ coep_esneerdv_icdeast_et ype sshheellff__wheidigthht__ccmm wMeoenkt_hon utmhbeerr_ odveirmall ensiontTyysppe)e_ _pcoosutpero ns ffiinrsatn_coep_esneerdv_icdeast_et ype
s…he…lf_..d. epth_cm qfiuscaarlt_epr eriod • Inpstcraorlmut_oddtaioeten _sc oast ll the recolsatrosdtr_esr_es mqfotd el_date s…he…lf_..d. epth_cm qfiuscaarlt_epr eriod pstraormt_odtaioten _cost lsatostr_er_esmqfotd el_date
yheoalird ay_flag ree…npd…r_.ed..a stee nting the timgfrerooz cepenr_yes_qrsqfitof t d yheoalird ay_flag e…nd…_.d..a te gfrroozceenr_ys_qsqftf t
………. considered in the DWmea t_sqft ………. meat_sqft
……... ……...
DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 47 DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 48
DEPEND 2009
8
Marco Vieira, University of Coimbra, Portugal
Retail sales – Details Retail sales – Details
ID_product • Characterizes the existing prIoDm_proodtiuoctn s
ID_product • Must characterize tIhD_eti mset ores as ID_product ID_time
dfuelslc_rdiepstciornip tion seen by the busineIIsDDs__sp tmroormea ontioang ement InDam_seto re •dfue lIslc_nrdi eptstchiorniips ti oen xample there is only IIoDDn__spetroo rmde oimtione nsion related to InpDam_rsoeto mre otions
SpbsuKarbacUknca_adtng eeug_mosribyzee r • Mreulesvt acnotn ftoari np othsete aritupsotanurlrireit cb_sqhv_uaasuosltueeled_er c sioe stts h at are sscstttiootoyrrr eee___nsctourumenebtt_yea rd dress •SpbsuKar bRacUknca_adetng• ee upgM_mosrribyzaeee nr s aegnetrss aw avnet rtyo kimnopwo trhtae nimtups apdnulaireitc_mschv_taas eoslouelndf_e c psorsioot mno tions in the salessscsttti ootoiyrrrn eee ___onsctourrumdeneebtt_yera r d tdor ess
category num_Clients store_state categoryt arget new promotions to specnifuicm _pCrloiednutsc ts, stores and time store_state
dpdweaieepcitgka_hratyttgm pe_ee tnytp e • (InloccluaIdDadlti_ezet imaset igoeno) g raphical aIDt_tprriobmuottioen s sssstaatoolleerrssee____drzmeiipsgat inroaincg te r dpdweaieepcitgka_hratyttgm pe_ee tnytp e IdDat_et ime ID_promotion sssstaatoolleerrssee____drzmeiipsgat inroaincg te r
weight_unit_of_measure day_of_week number store_phone weight_unit_of_measure day_of_week number store_phone
uunniittss__ppeerr__rshetiapipl_incga_sec as•e  Includdaadyy__ennsuumm tbbieemrr__ioenv_e mraaoltln ttrh ibutesnty apme_e price_red sfltooorre__pFlAaXn_ type uunniittss__ppeerr__rshetiapipl_incga_sec ase ddaayy__nnuummbbeerr__ionv_emraolln th ntyapme_e price_red sfltooorre__pFlAaXn_ type
cshaseelfs__wpeidrt_hp_aclmlet (opewwneeeeikkn__nnguu mmdbbaeerr__teionv_,ey…reaallr ) . ttyyppee__apdovsteerrt isement pfihnoatnoc_ep_rsoecrevsicsiensg__tytyppe e cshaseelfs__wpeidrt_hp_aclmlet wweeeekk__nnuummbbeerr__ionv_eyreaallr ttyyppee__apdovsteerrt isement pfihnoatnoc_ep_rsoecrevsicsiensg__tytyppe e
shelf_height_cm Month Type_coupons first_opened_date shelf_height_cm Month Type_coupons first_opened_date
shelf_depth_cm quarter promotion_cost last_remodel_date shelf_depth_cm quarter promotion_cost last_remodel_date
……... fiscal_period start_date store_sqft ……... fiscal_period start_date store_sqft
year end_date grocery_sqft year end_date grocery_sqft
holiday_flag ……... frozen_sqft holiday_flag ……... frozen_sqft
………. meat_sqft ………. meat_sqft
……... ……...
DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 49 DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 50
More than one star Several stars
Sales Stock
Store IIIDDD___tpsitrmoorede u ct Time IIIDDD___tpwirmaorede uhcotu se Warehouse
upsnanuulirmetc_s_hv_caaslosliueeld_ne c tso st Product qqplauuusaart_cnnhstte__alaosl_evu_patc riloiacsbet le OrdDeirmse nsion: Time Sales DDiimmeennssiioonn:: TCiommep onent
•  Two or more starts can be connected using one DDiimmeennssiioonn:: CSuopmpplioenr ent DDiimmeennssiioonn:: CCloinentrta ct
or more dimensions Dimension: Contract
Stocks
•  Shared dimensions must be conform Dimension: Time
Dimension: Component
– Contain consistent data when considering each star Dimension: Warehouse
•  Drill across: query that crosses more than one
start
DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 51 DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 52
Questions
?
3. Using DW to analyze
dependability data
DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 53
DEPEND 2009
9
Marco Vieira, University of Coimbra, Portugal
Basic elements of a DW A DW for experimental data
Operations Analysis
Experiments Result analysis
Operational DB Fault injection
Multidsiemrveenr sional O(LreAsPu lat panpalilcyasitsio) n tools Multidsiemrveenr sional O(LreAsPu lat panpalilcyasitsio) n
Robustness testing
Legacy Systems Exp. Stoysotles m A
Ad hoc
Aqude hrioecs Dependability queries
Sprefailde ss h..e. ets, WaDreahtao use Net Statistical Ebxeepnx.cp Sheymrismtaermekni Bnts g WaDreahtao use InLtAerNn/e t RSteaptiosrttiicnagl
Reporting
Any other
experimental
External sources environment
ExpF.i Selyds tdemat aN
DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 55 DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 56
Two types of data in experimental
Key points of the proposed approach
dependability evaluation

• Experiments • Multidimens ional • OLAP tool
• Exp. Setup A database •q Aude rhioe cs Network

• Exp. Setup B W?aDreahtoa u se • Ne t ManagemEexnpte Sryimsteenmt EFxapu.l tcso dnetrfionl idtiaotna Target System
Exp. Setup N •• R Steaptoisrttiicna gl (impRaecatd oofu ftasu lts)
Two types of data:
•  General approach to store results from dependability
evaluation experiments •  Measures collected from the target system (FACTS)
•  Data from different experiments can be compared/cross- – tFimore e, xfaaimluprele m, roadwe sd,a etatc r epresenting error detection efficiency, recovery
exploit (only if it makes Wsehnaste’s t oin csiodme?p are) •  Features of the target system and experimental setup
•  Raw data is available (not only the final results) that have impact on the measures (DIMENSIONS)
•  Results can be analyzed and shared world wide by using
– For example, attributes describing the target systems, the different
web-enabled versions of OLAP tools configurations, the workload, the faultload, etc
DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 57 DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 58
The multidimensional model The star schema
•  Facts are stored in a multidimensional array
•  Dimensions are used to access the array
according to any possible criteria
m
Target syste SysSteymste Am B
Faultload
Workload
DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 59 DEPEND 2009, Athens/Glyfada, Greece, June 18,2009 60
DEPEND 2009
10