Banco de Dados I – BD I Prof. Lineu Mialaret Aula 9: Mapeamento MER – Modelo Relacional

©Prof. Lineu MialaretAula 9 - 1/51Banco de Dados I

Banco de Dados I – BD I Prof. Lineu Mialaret

Aula 9: Mapeamento MER – Modelo Relacional

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


Modelo Físico

Modelo Lógico

Modelo ConceitualRequisito

s

+

Regras de

Negócio

BD Operacional

Visão de Negócio

Visão de Sistema

Desenvolvimento de um um Aplicativo de Banco de Dados A

ná

liseP

roje

to

Modelo Funcional

Mapeamento


Introdução

Um Banco de Dados em conformidade com o Modelo Entidade Relacionamento - MER pode ser representado por uma coleção de tabelas no Modelo Lógico Relacional ou Modelo Relacional.

Para cada conjunto de entidades (e dependendo do tipo de conjunto de relacionamentos) há, internamente no Banco de Dados Relacional, em princípio uma tabela única, registrando o nome do conjunto de entidades (ou relacionamentos) correspondente.

Tanto o MER quanto o Modelo Relacional são abstratos, ou seja, são representações abstratas e lógicas de domínios de conhecimento, os quais podem representar empresas reais.

Como esses dois modelos empregam princípios similares, pode-se converter, de maneira adequada, o Modelo Entidade Relacionamento - MER num Modelo Relacional.

Em ferramentas CASE robustas, esse mapeamento é realizado de forma transparente ao usuário.


Mapeamento do MER para o Modelo Relacional

Passos gerais para o mapeamento MER - Modelo Relacional:

Identificar todas as entidades, atributos e relacionamentos para o contexto de negócio.

Construir o Modelo Entidade Relacionamento – MER.

Encontrar o conjunto de tabelas preliminares e identificar as suas respectivas chaves primárias.

Identificar todos os atributos relevantes e associá-los às tabelas preliminares já definidas.

Há uma série de regras para realizar o devido mapeamento do Modelo Entidade Relacionamento para o Modelo Relacional.


Diagrama de Entidade-Relacionamento

Entidade: algo relativo a um domínio de conhecimento (problema) a ser tratado e sobre a qual há um interesse em armazenar e manipular dados e informação.

Relacionamento: ligação semântica entre entidades.

Atributo: propriedade de uma entidade (em certos casos também de um relacionamento).

Notação 1(Chen)

Notação 2(EI)

Professor Ensina DisciplinaNDoc

NomeTel CodDisc PreReq

Ensina

Professor

NDocNomeTel

Disciplina

CodDiscPreReq


Regra 0

Mapeamento: É necessária apenas uma tabela para representar a

entidade. A chave primária dessa entidade se torna a chave primária

da tabela relacional.

Conjunto de Entidades Fortes


Conjunto de Entidades Fortes (1) Um conjunto de entidades fortes se transforma numa tabela no Modelo

Relacional com os mesmos atributos.

JonesSmithHayes

321-12-3123019-28-3746677-89-9011

MainNorthMain

HarrisonRye

Harrison

customer-name customer-id customer-street customer-city

customer relation


(a) CUSTOMER entity with simple attributes

(b) CUSTOMER relation

Conjunto de Entidades Fortes (2)


Grafo de Ocorrências ou Cardinalidade O grafo de ocorrências ou cardinalidade exemplifica os relacionamentos que ocorrem entre as entidades de conjuntos de entidades. A associação que ocorre entre conjuntos de entidades é definida como uma participação, a qual pode ser obrigatória ou opcional.

Professor Ensina Disciplina

P1 •P2 •P3 •P4 •

• D1• D2• D3• D4

Participação obrigatória

Participação opcional

Notação Chen usada para se referir a participação.

Professor Professor


Participação – Relacionamento 1:1

P1 •P2 •P3 •P4 •

• D1• D2• D3• D4

P1 •P2 •P3 •

• D1• D2• D3• D4

P1 •P2 •P3 •P4 •

• D1• D2• D3

P1 •P2 •P3 •P4 •

• D1• D2• D3• D4

Professor

Professor

Professor

Professor

Disciplina

Disciplina

Disciplina

Disciplina


P1 •P2 •P3 •

• D1• D2• D3• D4• D5

P1 •P2 •P3 •

• D1• D2• D3• D4

P1 •P2 •P3 •P4 •

• D1• D2• D3• D4• D5

P1 •P2 •P3 •

• D1• D2• D3• D4• D5

Participação - Relacionamento 1:N

Professor

Professor

Professor

Professor

