Banco de dados - Parte 1: Diagrama Entidade x Relacionamento (DER)
Quando se constrói o banco de dados de um sistema, é necessário ter um planejamento, e quanto maior o tempo despendido para criar um bom modelo de dados, menor será o tempo necessário para fazer futuras manutenções.
Ao terminar de ler este post, tem a continuação na parte 2.
Imagine a construção de um novo sistema para uma pequena empresa que tenha apenas uma sede. Seria normal para este caso criar um cadastro da empresa relacionado a diversos outros registros, como nota fiscal, estoque, etc. É possível fazer neste caso, uma modelagem baseada na “fotografia atual” desta empresa, mas se no futuro, esta empresa vir a abrir filiais, logo será necessário alterações no banco de dados para criar registros específicos das filiais e seus vínculos. Se esta situação tivesse sido pré-visualizada, não haveriam problemas para os novos cadastros e tempo de manutenção para adaptações no banco de dados para a nova necessidade.
Lógico que nem tudo é possível prever, pois ao definir os requisitos de um novo sistema é comum não se ter noção de todas tarefas necessárias que precisam ser realizadas, no entanto, é um engano pensar que já se sabe tudo por experiências anteriores ou por falta de tempo para um planejamento mais detalhado. O objetivo de se possuir um estudo e uma modelagem do banco de dados é justamente para minimizar este tipo de problema. Nessa fase de construção deve-se saber o que é necessário armazenar.
O processo de modelagem de um banco de dados, pressupõe três fases distintas e sequências:
A etapa de Modelo Conceitual de Dados é a análise e modelagem utilizando Entidade e Relacionamento e normalização de dados, a Entidade x Relacionamento pode ser apresentada de duas formas, como MER (Modelo Entidade x Relacionamento) e DER (Diagrama Entidade x Relacionamento). A etapa de Desenho do Banco de Dados são as definições de tabelas, index, views e etc. A etapa de Criação do Banco de Dados é onde realmente ocorre a criação do banco de dados.
Diagrama Entidade x Relacionamento (DER)
A modelagem de um banco de dados trata-se de uma representação das necessidades do sistemas e do que será armazenado. Este modelo de dados é composto por entidades e relacionamentos, será apresentado neste artigo somente o DER. Abaixo, algumas das vantagens de fazer uma modelagem com base em Entidade x Relacionamento:
- Documenta a necessidade de um sistema.
- Os usuários podem entender o modelo.
- Facilita a integração entre sistemas inter-relacionando diversos modelos.
- Linguagem universal, um modelo de dados não está vinculado a um banco de dados específico, mas as necessidades do sistema independente da implementação.
Caso de estudo
Para estudo e construção do modelo, será utilizado um catálogo de CDs.
Um dos problemas relacionados a um banco de dados, é a redundância de informações. Sempre que existir informações redundantes, não sabemos exatamente em qual informação confiar. No exemplo demostrado na imagem acima, é possível claramente ver as repetições de informações. Imagine que na segunda linha fosse alterado o nome do CD para Mais ou Menos. Qual informação estaria correta, Mais do Mesmo ou Mais ou Menos? É exatamente por este motivo que o banco de dados não deve possuir redundâncias, sem contar também que isso traz vantagem relacionada ao espaço de armazenamento, evitar redundância diminui o tamanho de um banco de dados.
Bom, neste exemplo podemos ver alguns dados se repetindo, o nome do CD e o nome do Autor, mas será adicionado outras informações para ter um caso de exemplo com um pouco mais de informações, será utilizado os dados do CD (código do CD, nome do CD, nome da gravadora e preço) e as músicas (número da faixa, nome, autor(es) e tempo). Pensando dessa forma, bastaria adicionar o código do CD nas músicas e teríamos uma relação entre o CD e as músicas, no entanto apenas isso não é suficiente para se conseguir ter um bom modelo de dados.
Convenção para utilização de diagramas
O diagrama é representado por uma caixa de qualquer dimensão com um nome único que representa uma entidade do sistema. Uma entidade do sistema normalmente representa um objeto do mundo real, ou quando não é, contém informações relevantes, no modelo físico de um banco de dados uma entidade é uma tabela. As bordas dessa caixa não possuem regras, podem ser arredondadas ou não. No diagrama deve ser separado os atributos do código da entidade. Esse código é um código único para identificar cada entidade, no banco de dados físico esse código é chamado de chave primária, os atributos da entidade são as informações básicas que qualificam ou descrevem características, no modelo físico do banco de dados esses atributos são chamados de campo ou coluna.
Entidades podem ser identificadas examinando substantivos, informações relevantes ao sistema, verificando se cada item candidato a ser uma entidade possui um identificador único e se possui alguns atributos.
Convenção para utilização de relacionamentos
Quando existirem duas entidades que possuem alguma ligação, como por exemplo a música e o autor da música, dizemos que existe um relacionamento entre elas. Podemos utilizar o seguinte esquema para identificar relacionamento entre entidades:
- Cada entidade1 { deve ter ou pode ter } relacionamento { uma vez ou uma ou mais vezes } entidade2
Utilizando o esquema acima, com os dados proposto podemos afirmar que:
- Cada CD deve ser gravado por uma única gravadora.
- Cada gravadora pode ter gravado um ou mais CDs.
- Cada autor pode ter escrito uma ou mais músicas.
- Cada música pode ser escrita por um ou mais autores.
- Cada música pode ser gravada em um ou mais CDs.
- Cada CD deve conter uma ou mais músicas.
- Cada CD pode se indicado por um ou mais CDs.
- Cada CD pode indicar um único CD.
Nota-se que normalmente cada relacionamento contém um nome, como um verbo, a opcionalidade (deve ou pode) e um grau de relacionamento (uma vez ou um ou mais), que é chamado na modelagem de dados de cardinalidade.
A convenção para utilização dos relacionamentos no DER é utilizando uma linha única entre as entidades, essa linha pode ser contínua ou tracejada. A linha contínua é um relacionamento obrigatório(deve), e a linha tracejada é um relacionamento opcional(pode). Na extremidade de cada linha é indicado a cardinalidade, podendo ser um para um (1:1), um para muitos (1:m) e muitos para muitos (m:n).
Para indicar que um relacionamento pode não existir ou deve existir, é utilizado uma bolinha ou um traço respectivamente.
O relacionamento de 1:1 ocorre quando uma entidade depende de outra entidade, como por exemplo a entidade Gerente gerencia um Departamento, e cada Departamento é gerenciado por um Gerente, são duas entidades que dependem uma da outra. O relacionamento 1:n é o mais comum de acontecer, a parte do relacionamento 1 possui os dados básicos e o lado muitos é uma lista que complementa com outros atributos, podemos usar como exemplo as entidades CD e Gravadora, cada CD pode ser gravado por uma Gravadora, mas cada Gravadora pode gravar muitos CDs.
Por fim temos o relacionamento de m:n, esse relacionamento ocorre quando uma entidade se relaciona com vários registros de outra entidade e vice-versa. Não é possível aplicar diretamente esse tipo de cardinalidade para um modelo físico do banco de dados. Para aplicar, será necessário criar uma entidade intermediária que receberá o identificador único da primeira e da segunda entidade, ou seja, um m:n é transformado em dois 1:m. Podemos utilizar como exemplo as Entidades Autor e Música, um Autor pode gravar várias Músicas e uma Música pode ser gravada por vários Autores.
Finalmente
Vimos anteriormente que o nosso caso de uso é a criação de um catálogo de CDs. Agora com os conceitos explicados, iremos ver novamente os dados referente ao catálogo de CDs (porém de foram completa) para finalmente fazer o DER do banco de dados.
Podemos ver que vários dados se repetem nesta última tabela, assim, como melhor forma de visualização os campos foram deixados em branco. Iniciando pelo nome do CD, para que não haja redundâncias iremos modelar uma entidade chamada CD. Podemos ver também que a gravadora é uma informação com repetição, então será criado uma entidade Gravadora. Para cada CD, observa-se que existem diversas músicas, mas uma música pode estar contida em diversos CDs, então, será necessário além das entidades CD e Música, uma entidade intermediária para fazer o relacionamento. Por fim há o relacionamento com o Autor, mas uma Música pode ter vários Autores e um Autor pode ter várias Músicas, logo também será necessário de uma entidade intermediária.
No modelo criado:
- Uma Gravadora pode gravar zeros(bolinha) ou mais CDs, e um CD deve(traço) ser gravado por uma Gravadora.
- Um CD pode indicar um outro CD, e um CD pode receber várias indicações, esse é o relacionamento da entidade CD com ela mesma.
- Um CD pode ter uma ou várias Músicas, e uma Música pode estar em um ou mais CDs. Para isso é feito o relacionamento utilizando a entidade MUSICA_CD, que mantém o código único da Música e o código único do CD.
- Uma Música deve ter um Autor e pode ter mais de um, e um Autor pode não ter nenhuma Música ou ter várias Músicas.
Nosso diagrama agora está pronto, nada impede dos dados serem modelados de outra forma, é possível verificar que agora os dados estão separados corretamente por entidades e que foi eliminado as redundâncias, ao vincular um CD a uma GRAVADORA por exemplo, basta adicionar o código da gravadora na entidade CD e não haverá mais repetição de nomes, e nem teremos o problema ter possuir a informação em dois lugares diferentes.
É possível ainda explorar mais o assunto para entender o motivo dos dados serem estruturados dessa forma, no entanto, isso fica para um próximo post que falará sobre as 5 formas de normalização de Banco de Dados.
Fonte:
OLIVEIRA, Celso Henrique Poderoso de. SQL Curso Prático. São Paulo: Novatec Editora Ltda, 2002. 271 p.
