UML NO PROJETO LÓGICO DE BANCO DE
DADOS: 1ª PARTE

DIAGRAMA DE CLASSES

MODELO RELACIONAL

PROJETO LÓGICO DE BANCO DE DADOS

ELABORANDO O DIAGRAMA
1
I. DIAGRAMA DE CLASSES
 Possibilita uma visão estática do sistema
 Ao elaborarmos um diagrama de classe devemos fazê-lo
numa única perspectiva: conceitual ou de implementação
 Na etapa de projeto lógico de banco de dados deve ser
seguida a perspectiva de implementação.
2
Resumo:
A partir do diagrama de classes elaborado na etapa
de Análise ...
Empregado
id
0..*
nome
data_contrataçao
perc_comissao
Departamento
0..1
id
nome
... e de outras informações obtidas sobre o
sistema, como por exemplo o número de objetos ou
instâncias de uma classe (multiplicidade da classe)
e a freqüência das operações ...
é elaborado o Projeto Lógico de Banco de Dados.
3
Obs: No diagrama de classes pode ser incluída a
multiplicidade da classe
Multiplicidade da classe
Empregado 540
id
nome
data_contratação
perc_comissao
Departamento20
0..*
0..1
id
nome
4
A solução obtida no Projeto Lógico de BD pode ser
representada assim:
Departamento
Coluna
id
Tipo da chave
(PK,FK)
not null/unique
Tabela FK
Coluna FK
Tipo
Tamanho
PK
nome
nn/u
nn/u
NUMBER
VARCHAR2
7
25
Empregado
Coluna
id
Tipo da chave
(PK,FK)
not null/unique
Tabela FK
Coluna FK
Tipo
Tamanho
PK
nn/u
nome
data_contratacao perc_comissao dep_id
FK
nn
nn
nn
dep
id
NUMBER VARCHAR2
7
50
DATE
NUMBER
NUMBER
4,2
7
5
Utilizaremos também uma forma mais simples de
representar o Projeto Lógico de BD, na qual não são
apresentadas algumas das decisões, como tipo e permissão
de nulos:
Sublinhado: chave primária

Departamento (id, nome)
Empregado (id, nome, data_contração, perc_comissão,
dep_id (FK-Departamento-id))

nome da tabela
chave estrangeira
nome da coluna
6
A solução também pode ser representada através do seguinte
diagrama de classes:
7
II. MODELO RELACIONAL
 O modelo de dados relacional foi criado por
E.F.Codd e se baseia no conceito de tabela.
 Um SGBDR (Sistema de Gerência de Banco de
Dados Relacional) é um programa de computador
criado com o objetivo de gerenciar essas tabelas.
8
 Um SGBDR, como definido por Codd, possui três
partes principais:
- Dados, que são apresentados como tabelas.
- Operadores para manipulação de tabelas
- Regras de integridade das tabelas
9
TABELAS
Coluna (atributo)
Nome da tabela
Empregado
Linha
(tupla)
id
nome
data_inicio perc_comissao
dep_id
1
Marta Louzada
12/01/1999
7
2
Pedro Borges
14/02/1999
5
3
Liliane Lisboa
25/02/1999
5
1
4
Leonel Marques
30/02/1999
10
2
1
Departamento
id
nome
1
Brinquedos
2
Eletrodomésticos
Nulo: permitido porque é possível
que um empregado não esteja alocado a
um departamento
10
 Tabela
- Cada tabela é designada por um nome único.
- As tabelas possuem um número específico de colunas e um número arbitrário
de linhas.
- As colunas das tabelas são denominadas atributos. Para cada atributo deve
ser atribuído um domínio.
- Um domínio é um conjunto de valores válidos. Cada valor de uma tabela deve
pertencer ao domínio do seu atributo ou ser nulo. Nulo significa que o valor
do atributo é desconhecido ou não aplicável a uma determinada linha.
- As linhas são denominadas tuplas.
- Um único valor é armazenado em cada interseção coluna - linha.
11
 Operadores de SGBDR
- SQL tornou-se uma linguagem padrão para SGBDR.
Possibilita a definição de dados, sua manipulação e o
controle de acesso dos usuários a esses dados.
 Integridade do SGBDR
- Visa assegurar que mudanças feitas no BD por
usuários autorizados não resultem em dados
inconsistentes.
- Os dois aspectos de integridade no modelo de Codd
são a integridade de entidades e a integridade
referencial.
12
Integridade de entidade
 Exige que cada tabela tenha uma chave primária.
 A chave primária é a combinação de um ou mais atributos,