Disciplina

Disciplina

Disciplina

Disciplina


P1 •P2 •P3 •P4 •P5 •

• D1• D2• D3• D4

P1 •P2 •P3 •P4 •P5 •

• D1• D2• D3• D4

P1 •P2 •P3 •P4 •

• D1• D2• D3

P1 •P2 •P3 •P4 •P5 •

• D1• D2• D3

Participação – Relacionamento N:1

Professor

Professor

Professor

Professor

Disciplina

Disciplina

Disciplina

Disciplina


P1 •P2 •P3 •P4 •P5 •

• D1• D2• D3• D4• D5

P1 •P2 •P3 •P4 •P5 •

• D1• D2• D3• D4• D5

• D1• D2• D3• D4

P1 •P2 •P3 •P4 •P5 •

P1 •P2 •P3 •P4 •P5 •

• D1• D2• D3• D4• D5

Participação - Relacionamento N:M

Professor

Professor

Professor

Professor

Disciplina

Disciplina

Disciplina

Disciplina


Regra 1

Mapeamento Solução 1:

É necessária apenas uma tabela. A chave primária dessa tabela pode ser a chave primária de

qualquer uma das entidades envolvidas no relacionamento.

Solução 2: São necessárias duas tabelas, cada uma representando uma

entidade, e a chave primária de cada uma das tabelas se torna a chave estrangeira (foreign key) da outra tabela. (Isto implica que há uma navegação bidirecional. Pode ser usada uma solução que implique numa navegação parcial)

Relacionamento Binário 1:1 e Participação Obrigatória de Ambas as Entidades


Relacionamento Binário 1:1

Participação Obrigatória das duas Entidades


Solução 1:ProfessorDisciplina

NDoc Nome Tel CodDisc PreReq

1001 Altino 721334 ALGA Nenhum

977 Ferreira 722876 LP EPPA

667 Fragoso 87761 EPPA Nenhum

778 Nunes 765342 SO LP

NDoc


O atributo CodDisc

também poderia ser chave

primária dessa tabela



Participação Obrigatória das duas Entidades


Solução 2:Professor Disciplina

chave estrangeira chave estrangeira

NDoc Nome Tel CodDisc

1001 Altino 721334 ALGA

977 Ferreira 722876 LP

667 Fragoso 87761 EPPA

778 Nunes 765342 SO

CodDisc PreReq NDoc

ALGA Nenhum 1001

LP EPPA 977

EPPA LP 667

SO LP 778

NDoc



Regra 2

Mapeamento: São necessárias duas tabelas, uma para cada entidade.

A chave primária de cada entidade serve de chave primária na tabela correspondente.

A chave primária da entidade com participação não obrigatória é usada como atributo (chave estrangeira) na tabela correspondente à entidade cuja participação é obrigatória.

Relacionamento Binário 1:1 e Participação Obrigatória de apenas uma das Entidades


Participação Obrigatória de apenas uma das Entidades

Surgem valores nulos (Null)

sempre que há uma disciplina que não tem

professor. Essa solução é

válida, mas não adequada


ProfessorDisciplina





778 Nunes 765342 SO LP

Null Null Null TAP LP




Solução:

Professor

Disciplina

São necessárias duas tabelas:Professor (NDoc, Nome, Tel, CodDisc)Disciplina (CodDisc, PreReq)

É uma chave estrangeira



1001 Altino 721334 Alga



778 Nunes 765342 SO

CodDisc PreReq

Alga Nenhum

LP EPPA

EPPA Nenhum

SO LP

TAP LP


Regra 3



A chave primária de cada uma das tabelas se torna chave estrangeira (foreign key) da outra.

Relacionamento Binário 1:1 e Participação Opcional de ambas Entidades


Participação Obrigatória de nenhuma das Entidades

ProfessorDisciplina

Surgem valores nulos (Null) quer para as disciplinas que não têm professor, quer para os professores que não lecionam nenhuma disciplina. Não há como chavear a tabela.



Null Null Null ALGA Nenhum



778 Nunes 765342 Null Null




Professor Disciplina


Participação Obrigatória de nenhuma das Entidades


1001 Altino 721334 ALGA



778 Nunes 765342 Null

CodDisc PreReq NDoc

ALGA Nenhum Null

LP EPPA 977

EPPA LP 667

Solução:


Regra 4



A chave primária da entidade do lado 1 é usada como atributo (chave estrangeira) na tabela correspondente à entidade do lado N.

Relacionamento Binário 1:N com Participação Obrigatória ou Opcional no lado 1

e Participação Obrigatória do lado N


