Aprendendo o design de diagramas de relacionamento com entidades

Olá. Este artigo é dedicado a um dos modelos de design mais populares e familiares - ER ( Entity Relationship ), proposto por cientistas no campo da ciência da computação - Peter Chen, em 1976.


No decorrer do artigo, em linguagem simples, usando exemplos simples da vida, desenvolveremos versões diferentes do diagrama que dependerão do tipo de conexão. Vamos começar!

Design Orientado a Objetos

Antes de mais, gostaria de dizer algumas palavras sobre OOP (Programação / Design Orientado a Objetos) para que não haja problemas com a compreensão do paradigma do próprio diagrama. É mais conveniente para mim abstrair este modelo com o princípio de POO, onde a essência é o objeto, os atributos são suas características e as conexões são um pouco intermediárias (em alguns casos, como método).

Início rápido

A principal vantagem do modelo de design do Entity Relationship é que ele é universal. Você pode criar um banco de dados (bancos de dados), a operação de um programa, os princípios de interação etc.

O que você precisa saber no início do estudo?

- Você precisa saber desde o início que o trabalho principal é realizado sobre a relação de essência e comunicação. Para uma percepção mais fácil, vale lembrar que a essência é um substantivo que está em um retângulo e a conexão é um verbo que está em um losango. Aqui está um exemplo:



Eu acho que você entende o que é o quê. Nosso programador ensina Python. Parece que tudo é lógico. Mas aqui, apenas, quais são essas unidades no exemplo?

- Este é um indicador do tipo de conexão! Neste exemplo, o tipo de conexão é Um para um:

$$

$$1: 1$$

Voltaremos aos tipos de comunicação, mas um pouco mais tarde, e agora precisamos analisar mais MAS:
- O gráfico deve ser lido nas duas direções. Se você ler da esquerda para a direita, tudo será lógico, como foi dito anteriormente, mas, pelo contrário ... pensaremos mais algumas vezes sobre o que é a lógica. De fato, está escrito assim e está certo! Este é apenas um dos recursos deste modelo, que às vezes pode ser confuso. No entanto, nada impede que você, como muitos, no lado da unidade, adicione uma seta, como no exemplo abaixo:



PS Espero que você esteja interessado. Você pode criar esses diagramas no editor de diagramas - Dia.

Atributos

Então, temos um programador, mas não sabemos nada sobre ele ... Sem o qual um programador não é um programador?
- Sem atributos!

Vamos complementar o nosso exemplo:



Sim, os atributos realmente não distinguem nosso programador de uma pessoa comum ... mas, no futuro, iremos corrigi-lo com novos atributos! Na minha opinião, o atributo é COLUMN (coluna) na tabela Banco de Dados.

Os atributos estão vazios

Se não for necessário indicar um sobrenome na tabela do seu banco de dados (o atributo será opcional), o atributo deverá consistir em duas formas ovais: externa e interna (dentro da qual o nome do atributo).

Identificando atributos

Você pode ver um sublinhado do nome do atributo no diagrama - isso é normal. Você não deve ter medo disso, talvez seja apenas um atributo de identificação. Ou seja, é um atributo que sempre deve ser preenchido, necessário (chave primária). Como um exemplo - o id bem conhecido.

Bem, agora precisamos fornecer ao programador conhecimento (que linguagens, tecnologias ele conhece).
"Mas não listaremos imediatamente com cada atributo separado os componentes de seu conhecimento?"
É isso mesmo, usaremos um atributo composto ( um atributo que consiste em atributos do componente)! Quero observar que os atributos-componentes também podem ser compostos. A única questão é como você o implementará.

Tipos de Comunicação

Ótimo. Fomos capazes de descobrir isso. Agora considere os demais tipos de comunicação!

Vamos continuar com o tipo de conexão - um para muitos:

$$

$$1: N$$

Deixe-me mostrar um exemplo:



Agora nosso programador também está estudando Perl. Nada mal.
No entanto, quero observar que o exemplo mencionado acima é apenas uma exceção, a fim de mostrar claramente qual é o relacionamento, porque pode haver mil ramos, o que seria tolo de desenhar. No futuro, retornaremos a um registro abreviado e correto, e vale a pena lembrar esse padrão frágil, para que haja uma idéia geral do que é o quê. Espero ter conseguido explicar a você o que o tipo de conexão “Um para muitos” representa.
* A proporção de uma entidade para várias e vice-versa *

Antes de continuar estudando os tipos de links, você deve descobrir que os atributos também existem nos links .
Não vou mostrá-lo como um exemplo - talvez, possa ser entendido sem problemas, em palavras. Imagine que você tem uma conexão de transação. Suponha que no seu projeto você precise salvar todas as informações sobre as transações salvas, seja em um arquivo ou em um banco de dados, isso não importa. Você precisa economizar tempo, exceções (erros que ocorreram) e outras coisas. No nosso caso, todos os itens acima são atributos que pertencerão à conexão. Esses atributos também podem ser compostos, identificando, opcionais. A questão está apenas em implementação. Vamos continuar.

