1

DIAGRAMA DE CLASSES

MODELO RELACIONAL

PROJETO LÓGICO DE BANCO DE DADOS

ELABORANDO O DIAGRAMA

UML NO PROJETO LÓGICO DE BANCO DE DADOS: 1ª PARTE

2

I . DIAGRAMA DE CLASSES

Possibilita uma visão estática do sistema

Ao elaborarmos um diagrama de classe devemos f azê-lonuma única perspectiva: conceitual ou de implementação

Na etapa de projeto lógico de banco de dados deve serseguida a perspectiva de implementação.

3

Resumo:A partir do diagrama de classes elaborado na etapa de Análise ...

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

Departamento

id

nome

Empregado

id

nome

data_contrataçao

perc_comissao

0..10..* 0..10..*

4

Obs: No diagrama de classes pode ser incluída a multiplicidade da classe

Departamento

idnome

Empregado

idnomedata_contrataçãoperc_comissao

0..10..* 0..10..*

540

20

Multiplicidade da classe

5

A solução obtida no Projeto Lógico de BD pode ser representada assim: Departamento

Coluna id nome

Tipo da chave (PK,FK)

PK

not null/unique nn/ u nn/ u

Tabela FK

Coluna FK

Tipo NUMBER VARCHAR2

Tamanho 7 25

Empregado

Coluna id nome data_contratacao perc_comissao dep_id

Tipo da chave (PK,FK)

PK FK

not null/unique nn/ u nn nn nn

Tabela FK dep

Coluna FK id

Tipo NUMBER VARCHAR2 DATE NUMBER NUMBER

Tamanho 7 50 4,2 7

6

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:

Departamento (id, nome)

Empregado (id, nome, data_contração, perc_comissão, dep_id (FK-Departamento-id))

Sublinhado: chave primária

chave estrangeiranome da tabela

nome da coluna

7

A solução também pode ser representada através do seguinte diagrama de classes:

DEPARTAMENTO

ID : NUMBERNOME : VARCHAR2DEPARTAMENTO_ID_PK = ID

<<RelationalTable>>EMPREGADO

ID : NUMBERNOME : VARCHAR2DATA_CONTRATACAO : DATEPERC_COMISSAO : NUMBEREMPREGADO_ID_PK = ID

<<RelationalTable>>

DEP_ID = IDDEP_ID = IDEMP_DEP_ID_FK

<<FK>>

8

I I . MODELO RELACIONAL

O modelo de dados relacional f oi criado porE.F.Codd e se baseia no conceito de tabela.

Um SGBDR (Sistema de Gerência de Banco deDados Relacional) é um programa de computadorcriado com o objetivo de gerenciar essas tabelas.

9

Um SGBDR, como defi nido por Codd, possui trêspartes principais:

- Dados, que são apresentados como tabelas.

- Operadores para manipulação de tabelas

- Regras de integridade das tabelas

10

TABELAS

Empregado

id nome data_inicio perc_comissao dep_id

1 Marta Louzada 12/ 01/ 1999 7 1

2 Pedro Borges 14/ 02/ 1999 5

3 Liliane Lisboa 25/ 02/ 1999 5 1

4 Leonel Marques 30/ 02/ 1999 10 2

Departamento

id nome

1 Brinquedos

2 Eletrodomésticos

Linha(tupla)

Coluna (atributo)Nome da tabela

Nulo: permitido porque é possívelque um empregado não esteja alocado aum departamento

11

Tabela

- Cada tabela é designada por um nome único.

- As tabelas possuem um número específico de colunas e um número arbitráriode linhas.

- As colunas das tabelas são denominadas atributos. Para cada atributo deveser atribuído um domínio.

- Um domínio é um conjunto de valores válidos. Cada valor de uma tabela devepertencer ao domínio do seu atributo ou ser nulo. Nulo significa que o valordo 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.

12

Operadores de SGBDR

- SQL tornou-se uma linguagem padrão para SGBDR.Possibilita a defi nição de dados, sua manipulação e ocontrole de acesso dos usuários a esses dados.

I ntegridade do SGBDR

- Visa assegurar que mudanças f eitas no BD porusuários autorizados não resultem em dadosinconsistentes.

- Os dois aspectos de integridade no modelo de Coddsão a integridade de entidades e a integridadereferencial.