Relacionamento Binário 1:N

ProfessorDisciplina

Participação obrigatória do lado N





977 Ferreira 765342 SO LP

667 Fragoso 87761 EBD LP




Surgem valores nulos (Null)

sempre que há um professor que não tem

disciplina. Não há como

chavear a tabela


Solução:

Professor

Disciplina

São necessárias duas relações:Professor (Ndoc, Nome, Tel)Disciplina (CodDisc, PreReq, NDoc)

Chave estrangeira


NDoc Nome Tel

1001 Altino 721334

977 Ferreira 722876

667 Fragoso 87761

778 Nunes 765342

CodDisc PreReq NDoc

ALGA Nenhum 1001

LP EPPA 977

EPPA Nenhum 667

SO LP 977

EBD LP 667


Regra 5

Relacionamento Binário 1:N com Participação Obrigatória ou Opcional no lado 1

e Participação Opcional do lado N



A chave primária da entidade do lado 1 é usada como atributo (chave estrangeira) na tabela correspondente à entidade do lado N.


Participação Opcional de ambos os lados


ProfessorDisciplina





Null Null Null TI SD


667 Fragoso 87761 EBD LP




Por que a solução em uma tabela única não

é viável?


Solução:

Professor

Disciplina

São necessárias duas relações:Professor (Ndoc, Nome, Tel)Disciplina (CodDisc, PreReq, NDoc)

Chave estrangeira


NDoc Nome Tel

1001 Altino 721334

977 Ferreira 722876

667 Fragoso 87761

778 Nunes 765342

CodDisc PreReq NDoc

ALGA Nenhum 1001

LP EPPA 977

EPPA Nenhum 667

SO LP 977

EBD LP 667

TI SD Null


Regra 6

Mapeamento: São necessárias três tabelas, uma para cada entidade e

uma terceira para o relacionamento.


A tabela relativa ao relacionamento terá de ter entre os seus atributos chaves (que compõem a chave primária da tabela) as chaves primárias de cada uma das entidades envolvidas no relacionamento.

Relacionamento Binário M:N


Relacionamento Binário M:N (1)

ProfessorDisciplina





Null Null Null TI SD


667 Altino 87761 EBD LP


1002 Anacleto 643246 SO LP

988 M Teresa 812354 Null Null



Por que a solução em uma tabela única não

é viável?


Relacionamento Binário M:N (2)

Quando o relacionamento binário é M:N, e independentemente do tipo de participação, são sempre necessárias três tabelas.

Professor Disciplina

EnsinaNDoc Nome Tel

1001 Altino 721334

977 Ferreira 722876

667 Frgoso 87761

778 Nunes 765342

1002 Anacleto 643246

988 M Teresa 812354

NDoc CodDisc

1001 ALGA

977 LP

667 EPPA

977 SO

667 EBD

1002 SO

CodDisc PreReq

ALGA Nenhum

LP EPPA

EPPA Nenhum

TI SD

SO LP

EBD LP

Solução:


Regra 7

Mapeamento: São sempre necessárias quatro tabelas, uma para cada

entidade e uma quarta para o relacionamento. A chave primária de cada entidade serve de chave primária

na tabela correspondente. A tabela relativa ao relacionamento terá de ter entre os seus

atributos chave (que compõem a chave primária da tabela) as chaves primárias de cada uma das outras tabelas.

Em relacionamentos de grau N são necessárias N+1 tabelas, de modo inteiramente com o mapeamento de mode análogo.

Relacionamento Ternário (e superior)


(a) Ternary relationship.

Relacionamento Ternário ou Superior (1)


(b) Mapping the ternary relationship.

Relacionamento Ternário ou Superior (2)


Mapeamento: É necessária uma tabela para a entidade (ou relacionamento) e seus atributos que não são multivalorados.

Cria-se uma nova tabela R que inclui como atributos o atributo multivalorado A mais a chave primária K da tabela que representa a entidade (ou relacionamento) que tem A como atributo.

A chave primária de R é a combinação de A e K.

Atributos Multivalorados

Regra 8


a) Mapping a multivalued attribute. Multivalued attribute becomes a separate relation with foreign key.

b) 1:M relationship between original entity and new relation.

(a)

(b)

Atributos Multivalorados


Mapeamento: É necessária uma tabela para a entidade (ou relacionamento) e

seus atributos que não são compostos. Se o atributo é composto, incluir seus componentes atômicos na tabela correspondente à entidade que possui esse atributo.

Atributos Compostos

Regra 9


(a) CUSTOMER entity with composite attribute

Mapping a composite attribute.

