Modelagem de dados

Dalessandro Soares Vianna

Projeto de um banco de dados
 Parte integrante do desenvolvimento
de um sistema de informação.
 preocupação com a representação
adequada de dados operacionais.
 Tipos de projeto de BD
 Top-down.
 Botton-up
Projeto top-down de BD
 Ênfase nos requisitos da aplicação.
 Obtidos com os usuários.
 Compreensão dos dados operacionais relevantes para a
aplicação.
 Processo mais usual de projeto.
 Aplicado em casos onde não existe sistema informatizado
ou banco de dados anterior.
 Quatro etapas:
1. levantamento de requisitos;
2. projeto conceitual;
3. projeto lógico; e
4. projeto físico ou implementação.
Levantamento de requisitos
 Coleta de informações sobre os dados,
suas restrições e seus relacionamentos na
organização.
 Forma de realização: reuniões com os
usuários; observação do funcionamento da
organização.
 Resultado: documento com a especificação
de requisitos.
Exemplo de requisitos
 Sistema Administrativo da Universidade
 Caso: “... Todo servidor possui uma
identificação única na universidade e está lotado
em um departamento, onde exerce uma
determinada função...”
 Requisitos: ... • Servidor:
 possui uma identificação única na Universidade;
 está lotado em um departamento;
 exerce uma função no departamento no qual está
lotado; ...
Projeto conceitual
 Independente de detalhes de implementação.
 Objetivo: entendimento da semântica do domínio.
 Pode ser traduzido para qualquer modelo de BD.
 Facilita a manutenção do modelo lógico
(engenharia reversa).
 Melhor compreendido pelo usuário leigo.
Diagrama
Entidade-Relacionamento
 Técnica diagramática para a representação de um
modelo conceitual.
 Definida originalmente por Peter Chen (1976) e
estendida a partir da década de 80.
 Técnica formal que se estabeleceu como padrão
para modelagem conceitual de BD.
 Poucos conceitos (entidade, relacionamento, atributo,
G/E e agregação).
 Representação gráfica.
 Fácil compreensão.
Exemplo de DER
Conceitos de um DER
 1) Entidade
 Representação de um fato do mundo real do
qual se deseja manter seus dados.
 Retângulo nomeado  representa um
conjunto de ocorrências de uma entidade.
Conceitos de um DER
 2) Relacionamento
 Representação de uma associação entre 2 ou
mais entidades (entre ocorrências de
entidades).
 Losango nomeado  representa um
conjunto de ocorrências de um
relacionamento.
Conceitos de um DER
 Definição de um relacionamento envolve:
 Cardinalidade máxima : indica a quantidade
máxima de ocorrências de entidades que
podem estar associadas a uma ocorrência da
outra entidade.
 Totalidade/Parcialidade : especifica se a
participação das ocorrências das entidades no
relacionamento é obrigatória ou opcional.
 são RIs a serem controladas.
Conceitos de um DER
Conceitos de um DER
 Notação com cardinalidade mínima e
máxima:
Conceitos de um DER
 Auto-relacionamento
Conceitos de um DER
 Relacionamentos ternários
Conceitos de um DER
 Atributos
 Representação de uma propriedade de uma
entidade ou de um relacionamento.
Conceitos de um DER
 Atributos identificadores
 Identificam unicamente uma entidade.

 Chaves estrangeiras
o Fazem referência a outra tabela.
Conceitos de um DER
 Entidades Fracas
 Dependentes de outra entidade.
Conceitos de um DER
 Generalização/especialização
 Generalização  conjunto de entidades visto como uma
entidade genérica.
 Especialização  algumas ocorrências de entidades
possuem atributos ou relacionamentos adicionais, sendo
especializadas em uma ou mais entidades.
Conceitos de um DER
 Agregação
 Relacionamento visto como uma entidade.
Exercício1
Vídeo-locadora: Uma vídeo-locadora trabalha com o aluguel de
fitas, cd's e cartuchos de jogos. Todos os 3 tem um código , o
titulo que o descreve e a categoria. As fitas possuem a sinopse e
os artistas principais; os Cd's, o nome do cantor e uma descrição
das músicas contidas. Os cartuchos possuem apenas o nome do
fabricante.
A locadora empresta apenas para os clientes cadastrados. O seu
nome, endereço, data de nascimento e telefone ficam
armazenados junto com um código numérico seqüencial atribuído
ao cliente no momento do cadastro.
Cada cliente pode alugar um ou mais objetos de locação (fita, cd
ou cartucho), sendo que cada um deste só pode ser alugado por
apenas um cliente em um determinado momento(data).
Exercício 2
Clínica médica: em uma clínica trabalham médicos e
existem pacientes internados. Cada médico é identificado
pelo seu CRM, possui um nome e recebe um salário na
clínica. Um médico tem formação em diversas
especialidades (ortopedia, traumatologia, etc), mas só
exerce uma delas na clínica. Para todo paciente internado
na clínica são cadastrados alguns dados pessoais: nome,
RG, CPF, endereço, telefone(s) para contato e data do
nascimento. Um paciente possui um determinado médico
como responsável (com um horário de visita diário
predeterminado), porém vários outros médicos podem
participar do seu tratamento. Pacientes estão sempre
internados em leitos individuais, que são identificados por
um número e ficam em um andar da clínica.
Exercício 3
Campeonato de voley: Cada equipe é caracterizada pela sua
sigla, nome, cidade, estado, nome do técnico, número de títulos
importantes já conquistados. Cada equipe é composta por no
máximo 15 jogadores. Cada jogador tem armazenado seu nome,
CPF, data de nascimento e especialidade. Cada jogador está
associado a no máximo um time.
De cada partida é importante saber a data, público, renda e placar.
Para cada partida é interessante saber também quais foram os
jogadores que participaram, bem como a pontuação de cada um.
Um patrocinador é composto por código e nome. Este pode
patrocinar várias equipes e/ou jogadores. Enquanto um jogador ou
um time pode ter um único patrocinador.

