Modelo Entidade Relacionamento

Banco de Dados Modelagem de Dados Modelo E-R Gabriel Issa Jabra Shammas

BD_04 (01) 02 de fevereiro de 2005

MODELO ENTIDADE-RELACIONAMENTO ? Relação de siglas utilizadas neste trabalho: DBMS: Data Base Manager System. E-R: Entidade-Relacionamento. MER: Modelo Entidade-Relacionamento. SGBD: Sistema Gerenciador de Banco de Dados. SGBDr: Sistema Gerenciador de Banco de Dados Relacional. SI: Sistema de Informação.

1/20

1. MODELO ENTIDADE-RELACIONAMENTO (M.E.R.) O Modelo Entidade-Relacionamento (MER) foi desenvolvido pelo professor Peter Chen, a fim de representar as estruturas de dados de uma forma mais natural e mais próxima do mundo real dos negócios. Apesar de ter recebido, por alguns outros estudiosos, algumas representações gráficas e abordagens ligeiramente diferentes, tais como a notação Peter Chen, Bachman ou James Martin, o Modelo EntidadeRelacionamento acabou se tornando o mais utilizado e, até mesmo, confundido com a própria modelagem de dados. A abordagem que será utilizada neste trabalho par o estudo do Modelo de Dados baseia-se nas definições da Engenharia da Informação, proposta por James Martin. O Modelo E-R propõe que a realidade seja visualizada sob três pontos de vista. Assim, há três conceitos fundamentais no Modelo E-R: Entidade, Atributo e Relacionamento.

2/20

2. CONCEITOS ENVOLVIDOS O Modelo Entidade-Relacionamento propõe que a realidade seja visualizada sob três pontos de vista, a saber: a) os objetos que compõem a realidade, b) os tipos de informação ou características que se deseja conhecer sobre os objetos que compõem a realidade e c) a forma como estes objetos interagem entre si. Desta forma, o Modelo Entidade-Relacionamento é composto por três conceitos: Entidade, Atributo e Relacionamento. Os objetos que compõem a realidade são as Entidades. As características que se deseja conhecer sobre os objetos que compõem a realidade são os Atributos. A forma como os objetos interagem entre si constitue o Relacionamento.

3/20

3. DESCRIÇÃO DOS CONCEITOS 3.1. Entidade O primeiro conceito estático do Modelo Entidade-Relacionamento é o conceito de entidade. Entidade, do latim, entitas, significa ser, existência; é algo que possui existência distinta e separada, real ou imaginária[FELLITA, 1983, pág. 5]. Uma entidade corresponde à representação de todo e qualquer substantivo, concreto ou abstrato, sobre o qual precisa-se armazenar e/ou recuperar informações. Por exemplo, os produtos de uma Organização não são idênticos, pois possuem características diferentes, mas eles podem ser refletidos em um modelo que represente todos os produtos e os tipos de informação ou de características que se conhece sobre eles: a entidade PRODUTO. Assim, a entidade PRODUTO é formada por todos os objetos que podem ser classificados como um produto. A Entidade CLIENTE, por outro lado, é formada por todos os objetos que podem ser considerados como um cliente. Em inglês, o conceito de entidade recebe o nome que demonstra bem o seu significado, que é “entity type”, ou seja, um tipo de entidade. Um outro aspecto importante no conceito de entidade é a possibilidade de individualização de cada um dos objetos que compõem o padrão. Como exemplo, pode-se dizer que todo funcionário da Organização possui uma matrícula; através desta matrícula é possível identificar cada um dos indivíduos (distintos) sem risco de ambiguidades ou confusão. Isto porque, se dois funcionários podem ter o mesmo salário ou até mesmo nomes idênticos, a matrícula é sempre única e não pode se repetir. Portanto, diz-se que toda entidade deve possuir um identificador único ou chave primária. Este identificador único é um dos critérios para identificar uma entidade. Sempre que não for possível achar este identificador ou chave primária, então não estará caracterizada uma entidade. Comparando a Modelagem de Dados com a Análise Sentencial, diz-se que cada entidade é uma palavra que representa um substantivo concreto ou abstrato. Animal, pessoa, funcionário, residência, eletrodoméstico, móvel, imóvel, material, aeronave e aluno são exemplos de substantivos concretos que representam objetos simples e do mesmo tipo, sendo, portanto, entidades. No entanto, algumas entidades podem ser mais abstratas porque representam as informações sobre eventos do negócio ou entes conceituais, como contrato (representa um compromisso firmado), pedido de vendas (representa a venda), cliente, depósito (evento de depositar), conta contábil (representa o registro contábil dos eventos), entre outras.