cujo valor localiza uma única linha em uma tabela.
Chave
primária
Departamento
id
nome
1
Brinquedos
2
Eletrodomésticos
13
Integridade referencial
 Exige que o SGBDR mantenha cada chave estrangeira
consistente com a
chave (primária ou índice único)
correspondente.
 O atributo de uma tabela que referencia uma outra (ou a
mesma) tabela é chamado de chave estrangeira.
 Cada chave estrangeira numa tabela deve ser nula ou
referenciar uma chave (primária ou índice único)
existente na tabela relacionada.
 A ligação entre chave estrangeira e chave primária forma
um caminho de navegação entre as tabelas.
14
Nome da tabela
Coluna (atributo)
Chave
primária
Chave estrangeira
Empregado
Linha
(tupla)
id
nome
data_inicio perc_comissao
dep_id
1
Marta Louzada
12/01/1999
7
2
Pedro Borges
14/02/1999
5
3
Liliane Lisboa
25/02/1999
5
1
4
Leonel Marques
30/02/1999
10
2
nulo
1
Departamento
Chave
primária
id
nome
1
Brinquedos
2
Eletrodomésticos
Obs: caso uma chave estrangeira não possa ter
valores nulos, é necessário especificar essa
condição.
15
III. PROJETO LÓGICO DE BANCO DE DADOS
Algumas das atividades a serem realizadas nesta etapa
incluem as que são descritas a seguir:
 Divisão de classes
 Seleção de chave primária
 Mapeamento das classes e associações em tabelas
16
III.1 Divisão de classes
A divisão pode ser:
- Horizontal: quando trata-se de uma divisão de
instâncias
- Vertical: quando trata-se de uma de divisão de
atributos
17
Horizontal
Ex: A classe Reserva é substituída por duas classes. Todos os
atributos de Reserva são mantidos em Reserva Antiga e Reserva
Atual.
Motivo: melhora de desempenho no acesso a Reserva Atual e na
realização de back-up
R e s e rva A n t ig a
n u m
d a ta
R e s e r va
num
d a ta
R e s e r va A t u a l
n u m
d a ta
Obs: Esta divisão pode reduzir bastante o tempo de back-up off-line, que
dependendo do caso pode até ser diário. Esse back-up seria só de Reserva
Atual. (Back-up on-line reduziria o tempo de acesso e assim uma opção é
torná-lo off-line. Quanto mais rápido esse back-up off-line, melhor)
18
Vertical
Ex: A classe Empregado é substituída por duas classes, cada
uma recebendo parte dos atributos de Empregado .
D a d o s P e s s o a is
C P F
E m
p r e g a d o
C P F
n o m
n o m e
e n d e re ç o
e
te l
e n d e r e ç o
te l
s a lá r io
a v a lia ç ã o
D a d o s S a la ria is
s a lá rio
a va lia ç ã o
Obs: Os SGBDRs permitem a definição de visões diferentes aos diversos
grupos de usuários. Assim, não haveria necessidade de fazer esta divisão.
Num caso bem específico, por exemplo, um sistema distribuído em que essas
tabelas ficassem em servidores diferentes, poderia haver essa indicação
19
III.2 Seleção de chave primária
 Chave primária: a combinação de uma ou mais colunas, cujo
valor localiza uma única linha em uma tabela. Assim, não há
duas ou mais linhas da tabela com o mesmo valor na coluna
ou combinação de colunas que formam a chave primária.
 Integridade de entidade: exige que cada tabela tenha
exatamente uma chave primária.
 Chaves primárias devem ser escolhidas por serem usadas na
maioria dos acessos, devem ser simples e ter tamanho
mínimo.
(obs: se for numérica não precisamos nos preocupar com o tamanho. Mas no
caso de string é bom que tenha tamanho mínimo)
20
III.3 Mapeamento das classes e associações em
tabelas
Associação binária 1:1
C lie n te
C a rtã o L o ja
nom e
n u m e ro
e n d e re ç o
d a ta _ i n íc io
1
0 . .1
Opção 1:

Cliente (id, nome, endereço, numeroCartão, data_início)
Sublinhado - chave primária
21
Cliente
Opção 2:
nome
endereço
CartãoLoja
1
0..1
numero
data_início
Se fosse muito comum clientes não possuírem cartão da loja
então poderíamos adotar a seguinte solução:
 Cliente (id, nome, endereço)
 CartãoLoja (numero, data_início, id_Cliente(FK-Cliente-id))
