O
modelo entidade relacionamento (MER) é baseado na percepção do
mundo real que consiste em um conjunto de objetos básicos chamados entidades e nos relacionamentos entre
esses objetos. Ele foi desenvolvido para facilitar o projeto de banco de dados
permitindo a especificação de um esquema da empresa. Tal esquema representa a
estrutura lógica
geral do banco de dados.
ENTIDADES E CONJUNTOS DE ENTIDADES
Uma entidade
é um objeto que existe e é distinguível dos outros objetos. Por exemplo, a
pessoa física Paulo Silva com número de CPF 123.456.789-00 é uma entidade,
visto que isso identifica unicamente uma pessoa particular do universo. Por
outro lado, a conta número 40167-9 na agência Lapa é uma entidade que
identifica unicamente uma conta corrente particular. Uma entidade pode ser concreta, como uma
pessoa ou um livro, ou pode ser abstrata,
como um feriado ou um conceito.
Um conjunto
de entidades é um conjunto de entidades do mesmo tipo. O
conjunto de todas as pessoas com conta em um banco, por exemplo, pode ser
definido como o conjunto de todas as entidades cliente. Similarmente, o conjunto de
entidades conta
pode representar o conjunto de todas as contas de um banco particular. É
convenção adotar nomes de conjuntos de entidades no singular, mas não é
obrigatório.
Conjuntos de entidades não precisam ser
disjuntos. Por exemplo, é possível definir o conjunto de entidades de todos os
funcionários de um banco (funcionários)
e o conjunto de todos os clientes do banco (clientes).
Uma entidade pessoa
pode ser uma entidade funcionário,
uma entidade cliente,
ambas ou nenhuma delas.
Uma entidade é representada por um conjunto de atributos. Possíveis
atributos do conjunto de entidades cliente podem ser nome-cliente, cpf, rua e cidade-cliente.
Possíveis atributos do conjunto de entidade conta são número-conta e saldo. Para cada
atributo, existe um conjunto de valores permitidos chamado domínio daquele
atributo. O domínio do atributo
nome-cliente pode ser o conjunto de todas as cadeias de texto (strings) de um certo
tamanho. Assim, o domínio do atributo número-conta
pode ser o conjunto de todos os inteiros positivos. O atributo idade de uma entidade pessoa poderia ter como
domínio os números inteiros entre 0 e 150.
Formalmente, um atributo é uma função que mapeia
um conjunto de entidades em um domínio. Portanto, toda entidade é descrita por
um conjunto de pares (atributo, valor do atributo), sendo um par para cada
atributo do conjunto de entidades. Uma entidade cliente é descrita pelo conjunto {(nome, Paulo Silva), (cpf, 123.456.789-00), (rua, XV de Novembro), (cidade, Campinas)}, que
significa que a entidade descreve uma pessoa chamada Paulo Silva, cujo CPF é
123.456.789-00, residente à rua XV de Novembro, em Campinas.
Um banco de dados inclui uma coleção de conjuntos
de entidades, cada qual contendo um número de entidades do mesmo tipo. A figura
abaixo mostra parte de um banco de dados que consiste em dois conjuntos de
entidades: clientes
e contas.
|
Conjuntos de
entidades cliente
e conta
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Daqui em diante, trataremos de cinco conjuntos de
entidades. Para não criar confusão, serão usados nomes de atributos diferentes
em cada conjunto:
- agência, o conjunto
de todas as agências de um banco. Cada agência
é descrita pelos atributos nome-agência,
cidade-agência
e ativos;
- cliente, o conjunto
de todas as pessoas que têm uma conta no banco. Cada cliente é descrito
pelos atributos nome-cliente,
seguridade-social,
rua e cidade-cliente;
- funcionário, o conjunto
de todas as pessoas que trabalham no banco. Cada funcionário é
descrito pelos atributos nome-funcionário
e número-telefone;
- conta, o conjunto
de todas as contas mantidas no banco. Cada conta é descrita pelos atributos número-conta e saldo;
- transação, o conjunto
de todas as transações executadas no banco. Cada transação é
descrita pelos atributos número-transação,
data e quantia.
Abaixo segue o modelo ER das entidades,
relacionamentos e atributos descritos acima.
RELACIONAMENTOS
E CONJUNTOS DE RELACIONAMENTOS
Um relacionamento
é uma associação entre diversas entidades. Por exemplo, podemos definir um
relacionamento que associa o cliente Harris à conta 401. Isto especifica que
Harris é um cliente
com conta bancária número 401.
Um conjunto
de relacionamentos é uma coleção de relacionamentos do mesmo
tipo. Formalmente, é a relação matemática em n >= 2 conjuntos de entidades
possivelmente não-distintos. Se E1, E2, ..., En
são conjuntos de entidades, então o conjunto de relacionamentos R é um
subconjunto de
{(e1, e2, ..., en)
| e1 pertence E1, e2 pertence E2,
..., en pertence En
onde (e1, e2, ..., en)
é um relacionamento.
Considere os dois conjuntos de entidades cliente
e conta na figura acima. Definimos o conjunto de relacionamentos ContaCliente
para denotar a associação entre clientes e suas contas bancárias. Esta
associação está representada na figura abaixo:
O relacionamento ContaCliente é um exemplo de um
conjunto de relacionamentos binários - isto é, ele envolve dois conjuntos de
entidades. A maioria dos conjuntos de relacionamentos num sistema de banco de
dados é binária. Ocasionalmente, existem conjuntos de relacionamentos que envolvem
mais de dois conjuntos de entidades. Como exemplo, considere o relacionamento
ternário entre as entidades correspondentes ao cliente Harris, conta 401 e
agência Redwood. Este relacionamento especifica que um cliente Harris tem uma conta número 401 na agência Redwood. Isto é
uma instância de um conjunto de relacionamentos CCA (CliConAg) que envolve os
conjuntos de entidades cliente,
conta e agência.
A função que uma entidade exerce num
relacionamento é chamada de papel.
Papéis são normalmente implícitos e não são usualmente especificados.
Entretanto eles são úteis quando o significado de um relacionamento necessita
de esclarecimentos. Tal é o caso quando os conjuntos de entidades de um
conjunto de relacionamentos não são distintos. Por exemplo, o conjunto de
relacionamentos
trabalha-para pode ser modelado para pares ordenados de entidades funcionário; O
primeiro funcionário do par faz o papel do gerente, enquanto o segundo faz o
papel de operário. Deste modo, todos os relacionamentos de trabalha-para são
caracterizados por pares (gerente, operário); os pares (operário; gerente) são
excluídos.
Um relacionamento pode também ter atributos
descritivos. Por exemplo, data
pode ser um atributo do conjunto de relacionamentos ContaCliente. Isto especifica a última data
na qual o cliente fez acesso à conta. O relacionamento ContaCliente entre as
entidades correspondentes Harris e à conta 401 é descrito por {(data, 23 janeiro de
2005)}, o que significa que a última vez que Harris fez algum acesso à conta
401 foi em 23 de janeiro de 2005.
ATRIBUTOS
Uma vez que a noção de um conjunto de entidades e
de um conjunto de relacionamentos não é precisa, é possível definir um conjunto
de entidades e o relacionamento entre elas de diversos modos. A principal
diferença é a forma como tratamos os vários atributos. Considere o conjunto de
entidades funcionário
com os atributos nome-funcionário
e numero-telefone.
É possível facilmente argumentar que um telefone é uma entidade com os
atributos numero-telefone
e local
(escritório onde está o telefone). Assumindo este ponto de vista, o conjunto de
entidades funcionário
precisa ser redefinido assim:
- O conjunto de
entidades funcionário
com atributo nome-funcionário;
- O conjunto de
entidades telefone
com atributos numero-telefone
e local;
- O conjunto de
relacionamentos FuncTel, que denota a associação entre funcionários e seus
telefones.
Qual é então, a principal diferença entre essas
duas definições de um funcionário? No primeiro caso, a definição implica que
todo funcionário tem precisamente um número de telefone associado a ele. No
segundo caso, entretanto, a definição admite que funcionários possam ter
diversos números de telefone (incluindo zero) associados a eles. Desta forma, a
segunda definição é mais geral que a primeira e pode refletir com mais fieldade
a situação real.
Mesmo se considerarmos que cada funcionário tenha
precisamente um número de telefone associado a ele, a segunda definição pode
até ser mais adequada se o telefone for compartilhado entre vários empregados.
Não seria apropriado, entretanto, aplicar a mesma
técnica ao atributo nome-funcionário.
Isto se deve à dificuldade de argumentar que nome-funcionário
é uma entidade propriamente dita (em comparação com o telefone). Assim, é
apropriado ter nome-funcionário
como atributo do conjunto de entidades funcionário.
Aparece uma questão natural: o que constitui um
atributo e o que constitui um conjunto de entidades? Desafortunadamente não
existe uma resposta simples. A distinção depende principalmente da estrutura da
empresa que está sendo modelada e da semântica associada ao atributo em
questão.
Existem diversos tipos de atributos às quais
veremos abaixo:
- Compostos. Os atributos
compostos podem ser divididos em partes
menores, ou subpartes, os quais representariam atributos básicos mais
simples com significados independentes. Por exemplo, um atributo endereço pode ser
subdividido em rua,
cidade, estado e cep. Poderíamos
também dividir o atributo rua
em número,
nome-rua
e número-apartamento.
Atributos deste tipo formam uma hierarquia.
- Simples. São chamados
também por atributos atômicos. Eles não são divisíveis.
- Monovalorados. São atributos
que possuem apenas um valor para uma entidade em particular. Por exemplo,
a idade é
um atributo monovalorado para uma entidade pessoa.
- Multivalorado. São atributos
que possuem um ou mais valores para o mesmo. Por exemplo, o atributo idioma de
uma entidade aluno
pode conter os valores inglês e francês. Para um outro aluno poderia
conter apenas um valor - espanhol. Para um terceiro aluno, poderíamos ter
3 valores para este atributo.
- Armazenado. Em geral
todos os atributos são armazenados.
- Derivado. Alguns
atributos podem ter uma relação entre si. Por exemplo, idade e data-nascimento de
uma pessoa.
Para uma pessoa em particular, podemos determinar o valor atual de idade através do
atributo data-nascimento.
Então idade
é chamado um atributo derivado
e é derivado do atributo data-nascimento.
Alguns atributos podem ser derivados de entidades relacionadas. Por
exemplo, um atributo número-empregados
de uma entidade departamento
pode ser derivado através da contagem de número de empregados que trabalham-para um departamento.
- Nulo. Em alguns
casos, uma entidade pode não necessitar de um valor aplicável a um de seus
atributos. Por exemplo, no atributo número-apartamento
composto visto acima, apenas definiremos valores para este campo quando a
entidade pessoa em particular morar em um prédio. Outro exemplo é
multivalorado idioma
de um aluno:
caso este aluno em particular não tenha fluência em nenhuma língua, então
não necessitamos preencher o valor deste atributo. A representação de um
atributo sem valor é colocarmos um valor especial null. Null
também pode ser utilizado quando não conhecemos o valor de um atributo,
por exemplo, quando se é desconhecida a data de nascimento de uma pessoa.
RESTRIÇÕES
DE MAPEAMENTO
Um esquema ER de uma empresa pode definir certas
restrições com as quais o conteúdo do banco de dados tem de estar de acordo.
Uma restrição importante são as cardinalidades
(ou multiplicidade) do mapeamento, que expressam o número de
entidades às quais outra entidade pode estar associada via um conjunto de
relacionamentos.
As cardinalidades do mapeamento são muito úteis
na descrição de conjuntos de relacionamentos binários, embora ocasionalmente
contribuam para a descrição de conjuntos de relacionamentos que envolvam mais
de dois conjuntos de entidades. O foco aqui será apenas conjuntos de
relacionamentos binários.
Para um conjunto de relacionamentos binário R
entre o conjunto de entidades A e B, a cardinalidade do mapeamento precisa ser
um dos seguintes:
- Um-para-um: uma entidade
A está associada no máximo a uma entidade B e uma entidade B está
associada no máximo a entidade de A;
- Um-para-muitos: uma entidade
A está associada a qualquer número de entidades de B. Uma entidade de B,
entretanto, pode estar associada no máximo a uma entidade de A;
- Muitos-para-um: uma entidade
A está associada no máximo a uma entidades de B. Uma entidade de B,
entretanto, pode estar associada a qualquer número de entidades de A;
- Muitos-para-muitos: uma entidade
A está associada a qualquer número de entidades de B e uma entidade de B
está associada a qualquer número de entidades de A.
A cardinalidade do mapeamento para um conjunto de
relacionamentos particular é obviamente dependente do mundo real que está sendo
modelado pelo conjunto de relacionamentos.
Para ilustrar, considere o conjunto de
relacionamentos ContaCliente.
Se, em um banco específico, uma conta pode pertencer a apenas um cliente, e um
cliente pode ter diversas contas, então o conjunto dos relacionamentos é
um-para-muitos de cliente
e conta. Se
uma conta pode pertencer a diversos clientes (como uma conta conjunta de
diversos membros de uma família), o conjunto de relacionamentos é
muitos-para-muitos.
A dependência
de existência forma outra importante classe de restrições.
Especificamente, se a existência da entidade x
depende da existência da entidade y,
então x é dito dependente
da existência de y. Operacionalmente, isso significa que se y for eliminado, x também o será. A
entidade y é
chamada de entidade
dominante, e x
é chamado de entidade
subordinada.
Para ilustrar, considere os conjuntos de
entidades conta
e transação.
Formamos um conjunto de relacionamentos log
entre estes dois conjuntos, o qual especifica que, para uma conta particular,
pode haver diversas transações. Este conjunto de relacionamentos é
um-para-muitos de conta
para transação.
Toda entidade de transação
deve estar associada a uma entidade de conta. Caso uma entidade de conta seja eliminada,
todas as entidades de transação
associadas a ela deverão ser apagadas também. Em comparação, entidades transação podem ser
eliminadas do banco de dados sem prejudicar qualquer conta. O conjunto de
entidades conta,
como visto, é dominante,
e transação é subordinado
no conjunto de relacionamentos log.
CHAVES
É importante pode especificar como entidades e
relacionamentos são identificados. Conceitualmente, entidades e relacionamentos
individuais são distintos, mas numa perspectiva de banco de dados a diferença
entre eles precisa ser expressa em termos de seus atributos. O conceito de superchave
permite-nos fazer tais distinções. Uma superchave
é um conjunto de um ou mais atributos que, tomando coletivamente, permite-nos
identificar unicamente uma entidade no conjunto de entidades. Por exemplo, o
atributo seguridade-social
do conjunto de entidades cliente
é suficiente para distinguir uma entidade cliente
das outras. Desta forma, seguridade-social
é uma superchave. De forma semelhante, a combinação nome-cliente e seguridade-social é uma superchave para o
conjunto de entidades cliente.
O atributo nome-cliente
de cliente não
é uma superchave, pois diversas pessoas podem ter o mesmo nome.
O conceito de superchave não é suficiente para
nossos propósitos, uma vez que, como vimos anteriormente, uma superchave pode
conter atributos desnecessários. Freqüentemente, procuramos superchaves que não
contenham nenhum subconjunto próprio que seja uma superchave. Tais superchaves
mínimas são chamadas chaves
candidatas.
É possível que diversos conjuntos distintos de
atributos possam servir como uma chave candidata. Suponha que uma combinação de
nome-cliente e
rua seja
suficiente para distinguir entre membros do conjunto de entidades cliente. Então ambos, {seguridade-social} e {nome-cliente, rua}, são chaves
candidatas. Embora os atributos seguridade-social
e nome-cliente
juntos possam distinguir entidades de cliente,
sua combinação não forma uma chave candidata, uma vez que o atributo seguridade-social
sozinho é uma chave
candidata.
Utilizaremos o termo chave primária para denotar
uma chave candidata que é escolhida por um projetista de banco de dados como
meio principal de identificação de entidades dentro de um conjunto de
entidades.
ENTIDADES
FORTES E ENTIDADES FRACAS
É possível que um conjunto de entidades não tenha
atributos suficientes para formar uma chave primária. Tal conjunto de entidades
é nomeado como conjunto
de entidades fraco. Um conjunto de entidades que possui uma
chave primária é definido como conjunto
de entidades forte. Para ilustrar, considere o conjunto de
entidades transação
que possui três atributos: número-transação,
data e quantia. Embora cada
entidade transação
seja distinta, transações em contas diferentes podem compartilhar o mesmo
número de transação. Assim, este conjunto de entidades não tem uma chave
primária e é, portanto, um conjunto de entidades fraco. Para que este conjunto
de entidades fraco tenha significado, ele deve fazer parte de um conjunto de
relacionamentos um-para-muitos. Este conjunto de relacionamentos não deve ter
atributos descritivos, uma vez que qualquer atributo requerido pode estar
associado ao conjunto de entidade fraco.
Os conceitos de conjuntos de entidades forte e
fraco estão relacionados às dependências de existência introduzidas
anteriormente. Um membro de um conjunto de entidades forte é por definição uma
entidade dominante, enquanto um membro de um conjunto de entidades fraco é uma
entidade subordinada.
Embora um conjunto de entidades fraco não tenha
uma chave primária, precisamos todavia de uma forma de distinção entre todas
essas entidades no conjunto de entidades que dependa de uma entidade forte
particular. O discriminador
(ou chave parcial) de um conjunto de entidades fraco é um
conjunto de atributos que permite que esta distinção seja feita. por exemplo, o
discriminador
do conjunto de entidades fraco transação
é o atributo número-transação,
uma vez que para cada conta um número de transação univocamente identifica uma
única transação.
A chave primária de um conjunto de entidades
fraco é formada pela chave primária do conjunto de entidades forte do qual ele
é dependente de
existência (ou dependência existencial), mais seu
discriminador. No caso do conjunto de entidades transação, sua chave primária é
{número-conta,
número-transação},
onde número conta identifica a entidade dominante de uma transação e número-transação
distingue entidades de transação
dentro da mesma conta.
As entidades fracas são representadas por um
retângulo duplicado. O conjunto de relações que identificam as entidades fracas
são representados por losângulos duplicados. Os atributos que constituem a
chave parcial (ou discriminadores) são sublinhados de forma tracejada.
Modelando
um banco de dados
Modelar um banco de dados parece uma tarefa
simples, porém cheia de difuldades que não estão explícitas e muitas vezes
passamos despercebidos. Esta fase é a mais importante de um projeto de banco de
dados e deve-se tomar o maior cuidado, pois um modelo ER errado implicará em um
modelo físico errado. Uma vez feito o modelo físico, as alterações no modelo ER
podem causar grandes impactos no modelo físico e consequentemente muitas horas
de retrabalho.
Vamos utilizar algumas convenções no modelo ER:
- Nomes de
conjuntos de entidades e conjuntos de relacionamentos serão em letras
maiúsculas;
- Nomes de
atributos e papéis serão em letras minúsculas;
- Desenhar o
diagrama ER de cima para baixo, da esquerda para a direita.
Como prática geral, dada uma descrição narrativa
dos requisitos de um banco de dados, os substantivos que aparecem na narrativa
tendem a denotar nomes de conjuntos de entidades e os verbos tendem a denotar
nomes de conjuntos de relacionamentos. Os atributos dos conjuntos de entidades
provêem da descrição adicional dos substantivos correspondente às entidades.
Em geral, a narrativa dos requisitos de
informações que o banco de dados armazenará pode ser feito através de
entrevistas, engenharia reversa de um sistema, e-mails, telefone, enfim, todo
canal de comunicação é utilizado a fim de coletar as diferentes visões de um
banco de dados que terão os vários usuários finais.
Geralmente, o processo de modelagem é iterativo,
onde:
1.
Inicialmente
identificamos e representamos os conjuntos de entidades (fortes e fracas);
2.
Identificamos
e representamos os conjuntos de relacionamentos;
3.
Procuramos
os atributos das entidades e dos relacionamentos e o domínio destes atributos;
4.
Definindo
as superchaves, chaves candidatas e chaves parciais;
5.
Definimos
os tipos de atributos (simples/compostos, mono/multi valorados, armazenado/derivado);
6.
Definimos
as cardinalidades dos conjuntos de relacionamentos;
7.
Definimos
a participação (total ou parcial) de cada papel de relacionamento;
8.
Refinamos
o modelo ER a fim de verificar se este atende as necessidades das diferentes
visões.
O
que pode acontecer no MER:
1.
Existir
uma, duas, três, ..., dez, onze, ..., entidades, ou seja, o número de entidades
é ilimitado;
2.
Existir
um, dois, três, ..., dez, onze, ..., atributos ligados a uma entidade, ou seja,
o número de atributos por entidade é ilimitado;
3.
Existir
um, dois, três, ..., dez, onze, ..., relacionamentos, ou seja, o número de
relacionamentos é ilimitado;
4.
Existir
mais de duas entidades que executam um mesmo relacionamento;
5.
Os
atributos podem ser conectados a no máximo uma entidade, ou um relacionamento
ou um atributo (caso dos atributos compostos).
O
que NÃO pode acontecer no MER:
1.
Relacionamentos
sem nome ou sem cardinalidade;
2.
Entidades
ou atributos sem nome;
3.
Entidade
forte sem chave candidata;
4.
Entidade
fraca com chave candidata.
Nenhum comentário:
Postar um comentário