Introdução a Bancos de Dados

Prévia do material em texto

1 Banco de Dados I 
Prof. Marcos Miguel 
marcos.a.miguel@gmail.com 
http://marcosmiguel.com 
 
 
 
2 
Prof. Marcos Miguel - MBI 
BD1(Banco de Dados 1) 
2 
¨ O que é e para que serve um 
banco de dados? 
3 
Prof. Marcos Miguel 
BD1(Banco de Dados 1) 
¨  Opção 1 ¨  Opção 2 
3 
4 
Prof. Marcos Miguel - MBI 
BD1(Banco de Dados 1) 
4 
¨  OBJETIVO 
¤  Mostrar e definir os conceitos relativos à criação e 
organização de Sistemas de Bancos de Dados. 
Fazer com que o aluno desenvolva habilidades 
necessárias para a modelagem conceitual de 
dados, no processo de análise de um sistema, 
e sua implementação baseada no modelo 
lógico relacional. Possibilitar ao aluno o 
entendimento das operações de álgebra relacional 
como fundamento para a realização de consultas 
a bancos de dados usando a linguagem SQL. 
BD1(Banco de Dados 1) 
¨  HABILIDADES 
¤  Desenvolver a habilidade crítica ao analisar 
estudos de casos e a partir dos mesmos 
desenvolver diagramas que servirão de base para 
a criação de banco de dados. 
¨  COMPETÊNCIAS 
¤  Compreender o funcionamento de Sistemas 
Gerenciador de Banco de Dados, desenvolver a 
capacidade de modelar conceitualmente banco de 
dados, implementar, baseado no modelo lógico 
desenvolvido, banco de dados. 
5 
6 
Prof. Marcos Miguel - MBI 
CONTEÚDO PROGRAMÁTICO 
6 
¨  Unidade 1. Conceitos de Sistemas de Bancos 
de Dados 
¤  1.1. Conceitos de Sistema Gerenciador de Bancos 
de Dados (SGBD) 
¤  1.2. Objetivos de um SGBD 
¤  1.3. Abstração de Dados 
¤  1.4. Arquitetura de um SGBD 
¤  1.5. Independência de Dados 
¤  1.6. Administração de Dados 
¤  1.7. Arquiteturas para uso de SBGDs 
7 
Prof. Marcos Miguel - MBI 
CONTEÚDO PROGRAMÁTICO 
7 
¨  Unidade 2. Modelagem de Dados 
¤  2.1. Abstração 
¤  2.2. Requisitos para modelagem 
¤  2.3. Modelos Conceituais 
¤  2.4. Modelos Lógicos: Relacional, Rede, 
Hierárquico 
¤  2.5. Modelo Físico 
8 
Prof. Marcos Miguel - MBI 
CONTEÚDO PROGRAMÁTICO 
8 
¨  Unidade 3. Modelo de Entidades e 
Relacionamentos (M.E.R.) 
¤  3.1. Entidade; Relacionamento; Atributo 
¤  3.2. Diagrama de Entidades e Relacionamentos 
(DER) 
¤  3.3. Classes de Relacionamentos 
¤  3.4. Cardinalidade 
¤  3.5. Auto-relacionamento 
¤  3.6. Relacionamento múltiplo 
¤  3.7. Atributos de relacionamento 
¤  3.8. Agregação 
CONTEÚDO PROGRAMÁTICO 
¨  Unidade 3. Modelo de Entidades e 
Relacionamentos (M.E.R.) cont… 
 
¤  3.9. Relacionamentos mutuamente exclusivos 
¤  3.10.Generalização 
¤  3.11.Entidade Fraca 
¤  3.12.Notações alternativas 
¤  3.13.Esquema textual do MER 
¤  3.14.Etapas do projeto MER 
9 
9 
10 
Prof. Marcos Miguel - MBI 
CONTEÚDO PROGRAMÁTICO 
10 
¨  Unidade 4. Modelo Relacional 
¤  4.1. Conceitos 
¤  4.2. Chaves 
¤  4.3. Características das tabelas 
¤  4.4. Restrições de integridade 
¤  4.5. Linguagens Relacionais 
11 
Prof. Marcos Miguel - MBI 
CONTEÚDO PROGRAMÁTICO 
11 
¨  Unidade 5. Álgebra Relacional 
¤  5.1. Operações Tradicionais 
¤  5.2. Operações Especiais 
¨  Unidade 6. SQL - Structured Query Language 
¤  6.1. Consultas (Queries) 
12 
Prof. Marcos Miguel - MBI 
Bibliografia 
12 
¨  DATE, C. J. Introdução a sistemas de 
bancos de dados. 8.ed. Rio de 
Janeiro:Campus, 2003. 
¨  HEUSER, Carlos Alberto. Projeto de 
banco de dados. 6.ed. Porto Alegre: 
Bookman,2008.. 
¨  KORTH, Henry F.; SILBERSCHATZ, 
Abraham. Sistemas de bancos de dados. 
3.ed.São Paulo: Makron, 1999. 
13 
Prof. Marcos Miguel - MBI 
Bibliografia auxiliar 
13 
¨  LIGHTSTONE, Sam; NADEAU, Tom; TEOREY, Toby, 
Projeto e modelagem de bancos de dados. 1.ed. Rio 
de Janeiro: Campos, 2006. 
¨  MEDEIROS, Marcelo. Banco de dados para sistemas 
de informaçao.1.ed. Florianopoles: VisualBooks, 2006. 
¨  SETZER, Valdemar W. Banco de dados. 1.ed. São 
Paulo: Edgard Blucher, 1995. TEOREY, Toby; 
LIGHTSTONE, Sam; NADEAU, Tom; Projeto e 
modelagem de banco de dados. 
14 
Prof. Marcos Miguel - MBI 
Avaliações 
¨  V1 – 23/09/2013 
¨  V2 – 25/11/2013 
¨  VT – 18/11/2013 - Apresentação dos trabalhos 
¨  2 CH (V1 + V2) – 02/12/2013 
¨  VS – 09/12/2013 
14 
15 
Prof. Marcos Miguel 
15 
Conceitos 
Introdutórios 
16 
Prof. Marcos Miguel - MBI 
16 
Introdução 
¨ Sistemas de Arquivos 
¤  Tipicamente formado por conjuntos de arquivos 
contendo informações a respeito de uma empresa 
(os arquivos possuem relacionamento entre si), e 
por um conjunto de programas de aplicação que são 
escritos para extrair ou adicionar registros nos 
arquivos apropriados 
¤  Se forem necessárias informações adicionais, mais 
arquivos e programas de aplicação são criados 
17 
Prof. Marcos Miguel - MBI 
Sistema de Arquivos 
¨  ORGANIZAÇÕES BÁSICAS DE ARQUIVOS: 	
¤  Estruturas de Dados: define a forma como os dados estão organizados, 
como se relacionam e como serão manipulados pelos programas. Ex: 
vetores e matrizes, registros, filas, pilhas, árvores, grafos, etc. 	
¤  Arquivo: coleção de registros lógicos, cada um deles representando 
um objeto ou entidade. Na prática os arquivos geralmente estão 
armazenados na memória secundária (fitas e discos) e são usados 
para armazenar os resultados intermediários de processamento ou 
armazenar os dados de forma permanente. 	
¤  Registro lógico (registro) : seqüência de itens, cada item sendo 
chamado de campo ou atributo, correspondendo a uma característica 
do objeto representado. Os registros podem ser de tamanho fixo ou de 
tamanho variável. 	
¤  Campo: item de dados do registro, com um nome e um tipo associados 
17 
18 
Prof. Marcos Miguel - MBI 
Sistema de Arquivos 
¨  ORGANIZAÇÕES BÁSICAS DE ARQUIVO	
n  Bloco: unidade de armazenamento do arquivo em 
disco, também denominado registro físico. Um registro 
físico normalmente é composto por vários registros 
lógicos. Cada bloco armazena um número inteiro de 
registros.	
n  Chave: é uma seqüência de um ou mais campos em 
um arquivo 	
n  Chave primária: é uma chave que apresenta um valor 
diferente para cada registro do arquivo. É usada para 
identificar, de forma única, cada registro.	
n  Chave de acesso: é uma chave usada para identificar 
o(s) registro(s) desejado(s) em uma operação de 
acesso ao arquivo. 
18 
19 
Prof. Marcos Miguel - MBI 
Sistema de Arquivos 
¨  ESTRUTURAS DE ARQUIVOS	
¤  Nos arquivos seqüenciais a ordem lógica e física dos registros 
armazenados é a mesma. Os registros podem estar dispostos seguindo a 
seqüência determinada por uma chave primária (chamada chave de 
ordenação), ou podem estar dispostos aleatoriamente.	
19 
20 
Prof. Marcos Miguel - MBI 
Sistema de Arquivos 
¨  Inserção de um registro	
¤  Se o arquivo não está ordenado, o registro pode ser simplesmente inserido após o 
último registro armazenado.	
¤  Se o arquivo está ordenado, normalmente é adotado o seguinte procedimento:	
¤  Dado um arquivo base B, é construído um arquivo de transações T, que contem 
os registros a serem inseridos, ordenado pela mesma chave que o arquivo B. Os 
arquivos B e T são então intercalados, gerando o arquivo A, que é a versão 
atualizada de B. 
20 
21 
Prof. Marcos Miguel - MBI 
Sistema de Arquivos 
¨  Exclusão de um registro	
¤  Normalmente é implementada como a inserção, com a criação de um arquivo de 
transações que contém os registros a serem excluídos, que é processado 
posteriormente. 
¤  Pode ainda ser implementada através de um campo adicional no arquivo que 
indique o estado (status) de cada registro. Na exclusão, o valor deste campo seria 
alterado para “excluído”. Posteriormente, é feita a leitura seqüencial de todos os 
registros, sendo que os registros que não estiverem marcados como “excluídos” 
são copiados para um novo arquivo.	
¨  Alteração de um registro 
¤  Consiste na modificação do valor de um ou mais atributos de um registro. O 
registro deve ser localizado, lido e os campos alterados, sendo gravadonovamente, na mesma posição.	
¤  A alteração é feita sem problemas, desde que ela não altere o tamanho do 
registro nem modifique o valor de um campo usado como chave de ordenação 
21 
22 
Prof. Marcos Miguel - MBI 
22 
Ambiente Utilizando Arquivos 
23 
Prof. Marcos Miguel - MBI 
23 
Ambiente Utilizando BD 
24 
Prof. Marcos Miguel - MBI 
Conceituação 
¨  Dados: 
¤  É a descrição de algum fenômeno do mundo real 
de um fato ou de uma idea 
¤  Representação de uma propriedade ou característica de 
um objeto real 
n  Não tem significado por si só 
¤  Ex.: quantidade de Kwh consumidos em uma residência 
24 
25 
Prof. Marcos Miguel - MBI 
Conceituação 
¨  Informação: Conhecimento adquirido pelo 
uso e interpretação do dado 
¤  Organização e agregação dos dados 
¤  Informação interpretação dos dados 
 