13

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

Departamento

id nome

1 Brinquedos

2 Eletrodomésticos

Chave primária

14

I ntegridade referencial

Exige que o SGBDR mantenha cada chave estrangeiraconsistente com a chave (primária ou índice único)correspondente.

O atributo de uma tabela que ref erencia uma outra (ou amesma) tabela é chamado de chave estrangeira.

Cada chave estrangeira numa tabela deve ser nula oureferenciar uma chave (primária ou índice único)existente na tabela relacionada.

A ligação entre chave estrangeira e chave primária f ormaum caminho de navegação entre as tabelas.

15

Chave estrangeiraEmpregado

id nome data_inicio perc_comissao dep_id

1 Marta Louzada 12/ 01/ 1999 7 1

2 Pedro Borges 14/ 02/ 1999 5

3 Liliane Lisboa 25/ 02/ 1999 5 1

4 Leonel Marques 30/ 02/ 1999 10 2

Departamento

id nome

1 Brinquedos

2 Eletrodomésticos

nuloLinha(tupla)

Nome da tabela

Chave primária

Coluna (atributo)

Chave primária

Obs: caso uma chave estrangeira não possa ter valores nulos, é necessário especificar essa condição.

16

I I I . PROJ ETO LÓGICO DE BANCO DE DADOS

Algumas das atividades a serem realizadas nesta etapaincluem 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

17

I I I .1 Divisão de classes

A divisão pode ser:

- Horizontal: quando trata-se de uma divisão deinstâncias

- Vertical: quando trata-se de uma de divisão deatributos

18

Horizontal

Ex: A classe Reserva é substituída por duas classes. Todos osatributos de Reserva são mantidos em Reserva Antiga e ReservaAtual.Motivo: melhora de desempenho no acesso a Reserva Atual e narealização de back-up

Obs: Esta divisão pode reduzir bastante o tempo de back-up off-line, quedependendo do caso pode até ser diário. Esse back-up seria só de ReservaAtual. (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)

Reserva

numdata

19

Vertical

Ex: A classe Empregado é substituída por duas classes, cadauma recebendo parte dos atributos de Empregado .

Obs: Os SGBDRs permitem a definição de visões diferentes aos diversosgrupos 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 essastabelas ficassem em servidores diferentes, poderia haver essa indicação

Empregado

CPFnomeendereçotelsalárioavaliação

20

I I I .2 Seleção de chave primária

Chave primária: a combinação de uma ou mais colunas, cujovalor localiza uma única linha em uma tabela. Assim, não háduas ou mais linhas da tabela com o mesmo valor na colunaou combinação de colunas que f ormam a chave primária.

I ntegridade de entidade: exige que cada tabela tenhaexatamente uma chave primária.

Chaves primárias devem ser escolhidas por serem usadas namaioria dos acessos, devem ser simples e ter tamanhomínimo.

(obs: se f or numérica não precisamos nos preocupar com o tamanho. Mas nocaso de string é bom que tenha tamanho mínimo)

21

I I I . 3 M a p e a m e n t o d a s c l a s s e s e a s s o c i a ç õ e s e mt a b e l a s

A s s o c i a ç ã o b i n á r i a 1 : 1

O p ç ã o 1 :

C l i e n t e ( i d , n o m e , e n d e r e ç o , n u m e r o C a r t ã o , d a t a _ i n í c i o )

Cliente

nomeendereço

CartãoLoja

numerodata_início

0..11 0..11Sublinhado - chave primária

22

Opção 2:

Se fosse muito comum clientes não possuírem cartão da lojaentã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

Cliente

nomeendereço

CartãoLoja

numerodata_início

0..11 0..11

nome da tabela

nome da coluna

chave primária

23

A s s o c i a ç ã o b i n á r i a 1 : N

O p ç ã o 1 :

P e d i d o ( i d , d a t a , d e s c r i ç ã o , i d _ v e n d e d o r ( F K - V e n d e d o r - i d ) ) V e n d e d o r ( i d , n o m e , e n d e r e ç o , t e l e f o n e )

Pedido

datadescrição

Vendedor

nomeendereçotelefone10..* 10..*

24

O p ç ã o 2 :