4/20

3.1.1. Tipos de entidades De acordo com a estrutura de sua chave primária e com o grau de dependência que uma entidade possui em relacão a outras entidades, tal entidade pode ser classificada, como segue: A. Entidade Fundamental ou “Kernel” É a entidade que possui chave primária simples, ou seja, a sua chave primária não é composta pela chave primária de nenhuma outra entidade. Dessa forma, a entidade fundamental possui uma maior independência de existência em relação a outras entidades. Por exemplo, temos as entidades CLIENTE, FUNCIONÁRIO, CONTA CONTÁBIL etc. B. Entidade Associativa É a entidade definida a partir da simplificação de um relacionamento de N:M (muitos-para-muitos) entre duas ou mais entidades. A sua chave primária deve ser composta, pelo menos, pelas chaves primárias das entidades que participam do relacionamento que a gerou. Por exemplo, no caso do relacionamento entre a entidade PEDIDO e a entidade PRODUTO, onde: PEDIDO vende (1,N) PRODUTO PRODUTO é_vendido_em (0,N) PEDIDO A entidade associativa ITEM DE PEDIDO é criada em decorrência desse relacionamento, pois alguns atributos não se referem nem ao PEDIDO e nem ao PRODUTO, mas a cada produto vendido (caso da Quantidade e do Desconto, por exemplo). Esses atributos pertencem à entidade ITEM DE PEDIDO, que terá uma chave primária concatenada e composta pelo Número do Pedido e pelo Código do Produto, que são as chaves primárias das entidades acima.

5/20

C. Entidade Atributiva É uma entidade definida a partir de um Grupo Repetitivo de Atributos de uma entidade. Um grupo repetitivo é o conjunto de atributos de uma entidade que ocorre múltiplas vezes para cada ocorrência da entidade. A sua chave primária deve ser composta pela chave primária da entidade da qual foi derivada, mais um outro atributo que individualize cada uma de suas ocorrências. Por exemplo, as entidades DEPENDENTE DE FUNCIONÁRIO e HISTÓRICO DO FUNCIONÁRIO foram definidas a partir dos atributos repetitivos da entidade FUNCIONÁRIO. As ocorrências dessas entidades somente têm sentido de existência se existir um funcionário que as possua. Essas entidades atributivas devem possuir chave primária concatenada e conter o Número de Matrícula do Funcionário como parte de sua chave primária. A entidade DEPENDENTE DE FUNCIONÁRIO possui o Código do Dependente como atributo de diferenciação, enquanto que o HISTÓRICO DO FUNCIONÁRIO possui a Data da Ocorrência.

6/20

3.2. Atributo Uma entidade funcionário representa um tipo, no qual são classificados todos os funcionários da Organização. No entanto, cada indivíduo possui características próprias que devem ser diferenciadas, como por exemplo o fato de que cada funcionário possui um nome, um salário, um carga, uma data de nascimento, entre outras coisas. Essas características de mesmo tipo são utilizadas pela Organização para contratar, administrar, pagar e desligar os funcionários. Esses tipos de características (ou tipos de informação) são denominados atributos de uma entidade. Em inglês, o conceito de atributo recebe o nome de “attribute type”, ou seja, um tipo de atributo. Assim, a entidade DEPÓSITO BANCÁRIO possui os atributos Número do Depósito (que é a chave primária), Data do Depósito, Número da Conta, Valor do Depósito, entre outros. Mesmo considerando que o conteúdo de cada depósito varie, os tipos de informação são os mesmos. Comparando a Modelagem de Dados com a Análise Sentencial, pode-se dizer que, se cada entidade é uma palavra que representa um substantivo concreto ou abstrato, então o atributo é o seu “adjetivo”, pois ele caracteriza a entidade. Exemplos de Atributos: FUNCIONÁRIO #