chave estrangeira
chave primária
nome da tabela
nome da coluna
22
Associação binária 1:N
V endedor
P e d id o
nom e
d a ta
d e s c riç ã o
e n d e re ç o
0 ..*
1
t e le fo n e
Opção 1:
 Pedido (id, data, descrição, id_vendedor(FK-Vendedor-id))
 Vendedor (id, nome, endereço, telefone)
23
Opção 2:
V endedor
P e d id o
nom e
data
d e s c riç ã o
e n d e re ç o
0..*
0..1
t e le fo n e
Se por acaso um pedido pudesse ser emitido sem
vendedor e tivéssemos inúmeros casos desse tipo,
poderíamos adotar a seguinte solução:
 Pedido (id, data, descrição)
 Vendedor (id, nome, endereço, telefone)
 EmitePedido (id_pedido(FK-Pedido-id), id_vendedor
(FK-Vendedor-id))
24
Associação binária M:N
F u n c io n á rio
D e p a rt a m e n t o
nom e
e n d e re ç o
tel
lo c a l
0 . .*
0..*
Lotaç ão
d a t a _ e n t ra d a
d a t a _ s a íd a
 Funcionário (id, nome, endereço, tel)
 Departamento (id, local)
 Lotação (id_func(FK-Funcionário-id), id_dep(FKDepartamento-id), data_entrada, data_saída)
25
Composição
Pedi do.
data
status
Produto
Item
nome
quantidade
1..*
quant_Estoque
0..*
1
Opção 1:
 Pedido (id, data, status)
 Item (id_pedido(FK-Pedido-id), numero_item, quantidade,
id_produto(FK-Produto-id))
 Produto (id, nome, quant_estoque)
