A Business Analysis Framework by st1nk778

VIEWS: 89 PAGES: 15

									            Metodologia de
            desenvolvimento de DW




    A Business Analysis
    Framework
   Quatro perspectivas no desenho de um DW:
       Top-down: permite a selecção da informação relevante
        necessária para armazenar no DW
       Fontes de dados: expõe a informação que foi capturada,
        armazenada e gerida pelos sistemas operacionais
       Data warehouse: consiste nas tabelas de factos e dimensões e
        representa informação armazenada no DW
       Interrogações do negócio: acesso aos dados do DW do ponto
        de vista do utilizador final




                                                                       1
             Processo de desenho do
             DW
   Bottom-up:
       Começa c/ experiências e protótipos (rápida)
       Deriva o esquema do DW a partir dos esquemas das fontes de
        dados
       Permite avançar a baixo custo e avaliar os benefícios, mas é mais
        difícil de crescer
   Top-down:
       Começa com desenho e planeamento completo e maduro
       Primeiro, chega ao esquema conceptual do DW e depois
        converte o esquema das fontes de dados no esquema global
       Robusto mas lento e caro
   Combinação de ambas




    Designing the DW
        Within a successful approach to DW design,
         top-down and bottom-up strategies should
         be mixed.

            When planning a DW, a bottom-up approach
             should be followed.
            One data mart at a time is identified and
             prototyped.
            Each data mart is designed in a top-down fashion
             by building a conceptual scheme for each fact of
             interest.




                                                                            2
Data Mart prototyping
Prototype first the data mart which:
   plays the most strategic role for the enterprise;
   can convince the final users of the potential benefits;
   leans on available and consistent data sources.


                      DM2                 DM4



                              DM1



                                       DM3
                  DM5




                 Source 3   Source 1    Source 2




    Três modelos de DW
Enterprise warehouse
       Colleciona toda a informação sobre os processos de negócio
        de toda a organização
Data Mart
       Subcjto dos dados da organização que são interessantes
        para um grupo específico de utilizadores (ex: marketing)
       Independentes vs. dependentes (directly from warehouse)
Virtual warehouse
       Cjto de vistas sobre as fontes de dados operacionais
       Só algumas vistas sumarizadas são materializadas




                                                                     3
Desenvolvimento incremental de um
DW
                                       Multi-Tier Data
                                       Warehouse
           Distributed
           Data Marts



    Data           Data                     Enterprise
    Mart           Mart                     Data
                                            Warehouse

      Model refinement   Model refinement


     Define a high-level corporate data model




 Business Dimensional Lifecycle




                                                         4
DW Bus Architecture Matrix

   Ferramenta de planeamento top-down para
    desenho do DW
   Obriga a nomear todos os data marts (ou
    processos de negócio) possíveis e nomear
    todas as dimensões envolvidas nesses data
    marts
   Depois, podemos passar ao desenho das
    tabelas de factos individuais envolvidas em
    cada data mart.




Estrutura da Matriz

Linhas: data marts
Colunas: dimensões
Intersecções: onde uma dimensão existe para
  um data mart

Uma linha indica o nº de dimensões para um
 dado data mart
Uma coluna com muitas intersecções indica
 que é importante e deve ser conforme




                                                  5
Extended 4-step design
methodology (Kimball)
    Processo de desenho de DW típico:
    
        Escolher o processo de negócio a modelizar
         (ex: encomendas, recebimentos, etc)
       Escolher o grão (nível de dados atómico) do
         processo de negócio
       Identificar e tornar conformes as dimensões
         que se aplicam a cada registo da tabela de
         factos
       Escolher os factos que vão popular cada
         registo da tabela de factos




Extended 4-step design method
(Kimball) (cont.)
       Armazenar medidas pré-calculadas na tabela
         de factos
       Enriquecer as tabelas de dimensões
       Escolher o período de duração do DW
       Monitorizar as slowly changing dimensions
       Decidir prioridades de interrogação e modos de
         interrogação




                                                          6
   1. Escolher o processo




Degenerate dimension: usually occur in line item-oriented
fact table designs




   2. Escolher o grão




     O grão é a linha em cada recibo do cliente




                                                            7
3. Identificar e tornar conformes
as dimensões




