You are on page 1of 15

MODELO LGICO DE DADOS

(MLD)
Ol, Turma!
Neste captulo, daremos prosseguimento ao nosso trabalho de
modelar o negcio para o qual estaremos desenvolvendo um sistema.
Quando vamos trabalhar com o modelo lgico, j deveremos ter o
modelo conceitual finalizado. Estaremos, ento, aplicando certas
restries tcnicas ao modelo conceitual para que seja possvel
implementar este modelo em um tipo de SGBD escolhido. No final,
veremos o modelo fsico e, nessa parte, iremos inserir caractersticas
de um especfico SGBD.
Os objetivos deste captulo so:


tFOUFOEFSPRVFVNQSPKFUPMHJDP

tTBCFSVUJMJ[BSBTSFHSBTEFJOUFHSJEBEF


tDPOIFDFSBQSJNFJSB TFHVOEBFUFSDFJSBGPSNBOPSNBMF
saber colocar o modelo na terceira forma normal;


tDPOIFDFSPNPEFMPGTJDP

Muitos autores e profissionais da rea, em suas abordagens sobre o


tema modelagem de dados, tm direcionado o processo de modelagem
diretamente para o nvel lgico. Partem, desde o incio de seu processo,
para a construo de um modelo fortemente dependente do ambiente
onde ser implementado. Isso tem levado obteno de modelos
eficientes, mas bastante dependentes da tecnologia que os orientou
(relacional, redes, orientado a objetos).
Dentro da proposta apresentada nos itens anteriores, vimos que a
gerao de um modelo lgico deveria ser antecedida pela obteno de
um modelo conceitual. Esse modelo conceitual deveria ser independente
da tecnologia disponvel, procurando aproximar-se o mximo possvel
do mapeamento fiel do ambiente observado. No modelo conceitual,
voc pode e deve representar o negcio sem limitaes tcnicas.
Existem vrias notaes para o modelo lgico. Em nossa disciplina,
vamos utilizar a notao de James Martin (Engenharia de Informaes)
que foi criada em 1980 e uma das mais utilizadas no mercado de
trabalho.

38

EROS MOURA

(0,n)
Empregado

(1,1)
Trabalha

EMPREGADO

Departamento

DEPARTAMENTO

= muitos
= um
= a ocorrncia do relacionamento opcional
= a ocorrncia do relacionamento obrigatria

Os relacionamentos j no so mais nomeados. S ser necessrio


nomear um relacionamento quando houver mais de um relacionamento
entre duas tabelas.
Lgicos ou de implementao (nvel intermedirio) entre o Modelo
Conceitual e o Modelo Fsico.

A grande vantagem dessa proposta que, a partir do modelo conceitual


gerado, poderemos aplicar regras predefinidas em funo da tecnologia
a ser empregada e, assim, obter os modelos necessrios. Isso far com
que, a partir de um mesmo modelo conceitual, possamos gerar modelos
lgicos para bancos de dados baseados na abordagem relacional ou
at mesmo em novas abordagens, tais como bancos de dados orientados
a objetos.
Assim, podemos definir que o processo de obteno de um modelo
lgico a partir de um modelo conceitual segue os seguintes passos,
segundo Cougo (1997):


PCUFSPNPEFMPDPODFJUVBM

EFOJSPUJQPEFJNQMFNFOUBP SFMBDJPOBM 00




BQMJDBSBTSFHSBTEFEFSJWBPFTQFDDBT
4. adaptar o modelo s necessidades.

BANCO DE DADOS

Perceba que, dentre os passos a serem seguidos, existe, em ltimo


lugar, uma atividade extremamente importante para a gerao de
um modelo lgico aplicvel efetivamente soluo de problemas
prticos do dia a dia.

Estaremos utilizando o programa DBDesigner para criar nossos


modelos lgicos. H uma verso dele que pode ser encontrada aqui:
http://sourceforge.net/projects/dbdesigner-fork/files/dbdesignerfork/r1.5/DBDesignerFork-1.5-bin-i386-win32-beta5.zip/
download

2.1. REGRAS DE DERIVAO


Como citamos anteriormente, a obteno de um modelo lgico deveria
ser feita a partir de um modelo conceituai previamente gerado. Para
tanto, deveramos dispor de uma srie de regras de derivao que fossem
aplicadas sobre o modelo conceitual e que o transformassem em funo
da topologia (tipo) de BD usada, em um modelo relacional, rede ou at
hierrquico.
Veremos, a partir deste instante, portanto, essas regras. Como nosso
objetivo, neste material, explorar a derivao de modelos relacionais,
estaremos trabalhando com as regras para o modelo relacional segundo
Elmasri e Navathe (2011).
2.1.1. Etapa 1: Mapeamento de tipos de entidade regular
Para cada tipo de entidade regular (forte) E no modelo conceitual,
crie uma tabela T que inclua todos os atributos simples de E. Inclua
apenas os atributos de componente simples de um atributo composto.
Escolha um dos atributos-chave de E como chave primria para T.
Se a chave escolhida de E for composta, ento o conjunto de atributos
simples que a compem juntos formaro a chave primria de T.
Se vrias chaves fossem identificadas para E durante o projeto
conceitual, a informao que descreve os atributos que formam cada
chave adicional mantida a fim de especificar chaves secundrias
(nicas) da tabela T. O conhecimento sobre as chaves tambm
mantido para fins de indexao e outros tipos de anlises.
Em nosso exemplo, criamos as tabelas JOGO, EQUIPE, JOGADOR e
PAS. Os atributos de chave estrangeira e relacionamento se houver,
BJOEB OP FTUP JODMVEPT FMFT TFSP BDSFTDFOUBEPT EVSBOUF BT FUBQBT

39

40

EROS MOURA

seguintes. Em nosso exemplo, escolhemos data_jogo e nome_estadio


DPNPDIBWFTQSJNSJBTQBSBBUBCFMB+0(0 DEJHP QBSBDIBWFQSJNSJB
EF &26*1& DEJHP  QBSB DIBWF QSJNSJB EF +0("%03 TJHMB   QBSB
chave primria de PAS.
2.1.2. Etapa 2: Mapeamento de tipos de entidade fraca
Para cada tipo de entidade fraca F no modelo conceitual: com tipo
de entidade proprietria forte E, crie uma tabela T e inclua todos os
atributos simples (ou componentes simples dos atributos compostos)
de F como atributos de T. Alm disso, inclua como atributos
chave estrangeira de T os atributos de chave primria da tabela que
correspondem aos de entidade proprietria E. Isso consegue mapear
o tipo de relacionamento de identificao de F. A chave primria de
T a combinao das chaves primrias do proprietrio E e a chave
parcial do tipo de entidade fraca F, se houver.
Se houver um tipo de entidade fraca E2, cujo proprietrio tambm
um tipo de entidade, ento Ej deve ser mapeado antes de E2
para determinar primeiro sua chave primria. Em outras palavras,
se houver uma entidade fraca (E2), ligada a outra entidade fraca
(E1), E1 deve ser criada antes de E2.
2.1.3. Etapa 3: Mapeamento dos tipos de relacionamento
binrios 1:1
Para cada tipo de relacionamento binrio 1:1 R no modelo conceitual,
identifique as tabelas A e B que correspondem aos tipos de entidades
participantes em R. Escolha entre as tabelas A e B e inclua a
chave estrangeira referenciando a outra. Por exemplo: coloco a chave
estrangeira em A referenciando B.
Complementando:
j criamos duas tabelas (A e B), uma para cada conjunto de
FOUJEBEFTRVFQBSUJDJQBEPSFMBDJPOBNFOUP
delas, incluir como chave estrangeira a chave primria da
PVUSB
se o relacionamento for total em um dos dois conjuntos de
entidades, ento melhor incluir a chave estrangeira no lado total.

BANCO DE DADOS

2.1.4. Etapa 4: Mapeamento de tipos de relacionam


binrio 1:N
Para cada tipo de relacionamento R binrio regular 1:N, identifique
a tabela T que representa o tipo de entidade participante no lado N
do tipo de relacionamento. Inclua como chave estrangeira em T a
chave primria da tabela P que representa o outro tipo de entidade
QBSUJDJQBOUF FN i3w GB[FNPT JTTP QPSRVF DBEB JOTUODJB EF FOUJEBEF
no lado N (tabela T) est relacionada, no mximo, a uma instncia
de entidade do lado 1 (tabela P) do tipo de relacionamento. Inclua
quaisquer atributos simples (ou componentes simples dos atributos
compostos) do tipo de relacionamento 1:N como atributos de P.
Complementando:
j temos duas tabelas (T,P), uma para cada conjunto de
FOUJEBEFTRVFQBSUJDJQBEPSFMBDJPOBNFOUP
incluir como chave estrangeira, na tabela do lado muitos (o
lado N), a chave primria da tabela do lado um.
2.1.5. Etapa 5: Mapeamento de tipos de relacionamento
binrio N:N
Para cada tipo de relacionamento R binrio N:N, crie uma nova tabela
S para representar R. Inclua como atributos de chave estrangeira em
S as chaves primrias das tabelas que representam os tipos de entidade
QBSUJDJQBOUFTTVBDPNCJOBPGPSNBSBDIBWFQSJNSJBEFi4w*ODMVB 
tambm, quaisquer atributos simples do tipo de relacionamento N:N
(ou componentes simples dos atributos compostos) como atributos de
S. Observe que no podemos representar um tipo de relacionamento
N:N por um nico atributo de chave estrangeira em uma das tabelas
participantes (como fizemos para os tipos de relacionamento 1:1 ou
1:N) devido razo de cardinalidade, por isso temos de criar uma tabela
de relacionamento S separada.
Complementando:
j temos duas tabelas, uma para cada conjunto de entidades
RVFQBSUJDJQBEPSFMBDJPOBNFOUP
criar uma nova tabela contendo, como chaves estrangeiras, as
DIBWFTQSJNSJBTEFTTBTEVBTUBCFMBT
a combinao dessas chaves estrangeiras forma a chave
QSJNSJBEBOPWBUBCFMB
incluir tambm, se houver, colunas com os atributos do
relacionamento.

41

42

EROS MOURA

2.1.6. Etapa 6: Mapeamento de atributos multivalorados


Para cada atributo multivalorado A na tabela S, crie uma tabela T.
Essa tabela T incluir um atributo correspondente a A, mais o atributo
da chave primria da tabela S. A chave primria de T a combinao
do atributo da chave primria da tabela S (esse atributo tambm ser
chave estrangeira) e o atributo A. Se o atributo multivalorado for
composto, inclumos seus componentes simples.
Complementando:
Para cada atributo multivalorado, criar uma tabela contendo:
como chave estrangeira, a chave primria da tabela que possua
PBUSJCVUPNVMUJWBMPSBEPNBJTPQSQSJPBUSJCVUPRVFFSBNVMUJWBMPSBEP
a nova chave primria tambm ser uma chave estrangeira
QBSBBUBCFMBRVFQPTTVBPBUSJCVUP
a chave primria da nova tabela a combinao da chave
FTUSBOHFJSBFEPWBMPSEPBUSJCVUP
se o atributo multivalorado for composto, inclumos seus
componentes simples.
2.1.7. ETAPA 7: MAPEAMENTO DE
AUTORRELACIONAMENTO 1:N
Para os autorrelacionamentos 1:N, como existe um relacionamento
entre a mesma entidade, deve-se criar a chave estrangeira na prpria
tabela, no atributo que tem o relacionamento. Nesse caso, o atributo que
ter a chave estrangeira no ter o mesmo nome da chave primria, pois
no possvel repetir o nome do atributo.

FUNCIONRIO
(1,n)

gerenciado por
GERNCIA

matrcula
nome_funcionrio
matrcula_gerente

(1,1)

gerente de

BANCO DE DADOS

Ao final, teremos a tabela assim:


FUNCIONARIO (matricula, nome_funcionario, matricula_gerente)
sendo que o atributo matricula_gerente ter uma chave estrangeira para
FUNCIONRIO.
2.1.8. Etapa 8: Autorrelacionamento N:N
Para os autorrelacionamentos N:N, faremos da mesma forma que um
relacionamento N:N tradicional, ou seja, criamos uma nova tabela para
o relacionamento. Esta nova tabela ter, ao menos, duas colunas as quais
sero, ao mesmo tempo, chave primria e chaves estrangeiras. Neste
caso, as duas chaves estrangeiras estaro se referenciando mesma
tabela base.

DISCIPLINA
(0,n)

cod_disciplina
nome_disciplina
carga_horria

(0,n)

so pr-requisito para

DISCIPLINA (cod_disciplina, nome_disciplina, carga_horaria)


PRE_REQUISITO (cod_disciplina, cod_disciplina_pre)
cod_disciplina ter uma chave estrangeira apontando para
DISCIPLINA.
cod_disciplina_pre ter uma chave estrangeira apontando para
DISCIPLINA.

2.1.9. Etapa 9: Mapeamento de tipos de relacionamento


n-rio (qualquer relacionamento maior que o binrio).
Para cada tipo de relacionamento n-rio R, onde n > 2, crie uma tabela T
para representar R. Inclua como atributos de chave estrangeira em T as
chaves primrias das tabelas que representam as entidade participantes.

43

44

EROS MOURA

Inclua, tambm, quaisquer atributos simples do tipo de relacionamento


n-rio (ou componentes simples de atributos compostos) como atributos
de T. A chave primria de T normalmente uma combinao de todas
as chaves estrangeiras que referenciam as tabelas representando as
entidades participantes. Porm, se as restries de cardinalidade sobre
qualquer um dos tipos de entidade E participantes em R for 1, ento a
chave primria de T no deve incluir o atributo de chave estrangeira que
referencia a relao E correspondente a E.
Complementando:
criar uma nova tabela contendo, como chaves estrangeiras, as
chaves primrias das tabelas que representam os conjuntos de entidades
QBSUJDJQBOUFT
normalmente, a combinao dessas chaves estrangeiras forma
a chave primria da nova tabela, mas se a cardinalidade mxima de
uma das entidades participantes for 1, ento a chave estrangeira que
referencia essa entidade no far parte da chave primria da nova tabela.

A tabela abaixo resume as correspondncias entre as construes e


restries do modelo conceitual para o modelo lgico.

MODELO CONCEITUAL

MODELO LGICO

Tipo de entidade

Tabela

Tipo de relacionamento 1:1 ou 1:N

Chave estrangeira (ou tabela)

Tipo de relacionamento N:N

Nova tabelae duaschaves estrangeiras

Tipo de relacionamento n-rio

Nova tabela

Atributo simples

Atributo

Atributo composto

Conjunto de atributos componentes simples

Atributo multivalorado

Tabela e chave estrangeira

Conjunto de valores

Domnio

Atributo-chave

Chave primria

45

BANCO DE DADOS

2.1.10. Etapa 10: Mapeamento da especializao /


generalizao
Tomemos como base este modelo conceitual.
CLIENTE

cdigo
nome

PESSOA
FSICA
CPF

PESSOA
JURDICA
CNPJ

Para os casos em que h generalizao / especializao, h trs opes


de projeto que podem ser adotadas:
t Opo 1: criar uma tabela para cada entidade (CLIENTE, FSICA,
JURDICA). Nesse caso, a chave primria das tabelas especializadas
(FSICA e JURDICA) a mesma da entidade generalista (CLIENTE) e
tambm devem ser chaves estrangeiras para a tabela CLIENTE.
Ao final, teremos trs tabelas, assim:
CLIENTE (cod_cliente, nome_cliente)
FISICA (cod_cliente, cpf, sexo)
JURIDICA(cod_cliente, cnpj, nome_fantasia)
OBS: aqui, a chave primria est sublinhada.
Lembre-se de que:
A coluna cod_cliente na tabela FISICA dever ter chave estrangeira
para CLIENTE.
A coluna cod_cliente na tabela JURIDICA dever ter chave
estrangeira para CLIENTE.

tOpo 2: criar uma tabela para cada entidade da especializao, como


FSICA e JURIDICA. Nesse caso, os atributos da entidade genrica (em
nosso exemplo CLIENTE) devem ser includos em ambas as tabelas
criadas.

46

EROS MOURA

Ao final, teremos duas tabelas, assim:


FISICA (cod_cliente, nome_cliente, cpf, sexo)
JURIDICA (cod_cliente, nome_cliente, CNPJ,nome_fantasia)
tOpo 3: criar uma nica tabela, incluindo os atributos das 3 entidades.
Nesse caso, os campos que eram das entidades especializadas devero
ser opcionais, ou seja, devero aceitar valores nulos. Ao final, teremos a
nica tabela, assim:
CLIENTE (cod_cliente, nome_cliente, cpf, sexo, cnpj, nome_fantasia)
Qual opo escolher?
Cada uma das opes apresentadas traz vantagens e desvantagens. A
terceira opo tem como vantagem a reduo do nmero de junes
(veremos isso mais adiante) entre tabelas e como desvantagem possuir
atributos que s tero valores preenchidos quando for o caso dos dados
especializados. Por exemplo: quando for o caso de cadastrar uma pessoa
fsica, os campos CNPJ e nome fantasia no sero preenchidos. O mesmo
PDPSSFSRVBOEPGPSPDBTPEPDBEBTUSPEBQFTTPB+VSEJDBOFTUFDBTP PT
atributos CPF e sexo no sero preenchidos. por esse motivo que os
atributos que vieram das entidades especializadas devem aceitar nulo,
pois assim passam a ser opcionais. Para a segunda opo, temos como
desvantagem a repetio dos atributos que eram da entidade generalista.
Agora, estes atributos devero existir nas duas tabelas. Na primeira
opo h uma organizao maior, pois so preservadas as estruturas que
existiam no modelo conceitual. O problema dessa soluo a quantidade
de junes que aumentar em relao s outras duas solues, o que pode
ser traduzido em problemas de performance. Deve-se, ento, verificar se
esta tabela ter muito acesso, e se o acesso a este dado, um pouco mais
lento, poder trazer problemas para a aplicao.

2.2. NORMALIZAO
Finalizado o esquema relacional, passa-se ao processo de normalizao.
Este processo baseia-se no conceito de forma normal. Uma forma
normal uma regra que deve ser obedecida por uma tabela para que esta
seja considerada bem projetada. H diversas formas normais, isto ,
diversas regras, cada vez mais rgidas, para verificar tabelas relacionais.
Em nossa disciplina, vamos considerar trs formas normais. As formas
normais so denominadas simplesmente primeira, segunda e terceira
forma normal, abreviadamente 1FN, 2FN e 3FN.

BANCO DE DADOS

Embora a normalizao seja um ingrediente muito importante do


projeto de bancos de dados, no se deve assumir que seu nvel mais
alto seja sempre o mais desejvel. Em geral, quanto mais alta a forma
normal, mais operaes de juno so necessrias para produzir a sada
especificada e mais recursos so exigidos pelo sistema de banco de
dados para responder a consultas do usurio final. Um projeto bemsucedido deve considerar a demanda desse usurio por empenho rpido.
Portanto, em algumas ocasies, ser preciso desnormalizar certas partes
de um projeto do banco de dados, de modo a atender s exigncias
de desempenho. A desnormalizao produz uma forma normal mais
CBJYBPVTFKB QPSNFJPEFMB /'QPEFTFSDPOWFSUJEPQBSB/'/P
entanto, o preo a pagar pela melhora de desempenho decorrente da
desnormalizao a maior redundncia de dados.
2.2.1. Primeira Forma Normal (1FN)
O primeiro passo da normalizao consta da transformao do esquema
de tabela no normalizada em um esquema relacional na primeira forma
normal (1FN). Segundo Rob e Coronel (2011), uma tabela encontra-se
na 1FN quando:


UPEPTPTBUSJCVUPTEFDIBWFFTUPEFOJEPT

no h grupos de repetio na tabela. Em outras palavras, cada


interseco de linha/coluna contm um e somente um valor, no um
DPOKVOUPEFWBMPSFT
todos os atributos so dependentes da chave primria.
V

CDIGO

NOME

GERENTE DEP.

LOCALIZAES DO DEPARTAMENTO

Pesquisa

Cachoeiro, Castelo, Muqui

Adm

Maratazes, Guarapari

Sede

Iconha

eja um exemplo de quando uma tabela no est na 1FN:

2.2.2. Segunda Forma Normal (2FN)


Segundo Rob e Coronel (2011), uma tabela encontra-se na 2FN quando:
est em 1NF. e

OPJODMVJEFQFOEODJBTQBSDJBJTPVTFKB OFOIVNBUSJCVUP
dependente apenas de uma parte da chave primria.

47

48

EROS MOURA

Se a 2FN trata das dependncias parciais de uma chave primria,


se a chave primria for simples (formada apenas por um atributo)
ela j estar na 2FN.

Observe que ainda possvel uma tabela em 2NF apresentar


dependncia transitiva, ou seja, um ou mais atributos podem
ser funcionalmente dependentes de atributos no relacionados
chave.

Veja um exemplo de quando uma tabela no est na 2FN:

*A

*B

Ddepende s de A e no da chave inteira (A,B)


2.2.3. TERCEIRA FORMA NORMAL (3FN)
Segundo (Rob e Coronel, 2011), uma tabela encontra-se na 3FN quando:
est em 2NF. e
no contm dependncias transitivas.

*A

C depende de B que no chave

Coloque as estruturas abaixo na 3FN.


a) Contrato( num_contrato, cod_cliente, dta_inicio_contrato,
dta_termino_contrato, num_prestacao, val_prestacao, dta_venc_
prestacao )
b) PecaEstocada(cod_peca,
tel_armazem)

cod_armazem,

qtd_estocada,

49

BANCO DE DADOS

c) Horario_Voo(sigla_cia, num_voo, hor_voo, sigla_aeroporto,


nom_aeroporto, cidade_aeroporto, status_voo).
OBS: a chave primria est em negrito e sublinhado.

2.2.4. EXEMPLO DE MODELO LGICO


Veja aqui exemplo de um modelo lgico de uma transportadora.

UF
sigla_uf: CHAR(2)
nome_uf: VARCHAR(25)

ITENS_MANIFESTO
num_manifesto: CHAR (6) (FK)
num_ctrc: CHAR(6) (FK)
posicao_ctrc: INTEGER

MANIFESTO
num_manifesto: CHAR (6)
filial_origem_manifesto: CHAR(3) (FK)
filial_destino_manifesto: CHAR (3) (FK)
placa_veiculo_manifesto: CHAR (7) (FK)
data_emissao_manifesto: CHAR (10)
data_chegada_manifesto: CHAR (10)
cod_ajudante: INTEGER (FK)

TIPO CLIENTE
cod_tipo_cliente: INTEGER
descricao_tipo_cliente: VARCHAR(20)

CIDADE
sigla_uf: CHAR(2)
nome_cidade: VARCHAR(40)
sigla_uf: CHAR(2) (FK)

CTRC
num_ctrc: CHAR (6)
cliente_remetente: INTEGER (FK)
cliente_destinatario: INTEGER (FK)
bairro_cliente: VARCHAR(40)
data_emisso: CHAR (10)
peso_ctrc: NUMERIC (8,2)
frete_ctrc: NUMERIC (10,2)

Remetente

Destinatrio

CTRC_NF
num_ctrc: CHAR(6) (FK)
num_nf: CHAR(6)
MANIFESTO_MOTORISTA
num_manifesto: CHAR (7)
cod_motorista: INTEGER (FK)
VEICULO

Origem

UF
sigla_uf: CHAR(2)
nome_uf: VARCHAR(25)

Destino

placa_veiculo: CHAR (7)


descricao_veiculo: VARCHAR (FK)
AJUDANTE
cod_ajudante: INTEGER (7)
nome_ajudante: VARCHAR (35)

Baseado no modelo lgico acima, responda s seguintes perguntas.


a) um manifesto pode ter, no mnimo, ___ itens de manifesto e,
OPNYJNP @@@JUFOTEFNBOJGFTUP
b) um item de manifesto pode ter, no mnimo, ___ manifesto(s) e,
no mximo, ___ manifesto(s).
c) um manifesto pode ter, no mnimo, ___ ajudante(s) e, no
mximo, ___ ajudante(s).