S e p o r a c a s o u m p e d i d o p u d e s s e s e r e m i t i d o s e mv e n d e d o r e t i v é s s e m o s i n ú m e r o s c a s o s d e s s e t i p o ,p o d e r í a m o s a d o t a r a s e g u i n t e s o l u ç ã o :

P e d i d o ( i d , d a t a , d e s c r i ç ã o ) V e n d e d o r ( i d , n o m e , e n d e r e ç o , t e l e f o n e ) E m i t e P e d i d o ( i d _ p e d i d o ( F K - P e d i d o - i d ) , i d _ v e n d e d o r

( F K - V e n d e d o r - i d ) )

Vendedor

nomeendereçotelefone

Pedido

datadescrição 0..10..* 0..10..*

25

Associação binária M:N

F uncionár io (id , nome, ender eço, t el) Depar t ament o ( id , local) Lot ação (id_ f unc(F K - F uncionár io- id), id_ dep(F K-

Depar t ament o- id), dat a_ ent r ada, dat a_ saída)

Funcionário

nomeendereçotel

Departamento

local0..*0..*

Lotação

data_entradadata_saída

0..*0..*

26

C o m p o s i ç ã o

O p ç ã o 1 :

P e d i d o ( i d , d a t a , s t a t u s ) I t e m ( i d _ p e d i d o ( F K - P e d i d o - i d ) , n u m e r o _ i t e m , q u a n t i d a d e ,

i d _ p r o d u t o ( F K - P r o d u t o - i d ) ) P r o d u t o ( i d , n o m e , q u a n t _ e s t o q u e )

Pedido.

datastatus

Item

quantidade1..*

Produto

nomequant_Estoque

10..* 10..*1..*

27

IV. ELABORANDO O DIAGRAMA DE CLASSES DAETAPA DE PROJ ETO LÓGI CO DE BANCO DEDADOS

1. Considerar o diagrama de classes elaborado na etapade Análise e outras informações obtidas sobre osistema, como o número de objetos de uma classe, af reqüência das operações realizadas e o tipo etamanho dos atributos.

28

2. Elaborar o projeto lógico de banco dedados, 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

29

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.

30

Item faturadoquantFaturada Livro

isbntítulodescriçãoquantEstoquepreço

prazoMédioEntrega

Item pedidoquantidadePedidapreçoCobrado

1

0..*

1

0..*

ClientecódigoCPFnomeendereçotelefone [0..1]eMail [0..1]

PedidonumPedidodataEmissão

nomePresenteado [0..1]endereçoEntregadataCancelamento [0..1]

status

1..*1..*

1..*1 faz ->

FaturanumFaturadataEmissãodataVencimentovalorPago [0..1]dataPagamento [0..1]

dataPedidoCancelamento [0..1]dataCancelamento [0..1]

status

1..*0..* 1..*0..*

1

0..*

1

0..*

{ Se uma fatura atende a um pedido, necessariamente os itens pedidos ligados à fatura devem ser do pedido ao qual a fatura está relacionada }

Diagrama de classes elaborado com uma perspectiva conceitual:

31

CLIENTE

COLUNA ID CPF NOME ENDERECO TELEFONE E_MAILTipo da chave(PK,FK)

PK

not null/unique nn/u nn/u nn nnTabela FKColuna FKTipo de dados NUMBER VARCHAR2 VARCHAR2 VARCHAR2 NUMBER VARCHAR2

Tamanho 7 20 50 50 20 50

Tabelas:

PEDIDO

COLUNA ID DT_EMISSAO NOME_PRESENTEADO

ENDERECO_ENTREGA

DT_CANCELAMENTO

STATUS ID_CLIENTE

Tipo da chave(PK,FK)

PK FK

not null/unique nn/u nn nn nn nnTabela FK CLIENTEColuna FK IDTipo de dados NUMBER DATE VARCHAR2 VARCHAR2 DATE CHAR NUMBER

Tamanho 7 50 50 1 7

32

ITEM_PEDIDO

COLUNA ID_PEDIDO NUM_ITEM QUANT_PEDIDA

PRECO_COBRADO

ID_LIVRO

Tipo da chave(PK,FK)

FK/PK PK FK

not null/unique nn nn nn nn nnTabela FK PEDIDO LIVROColuna FK ID ISBNTipo de dados NUMBER NUMBER NUMBER NUMBER VARCHAR2