O último tipo de conexão permanece - para muitos:

$$

$$M: N$$

Como sempre, mostrarei a você por exemplo, mas não com o Programador, mas pelo exemplo da relação do Espectador com o Filme, em qualquer serviço para assistir filmes:



Há duas questões controversas. Vamos começar.

Primeiro:
- Por que a comunicação se parece mais com uma entidade?

Para simplificar o relacionamento do tipo "Muitos para muitos", entidades intermediárias são usadas .

"Por que não há galhos?"

- O visualizador pode se inscrever em muitos filmes.
- Os filmes podem ter muitos espectadores que os assinam.

Agora, vamos considerar outra maneira de implementar o relacionamento Muito para Muitos, que será um pouco mais difícil de escrever, mas talvez mais compreensível para quem não conhece entidades intermediárias:



Como você deve ter notado, neste exemplo existe um tipo de conexão “Um para muitos” e até vários.
Isso é verdade e fácil de explicar. O fato é que o tipo de conexão “Muitos para muitos” é igual a duas comunicações “Um para muitos”.

$$

$$M: N = 1: N + N: 1$$

Você provavelmente está interessado em saber por que nós, entre a conexão e a entidade, temos duas arestas.
Isso já é um pouco mais difícil de explicar. Leia com atenção.
O fato é que existem conexões opcionais e obrigatórias . Lembre-se da identidade:

Conexões opcionais criam participação parcial, enquanto as obrigatórias criam participação total.

- O que é participação parcial e total?

A participação parcial também é uma das exceções, um pouco semelhante a um atributo opcional, depende apenas da entidade. Imagine a foto. Existem duas entidades:
Comprador e produtos. Tipo de conexão - Um para muitos.
Eles têm uma conexão comum - compras. Mas precisamos entender outra coisa. Sem o qual o comprador não é o comprador?
- Sem pelo menos uma compra!
Este caso é um representante de uma conexão parcial, porque oferecemos a opção "Comprar e se tornar um comprador ou recusar". Nesse caso, teremos uma borda entre o link "Compras" e a entidade "Produtos". Agora considere a participação total.

A participação plena é o caso quando não há escolha. Nosso programador continuará sendo um programador, mesmo que ele não aprenda nada, devido ao fato de fixarmos no diagrama que ele deve aprender algo e não pode haver exceções. Corrigimos esse negócio com duas arestas. O tipo de participação depende de como você projeta, se a amostragem é necessária no estágio de comunicação.
Isso está feito. Nós continuamos.

Lembre-se do exemplo “Um para muitos”, onde após o link “Ensina” havia nomes de YP (Linguagens de programação), o que levou a um grande número de ramificações, porque não era correto em termos de escrita. Basta pensar, porque não precisamos fazer ramificações para cada PL. Podemos simplesmente criar uma entidade “Linguagem de programação”, na qual colocamos os atributos que serão responsáveis ​​por seu nome, idade, poder e muito mais. Eu acho que você entende. Eu aconselho você a usar a entrada abreviada "Muito para muitos".

Entidades fracas

Considere o conceito final.

Imagine que você tenha uma tabela "Pai" e "Filho", respectivamente, as mesmas entidades no diagrama. Um pode existir sem o outro? Eu acho que não. Tanto em biológico como em geral lógico.

Essência fraca: não pode haver maçã sem uma macieira

.

Neste exemplo, a entidade "Filho" é uma entidade fraca.

Entidades fracas são aquelas que não podem existir sem outra entidade.

Criamos a entidade “Filho”, na esperança de que os Pais / Pais não tenham filhos com o mesmo nome; caso contrário, nossa entidade, que pode ser uma tabela no banco de dados, dificilmente pode ser chamada de Normalizada (uma tabela na qual as regras de Automação de Dados e existe um identificador de chave primária), porque não podemos distinguir entre crianças.

No entanto, esses casos ocorrem, mas você pode corrigir isso adicionando um atributo adicional. Nesse caso, o atributo "Nome" é o que cria uma situação semelhante, e é chamado o componente principal de uma entidade fraca . O nome de tais atributos, em ovais, é sublinhado com uma linha pontilhada, e a essência e a conexão são colocadas em figuras adicionais nas quais são compostas.

Vou apresentar isso a você como um exemplo:

Conclusão

Concluindo, quero dizer que um dos trabalhos cooperativos fundamentais fundamentais é uma boa explicação das tarefas, uma boa apresentação do produto que precisa ser desenvolvido e é isso que os modelos de design ajudam. O relacionamento da entidade é um modelo de design popular há décadas. Ele permite criar gráficos elegantes que, com a abordagem correta, podem ser complementados e modificados no futuro. Aproveite o tempo para aprender. Obrigado pela atenção!

Fontes

- Autoria do livro "MySQL Guide":
Seyed M.M. Tahagghoghi “Saied”, Hugh E. Williams
- pt.wikipedia.org/wiki/Entity –relationship_model