Curso de Banco de Dados 1 Aula 4 - 1 ©Prof. Lineu Mialaret Banco de Dados I – BD I Prof. Lineu Mialaret Aula 4: Modelo Entidade Relacionamento (1) Instituto

Curso de Banco de Dados 1 Aula 4 - 1 ©Prof. Lineu Mialaret

Banco de Dados I – BD I Prof. Lineu Mialaret

Aula 4: Modelo Entidade Relacionamento (1)

Instituto Federal de Educação, Ciência e Tecnologia de São Paulo - IFSP

Campus de Caraguatatuba

Tecnólogo em Análise e Desenvolvimento de Sistemas

10 Semestre de 2013


Etapa de Desenvolvimento

Etapa de Especificação

Modelo Funcional

Modelo Lógico de Banco de Dados

Modelo Conceitual de Banco de Dados

Modelo Hierárquico Modelo Rede Modelo Relacional

Modelo Físico

Modelo Físico

Modelo Físico

Modelo Físico

Modelo OO

Desenvolvimento de BD (1)


Modelo Físico

Modelo Lógico

Modelo ConceitualRequisitos

+

Regras de

Negócio

BD Operacional

Visão de Negócio

Visão de Sistema

An

ális

e

Pro

jeto

Modelo Funcional



1.2 - Modificar Itens

1.1 - Visualizar Lista de Itens Bibliograficos

1.4 - Incluir Itens

1.3 - Remover Itens

«extend»

«extend»

«extend»

Pesquisador

3 - Login

«include»

Quais os conceitos importantes (concretos e abstratos) envolvidos na execução dessas funcionalidades?



No mundo real, entidades (objetos ou conceitos) não existem de forma isolada. Essas entidades, seus atributos (suas características), e os relacionamentos ou as associações entre elas (suas conexões semânticas) devem encontradas e representadas para propósito de armazenamento num Banco de Dados - BD.

Em certo ponto de um projeto de um Aplicativo de Banco de Dados, tanto as capacidades, como as limitações do SGBD a ser utilizado devem ser levadas em consideração (e isso vai depender do modelo lógico de BD adotado).

O enfoque desta parte do curso de Banco de Dados 1 é o de, inicialmente, modelar contextos do mundo real, de forma independente do “SGBD escolhido”, e mais tarde então, converter esse Modelo Conceitual (ou Canônico) gerado para um Modelo Lógico, de forma que ele se encaixe nas características especiais do SGBD adotado.

Modelos de BD (1)


Modelo Conceitual: É um modelo independente da implementação,

representando os conceitos (do domínio de negócio) que aparecem no Aplicativo de BD.

Exemplo: Modelo Entidade Relacionamento - MER. Modelo Entidade Relacionamento - MER:

Introduzido por Peter Chen no artigo: The Entity-Relationship Model - Toward a Unified View of Data,

Transactions on Database Systems, 1(1), March, 1976. O MER é um modelo conceitual utilizado durante a fase

inicial de projeto de um Aplicativo de BD, para o entendimento do mundo real.

Modelo Lógico: É a descrição de como os dados estarão armazenados

logicamente, e é parcialmente dependente do tipo de SGBD utilizado.

Exemplo: Modelo Relacional - MR.

Modelos de BD (2)


O Modelo Entidade Relacionamento – MER tem por base a percepção de que o mundo real é formado por um conjunto de objetos chamados de entidades (tangíveis ou não), caracterizados por atributos, e pelos conjuntos de relacionamentos entre esses objetos.

Esse modelo foi desenvolvido para facilitar o projeto de desenvolvimento de um Aplicativo de Banco de Dados, permitindo a especificação do esquema conceitual de uma empresa por exemplo, o qual será devidamente mapeado para um modelo lógico, representativo da organização em questão.

O MER é um dos modelos com maior capacidade semântica, e esses aspectos semânticos se referem a tentativa de representar os significado de entidades, atributos e relacionamentos.

Esse modelo é extremamente útil para mapear, no aspecto conceitual, o significado e as interações de empresas reais ou domínios de contextos significativos.

Modelos de BD (2)


Para a exemplificação dos conceitos que serão apresentados no Modelo Conceitual usado nesta parte do curso (Modelo Entidade Relacionamento – MER), será utilizado o seguinte contexto de um domínio de negócio, o qual representa de forma sintética, uma empresa bancária: Um banco é organizado em agências. Cada agência se

localiza numa cidade e é identificada por um nome único. O banco controla os depósitos (totais de saldos) de cada uma dessas agências. Os clientes do banco são identificados por meio de seu número de seguro social. O banco mantém armazenados dados como o nome, rua e cidade do cliente. Os clientes podem possuir contas e contrair empréstimos, bem como podem estar associados a um funcionário do banco específico que cuida de seus negócios ou atua como um agente de empréstimos.

Contextualização (1)


Os empregados do banco também são também identificados por meio de seu número de seguro social. A administração bancária mantém armazenados o nome e o número do telefone de cada um de seus funcionários, e também os nomes de seus dependentes, a data de contratação e o número de seguro social de seu gerente.

O banco oferece dois tipos de contas a seus clientes: contas do tipo poupança e movimento. As contas movimento podem ter mais de um correntista e este pode possuir mais de uma conta. Cada conta bancária possui um único número de identificação. O banco controla o saldo de cada conta, bem como como a data do mais recente de acesso a mesma. Por um outro lado, cada conta poupança possui uma taxa de juros associada, assim como são também registrados os excessos nos limites da conta movimento.



Um empréstimo originado numa determinada agência pode ter sido obtido por um ou mais clientes, sendo o mesmo identificado por um único número de empréstimo. Para cada empréstimo o banco mantém armazenados o montante emprestado, bem como também os pagamentos efetuados das parcelas.

Embora o número da parcela de um empréstimo não identifique de modo único um pagamento específico dentre os muitos pagamentos realizados num banco, esse número identifica um pagamento efetuado para um determinado empréstimo em particular. A data e o montante pago são registrados no pagamento de cada parcela.



Conjuntos de Entidades (1) Um Banco de Dados pode ser modelado no nível de

esquema conceitual como: Uma coleção de entidades e seus respectivos atributos. Os relacionamentos que ocorrem entre essas entidades.

Um entidade é um objeto que existe e é distinguível de outros objetos: Exemplo: uma pessoa, uma companhia, um evento, etc...

Entidades possuem propriedades ou atributos: Exemplo: pessoas possuem nome e endereço.

Um conjunto de entidades é um conjunto contendo entidades do mesmo tipo que compartilham as mesmas propriedades: Exemplo: O conjunto de todas as pessoas que são clientes

de um dado banco pode ser definido como o conjunto de entidades Cliente.

Entidades individuais desse conjunto são denominadas de extensões ou instâncias de um conjunto de entidades.


Conjuntos de Entidades (2)

Outras conceituações e características de entidades e conjuntos de entidades: Uma pessoa, um lugar, uma coisa, ou até mesmo um

conceito (concreto ou abstrato), que possua características de interesse numa organização empresarial ou num sistema computadorizado. Isto é, alguma coisa ou algo sobre os dados armazenados.

Conjunto de objetos da realidade modelada sobre os quais deseja-se manter informações no Banco de Dados (Heuser, 1998).

Um conjunto de objetos sobre os quais é preciso armazenar informações úteis.

Conjuntos de elementos distinguíveis que aceitam um código para diferenciá-los.


Conjunto de Entidades (3) cliente-id nome- rua- cidade- numero valor- cliente cliente cliente empréstimo

Exemplo dos conjuntos de entidades Cliente e Emprestimo.

Cliente Emprestimo


Atributos (1) Uma entidade é representada por um conjunto de

atributos, que são as propriedades descritivas possuídas por todos os membros de um conjunto de entidades. Exemplo: sejam as entidades cliente e emprestimo com os

seguintes atributos -

Cliente = (cliente-id, nome-cliente, rua-cliente, cidade-cliente)Emprestimo = (numero-emprestimo, valor)

O conjunto de valores permitidos para cada atributo denomina-se de domínio do atributo.

Exemplo: O domínio do atributo nome-cliente pode ser o

conjunto de todos os textos string de um certo tamanho.

O domínio do atributo numero-emprestimo pode ser o conjunto de todos os números inteiros.


Atributos (2) Um atributo pode ser caracterizado pelos

seguintes tipos: Atributos simples, os quais não podem ser divisíveis, ou

seja, são atributos atômicos. Atributos compostos, os quais podem ser divididos -

O atributo nome-cliente pode ser dividido nos seguintes atributos, prenome, nome-intermediario e sobrenome.

Atributos monovalorados, os quais só podem ter um valor. Atributos multivalorados, os quais podem ter mais de um

valor O atributo nome-dependente pode possuir vários nomes.

Atributos derivados, os quais podem ser obtidos de outros atributos

Seja o atributo data-contratação e o atributo derivado tempo-de-casa, que pode ser determinado pela data de contratação.

Atributos nulos.


Atributos (3)

Exemplo dos atributos compostos name (nome) e address (endereço).


Conjunto de Relacionamentos (1) Um relacionamento é uma associação (conexão

semântica) entre entidades. Exemplo:

Hayes depositante A-102entidade Cliente relacionamento entidade Conta

Por exemplo, considere os conjuntos de entidades Emprestimo e Agencia. Pode-se definir o conjunto de relacionamentos agencia-emprestimo, o qual caracteriza a associação entre um empréstimo bancário e a agência onde esse empréstimo é mantido. De modo similar, pode-se caracterizar o conjunto de relacionamentos devedor, entre os conjunto de entidades Cliente e Emprestimo.

agencia-emprestimoemprestimo 1

emprestimo 2agencia 10


Conjunto de Relacionamentos (2)

Exemplo do conjunto de relacionamentos devedor.

cliente-id nome- rua- cidade- numero valor- cliente cliente cliente emprestimo

Cliente Emprestimo

deve

dor

E1 E2


Conjunto de Relacionamentos (3) A associação entre os conjuntos de entidades também é

referida como uma participação, ou seja, o conjunto de entidades E1,E2,…,En participa do conjunto de relacionamentos R.

A função que uma entidade desempenha num relacionamento é chamada de papel. Uma vez que os conjuntos de entidades participantes num conjunto de relacionamentos são geralmente distintos, os nomes de papéis são implícitos e não são, necessariamente, especificados.

Entretanto, esse nomes de papéis são úteis quando o significado do relacionamento precisa ser esclarecido. Que é o caso em que os conjuntos de entidades e de relacionamentos não são distinguíveis, ou seja, o mesmo conjunto de entidades participa de um conjunto de relacionamentos mais de uma vez, em diferentes papéis.

Neste tipo de conjunto de relacionamentos, chamado de conjunto de relacionamento recursivo, nomes explícitos de papéis são necessários para especificar como uma entidade participa de uma instância do relacionamento.


Um atributo pode também ser uma propriedade de um conjunto de relacionamentos: O relacionamento depositante entre os conjuntos de

entidades Cliente e Conta pode ter o atributo data-acesso.

Conjunto de Relacionamentos (4)

Cliente (nome-cliente)

depositante(data-acesso)

Conta(numero-conta)


Graus de um Conjunto de Relacionamentos O grau de um conjunto de relacionamentos se refere

ao número de conjuntos de entidades distintos (diferentes) que participam nesse relacionamento.

Conjuntos de relacionamentos que envolvem dois conjuntos de entidades são chamados de binários (ou de grau 2).

Em certos casos, conjuntos de relacionamentos podem envolver mais que dois conjuntos de entidades Exemplo: suponha que empregados de um banco tenham

diversas tarefas (responsabilidades) em múltiplas agências, com diferentes tarefas nas várias agências. Então há um relacionamento ternário (ou de grau 3) denominado de ETA entre os conjuntos de entidades Empregado, Tarefa e Agencia.

Relacionamentos entre mais que dois conjuntos de entidades são raros. Geralmente, a maioria dos relacionamentos numa base de dados são binários.


Metas Básicas de Projeto de BD (1) Um conjunto de entidades e um conjunto de

relacionamentos não são noções precisas. Pode-se definir um conjunto de entidades e de

relacionamentos de várias formas. No uso de conjuntos de entidades e atributos, a

escolha destes vai depender principalmente da estrutura da empresa que está sendo modelada e da semântica associada com os atributos em questão.

Exemplo: Modelo 1:

O conjunto de entidades Empregado com os atributos nome-empregado e numero-telefone

Modelo 2: O conjunto de entidades Empregado com o atributo nome-empregado O conjunto de entidades Telefone com os atributos numero-telefone e

localizacao. O conjunto de relacionamentos emp-telefone, o qual denota a associação

entre os empregados e os telefones que podem ter.


Metas Básicas de Projeto de BD (2)

Observações: No primeiro modelo, a definição conceitual implica que

todo empregado possui, precisamente, um número de telefone a ele associado.

No segundo modelo, entretanto, a definição conceitual estabelece que o empregado pode ter vários números de telefones, incluindo zero, a ele associados. Esse modelo é mais geral que o primeiro e pode refletir com maior precisão as situações reais.

Caso seja constatado que cada empregado tem, precisamente, um número de telefone a ele associado, o segundo modelo pode, ainda assim, ser mais apropriado, caso um um mesmo telefone possa ser compartilhado por vários empregados.


No uso de conjunto de entidades e conjuntos de relacionamentos: Nem sempre fica claro se um objeto ou conceito é melhor

expresso por um conjunto de entidades ou por um conjunto de relacionamentos.

Como exemplo, um empréstimo pode ser modelado como uma entidade ou como um relacionamento com os atributos numero-emprestimo e conta?

Relacionamentos binários e n-ários (grau > 2): Ainda que seja possível substituir um conjunto de

relacionamentos não binário (n-ário, para n > 2) por um número distinto de conjuntos de relacionamentos binários, um conjunto de relacionamentos n-ários pode mostrar mais claramente todos os conjuntos de entidades que participam numa determinada relação, ou seja, ilustrar que várias entidades participam num único relacionamento.

Mas há relacionamentos que são naturalmente não binários.

Exemplo: o relacionamento ETA, entre empregado, agencia e tarefa

Metas Básicas de Projeto de BD (3)


Mapeamento de Restrições O contexto semântico de uma empresa pode definir,

por exemplo, certas regras de negócio as quais um Modelo Conceitual de um Banco de Dados deve respeitar e representar por meio de restrições.

Há algumas restrições importantes no Modelo Conceitual de um Banco de Dados, entre elas: O mapeamento de cardinalidades. A existência de dependência entre entidades. O conceito de chave.

O conceito de cardinalidade expressa o número de entidades às quais outra entidade pode estar associada ou relacionada via um conjunto de relacionamentos.

Ou seja, a cardinalidade identifica quantas vezes cada instância de uma entidade pode participar do relacionamento.


Mapeamento de Cardinalidades (1) Num conjunto de relacionamentos binário R entre

os conjuntos de entidades A e B, o mapeamento das cardinalidades ou (rateio das cardinalidades) pode ser dos seguintes tipos: um-para-um (1:1): uma entidade em A está associada no

máximo a uma entidade em B e uma entidade em B está associada a no máximo uma entidade em A.

um-para-muitos (1:M ou 1:N): uma entidade em A está associada a várias entidades em B. Uma entidade em B, entretanto, deve estar associada no máximo a uma entidade em A.

muitos-para-um (M:1 ou N:1): uma entidade em A está associada a no máximo uma entidade em B. Uma entidade em B, entretanto, pode estar associada a um número qualquer de entidades em A.

muitos-para-muitos (M:M ou N:N): uma entidade em A está associada a qualquer número de entidades em B e uma entidade em B está associada a um número qualquer de entidades em A.


um-para-um um-para-muitos

Mapeamento de Cardinalidades (2)


muitos-para-um muitos-para-muitos



O mapeamento das cardinalidades de um relacionamento pode afetar a colocação de atributos nos relacionamentos.

Atributos em conjuntos de relacionamentos um-para-um ou um-para-muitos devem ser associados a um dos conjuntos de entidades participantes, em vez de serem associados ao conjunto de relacionamentos: Atributos de conjuntos de relacionamentos um-para-

muitos podem apenas ser reposicionados no conjunto de entidades do lado “muitos” desse relacionamento.

Em conjuntos de relacionamentos um-para-um, o atributo do relacionamento pode ser associado a qualquer uma das entidades.



Pode-se fazer o atributo data-acesso ser um atributo da entidade Conta, ao invés de um atributo do relacionamento depositante, se cada conta é vinculada a somente um cliente. Ou seja, se o relacionamento depositante, de Conta para Cliente é de muitos-para-um.

Cliente (nome-cliente)depositante

Conta(numero-conta,data-acesso)



A escolha de onde colocar um atributo fica mais clara quando se trata de um conjunto de relacionamentos muitos-para-muitos. Exemplo: seja o cenário onde um cliente pode ter uma ou

mais contas e uma conta pode estar vinculada a um ou mais clientes. Caso se queira expressar a data do último acesso de um cliente a uma determinada conta, o atributo data-acesso deverá ser atribuído ao conjunto de relacionamentos depositante, em vez de ser alocado a uma das duas entidades participantes. Se data-acesso fosse atributo de Conta, não se pode determinar qual dos clientes é responsável pelo acesso mais recente a conta em questão.

Quando um atributo é determinado pela combinação dos conjuntos de entidades participantes em vez de estar associado a cada uma das entidades separadamente, esse atributo precisa ser associado ao conjunto de relacionamentos muitos-para-muitos.



Outra classe importante de restrição é a dependência de existência. Se a existência de uma entidade X depende da existência de uma entidade Y, então a entidade X é denominada dependente da existência de Y. Operacionalmente, se a entidade Y for excluída, o mesmo deve acontecer com a entidade X.

A entidade Y é denominada entidade dominante e a entidade X de entidade subordinada ou dependente. Exemplo: sejam os conjuntos de entidades Emprestimo e

Pagamento, sendo que este último mantém todas as informações de pagamentos realizados por determinado empréstimo e é caracterizado pelos atributos numero-pagamento, data-pagamento e total-pagamento. Cria-se um conjunto de relacionamentos pagamento_emprestimo para esses dois conjuntos de entidades, que é um-para-muitos de Emprestimo para Pagamento. Toda entidade Pagamento está associada a uma entidade Emprestimo. Se uma entidade Emprestimo for removida, todas as entidades Pagamento a ela associadas devem ser excluídas também.

Dependência de Existência


Participação de um Conjunto de Entidades num Conjunto de Relacionamentos

Participação total: toda entidade no conjunto de entidades E participa com no mínimo um relacionamento no conjunto de relacionamentos R. Exemplo: desde que toda entidade Pagamento está

associada a alguma entidade Emprestimo pelo relacionamento pagamento-emprestimo, a participação da entidade Pagamento no conjunto de relacionamentos pagamento-emprestimo é dita ser uma participação total.

Participação parcial (ou opcional): algumas entidades do conjunto de entidades E podem não participar de algum relacionamento no conjunto de relacionamentos R. Exemplo: é possível que apenas parte do conjunto de

entidades Cliente esteja relacionado ao conjunto de entidades Emprestimo e a participação da entidade Cliente no conjunto de relacionamentos devedor é portanto, dita ser uma participação parcial (ou opcional).


Chaves (1)

É importante especificar como as entidades num dado conjunto de entidades e os relacionamentos de um conjunto de relacionamentos podem ser identificados, de maneira distinta ou unívoca.

Conceitualmente, entidades e relacionamentos individuais são distintos.

Entretanto, na perspectiva de uma modelagem conceitual, a diferença entre ambos vai ser estabelecida em termos de seus atributos.

A noção de chave (key) permite fazer tal distinção.


Chaves (2)

Uma superchave é um conjunto de um ou mais atributos que, tomados coletivamente, permite a identificação, de modo unívoco ou distinto, de uma entidade específica num conjunto de entidades.

Exemplo: O atributo seguro-social do conjunto de entidades Cliente. Os atributos nome-cliente e seguro-social do conjunto de

entidades Cliente.


Uma chave candidata de um conjunto de entidades é a menor superchave que pode ser identificada, ou seja, é a superchave para a qual nenhum subconjunto pode ser uma superchave.

Exemplo: O atributo seguro-social é uma chave candidata da entidade

Cliente. A combinação dos atributos (nome-cliente, endereco-

cliente) constitui-se numa chave candidata de Cliente. A combinação dos atributos (seguro-social, endereco-

cliente) não constitui uma chave candidata da entidade Cliente.

Chaves (3)


Ainda que possam haver várias chaves candidatas, usa-se o termo chave primária para caracterizar a chave candidata que é aquela escolhida como de significado especial para a identificação de entidades num conjunto de entidades.

Uma chave (super, candidata e primária) é uma propriedade de um conjunto de entidades.

Quaisquer duas entidades entidades individuais num conjunto de entidades não podem ter, simultaneamente, os mesmos valores em seus atributos-chave.

Chaves (4)


Uma chave primária distingue as várias entidades de um conjunto de entidades. De modo similar, é necessário realizar essa distinção num conjunto de relacionamentos.

Seja R um conjunto de relacionamentos envolvendo os conjuntos de entidades E1,E2,...,En.

Seja k(Ei) o conjunto de atributos que formam a chave primária de Ei . Suponha que todos os nomes de atributos de todas as chaves primárias são diferentes.

