Projeto de BDAnálise de Requisitos

Projeto Conceitual

Projeto Lógico

Projeto Físico

Especificação de requisitos

Esquema conceitual

Esquema lógico

Esquema físico ou implementação

Projeto Lógico de BDOO

EntidadesEntidades Classes ClassesRelacionamentosRelacionamentos Atributos AtributosAtributosAtributos Herança Herança HerançaHerança Associação Associação

Diagrama ERDiagrama ER Modelo OOModelo OO(abstração da realidade) (organização de dados)

Modelo ER - Conceitos• Entidade

– normal, fraca ou associativa• Relacionamento

– auto-relacionamento, binário ou n-ário– cardinalidades

• um-para-um, um-para-muitos ou muitos-para-muitos – participação opcional ou obrigatória das

entidades envolvidas• Atributo

– categorias • identificador, monovalorado, multivalorado, composto,

obrigatório e opcional

• Generalização e Especialização– total ou parcial– exclusiva ou não-exclusiva

Modelo ER - Notação

E1 E2

a4 (0,1)a1

r 1

a3

(1,N) (0,3)

r 2

(1,N)

a2 (0,N)

E3(1,1)

(1,N)

E4a8 (1,N)

a7

a5 a6r 3

(0,N)

(1,1)

papel 1

papel 2

E5 E6

p

E7 E8

r 4

E9

(0,N)

(1,1)

r 5

(1,N)

(0,N)

E10

E11

r 6

(1,1)

E12

(0,1)

a9

a10a12 a13

a11

Mapeamento de Entidades

• Entidades tornam-se classes– controle de unicidade de atributos identificadores (CPF, p.ex.) deve ser definido

• Métodos relevantes a nível de instâncias e da classe podem ser previstos

EmpregadosSalárioNomeCPF

CPFNomeSalário

reajustaSalário

Empregados

maiorSalário

(1) Duas classes + atributos de referência OU(2) Entidade fraca como atributo da classe forte

Quantidade

Composição Itens(1,1) (1,N)

Produto

Pedidos

NúmeroNúmeroData

PedidosNúmeroDataItens: SET ( TUPLE ( Número

Produto Quantidade))

(1) (2)

Observações: (i) ‘*’ pode ser SET, BAG ou LIST(ii) (1): acesso direto a instâncias de Itens; é possível modelar relacionamentos de outras classes com Itens (2): menor número de classes; melhor representação de agregação

PedidosNúmeroDataItens *

ItensNúmeroProdutoQuantidadePedido

Entidades Fracas

Relacionamentos

• Análise de 3 casos– 1:1– 1:N– M:N

• Participação obrigatória/opcional da entidade no relacionamento

– se o SGBDOO não dá suporte explícito a estas RIs na ODL, então

– definir métodos de RI

Relacionamentos 1:1(1) Duas classes + atributos de referência OU(2) Classe única com todas as propriedades

ComissõesOrganizaçãoEventos

Code ResponsávelNro LocalNome Data_inst(1,1)(1,1)

(1) Eventos

NomeComissão

ComissõesNroLocalResponsávelEvento

Code

Data_inst

EventosCodeNomeNroComissão

(2)

LocalComissãoResponsávelComissãoData_instComissão

Observação: atributos do relacionamento ficam em alguma das classes em (1)

Relacionamentos 1:N

• Duas classes + atributos de referência

(1,1)(1,N)

Codd NomeSalárioNomeCPF

Empregados DepartamentosLotação

Empregados

Nome

Salário

DepartamentosCoddNome

CPF

Departamento

Empregados *

Relacionamentos 1:N• E se existem atributos no relacionamento? ficam na classe do lado N, definindo um atributo com domínio Tuple (1,1)(1,N)

CoddTempoServiço

NomeSalárioNome

CPF

Empregados DepartamentosLotação

Empregados

Nome

Salário

DepartamentosCoddNome

CPF

Lotação: TUPLE ( Departamento

TempoServiço) Empregados *

Relacionamentos M:N

• Duas classes + atributos de referência

Duração

SalárioNome

(1,N) (0,N)

CodpCPF Título

Empregados ProjetosAlocação

Empregados

Nome

ProjetosCodpTítulo

CPF

Projetos * Empregados *Salário Duração

Relacionamentos M:N• E se existem atributos no relacionamento? (i) o relacionamento fica em uma das classes como um atributo complexo

– menos classes; certas consultas são prejudicadas

Duração

DataInícioSalárioNome

(1,N) (0,N)

CodpCPF Título

Empregados ProjetosAlocação

Período

ProjetosCodpTítuloEmpregados *Duração

Empregados

Nome

Salário

CPF

Alocações: SET( TUPLE ( Projeto

DataInício

Período))

Relacionamentos M:N• E se existem atributos no relacionamento? (ii) pode-se criar uma classe para o relacionamento, com referências bidirecionais

– acesso direto a instâncias de Alocações; mais classes

Duração

DataInícioSalárioNome

(1,N) (0,N)

CodpCPF Título

Empregados ProjetosAlocação

Período

Empregados

NomeCPF

Alocações * Salário

ProjetosCodpTítuloAlocações *Duração

Alocações

ProjetoEmpregado

DataInício Período

Atributos Especiais• Atributo Opcional:

(i) atributo que pode assumir NULL (ii) atributo obrigatório em uma subclasse da

entidade (?)• Atributo Composto: atributo com domínio tuple• Atributo Multivalorado: atributo com domínio set/list

Cidade

Telefone (0,n)

Salário

CPF

Endereço

Rua

Nome

Número

NroHabilitação (0,1)

Empregados

Empregados

NomeSalário

CPF

NroHabilitaçãoTelefone: SET (inteiro)Endereço: TUPLE ( Rua, Número, Cidade)

Herança• Mapeadas diretamente para hierarquias de classes

DataNasc

CPFPessoas

ProfessoresAlunosÁrea

Nome

Matrícula

Curso Titulação

Alunos

CursoMatrícula

ProfessoresÁreaTitulação

DataNasc

Pessoas

NomeCPF

Herança Não-Exclusiva

DataNasc

CPFPessoas

ProfessoresAlunosÁrea

Nome

Matrícula

Curso Titulação

Alunos

CursoMatrícula

ProfessoresÁreaTitulação

DataNasc

Pessoas

NomeCPFObs.: Indicar soluções para

a resolução de conflitos de herança múltipla

ProfessoresAlunos

Entidade Associativa

• Segue as diretrizes para mapeamento de relacionamentos binários

• Exemplo: entidade associativa Escalonamento

Tarefas

ProjetosEmpregados Alocação(1,N)(0,N)

(1,1)

(0,N)CodTDescrição

DataInício

Escalonamento

Período

Execução

Entidade Associativa• Resultado do mapeamento de Escalonamento

Empregados

NomeCPF

Alocações * Salário

ProjetosCodpTítuloAlocações *Duração

Alocações

ProjetoEmpregado

DataInício Período

TarefasCodTDescriçãoAlocação

Tarefas *

Exercício em Grupo

• Sugira mapeamentos para relacionamentos ternários do ER

– considerar 4 casos: M:N:P 1:M:N 1:1:N 1:1:1

justificar as suas sugestões