O Modelo de Dados Entidade-Relacionamento , também chamado de ER , é um dos vários modelos de dados que você pode usar para raciocinar sobre seus dados.
Em particular, é um modelo de dados conceitual , pois não está vinculado a nenhuma implementação específica. Essa é uma tarefa deixada para o modelo de dados lógicos.
O Modelo de Dados ER é tão geral, tão alto nível, que pode ser implementado por uma variedade de tipos completamente diferentes de bancos de dados.
É ótimo porque você não pensa nos detalhes da implementação, mas pensa apenas nos seus dados e em como eles estão organizados . E ao fazer isso, você é forçado a analisar o problema de maneiras que não pensou antes.
Acho os diagramas ER ótimos para ajudá-lo a analisar um cenário em que os dados estão envolvidos.
O Modelo ER oferece as ferramentas para representar, usando uma notação gráfica, todos os dados que você precisa modelar, as relações entre os diferentes tipos de dados e as informações associadas a eles.
Existem 2 itens que compõem um Modelo ER:
- as entidades
- as relações
Entidades são tipos de dados, como itens ou pessoas, que possuem propriedades comuns.
As relações são as relações entre entidades.
Deixe-me dar um exemplo, vamos falar sobre livros e seus autores. Temos 2 entidades :
- livro
- autor
Um livro específico é uma instância da entidade livro.
Como temos 2 entidades, temos 2 relações entre eles. Uma é a relação entre um único livro e a entidade autora. Uma é a relação entre um único autor e a entidade livros. Se pensarmos bem, temos:
- um livro tem um autor
- um autor pode escrever muitos livros diferentes
A notação visual para entidades
Dado este exemplo simples, podemos começar a introduzir a notação visual que nos ajudará a criar o Modelo de Dados ER do nosso cenário.
Nota:Existem muitas maneiras diferentes de desenhar diagramas ER. Vou usar aquele que, na minha opinião , é mais visual e faz mais sentido.
As entidades são representadas como retângulos, com algum texto para identificá-las:
A notação visual para relações
A relação entre entidades é representada, em sua forma mais básica, usando uma linha que conecta duas relações, e um losango com algum texto para identificar o tipo de relação:
Note que eu não criei 2 relações “livro tem autor” e “autor escreveu livro”. Fiz uma única relação “de autoria” entre um Livro e um Autor.
Cardinalidades
Uma vez que tenhamos uma relação, devemos agora indicar os números envolvidos. No momento, temos muitas perguntas:
- Quantos autores um livro pode ter?
- Um autor pode escrever vários livros?
- Um autor precisa escrever pelo menos um livro para ser chamado de autor?
- Um livro pode ser escrito por vários autores?
- Pode existir um livro sem pelo menos um autor?
Todas essas são boas perguntas a serem feitas e, neste caso, acho que as respostas são bastante óbvias. E quando a resposta não for óbvia, você pode pensar no problema e adicionar suas próprias restrições.
Existem várias maneiras de indicar visualmente as cardinalidades em um diagrama. Alguns preferem alterar a forma da linha quando ela se vincula a uma entidade.
Eu prefiro números, que tornam as coisas mais claras:
Os números acima significam o seguinte:um livro pode ser de autoria de 1 ou mais autores.
n significa qualquer número de elementos. E um autor pode ter escrito de 0 livros (talvez esteja escrevendo um agora) até um número infinito de livros.
O primeiro é chamado de relação zero-para-muitos . A segunda é uma relação um-para-muitos .
Também podemos ter:
- relacionamentos individuais
- relacionamentos muitos-para-muitos
- relações zero para um
Atributos
Cada entidade pode ter um ou mais atributos.
Digamos que usaremos o relacionamento acima em uma livraria. Cada autor tem um nome, uma biografia, uma URL de site.
Cada livro tem um título, uma editora, um ano de publicação, um ISBN. O editor também pode ser uma entidade, se quisermos. Mas também podemos defini-lo como um atributo de um livro.
É assim que podemos representar as informações acima:
Atributos do identificador
As entidades devem ser identificadas por uma chave única. A entidade do livro pode ser identificada exclusivamente pelo atributo ISBN. Cada livro tem um único ISBN (considerando que não representamos um único exemplar de um livro, mas um “título” do livro).
Identificamos os atributos de chave primária subjacentes a eles:
O autor, por outro lado, não possui identificador exclusivo no momento. Dois autores podem ter o mesmo nome.
Devemos, portanto, adicionar um atributo de chave exclusivo. Por exemplo, um
id atributo:
Os atributos identificadores podem abranger vários atributos.
Por exemplo, o ID do passaporte e o país do autor identificam exclusivamente a pessoa e podem substituir o
id atributo que adicionamos:
Qual escolher? É uma questão do que faz mais sentido em sua aplicação. Se estamos modelando uma livraria, não podemos esperar ter o ID do país e do passaporte de todos os autores de livros. Portanto, usaremos um
id aleatório vamos escolher e associar a cada autor. Atributos de relação
Os atributos não são exclusivos das entidades. As relações também podem ter atributos.
Considere que precisamos modelar uma biblioteca. Além das entidades livro e autor, agora apresentamos a entidade leitor , pessoa que empresta o livro para lê-lo. Tomamos seu nome e número de cartão de identificação quando o emprestam:
Mas ainda perdemos informações. Precisamos saber quando a pessoa emprestou o livro e a data em que o devolveu, para que possamos armazenar as informações sobre toda a história de um determinado livro em nossa biblioteca. Esta informação não pertence nem ao livro nem às entidades leitoras; pertence à relação:
Entidades fracas
Falamos sobre chaves primárias acima e como a ajuda identifica exclusivamente uma entidade.
Algumas entidades dependem de outras entidades para sua existência e são chamadas de entidades fracas .
Suponha que precisamos modelar pedidos para uma loja online.
Para cada pedido, armazenaremos o id do pedido, que começa em 1 e aumenta com o tempo, a data e hora em que foi feito e as informações sobre o cliente, para sabermos quem cobrar e para onde enviá-lo.
Então também precisamos saber o que eles pediram. Criamos uma entidade fraca “item pedido”, que representa cada item no carrinho no momento da finalização da compra.
Esta entidade guardará o preço do artigo no momento da finalização da compra (assim quando alterarmos o preço dos produtos em promoção, não afetará as encomendas já efetuadas), a quantidade de artigos encomendados e as opções escolhidas. Digamos que vendemos camisetas, portanto precisamos armazenar a cor e o tamanho da camiseta encomendada.
É uma entidade fraca porque uma entidade de item ordenado não pode existir sem uma entidade de pedido.
Relações recursivas
Uma entidade pode ter uma relação recursiva consigo mesma. Suponha que temos uma entidade pessoa. Podemos modelar o relacionamento pai-filho desta forma:
Uma pessoa pode ter de 0 a n filhos, um filho tem 2 pais (considerando o cenário mais simples).
Relações ISA
ISA significa IS-A e é uma maneira de modelar generalizações no modelo ER.
Usamos para agrupar entidades semelhantes sob um guarda-chuva comum. Por exemplo, um autor e um leitor, no caso do exemplo de livros e bibliotecas, podem ser generalizados usando uma entidade pessoa.
Ambos têm um nome, então extraímos o nome até a entidade pessoa, e apenas gerenciamos as peculiaridades de ser autor ou leitor na entidade correspondente:
Relações não binárias
Nem todo relacionamento é estritamente binário. Vamos fazer um cenário de aula.
Hoje, às 10h, acontece uma aula em uma sala da escola, com um professor, conversando com uma turma sobre física.
Então, uma aula é dada em um determinado horário do dia, envolve uma matéria, um professor, uma aula e uma sala.
Podemos modelar assim:
