A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Campus de Caraguatatuba Aula 4: Modelo Entidade Relacionamento (1)

Apresentações semelhantes


Apresentação em tema: "Campus de Caraguatatuba Aula 4: Modelo Entidade Relacionamento (1)"— Transcrição da apresentação:

1 Campus de Caraguatatuba 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 Semestre de 2013 Banco de Dados I – BD I Prof. Lineu Mialaret Aula 4: Modelo Entidade Relacionamento (1)

2 Desenvolvimento de BD (1)
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 OO

3 Desenvolvimento de BD (2)
Modelo Físico Modelo Lógico Modelo Conceitual Requisitos + Regras de Negócio BD Operacional Visão de Negócio Visão de Sistema Análise Projeto Modelo Funcional

4 1.1 - Visualizar Lista de Itens Bibliograficos
Desenvolvimento de BD (3) 3 - Login «include» 1.1 - Visualizar Lista de Itens Bibliograficos «extend» Pesquisador «extend» 1.4 - Incluir Itens «extend» 1.2 - Modificar Itens 1.3 - Remover Itens Quais os conceitos importantes (concretos e abstratos) envolvidos na execução dessas funcionalidades?

5 Modelos de BD (1) 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.

6 Modelos de BD (2) 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.

7 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.

8 Contextualização (1) 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.

9 Contextualização (2) 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.

10 Contextualização (3) 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.

11 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.

12 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.

13 Conjunto de Entidades (3)
cliente-id nome rua cidade numero valor cliente cliente cliente empréstimo Cliente Emprestimo Exemplo dos conjuntos de entidades Cliente e Emprestimo.

14 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.

15 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.

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

17 Conjunto de Relacionamentos (1)
Um relacionamento é uma associação (conexão semântica) entre entidades. Exemplo: Hayes depositante A-102 entidade 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. emprestimo 1 agencia-emprestimo emprestimo 2 agencia 10

18 Conjunto de Relacionamentos (2)
cliente-id nome rua cidade numero valor cliente cliente cliente emprestimo devedor E1 E2 Cliente Emprestimo Exemplo do conjunto de relacionamentos devedor.

19 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.

20 Conjunto de Relacionamentos (4)
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. Cliente (nome-cliente) depositante(data-acesso) Conta(numero-conta)

21 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.

22 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.

23 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.

24 Metas Básicas de Projeto de BD (3)
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

25 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.

26 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.

27 Mapeamento de Cardinalidades (2)
um-para-um um-para-muitos

28 Mapeamento de Cardinalidades (3)
muitos-para-um muitos-para-muitos

29 Mapeamento de Cardinalidades (4)
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.

30 Cliente (nome-cliente) Conta(numero-conta,data-acesso)
Mapeamento de Cardinalidades (5) 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)

31 Mapeamento de Cardinalidades (6)
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.

32 Dependência de Existência
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.

33 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).

34 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.

35 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.

36 Chaves (3) 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.

37 Chaves (4) 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.

38 Chaves (5) 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)

39 Chaves (6) 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.

40 Chaves (7) 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.

41 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.

42 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.

43 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.

44 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.


Carregar ppt "Campus de Caraguatatuba Aula 4: Modelo Entidade Relacionamento (1)"

Apresentações semelhantes


Anúncios Google