Suponha que R não tem atributos. Então, os atributos que distinguem os relacionamentos individuais do conjunto R são:

k(E1) k(E2) ... k(En)

Chaves (5)


Se R tem os atributos a1,a2,...,an então a descrição de um relacionamento em particular do conjunto R é dada por:

k(E1) k(E2) ... k(En) {a1, a2,...,an}

Em ambos os casos, o conjunto de atributos abaixo forma uma superchave do conjunto de relacionamentos R:

k(E1) k(E2) ... k(En)

A estrutura da chave primária para o conjunto de relacionamentos depende também do mapeamento da cardinalidade do conjunto de relacionamentos, ou seja, se o relacionamento é do tipo um-para-muitos ou muitos-para-muitos, por exemplo.

Chaves (6)


Exemplo: Sejam os conjuntos de entidades Cliente e Empregado e o conjunto de relacionamentos cliente-bancario, representando a associação entre um cliente e um bancário (uma entidade Empregado). Suponha que o relacionamento seja de muitos-para-muitos, e também que ele possui o atributo tipo associado, representando a natureza do relacionamento (como um agente de empréstimo ou como um atendente pessoal). A chave primária do relacionamento cliente-bancario constitui-se da união das chaves primárias das entidades Cliente e Empregado.

Entretanto, se um cliente pode ser atendido exclusivamente por um bancário, ou seja, se o relacionamento cliente-bancario é muitos-para-um, então a chave primária de cliente-bancario é simplesmente a chave primária de Cliente. Para os relacionamentos um-para-um, qualquer uma das chaves primárias das entidades participantes do relacionamento pode ser usada.

Chaves (7)


Conjunto de Entidades Fracas (1) Um conjunto de entidades pode não ter atributos

que permitam a formação de uma chave primária.

Esse tipo de conjunto de entidades é denominado de conjunto de entidades fracas. Um conjunto de entidades que possui uma chave primária é denominado de conjunto de entidades fortes. Exemplo: Seja o conjunto de entidades Pagamento com os

atributos numero-pagamento, data-pagamento e total-pagamentos. Embora cada entidade Pagamento seja distinta, os pagamentos de empréstimos diferentes podem compartilhar de um mesmo número.

Para um conjunto de entidades fracas ser significativo, ele deve fazer parte de um conjunto de relacionamentos um-para-muitos.


Conjunto de Entidades Fracas (2) Uma entidade de um conjunto de entidades fortes é

definida como uma entidade dominante, enquanto que uma entidade de um conjunto de entidades fracas é dita ser uma entidade subordinada.

Apesar de um conjunto de entidades fracas não ter chave primária, deve-se procurar um meio de se distinguir as entidades fracas.

O identificador de um conjunto de entidades fracas é um conjunto de atributos que permite que essa distinção seja realizada. Esse identificador também é denominado de chave parcial ou discriminador de um conjunto de entidades fracas. Exemplo: O identificador do conjunto de entidades

Pagamento é o atributo numero-pagamento, e dessa forma, para cada empréstimo, um número de pagamento identifica um determinado pagamento para aquele empréstimo.


Conjunto de Entidades Fracas (3)

A chave primária de um conjunto de entidades fracas é formada pela chave primária do conjunto de entidades fortes ao qual a existência do conjunto de entidades fracas está vinculada mais o identificador do conjunto de entidades fracas. Exemplo: No caso do conjunto de entidades Pagamento,

sua chave primária é composta pelos atributos numero-emprestimo e numero-pagamento, em que o atributo numero-emprestimo identifica a entidade dominante emprestimo e o atributo numero-pagamento identifica a entidade Pagamento dentro de um determinado empréstimo.


Conjunto de Entidades Fracas (4)

O conjunto de entidades dominantes é denominado proprietário do conjunto de entidades fracas por ele dominado. O relacionamento que associa o conjunto de entidades fracas a seu proprietário é denominado de relacionamento identificador. Exemplo: o relacionamento pagamento-emprestimo é o

relacionamento identificador do conjunto de entidades Pagamento e Emprestimo.

Documents

Curso de Banco de Dados 1 Aula 4 - 1 ©Prof. Lineu Mialaret Banco de Dados I – BD I Prof. Lineu Mialaret Aula 4: Modelo Entidade Relacionamento (1) Instituto