¤  Ex.: Consumo de energia comparado com a capacidade 
geradora da usina.	
25 
26 
Prof. Marcos Miguel - MBI 
26 
Conceituação 
¨  Banco de Dados: É uma coleção de dados 
armazenados. Pode ser considerado como um modelo 
da porção do mundo real que é de interesse para 
determinada aplicação 
¨  Sistema de Gerenciamento de Banco de 
Dados: 
¤  Conjunto de software para gerenciar (definir, criar, 
modificar, usar) um BD e garantir a integridade e 
segurança dos dados. O SGBD é a interface entre os 
programas de aplicação e o BD. Em inglês é 
denominado DataBase Management System (DBMS) 
27 
Prof. Marcos Miguel - MBI 
27 
Conceituação 
¨  Instâncias: é a coleção de informações 
armazenadas no banco de dados em um 
instante qualquer (em l inguagens de 
programação seria o equivalente ao valor das 
variáveis de um programa em determinado 
instante) 
¨  Ex.: 
 nome : Luis 
 sexo : Masculino 
 profissão : Engenheiro 
28 
Prof. Marcos Miguel - MBI 
28 
Conceituação 
¨ Modelo X Esquema 
¤ Modelo: Conjunto de estrutura, operadores e 
restrições de integridade usadas para 
representar o mundo real de forma mais 
ordenada 
¤ Esquema: Representação da parte da 
realidade na qual estamos interessados através 
do uso do modelo de dados 
29 
Prof. Marcos Miguel - MBI 
29 
Conceituação 
¨  Esquema: é a concepção global do BD. Sua 
descrição no BD é denominada de metadados 
30 
Prof. Marcos Miguel - MBI 
30 
Componentes de um SGBD 
¨  Dicionário de Dados (Data Dictionary) 
¤ Descreve os dados e suas relações em forma 
conceitual e independente de seu envolvimento 
nas diversas aplicações. 
¤ Fornece referências cruzadas entre os dados e 
as aplicações 
31 
Prof. Marcos Miguel - MBI 
31 
Componentes de um SGBD 
¨  Linguagem de definição de dados (LDD ou DDL 
– Data Definition Language) 
¤  Usada para especificar o esquema do BD. O 
resultado da especificação é um conjunto de 
definição 
¤  A compilação dessas instruções da LDD gera o 
dicionário de dados ou diretório de metadados 
¤  Alguns SGBD´s permitem a definição da estrutura 
de armazenamento e os métodos de acesso que 
serão usados, através da LDD 
32 
Prof. Marcos Miguel - MBI 
32 
Componentes de um SGBD 
¨  Linguagem de manipulação de dados (LMD ou 
DML – Data Manipulation Language) 
¤  Permite ao usuário acessar ou manipular dados organizados 
através de um modelo 
¤  Envolve: recuperação, alteração, inserção e remoção de 
informações 
¤  Existe dois tipos básicos 
n  Procedimental: quais dados e como chegar até eles 
(mais eficiente) 
n  Não procedimental: quais dados (mais fácil) 
¤  Muitas vezes a LMD é chamada também de linguagem de 
consulta. Na verdade, a consulta é apenas uma parte da 
LMD 
33 
Prof. Marcos Miguel - MBI 
33 
Componentes de um SGBD 
¨  Linguagem de consulta (QUERY) 
¤  Permite que o usuário final, com poucos 
conhecimentos técnicos, possa obter de forma 
simples, informações do BD 
¨  Utilitários administrativos 
¤  Programas auxiliares para carregar, reorganizar, 
adicionar, modificar a descrição do BD, obter 
cópias de reserva e recuperar a integridade física 
do BD 
34 
Prof. Marcos Miguel - MBI 
34 
Funções de um SGBD 
¨  Independência dos dados 
¤  O SGBD deve oferecer isolamento das aplicações em relação 
aos dados. Esta característica permite modificar o modelo de 
dados do BD sem necessidade de reescrever ou recompilar 
todos os programas que estão prontos. 
¤  As definições dos dados e os relacionamentos entre os 
dados são separados dos códigos os programas 
35 
Prof. Marcos Miguel - MBI 
35 
Funções de um SGBD 
¨  Facilidade uso/desempenho 
¤  Embora o SGBD trabalhe com estruturas de dados 
complexas, os arquivos devem ser projetados para atender 
a diferentes necessidades, permitindo desenvolver 
aplicações melhores, mais seguras e mais rapidamente. 
¤  Deve possui comandos poderosos em sua linguagem de 
acesso 
36 
Prof. Marcos Miguel - MBI 
36 
Funções de um SGBD 
¨  Integridade dos dados 
¤  O SGBD deve garantir a integridade dos dados, através da 
implementação de restrições adequadas. Isto significa que 
os dados devem ser precisos e válidos 
¨  Redundância dos dados 
¤  O SGBD deve manter a redundância de dados sob controle, 
ou seja, ainda que existam diversas representações do 
mesmo dado, do ponto de vista do usuário é como se 
existisse uma única representação 
37 
Prof. Marcos Miguel - MBI 
37 
Funções de um SGBD 
¨  Segurança e privacidade dos dados 
¤  O SGBD deve assegurar que estes só poderão ser acessados 
ou modificados por usuários autorizados 
¨  Rápida recuperação após falha 
¤  Os dados são de importância vital e não podem ser 
perdidos. Assim, o SGBD deve implementar sistemas de 
tolerância a falhas, tais como estrutura automática de 
recover e uso do conceito de transação 
38 
Prof. Marcos Miguel - MBI 
38 
Funções de um SGBD 
¨  Uso compartilhado 
¤  O BD pode ser acessado concorrentemente por 
múltiplos usuários 
¨  Controle do espaço de armazenamento 
¤  O SGBD deve manter controle das áreas de disco 
ocupadas, evitando a ocorrência de falhas por falta 
de espaço de armazenamento 
39 
Prof. Marcos Miguel - MBI 
39 
Abstração de Dados 
¨  O SGBD deve esconder certos detalhes de 
como os dados são armazenados ou mantidos. 
¨  Dados precisam ser recuperados 
eficientemente. A preocupação com a eficiência 
leva a concepção de estruturas de dados 
complexas para representação dos dados no 
BD 
40 
Prof. Marcos Miguel - MBI 
40 
Níveis de Abstração 
¨  Nível Físico: 
¤  É o nível mais baixo de abstração, no qual se 
descreve como os dados são armazenados. 
Estruturas complexas, de baixo nível, são descritas 
em detalhe 
41 
Prof. Marcos Miguel - MBI 
41 
Níveis de Abstração 
¨  Nível Conceitual: 
¤  É o nível que descreve quais os dados são realmente 
armazenados no BD e quais os relacionamentos existentes 
entre eles 
¤  Este nível descreve o BD como um conjunto de estruturas 
relativamente simples. Muito embora a implementação de 
estruturas simples no nível conceitual possa envolver estruturas 
complexas no nível físico, o usuário do nível conceitual não 
precisa saber disto. 
¤  Geralmente é usado pelos administradores de banco de dados, 
que devem decidir qual informação deve ser mantida no banco 
de dados 
42 
Prof. Marcos Miguel - MBI 
42 
Níveis de Abstração 
¨  Nível Visão: 
¤  Este é o nível mais alto de abstração, no qual se expõe 
apenas parte do BD, expondo apenas parte do banco de 
dados que seja de interesse do usuário final. 
¤  Na maioria das vezes os usuários não estão preocupados 
com todas as informações do BD e sim com apenas parte 
delas (Visões dos Usuários) 
43 
Prof. Marcos Miguel - MBI 
43 
Níveis de Abstração 
44 
Prof. Marcos Miguel - MBI 
44 
Modelos de Banco de Dados 
¨  Modelos de Dados 
¤  É uma coleção de ferramentas conceituais para descrição 
dos dados, relacionamento, semântica e restrições de dados 
¤  Métodos para se estruturar e organizar os dados 
¨  Componentesbásicos 
¤  Modelo conceitual: entidades, relacionamentos, 
atributos 
¤  Modelo lógico: relação, tuplas, atributos e 
relacionamentos 
¤  Modelo físico: arquivos, registros, campos e 
ponteiros 
45 
Prof. Marcos Miguel - MBI 
45 
Modelos de Banco de Dados 
¨  Modelo Conceitual 
¤  Utilizado para descrever o mini-mundo da aplicação 
¤  É concebido em um nível de abstração alto, de fácil entendimento por 
parte do usuário 
¤  Independe dos aspectos implementacionais podendo ser aplicado a 
diferentes tipos de SGBD 
¤  Geralmente possui mecanismos de abstração que facilitam a 
modelagem 
¤  É o ponto de partida para o projeto da base de dados 
¤  Mais estável que o esquema lógico 
n  Ex: Entidade-Relacionamento / Modelos Orientado a Objetos 
46 
Prof. Marcos Miguel - MBI 
46 
Modelos de Banco de Dados 
¨  Modelo Lógico 
¤  É utilizado para descrever a base de dados conforme é vista 
pelos usuários do SGBD 
¤  Utilizado para descrever a estrutura de um banco de dados 
em um nível dependente do SGBD a ser escolhido para a 
implementação, porém não apresenta detalhes de 
implementação 
¤  Ex: Relacional / Rede / Hierárquico / Orientado a 
Objetos 
47 
Prof. Marcos Miguel - MBI 
47 
Modelos de Banco de Dados 
¨  Modelo Físico (Interno) 
¤  Utilizado para descrever as estruturas físicas de 
armazenamento dos dados 
¤  Não são muito utilizados pois os SGBD´s já possuem o 
interfaceamento do modelo lógico para o físico 
¤  Geralmente só é alterada para ajuste de desempenho 
¤  A tendência de produtos modernos é ocultar cada vez mais 
os detalhes físicos de implementação 
¤  Ex: Procedimentos para definição da estrutura de índices 
48 
Prof. Marcos Miguel - MBI 
48 
Independência de Dados 
¨  Capacidade de modificar a estrutura do banco 
de dados em um nível de abstração sem afetar 
o nível mais acima 
¨  Tipos de independência de dados 
¤  Física: é a capacidade de se modificar o 
esquema físico sem precisar de reescrever os 
programas de aplicação (ex. para melhorar a 
performance) 
¤  Lógica: é a capacidade de se modificar o 
esquema conceitual sem a necessidade de 
reescrever os programas de aplicação (quando 
muda a estrutura lógica do BD) 
49 
Prof. Marcos Miguel - MBI 
49 
Arquitetura ANSI / SPARC 
¨  ANSI (American National Standards Committe on 
Computers and Information Processing) 
¨  SPARC (Standard Planning and Requirements Committe) 
50 
Prof. Marcos Miguel - MBI 
50 
Usuários de Banco de Dados 
¨  Administrados do banco de dados (DBA – 
Data Base Administrator) 
¤  Responsável pelo controle do SGBD 
¤  Funções 
¤  Definição da estrutura de armazenamento 
¤  Modificação da organização física e do esquema 
¤  Concessão de autorização para acesso aos dados 
¤  Especificação de restrições de integridade 
¤  Manter o dicionário de dados 
¤  Definir estratégias de backup 
51 
Prof. Marcos Miguel - MBI 
51 
Usuários de Banco de Dados 
¨  Programador de aplicação 
¤  Escreve programas que utilizam a base de dados (usando C, Cobol, 
linguagens de aplicação do SGBD). Os comandos LMD são inseridos 
no programa a cada referência a base de dados 
¤  Busca-se cada vez mais maior integração entre os dois tipos 
de linguagens (aplicação e LMD) 
¨  Usuários finais 
¤  Acessam os dados através de linguagem de consulta ou através das 
aplicações desenvolvidas 
¨  Usuários especializados 
¤  Escrevem aplicações consideradas não convencionais como CASE, 
Automação de Escritório, Sistema especialistas, CAD, etc. 
52 
Prof. Marcos Miguel - MBI 
52 
Arquiteturas para o uso do SGBD 
¨  Mono-Usuário 
¤  BD está no mesmo computador que as aplicações 
¤  Não há múltiplos usuários 
¤  Recuperação geralmente através de backup 
¤  Típico de computadores pessoais 
53 
Prof. Marcos Miguel - MBI 
53 
Arquiteturas para o uso do SGBD 
¨  Multi-Usuário 
¤  BD está no mesmo computador que as aplicações 
¤  Múltiplos usuários acessando através de terminais 
¤  Típico de ambientes com mainframe 
54 
Prof. Marcos Miguel - MBI 
54 
Arquiteturas para o uso do SGBD 
¨  Cliente/Servidor 
¤  Multi-usuário 
¤  Servidor dedicado ao Banco de Dados, executando 
o SGBD 
¤  As estações clientes executam apenas as 
aplicações 
¤  Tráfego na rede é menor 
¤  Arquitetura atualmente em uso 
55 
Prof. Marcos Miguel - MBI 
55 
Fases do Projeto de BD 
56 
Prof. Marcos Miguel - MBI 
56 
Fases do Projeto de BD 
¨  Construir o Modelo Conceitual 
¤  Modelo de alto nível, independente do SGBD 
¤  Etapa de levantamento de dados 
¤  Determinação dos relacionamentos dos dados 
¤  Uso de uma técnica de modelagem de dados 
¤  Abstração do ambiente de hardware/software 
57 
Prof. Marcos Miguel - MBI 
57 
Fases do Projeto de BD 
¨  Construir o Modelo Lógico 
¤  Modelo implementável, dependente do tipo de 
SGBD a ser usado 
¤  Considera as necessidades de processamento 
¤  Considera as características e restrições do SGBD 
¤  Etapa de normalização dos dados 
58 
Prof. Marcos Miguel - MBI 
58 
Fases do Projeto de BD 
¨  Construir o Modelo Físico 
¤  Modelo implementável, com métodos de acesso e 
estrutura física 
¤  Considera necessidades de desempenho 
¤  Considera as características e restrições do SGBD 
¤  Dependente das características de hardware/
software 
59 
Prof. Marcos Miguel - MBI 
59 
Fases do Projeto de BD 
¨  Avaliar o Modelo Físico 
¤  Avaliar o desempenho das aplicações 
¤  Avaliar os caminhos de acesso aos dados e 
estruturas utilizadas 
¨  Implementar o Banco de Dados 
¤  Etapa de carga (load) dos dados 
¤  Gerar as interfaces com outras aplicações 
60 
Prof. Marcos Miguel - MBI 
60 
Fases do Projeto de BD 
61 
Prof. Marcos Miguel 
61 
Modelagem 
de 
Dados 
62 
Prof. Marcos Miguel - MBI 
Exercício 
¨  Dividir a turma em 6 grupos de 3 pessoas: 
¤  Mini Mundos: 
n  Locadora de veículos 
n  Salão de Beleza 
n  Cartório 
n  Pague Rápido 
n  Distribuidora de Bebidas 
n  Administradora de Condomínio 
n  Administradora Imobiliária 
n  Cursos Profissionalizantes 
62 
63 
Prof. Marcos Miguel - MBI 
63 
Modelagem de Dados 
¨  Abstração 
¤  Processo mental através do qual selecionamos 
determinadas propriedades ou características dos 
objetos e excluímos outras, consideradas menos 
relevantes para o problema sendo analisado 
¨  Modelo 
¤  É uma abstração, uma representação simplificada, 
de uma parcela do mundo real, composta por 
objetos reais 
64 
Prof. Marcos Miguel - MBI 
64 
Modelagem de Dados 
¨  Modelagem 
¤  Atividade através da qual se cria um modelo 
¨  Modelo de dados 
¤  Um modelo de dados é uma descrição das informações que 
devem ser armazenadas em um banco de dados, ou seja, é 
a descrição formal da estrutura de BD (descrição dos dados, 
dos relacionamentos entre os dados, da semântica e das 
restrições impostas aos dados) 
65 
Prof. Marcos Miguel - MBI 
65 
Requisitos para Modelagem 
¤  Entender a realidade em questão, identificando os 
objetos que compõe a parte da realidade que vai ser 
modelada 
¤  Representar formalmente a realidade analisada 
construindo um modelo de dados 
¤  Estruturar o modelo obtido e adequá-lo ao SGBD a ser 
usado, transformando o modelo conceitual em modelo 
lógico 
66 
Prof. Marcos Miguel - MBI 
66 
Modelos Conceituais 
¨  São usados para descrição de dados no nível 
conceitual. Proporcionam grande capacidade de 
estruturação e permitem a especificação de 
restrições de dados de forma explícita. 
¨  Exemplos: 
¤  Modelo Entidade-Relacionamento (M.E.R.) 
¤  Modelos Orientados para Objetos (OO) 
67 
Prof. Marcos Miguel - MBI 
67 
Modelos Lógicos 
¨  São usados na descrição dos dados no nível 
lógico. Em contraste com modelos conceituais, 
esses modelos são usados para especificar 
tanto a estrutura lógica global do BD como uma 
descrição em alto nível da implementação. 
¨  Tipos: 
¤  Modelo Relacional¤  Modelo de Rede 
¤  Modelo Hierárquico 
68 
Prof. Marcos Miguel - MBI 
68 
Modelo Relacional 
¨  Um BD relacional possui apenas um tipo de 
construção, a tabela. Uma tabela é composta 
por linhas (tuplas) e colunas (atributos). Os 
relacionamentos entre os dados também são 
representados ou por tabelas, ou através da 
reprodução dos valores de atributos 
¨  Idéias básicas Edward F. Codd, laboratório 
pesquisas da IBM em 1970 
69 
Prof. Marcos Miguel - MBI 
Modelo Relacional 
69 
70 
Prof. Marcos Miguel - MBI 
Modelo Relacional 
70 
71 
Prof. Marcos Miguel - MBI 
Modelo Relacional 
71 
72 
Prof. Marcos Miguel - MBI 
72 
Modelo Relacional 
73 
Prof. Marcos Miguel - MBI 
73 
Outros modelos 
¨  Modelo Hierárquico: 
¤  Um BD hierárquico é uma coleção de árvores de 
registros. Os registros são usados para representar 
os dados e ponteiros são usados para representar 
o relacionamento entre os dados, numa ligação do 
tipo pai-filho. 
¤  A restrição é que um determinado registro 
somente pode possuir um registro pai 
74 
Prof. Marcos Miguel - MBI 
Modelo Hierárquico 
74 
75 
Prof. Marcos Miguel - MBI 
Modelo Hierárquico 
75 
76 
Prof. Marcos Miguel - MBI 
Modelo de Rede 
¨  Modelo de Rede: 
¤  O BD em rede é um grafo, onde os nós 
representam os registros e os arcos representam 
os relacionamentos entre os registros, através de 
ligações pai-filho. 
¤  Diferente do modelo hierárquico, um registro 
pode possuir diversos registros pai 
¤  Origem na linguagem de programação Cobol, 
Primeiro SGBD comercial IDS (Integrated Data 
Store) projetado para a General Eletric na década 
de 60 
76 
77 
Prof. Marcos Miguel - MBI 
Modelo de Rede 
77 
78 
Prof. Marcos Miguel - MBI 
Modelo de Rede 
78 
79 
Prof. Marcos Miguel - MBI 
79 
Modelos de Dados Físico 
¨  Usados para descrever os dados em seu nível 
mais baixo. 
¨  Capturam os aspectos de implementação do 
SGBD 
80 
Prof. Marcos Miguel 
80 
Modelo 
Entidade - 
Relacionamento 
(MER) 
81 
Prof. Marcos Miguel - MBI 
81 
Modelo Entidade-Relacionamento (MER) 
¨  Introduzido por Peter Chen em 1976 
¨  Modelo Conceitual e portanto independente de 
aspectos de implementação e conseqüentemente do 
tipo de SGBD escolhido 
¨  O modelo é representado graficamente por um 
Diagrama de Entidade-Relacionamento (DER) 
¨  Componentes básicos 
¤  Entidades 
¤  Atributos 
¤  Relacionamentos 
¤  Generalização / Especialização 
¤  Agregação 
82 
Prof. Marcos Miguel - MBI 
82 
Entidades 
¨  ENTIDADE 
¤  São objetos, conceitos ou coisas no universo de discurso, 
que são representadas no Banco de Dados 
¤  Ex.: O EMPREGADO chamado “Pedro Costa” 
O DEPARTAMENTO “Suporte de Sistemas” 
¨  Tipos: 
¤  Físicos (Pessoas, Empregados, Carros, Notas 
Fiscais, ...) 
¤  Conceituais (Empregos, Tipos de Carros, ...) 
¤  Fatos (Históricos, Reservas, Viagens, ...) 
83 
Prof. Marcos Miguel - MBI 
83 
Entidades 
Nomenclatura e Representação (DER) 
¤  Entidade-Tipo: Entidades que possuem os mesmos atributos 
básicos são agrupadas em uma classe (ou conjunto) de 
entidades correspondente ao mesmo tipo de entidade 
¤  Ex.: - o tipo EMPREGADO 
 - o tipo DEPARTAMENTO 