Matrícula Nome Data de Admissão

NOME DA ENTIDADE

ATRIBUTOS DA ENTIDADE

# identifica a Chave Primária

7/20

3.2.1. Tipos de atributos Os atributos de uma entidade podem desempenhar diversos papéis, de modo que eles podem ser classificados, como segue: A. Atributo simples Ocorre quando uma característica da entidade é representada por um único atributo. Por exemplo, na entidade FUNCIONÁRIO, temos os seguintes atributos simples: NOME (desde que no Brasil), SEXO, ALTURA, etc. B. Atributo concatenado Ocorre quando uma característica da entidade é representada por um conjunto de atributos (dois ou mais atributos). Por exemplo, na entidade FUNCIONÁRIO, temos o seguinte atributo concatenado: ENDEREÇO (composto pelos atributos Logradouro, Número, Complemento, Bairro, Cidade, CEP, UF).

C.

Chave primária (primary key)

Também conhecida como Identificador Único. É o atributo de uma entidade cujo conteúdo individualiza uma única ocorrência desta entidade. Por exemplo, a cada funcionário de uma organização é designado um número de matrícula, através do qual é possível individualizar cada funcionário sem ambiguidade ou confusão. Isso porque, mesmo que dois funcionários tenham o mesmo nome e tenham sido contratados na mesma data, o número de matrícula é sempre único para cada um deles. Por isso, o Número de Matrícula é a chave primária da entidade FUNCIONÁRIO. A chave primária pode ser simples ou concatenada. A chave primária simples é composta por um único atributo que individualiza cada ocorrência da entidade, sem requerer qualquer outra diferenciação. Por exemplo, na entidade FUNCIONÁRIO, temos como chave primária simples o Número de Matrícula; na entidade CLIENTE, temos como chave primária simples o Código do Cliente; na entidade AGÊNCIA, temos como chave primária simples o Número da Agência; na entidade CONTA CONTÁBIL, temos como chave primária simples o Número da Conta etc.

8/20

A chave primária concatenada é composta por vários atributos que, em conjunto, individualizam cada ocorrência da entidade. Ela ocorre, principalmente, nas seguintes situações: 

entidade que representa um histórico, onde cada ocorrência necessita de uma data para sua perfeita individualização. Nesse caso, a chave primária da entidade deve ser composta por uma data ou um período de tempo mais um outro atributo qualquer de diferenciação;



entidade cuja chave primária deve ser composta pela chave primária de uma ou mais entidades (chaves estrangeiras). Nesse caso, pode haver a necessidade de um outro atributo de diferenciação.

Por exemplo, na entidade CONTA CORRENTE, tem-se como chave primária concatenada o Número de Conta Corrente, que é composta por uma chave estrangeira (o Código da Agência, que é a chave primária da entidade AGÊNCIA e que, como chave estrangeira, identifica a agência que controla a conta corrente) e uma diferenciação (o Número Sequencial da Conta Corrente dentro de uma agência). Outro exemplo é a entidade DEPENDENTE DE FUNCIONÁRIO, cuja chave primária concatenada a Identificação do Dependente, que é composta por uma chave estrangeira (o Número de Matrícula do Funcionário, que é a chave primária da entidade FUNCIONÁRIO e que, como chave estrangeira, indica o funcionário que possui o dependente) e uma diferenciação (o Código do Dependente, que pode ser um número sequencial). Outro exemplo é a entidade LANÇAMENTO CONTÁBIL, cuja chave primária concatenada é o Número do Lançamento, que é composto por um atributo (a Data do Movimento quando foi realizado o lançamento) e uma diferenciação (o Número do Movimento, que se renova diariamente). Outro exemplo é a entidade HISTÓRICO DE TREINAMENTO, cuja chave primária concatenada é a Identificação do Treinamento, que é composta por duas chaves estrangeiras, sendo a primeira chave estrangeira o Código do Curso (que é a chave primária da entidade CURSO, indicando qual o curso ministrado), a segunda chave estrangeira é o Número de Matrícula do Funcionário (que é a chave primária da entidade FUNCIONÁRIO, indicando qual o funcionário que recebeu o treinamento) e uma diferenciação (a Data do Curso, considerando que o mesmo funcionário pode ter recebido o mesmo curso em datas diferentes).

