quinta-feira, 4 de abril de 2013

MODELO ENTIDADE RELACIONAMENTO - MER


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
cliente
Nome
SSN
Bairro
Cidade
Oliver
645-32-1098
Main
Austin
Harris
890-12-3456
North
Georgetown
Marsh
456-78-9012
Main
Austin
Pepper
369-12-1518
North
Georgetown
Ratliff
246-80-1214
Park
Round Rock
Brill
121-21-2121
Putnam
San Marcos
Evers
135-79-1357
Nassau
Austin

conta
Ag.
Cta.
259
1000
630
2000
401
1500
700
1500
199
500
467
900
115
1200
183
1300
118
2000
225
2500
210
2200

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