CLIENTE
cod_cliente: INTEGER
nome_cliente: VARCHAR(40)
rua_cliente: VARCHAR(40)
bairro_cliente: VARCHAR(40)
cidade_cliente: INTEGER (FK)
cep_cliente: VARCHAR(8)
documento_cliente: VARCHAR (20)
cod_tipo_cliente: INTEGER (FK)

CLIENTE_TELEFONE
cod_cliente: INTEGER (FK)
telefone_cliente: CHAR(10)
MOTORISTA
cod_motorista: INTEGER
nome_motorista: VARCHAR(40)
sexo_motorista: CHAR(1)

50

EROS MOURA

d) qual a chave primria da tabela itens __ manifesto?


________________
e) responda a estas perguntas para todos os relacionamentos e
chaves primrias do modelo.

2.3. MODELO FSICO DE DADOS (MFD)


Define-se como modelo fsico de dados (tambm chamado de modelo
interno) aquele em que a representao dos objetos feita sob o foco
do nvel fsico de implementao das entidades e seus relacionamentos.
O conhecimento do modo fsico de implementao das estruturas de
dados ponto bsico para o domnio desse tipo de modelo.
Cada diferente SGBD poder definir um diferente modo de
implementao fsica das caractersticas e recursos necessrios para o
armazenamento e manipulao das estruturas de dados. Utilizar estas
caractersticas de modo correto pode significar uma tima performance,
enquanto a no utilizao das mesmas pode significar um grande
problema.
Na prtica, para se desenvolver um bom modelo fsico necessrio um
bom conhecimento do SGBD com que voc vai trabalhar (aqui, estou
me referindo a um especfico SGBD, por exemplo, PostGreSQL). Neste
momento, voc no tem conhecimento necessrio para decidir se no
SGBD Oracle melhor trabalhar com a tabela Cliente particionada em
vrios discos rgidos diferentes ou no. Ou, se para o campo sexo da
tabela Cliente, que receber consultas, seria melhor criar um ndice
BTree ou Bitmap.
Cougo (1997) diz que, em alguns casos, um mesmo SGBD em diferentes
ambientes de sistema operacional poder ter diferentes mtodos de
armazenamento e manuseio de suas estruturas de dados. Isso fcil de ser
constatado quando analisamos um SGBD que tenha sua implementao,
por exemplo, em ambiente Windows(DOS), Linux(UNIX) e VMS.
Em cada um desses ambientes, existiro diferentes estruturas de
armazenamento, endereamento, acesso e alocao fsica. Isso significa
que, em alguns casos, um mesmo modelo lgico poder estar mapeado
de diferentes modos em cada um dos sistemas operacionais.