9/20

D.

Chave estrangeira (foreign key)

É um atributo pertencente a uma entidade, mas que é a chave primária de uma outra entidade. A chave estrangeira implementa o relacionamento entre as entidades. Por exemplo, a chave primária da entidade CLIENTE é o seu Código. A entidade PEDIDO DE VENDAS contém como atributo o Código do Cliente que é, na verdade, a chave primária da entidade CLIENTE. Portanto, o Código do Cliente é uma chave estrangeira na entidade PEDIDO DE VENDAS e existe porque há um relacionamento entre o CLIENTE e o PEDIDO DE VENDAS. A chave estrangeira pode ser simples ou concatenada.

10/20

3.3. Relacionamento É a forma como os objetos que compõem a realidade se relacionam. Quando se reduz a realidade em objetos como entidades e seus atributos, está se trabalhando com a parte estática dos Negócios. Todavia, na verdade, iremos encontrar situações onde Clientes solicitam Cotações, que geram Pedidos de Vendas quando aprovadas; os Pedidos vendem Produtos em quantidades e preços diferentes que são faturados através da Nota Fiscal, que é paga em parcelas pelas Duplicatas e, assim por diante, em um fluxo dinâmico. Isto mostra que os dados se relacionam entre si, indicando a própria dinâmica dos negócios, bem como as regras e políticas que os regem. Para representar essa dinâmica, o Modelo E-R define o conceito de relacionamento entre as entidades. Logo, o relacionamento é um conceito dinâmico, pois representa a própria dinâmica dos negócios, bem como as suas regras e políticas. Tomando como exemplo a entidade ANALISTA DE SISTEMAS e a entidade PROJETO, pode-se dizer que nem todos os Analistas de Sistemas estão sempre envolvidos em um Projeto (podem estar fazendo cursos ou outras atividades). Porém, se algum Analista de Sistema estiver envolvido em um Projeto, este envolvimento possui um tipo bem definido, regido por alguma política ou regra. Assim, um Analista de Sistema não possui um projeto (o projeto é da Organização), nem é composto, tampouco, por Projetos. O tipo de relacionamento entre ANALISTA DE SISTEMA e PROJETO é sempre de ALOCAÇÃO, de forma que se diz que a entidade ANALISTA DE SISTEMA relaciona-se com a entidade PROJETO através do seguinte relacionamento: ANALISTA é_alocado_em PROJETO Tendo conhecimento deste relacionamento, um Gerente de Sistemas pode obter informações sobre os profissionais envolvidos por PROJETO e pode remanejar os ANALISTAS DE SISTEMAS (por razões de prioridades). Isto porque o relacionamento reflete as rotas lógicas de acesso às informações, que são obtidas sobre vários objetos do mundo real. O Relacionamento possui um verbo como nome, porque representam ações que uma entidade exerce sobre uma outra.

11/20

