Como representar a chave estrangeira em um diagrama ER?

Diagramas ER foram originalmente usados apenas para representar o modelo ER. O modelo ER não usa chaves estrangeiras para representar relacionamentos. Ele usa linhas entre as caixas. As linhas têm algum tipo de indicador de cardinalidade em uma ou duas extremidades. Às vezes, um relacionamento é indicado separadamente por um diamante.

Hoje, mais da metade dos diagramas ER que flutuam são, na verdade, diagramas de um modelo relacional, e não de um modelo ER. Um modelo relacional possui as chaves estrangeiras incluídas nas tabelas e elas servem para implementar os relacionamentos que o modelo ER identifica. E um modelo relacional terá uma tabela extra, geralmente chamada de “tabela de junção” entre duas tabelas de entidade vinculadas por um relacionamento muitos-para-muitos. Esta tabela de junção contém duas ou mais chaves estrangeiras.

Existem muitas maneiras de representar um modelo relacional. Talvez o mais simples seja o “Diagrama de relacionamento” que o MS Access pode produzir a partir de um banco de dados completo. Isso será razoavelmente completo, se o construtor do banco de dados tiver identificado as chaves estrangeiras.

Existem muitas ferramentas que são mais sofisticadas do que o MS Access para fazer diagramas em uma escala maior. Alguns deles são usados antes de construir o banco de dados. Alguns são usados depois.

Comentários

• Atualmente estou apenas fazendo um diagrama em um papel. Você pode mostrar como as duas tabelas acima (na pergunta) podem ser representadas em um diagrama de relacionamento?
• Se você pesquisar em ” Diagrama ER Transações de clientes ” você obterá muitas imagens que mostram várias maneiras de fazer o que você deseja.

Ao desenhar diagramas ER, usei a seguinte convenção gráfica: Rotule as linhas de relacionamento com os nomes das colunas de chave estrangeira, assim:

Isso deixa claro qual coluna da tabela filho é a chave estrangeira para a tabela pai. A indicação do status da chave primária pode ser feita sublinhando o atributo em questão.

O que pode ser mais útil do que isso é uma convenção de nomenclatura que deixa claro qual é a chave primária de uma tabela (facilmente feito se você usar surrogate keys por convenção) e o que é uma coluna de chave estrangeira.

Alguns diagramas de modelo relacional também incluem um rótulo de participação de chave à esquerda dos nomes das colunas na lista de colunas (por exemplo, ” PK “, ” FK1 “, ” FK2 “, …) que pode ajudar especialmente se você tiver chaves compostas.

Comentários

• Esta convenção também foi publicada em algum lugar ou é apenas sua (boa) ideia?
• @Lorenz it ‘ é minha adaptação para um diagrama de relação de entidade física da versão da notação do pé do corvo ‘ s ( en.wikipedia.o rg / wiki / … ) publicado por James Martin ( en.wikipedia.org/wiki/James_Martin_(author) ) em seu livro Engenharia da Informação , que usava o nome do relacionamento como rótulo nos relacionamentos.Para mim, é ‘ uma extensão sensata do modelo lógico para o modelo físico.
• Mesmo que ajude, continua sendo uma ideia privada, não era totalmente limpar a partir da expressão “Eu usei”.

Eu prefiro este formato, usando “pés de galinha” para ilustrar as junções muitos-para-um

Comentários

• Eu também gosto de pés de galinha para diagramas ER. Para diagramas relacionais, prefiro a ponta de seta. observe que um pé de galinha vai no ” muitos ” final de uma linha, enquanto uma ponta de flecha vai no ” um ” final de linha.
• Existem apenas os símbolos FK / PK ausentes nas extremidades da linha neste gráfico aqui 🙂 Ainda assim, esta resposta de acompanhamento à primeira postagem do link de dlink ‘ obteve poucos votos em minha opinião. dlink ‘ O link postado anteriormente foi criticado, já foi mencionado no primeiro comentário da pergunta anterior por @MKSingh que havia perguntado;), MAS! parece que o link é melhor do que o declarado lá. Se você assistir ao vídeo oferecido em ” símbolos ERD físicos “, ele mostra exatamente como representar vários FK em um ERD, aqui está o link direto, vá para 7:28, youtube.com/watch?v=QpdhBUYk7Kk

Muitos anos depois, preste atenção às diferentes notações dos diagramas ER; portanto, a pergunta não é precisa o suficiente.

Dê uma olhada em todas as respostas em

https://stackoverflow.com/questions/48191228/is-erd-considered-a-kind-of-uml-diagram#48198083

e

Qual deles é um diagrama ER? . Uma resposta aqui afirma que a notação Chen é a ERD, enquanto a notação Crow Foot é considerada um EAD (Entity Attribute Diagram), consulte @JoshuaGuttman.

A notação Chen não mostra explicitamente as relações FK , como a resposta aceita já explica, enquanto outras notações podem fazer isso.

Se você pegar, por exemplo, a notação Crow Foot ou Baker “s, você pode pegar a ” resposta ” mais precisa de @dlink onde as linhas levam exatamente aos FKs. Então, ainda não está claro o que fazer com FKs compostos que levam a PKs compostos, e provavelmente por causa de que programas profissionais simplesmente não vinculam graficamente as terminações de linha com os FKs. Então, nomear é tudo o que você pode se referir, o que é suficiente de qualquer maneira se você seguir estritamente uma convenção de nomenclatura (como CustomerID para Customer.ID ou outras regras) . Veja, por exemplo, Visual Paradigma em https://www.visual-paradigm.com/guide/data-modeling/what-is-entity-relationship-diagram/

vp erd

Esta página, por LucidCharts tem um bom artigo sobre como deve ser o ERD.

Em Símbolos físicos ERD, mostra como representar as chaves.

[ https://www.lucidchart.com/pages/ER-diagram-symbols-and-meaning]

Comentários

• Bem-vindo dlink. Tente fornecer respostas completas que sejam mais do que apenas um link , caso contrário, elas podem ser removidas.