¨  Instância de Entidade 
84 
Prof. Marcos Miguel - MBI 
84 
Atributos 
¨  ATRIBUTO 
¤  São propriedades usadas para descrever uma entidade 
¤  São as informações que desejamos guardar à 
respeito das instâncias de Entidades 
n  Ex.: a entidade EMPREGADO pode ser descrita 
pelos atributos NOME, REGISTRO, SEXO, ENDEREÇO 
¤  Cada instância de uma entidade tem um valor para cada um 
de seus atributos 
85 
Prof. Marcos Miguel - MBI 
85 
Atributos 
¨  Nomenclatura e Representação (DER) 
¤  Nomes dos Atributos 
¤  Valores dos Atributos 
86 
Prof. Marcos Miguel - MBI 
86 
Atributos 
¨  Domínio de Atributo 
¤  Todo atributo é baseado em um único domínio 
¤  Pode existir mais de 1 atributo baseado no mesmo domínio 
¤  Podem existir domínios que aceitem valores nulos 
(desconhecidos ou não aplicável) 
 nroApto -> inteiro ou nulo (não aplicável se mora em casa) 
 salário -> inteiro > 5000 ou nulo 
¤  Exemplos: 
 Sexo = (“M” , “F”) 
 Nome = Char (30) 
 Salário = Inteiro tal que > 5000 