Assim, temos como exemplos de relacionamentos entre entidades: CLIENTE solicita COTAÇÃO PEDIDO vende PRODUTO CLIENTE possui CONTA BANCÁRIA Os tipos de relacionamento mais comuns são aqueles que indicam: a) POSSE. Ex.: Funcionário possui Dependente b) COMPOSIÇÃO. Ex.: Componente compõe Produto c) GERAÇÃO (ORIGEM). Ex.: Cotação gera Pedido de Vendas d) ALOCAÇÃO. Ex.: Projeto aloca Funcionário. 3.3.1. Cardinalidade dos relacionamentos Obviamente, o Modelo E-R, como toda representação, não é a própria realidade, mas foi desenvolvido para estar o mais próximo dela. Por isso, além de representar as relações de posse, envolvimento, composição e geração (entre outras), incorporou, também, um outro conceito para melhorar o conhecimento sobre as políticas e regras dos Negócios. Este conceito é chamado de Cardinalidade do Relacionamento. É um conceito que melhora o conhecimento sobre as políticas e regras dos Negócios, consistindo de números (cardinais) colocados ao lado do nome do relacionamento. Por exemplo, um indivíduo quer abrir uma conta em um banco e realizar depósitos e saques. No entanto, ele possui algumas dúvidas, como: “quantas contas eu posso abrir no banco?”, “esta conta deve ser apenas minha ou pode ser conjunta?”, “quando abrir a conta em uma agência, eu ficarei sendo cliente desta agência?”, “se eu fizer um depósito em outra agência, eu passarei a ser cliente da outra agência?”. Para conceber o Modelo de Dados, é essencial conhecer as políticas que respondem às questões acima e fazer com que elas sejam refletidas no modelo. As dúvidas levantadas anteriormente continuariam sem serem sanadas se o modelo, por exemplo, fosse construído da seguinte forma: CLIENTE possui CONTA BANCÁRIA CONTA BANCÁRIA pertence a AGÊNCIA Mas, acrescentando-se algumas dimensões aos relacionamentos, o modelo torna-se mais claro: CLIENTE possui “uma ou muitas” CONTA BANCÁRIA CONTA BANCÁRIA pertence a 1 CLIENTE CONTA BANCÁRIA pertence a 1 AGÊNCIA Este modelo, agora, indica que um cliente pode possuir muitas contas no banco (sendo que neste caso não há restrição quanto ao número de contas). Entretanto, uma conta pode pertencer a apenas um cliente (não existem contas conjuntas neste banco hipotético). O cliente pode abrir várias contas em várias agências, mas, para cada número de conta, ele será considerado como cliente de uma agência. 12/20

Desta forma, os números colocados ao lado do nome do nome do relacionamento são chamados de cardinalidade do relacionamento e dimensionam as políticas de Negócio que envolvem os dados. A cardinalidade define, portanto, o número de ocorrências de uma entidade que pode estar envolvido em um relacionamento, sendo útil para extrair daí regras de consistência e integridade dos dados. Por exemplo, o analista de sistemas deve incorporar ao SI mecanismos que impeçam que um mesmo número de conta possa ser aberto para a mesma agência; no entanto, os números de contas podem se repetir para agências diferentes. Isto ocorre porque o número da agência deve ser parte do número da conta (chave primária da entidade CONTA BANCÁRIA).

13/20

3.3.2. Tipos de relacionamento De acordo com a cardinalidade, existem 3 (três) tipos básicos de relacionamento entre as entidades. A. Relacionamento um-para-um (1:1) Indica que uma única ocorrência de uma entidade pode se relacionar com apenas uma única ocorrência de outra entidade. Este tipo de relacionamento é bastante raro (no mundo dos negócios). Por exemplo: FUNCIONÁRIO (1) gerencia (1) DEPARTAMENTO (Lê-se: um departamento possui um funcionário que exerce o papel de gerente; por sua vez, um funcionário-gerente pode gerenciar apenas um departamento de cada vez.) B. Relacionamento um-para-muitos (1:N ou 1:M) Indica que uma ocorrência de uma entidade pode se relacionar com muitas ocorrências de outra entidade. No entanto, a recíproca não é verdadeira. Este tipo de relacionamento é muito comum (no mundo dos negócios). Por exemplo: FUNCIONÁRIO (1) possui (N) DEPENDENTE (Lê-se: um funcionário pode possuir vários dependentes; mas cada dependente pertence a apenas um funcionário.) Outro exemplo: CLIENTE (1) solicita (N) COTAÇÃO (Lê-se: um cliente pode solicitar muitas cotações de vendas; no entanto, cada cotação somente pode ter sido solicitada por um cliente.) Pode-se representar como 1:N ou 1:M.