(b) CUSTOMER relation with address detail

Atributos Compostos


Mapeamento:

Para cada entidade fraca W relacionada com uma entidade forte E, cria-se uma tabela R e incluí-se todos os atributos simples de W como atributos de R.

Incluí-se como atributos da chave estrangeira de R os atributos que compõem a chave primária da entidade forte E.

A chave primária da tabela R é a combinação da chave primária da entidade forte E (que é chave estrangeira em W) e a chave parcial da entidade fraca W.

Regra 10

Entidades Fracas


a) Example of a weak entity DEPENDENT.

Entidades Fracas (1)


b) Relations resulting from weak entity.

Foreign key

Composite primary key

Entidades Fracas (2)


Mapeamento: Para relacionamentos recursivos 1:N -

Usar de uma chave estrangeira recursiva (um atributo que referencia o atributo chave da própria tabela) na mesma tabela.

Para relacionamentos recursivos M:N - Criar duas tabelas, sendo uma para a entidade envolvida.

A outra tabela é usada para representar o relacionamento recursivo, sendo que sua chave primária possui dois atributos, ambos tomados da chave primária da entidade.

Regra 11

Relacionamento Recursivo


Mapping a unary 1:N relationship.

(a) EMPLOYEE entity with Manages relationship

(b) EMPLOYEE relation with

recursive foreign key

Relacionamento Recursivo (1)


Mapping a unary M:N relationship.

(a) Bill-of-materials relationships (M:N) (b) ITEM and COMPONENT relations

Relacionamento Recursivo (2)


Mapeamento: É criada uma tabela para o supertipo e uma tabela para cada subtipo.

Os atributos do supertipo (incluindo as suas chaves) são mapeados para uma tabela correspondente.

os atributos dos subtipos são mapeados para tabelas correspondentes aos subtipos, e a chave primária do supertipo se torna chave primária (chave estrangeira) do subtipo.

Regra 12

Relacionamento de Herança


Supertype/subtype relationships.

Relacionamento de Herança (1)


Mapping Supertype/subtype relationships to relations

Relacionamento de Herança (2)


Relationship_8

Relationship_7

Relationship_6

Relationship_5Relationship_1

Relationship_2

Relationship_3

Relationship_4Entity_7

Attribute_3Attribute_4

Entity_8


Entity_5


Entity_6


Entity_3


Entity_4


Entity_2


Entity_1


Entity_9


Entity_10


Entity_11


Entity_12


Entity_13


Entity_14


Entity_15


Entity_16


MER no PowerDesigner (1)

MER no PowerDesigner com Diversos Tipos de Participações.




Relationship_6


Relationship_1

Relationship_2

Relationship_2

Relationship_3

Relationship_3

Relationship_4

Relationship_4Entity_7

Attribute_3Attribute_1Attribute_4

<pk><fk>

Entity_8


<pk><fk>

Entity_5


<pk><fk>

Entity_6


<pk><fk>

Entity_3


<pk><fk>

Entity_4


<pk><fk>

Entity_2


<pk><fk>

Entity_1


<pk><fk>

Entity_9


<pk><fk>

Entity_10


<pk>

Entity_11


<pk><fk>

Entity_12


<pk>

Entity_13


<pk>

Entity_14


<pk>

Entity_15


<pk>

Entity_16


<pk>

Relationship_7


<pk,fk1><pk,fk2>

Relationship_8


<pk,fk1><pk,fk2>

Modelo Relacional no PowerDesigner (1)

Modelo Relacional no PowerDesigner Gerado do MER Anterior.


Inheritance_1

Employee

EmployeeNumberEmployeeNameAddressEmployeeTypeData_Hired

HourlyEmployee

Hourly_Rate

SalariedEmployee

Annual_SalaryStock_Options

Consultor

Contract_NumberBilling_Rate

MER com Herança no PowerDesigner.

MER no PowerDesigner (2)


Modelo Relacional no PowerDesigner (2)

Inheritance_1

Inheritance_1

Inheritance_1

Employee

EmployeeNumberEmployeeNameAddressEmployeeTypeData_Hired

<pk>

HourlyEmployee

H_EmployeeNumberHourly_Rate

<pk,fk>

SalariedEmployee

E_EmployeeNumberAnnual_SalaryStock_Options

<pk,fk>

Consultor

C_EmployeeNumberContract_NumberBilling_Rate

<pk,fk>

Modelo Relacional Gerado no PowerDesigner com Base no MER Anterior.

Documents

Banco de Dados I – BD I Prof. Lineu Mialaret Aula 9: Mapeamento MER – Modelo Relacional