87 
Prof. Marcos Miguel - MBI 
87 
Atributos 
¨  Tipos de Atributos 
¤  Opcional/Mandatório 
n  Opcional: o atributo pode possuir um valor nulo (vazio). Ex: 
número de telefone 
n  Mandatório: o atributo deve possuir um valor válido, não nulo. Ex: 
nome do cliente 
¤  Atributo Simples: cada instância da entidade tem um valor atômico 
(indivisível) para o atributo. 
n  Ex.: Idade 
¤  Atributo Composto: o atributo é composto por vários componentes 
n  Ex.: - ENDEREÇO (rua, número, apto, cidade, estado, país) - 
NOME(sobrenome, nome) 
88 
Prof. Marcos Miguel - MBI 
88 
Atributos 
¤  Atributo Multivalorado: cada instância da entidade tem múltiplos 
valores (um conjunto de valores) para o atributo 
n  Ex.: - TELEFONES do EMPREGADO / TAMANHOS da PEÇA 
¤  Atributo Derivado:atributo que pode ser obtido através de 
operações sobre outros atributos da própria entidade ou de 
outra entidade 
n  Ex.: - DEPENDENTES de EMPREGADO pode ser obtido 
 através de consulta à entidade DEPENDENTES 
¤  Atributo Determinante: atributo para qual cada instância 
da entidade tem um valor único 
n  Ex.: - REGISTRO do EMPREGADO 
89 
Prof. Marcos Miguel - MBI 
89 
Atributos 
¨  Representação para Tipos de Atributos 
(DER) 
¤  Simples default 
¤  Composto árvore ou ( ) 
¤  Multivalorado * ou { } 
¤  Derivados elipse 
¤  Determinante sublinhado 
90 
Prof. Marcos Miguel - MBI 
90 
Atributos 
¨  Tipos de Atributos 
91 
Prof. Marcos Miguel - MBI 
91 
Atributos 
¨  Observações 
¤  Toda Entidade deve ter pelo menos 1 atributo 
determinante (sublinhar todos) 
¤  Pode ser artificialmente criado ou concatenado 
¤  Devo representar todo atributo derivado que 
posso imaginar? 
92 
Prof. Marcos Miguel - MBI 
92 
Relacionamentos 
¨  RELACIONAMENTO 
¤  Relaciona duas ou mais entidades e tem um 
significado específico 
n  Ex.: - O EMPREGADO “João da Silva” GERENCIA o 
 DEPARTAMENTO “Suporte de Sistemas” 
¤  Relacionamentos semelhantes são agrupados em 
um TIPO DE RELACIONAMENTO 
n  Ex.: - TRABALHA-EM entre EMPREGADO e PROJETO 
 GERENCIA entre EMPREGADO e DEPARTAMENTO 
93 
Prof. Marcos Miguel - MBI 
93 
Relacionamentos 
¨  Exemplos: 
¤  Um cliente faz pedidos de compra de um ou mais 
livros, para um ou mais fornecedores 
¤  Um livro é especificado em um ou mais pedidos de 
compra, de um ou mais clientes, para um ou mais 
fornecedores 
¤  Um fornecedor recebe um ou mais pedidos de 
compra, de um ou mais livros, de um ou mais 
clientes 
94 
Prof. Marcos Miguel - MBI 
94 
Relacionamentos 
¨  Exemplo 
95 
Prof. Marcos Miguel - MBI 
95 
Relacionamentos 
¨  Quando o domínio de um atributo de uma 
entidade-tipo a é o mesmo de um atributo 
determinante de uma entidade-tipo B, então: 
¤  Deve existir um atributo na entidade-tipo B cujo 
domínio é o mesmo que um atributo determinante 
da entidade-tipo A 
¤  Removemos estes atributos e substituímos por 
um relacionamento 
96 
Prof. Marcos Miguel - MBI 
96 
Relacionamentos 
97 
Prof. Marcos Miguel - MBI 
97 
Relacionamentos 
¨  Nomenclatura e Representação (DER) 
98 
Prof. Marcos Miguel - MBI 
98 
Relacionamentos 
¨  Mais de um relacionamento pode existir entre 
os mesmos tipos de entidades 
¨  Cada um contém um conjunto diferente 
de instâncias 
99 
Prof. Marcos Miguel - MBI 
99 
Cardinalidade de Relacionamentos 
¨  A) UM - PARA - UM (1:1) 
¤  Uma entidade em “A” está associada com no 
máximo uma entidade em “B”. Uma entidade em 
“B” está associada com no máximo uma entidade 
em “A” 
100 
Prof. Marcos Miguel - MBI 
100 
Cardinalidade de Relacionamentos¨  CARDINALIDADE (1:1) 
101 
Prof. Marcos Miguel - MBI 
101 
Cardinalidade de Relacionamentos 
¨  B) UM – PARA – MUITOS (1:N) 
¤  Uma entidade em “A” está associada a qualquer 
número de entidades em “B” 
¤  Uma entidade em “B”, todavia, pode estar 
associada a no máximo uma entidade em “A” 
102 
Prof. Marcos Miguel - MBI 
102 
Cardinalidade de Relacionamentos 
¨  CARDINALIDADE (1:N) 
103 
Prof. Marcos Miguel - MBI 
103 
Cardinalidade de Relacionamentos 
¨  MUITOS – PARA – MUITOS (N:N) 
¤  Uma entidade em “A” está associada a qualquer 
número de entidades em “B”. Uma entidade em 
“B” está associada a qualquer número de entidades 
em “A” 
104 
Prof. Marcos Miguel - MBI 
104 
Cardinalidade de Relacionamentos 
¨  CARDINALIDADE (N:N) 
105 
Prof. Marcos Miguel - MBI 
105 
Cardinalidade de Relacionamentos 
¨  Grau: especifica o número de instâncias de 
cada um dos tipos de entidades que podem 
estar associadas a cada instância das demais 
entidades naquele relacionamento. Ex.: (_,N) 
¨  Participação de uma entidade em um 
relacionamento: especifica se a existência de 
uma instânc ia do re lac ionamento é 
obrigatória para cada instância daquela 
entidade. Ex.: (0,_) 
106 
Prof. Marcos Miguel - MBI 
106 
Cardinalidade de Relacionamentos 
¨  CARDINALIDADE: 
¤  Nenhum ou vários empregados (0,N) trabalham em um 
e somente um (1,1) departamento 
107 
Prof. Marcos Miguel - MBI 
107 
Cardinalidade de Relacionamentos 
¨  Cardinalidade e Participação podem também 
ser vistas como o número mínimo e máximo de 
associações de cada entidade participante do 
relacionamento 
108 
Prof. Marcos Miguel - MBI 
108 
Atributos de Relacionamento 
¨  Um relacionamento pode ter atributos 
¨  Cada instância do relacionamento terá um valor 
para aquele atributo 
109 
Prof. Marcos Miguel - MBI 
109 
Atributos de Relacionamento 
¨  Natural em N:N 
110 
Prof. Marcos Miguel - MBI 
110 
Atributos de Relacionamento 
¨  Não existe atributo determinante de 
relacionamento 
111 
Prof. Marcos Miguel - MBI 
111 
¨  Modelagem com Atributo Multivalorado 
Atributos de Relacionamento 
112 
Prof. Marcos Miguel - MBI 
112 
Atributos de Relacionamento 
¨  Relacionamentos de grau mais alto 
113 
Prof. Marcos Miguel - MBI 
113 
Grau de Relacionamentos 
¨  Grau = 1: AUTO-RELACIONAMENTO 
¤  Uma entidade se relaciona com ela mesma 
114 
Prof. Marcos Miguel - MBI 
114 
Grau de Relacionamentos 
¨  Grau = 2: BINÁRIO 
¤  Relacionamento entre duas entidades 
¤  Um Departamento tem no mínimo 1 e no máximo N 
Funcionários lotados 
¤  Um Funcionário está lotado em um único Departamento 
115 
Prof. Marcos Miguel - MBI 
115 
Grau de Relacionamentos 
¨  Grau = 3: TERNÁRIO 
¤  Um depósito entrega nenhum ou vários produtos a um ou mais 
clientes 
¤  Um produto é entregue para nenhum ou vários clientes oriundos de 
nenhum ou vários depósitos 
¤  Um cliente recebe nenhum ou vários produtos oriundos de nenhum 
ou vários depósitos 
116 
Prof. Marcos Miguel - MBI 
116 
Grau de Relacionamentos 
¨  Grau > 3: N-ÁRIO 
117 
Prof. Marcos Miguel - MBI 
117 
Auto-Relacionamentos 
¨  Um relacionamento pode associar entidades do mesmo 
tipo, onde cada instância da entidade tem um papel 
distinto. Também chamado de relacionamento recursivo 
ou auto-relacionamento 
¨  Relacionamento Supervisão: cada instância do 
relacionamento relaciona dois empregados: um 
empregado tem o papel de supervisor, o outro tem o 
papel de subordinado 
118 
Prof. Marcos Miguel - MBI 
118 
Auto-Relacionamentos 
¨  Podem ser 1:1, 1:N ou N:N 
119 
Prof. Marcos Miguel - MBI 
119 
Auto-Relacionamentos 
¨  Papéis 
120 
Prof. Marcos Miguel - MBI 
120 
Entidade Fraca 
¨  Entidade Fraca 
¤  Tipo de entidade que não tem um atributo chave próprio 
¤  Entidade fraca é uma entidade que precisa usar o tributo 
determinante de outra entidade para compor seu próprio atributo 
determinante 
¤  A entidade DEPENDENTE é identificada pela combinação dos atributos 
nome, data_nasc e registro do EMPREGADO com o qual o dependente 
se relaciona 
121 
Prof. Marcos Miguel - MBI 
121 
Entidade Fraca 
¤  Se a entidade fraca se relacionar com outras partes 
do DER deve ser entidade e não atributo 
¤  Se não tiver atributos, geralmente deve ser 
modelado como atributo multivalorado (Ex: 
telefones) 
122 
Prof. Marcos Miguel - MBI 
122 
Generalização / Especialização 
¨  Abstrações (SUBCLASSES E SUPERCLASSES) 
¤  Subclasses são usada para representar subgrupos de uma classe de 
entidades 
n  Ex.: A classe EMPREGADO pode ter as seguintes subclasses 
 - SECRETÁRIO 
 - ENGENHEIRO 
 - GERENTE 
 - TÉCNICO 
 - EMPREGADO-ASSALARIADO (EMP-ASSALAR) 
 - EMPREGADO-HORISTA (EMP-HORA) 