14/20

C. Relacionamento muitos-para-muitos (N:M) Indica que várias ocorrências de uma entidade pode se relacionar com muitas ocorrências de outra entidade. Pode-se representar como N:M ou como M:N ou, ainda, como N:N ou M:M. Geralmente, um relacionamento desse tipo pode ser convertido e simplificado pela criação de uma entidade intermediária (do tipo associativa, a ser vista posteriormente) e de dois relacionamentos do tipo 1:N (umpara-muitos). Por exemplo: PEDIDO (N) vende (M) PRODUTO (Lê-se: em cada pedido podem ser vendidos muitos produtos diferentes - um para cada linha do pedido; por outro lado, um produto pode ser vendido por diversos pedidos.) Simplificando este relacionamento, tem-se: PEDIDO (1) possui (N) ITEM DE PEDIDO ITEM DE PEDIDO (M) vende (1) PRODUTO (Neste caso, a entidade ITEM DE PEDIDO foi criada para simplificar o relacionamento que, originalmente, era do tipo N:M (muitos-para-muitos.)

15/20

3.3.3. Relacionamentos recursivos ou auto-relacionamentos Os relacionamentos recursivos (também chamados de auto-relacionamentos) são casos especiais onde uma entidade se relaciona com si própria. Apesar de serem relacionamentos muito raros, a sua utilização é muito importante em alguns casos. Os auto-relacionamentos podem ser do tipo 1:1 (um-para-um), 1:N (um-para-muitos) ou N:M (muitos-paramuitos), dependendo da política de negócio que estiver envolvida. Exemplos deste relacionamento podem ser encontrados na chamada “explosão de materiais”, onde itens compostos são formados por muitos itens componentes; por sua vez, estes itens compostos podem ser componentes de outros itens maiores. Exemplificando, temos um automóvel, que é composto pelo chassiz, motor, direção, câmbio etc.; O motor, por sua vez, é formado pelo carburador, velas, platinado etc. Esta explosão pode ser representada pelo seguinte relacionamento: ITEM (N) compõe (M) ITEM sendo que o papel do ITEM é ora de componente e ora de composto. Um outro exemplo de auto-relacionamento é o gerenciamento de funcionários, onde o gerente é um funcionário que possui um relacionamento com outros funcionários que lhe são subordinados. Este relacionamento pode ser representado da seguinte forma: FUNCIONÁRIO (1) gerencia (N) FUNCIONÁRIO sendo que o papel do FUNCIONÁRIO é ora de gerente e ora de subordinado.

16/20

3.3.4. Cardinalidade mínima e máxima Existem casos em que representar e dimensionar as políticas e regras ligadas ao Negócio, através de cardinalidades genéricas do tipo 1:N (um-para-muitos) e N:M (muitos-para-muitos), não consegue refletir totalmente a realidade. Isto porque o conceito de “muitos” é um conceito vago, podendo ser um ou qualquer número acima de um, existindo, ainda, o valor zero, pois, em alguns casos, nem todas as ocorrências das entidades participam do relacionamento. Também é certo que alguns relacionamentos exigem maior precisão na definição da cardinalidade para espelhar as políticas e regras dos negócios. Para isso, o Modelo E-R propõe que seja utilizado o conceito de Cardinalidade Mínima e de Cardinalidade Máxima. Por exemplo, um Modelo de Dados pode indicar um relacionamento entre duas entidades do tipo 1:N (umpara-muitos), como segue: COTAÇÃO (1) gera (N) PEDIDO Este modelo atende a algumas questões, como, por exemplo, COTAÇÃO e que as COTAÇÕES geram PEDIDOS.

que um PEDIDO se origina de uma

Mas, suponha que um Analista de SI esteja estudando o processo de Registro de Pedidos. Ele, com certeza, poderia ter algumas dúvidas, tal como “o PEDIDO deve sempre estar vinculado a uma COTAÇÃO ou existem PEDIDOS que se originaram diretamente, sem que qualquer COTAÇÃO fosse realizada anteriormente?”, ou ainda “todas as COTAÇÕES geram necessariamente um PEDIDO?”. Estas dúvidas aparecem porque dizer que o PEDIDO é gerado por (1) COTAÇÃO é vago, assim como dizer que as COTAÇÕES geram (muitos) PEDIDOS não é específico. Para melhor representar a política de vendas no Modelo de Dados em questão, deve-se complementar as definições dos relacionamentos, indicando as cardinalidades mínima e máxima, da seguinte forma: COTAÇÃO (0,1) gera (0,N) PEDIDO Interpretando o Modelo de Dados, agora, pode-se ler que uma COTAÇÃO pode gerar zerou ou muitos PEDIDOS, ou seja, pode gerar algum PEDIDO, mas não necessariamente, pois algumas negociações podem ser perdidas. Por outro lado, o PEDIDO pode ser ligado a zero ou uma COTAÇÃO, mas existem PEDIDOS que se originaram diretamente, sem COTAÇÃO. Desta forma, além do entendimento, as cardinalidades mínima e máxima auxiliam na definição das regras de validação e consistência dos dados. Por exemplo, saber que um PEDIDO pode ser gerado sem COTAÇÃO indica que o programa de computador não pode forçar a existência de uma COTAÇÃO no instante do registro do PEDIDO; porém, conhecendo esta política, o SI pode ser preparado para aceitar números de cotações em branco. O Modelo de Dados pode, portanto, ser a fonte de muitas interpretações para garantir a consistência e a integridade dos dados.

17/20

4. AGREGAÇÃO DE ENTIDADES A agregação de entidades ocorre quando duas (ou mais) entidades, juntamente com o(s) seu(s) respectivo(s) relacionamento(s), comportam-se como se fossem uma só entidade. A esta entidade denominanos entidade agregada. A entidade agregada tem valor para a documentação das regras de negócios. Sempre que ela aparece, deve ser simplificada (alguns dizem que ela deve ser expandida). Este processo irá gerar uma ou mais entidades associativas.

18/20

5. ENTIDADE GENÈRICA/ESPECIALIZADA Algumas entidades possuem um sentido muito amplo. São chamadas como entidades genéricas. Estas entidades genéricas podem ser melhor descritas utilizando-se tantas especializações quantas se fizerem necessárias. Os atributos da entidade genérica passa para as entidades especializadas através do mecanismo de herança. Cada entidade especializada terá, além dos atributos herdados, o seu próprio conjunto de atributos que lhe caracterizam. Pode-se dizer que “generalização é um relacionamento de especialização/generalização, em que objetos do elemento especializado (o filho) podem ser substituídos para objetos do elemento generalizado (o pai)” [BOOCH, 2000, p. 454].

“Herança é o mecanismo pelo qual elementos mais específicos incorporam a estrutura e o comportamento de elementos mais gerais” [BOOCH, 2000, p. 454].

19/20

6. REFERÊNCIAS BIBLIOGRÁFICAS BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: guia do usuário. Trad. Fábio Freitas. Rio de Janeiro: Campus, 2000. CHEN, Peter. Modelagem de dados: a abordagem entidade-relacionamento para projeto lógico. Trad. Cecília Camargo Bartalotti. São Paulo: Makron Books, 1990. HEUSER, Carlos Alberto. Projeto de banco de dados. 3a ed. Porto Alegre: Sagra-Luzzatto, 2000 (Série Livros Didáticos; Número 4). KORTH, Henry F.; SILBERSCHATZ, Abraham; SUDARSHAN, S. Sistema de bancos de dados. 3a ed. Trad. Marília Guimarães Pinheiro e Paulo César Canhette. São Paulo: Makron, 1999.

20/20