©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
©Prof. Lineu MialaretAula 9 - 2/51Banco de Dados I
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
©Prof. Lineu MialaretAula 9 - 3/51Banco de Dados I
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.
©Prof. Lineu MialaretAula 9 - 4/51Banco de Dados I
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.
©Prof. Lineu MialaretAula 9 - 5/51Banco de Dados I
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
©Prof. Lineu MialaretAula 9 - 6/51Banco de Dados I
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
©Prof. Lineu MialaretAula 9 - 7/51Banco de Dados I
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
©Prof. Lineu MialaretAula 9 - 8/51Banco de Dados I
(a) CUSTOMER entity with simple attributes
(b) CUSTOMER relation
Conjunto de Entidades Fortes (2)
©Prof. Lineu MialaretAula 9 - 9/51Banco de Dados I
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
©Prof. Lineu MialaretAula 9 - 10/51Banco de Dados I
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
©Prof. Lineu MialaretAula 9 - 11/51Banco de Dados I
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
©Prof. Lineu MialaretAula 9 - 12/51Banco de Dados I
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
©Prof. Lineu MialaretAula 9 - 13/51Banco de Dados I
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
©Prof. Lineu MialaretAula 9 - 14/51Banco de Dados I
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
©Prof. Lineu MialaretAula 9 - 15/51Banco de Dados I
Relacionamento Binário 1:1
Participação Obrigatória das duas Entidades
Professor Ensina Disciplina
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
NomeTel CodDisc PreReq
O atributo CodDisc
também poderia ser chave
primária dessa tabela
©Prof. Lineu MialaretAula 9 - 16/51Banco de Dados I
Relacionamento Binário 1:1
Participação Obrigatória das duas Entidades
Professor Ensina Disciplina
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
NomeTel CodDisc PreReq
©Prof. Lineu MialaretAula 9 - 17/51Banco de Dados I
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
©Prof. Lineu MialaretAula 9 - 18/51Banco de Dados I
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
Relacionamento Binário 1: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
Null Null Null TAP LP
Professor Ensina DisciplinaNDoc
NomeTel CodDisc PreReq
©Prof. Lineu MialaretAula 9 - 19/51Banco de Dados I
Solução:
Professor
Disciplina
São necessárias duas tabelas:Professor (NDoc, Nome, Tel, CodDisc)Disciplina (CodDisc, PreReq)
É uma chave estrangeira
Relacionamento Binário 1:1
NDoc Nome Tel CodDisc
1001 Altino 721334 Alga
977 Ferreira 722876 LP
667 Fragoso 87761 EPPA
778 Nunes 765342 SO
CodDisc PreReq
Alga Nenhum
LP EPPA
EPPA Nenhum
SO LP
TAP LP
©Prof. Lineu MialaretAula 9 - 20/51Banco de Dados I
Regra 3
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 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
©Prof. Lineu MialaretAula 9 - 21/51Banco de Dados I
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.
Relacionamento Binário 1:1
NDoc Nome Tel CodDisc PreReq
Null Null Null ALGA Nenhum
977 Ferreira 722876 LP EPPA
667 Fragoso 87761 EPPA Nenhum
778 Nunes 765342 Null Null
Professor Ensina DisciplinaNDoc
NomeTel CodDisc PreReq
©Prof. Lineu MialaretAula 9 - 22/51Banco de Dados I
Professor Disciplina
Relacionamento Binário 1:1
Participação Obrigatória de nenhuma das Entidades
NDoc Nome Tel CodDisc
1001 Altino 721334 ALGA
977 Ferreira 722876 LP
667 Fragoso 87761 EPPA
778 Nunes 765342 Null
CodDisc PreReq NDoc
ALGA Nenhum Null
LP EPPA 977
EPPA LP 667
Solução:
©Prof. Lineu MialaretAula 9 - 23/51Banco de Dados I
Regra 4
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 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
©Prof. Lineu MialaretAula 9 - 24/51Banco de Dados I
Relacionamento Binário 1:N
ProfessorDisciplina
Participação obrigatória do lado N
NDoc Nome Tel CodDisc PreReq
1001 Altino 721334 ALGA Nenhum
977 Ferreira 722876 LP EPPA
667 Fragoso 87761 EPPA Nenhum
977 Ferreira 765342 SO LP
667 Fragoso 87761 EBD LP
778 Nunes 765342 Null Null
Professor Ensina DisciplinaNDoc
NomeTel CodDisc PreReq
Surgem valores nulos (Null)
sempre que há um professor que não tem
disciplina. Não há como
chavear a tabela
©Prof. Lineu MialaretAula 9 - 25/51Banco de Dados I
Solução:
Professor
Disciplina
São necessárias duas relações:Professor (Ndoc, Nome, Tel)Disciplina (CodDisc, PreReq, NDoc)
Chave estrangeira
Relacionamento Binário 1:N
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
©Prof. Lineu MialaretAula 9 - 26/51Banco de Dados I
Regra 5
Relacionamento Binário 1:N com Participação Obrigatória ou Opcional no lado 1
e Participação Opcional do lado N
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 do lado 1 é usada como atributo (chave estrangeira) na tabela correspondente à entidade do lado N.
©Prof. Lineu MialaretAula 9 - 27/51Banco de Dados I
Participação Opcional de ambos os lados
Relacionamento Binário 1:N
ProfessorDisciplina
NDoc Nome Tel CodDisc PreReq
1001 Altino 721334 ALGA Nenhum
977 Ferreira 722876 LP EPPA
667 Fragoso 87761 EPPA Nenhum
Null Null Null TI SD
977 Ferreira 765342 SO LP
667 Fragoso 87761 EBD LP
778 Nunes 7653342 Null Null
Professor Ensina DisciplinaNDoc
NomeTel CodDisc PreReq
Por que a solução em uma tabela única não
é viável?
©Prof. Lineu MialaretAula 9 - 28/51Banco de Dados I
Solução:
Professor
Disciplina
São necessárias duas relações:Professor (Ndoc, Nome, Tel)Disciplina (CodDisc, PreReq, NDoc)
Chave estrangeira
Relacionamento Binário 1:N
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
©Prof. Lineu MialaretAula 9 - 29/51Banco de Dados I
Regra 6
Mapeamento: São necessárias três tabelas, uma para cada entidade e
uma terceira 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 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
©Prof. Lineu MialaretAula 9 - 30/51Banco de Dados I
Relacionamento Binário M:N (1)
ProfessorDisciplina
NDoc Nome Tel CodDisc PreReq
1001 Altino 721334 ALGA Nenhum
977 Ferreira 722876 LP EPPA
667 Fragoso 87761 EPPA Nenhum
Null Null Null TI SD
977 Ferreira 765342 SO LP
667 Altino 87761 EBD LP
778 Nunes 765342 Null Null
1002 Anacleto 643246 SO LP
988 M Teresa 812354 Null Null
Professor Ensina DisciplinaNDoc
NomeTel CodDisc PreReq
Por que a solução em uma tabela única não
é viável?
©Prof. Lineu MialaretAula 9 - 31/51Banco de Dados I
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:
©Prof. Lineu MialaretAula 9 - 32/51Banco de Dados I
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)
©Prof. Lineu MialaretAula 9 - 33/51Banco de Dados I
(a) Ternary relationship.
Relacionamento Ternário ou Superior (1)
©Prof. Lineu MialaretAula 9 - 34/51Banco de Dados I
(b) Mapping the ternary relationship.
Relacionamento Ternário ou Superior (2)
©Prof. Lineu MialaretAula 9 - 35/51Banco de Dados I
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
©Prof. Lineu MialaretAula 9 - 36/51Banco de Dados I
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
©Prof. Lineu MialaretAula 9 - 37/51Banco de Dados I
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
©Prof. Lineu MialaretAula 9 - 38/51Banco de Dados I
(a) CUSTOMER entity with composite attribute
Mapping a composite attribute.
(b) CUSTOMER relation with address detail
Atributos Compostos
©Prof. Lineu MialaretAula 9 - 39/51Banco de Dados I
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
©Prof. Lineu MialaretAula 9 - 40/51Banco de Dados I
a) Example of a weak entity DEPENDENT.
Entidades Fracas (1)
©Prof. Lineu MialaretAula 9 - 41/51Banco de Dados I
b) Relations resulting from weak entity.
Foreign key
Composite primary key
Entidades Fracas (2)
©Prof. Lineu MialaretAula 9 - 42/51Banco de Dados I
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
©Prof. Lineu MialaretAula 9 - 43/51Banco de Dados I
Mapping a unary 1:N relationship.
(a) EMPLOYEE entity with Manages relationship
(b) EMPLOYEE relation with
recursive foreign key
Relacionamento Recursivo (1)
©Prof. Lineu MialaretAula 9 - 44/51Banco de Dados I
Mapping a unary M:N relationship.
(a) Bill-of-materials relationships (M:N) (b) ITEM and COMPONENT relations
Relacionamento Recursivo (2)
©Prof. Lineu MialaretAula 9 - 45/51Banco de Dados I
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
©Prof. Lineu MialaretAula 9 - 46/51Banco de Dados I
Supertype/subtype relationships.
Relacionamento de Herança (1)
©Prof. Lineu MialaretAula 9 - 47/51Banco de Dados I
Mapping Supertype/subtype relationships to relations
Relacionamento de Herança (2)
©Prof. Lineu MialaretAula 9 - 48/51Banco de Dados I
Relationship_8
Relationship_7
Relationship_6
Relationship_5Relationship_1
Relationship_2
Relationship_3
Relationship_4Entity_7
Attribute_3Attribute_4
Entity_8
Attribute_1Attribute_2
Entity_5
Attribute_3Attribute_4
Entity_6
Attribute_1Attribute_2
Entity_3
Attribute_3Attribute_4
Entity_4
Attribute_1Attribute_2
Entity_2
Attribute_3Attribute_4
Entity_1
Attribute_1Attribute_2
Entity_9
Attribute_3Attribute_4
Entity_10
Attribute_1Attribute_2
Entity_11
Attribute_3Attribute_4
Entity_12
Attribute_1Attribute_2
Entity_13
Attribute_3Attribute_4
Entity_14
Attribute_1Attribute_2
Entity_15
Attribute_3Attribute_4
Entity_16
Attribute_1Attribute_2
MER no PowerDesigner (1)
MER no PowerDesigner com Diversos Tipos de Participações.
©Prof. Lineu MialaretAula 9 - 49/51Banco de Dados I
Relationship_8Relationship_8
Relationship_7Relationship_7
Relationship_6
Relationship_5Relationship_1
Relationship_1
Relationship_2
Relationship_2
Relationship_3
Relationship_3
Relationship_4
Relationship_4Entity_7
Attribute_3Attribute_1Attribute_4
<pk><fk>
Entity_8
Attribute_1Attribute_3Attribute_2
<pk><fk>
Entity_5
Attribute_3Attribute_1Attribute_4
<pk><fk>
Entity_6
Attribute_1Attribute_3Attribute_2
<pk><fk>
Entity_3
Attribute_3Attribute_1Attribute_4
<pk><fk>
Entity_4
Attribute_1Attribute_3Attribute_2
<pk><fk>
Entity_2
Attribute_3Attribute_1Attribute_4
<pk><fk>
Entity_1
Attribute_1Attribute_3Attribute_2
<pk><fk>
Entity_9
Attribute_3Attribute_1Attribute_4
<pk><fk>
Entity_10
Attribute_1Attribute_2
<pk>
Entity_11
Attribute_3Attribute_1Attribute_4
<pk><fk>
Entity_12
Attribute_1Attribute_2
<pk>
Entity_13
Attribute_3Attribute_4
<pk>
Entity_14
Attribute_1Attribute_2
<pk>
Entity_15
Attribute_3Attribute_4
<pk>
Entity_16
Attribute_1Attribute_2
<pk>
Relationship_7
Attribute_1Attribute_3
<pk,fk1><pk,fk2>
Relationship_8
Attribute_1Attribute_3
<pk,fk1><pk,fk2>
Modelo Relacional no PowerDesigner (1)
Modelo Relacional no PowerDesigner Gerado do MER Anterior.
©Prof. Lineu MialaretAula 9 - 50/51Banco de Dados I
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)
©Prof. Lineu MialaretAula 9 - 51/51Banco de Dados I
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.