¤  Generalização é o mesmo que SuperClasse 
¤  Especialização é o mesmo que SubClasse 
123 
Prof. Marcos Miguel - MBI 
123 
Generalização / Especialização 
¨  Membros de cada subclasse constituem um 
subconjunto das entidades da classe 
EMPREGADO 
¤  A classe EMPREGADO é chamada de superclasse 
em relação a cada uma das suas subclasses 
¤  Também conhecida como relacionamento É-UM 
n  Ex.: GERENTE É-UM EMPREGADO 
124 
Prof. Marcos Miguel - MBI 
124 
Generalização / Especialização 
¨  EXEMPLO DE SUBCLASSES 
125 
Prof. Marcos Miguel - MBI 
125 
Generalização / Especialização 
¨  Uma entidade (instância) em uma subclasse representa a 
mesma entidade no mundo real que a correspondente 
entidade na superclasse 
¤  Ex:. ENGENHEIRO “Pedro Souza” é a mesma entidade do 
mundo real que o EMPREGADO “Pedro Souza” 
¨  Membros de uma subclasse são a mesma entidade em um 
papel específico 
¨  Um membro de uma superclasse deve existir na superclasse 
¨  Um membro de uma superclasse pode opcionalmente existir 
em (qualquer número de) suas subclasses 
¨  Em geral, não é necessário que toda entidade em uma 
superclasse seja um membro de uma subclasse 
126 
Prof. Marcos Miguel - MBI 
126 
Generalização / Especialização 
¨  Membros da subclasse também podem ter seus 
relacionamentos específicos 
¨  Atributos e relacionamentos específicos referem-se 
apenas a membros da subclasse 
¤  Ex.: Relacionamento e atributos de GERENTE não se aplicam a 
EMPREGADO que não seja GERENTE 
¨  Especialização 
¤  É o mecanismo pelo qual novas classes são definidas através 
do refinamento de uma classe mais geral 
127 
Prof. Marcos Miguel - MBI 
127 
Generalização / Especialização 
¨  Toda as subclasses têm uma mesma superclasse 
¨  O conjunto de subclasses é definido por alguma 
característica específica da superclasse 
¨  Pode haver várias especializações de uma mesma 
superclasse baseada em diferentes características 
n  EMP_ASSAL e EMP_HORA são uma especialização de 
EMPREGADO baseada no método de pagamento 
n  SECRETÁRIO, TÉCNICO E ENGENHEIRO são uma 
especialização de EMPREGADO baseada na função do 
empregado 
128 
Prof. Marcos Miguel - MBI 
128 
Generalização / Especialização 
¨  Generalização 
¤  É o processo inverso da especialização: começando de um 
número de classes com alguns atributos ou relacionamento 
em comum, define-se uma classe mais geral 
¤  Especialização e generalização são processos inversos que 
podem ser usados para chegar ao mesmo projeto final 
n  Ex.: Começando das classes CARRO e CAMINHÃO pode-se definir 
a classe de entidade mais genérica VEÍCULO. 
n  VEÍCULO torna-se a superclasse de CARRO e CAMINHÃO 
n  VEÍCULO é uma generalização de CARRO e 
CAMINHÃO 
129 
Prof. Marcos Miguel - MBI 
129 
Generalização / Especialização 
130 
Prof. Marcos Miguel - MBI 
130 
Generalização / Especialização 
131 
Prof. Marcos Miguel - MBI 
131 
Agregação 
¨  Entidade é uma agregação de atributos 
¨  Relacionamento é uma agregação de entidades 
e atributos 
¨  Atributo composto é uma agregação de atributo 
132 
Prof. Marcos Miguel - MBI 
132 
Agregação¨  Representação (DER) 
¤  “C” é uma agregação 
¤  “C” é formada por todas as ocorrências do relacionamento “A-B” 
133 
Prof. Marcos Miguel - MBI 
133 
Agregação 
134 
Prof. Marcos Miguel - MBI 
134 
Agregação 
135 
Prof. Marcos Miguel - MBI 
135 
Agregação 
136 
Prof. Marcos Miguel - MBI 
136 
Agregação 
¨  Exemplo 
¤  ENTIDADES RESULTANTES DA FASE DE LEVANTAMENTO 
n  NOTA FISCAL 
n  DUPLICATA 
n  PAGAMENTO (COMPROVANTE) 
n  CONTA A RECEBER 
n  CONTA RECEBIDA 
137 
Prof. Marcos Miguel - MBI 
137 
Agregação 
¨  DER – Sem o conceito de Agregação 
138 
Prof. Marcos Miguel - MBI 
138 
Agregação 
¨  DER – Usando o conceito de Agregação 
139 
Prof. Marcos Miguel - MBI 
139 
Agregação 
140 
Prof. Marcos Miguel - MBI 
140 
Agregação 
¨  O exemplo anterior é diferente de: 
¨  
¨  Pois, neste caso, não se consegue representar uma disciplina 
que ainda não tenha um professor para ministrá-la 
141 
Prof. Marcos Miguel - MBI 
141 
Agregação e Generalização 
142 
Prof. Marcos Miguel - MBI 
142 
Processo de Modelagem 
¨  Classificar atributos e entidades 
¤  Atributo é uma propriedade e assume valores. Tipo 
de entidade é uma classe de objetos 
¨  Identificar generalizações 
¤  Se forem identificados subconjuntos de entidades 
com propriedades específicas, isto é, se existem 
tipos com propriedades comuns e algumas 
diferenças 
143 
Prof. Marcos Miguel - MBI 
143 
Processo de Modelagem 
¨  Definir relacionamentos 
¤  definindo grau, cardinalidade e participação 
¨  Integrar múltiplas visões de entidades, 
atributos e relacionamentos 
¤  Quando o projeto é muito grande e muitas pessoas 
estão envolvidas na análise de requisitos, deve-se 
utilizar visões que posteriormente devem ser 
consolidadas em uma visão 
144 
Prof. Marcos Miguel - MBI 
144 
Exemplo - Modelo Conceitual 
¨  EXEMPLO 
¤  EMPRESA DE PROJETOS (Requisitos) 
n  TODO EMPREGADO PERTENCE A UM DEPARTAMENTO 
n  TODO DEPARTAMENTO POSSUI UM GERENTE 
n  UM ENGENHEIRO PODE PARTICIPAR DE MAIS DE UM 
PROJETO 
n  TODO PROJETO POSSUI UM LIDER 
n  TODO PROJETO É COORDENADO POR UM DEPARTAMENTO 
n  UM EMPREGADO PODE TER UM OU MAIS DEPENDENTES 
145 
Prof. Marcos Miguel - MBI 
145 
Exemplo - Modelo Conceitual 
146 
Prof. Marcos Miguel 
146 
Modelo 
Relacional 
147 
Prof. Marcos Miguel - MBI 
147 
Modelo Relacional 
¨  Introduzido por Codd (1970) sendo o mais 
simples, mais formal (correspondência com 
relação matemática) e o que tem estruturas de 
dados mais uniformes 
¨  Conceitos do modelo relacional: 
¤  Representa os dados como uma coleção de relações 
(informalmente, cada relação lembra uma tabela ou, algumas 
vezes, um arquivo) 
¤  LINHAS ↔ REGISTROS ↔ TUPLAS 
 COLUNAS ↔ CAMPOS ↔ ATRIBUTOS 
