Conheça o diagrama ER (Entity Relationship), suas partes e o que costuma dar errado ao criá-lo.
Você já criou um modelo de banco de dados relacional? Ou talvez você esteja tentando criar seu primeiro? Você sabe (ou logo descobrirá) que traduzir problemas do mundo real para lógica de banco de dados às vezes pode ser bastante difícil.
Uma das ferramentas que podem ajudá-lo é o diagrama ER. A sabedoria comum de design de banco de dados afirma que quanto melhor for o diagrama ER, mais fácil será construir o modelo de banco de dados. Este item importante dá o tom para todas as frustrações ou sucessos futuros. Com um bom diagrama ER, criar um modelo de banco de dados relacional é bastante simples. É claro que erros podem ser cometidos em qualquer fase da modelagem do banco de dados. No entanto, ter um bom diagrama ER pode ajudá-lo a evitar alguns desses erros.
Então, vamos ver o que é o diagrama ER e como podemos evitar seus erros comuns.
O que é um diagrama ER?
“ER Diagram”, ou ERD, é a abreviação de Entity Relationship Diagram. Ele mapeia o problema a ser modelado, mas de forma estruturada que mostra as relações entre as entidades.
Os blocos de construção de um diagrama ER
Os diagramas ER consistem nos seguintes elementos:
- Entidade
- Relacionamentos
- Atributos de entidade ou relacionamento
O primeiro elemento do diagrama ER é a entidade . A entidade é um objeto ou ocorrência sobre a qual desejamos armazenar informações. Basicamente, é qualquer coisa sobre a qual podemos coletar dados. Por exemplo, podemos armazenar dados sobre funcionários, alunos, professores, compradores, produtos, departamentos, pagamentos, locais, etc.
Uma vez que temos entidades, é necessário criar relacionamentos . Um relacionamento mostra como uma entidade está conectada e associada a uma ou mais outras entidades.
O elemento final do diagrama ER é um atributo de entidade ou relacionamento . Um atributo é uma descrição de uma propriedade pertencente a uma entidade ou relacionamento. Os atributos têm valores. Alguns atributos para as entidades mencionadas acima podem ser:
- Funcionário, aluno, professor, comprador – ID, nome, sobrenome, data de nascimento, endereço, etc.
- Produto – ID, categoria, descrição, cor, número de série, etc.
- Departamento – ID, nome do departamento, chefe do departamento, número de funcionários, etc.
- Pagamentos – ID, data e hora, valor.
- Local – Cidade, CEP, região, país, continente.
Tipos de relacionamentos
Antes de entrarmos nos erros comuns encontrados em diagramas ER, é importante entender os possíveis tipos de relacionamento. A maioria dos erros de ERD são essencialmente relacionamentos definidos erroneamente entre entidades.
Existem três tipos de relacionamentos entre entidades:
- Um para um (1:1)
- Um para muitos (1:N)
- Muitos para muitos (M:N)
Relações de um para um (1:1)
O primeiro tipo de relacionamento é um para um , ou 1:1 . Nesse relacionamento, uma única instância de uma entidade pode ser conectada apenas a uma única instância de outra entidade (e vice-versa, é claro).
Digamos que temos a entidade aluno com os atributos nome e sobrenome . Também temos a entidade id com o único atributo id . A relação 1:1 significaria que um aluno pode ter apenas um número de identificação. Isso também significa que um número de identificação pode pertencer a apenas um aluno.
Essa relação é muito raramente vista em bancos de dados. Se apenas um ID puder ser conectado a apenas um aluno, não há necessidade de separá-los em duas entidades diferentes.
Veja um exemplo dessa relação:
Relações de um para muitos (1:N)
O tipo mais comum de relacionamento de banco de dados é um para muitos ou 1:N . Um relacionamento um-para-muitos significa que cada instância única de uma entidade pode ser conectada a várias instâncias de outra entidade. Isso também significa que cada instância da segunda entidade pode ser associada a apenas uma instância da primeira entidade.
Por exemplo, existe uma entidade comprador com os atributos id , nome e sobrenome . Queremos estabelecer uma relação com a entidade pagamento que tem os atributos id , data e valor . Esta é uma relação 1:N porque um comprador pode fazer um ou vários pagamentos. No entanto, um pagamento não pode ser feito por vários compradores; só pode ser feito por um comprador.
Aqui está o exemplo:
Essa relação também pode ser vista ao contrário. Nesta situação, é chamado de muitos-para-um ou N:1 . Claro, este não é um novo tipo de relacionamento. É o mesmo que 1:N, mas é visto na direção oposta.
Como exemplo, suponha que temos a entidade funcionário com os atributos id , nome e sobrenome . Queremos estabelecer funcionário relacionamento da entidade departamento que tem os atributos id e nome . A relação entre essas duas entidades é N:1. Isso significa que cada funcionário pode trabalhar em apenas um departamento, mas vários funcionários podem trabalhar no mesmo departamento.
Relações muitos-para-muitos (M:N)
Um muitos-para-muitos ou M:N relacionamento significa que cada instância da primeira entidade pode ser associada a mais de uma instância da segunda entidade. Isso também significa que cada instância da segunda entidade pode ser associada a várias instâncias da primeira entidade.
Vamos ver como isso funciona entre as entidades aluno e palestra . Digamos que aluno tem os atributos id , nome e sobrenome . A entidade palestra tem os atributos id e nome . Uma relação muitos-para-muitos pode ser interpretada da seguinte forma:um aluno pode assistir a uma ou mais aulas, enquanto uma aula pode ser assistida por um ou mais alunos.
Aqui está o diagrama para este exemplo:
Na modelagem de banco de dados, esses relacionamentos geralmente são divididos em dois ou mais relacionamentos 1:N ou N:1 pela introdução de novas entidades.
Erros típicos cometidos ao criar um diagrama ER
Muitos erros do diagrama ER se encaixam em uma dessas quatro categorias:
- Relações incorretas entre entidades
- Usando uma instância de entidade em vez de uma entidade
- Confundir um atributo com uma entidade
- Atributos complexos
Vejamos cada um individualmente.
Relações incorretas entre entidades
Os erros mais comuns ocorrem ao definir o relacionamento entre entidades . Geralmente não há erros em um relacionamento 1:1. No entanto, é muito fácil confundir uma relação 1:N com uma relação M:N. Isso geralmente decorre da não compreensão dos requisitos fornecidos pelo usuário final. É vital ter requisitos muito claramente definidos e uma compreensão profunda de por que o banco de dados é necessário e como ele será usado. Se criarmos um diagrama ER com dados insuficientes e compreensão incompleta, isso provavelmente resultará em relacionamentos entre entidades sendo definidos incorretamente.
Vejamos um exemplo. Se você estiver criando um banco de dados para um banco, provavelmente criará um diagrama ER com a entidade cliente tendo os atributos id , nome e sobrenome . Você também terá uma entidade chamada conta com os atributos id e digite . Se você não tem experiência no setor bancário, provavelmente pensará que sempre há um relacionamento 1:N entre o cliente e conta entidades, como mostrado abaixo.
Um cliente pode ter várias contas em um banco. No entanto, uma conta pode ser de propriedade de apenas um cliente. Isso é realmente verdade? Talvez seja, talvez não. Muitos bancos oferecem contas conjuntas que podem ser usadas por vários clientes. Você está criando um diagrama ER para um banco que oferece esse serviço? Se o banco não oferece contas conjuntas, você está certo:o relacionamento entre cliente e conta é 1:N. No entanto, se o banco oferece contas conjuntas, então a relação é M:N.
Usando uma instância de entidade em vez de uma entidade
Outro erro comum é usar uma instância de entidade em vez de uma entidade. Uma instância de entidade é uma ocorrência única de uma determinada entidade – ou seja, uma entidade que pode realmente ser um atributo de uma categoria maior.
Digamos que trabalhamos em uma empresa que aloca telefones celulares e laptops para determinados funcionários. Então, em nosso banco de dados, teríamos uma entidade chamada laptop com os atributos id e modelo e uma entidade chamada employee com os atributos id , nome e sobrenome , direita?
Há um problema aqui:um laptop na verdade não é uma entidade – também há telefones celulares para contabilizar. A solução é substituir a entidade laptop com uma entidade mais geral, como equipamento . Esta entidade pode ter os atributos ID , tipo , e modelo , como mostrado abaixo. O tipo pode consistir em valores como telefone , PC , comprimido , e laptop . Desta forma, não há necessidade de criar uma entidade separada para cada tipo de equipamento.
Você pode encontrar o exemplo aqui:
Confundir um atributo com uma entidade
O próximo erro comum é confundir um atributo com uma entidade. Digamos que decidimos criar uma entidade chamada employee que consistirá nos atributos id , nome , sobrenome , data_nascimento , id_departamento , nome_departamento e head_department . Essa entidade nos causará problemas quando estivermos criando um modelo de banco de dados porque consiste em muitos atributos que não definem exclusivamente essa entidade específica .
Lembre-se, definimos entidades como qualquer coisa sobre a qual podemos coletar dados. Com isso em mente, podemos ver que o atual funcionário entidade pode ser dividida em duas entidades:funcionário e departamento , como mostrado abaixo.
Atributos complexos
O último erro comum sobre o qual falaremos é incluir um atributo complexo em uma entidade. Em outras palavras, temos um atributo que deveria ser sua própria entidade .
Digamos que temos uma entidade chamada alunos que é definido pelos seguintes atributos:id , nome , sobrenome , data_nascimento , endereço e exam_passed . Aqui, exam_passed é um atributo complexo que consiste em mais de uma informação, ou seja, o ID e a data do exame e a pontuação do aluno. Deixar assim seria um erro. Em vez disso, devemos criar uma nova entidade fora deste atributo complexo . A nova entidade pode se chamar exames e consistem nos seguintes atributos:id , data , id_alunos , e pontuação .
Você pode encontrar o exemplo aqui:
Você recebeu alguma dica útil de diagrama ER?
Esses quatro tipos de erros são os mais comuns no processo de criação do diagrama ER. Claro, não há uma lista completa de erros típicos ou tipos de erros. Na vida real, muitos tipos de erros podem acontecer. A falta de planejamento, suporte técnico insuficiente e um processo de design de banco de dados apressado contribuem para seus próprios problemas. Se você já criou bancos de dados ou participou deles do lado comercial, provavelmente já experimentou alguns deles! Todas essas circunstâncias levam a vários erros, alguns dos quais são bastante únicos.
Você tem seu próprio exemplo de um diagrama ER não tão bom? Ou talvez haja alguns outros erros que você encontra com frequência? Por favor, deixe-me saber na seção de comentários.