Dimensões conformes

   As dimensões são os pontos de entrada num data
    mart. Determinam:
       Os critérios de navegação
       Os cabeçalhos dos relatórios
       Vocabulário da organização para os utilizadores
   Dimensões conformes: significam a mesma coisa e
    guardam a mesma informação independentemente
    da tabela de factos a que estão ligadas.




                                                          8
    4. Escolher os factos

   O grão da tabela de factos determina que factos
    usar num data mart
   Todos os factos têm que ser especificados ao
    mesmo nível determinado pelo grão
   Os factos devem ser o mais aditivos possíveis
   Podem ser adicionados factos suplementares
    desde que sejam consistentes com o grão.




    Bad vs good fact table




                                                      9
Categorização dos factos ou
medidas
   Aditiva: podem ser somadas através de todas as
    dimensões; são medidas de actividade
       E.g.: unidades_vendidas, dolares_vendidos
   Semi-aditiva: só podem somadas ao longo de
    algumas dimensões; são fotografias no tempo
       E.g.: saldo_conta, quantidade de um inventário não
        podem ser somadas ao longo do tempo
   Não aditiva: não podem ser somadas de todo
       E.g.: temperatura, taxas de juro




Medidas aditivas
       F : A x B ® C é aditiva sobre A sse:
           F (a1 + a2, b) = F (a1, b) + F (a2, b)
           F é aditiva se é aditiva sobre todos os seus
            argumentos

    Exemplo : conta(contaID, clienteID, data, saldo)

    saldo : contaID x clienteID x data ® saldo

    saldo (x, y, [t0 , t2 ]) = saldo (x, y, [t0 , t1]) + saldo (x, y, [t1 , t2])
                                ?
    saldo (x1 È x2, y, t ) = saldo (x1, y, t) È saldo (x2, y, t2)
                                ?




                                                                                   10
Factless facts (1)

   Facts that do not go into a “normal” fact table
    since they do not measure anything
   Describe events and coverage
   Ex:
    Student traking system that detects each student
      attendance at a college
    Fact table: Student Attendance with attribute
      attendance (0/1)
    Dimensions: Time, Course, Student, Teacher




Factless facts (2)

   Ex:
    Sales Promotion fact table that records the sales of
      products in stores on particular days under each
      promotion condition
    Fact table: Promotion Coverage
    Dimensions: Time, Store, Product, Promotion




                                                           11
5. Storing precalculations (derived
facts) in the fact table
Derived data : computed from facts applying a
  function
 Some derived data are required to be explicitly
  stored
Aggregate data: usually modeled in specific fact
  tables.
Advantage: speed up OLAP queries
Inconvenient: slows down DW refreshment and
  increases DW size




Fact table with derived data




                                                    12
Fact table with aggregate data

      Customer Table          Store Table
         Cust_id               Store_id
       Cust_name               District_id                     Product,
                                                 Summary for Product,
                                                 Store, and Time for all
                                                       Customers
                   Sales Fact Table
                                                  Customer Summary
                    Unit Sell Price
                                                        Cust_id
                     Dollar Sales
                                                      Total Sales
                      Unit Sales
                                                  Highest Sales Value
                     Dollar Cost
                                                     Average Sales

      Time Table                 Product Table
       Week_id                    Product_id
       Period_id                 Product_desc
        Year_id




6. Enrich the dimension tables

   Return to the dimension tables and
    exhaustively add text-like descriptors
   No abbreviations should be used
   Important dimensions typically should have
    50 text-like attributes




                                                                           13
7. Choosing the duration of the
DW
   Measures how far back in time the fact table
    goes
   Very long fact table durations pose two kinds
    of problems:
       Difficult to get and interpret source old data (old
        files, old tapes)
       Old versions of important dimensions must be
        used instead of current ones




8. Tracking slowly changing
dimensions
       The operational data source that feeds
        dimensions changes: keys are kept but
        descriptive attributes change
       Three types of solutions:
    
         Overwrite the dimension record with new values
        Create a new additional dimension record
          using a new value of the surrogate key
        Create an “old” field in the dimension record to
          store previous attribute value




                                                              14
    9. Deciding query priorities and
    query modes
       Physical design issues:
           Physical sort order of the fact table
           Pre-stored aggregations
           Indexing
           ...




    Bibliografia

   (Livro) Data Mining: Concepts and Techniques, J. Han &
    M. Kamber, Morgan Kaufmann, 2001 (parte da Secção
    2.3)
   (Livro) The Data Warehouse Lifecycle Toolkit, R.
    Kimball, Wiley 1998 (Cap. 5, 6 e 7)
   (Artigo) Letting the Users Sleep Part 1 and 2, R.
    Kimball, DBMS – Dec. 1996 and Jan. 1997,
    http://www.dbmsmag.com/9612d05.html
    http://www.dbmsmag.com/9701d05.html




                                                             15

								
To top