Tamanho 7 7 9 9,2 20

LIVRO

COLUNA ISBN TITULO DESCRICAO QUANT_ESTOQUE

PRECO PRAZO_MEDIO_ENTREGA

Tipo da chave(PK,FK)

PK

not null/unique nn/u nn nn nn nn nnTabela FKColuna FKTipo de dados VARCHAR2 VARCHAR2 VARCHAR2 NUMBER NUMBER NUMBER

Tamanho 20 50 2000 9 9,2 9

33

FATURA

COLUNA ID DT_EMISSAO

DT_VENCIMENTO

VALOR_PAGO

DT_PAGAMENTO

DT_PEDIDO_CANCELAM

ENTO

DT_CANCELAME

NTO

STATUS ID_PEDIDO

Tipo da chave(PK,FK)

PK FK

not null/unique nn/u nn nn nn nnTabela FK PEDIDOColuna FK IDTipo de dados NUMBER DATE DATE NUMBER DATE DATE DATE CHAR NUMBER

Tamanho 7 9,2 1 7

ITEM_FATURADO

COLUNA ID_FATURA ID_ PEDIDO ID_ITEM QUANT_FATURADATipo da chave(PK,FK)

FK/PK FK/PK FK/PK

not null/unique nn nn nn nnTabela FK FATURA ITEM_PEDIDOColuna FK ID ID_PEDIDO NUM_ITEMTipo de dados NUMBER NUMBER NUMBER NUMBER

Tamanho 7 7 7 9

34

CLIENTE

ID : VARCHAR2CPF : VARCHAR2NOME : VARCHAR2ENDERECO : VARCHAR2TELEFONE : NUMBERE_MAIL : VARCHAR2CLIENTE_PK = ID

<<RelationalTable>>

LIVRO

ISBN : VARCHAR2TITULO : VARCHAR2DESCRICAO : VARCHAR2QUANT_ESTOQUE : NUMBER

PRECO : NUMBERPRAZO_MEDIO_ENTREGA : NUMBERLIVRO_PK = ISBN

<<RelationalTable>>

PEDIDO

ID : VARCHAR2DT_EMISSAO : DATE

NOME_PRESENTEADO : VARCHAR2ENDERECO_ENTREGA : VARCHAR2DT_CANCELAMENTO : DATESTATUS : CHARPEDIDO_PK = ID

<<RelationalTable>>

ID_CLIENTE = IDID_CLIENTE = IDPEDIDO_CLIENTE_FK

<<FK>>

FATURA

ID : VARCHAR2DT_EMISSAO : DATEDT_VENCIMENTO : DATE

VALOR_PAGO : NUMBERDT_PAGAMENTO : DATE

DT_PEDIDO_CANCELAMENTO : DATEDT_CANCELAMENTO : DATESTATUS : CHARFATURA_PK = ID

<<RelationalTable>>ID_PEDIDO = IDID_PEDIDO = ID

FATURA_PEDIDO_FK

<<FK>>

ITEM_FATURADO

QUANT_FATURADA : NUMBERITEM_FATURADO_PK = ID_FATURA,ID_PEDIDO,ID_ITEM

<<RelationalTable>>

ID_FATURA = IDID_FATURA = ID

ITEMFAT_FATURA_FK

<<FK>>

ITEM_PEDIDO

NUM_ITEM : NUMBERQUANT_PEDIDA : NUMBER

PRECO_COBRADO : NUMBERITEM_PEDIDO_PK = ID_PEDIDO,NUM_ITEM

<<RelationalTable>>

ID_PEDIDO = IDID_PEDIDO = ID

ITEMPEDIDO_PED_FK

<<FK>>

ID_LIVRO = ISBNID_LIVRO = ISBN

ITEMPEDIDO_LIVRO_FK

<<FK>>ID_PEDIDO = ID_PEDIDO

ID_ITEM = NUM_ITEMID_PEDIDO = ID_PEDIDO

ID_ITEM = NUM_ITEM

ITEMFAT_ITEMPED_FK

<<FK>>

Diagrama de classes representando as tabelas:

35

Exercício:

Elaborar o diagrama de classes padrão e de Banco de Dados para o problema da Agenda