148 
Prof. Marcos Miguel - MBI 
148 
Modelo Relacional 
¨  Cada linha da relação é uma tupla, ou seja, um conjunto de 
valores relacionados. Estes valores podem ser interpretados 
como um fato que descreve uma instância de uma entidade ou 
relacionamento 
¨  No desenho acima, a relação é chamada ESTUDANTE porque 
cada linha representa um instância da entidade ESTUDANTE 
149 
Prof. Marcos Miguel - MBI 
149 
Modelo Relacional 
¨  É um modelo que opera com os dados 
organizados como um conjunto de RELAÇÕES 
¨  O modelo de dados relacional representa o BD 
como uma coleção de tabelas, cada uma das 
quais associada a um nome único 
150 
Prof. Marcos Miguel - MBI 
150 
Modelo Relacional 
¨  REPRESENTAÇÃO TABULAR 
¤  Toda relação pode ser vista como uma TABELA, onde cada 
linha é uma TUPLA e em cada coluna estão valores de um 
mesmo domínio 
¤  Uma tabela é um formato de apresentação de dados mais 
entendido universalmente 
151 
Prof. Marcos Miguel - MBI 
151 
Modelo Relacional 
¨  Algumas propriedades das relações 
¤  Cada tabela tem um nome único através do qual é 
referenciada 
¤  Cada tabela contém um número fixo de colunas 
¤  Cada linha da tabela representa uma tupla ou registro 
da relação 
¤  Todas as linhas são distintas uma das outras (não 
existem linhas iguais) 
¤  A ordem das linhas da tabela é irrelevante 
¤  Cada coluna tem um nome único 
¤  A ordem das colunas é irrelevante 
¤  Cada coluna representa um atributo mono-valorado 
152 
Prof. Marcos Miguel - MBI 
152 
Modelo Relacional 
¤  Os nomes das colunas (atributos): nome, 
endereço, etc. , especificam como interpretar os 
valores dos dados em cada linha, baseando-se na 
coluna em que o dado está 
¤  Um domínio D de um atributo é um conjunto de 
valores atômicos (especificam que cada valor em 
um domínio é indivisível) 
153 
Prof. Marcos Miguel - MBI 
153 
Modelo Relacional 
¨  Um esquema de uma relação R, denotado por 
R (A1, A2,... , AN), é um conjunto de atributos 
R = {A1, A2, ..., AN}. Cada atributo Ai é o 
nome de algum domínio D no esquema da 
relação R. D é denotado por dom (Ai). Um 
esquema de relação é usado para descrever a 
relação. 
¤  R é chamado nome da relação. O grau da 
relação é o número de atributos do esquema 
da relação 
154 
Prof. Marcos Miguel - MBI 
154 
Modelo Relacional 
¨  Associado a cada domínio, temos um nome (que em 
geral é o nome de um atributo), uma definição lógica 
e também um tipo de dado ou formato para o 
domínio. O tipo de dado para número de telefones 
pode ser declarado como um conjunto de caracteres 
na forma (ddd) dddd-dddd, onde cada d é um dígito 
decimal 
¨  Um domínio é portanto formado por um nome, uma 
definição lógica e um formato. Outras informações 
podem ser dadas a respeito de um domínio como, por 
exemplo, unidades de medida 
155 
Prof. Marcos Miguel - MBI 
155 
Modelo Relacional 
156 
Prof. Marcos Miguel - MBI 
156 
Modelo Relacional 
¨  Características 
¤  Cada relação tem um número fixo de atributos, todos com 
nomes distintos 
¤  Os atributos em uma tupla são atômicos (grupos de 
repetição não são permitidos) 
¤  Cada tupla é única (duplicatas não são permitidas) 
¤  As tuplas não tem uma ordem específica na relação 
¤  O mesmo domínio pode ser usado para diferentes 
atributos, tornando-se fonte de valores para diferentes 
colunas na mesma ou em diferentes tabelas 
¤  Instância de uma relação = tabela com linhas e colunas 
¤  Conjunto destas instâncias = extensão de uma tabela 
n  EX: PEÇA (#PEÇA, NOME_PEÇA, COR, TIPO) 
¤  Conjunto destes esquemas = esquema do BD 
157 
Prof. Marcos Miguel - MBI 
157 
Atributos Chave 
¨  Chave 
¤  Conjunto de atributos de uma relação R com a 
propriedade de que nenhum par de tuplas na 
instância r de R tem a mesma combinação de 
valores para aqueles atributos 
158 
Prof. Marcos Miguel - MBI 
158 
Chave Candidata 
¨  É comum uma relação ter mais de uma chave. Neste 
caso, cada uma das chaves é chamada chave 
candidata (ou alternativa) 
¨  Todo atributo (ou conjunto de atributos) para o qual não 
pode haver repetição de valores na tabela. Identifica, de 
maneira inequívoca, uma linha da tabela 
¨  Toda relação tem pelo menos uma chave candidata: a 
concatenação de todos os atributos 
159 
Prof. Marcos Miguel - MBI 
159 
Chave Primária 
¨  A chave candidata cujos valores são usados 
para identificar tuplas em uma relação é 
chamada chave primária (Primary Key) 
¨  É a chave candidata escolhida para identificar 
univocamente uma linha de uma relação 
¨  A chave primária de uma tabela T1, 
corresponde a uma ou mais colunas de T1 de 
tal forma que identifique univocamente as 
ocorrências (linhas) de T1, ou seja, não há 2 ou 
mais linhas de T1 que tenham o mesmo valor 
de chave primária 
160 
Prof. Marcos Miguel - MBI 
160 
Chaves Secundária, Composta e Cega 
¨  CHAVE SECUNDÁRIA (SECUNDARY KEY) 
¤  É a chave candidata que não foi escolhida como primária 
¨  CHAVE COMPOSTA 
¤  É a chave formada por dois ou mais atributos 
concatenados 
¨  CHAVE CEGA (BLIND KEY) 
¤  Chave primária arbitrada que incorporaatributos não 
representativos para o negócio que estiver sendo 
modelado. Esse(s) atributo(s) são criados para identificar 
cada linha de uma relação 
161 
Prof. Marcos Miguel - MBI 
161 
Chave Estrangeira 
¨  Se um atributo (ou atributos) chave não-primário em 
uma relação é chave primária em outra relação, então 
este atributo na primeira relação é chamado de chave 
estrangeira (Foreign Key) 
¨  É chave primária de outra tabela, colocada como atributo 
para mostrar o relacionamento entre tabelas 
¨  A chave estrangeira de uma tabela T2, corresponde a 
uma ou mais colunas de T2 de tal forma que, para cada 
valor não nulo da chave estrangeira de T2, há um valor 
igual a uma chave primária da tabela T1 
162 
Prof. Marcos Miguel - MBI 
162 
Chaves Primária e Estrangeira 
163 
Prof. Marcos Miguel - MBI 
163 
Restrições de Integridade 
¨  São regras gerais que se aplicam a qualquer banco de 
dados baseado no modelo relacional 
¤  Integridade de Chave: Uma relação deve ter pelo menos 
uma chave 
¤  Integridade de Entidade: Nenhum atributo participante da 
chave primária de uma relação pode aceitar valor nulo 
¤  Integridade Referencial: A chave estrangeira deve ter 
correspondência com a chave primária em outra tabela ou ser 
nula 
¤  Integridade Semântica ou Regras de Negócio: São regras 
ditadas pelo negócio e não tratadas na modelagem. 
n  Ex.: o valor mínimo de depósito para abertura de contas é de 
R$ 500,00 
¤  Respeitar as cardinalidades mínimas e máximas 
164 
Prof. Marcos Miguel - MBI 
164 
Integridade de Inserção 
¨  Para garantir a integridade referencial em uma 
operação de inserção, significa que antes de 
ser inserida uma nova linha de uma tabela que 
contém um valor de chave estrangeira, é 
necessário que já exista uma linha em uma 
tabela com este valor de chave primária. Caso 
contrário, a operação de inserção deve ser 
rejeitada ou uma linha com a chave primária 
deverá também ser inserida na respectiva 
tabela 
165 
Prof. Marcos Miguel - MBI 
165 
Integridade de Inserção 
166 
Prof. Marcos Miguel - MBI 
166 
Integridade de Deleção 
¨  Para operações de deleção, também há ações 
alternativas que possibilitam preservar a 
consistência dos dados 
¤  Quando uma linha em uma tabela é 
deletada ,então, todas as ocorrências de chave 
estrangeira desta chave primária também devem 
ser deletadas (efeito cascata) ou os valores de 
chave estrangeira devem ser atualizados para 
nulos 
¤  A operação de deleção pode ser rejeitada se 
existir uma ocorrência de chave estrangeira da 
chave primária a ser deletada 
167 
Prof. Marcos Miguel - MBI 
167 
Integridade de Deleção 
¨  Exemplo 
168 
Prof. Marcos Miguel - MBI 
168 
Integridade de Deleção 
¨  Exemplo 
169 
Prof. Marcos Miguel - MBI 
169 
Integridade de Deleção 
¨  Ações possíveis no caso de exclusão de 
linha 
¤  Exclusão automática de todas as linhas que 
referenciem a chave excluída 
¤  Exclusão não permitida para linhas que sejam 
referenciadas em outras tabelas 
¤  Inserção de valor nulo nas linhas referentes à 
chave excluída 
170 
Prof. Marcos Miguel - MBI 
170 
Integridade de Atualização 
¨  Para a operação de atualização, também há 
ações alternativas que possibilitam preservar a 
integridade dos dados 
¨  Dependendo se já existe o novo valor como 
chave em outra tabela, a atualização pode ser 
rejeitada ou aceita 
¨  Se uma chave primária é atualizada pode ser 
necessário: 
¤  mudar para nulas todas as ocorrências existentes de chave 
estrangeira com o antigo valor 
¤  mudar todas as ocorrências de chave estrangeira do antigo para 
o novo valor 
¤  rejeitar a atualização 
171 
Prof. Marcos Miguel - MBI 
171 
Integridade de Atualização 
¨  Exemplo 
¤  Um determinado departamento mudou o código do 
depto. O que fazer com todos os funcionários 
alocados neste departamento? 
n  deixar todos os funcionários deste departamento sem 
lotação, ou 
n  alocar todos os funcionários deste departamento no 
novo departamento, ou 
n  rejeitar a atualização, pois, não se pode mudar a 
identificação do depto enquanto houver funcionários 
alocados 
172 
Prof. Marcos Miguel - MBI 
172 
Integridade de Atualização 
173 
Prof. Marcos Miguel - MBI 
173 
Integridade de Atualização 
¨  Exemplo 
¤  Um determinado departamento mudou o código do 
depto. O que fazer com todos os funcionários 
alocados neste departamento? 
n  deixar todos os funcionários deste departamento sem 
lotação, ou 
n  alocar todos os funcionários deste departamento no 
novo departamento, ou 
n  rejeitar a atualização, pois, não se pode mudar a 
identificação do depto enquanto houver funcionários 
alocados 
174 
Prof. Marcos Miguel 
174 
Dependência 
Funcional e 
Normalização 
175 
Prof. Marcos Miguel - MBI 
175 
Dependência Funcional 
¨  Análise de dependência funcional é uma técnica 
de normalização que consiste na síntese de 
relações a partir do conhecimento das 
propriedades dos dados, ou seja, a partir das 
“dependências funcionais” existentes entre os 
dados 
176 
Prof. Marcos Miguel - MBI 
176 
Dependência Funcional 
¨  O atributo B é funcionalmente dependente do 
atributo A se, em qualquer instante, um valor em A 
determina, de modo único, o valor correspondente em 
B, na mesma relação. Ou seja, todas as vezes que A é 
alterado, B também é 
¨  O valor do salário de um empregado é funcionalmente 
dependente do num-empregado 
177 
Prof. Marcos Miguel - MBI 
177 
Dependência Funcional 
¨  Observação 
¤  Um atributo pode ser funcionalmente dependente 
de um grupo de atributos ao invés de um único 
n  Exemplo: 
n  Preço do material é funcionalmente dependente da 
chave composta COD-MATERIAL e COD-FORNECEDOR 
178 
Prof. Marcos Miguel - MBI 
178 
Dependência Funcional Total 
¨  Um atributo é totalmente funcionalmente 
dependente da chave primária quando for 
funcionalmente dependente de toda a chave 
primária não funcionalmente dependente de 
qualquer parte da chave primária 
¤  OBS: Quando a chave primária da relação for uma 
chave atômica, um atributo funcionalmente 
dependente da chave será totalmente funcionalmente 
dependente 
179 
Prof. Marcos Miguel - MBI 
179 
Dependência Funcional Total 
¨  A quantidade de horas trabalhadas por um empregado 
em um projeto não é funcionalmente dependente do 
atributo COD-PROJETO, porque não significa o total de 
horas do projeto e não é funcionalmente dependente 
da matrícula do funcionário, porque não significa o 
total de horas trabalhadas pelo empregado 
¨  A quantidade de horas trabalhadas é determinada, de 
modo único, pela composição da matrícula do 
empregado e do código do projeto, porque significa a 
quantidade de horas trabalhadas por empregado em 
um determinado projeto 
180 
Prof. Marcos Miguel - MBI 
180 
Dependência Funcional Parcial 
¨  Um atributo é parcialmente funcionalmente dependente da 
chave primária composta quando for funcionalmente 
dependente de parte da chave primária e não de toda a chave 
primária simultaneamente 
¨  O atributo NOME-FORNECEDOR é funcionalmente dependente 
somente do atributo COD-FORNECEDOR. O nome do 
fornecedor é determinado, de modo único, pelo código do 
fornecedor, independente dos materiais que são fornecidos 
181 
Prof. Marcos Miguel - MBI 
181 
Dependência Funcional Parcial 
¨  A dependência funcional parcial pode ocorrer 
quando a chave primária da relação é composta. 
¤  Constitui numa anomalia que se deve ser evitada 
¤  A solução para o problema da dependência parcial 
consiste na criação de uma nova relação que será 
composta pelo atributo ou atributos que dependem 
de parte da chave e a chave que determine, de 
modo único estes atributos 
182 
Prof. Marcos Miguel - MBI 
182 
Dependência Funcional Transitiva 
¨  Um atributo C é dependente funcional transitivo 
de A se C é funcionalmente dependente de B e 
B funcionalmente dependente de A,na mesma 
relação 
183 
Prof. Marcos Miguel - MBI 
183 
Dependência Funcional Transitiva 
¨  O atributo DATA-TERM-PROJETO é funcionalmente 
dependente do atributo COD-PROJETO que por sua vez é 
funcionalmente dependente do atributo NUM-EMP. Então 
DATA-TERMPROJETO é dependente transitivo de NUM-
EMPREGADO 
¨  A dependência funcional transitiva constitui numa anomalia 
que deve ser evitada. A solução para o problema da D.F.T. 
consiste na criação de uma nova relação que será composta 
pelo atributo ou atributos que serão dependentes funcionais 
transitivos tendo como chave primária o atributo que 
determina 
184 
Prof. Marcos Miguel - MBI 
184 
Resultado da Análise da Dependência 
Funcional 
¨  Uma relação estará normalizada segundo a 
análise da dependência funcional, quando 
possui uma única chave primária, todos os 
atributos não chaves forem totalmente 
funcionalmente dependentes da chave primária 
e independentes entre si, ou seja, após a 
eliminação da dependência funcional parcial e 
transitiva, caso exista 
185 
Prof. Marcos Miguel - MBI 
185 
Normalização 
¨  Objetivo: Obter relações que não sofram de 
determinadas anomalias que prejudicam a 
manutenção e a integridade dos dados 
¨  Método: Refinamento das relações através da 
sua composição sem prejuízo das informações 
contidas nas mesmas 
¤  Formas Normais: 
186 
Prof. Marcos Miguel - MBI 
186 
Normalização 
¨  Uma tabela está na primeira forma normal (1FN) se e 
somente se todas as colunas correspondentes contém 
apenas valores atômicos 
¨  Uma tabela está na segunda forma normal (2FN) se 
está na primeira forma normal e todo atributo não 
chave é totalmente dependente da chave primária 
¨  Uma tabela está na terceira forma normal (3FN) se e 
somente se ela está na segunda forma normal e todo 
atributo não chave é mutuamente independente 
187 
Prof. Marcos Miguel - MBI 
187 
Normalização 
¨  Normalmente os casos que violam a normalização refletem um 
projeto ruim 
¨  A normalização é um método para validar a qualidade de um 
modelo de dados, não um método para desenvolvê-lo 
¨  Princípios básicos – Todo atributo deve: 
188 
Prof. Marcos Miguel - MBI 
188 
Normalização 
¨  EXEMPLO: 
¤  Uma empresa mantém uma cooperativa para vender aos 
seus funcionários uma série de bens de consumo. Tantas 
vezes por mês quantas forem do desejo do funcionário, ele 
pode se dirigir à cooperativa e fazer suas compras, 
assinando na passagem pelo caixa uma autorização para 
débito da despesa no seu contra-cheque com as notas 
descritivas de cada uma das compras efetuadas ao longo do 
mês 
189 
Prof. Marcos Miguel - MBI 
189 
Normalização 
¨  Dados constantes da nota descritiva: 
¤  número da matrícula do funcionário (NUM_FUNC) 
¤  número da nota (NOME_FUNC) 
¤  data da compra (DATA_NOTA) 
¤  código do departamento do funcionário (COD_DEP) 
¤  nome do departamento (NOME_DEP) 
¤  local do departamento (LOCAL_DEP) 
¤  código de cada produto comprado (COD_PROD) 
¤  nome de cada produto comprado (NOME_PROD) 
¤  valor de cada produto comprado (VAL_PROD) 
¤  quantidade de cada produto comprado (QTD_COMPR) 
190 
Prof. Marcos Miguel - MBI 
190 
Normalização 
¨  Construindo uma relação que contenha todas as 
informações necessárias para aplicação descrita 
¤  REL1(NUM_FUNC, NUM_NOTA, COD_PROD, NOME_FUNC, DAT_NOTA, 
COD_DEP, NOME_DEP, LOCAL_DEP, NOME_PROD,VAL_PROD, 
QTD_COMPR) 
 1ªFN 
¤  Dado o valor chave da relação, temos um e somente um 
valor para cada atributo da relação 
191 
Prof. Marcos Miguel - MBI 
191 
Normalização 
¨  Algumas anomalias 
¤  Inserção: nenhum funcionário pode ser inserido até que se 
tenha ao menos um produto adquirido 
¤  Deleção: ao se deletar a última nota para um empregado, 
todas referências àquele empregado são deletadas 
¤  Atualização: o local de um departamento é repetido várias 
vezes 
¤  Se um departamento tiver o local alterado, muitos registros 
devem ser atualizados 
192 
Prof. Marcos Miguel - MBI 
192 
Normalização 
¨  FUNC (NUM_FUNC, NOME_FUNC, COD_DEP, NOME_DEP, 
LOCAL_DEP) 
¨  NOTA (NUM_NOTA, DATA_NOTA, NUM_FUNC) 
¨  PROD (COD_PROD, NOME_PROD) 
¨  COMPRA (NUM_NOTA, COD_PROD, VAL_PROD, 
QTD_COMPR) 
 2ª FN 
¤  Para determinar um valor único para cada atributo da relação, é 
necessário fornecer os valores de todos os componentes da chave 
193 
Prof. Marcos Miguel - MBI 
193 
Normalização 
¨  Algumas anomalias 
¤  Inserção: para que sejam inseridas informações sobre um 
departamento, ele deve ter pelo menos um empregado 
alocado 
¤  Deleção: ao se deletar o último empregado de um 
departamento, todas as referências àquele departamento 
são deletadas 
¤  Atualização: o local de um departamento é repetido várias 
vezes. Se um departamento tiver um local alterado, muitos 
registros devem ser atualizados 
194 
Prof. Marcos Miguel - MBI 
194 
Normalização 
¨  FUNC (NUM_FUNC, NOME_FUNC, COD_DEP) 
¨  DEPART (COD_DEPART, NOME_DEP, LOCAL_DEP) 
¨  NOTA (NUM_NOTA, DATA_NOTA, NUM_FUNC) 
¨  PROD (COD_PROD, NOME_PROD) 
¨  COMPRA (NUM_NOTA, COD_PROD, VAL_PROD, 
¨  QTD_PROD) 
 3ª FN 
¤  Não existem atributos na relação que tenham dependência funcional 
total em relação a outro atributo da relação que não é chave 
195 
Prof. Marcos Miguel - MBI 
195 
Primeira Forma Normal – 1ª FN 
¨  Uma relação está na 1ª FN se e somente se todos os 
seus atributos pertencem a domínios simples (valores 
atômicos) 
¨  O objetivo da 1ª FN é eliminar 
¤  dado estruturado 
¤  dado multivalorado 
¨  Os atributos multivalorados serão agrupados em uma 
nova relação. Deve-se escolher uma chave para o novo 
agrupamento, composta pela chave do agrupamento 
original e complementada pelo(s) atributo(s) que 
definiu(ram) a multivaloração 
196 
Prof. Marcos Miguel - MBI 
196 
1ª FN - Exemplo 
197 
Prof. Marcos Miguel - MBI 
197 
1ª FN - Exemplo 
198 
Prof. Marcos Miguel - MBI 
198 
1ª FN - Problemas 
¨  Se a chave for composta por mais de um 
atributo, alguns atributos que não sejam 
chaves, poderão depender de parte da chave, e 
não da chave toda 
¨  Alguns dos atributos que não sejam chaves, 
podem estar inter-relacionados 
¨  A 2ª e 3ª formas normais objetivam solucionar 
estes problemas 
199 
Prof. Marcos Miguel - MBI 
199 
Segunda Forma Normal – 2ª FN 
¨  Uma tabela é dita na segunda forma normal se, além de 
estar na primeira forma normal, todos os seus campos que 
não pertençam a sua chave primária, forem totalmente 
funcionalmente dependentes dela 
¤  Assim sendo, campos que não sejam dependentes exatamente da 
mesma chave,devem ser separadas em diferentes tabelas 
200 
Prof. Marcos Miguel - MBI 
200 
Segunda Forma Normal – 2ª FN 
¨  Não existe Dependência Funcional Parcial dos 
atributos não chave 
¨  Só tem sentido quando a chave é formada 
por mais de um atributo (chave composta) 
¨  Os atributos com D.F.P. serão agrupados em 
uma nova relação, cuja chave é formada 
pelos identificadores que definiram a 
dependência parcial 
¨  Apenas os atributos que dependem 
totalmente da chave composta permanecem 
na relação original 
201 
Prof. Marcos Miguel - MBI 
201 
2ª FN - Exemplo 
202 
Prof. Marcos Miguel - MBI 
202 
Anomalias da 2ª FN 
¨  Inclusão: não poderia incluir um funcionário sem 
dependente (chave não pode conter valor nulo) 
¨  Exclusão: filho deixa de ser dependente (único 
dependente) -> perda de informações do 
funcionário 
¨  Alteração: alteração de salário -> todas as linhas 
devem ser alteradas 
203 
Prof. Marcos Miguel - MBI 
203 
Terceira Forma Normal - 3ª FN 
¨  Uma tabela é dita na terceira forma normal se,além de 
estar na segunda forma normal, todos os seus campos 
forem mutualmente independentes (atributos não-chave 
são dependentes não-transitivos da chave primária) 
¤  Assim sendo, campos que estejam envolvidos numa 
dependência funcional mútua, devem ser transferidos para 
outra tabela204 
Prof. Marcos Miguel - MBI 
204 
Terceira Forma Normal - 3ª FN 
¨  Não existe Dependência Funcional Transitiva 
¨  Os atributos com D.F.T. serão agrupados em uma nova 
relação cuja chave é formada pelos atributos que 
definiram a dependência transitiva. Estes atributos 
continuam na tabela original, por que são o elo de 
ligação entre as tabelas 
¨  Deve-se evitar a redundância. Dados derivados, que 
podem ser calculados através dos valores de outros 
atributos, não devem ser guardados 
205 
Prof. Marcos Miguel - MBI 
205 
3ª FN - Exemplo 
206 
Prof. Marcos Miguel - MBI 
206 
3ª FN - Exemplo 
¤  Está na 1ª e 2ª FN porém não está na 3ª FN pois NOME-
PROJ e DATA-TERM são determinados apenas conhecendo-
se o NUMPROJETO 
207 
Prof. Marcos Miguel - MBI 
207 
3ª FN - Exemplo 
208 
Prof. Marcos Miguel - MBI 
208 
Exemplo de Normalização 
209 
Prof. Marcos Miguel - MBI 
209 
Exemplo de Normalização 
¨  A relação está na 1ª FN pois não contém grupos 
repetidos 
¨  Eliminar o fato de TÍTULO, AUTOR e PREÇO serem 
determinados apenas conhecendo-se o ISBN 
(International Standard Book Number) 
210 
Prof. Marcos Miguel - MBI 
210 
Forma Normal de Boyce-Codd (FNBC) 
¨  Surgiu para resolver problemas de entidades 
que eventualmente possam ter chaves com 
elementos sobrepostos 
¨  Tenta corrigir imperfeições deixadas pela 
definição da 3ª FN, que era condescendente 
caso a relação tivesse mais de uma chave 
candidata a ser chave primária 
¨  Em toda relação FNBC os determinantes são 
chaves candidatas 
211 
Prof. Marcos Miguel - MBI 
211 
Forma Normal de Boyce-Codd (FNBC) 
¨  Situação 
¤  Existem duas ou mais chaves possíveis para uma 
relação 
¤  Essas chaves são compostas 
¤  Têm pelo menos um atributo em comum 
212 
Prof. Marcos Miguel - MBI 
212 
Forma Normal de Boyce-Codd (FNBC) 
¨  Exemplo 
¨  Está na 3ª FN: 
¤  No caso de considerar a chave (NumNota, Descricao), 
não há transitividade alguma 
¤  No caso da chave (Codigo, NumNota), já que Codigo 
define Descricao, a dependência não é total em relação 
à chave 
¤  A 2ª e 3ª FN só previam o caso de dependências 
parciais e transitivas de colunas fora de qualquer 
chave. Como Descricao pertence a uma chave, ela não 
entra nas verificações 
213 
Prof. Marcos Miguel - MBI 
213 
Forma Normal de Boyce-Codd (FNBC) 
¨  A relação NotaFiscal, apesar de estar em 3ª FN, 
apresenta anomalias. Por exemplo, a eliminação de 
uma nota onde aparece pela única vez a descrição de 
um material, faz com que esta informação seja perdida 
¤  NotaFiscal não está em FNBC 
n  Codigo → Descricao mas Codigo → Quant e Codigo → 
NumNota 
¤  Solução 
n  NotaFiscal (NumNota, Codigo, Qtde) 
n  Material (Codigo, Descricao) 
214 
Prof. Marcos Miguel - MBI 
214 
Quarta Forma Normal – 4ª FN 
¨  A 4ª FN surgiu para resolver problemas de atributos 
multivalorados independentes 
¤  Exemplo: 
¤  Livro (NumChamada, (Autor), Titulo, (Assunto)) 
¤  Passando para a 1ª FN: 
n  Livro (NumChamada, Autor, Assunto, Titulo) 
¤  Passando para a 2ª FN: 
n  Livro1 (NumChamada, Titulo) 
n  Livro2 (NumChamada, Autor, Assunto) 
215 
Prof. Marcos Miguel - MBI 
215 
Quarta Forma Normal – 4ª FN 
¨  As relações estão em 3ª FN e FNBC, pois não 
há nenhuma dependência funcional 
¨  Entretanto, existem muitas redundâncias, uma 
vez que, para cada livro, repete-se a 
informação de quais são seus autores tantas 
vezes quantas são seus assuntos, e vice-versa 
¤  Solução: 
n  Livros2A (NumChamada, Autor) 
n  Livros2B (NumChamada, Assunto) 
216 
Prof. Marcos Miguel - MBI 
216 
Quinta Forma Normal – 5ª FN 
¨  A 5ª FN trata de atributos dependentes e 
surgiu para resolver os processos de 
decomposição de entidades em visões 
(subconjuntos) e a possível reconstituição da 
relação original pela junção destas visões 
(subconjuntos) 
¨  Uma relação estará em 5ª FN se, e somente se, 
as dependências de junção (das visões) 
estiverem subentendidas pela chave da relação 
217 
Prof. Marcos Miguel - MBI 
217 
Quinta Forma Normal – 5ª FN 
¨  Considere a seguinte relação: 
¤  Atleta (NumAtleta, SexoAtleta, IdadeAtleta, 
EnderecoAtleta) 
¤  Exemplo: 
n  Atleta1 (NumAtleta, SexoAtleta, IdadeAtleta) 
n  Atleta2 (NumAtleta, EnderecoAtleta) 
¤  Esta relação está em 5ª FN, pois a dependência de 
junção pode ser subentendida pela chave 
218 
Prof. Marcos Miguel - MBI 
218 
Quinta Forma Normal – 5ª FN 
¨  Considere a seguinte situação 
¤  Participacao (NumAtleta, TipoCompeticao, Data) 
219 
Prof. Marcos Miguel - MBI 
219 
Quinta Forma Normal – 5ª FN 
¨  A relação anterior poderia ser assim modelada? 
¤  A-C (NumAtleta, TipoCompeticao) 
¤  A-D (NumAtleta, Data) 
¤  C-D (TipoCompeticao, Data) 
220 
Prof. Marcos Miguel - MBI 
220 
Quinta Forma Normal – 5ª FN 
¨  Verifique o exemplo: 
221 
Prof. Marcos Miguel - MBI 
221 
Exercícios de Normalização 
¨  DADOS-EMPREGADO 
 #Matrícula 
 Nome 
 Endereço 
 Código-Cargo-Atual 
 Nome-Cargo-Atual 
 CURSOS N vezes 
 Cod-Curso 
 Nome-Curso 
 Data-Conclusão 
 Nota-Final 
 HABILIDADES N vezes 
 Cod-Habilidade 
 Nome-Habilidade 
 Grau-Habilitação 
 Data-Admissão 
 Código-Orgão-lotação 
 Nome-Orgão-lotação 
222 
Prof. Marcos Miguel - MBI 
222 
Exercícios de Normalização 
¨  PEDIDOS (#Num-Pedido, Data-Pedido, Num-Cliente, End-
Cliente, (Cod-Produto, Nome-Produto, Preço-Unitário, Qtde-
Pedida, Valor-Total-Item), Valor-Total-Pedido) 
¨  CONTRATO (#Num-Contrato, Cod-Cliente, Nome-Cliente, 
CPF-Cliente, Dt-Inic-Contrato, Dt-Term-Contrato, (Num-
Prestação, Valor-Prestação, Dt-Venc-Prest),Valor-Total-
Contrato) 
¨  EMPREGADO (#Cod-Empregado, Nome-Empregado, Título-
Empregado, (Cod-Curso, Data-Início-Curso, Resultado-Curso)) 
¨  PEÇA-ESTOCADA (#Cod-Peça, #Cod-Armazenada, Qtde-
Estocada,Tel-Armazém) 
¨  HORÁRIO-VÔO(#Sigla-Cia, #Num-Vôo, Horário-Vôo, Sigla-
Aeroporto, Nome-Aeroporto, Cidade-Aeroporto, Status-Vôo) 
223 
Prof. Marcos Miguel - MBI 
223 
Exercícios de Normalização 
¨  QUADRO-PESSOAL 
 #Cod-Orgão 
 Nome-Orgão 
 CARGO N vezes 
 Cod-Cargo 
 Nome-Cargo 
 Número-Vagas 
 FUNCIONÁRIO N vezes 
 Matrícula-Emp 
 Nome-Emp 
 Data-Posse-Emp 
224 
Prof. Marcos Miguel - MBI 
224 
Diagramas de Tabelas Relacionais (DTR) 
¨  Toda entidade vira uma tabela 
¨  Todo relacionamento com atributo vira uma 
tabela 
¨  Todo relacionamento N:N vira uma tabela 
¨  Simbologia 
225 
Prof. Marcos Miguel - MBI 
225 
Mapeamento 1:1 
¨  As duas relações possuem a mesma chave 
primária 
¨  Pode-se unir as duas relações 
226 
Prof. Marcos Miguel - MBI 
226 
Mapeamento 1:1 
¨  As duas relações possuem chaves primárias 
diferentes 
¤  Pelo menos uma das entidades possui participação total no 
relacionamento 
227 
Prof. Marcos Miguel - MBI 
227 
Mapeamento 1:1 
¤  Ambas as entidades possuem participação parcial 
no relacionamento 
228 
Prof. Marcos Miguel - MBI 
228 
Mapeamento 1:N 
¨  A entidade do lado 1 possui participação total 
no relacionamento 
229 
Prof. Marcos Miguel - MBI 
229 
Mapeamento 1:N 
¨  A entidade do lado 1 possui participação 
parcial no relacionamento 
230 
Prof. Marcos Miguel - MBI 
230 
Mapeamento N:N 
¨  Um relacionamento N:N pode ser resolvido em 
dois relacionamentos 1:N 
¨  Uma relação de interseção deve ser 
implementada 
231 
Prof. Marcos Miguel - MBI 
231 
Mapeamento N:N 
232 
Prof. Marcos Miguel - MBI 
232 
Mapeamento Agregação 
233 
Prof. Marcos Miguel - MBI 
233 
Mapeamento Auto-Relacionamento 
234 
Prof. Marcos Miguel - MBI 
234 
Mapeamento de Hierarquias 
235 
Prof. Marcos Miguel - MBI 
235 
Mapeamento de Hierarquias 
236 
<fim> 
Banco de Dados I 
Prof. Marcos Miguel 
marcos.a.miguel@gmail.com 
http://marcosmiguel.com