Como devemos montar a chave primária da tabela Fato?

Oii Ana, tudo bem?

Eu não entendi bem a sua dúvida.

O problema é que não conseguimos montar esse conjunto como chave primária, pois não é.

Aqui você está dizendo sobre um projeto real que está fazendo/participando? O porque não podem fazer dessa maneira?

Bom, para te ajudar a decidir isso, temos dois tipos de chaves primárias:

Natural Key, é uma coluna que já existe na tabela, de um valor de negócio que pode servir como chave primária.

Surrogate Key, é uma coluna com um número criado, sem valor relevante para seu negócio, que pode servir como primary key pois se trata de um índice criado especialmente para isso.

Até aqui, ok certo? O importante é que todos as chaves primárias da fato precisam ser também as chaves primárias das tabelas com o qual tem relações(FKs).

Então acredito que a estratégia 2 e 3 estejam foram de cogitação. A melhor opção parece ser a 1.

Espero ter ajudado de alguma forma. Qualquer coisa vamos conversando :)

Oi, Maria. Tudo em Paz e espero o mesmo para você.

Desculpa mesmo, vou melhorar...

No curso, o exemplo utilizado força a chave primária da tabela fato ficar assim: ID_Cliente, ID_Fabrica, ID_Produto, ID_Tempo, ID_Vendedor.

Desta forma, a cliente Ana não poderia comprar o mesmo produto da mesma fábrica no mesmo dia com o mesmo vendedor.

Então, eu não poderia montar a chave primária da tabela Fato apenas com esses campos. Precisaria de uma das alternativas colocadas acima, que irei repetir aqui para me ajudar no texto, certo.

1. Incluir mais um campo para ser "juntado" aos demais campos e, assim formar nossa PK;
    (ID_Cliente, ID_Fabrica, ID_Produto, ID_Tempo, ID_Vendedor, ID_Contador). 
    . Como não tenho um campo que identifique a venda de forma única, preciso colocar um contador qualquer.
    . Acho que essa ideia não é muito boa, pois a chave fica muito grande, causando baixa performance e teria que ficar calculando esse contador para cada tupla igual (performance ruim na montagem). 
2. Incluir um campo inteiro para ser sua PK.
    (ID_Fato)
    . Colocaria todos os campos para serem apenas chaves estrangeiras e criaria uma PK com apenas um campo que poderia ser auto incremento.
    . Acho que essa é a melhor ideia, pois acho que fica tudo no canto certo e acho que teria a melhor performance.
3. Criar uma tabela sem PK.
    . Sem PK.
    . Sou totalmente contra a ideia de criar tabelas sem PK. Para mim, tem muitos problemas em fazer isso. Performance baixa, não consigo identificar uma tupla de forma única.
    . Mas pesquisando, vi que existem muitos que indicam essa forma de criação. Eles dizem que a tabela fato deve ficar sem PK.

Bom... mas isso é o que penso. Como esse mundo BI é muito novo para mim, queria abrir uma discursão para, realmente, encontrar a melhor saída. Como funciona a performance em um cubo??? É melhor ter a fato sem PK ou com PK?!? É melhor ter as chaves estrangeiras da fato como PK ou não?!?

Espero que tenha explicado melhor.

Muito obrigada!

Oi, Maria...

Vi agora que não posso criar campos calculados como sequenciais e auto incremento para a tabela Fato, pois não serve para nada. Preciso de alguma forma de identificar a tupla da Fato de forma única. Então preciso de algum campo da tabela de Vendas que faça isso. Certo?

Então, minha dúvida ficou entre colocar todos esses campos como PK ou não.

Grata!

Oi Ana, eu estou bem, obrigada.

De toda forma, uma tabela não pode ficar sem a PK, não acredito que seja uma boa ideia. E o cubo, querendo ou não ele vai repetir informações, pois é um banco de dados multidimensional e desnormalizado, para facilitar as consultas. Em quase todos lugares que leio sobre BI, a maioria dizem que o ideal é ter as PKs das dimensões relacionada a fato como PK da fato.

E como disse, um campo autoincremento numa fato realmente serve para nada.

Quais são os campos em sua tabela de vendas? Para que possamos ver um campo legal para poder colocar como PK da fato.

Joia, então.

Não tenho muita dificuldade em encontrar um campo para colocar na Fato e tornar as tuplas únicas. Por exemplo, basta colocar a PK da tabela de vendas para a tabela fato. Outra ideia é deixar os campos de valores já sumarizados. E essa é a ideia certa, né?!?

Então, chegamos a melhor escolha.

Falando de modelo estrela, colocar todas as IDs das dimensões para ser a PK da Fato. Caso não seja suficiente, procura quem pode ser adicionado na PK para tornar as tuplas únicas. Pronto!!!

Inclusive busquei mais um pouco e achei, no livro do Ralph Kimball, esse trecho: "A tabela Fato geralmente tem sua própria chave primária composta de um subconjunto das chaves estrangeiras".

Muito obrigada!