Obs.:
• O sistema só guarda dados do campeonato atual.
• No meio do campeonato não há troca de jogadores, nem de
patrocinadores.
Vantagens do projeto
conceitual
 Abstração de dados de alto nível.
 Indicação de dados e seus relacionamentos da
forma como percebidos no mundo real.
 Independência de detalhes de representação de
SGBDs.
 Fácil compreensão pelo usuário leigo.
 Facilita a validação da modelagem dos dados.
 Facilita a manutenção dos dados.
 Modificação dos requisitos.
 Migração de SGBD.
 Tradução para qualquer modelo de SGBD.
Projeto lógico
 Conversão do esquema conceitual para o
esquema de representação de um SGBD
(esquema lógico ou DED).
 Forma de realização: aplicação de regras
de conversão.
 Resultado: esquema lógico (tabelas,
restrições de integridade, transações,
visões, autorizações de acesso, índices, ...).
Exemplo de projeto lógico

Servidores (Matrícula, Nome, Função, Depto)

chave primária: Matrícula
chave estrangeira: Depto é uma referência para tabela Departamentos
Função IN {professor, funcionário}
Departamentos (Código, Nome)
chave primária: Código
Projeto lógico
 (1,1)  (1,1)

(1,1) (1,1)
Produto Possui Estoque
Projeto lógico
 (0,1)  (1,1)

(1,1) (0,1)
Paciente Ocupa Leito
Projeto lógico
 (0,1)  (0,1)

(0,1) (0,1)
Homem Casado Mulher
Projeto lógico
 1N

(1,1) (0,N)
Médico Resp. Paciente
Projeto lógico
 NN

(0,N) (0,N)
Médico Trata Paciente
Projeto lógico
 Atributo multivalorado.
 Generalização / Especialização.
 Chave estrangeira.
 Remoção / alteração em cascata.
 Remoção / alteração proibida.
Projeto físico
 Definição do esquema lógico em um
SGBD adequado ao modelo.
 Forma de realização: DDL do SGBD.
 Resultado: esquema físico.
Exemplo de projeto físico
Servidores (Matrícula, Nome, Função, CódigoDepto)
chave primária: Código
chave estrangeira: CódigoDepto referência para Departamentos
Função IN {professor, funcionário}
Departamentos (Código, Nome)
chave primária: Código

CREATE TABLE Servidores (

Matrícula int, Nome char(50), Função char(20) check(Função
in (‘professor’, ‘funcionário’)), Depto int NOT NULL,
primary key(Matrícula),
foreign key(CódigoDepto) references Departamentos);
create index NomeServidor on Servidores (Nome);
create table Departamentos ( . . .);
Projeto Bottom-up
 Ênfase nas descrições de dados já
existentes na organização.
 arquivos eletrônicos, fichários, documentos bem
formatados (pedido, NF), relatórios, ...
 Processo também chamado de engenharia
reversa de BD.
 aplicado em casos onde existem fontes de
dados ou sistemas informatizados (legados)
sem BD.
Projeto Bottom-up
 Cinco etapas:
1. Coleta de fontes de dados.
2. Representação em uma tabela não-
normalizada.
3. Normalização.
4. Integração de esquemas relacionais das
fontes.
5. Engenharia reversa do esquema
relacional.
Projeto Bottom-up
Normalização
 Decomposição sistemática da tabela não-
normalizada em várias tabelas relacionais.
 Objetivo: eliminação de redundâncias no
armazenamento e organização dos dados
em tabelas lógicas.
 Processo baseado na aplicação de regras
(formas normais).
 1FN a 3FN, na prática.
 Normalização