51

BANCO DE DADOS

Baseado no modelo conceitual abaixo, crie o modelo lgico.

cod_cidade
nome_cidade
sigla_uf

CIDADE

(0, n)

Est localizada

(1,1)

sigla_uf
nome_uf

UF

(1,1)

Mora

(1,n)
cod_cliente
nome_cliente
rua
numero

bairro
cod_cidade
cep
telefones )(0,n
sexo (M,F
)

CLIENTE

TCNICO
(1,1)

(1,1)

faz

pede

(1,n)
nmero_oe
data_os
hora_os
cod_cliente
matrcula_atendente
descrio_problema
descrio_fechamento
posio_os (A,F, P)
valor_total_os

Ordem
de
Servio

(1,n)

(1,1)

Possui

(1,n)

Servio Executado

(0,n)

Cadastra

cod_tcnico
nome_tcnico
terceitos) (S,N

(0,n)

data_uso

usa

nmero_os
cod_servio
cod_tcnico
data_inicial_servio
hora_inicial_servio
data_final_servio
hora_final_servio
valor_cobrado_servio

(0,n)

feito

hora_uso
quantidade_uso

(1,1)

ATENDENTE
ATENDENTE

matrcula_atendente
nome_atendente

ESTOQUE

SERVIO

(1,1)
quantidade_estoque
valor_compra
desc_estoque
cod_estoque

cod_servio
nome_servio
estimativa_tempo
valor_servio

You might also like