Metodologia das Entidades e Relacionamentos

METODOLOGIA DAS ENTIDADES E RELACIONAMENTOS
Pedro Cosme da Costa Vieira, Março 2007
O objectivo da metodologia das entidades e relacionamentos, MER, é, partindo de
uma descrição abstracta do problema de armazenamento de informação, projectar a
estrutura da base de dados que conterá diversas tabelas relacionadas entre si com
relações de “1:N”.
Esta filosofia é contrária à normalização que parte de um exemplo concreto já com
informação explicitada e onde se vai evitar a existência de repetições de informação.
Num caso mais difícil será necessário auxiliar a MER com exemplos parcelares com
informação simulada que se normaliza. Será uma estratégia mista entre o MER e a
normalização.
O elemento base de informação é o “atributo”
Um atributo é uma “caixinha” onde podemos depositar informação necessária para
responder ao problema em estudo. Por exemplo, numa situação de contas bancárias, o
“nome do cliente”, o “valor do movimento”, a “data de abertura da conta”, a “morada
do cliente”, são exemplos de atributos.
Partindo da informação contida nos atributos, podemos calcular outra informação.
Por exemplo, com a informação do atributo “valor do movimento” podemos calcular
o “saldo da conta” que não é um atributo mas um “total” calculado com todos os
movimentos registados.
Uma entidade não podem ficar “perdidas” no meio da base de dados, havendo
necessidade de agrupar as entidades referentes à mesma entidade. Em teremos de
base de dados, um atributo corresponde a um campo enquanto que uma entidade
corresponde a uma tabela. Por exemplo, o “nome do cliente” implica a “morada do
cliente” e o “telefone do cliente”. Então, teremos que associar esses atributos numa
entidade que podemos denominar por “Clientes”.
A “entidade” é o elemento central da análise do MER.
Uma entidade, ao associar atributos relacionados com um tipo de “indivíduos”,
guarda informação sobre muitos indivíduos. Por exemplo, nas contas bancárias, os
“clientes” dão origem a uma entidade: Clientes (Nome; Morada; Telefone) que
contem informação que caracteriza todos os clientes do banco.
O elemento de aglutinação da informação é a “relação” entre as entidades.
Como já explicado, as relações entre as entidades podem ser de “1 para 1”, de “1 para
N” (igual a de “N para 1”) ou de “N para N”. A base de dados não pode ter relações
de “N para N”. Para resolver tal impossibilidade, é necessário criar uma entidade de
ligação e duas relações “1:N”.
No contexto de contas bancários, vamos supor que um cliente pode ter várias contas e
que uma conta pode ter vários titulares (que são clientes). Isto traduz uma relação de “N
para N” entre a entidade contas e a entidade clientes que se resolve com a entidade de
ligação Clientes-Contas.
Para experimentarmos se o nosso modelo de entidades e relacionamentos permite
guardar que um cliente tem duas contas e uma conta tem dois clientes, fazemos um
pequeno exemplo:
Para implementar uma relação “1:N” é OBRIGATÓRIO que a entidade do lado “1”
tenha um atributo chave e que esse atributo chave será “importado” para a entidade do
lado “N” da relação.
Resolução de um caso: Informatização de uma biblioteca
Num caso concreto temos que identificar o que são atributos, entidades, relacionamentos
e “campos calculados”. Se o problema está numa fase insipiente, tenta-se identificar as
entidades e depois partir para os atributos.
Na biblioteca teremos que ter informação sobre os livros. Será também fundamental
saber quando cada livro foi emprestado e a quem.
Assim, LIVROS deve ser uma entidade. De cada livro, será necessário guardar a cota, o
título, os autores, o ano de edição, a editora, a data de aquisição, o preço e as datas de
empréstimo, de entrega e quem levou os livros. Sempre que estamos em presença de um
plural para um livro só teremos que ter outra entidade. Neste caso estão autores, datas de
empréstimo, datas de entrega e leitores.
Os AUTORES devem ser uma entidade e os LEITORES deve ser outra entidade.
A entidade AUTORES terá o código, nome, afiliação e um pequeno curriculum
enquanto que a entidade LEITORES terá o código, nome, morada e telefone.
As datas de empréstimo, de entrega e quem levou os livros parecem mais atributos de
uma entidade, os EMPRÉSTIMOS que terá como atributos a data de empréstimo, a data
de entrega. Em termos de balanço temos neste momento
LIVROS(Cota; Título; D-Edição; Editora; D-Aquisição; preço)
AUTORES(Código; Nome; Afiliação; Curriculum)
LEITORES(Código; Nome; Morada; Telefone)
EMPRÉSTIMOS(ID; D-Empréstimo; D-Entrega)
Temos agora que pensar as relações entre as 4 entidades identificadas até agora.
Um LIVRO tem vários AUTORES e um AUTOR tem vários LIVROS
Um LIVRO é várias vezes REQUISITADO e uma REQUISIÇÃO é de vários LIVROS
Um LEITOR faz vários EMPRÉSTIMOS e um EMPRÉSTIMO é feita por um AUTOR
Temos agora que fazer Entidades de Ligação para quebrar as ligações “N:N”
EL-LIVRO-AUTOR(Cota, Cod-Autor)
EL-LIVRO-EMPRÉSTIMO(Cota, Cod-empréstimo)
Agora já só temos relações 1:N. temos que importar as chaves da tabela do lado “1” para
a entidade do lado “N”
LIVROS(Cota; Título; D-Edição; Editora; D-Aquisição; preço)
EL-LIVRO-AUTOR(Cota, Cod-Autor)
AUTORES(Código; Nome; Afiliação; Curriculum)
LEITORES(Código; Nome; Morada; Telefone)
EL-LIVRO-EMPRÉSTIMO(Cota, ID-Empréstimo)
EMPRÉSTIMOS(ID; D-Empréstimo; D-Entrega, Cod-Leitor)
EM TERMOS DE LINGUAGEM, TEMOS QUE FALAR DE ATRIBUTOS E
ENTIDADES E NUNCA DE CAMPOS E TABELAS