PEDIDO CLIENTE NOME TELEFONE PRODUTO DESCRIÇÃO QTDE VALUNIT VALTOT TOTPED VENDEDOR NOMEVEND
2625 A AAA 111 001 ARROZ 10 1,00 10,00 290,00 I PEDRO
2625 A AAA 111 002 FEIJ AO 50 2,00 100,00 290,00 I PEDRO
2625 A AAA 111 003 FARINHA 60 3,00 180,00 290,00 I PEDRO
3001 B BBB 222 003 FARINHA 20 3,00 60,00 120,00 2 ANTONIO
3001 B BBB 222 004 OLEO 15 4,00 60,00 120,00 2 ANTONIO
4954 A AAA 111 001 ARROZ 40 1,00 40,00 70,00 3 SILVIA
4954 A AAA 111 003 FARINHA 10 3,00 30,00 70,00 3 SILVIA
Normalização
 Anomalias de atualização:
 Anomalia de inclusão: para ser incluído um
cliente este tem que obrigatoriamente
pertencer a um pedido.
 Anomalia de exclusão: ao ser excluída uma
linha, caso ela seja a única linha em que um
produto foi vendido os seus dados
desaparecerão.
 Anomalia de alteração: para se alterar o
telefone de um cliente sou obrigado a
percorrer todas as linhas da minha tabela que
se refere àquele cliente realizando esta
alteração uma a uma.
Normalização
 Dependência Funcional (  )
 Dados dois elementos A e B, podemos
dizer que o elemento B é dependente
funcionalmente do elemento A se para
cada valor de A encontrado obtemos os
mesmos valores de B.
 Sendo PEDIDO a chave primária podemos
dizer que todos os outros campos são
dependentes funcionalmente de PEDIDO.
Normalização
 Observamos também que toda vez que o
CLIENTE A aparece o NOME e
TELEFONE também se repetem, o que
caracteriza uma outra dependência
funcional no nosso exemplo.
 Toda vez que PRODUTO se repete,
também se repete DESCRIÇÃO e
VALUNIT.
 Toda vez que VENDEDOR se repete, se
repete também nome vendedor.
Normalização
 Atributos Multivalorados
 São atributos cujo valor muda em
relação ao atributo chave da minha
tabela.
 No nosso exemplo temos que
PRODUTO, DESC, QTDE, VALUNIT,
VALTOT, não são iguais no mesmo
PEDIDO (que é chave primária),
portanto estes atributos são
multivalorados.
Normalização
 Dependência Parcial X Dependência
Total
 Toda vez que temos uma chave composta os atributos
que possuírem dependência sobre uma parte da chave
são ditos parcialmente dependentes, enquanto os outros
são ditos completamente dependentes.

A B C D
Normalização
 Dependência Transitiva
 Temos dependência Transitiva, quando o atributo
possuir dependência a outro que não pertence a
chave primária.

Cód Nome*
Paciente Nome
Plano Plano
 Formas Normais
 1ª Forma Normal (1FN)
 Dizemos que uma relação está na primeira forma
normal se todos os seus atributos forem atômicos,
ou seja, não possuir atributos multivalorados. 

A B

A B C D

A C D
 Formas Normais
 2ª Forma Normal (2FN)
 Dizemos que uma relação está na 2FN, se ela
estiver na 1FN e nenhum de seus atributos possuir
dependência parcial.

A B C D E

A B C E
B D
 Formas Normais
 3ª Forma Normal (3FN)
 Uma relação está na 3FN, se ela estiver na 2FN e
não possuir dependência transitiva entre seus
atributos que não façam parte da chave primária.

A B C D

A B C C D
Normalização - Exercícios

1. Passe o esquema abaixo para até a 3FN e

monte o DED correspondente:

A B C D E F G
Normalização - Exercícios
2. As tabelas abaixo estão ferindo qual forma
normal? Consertem (Mostre o DED
consertado).
a) Funcionários (matricula, nome, salário, filhos)
b) Departamento (coddepto, descrição,
gerencia, nome_gerencia)
c) Produção(coddepto, codprojeto, mês,
n_horas, nome_projeto)
Normalização - Exercícios
3. Normalize (3FN):

Projetos (codProj, tipo, descr, codEmp, nome, cat,

sal, dataIni, tempoAloc).
Particionamento de tabelas
 Particionamento horizontal
 Ex.: Apenas os dados mais recentes são
acessados.

 Particionamento vertical
 Ex.: Algumas colunas são bem mais
acessadas do que as outras.
Integração OO-Relacional
 Mapeamento:
 A princípio, cada tipo de objeto persistente
(Classe) pode ser mapeado para uma tabela no
banco de dados relacional.
 Atributos de objetos que armazenam valores de
tipos de dados primitivos (char, boolean, integer,
real, etc.) são mapeados diretamente para
colunas das tabelas.
Integração OO-Relacional
 Mapeamento:
 Nomes de Classes devem ser mantidos
nas Tabelas, assim como os nomes dos
atributos de instância também devem ser
mantidos para as suas colunas.
Chave primária
 Objetos têm identidade. Objetos são
únicos.
 Objetos possuem um OID: Object
Identifier.
 Valor numérico seqüencial.
 BDs Relacionais possuem Chaves
Primárias (PK).
Exemplo de mapeamento
Mapeando herança