Preciso resolver um exercício para uma empresa farmacêutica, eles me pedem para criar uma estrutura de banco de dados do zero a partir de algumas informações.
Porque quero que seja escalável e "à prova de futuro" decidi seguir a star/snowflakeestrutura. Por enquanto parece mais estrela do que floco de neve mas a ideia está aí. Tenho uma dúvida em particular sobre a tabela de fatos principal ( estudo ) e como representar o status da tabela de dimensões .
Cheguei a 2 opções:
- OPÇÃO 1: Estudo da Tabela de Fatos > Chave Estrangeira > Contrato da Tabela de Dimensões > Chaves Estrangeiras > Status da Tabela de Dimensões .
Assim, passamos por duas Tabelas de Dimensões para representar o Status na Tabela de Fatos. Eu vou fazer isso através de um JOINem um viewou qualquer outra coisa...
- OPÇÃO 2: Estudo da Tabela de Fatos > Chave Estrangeira > Status da Tabela de Dimensões .
Desta forma, vinculamos diretamente a Tabela de Fatos ( Estudo ) ao Status da Tabela de Dimensões .
Devo optar pela Opção 1 ou Opção 2 ?
Tenho medo de vincular muitas tabelas de dimensões à tabela de fatos. Esta é a primeira vez que tento criar uma estrutura de banco de dados.
Qualquer conselho é bem-vindo, qualquer sugestão é bem-vinda, especialmente de arquitetos de banco de dados experientes, mas também de amadores.
obrigada
EDIT: adicionando mais algumas informações
Obrigado @AntC por sua pergunta. Na verdade, este não é um cenário de Data Warehouse, o cenário é o de uma empresa farmacêutica que precisa de um novo software para rastrear seu ensaio clínico.
Mas é claro que os esquemas mais conhecidos são Star/Snowflake e não quero usar nenhum esquema hierárquico. Ao mesmo tempo, quero evitar formas como triângulo, diamante, círculo, porque mesmo que agora existam apenas 100 usuários que saibam como será esse banco de dados em 10 anos. A ideia é moldar algo para o longo prazo e na minha opinião a forma Estrela/Floco de Neve é escolhida também para aplicação normal até onde eu sei.
Na Opção 2
Status_Codeaparece como não chave em duas tabelas:Study,Contract. Mas a qual dessas entidades ela pertence? E quais são as cardinalidades relativas dessas entidades?Olhando para a Opção 1, o
Status_Codepertence aoContract; pode haver váriosStudys para um dadoContract.Portanto, se você adotasse a opção 2, causaria dor de cabeça ao OLTP: sempre que houver uma alteração em
StatusumContract, o processamento da transação precisará replicar essa alteração para todos osStudys, com um risco óbvio de ficar fora de sincronia. Isso é chamado de anomalia de atualização .Desnormalizar o modelo como a Opção 2 é legítimo em data warehouses, porque queremos relatórios rápidos. É imprudente em um modelo de dados orientado ao processamento de transações, devido ao custo de processamento e aos riscos de manter os dados em sincronia.
Assim, para uma aplicação com foco no processamento de transações, a Opção 1 é indicada. E sim , você criaria uma
JoinviewStudy>>Contract.Status