26
IV. ELABORANDO O DIAGRAMA DE CLASSES DA
ETAPA DE PROJETO LÓGICO DE BANCO DE
DADOS
1. Considerar o diagrama de classes elaborado na etapa
de Análise e outras informações obtidas sobre o
sistema, como o número de objetos de uma classe, a
freqüência das operações realizadas e o tipo e
tamanho dos atributos.
27
2. Elaborar o projeto lógico de banco de
dados, descrevendo as tabelas
COLUNA
Tipo da chave (PK,FK)
not null/unique
Tabela FK
Coluna FK
Tipo de dados
Tamanho
3. Elaborar o diagrama de classes correspondente
28
Exemplo:
Elaborando o Projeto Lógico de Banco de Dados
do Sistema de controle de pedidos
Obs: Neste exemplo foi considerado apenas o
Diagr. de Classes para a elaboração do Projeto.
29
Diagrama de classes elaborado com uma perspectiva conceitual:
Cliente
código
CPF
nome
endereço
1
telefone [0..1]
eMail [0..1]
Fatura
Pedido
faz ->
1..*
1
0..*
numFatura
dataEmissão
dataVencimento
valorPago [0..1]
dataPagamento [0..1]
0..*
dataPedidoCancelamento [0..1]
dataCancelamento [0..1]
status
Item faturado
quantFaturada
{ Se uma fatura atende a um
pedido, necessariamente os itens
pedidos ligados à fatura devem ser
do pedido ao qual a fatura está
relacionada }
numPedido
dataEmissão
nomePresenteado [0..1]
endereçoEntrega
dataCancelamento [0..1]
status
1..*
Item pedido
quantidadePedida
1..* preçoCobrado
0..*
1
Livro
isbn
título
descrição
quantEstoque
preço
prazoMédioEntrega
30
Tabelas:
CLIENTE
COLUNA
Tipo da chave
(PK,FK)
not null/unique
Tabela FK
Coluna FK
Tipo de dados
Tamanho
ID
PK
CPF
NOME
ENDERECO TELEFONE
E_MAIL
nn/u
nn/u
nn
nn
NUMBER
VARCHAR2
VARCHAR2
VARCHAR2
NUMBER
VARCHAR2
7
20
50
50
20
50
PEDIDO
COLUNA
Tipo da chave
(PK,FK)
not null/unique
Tabela FK
Coluna FK
Tipo de dados
Tamanho
ID
DT_EMISSAO NOME_PRE ENDERECO DT_CANCELA
SENTEADO _ENTREGA
MENTO
STATUS ID_CLIENTE
PK
FK
nn/u
nn
NUMBER
DATE
7
nn
VARCHAR2
VARCHAR2
50
50
DATE
nn
nn
CLIENTE
ID
CHAR
NUMBER
1
7
31
LIVRO
COLUNA
Tipo da chave
(PK,FK)
not null/unique
Tabela FK
Coluna FK
Tipo de dados
Tamanho
ISBN
TITULO
DESCRICAO
QUANT_
ESTOQUE
PRECO
PRAZO_MEDIO
_ENTREGA
nn/u
nn
nn
nn
nn
nn
VARCHAR2
VARCHAR2
VARCHAR2
NUMBER
NUMBER
NUMBER
20
50
2000
9
9,2
9
PK
ITEM_PEDIDO
COLUNA
Tipo da chave
(PK,FK)
not null/unique
Tabela FK
Coluna FK
Tipo de dados
Tamanho
ID_PEDIDO
NUM_ITEM
QUANT_PEDI PRECO_CO
DA
BRADO
ID_LIVRO
FK/PK
PK
nn
PEDIDO
ID
nn
nn
nn
nn
LIVRO
ISBN
NUMBER
NUMBER
NUMBER
NUMBER
VARCHAR2
7
7
9
9,2
20
FK
32
FATURA
COLUNA
Tipo da chave
(PK,FK)
not null/unique
Tabela FK
Coluna FK
Tipo de dados
Tamanho
ID
DT_EMIS DT_VENCI VALOR_PA
SAO
MENTO
GO
DT_PAGA DT_PEDIDO_ DT_CAN
MENTO CANCELAM CELAME
ENTO
NTO
STATUS ID_PEDI
DO
PK
FK
nn/u
nn
nn
NUMBER
DATE
DATE
7
NUMBER
DATE
DATE
DATE
9,2
nn
nn
PEDIDO
ID
CHAR
NUMBER
1
7
ITEM_FATURADO
COLUNA
Tipo da chave
(PK,FK)
not null/unique
Tabela FK
Coluna FK
Tipo de dados
Tamanho
ID_FATURA
FK/PK
ID_ PEDIDO
FK/PK
ID_ITEM
FK/PK
QUANT_FATURADA
nn
FATURA
ID
nn
nn
nn
NUMBER
7
ITEM_PEDIDO
ID_PEDIDO
NUM_ITEM
NUMBER
7
NUMBER
7
NUMBER
9
33
Diagrama de classes representando as tabelas:
<<RelationalTable>>
CLIENTE
ID : VARCHAR2
<<FK>>
CPF : VARCHAR2
PEDIDO_CLIENTE_FK
NOME : VARCHAR2
ID_CLIENTE = ID
ENDERECO : VARCHAR2
TELEFONE : NUMBER
E_MAIL : VARCHAR2
CLIENTE_PK = ID
<<FK>>
<<RelationalTable>>
PEDIDO
ID : VARCHAR2
DT_EMISSAO : DATE
NOME_PRESENTEADO : VARCHAR2
ENDERECO_ENTREGA : VARCHAR2
DT_CANCELAMENTO : DATE
STATUS : CHAR
PEDIDO_PK = ID
FATURA_PEDIDO_FK
<<FK>>
ITEMPEDIDO_PED_FK
<<RelationalTable>>
FATURA
ID_PEDIDO = ID
ID : VARCHAR2
DT_EMISSAO : DATE
DT_VENCIMENTO : DATE
VALOR_PAGO : NUMBER
DT_PAGAMENTO : DATE
DT_PEDIDO_CANCELAMENTO : DATE
DT_CANCELAMENTO : DATE
STATUS : CHAR
FATURA_PK = ID
<<FK>>
ITEMFAT_FATURA_FK
ID_FATURA = ID
ID_PEDIDO = ID
<<RelationalTable>>
ITEM_PEDIDO
NUM_ITEM : NUMBER
QUANT_PEDIDA : NUMBER
PRECO_COBRADO : NUMBER
ITEM_PEDIDO_PK = ID_PEDIDO,NUM_ITEM
<<FK>>
ITEMFAT_ITEMPED_FK
ID_PEDIDO = ID_PEDIDO
ID_ITEM = NUM_ITEM
<<RelationalTable>>
ITEM_FATURADO
QUANT_FATURADA : NUMBER
ITEM_FATURADO_PK = ID_FATURA,ID_PEDIDO,ID_ITEM
ID_LIVRO = ISBN
ITEMPEDIDO_LIVRO_FK
<<FK>>
<<RelationalTable>>
LIVRO
ISBN : VARCHAR2
TITULO : VARCHAR2
DESCRICAO : VARCHAR2
QUANT_ESTOQUE : NUMBER
PRECO : NUMBER
PRAZO_MEDIO_ENTREGA : NUMBER
LIVRO_PK = ISBN
34
Exercício
Desenvolva o projeto de Banco de Dados para o
Sistema da PETROBRAS
35