Início / dba / Perguntas / 151547
Accepted
Mattia Nocerino
Asked: 2016-10-07 00:03:17 +0800 CST

"Dimensões do tipo de medida" na tabela de fatos "Instantâneo acumulado"

  • 772

Eu tenho uma tabela de fatos de instantâneo acumulando que rastreia a entrada e saída de contêineres em um terminal .

Os containers podem entrar e sair de 3 formas diferentes , então pensei em criar uma tabela de dimensão específica que listasse essas 3 formas possíveis ( trem, embarcação ou caminhão ).

Então li este artigo que basicamente diz que essa técnica está errada, mas não consigo entender o porquê.

Primeiro artigo:

Às vezes, quando uma tabela de fatos tem uma longa lista de fatos esparsamente preenchida em qualquer linha individual, é tentador criar uma dimensão de tipo de medida que reduza a linha da tabela de fatos a um único fato genérico identificado pela dimensão de tipo de medida. Geralmente, não recomendamos essa abordagem. Embora remova todas as colunas de fatos vazias, ele multiplica o tamanho da tabela de fatos pelo número médio de colunas ocupadas em cada linha e torna os cálculos intracolunas muito mais difíceis. Essa técnica é aceitável quando o número de fatos potenciais é extremo (na casa das centenas), mas menos de um punhado seria aplicável a qualquer linha da tabela de fatos.

Entendo que, se uma " dimensão de tipo de medida " for implementada para uma tabela de fatos de transação, ela poderá criar problemas como este outro artigo diz, mas não consigo ver nenhuma desvantagem se usada para um fato instantâneo acumulado .

Segundo artigo: (algumas desvantagens de implementar uma "Dimensão de tipo de medida")

  1. [...] Se formos com uma "Dimensão do tipo de medida", perderemos essa capacidade analítica. Se uma medida não for compatível com as outras medidas, não podemos somá-las.
  2. [...] Quanto mais passos nosso SQL precisar executar para produzir um relatório, mais lento será o relatório.
  3. [...] Na ferramenta de BI, se você não colocar o filtro do tipo de medida, você corre o risco de o usuário ficar com “informação lixo”. Do ponto de vista da usabilidade, esse design é um lixo.

Resposta à resposta de Mark Storey-Smith

Muito boa abordagem, eu nunca teria pensado nisso.

Outra coisa: toda entrada e saída de veículo que traz contêiner para dentro do terminal tem um identificador único que me dá outras informações como: previsão de chegada do veículo, chegada efetiva, se é embarcação o cais, se é caminhão o pedágio e muitas outras informações...

Estas são 3 tabelas de fatos diferentes e devem ser vinculadas de alguma forma à tabela de fatos do contêiner.

Eu pensei que o ID da viagem é um degenerate dimension, então ele iria diretamente para a tabela de fatos do contêiner. Então, minha dúvida é: devo adicionar 6 campos diferentes na tabela de fatos do contêiner (vessel_voyage_in_key, Vessel_voyage_out_key, train_voyage_in_key, train_voyage_out_key, truck_voyage_in_key, truck_voyage_out_key) ou apenas 2 outros campos (voyage_in, voyage_out) que se vinculam dinamicamente às várias tabelas de viagem?

Espero que minha dúvida tenha sido esclarecida, obrigado.

database-design data-warehouse

1 respostas

  1. Best Answer

    Acredito que a orientação esteja se referindo a uma ampla tabela de fatos em que a maioria dos valores de medida é nula:

    CREATE TABLE dbo.SparseFact
(
    Dim1Key     INT NOT NULL
    , Dim2Key   INT NOT NULL
    , Dim3Key   INT NOT NULL
    , Dim4Key   INT NOT NULL
    , Dim5Key   INT NOT NULL
    , Value1    INT NULL
    , Value2    INT NULL
    , Value3    INT NULL
    , Value4    INT NULL
    , Value5    INT NULL
    , Value6    INT NULL
    , Value7    INT NULL
    , Value8    INT NULL
    ..
    , Value101  INT NULL
    , Value102  INT NULL
    , Value103  INT NULL
);

    A sugestão é que algumas pessoas vejam todos os nulos e decidam fazer isso:

    CREATE TABLE dbo.DontDoThisFact
(
    Dim1Key             INT NOT NULL
    , Dim2Key           INT NOT NULL
    , Dim3Key           INT NOT NULL
    , Dim4Key           INT NOT NULL
    , Dim5Key           INT NOT NULL
    , MeasureTypeKey    INT NOT NULL
    , Value             INT NOT NULL
);

    Não é bom.

    Em seu cenário, acho que estaria olhando para algo assim, que é muito diferente do cenário descrito nos artigos que você mencionou.

    CREATE TABLE dbo.InventoryFact
(
    ContainerKey        INT NOT NULL
    , TransportTypeKey  TINYINT NOT NULL
    , EntryDateTime     DATETIME NULL
    , ExitDateTime      DATETIME NULL
);

CREATE TABLE dbo.TransportType
(
    TransportTypeKey    TINYINT IDENTITY(1,1) NOT NULL
    , EntryTransport    CHAR(10) NOT NULL
    , ExitTransport     CHAR(10) NOT NULL
);

INSERT
    dbo.TransportType
SELECT
    EntryTransport
    , ExitTransport
FROM
    (
    SELECT EntryTransport = 'Train'
    UNION
    SELECT EntryTransport = 'Truck'
    UNION
    SELECT EntryTransport = 'Vessel'
    UNION
    SELECT EntryTransport = 'N/A'
    UNION
    SELECT EntryTransport = 'Unknown'
    ) en
CROSS JOIN
    (
    SELECT ExitTransport = 'Train'
    UNION
    SELECT ExitTransport = 'Truck'
    UNION
    SELECT ExitTransport = 'Vessel'
    UNION
    SELECT ExitTransport = 'N/A'
    UNION
    SELECT ExitTransport = 'Unknown'
    ) ex;

    Para as perguntas adicionais...

    Eu acrescentaria ExpectedEntryDate, ExpectedExitDateao Container/InventoryFact. Com menos certeza, sem visibilidade de todos os elementos de dados, eu provavelmente colocaria EntryVoyageIde ExitVoyageIdem uma dimensão de lixo separada em uma linha junto com quaisquer outros itens de dados degenerados (identificadores para o caminhão, trem, etc.).

    Eu adicionaria 3 novas dimensões para VesselVoyage, TruckVoyagee TrainVoyage6 chaves Voyage (entrada/saída) a este único fato (são 6 novas chaves, não 6 linhas adicionais). Você então tem a opção de colocar Docke Tollboothna dimensão Voyage apropriada. Se você mantiver os dados genéricos nessas dimensões ( VesselFlag, TruckCapacity) e os específicos em uma dimensão de lixo ( VesselName, VesselMMSI) eles não explodirão de tamanho.

    • 3

relate perguntas