Verificação do desenho da base de dados/ Diagrama ERD
ficaria grato se pudesse dar uma vista de olhos no meu diagrama ERD, que está relacionado com a descrição:
A base de dados contém registos de pessoas (desde 1900). Cada pessoa pode ter mãe e / ou pai. As mulheres podem ter um marido e os homens podem ter um. esposo. As pessoas trabalham em empresas, que contêm nome e um presidente. Uma pessoa pode trabalhar em uma ou mais empresas, empregando em obrigatório contrato ou contrato de trabalho.
e o exemplo a pesquisa é: encontre a pessoa (nome e sobrenome) com maior número de grandchildrens.
e Abaixo está o meu diagrama ERD, mas não tenho a certeza sobre as partes mãe/pai e mulher/marido.
obrigado antecipadamente
1 answers
Seu "ERD", embora comumente chamado de tal, é realmente um diagrama de tabela. Um diagrama ER próprio tem de ser capaz de representar um modelo ER, o que significa que deve ser capaz de representar relações ternárias e superiores, entre outras coisas. Recomendo usar a notação do Chen para os diagramas das urgências. Isso não significa que eu seja contra diagramas de mesa - eles são usados apenas para propósitos diferentes. Diagramas ER para modelos conceptuais, diagramas table para modelos físicos. Entre eles estão diagramas relacionais para lógicas modelo.
O seu diagrama também não aplica muito bem a descrição dada. Considere "cada pessoa pode ter uma mãe e / ou um pai". A sua tabela relationship permite que um person seja associado a um número de relationship_types, mas não associa dois persons em papéis de pais e filhos. Uma melhor abordagem pode ser ter father e mother tabelas com parent_id e child_id campos que se referem a person_id, ou uma única Tabela parent com parent_id, child_id, relationship_type campos.
husband_id, wife_id Tal como acontece com as tabelas father e mother, isto não garante que apenas pessoas do sexo correspondente sejam registadas em cada papel. É possível fazer valer isso em ambos os casos criando tabelas disjuntas de subtipos para gêneros de person. No entanto, isso não é comumente feito (e hoje em dia, flexibilidade em seu modelo de dados é mais provável ser visto como uma vantagem do que um problema), e eu suspeito que pode ser exagero para o seu projeto.
([36]) o emprego é mais bem modelado. A questão principal há uma associação de um para um entre agreement_type e employment_condition. Presumo que {[15] } esteja destinado a gravar mandatory contract e employment contract. No entanto, com uma associação de um para um, não se pode ter dois ou mais empregados com um mandatory contract. Creio que cada agreement_type deve ser utilizável em múltiplos employment_conditions.
Também estou preocupado com a(s) Chave (s) de employment_condition. condition_id e agreement_name são ambos indicados como chaves estrangeiras (laranja) e parte da chave primária (ícone da chave). A que se refere condition_id e por que estão incluídos no PK? I seria de esperar que a combinação de person_id, company_id fosse suficiente para identificar uma relação entre muitas empresas e trabalhadores.
Da mesma forma, person_id em company está incluído no PK. Com base na descrição dada, esperava que company_id determinasse tanto o name como o presidente (person_id). BTW, eu sugiro que você mude o nome desse campo para chairperson_id para ser mais descritivo. Imagine se tivéssemos mais pessoas em papéis individuais - não poderíamos chamar cada campo, certo? É geralmente mais útil para nomear campos baseados em seu papel ao invés de seu domínio, embora os dois frequentemente coincidem.