Apostila Modelagem e Desenvolvimento de Banco de Dados.pdf

SUMÁRIO
M Ó D UL O 1
M Ó D UL O 2
M Ó D UL O 3
M Ó D UL O 4
M Ó D UL O 5
M Ó D UL O 6

O QUE VEREMOS NESTE MÓDULO
M Ó D UL O 1

002
Apresentação do Curso
Atualmente, lidamos com tecnologia constantemente. Com as empresas não é diferente. Elas estão
utilizando a tecnologia ara favorecer a organização, melhorar a comunicação interna e externa, formular
um bom planejamento e tomar decisões diante do mercado.
Tudo isso ocorre, entre outros fatores, devido ao armazenamento de suas informações. Assim, muito
provavelmente a maior parte dos softwares que conhecemos e utilizamos no dia a dia faz uso de algum
tipo de banco de dados, que objetivam armazenar e organizar as informações e utilizar recursos que
permitem recuperá-las de forma rápida e organizada.
Banco de Dados Servidor Usuário

003
Durante grande parte do curso SQL Impressionador dedicamos esforços para aprender a utilizar a
linguagem SQL dentro de programas especiais, chamados Sistemas de Gerenciamento de Bancos de
Dados Relacionais (SGBDRs), com o objetivo de manipular bancos de dados e tabelas.
De forma geral, esses bancos de dados e tabelas ou já estavam prontos, ou criamos por meio de
comandos CRUD (CREATE, UPDATE, DELETE).
Porém, em ambos os casos, ainda não estávamos muito preocupados com uma etapa bastante
importante quando falamos de bancos de dados, anterior a tudo o que fizemos até então.
Bancos de Dados e
Tabelas Linguagem SQL
?

004
Esta etapa anterior se trata da etapa de Modelagem de Bancos de Dados.
É através dessa etapa que definimos quais são as tabelas do banco, quais informações serão
armazenadas dentro das tabelas e como serão feitas as relações entre as tabelas.
Por isso, a partir deste módulo, vamos dedicar um tempo para entender a fundo todas as etapas
envolvidas dentro de um projeto de Modelagem de Bancos de Dados.
Vamos começar!
Bancos de Dados e
Tabelas Linguagem SQL
Modelagem de
Bancos de Dados

005
Qual a Importância da Modelagem de Dados
Um dos recursos mais valiosos dentro das empresas são os dados: dados financeiros, dados de
marketing, dados de vendas, dados de pessoas, etc. Esses dados são armazenados dentro de tabelas e de
bancos de dados, e o seu acompanhamento é fundamental para conseguir entender um negócio e para
onde ele está indo.
Porém, antes de um banco de dados ficar disponível para consultas, é preciso que ele seja modelado, de
modo a definir todas as entidades relacionadas, seus respectivos atributos, e como essas entidades se
relacionam entre si.
O objetivo da modelagem de bancos de dados é representar o mundo real observado com o máximo de
precisão, para que assim seja possível ter as informações certas armazenadas e a partir delas tomar
decisões de negócio.
Entender conceitos sobre a modelagem de dados vai nos ajudar tanto na concepção de novos bancos de
dados, como também entender melhor a origem das tabelas, colunas, e bancos de dados que nos
deparamos nas empresas.

006
Dado x Informação
Vamos começar entendendo a diferença entre dado e informação.
Um dado é um fato em sua forma primária, podendo ser armazenado em algum meio. Por exemplo:
Nome, CPF, Data de Nascimento.
De forma geral, um dado por si só não tem muita significância. Vamos pensar no valor 2.000. Esse
número isolado tem algum significado pra você? Acredito que não.
Porém, nunca teremos um único dado isolado. Teremos sempre dados organizados de forma a, em
conjunto, terem algum significado. É ai que entra a ideia de informação.
Uma informação são os fatos organizados de maneira a produzir algum significado. Por exemplo: Lista
de Funcionários com os seus salários ordenados.
Agora, se eu te disser que 2.000 é o valor médio de salário de um estagiário da empresa que você
trabalha, isso tem algum novo significado pra você?

007
Bancos de Dados
A ideia então será conseguir organizar de forma centralizada uma série de dados, que em conjunto,
terão algum significado.
É ai que entra a ideia de Bancos de Dados.
Um Banco de Dados é uma coleção organizada de dados. Esses dados são organizados de forma a
modelar aspectos do mundo real, para que seja possível efetuar processamento que gere informações
relevantes para os usuários a partir desses dados.
Um Banco de Dados é composto por diversos objetos, como: tabelas, visualizações, procedimentos,
triggers, e assim vai.

008
Bancos de Dados
Existem vários tipos de bancos de dados, no entanto, os principais são: banco de dados relacional e
banco de dados orientado a objetos.
• Banco de dados relacional (SQL): modelo que utiliza tabelas, compostas por linhas e colunas, para
representar e armazenar os dados. Essas tabelas possuem uma relação entre si.
• Banco de dados orientado a objetos: esse modelo é organizado na forma de diferentes objetos, os
quais contém arquivos e informações agrupados, além dos procedimentos para sua leitura e
processamento.
• Banco de dados não relacional (NoSQL): esse modelo armazena os dados em formato de documentos
e prioriza o armazenamento de grandes volumes de dados em detrimento da manutenção da
consistência.
Durante o curso de Modelagem, vamos nos concentrar nos bancos de dados relacionais.

009
Sistemas de Gerenciamento de Bancos de Dados
Um Sistema de Gerenciamento de Banco de Dados Relacional (SGBDR) é um software que possui
recursos capazes de manipular as informações do banco de dados e interagir com os usuários.
Será no SGBDR que criaremos as tabelas e bancos de dados do nosso modelo.
Alguns exemplos de SGBDR:

010
Aplicações de Bancos de Dados
Bancos de dados encontram aplicações em diferentes áreas, dentre elas:
• Sistema de Vendas
• Sistemas bancários
• Sistemas de Supermercados
• Receita Federal
• Instagram
• Youtube
• Dentre outros...

011
Um Modelo de Dados é uma descrição formal da estrutura de um banco de dados. Esse modelo pode ser
dividido em outros três:
Modelos de Dados
Modelo Conceitual Modelo Lógico Modelo Físico
Modelo de Dados que representa a
estrutura de dados de um banco de
dados conforme vista pelo usuário
do SGBD.
Neste ponto, representamos
entidades, atributos e relações em
estruturas de tabelas.
Usado para projetar o esquema
interno do banco de dados,
descrevendo as tabelas, suas
colunas e os relacionamentos entre
elas.
Sua implementação acontece por
meio da linguagem SQL, específica
para criação de bancos de dados.
É o processo de planejar um banco
de dados em termos de: Entidades,
Atributos e Relacionamentos.
Também é composto por uma
representação visual dos conceitos
do banco de dados, criada para
maior clareza e entendimento dos
requisitos do sistema.

012
Níveis de Abstração de um Banco de Dados
Vamos ver um exemplo para entender cada nível.
Imagine que criamos um modelo para
representar “pessoa”. Cada pessoa possui os
seguintes atributos: cpf e nome.
CPF: 999.999.999-99
Nome: Ana

013
Modelo Conceitual
Representamos “pessoa” através de um modelo
conceitual, que identifica de forma objetiva os
atributos daquele elemento “pessoa”.
O atributo CPF é o que diferencia cada pessoa, e
é conhecido como atributo identificador.
Quando criamos qualquer modelo, é importante
que a gente consiga, de alguma forma, fazer essa
diferenciação.
Neste momento, ainda não estamos preocupados
com o SGBD que será utilizado. Nossa
preocupação é apenas representar, por meio de
diagramas, cada entidade do negócio e quais
atributos estão associados a ela.
CPF: 999.999.999-99
Nome: Ana
CPF Nome
Pessoa
Conceitual

014
Modelo Lógico
Neste momento, traduzimos o diagrama
conceitual em tabelas que vão armazenar as
informações das entidades e seus respectivos
atributos.
Cada linha (registro/tupla) da tabela
corresponde a uma ocorrência de “pessoa”.
Importante reforçar que nenhuma linha dessa
tabela, ou seja, nenhuma pessoa dessa tabela,
pode se repetir. Por mais que uma pessoa tenha o
mesmo nome, elas não podem ter um mesmo
CPF. Isso significa que a coluna CPF identifica de
forma única cada pessoa. Representamos a
coluna identificadora com um sublinhado.
CPF: 999.999.999-99
Nome: Ana
CPF Nome
Pessoa
Conceitual
Lógico
CPF Nome
999.999.999-99 Ana

015
Modelo Físico
Por fim, vamos transformar tudo o que foi
planejado nos modelos conceitual e físico em um
código SQL dentro de um SGBD para criação do
banco de dados.
CPF: 999.999.999-99
Nome: Ana
CPF Nome
Pessoa
Conceitual
Lógico
CPF Nome
999.999.999-99 Ana
Físico
CREATE TABLE Pessoa(
CPF VARCHAR(11) NOT NULL,
Nome VARCHAR(50) NOT NULL,
PRIMARY KEY(CPF)
);

016
Modelo Conceitual
Vamos continuar falando sobre o modelo conceitual, e dessa vez vamos observar um modelo
relacionado à trânsito. Teremos portanto a seguinte situação:
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
n n
No modelo acima, temos que a entidade “pessoa” dirige a entidade “carro”. Ou seja, são coisas da
realidade cujas informações (atributos) queremos armazenar. A relação entre essas duas entidades é
dada pela ação “dirige”. Ou seja, pessoa dirige carro.
O “n” em cada um dos lados significa que: 1 pessoa pode dirigir n (vários) carros, assim como 1 carro
pode ser dirigido por n (várias) pessoas. Damos a isso o nome de cardinalidade, que veremos em
detalhes mais a frente.

017
Modelo Lógico
CPF Nome Sexo Placa Modelo Ano
P_CPF C_Placa
PESSOA DIRIGE CARRO
Podemos simplificar a imagem acima e descrever as tabelas da seguinte forma:
• Pessoa(CPF, Nome, Sexo)
• Carro(Placa, Modelo, Ano)
• Dirige(P_CPF, C_Placa)
P_CPF referencia Pessoa(CPF)
C_Placa referencia Carro(Placa)
O modelo lógico representa
os dados em um banco de
dados como sendo um
conjunto de relações.
Cada linha da tabela é
denominada registro (tupla).
Já a coluna é denominada
como atributo. Por fim, a
tabela é chamada de relação.
No modelo lógico, vamos
transformar as entidade-
relacionamentos em tabelas.

018
Modelo Físico
Por fim, chegamos no nosso modelo físico, onde finalmente vamos definir o código para criação das
tabelas dentro do software de banco de dados.
P_CPF C_Placa
PESSOA DIRIGE CARRO
CREATE TABLE Pessoa(
CPF VARCHAR(11),
Nome VARCHAR(50) NOT NULL,
Sexo VARCHAR(1) NOT NULL,
PRIMARY KEY(CPF)
);
CREATE TABLE Carro(
Placa VARCHAR(7),
Modelo VARCHAR(50) NOT NULL,
Ano INT NOT NULL,
PRIMARY KEY(Placa)
);
CREATE TABLE Dirige(
P_CPF VARCHAR(11),
C_Placa VARCHAR(7),
PRIMARY KEY(P_CPF, C_Placa),
FOREIGN KEY(P_CPF)
REFERENCES Pessoa(CPF),
FOREIGN KEY(Placa)
REFERENCES Carro(Placa)
);

019
Vejamos um exemplo bem simples para falar das etapas de modelagem.
Imagine que uma universidade contratou um analista para desenvolver um sistema para automatizar os processos
relacionados a relacionamento de alunos e professores.
Nesse sistema, será necessário:
1) Cadastrar os professores e alunos;
2) Disciplinas;
3) Registro de notas dos alunos;
4) Controle de presença e falta.
Para desenvolver este sistema, o analista vai observar o mundo real, ou seja, como essa informação é gerada. A partir
disso, ele vai entender quais são os conceitos relevantes para esse projeto.
Então ao observar a realidade, o analista concluiu que “professor” é um elemento importante, “aluno” é um elemento
importante, “curso” é um elemento importante. E a partir disso, vamos querer armazenar essas informações dentro de
um banco de dados relacional.
Etapas da Modelagem de Dados

020
Começamos então com o
nosso analista, responsável
por desenvolver o projeto.
Analista de
Sistemas
1

021
Observa
Realidade
Para definir como o projeto será executado, o analista
observa o mundo real (a universidade) e entende quais são
os principais elementos envolvidos naquela realidade, para
então levar isso para um sistema de informação.
Analista de
Sistemas
2

022
Observa
Realidade
O primeiro passo é desenhar um modelo conceitual. Um modelo é uma
representação simplificada da realidade. Vamos gerar uma entidade chamada
“aluno”. Uma entidade é uma coisa do mundo real sobre a qual desejamos armazenar
informações. Para a entidade “aluno”, vamos querer armazenar as informações
(atributos) que serão: matrícula e nome.
3
Analista de
Sistemas
Matrícula
Aluno
Modelo Conceitual
Nome

023
Observa
Realidade
Agora, vamos representar o modelo conceitual em uma forma de modelo lógico, onde
as informações serão armazenadas em formato de tabela. Observe que os atributos
de “aluno” (matrícula e nome) se transformaram em colunas da tabela. Já a
ocorrência de um aluno será representado por uma linha da tabela. Portanto, uma
tabela será um conjunto de linhas (registros) exclusivos.
4
Analista de
Sistemas
Modelo Lógico
Matrícula Nome
1 João
Matrícula Nome
Aluno
Modelo Conceitual

024
Observa
Realidade
Por fim, estes modelos serão
enviados para um implementador
(DBA) para que possa criar o
banco de dados em algum
software de banco de dados
apropriado (SQL Server, MySQL,
PostgreSQL, Oracle, ...)
5
Analista de
Sistemas
Matrícula Nome
Aluno
Modelo Conceitual Modelo Lógico
Matrícula Nome
1 João
Modelo Físico (SGBD)

025
1
Entendimento
do Problema
2
Levantamento
de Requisitos
3
Identificação de
Entidades e
Relacionamentos
4
Diagrama ER:
Cardinalidades e
Eliminação de N:N
5
Definição das
Tabelas e
Restrições de
Integridade
6
Normalização
7
Ajustes no Modelo Lógico
e Dicionário de Dados
8
Implementação
do Modelo
Físico
9
Testes Básicos
no SGBD
Modelo Conceitual Modelo Lógico Modelo Físico

026
Resumo do Módulo
A modelagem de dados é o primeiro passo para criação de bancos de dados.
O processo de modelagem de dados é extremamente importante para que o mundo real seja
representado com a maior precisão possível e assim permitir o melhor aproveitamento dos dados.
Um dado isolado não tem muito significado. Ele será relevante apenas se estiver em conjunto com
outros dados, dando origem à informação.
A modelagem de banco de dados envolve 3 modelos: conceitual, lógico e físico.
Dentro do processo de modelagem existem uma série de etapas a serem executadas, desde o
entendimento do problema até a implementação do modelo físico no SGBDR.

M Ó D UL O 2

028
O Modelo Conceitual
A partir deste módulo vamos entender mais detalhadamente os modelos conceitual, lógico e físico.
Para ilustrar essa parte, pense no analista que precisa desenvolver estes modelos para descrever uma
realidade onde se quer entender a relação entre carros e pessoas.

029
O Modelo Conceitual
Uma vez que o analista observa o
mundo real, ele faz uma
representação do observado através
dos três modelos conceitual, lógico e
físico.

030
O Modelo Conceitual
físico.

031
O Modelo Conceitual
físico.
Relembrando, o modelo conceitual é
aquele onde vamos definir as
entidades e os relacionamentos, por
meio de diagramas.
PESSOA CARRO
dirige
n n
Modelo Conceitual

032
O Modelo Conceitual
físico.
meio de diagramas.
Já o modelo lógico é o momento em
que definiremos como serão as
tabelas.
PESSOA CARRO
dirige
n n
Modelo Conceitual
Modelo Lógico
P_CPF C_Placa
Dirige
Pessoa Carro

033
O Modelo Conceitual
físico.
meio de diagramas.
tabelas.
Por fim, o modelo físico é a etapa de
criação das tabelas dentro do
software de banco de dados.
Modelo Lógico
P_CPF C_Placa
Dirige
Pessoa Carro
Modelo Físico
CREATE TABLE Pessoa(...
CREATE TABLE Carro(...
CREATE TABLE Dirige(...
PESSOA CARRO
dirige
n n
Modelo Conceitual

034
O Modelo Conceitual
Neste módulo veremos mais a fundo o
Modelo Conceitual.
PESSOA CARRO
dirige
n n
Modelo Conceitual
Modelo Lógico
P_CPF C_Placa
Dirige
Pessoa Carro
Modelo Físico

035
O Modelo Conceitual
Um projeto de banco de dados começa pelo modelo conceitual. O modelo conceitual consiste em
descrever de forma resumida os requisitos de dados dos usuários, ou seja, a forma como os usuários
pretendem guardar os seus dados.
Para realizar essa descrição resumida, precisaremos aprender o Modelo Entidade Relacionamento
(MER).
O modelo ER será descrito através de um Diagrama Entidade Relacionamento que terá uma simbologia
própria.

036
MER e DER
O Modelo Entidade Relacionamento (MER) é um modelo conceitual a partir do qual o nosso banco de
dados pode ser modelado. Representamos esse modelo por um Diagrama Entidade Relacionamento
(DER). No diagrama ER, utilizamos símbolos gráficos para representar os requisitos dos usuários.
O diagrama ER é a forma pela qual um projetista de banco de dados descreve os requisitos levantados
para os clientes.
Por esse motivo, é importante aprender os conceitos do Modelo ER e aprender como modelar tais
conceitos utilizando os diagramas ER.
Os principais conceitos do modelo ER são: entidade, atributo e relacionamento.

037
Pessoa Carro
O que é uma Entidade?
Uma entidade é um elemento (uma coisa) da realidade que será observada e modelada. Geralmente,
uma entidade executa uma ação ou recebe uma ação.
Voltando no nosso exemplo clássico de “pessoas” e “carros”.

038
Pessoa Carro
Pessoas dirigem carros. Dentro da nossa realidade modelada, temos que pessoa é uma entidade e carro
também é uma entidade.

039
• Uma entidade será representada por meio de um retângulo.
• Dentro do retângulo, vamos informar o nome da entidade.
• Nos referimos a um objeto particular como “instância” ou “ocorrência” daquela entidade.
Pessoa
PESSOA
Ocorrências de
Pessoa
1) Ana
2) Bruno
3) Carla
4) Diego

040
Todos os dados ou informações que são associados a cada ocorrência de uma entidade ou relacionamento.
Ou seja, observamos a relação “pessoa” e “carro”. Neste exemplo, “pessoa” é a coisa, ou seja, a entidade. Já os atributos
de “pessoa” são nome, cpf, identidade, e assim vai.
Pessoa
PESSOA
CPF Nome Sexo
Dados a serem
armazenados
1) CPF
2) Nome
3) Sexo
O que é um Atributo?

041
Os atributos podem ser classificados como: simples, composto, multivalorado e chave.
• Atributo simples: Ocorre quando uma característica da entidade é representada por um único atributo. Por
exemplo, na entidade Empregado, temos os seguintes atributos simples: Matrícula, Nome, Sexo, Endereço e Salário.
• Atributo composto: É formado por vários itens menores, por isso o chamamos de atributo composto. Por exemplo, o
atributo Endereço é composto por informações como Rua, Número, Bairro e CEP.
• Atributo multivalorado: seu conteúdo é formado por mais de um valor. Por exemplo, Telefone. Um cliente poderá
ter mais de um número de telefone.
• Atributo chave: é a característica utilizada para identificar de forma única uma entidade.
O que é um Atributo?

042
Se trata de um conjunto de associações entre entidades, sobre as quais desejamos armazenar informações no banco de
dados.
No caso das entidades “carro” e “pessoa”, temos uma relação clara entre elas: “pessoa” dirige “carro”. Nesse exemplo,
“pessoa” é uma entidade, “carro” é outra entidade”, e o conjunto de relações dadas entre essas duas entidades seria
representado pelo “dirige”.
Pessoa Carro
Dirige
O que é um Relacionamento?

043
A representação da forma gráfica e visual da relação entre entidades é mostrada na imagem abaixo.
Este modelo nos diz que o banco de dados armazena informações sobre um conjunto de pessoas, um conjunto de
carros e um conjunto de associações que relacionam pessoas e carros.
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
n n

044
Vamos ver por meio de exemplos como se dá o relacionamento entre as entidades.
Pessoa
111 - Ana
222 - Bruno
333 - Carla
444 - Diego
Carro
A1 - Versa
B2 - Civic
C3 - Corolla
D4 - Ranger
r1
r2
r3
r4
Dirige

045
Entidade x Tabela x Relação
É comum encontrarmos dois ou mais termos representando o mesmo conceito. Por exemplo, quando falamos “colunas”,
“campos” ou “atributos” estamos falando da mesma coisa.
Já em outras situações, temos termos que representam mais ou menos o mesmo conceito, com algumas pequenas
diferenças entre si. Esse é o caso de Entidade x Tabela x Relação.
De que forma então estes três termos representam mais ou menos o mesmo conceito?
Entidade Relação
Uma entidade é uma representação
genérica de um conceito (um elemento) do
mundo real modelado.
A entidade será composta de atributos.
Exemplos de entidade: cliente, produto,
carro, pessoa e departamento.
Uma relação é um conjunto de registros. Cada
registro representa uma ocorrência (instância)
de entidade, e o conjunto de todas as
ocorrências, com seus atributos, é chamado de
relação.
Uma relação seria quase a mesma coisa que
uma tabela, com a diferença de que se
preocupa em não ter, por exemplo, atributos
multivalorados e compostos.
Tabela
Uma tabela é um conjunto de registros. Cada
registro representa uma ocorrência (instância) de
entidade, e o conjunto de todas as ocorrências,
com seus atributos, é chamado de relação.
Porém, em uma tabela, não estamos
preocupados com certos “problemas”, como
atributos multivalorados e compostos.

046
Relação
Uma relação é uma tabela bidimensional, composta por linhas e colunas, criada a partir de uma entidade.
Características de uma relação:
Linhas contêm dados sobre ocorrências (registros) de uma entidade
Colunas contêm dados sobre atributos (campos) de uma entidade
Cada célula da relação armazena um único valor
Todos os valores em uma coluna são do mesmo tipo (domínio)
Cada coluna possui um nome único
Não existem duas linhas iguais
As relações geralmente geram as tabelas do banco de dados
Toda relação é uma tabela, mas nem toda tabela é uma relação

047
Relação
Logo abaixo temos um exemplo de relação.
Cod_Funcionario Nome_Completo Data_Contratacao Cargo Salario
001 Ana Almeida 15/02/2015 AS 6500
002 Bruno Bastos 08/11/2018 GV 12000
003 Carol Castro 02/05/2020 AJ 3800
004 Diego Dantas 21/04/2021 AJ 2800
Colunas
Linhas
Chave
Primária
Chave
Estrangeira

048
Cardinalidade de Relacionamentos
Agora vamos entrar em um tema muito importante em bancos de dados: a cardinalidade. Para entender esse novo
conceito, vamos voltar no exemplo onde modelamos que pessoas dirigem carros.
Aqui temos uma relação clara entre as entidades “pessoa” e “carro”: pessoa dirige carro. Mas vamos pensar na forma
como essas duas entidades podem se relacionar, nos fazendo as seguintes perguntas:
• 1 pessoa pode dirigir mais de 1 carro?
• 1 pessoa só pode dirigir 1 carro?
• Pode ter 1 pessoa que não dirige nenhum carro?
• Pode ter 1 carro que não é dirigido por nenhuma pessoa?
São exatamente essas perguntas que vão nos introduzir ao conceito de cardinalidade.

049
Cardinalidade de Relacionamentos
Em modelagem de dados, a cardinalidade é um dos princípios fundamentais sobre o relacionamento de um banco de dados
relacional. Nela são definidos os graus de relação entre duas entidades ou tabelas.
No modelo relacional, podemos ter os seguintes níveis de relacionamento: 1:1 (um para um), 1:N (1 para muitos), N:N
(muitos para muitos).
Por exemplo, vamos pensar em um banco de dados que armazena informações sobre um hospital. Esse banco de dados
poderá ter várias tabelas, como:
• Tabela médico, onde serão armazenadas as informações de médicos.
• Tabela paciente, onde serão armazenadas as informações de pacientes.
• Tabela departamento, onde serão armazenadas as informações dos departamentos médicos.
• Tabela leito, onde serão armazenadas as informações dos leitos individuais onde cada paciente pode ficar.
Neste modelo, teremos o seguinte cenário:
• Relacionamento N:N - Um médico atende diversos pacientes, assim como um paciente é atendido por diversos médicos.
• Relacionamento 1:N - Um médico pertence a apenas um departamento, mas um departamento pode contar vários
médicos.
• Relacionamento 1:1 – Um paciente pode ficar em um leito, assim como cada leito individual só pode ter um paciente.

050
Tipos de Cardinalidade
Para entender os tipos de cardinalidade, vamos pensar que queremos modelar uma realidade composta por
empregados e departamentos de uma empresa.
Pensando no relacionamento entre departamento e empregado, podemos fazer as seguintes perguntas:
Pergunta: Um departamento possui quantos empregados?
Resposta: No mínimo 0 e no máximo N (muitos).
Pergunta: Um empregado está associado a quantos departamentos?
Resposta: No mínimo 1 e no máximo 1.
De acordo com as respostas acima, podemos modelar a relação empregado-departamento da seguinte forma:
Departamento Empregado
Possui
(1, 1) (0, n)

051
Você deve ter observado que as respostas às perguntas são dadas na forma de “no mínimo” e “no máximo”. Pelo fato de
usarmos esses termos, surgiu o conceito de Cardinalidade Mínima e Cardinalidade Máxima. As cardinalidades são
expressas pela forma:
(0, n)
Cardinalidade
Mínima
Cardinalidade
Máxima

052
Quando a cardinalidade mínima é zero, é comum a gente representar apenas a cardinalidade máxima.
(n)
Cardinalidade
Máxima

053
Cardinalidade Máxima
A cardinalidade máxima indica a quantidade máxima de ocorrências de entidades que podem estar associadas a uma
ocorrência de outra entidade (1 ou N).
Por exemplo, temos que a entidade empregado possui cardinalidade máxima 1 no seu relacionamento com uma
ocorrência da entidade departamento. Ou seja, um empregado só pode estar trabalhando no máximo em 1
departamento.
Por outro lado, a entidade departamento tem cardinalidade máxima N. Ou seja, um departamento pode ter no máximo
N (muitos) empregados trabalhando nele.
Possui
(1, 1) (0, n)
Indica que 1 empregado
pertence a no máximo 1
departamento
Indica que 1 departamento
possui no máximo N (muitos)
empregados

054
Cardinalidade Mínima
Já a cardinalidade mínima especifica quando a participação de todas as ocorrências das entidades no relacionamento é
obrigatória ou opcional. Em um projeto de banco de dados, é usado somente duas cardinalidades mínimas: 0 ou 1.
Por exemplo, temos que a entidade empregado possui cardinalidade mínima 1 no seu relacionamento com uma
ocorrência da entidade departamento. Ou seja, um empregado precisa estar trabalhando no mínimo em 1
departamento.
Por outro lado, a entidade departamento tem cardinalidade mínima 0. Ou seja, um departamento pode não ter nenhum
empregado trabalhando nele.
Possui
(1, 1) (0, n)
Indica que 1 empregado
pertence a no mínimo 1
departamento
Indica que 1 departamento
pode ter no mínimo 0
empregados (ou seja, nenhum)

055
Soma de Cardinalidades
A cardinalidade final de um relacionamento será X:X, sendo X a cardinalidade máxima de cada lado.
PESSOA CARRO
DIRIGE
(1, 1) (1, 1)
PESSOA CARRO
DIRIGE
(0, 1) (1, 1)
PESSOA CARRO
DIRIGE
(1, 1) (0, 1)
PESSOA CARRO
DIRIGE
(0, 1) (0, 1)
Cardinalidade 1:1
PESSOA CARRO
DIRIGE
(1, n) (1, n)
PESSOA CARRO
DIRIGE
(0, n) (1, n)
PESSOA CARRO
DIRIGE
(1, n) (0, n)
PESSOA CARRO
DIRIGE
(0, n) (0, n)
Cardinalidade 1:n
PESSOA CARRO
DIRIGE
(1, 1) (1, n)
PESSOA CARRO
DIRIGE
(0, 1) (1, n)
PESSOA CARRO
DIRIGE
(1, 1) (0, n)
PESSOA CARRO
DIRIGE
(0, 1) (0, n)
Cardinalidade n:n

056
Realidade Modelada
Para entender cada uma das cardinalidades (1:1, 1:N e N:N), vamos voltar ao nosso exemplo onde queremos modelar a
relação entre as entidades pessoa e carro. Lembrando que pessoa dirige carro.
Pessoa Carro
Dirige

057
Cardinalidade 1:1 – Situação 1
Na cardinalidade 1:1, estamos dizendo que 1
pessoa pode dirigir 1 carro, e 1 carro pode ser
dirigido por 1 pessoa.
Na Situação 1, do ponto de vista das
cardinalidades mínima e máxima, temos que 1
pessoa dirige no mínimo 1 carro e no máximo 1
carro
Pessoa
111 - Ana
222 - Bruno
333 - Carla
444 - Diego
Carro
A1 - Versa
B2 - Civic
C3 - Corolla
D4 - Ranger
r1
r2
r3
r4
Dirige
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(1, 1) (1, 1)
(1, 1) (1, 1)
CARRO
Placa Modelo Ano
(1, 1)
Enquanto que 1 carro é dirigido por no
mínimo 1 pessoa e no máximo 1 pessoa.
PESSOA
CPF Nome Sexo
(1, 1)

058
Pessoa
111 - Ana
222 - Bruno
333 - Carla
444 - Diego
Carro
A1 - Versa
B2 - Civic
C3 - Corolla
D4 - Ranger
r1
r2
r3
r4
Dirige
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(1, 1) (1, 1)
(1, 1) (1, 1)

059
pessoa dirige no mínimo 0 carros e no máximo
1 carro
Pessoa
111 - Ana
222 - Bruno
333 - Carla
444 - Diego
Carro
A1 - Versa
B2 - Civic
C3 - Corolla
r1
r2
r3
Dirige
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(1, 1) (0, 1)
(1, 1) (0, 1)
CARRO
Placa Modelo Ano
(0, 1)
PESSOA
CPF Nome Sexo
(1, 1)

060
Pessoa
111 - Ana
222 - Bruno
333 - Carla
444 - Diego
Carro
A1 - Versa
B2 - Civic
C3 - Corolla
r1
r2
r3
Dirige
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(1, 1) (0, 1)
(1, 1) (0, 1)

061
pessoa dirige no mínimo 1 carro e no máximo 1
carro
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(0, 1) (1, 1)
(0, 1) (1, 1)
CARRO
Placa Modelo Ano
(1, 1)
mínimo 0 pessoas e no máximo 1 pessoa.
PESSOA
CPF Nome Sexo
(0, 1)
Pessoa
111 - Ana
222 - Bruno
333 - Carla
Carro
A1 - Versa
B2 - Civic
C3 - Corolla
D4 - Ranger
r1
r2
r3
Dirige

062
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(0, 1) (1, 1)
(0, 1) (1, 1)
Pessoa
111 - Ana
222 - Bruno
333 - Carla
Carro
A1 - Versa
B2 - Civic
C3 - Corolla
D4 - Ranger
r1
r2
r3
Dirige

063
1 carro
Pessoa
111 - Ana
222 - Bruno
333 - Carla
444 - Diego
Carro
A1 - Versa
B2 - Civic
C3 - Corolla
D4 - Ranger
r1
r2
r3
Dirige
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(0, 1) (0, 1)
(0, 1) (0, 1)
CARRO
Placa Modelo Ano
(0, 1)
PESSOA
CPF Nome Sexo
(0, 1)

064
Pessoa
111 - Ana
222 - Bruno
333 - Carla
444 - Diego
Carro
A1 - Versa
B2 - Civic
C3 - Corolla
D4 - Ranger
r1
r2
r3
Dirige
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(0, 1) (0, 1)
(0, 1) (0, 1)

065
Cardinalidade 1:n – Situação 1
Na cardinalidade 1:n, estamos dizendo que 1
pessoa pode dirigir 1 ou mais carros, e 1 carro
pode ser dirigido por 1 ou mais pessoas.
pessoa dirige no mínimo 1 carro e no máximo
N carros
Pessoa
111 - Ana
222 - Bruno
333 - Carla
Carro
A1 - Versa
B2 - Civic
C3 - Corolla
D4 - Ranger
r1
r2
r3
r4
Dirige
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(1, 1) (1, n)
(1, 1) (1, n)
CARRO
Placa Modelo Ano
(1, n)
PESSOA
CPF Nome Sexo
(1, 1)

066
Pessoa
111 - Ana
222 - Bruno
333 - Carla
Carro
A1 - Versa
B2 - Civic
C3 - Corolla
D4 - Ranger
r1
r2
r3
r4
Dirige
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(1, 1) (1, n)
(1, 1) (1, n)

067
N carros
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(1, 1) (0, n)
(1, 1) (0, n)
CARRO
Placa Modelo Ano
(0, n)
PESSOA
CPF Nome Sexo
(1, 1)
Pessoa
111 - Ana
222 - Bruno
333 - Carla
444 - Diego
Carro
A1 - Versa
B2 - Civic
C3 - Corolla
D4 - Ranger
r1
r2
r3
r4
Dirige

068
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(1, 1) (0, n)
(1, 1) (0, n)
Pessoa
111 - Ana
222 - Bruno
333 - Carla
444 - Diego
Carro
A1 - Versa
B2 - Civic
C3 - Corolla
D4 - Ranger
r1
r2
r3
r4
Dirige

069
N carros
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(0, 1) (1, n)
(0, 1) (1, n)
CARRO
Placa Modelo Ano
(1, n)
PESSOA
CPF Nome Sexo
(0, 1)
Pessoa
111 - Ana
222 - Bruno
Carro
A1 - Versa
B2 - Civic
C3 - Corolla
D4 - Ranger
r1
r2
r3
Dirige

070
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(0, 1) (1, n)
(0, 1) (1, n)
Pessoa
111 - Ana
222 - Bruno
Carro
A1 - Versa
B2 - Civic
C3 - Corolla
D4 - Ranger
r1
r2
r3
Dirige

071
N carros
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(0, 1) (0, n)
(0, 1) (0, n)
CARRO
Placa Modelo Ano
(0, n)
PESSOA
CPF Nome Sexo
(0, 1)
Pessoa
111 - Ana
222 - Bruno
333 - Carla
444 - Diego
Carro
A1 - Versa
B2 - Civic
C3 - Corolla
D4 - Ranger
r1
r2
r3
Dirige

072
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(0, 1) (0, n)
(0, 1) (0, n)
Pessoa
111 - Ana
222 - Bruno
333 - Carla
444 - Diego
Carro
A1 - Versa
B2 - Civic
C3 - Corolla
D4 - Ranger
r1
r2
r3
Dirige

073
Cardinalidade n:n – Situação 1
Na cardinalidade n:n, estamos dizendo que 1
pessoa pode dirigir 1 ou N carros, e 1 carro
pode ser dirigido por 1 ou N pessoas.
N carros
Pessoa
111 - Ana
222 - Bruno
333 - Carla
Carro
A1 - Versa
B2 - Civic
C3 - Corolla
D4 - Ranger
r1
r2
r3
r4
Dirige
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(1, n) (1, n)
(1, n) (1, n)
CARRO
Placa Modelo Ano
(1, n)
mínimo 1 pessoa e no máximo N pessoas.
PESSOA
CPF Nome Sexo
(1, n)
r5

074
Pessoa
111 - Ana
222 - Bruno
333 - Carla
Carro
A1 - Versa
B2 - Civic
C3 - Corolla
D4 - Ranger
r1
r2
r3
r4
Dirige
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(1, n) (1, n)
(1, n) (1, n)
r5

075
N carros
Pessoa
111 - Ana
222 - Bruno
333 - Carla
Carro
A1 - Versa
B2 - Civic
C3 - Corolla
D4 - Ranger
r1
r2
r3
r4
Dirige
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(1, n) (0, n)
(1, n) (0, n)
CARRO
Placa Modelo Ano
(0, n)
mínimo 1 pessoa e no máximo N pessoas.
PESSOA
CPF Nome Sexo
(1, n)
r5
444 - Diego

076
Pessoa
111 - Ana
222 - Bruno
333 - Carla
Carro
A1 - Versa
B2 - Civic
C3 - Corolla
D4 - Ranger
r1
r2
r3
r4
Dirige
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(1, n) (0, n)
(1, n) (0, n)
r5
444 - Diego

077
N carros
Pessoa
111 - Ana
222 - Bruno
333 - Carla
Carro
A1 - Versa
B2 - Civic
C3 - Corolla
D4 - Ranger
r1
r2
r3
r4
Dirige
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(0, n) (1, n)
(0, n) (1, n)
CARRO
Placa Modelo Ano
(1, n)
mínimo 0 pessoas e no máximo N pessoas.
PESSOA
CPF Nome Sexo
(0, n)

078
Pessoa
111 - Ana
222 - Bruno
333 - Carla
Carro
A1 - Versa
B2 - Civic
C3 - Corolla
D4 - Ranger
r1
r2
r3
r4
Dirige
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(0, n) (1, n)
(0, n) (1, n)

079
N carros
Pessoa
111 - Ana
222 - Bruno
333 - Carla
Carro
A1 - Versa
B2 - Civic
C3 - Corolla
D4 - Ranger
r1
r2
r3
r4
Dirige
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(0, n) (0, n)
(0, n) (0, n)
CARRO
Placa Modelo Ano
(0, n)
mínimo 0 pessoas e no máximo N pessoas.
PESSOA
CPF Nome Sexo
(0, n)
444 - Diego

080
Pessoa
111 - Ana
222 - Bruno
333 - Carla
Carro
A1 - Versa
B2 - Civic
C3 - Corolla
D4 - Ranger
r1
r2
r3
r4
Dirige
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(0, n) (0, n)
(0, n) (0, n)
444 - Diego

081
Modelo Conceitual – Engenharia da Informação
Existem inúmeros modelos para representação do modelo conceitual.
Até então, vimos o modelo proposto por Peter Chen.
A seguir, aprenderemos uma notação de Engenharia da Informação, proposta por James Martin,
também conhecida como “Pé de galinha”.

082
Cardinalidades – Engenharia da Informação
Na notação da Engenharia da Informação, as cardinalidades são representadas das seguintes formas:
(1, n) (0, n) (0, 1) (1, 1)

083
Representação Gráfica
Representamos graficamente essa notação da seguinte forma:
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(1, 1) (0, n)
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano

084
Resumo do Módulo
O modelo conceitual é o momento onde vamos entender a realidade modelada e definir as
entidades, atributos (simples, compostos, multivalorados e chave) e relacionamentos.
Dentro do modelo conceitual trabalhamos com o MER (Modelo Entidade Relacionamento) e o
DER (Diagrama Entidade Relacionamento), que será uma representação gráfica do MER.
Para criar as relações entre as entidades, precisamos definir as cardinalidades, a forma como os
relacionamentos ocorrerão (1 para 1, 1 para muitos, muitos para muitos). Uma cardinalidade pode
ser mínima ou máxima.
Existe uma notação para o DER chamada “Pé de Galinha”. Essa representação é comumente
encontrada em softwares de modelagem.
Entidades, Tabelas e Relações possuem significados muito parecidos, mas não são a mesma coisa.

M Ó D UL O 3

086
Introdução
físico.
meio de diagramas.
tabelas.
Por fim, o modelo físico é a etapa de
criação das tabelas dentro do
software de banco de dados.
PESSOA CARRO
dirige
n n
Modelo Conceitual
Modelo Lógico
P_CPF C_Placa
Dirige
Pessoa Carro
Modelo Físico

087
Introdução
PESSOA CARRO
dirige
n n
Modelo Conceitual
Modelo Lógico
P_CPF C_Placa
Dirige
Pessoa Carro
Modelo Físico
Agora veremos mais a fundo o
Modelo Lógico.
Uma vez que estaremos trabalhando
com bancos de dados relacionais, o
nosso modelo lógico será o modelo
relacional.

088
Modelo Lógico Relacional
O Modelo Relacional foi apresentado por Edgar Frank Codd, em
1970. Este modelo representa os dados em um banco de dados
como uma coleção de relações (tabelas).
Cada linha de uma tabela é denominada registro (ou tupla).
Cada coluna de uma tabela é denominada atributo (ou campo).
Por fim, uma tabela é chamada de relação.

089
Modelo Lógico Relacional
Um modelo relacional é composto pelos seguintes elementos:
Tabelas Chaves
Candidatas
Primárias
Alternadas ou Alternativas
Estrangeiras
Colunas: Atributos (Campos)
Linhas: Registros (Tuplas)

090
Tabelas
CPF Nome Sexo Placa
222 Ana F A1
333 Bruno M C3
111 Carla F D4
444 Diego M B2
PESSOA
Nome da
Tabela
Atributos
(Colunas)
Registros
(Linhas)
Chave
Estrangeira
Chave
Primária
Uma tabela é um conjunto registros (tuplas) exclusivos e não necessariamente ordenados. A tabela será composta de
Linhas, Colunas e Chaves. Diferentes tabelas serão relacionadas por meio de Chaves Estrangeiras.
Placa Modelo Ano
A1 Versa 2016
B2 Civic 2020
CARRO

091
Chaves
No Modelo Relacional, são consideradas as chaves:
- Candidatas
- Primárias
- Alternativas ou Alternadas
- Estrangeiras
CPF CNH Nome Sexo
111 AAA Ana F
222 BBB Bruno M
333 CCC Carla F
444 DDD Diego M
PESSOA

092
Chaves Candidatas
Todas as colunas que podem identificar de forma única as linhas de uma tabela serão chamadas de Chaves Candidatas.
No exemplo abaixo, temos uma tabela PESSOA com as informações de CPF, CNH, Nome e Sexo.
Dentre essas colunas, duas delas poderiam identificar de forma única a tabela: CPF e CNH.
CPF CNH Nome Sexo
111 AAA Ana F
222 BBB Bruno M
333 CCC Carla F
444 DDD Diego M
PESSOA

093
Chave Primária
Dentre as nossas chaves candidatas, apenas uma poderá ser a Chave Primária.
Uma Chave Primária é uma coluna (ou combinação de colunas) cujos valores distinguem uma linha das demais linhas
dentro de uma tabela.
Os valores de uma Chave Primária devem ser únicos, não nulos (not null) e irredutíveis.
PESSOA
Chave
Primária
Corredor Prateleira Produto
A 1 Arroz
A 2 Feijão
B 1 Café
B 2 Papel Toalha
B 1 Sabonete
C 1 Shampoo
C 2 Biscoito
PRATELEIRA
Chave Primária
Composta
CPF CNH Nome Sexo
111 AAA Ana F
222 BBB Bruno M
333 CCC Carla F
444 DDD Diego M

094
Chaves Alternadas
As chaves candidatas que não foram eleitas primárias, serão reconhecidas como Chaves Alternadas (ou Alternativas).
No exemplo da tabela abaixo, a coluna CNH será nossa chave alternada.
CPF CNH Nome Sexo
111 AAA Ana F
222 BBB Bruno M
333 CCC Carla F
444 DDD Diego M
PESSOA
Chave
Alternada

095
Chave Estrangeira
Uma Chave Estrangeira se trata de uma coluna (ou combinação de colunas), cujos valores aparecem na chave primária
da tabela que está sendo referenciada. Por meio da Chave Estrangeira é possível criar relacionamentos em um banco
de dados relacional.
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(0, 1) (0, 1)
CONCEITUAL
LÓGICO
CPF Nome Sexo Placa
111 Ana F A1
222 Bruno M C3
333 Carla F D4
444 Diego M NULL
PESSOA
Placa Modelo Ano
A1 Versa 2010
B2 Civic 2015
C3 Corolla 2014
D4 Ranger 2011
CARRO

096
Restrições de Integridade
Quando criamos tabelas em bancos de dados, essas tabelas aceitam qualquer valor. Como assim “aceitam qualquer
valor”?
Se a gente quiser adicionar um produto com preço negativo, nada nos impede. Somos livres para adicionar na tabela os
dados que a gente quiser.
É claro que adicionar um produto com preço negativo não faz nenhum sentido, então na prática, é sempre importante
a gente garantir que os dados adicionados dentro de um banco de dados são realmente válidos. Ou seja, garantir que
os dados façam sentido.
Por exemplo, em uma tabela de clientes, não podemos ter valores repetidos na coluna de CPF. Da mesma forma que
uma coluna que armazena a informação de placa de um carro não deveria aceitar um valor nulo, caso contrário, como
poderíamos identificar um carro sem placa?
Para garantir que os dados dentro do banco de dados terão algum nível de consistência, precisaremos criar restrições
de integridade.

097
Fatores que afetam a integridade de um banco
Vários fatores podem afetar a integridade dos dados armazenados em um banco de dados:
• Erros Humanos
A entrada manual de dados aumenta as chances de erros, duplicações ou exclusão. Além disso, muitas vezes os
dados inseridos não seguem um padrão, acarretando em erros ao longo do processo de armazenamento até análise
dos dados.
• Erros de Transferência
Um erro de transferência ocorre se os dados não forem transferidos com êxito de um site dentro de um banco de
dados para outro. Esses erros geralmente ocorrem quando um item de dados existe na tabela de destino, mas está
ausente da tabela de origem em um banco de dados relacional.
• Bugs e Vírus
A integridade dos dados também pode ser comprometida devido a bugs e vírus.

098
Restrições de Integridade
Restrições de integridade são regras de consistência dos dados, é o que vai garantir a validade dos dados presentes
dentro do banco de dados.
Temos diferentes tipos de restrições de integridade, são elas:
Integridade de Domínio
Integridade de Vazio
Integridade de Chave
Integridade Referencial
Integridade de Entidade
Integridade Definida pelo Usuário

099
Integridade de Domínio
Esta restrição de integridade diz que os valores inseridos em uma coluna devem sempre obedecer à definição dos
valores permitidos para essa coluna, ou seja, os valores do domínio.
Esse domínio pode ser o domínio de números inteiros, decimais, caracteres, datas, números inteiros positivos, e assim
vai.
Por exemplo, em uma coluna que armazena os preços de produtos, os valores aceitos devem ser do domínio numérico,
ou seja, apenas números. Mais especificamente números positivos. Não podemos inserir preços negativos, ou usando
letras ou caracteres especiais.

100
Integridade de Vazio
Este tipo de restrição informa se a coluna é obrigatória ou opcional, ou seja, se é possível simplesmente não inserir um
valor em uma coluna.
Uma coluna de chave primária, por exemplo, sempre deve conter dados não nulos. Portanto, nunca pode conterá
valores nulos.
Um valor nulo (NULL) significa que não existem dados disponíveis para o campo em particular. É diferente de zero,
espaço, string vazia ou tabulação, que consistem em algo armazenado.

101
Integridade de Chave
Essa integridade diz que os valores inseridos na coluna de chave primária devem ser sempre únicos, não aceitando-se
portanto repetições nesses valores.
Desta forma, as linhas (registros ou tuplas) serão sempre distintas.
Os valores da chave primária também não podem ser nulos.

102
Integridade Referencial
Uma restrição de integridade referencial diz que os valores de uma coluna em uma tabela são válidos baseados nos
valores em uma outra tabela relacionada.
Por exemplo, se um cliente de ID igual a 987 foi cadastrado em uma tabela de vendas (ou seja, existe uma venda
associada a ele), então este mesmo cliente também deve estar cadastrado na tabela de Clientes relacionada.
Em resumo, cada valor de uma chave estrangeira deve corresponder a um valor de uma chave primária existente. Com
isso, garantimos a consistência dos relacionamentos entre tabelas.

103
Integridade de Entidade
Essa restrição afirma que nenhum valor de chave primária pode ser NULL (nulo), pois o seu valor é utilizado para
identificar tuplas individuais em uma relação (tabela).
Isso significa que caso exista um valor NULL para uma chave primária, não será possível identificar uma tupla e por
consequência não poderíamos utilizar essas tuplas para referenciá-las em outras relações (tabelas), pois não
conseguiríamos distinguí-las.

104
Integridade Definida pelo Usuário
Se refere a regras de negócio específicas definidas pelo usuário do banco de dados. Por exemplo, podemos definir uma
regra que uma coluna somente aceita um conjunto de valores restritos.
Por exemplo, se você tiver uma coluna para cadastrar as siglas de estados do Brasil, essas siglas fazem parte de um
conjunto pré-definido de valores. Você não poderia cadastrar em uma coluna de siglas de estados o valor BRASIL, por
exemplo, pois ele não faz parte das opções que poderiam ser aceitas naquela coluna.

106
Cardinalidade 1:1 (Situação 1)
Vejamos agora como cada Cardinalidade é representada em seu modelo lógico relacional.
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(0, 1) (0, 1)
CONCEITUAL
LÓGICO

107
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(0, 1) (0, 1)
CONCEITUAL
LÓGICO
CPF Nome Sexo
111 Ana F
222 Bruno M
333 Carla F
444 Diego M
PESSOA

108
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(0, 1) (0, 1)
CONCEITUAL
LÓGICO
CPF Nome Sexo
111 Ana F
222 Bruno M
333 Carla F
444 Diego M
PESSOA
Placa Modelo Ano
A1 Versa 2010
B2 Civic 2015
C3 Corolla 2014
D4 Ranger 2011
CARRO

109
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(0, 1) (0, 1)
CONCEITUAL
LÓGICO
CPF Nome Sexo Placa
111 Ana F A1
222 Bruno M C3
333 Carla F D4
444 Diego M NULL
PESSOA
Placa Modelo Ano
A1 Versa 2010
B2 Civic 2015
C3 Corolla 2014
D4 Ranger 2011
CARRO

110
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(0, 1) (0, 1)
CONCEITUAL
LÓGICO
CPF Nome Sexo
111 Ana F
222 Bruno M
333 Carla F
444 Diego M
PESSOA
Placa Modelo Ano CPF
A1 Versa 2010 111
B2 Civic 2015 NULL
C3 Corolla 2014 222
D4 Ranger 2011 333
CARRO

111
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(1, 1) (0, 1)
CONCEITUAL
LÓGICO

112
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(1, 1) (0, 1)
CONCEITUAL
LÓGICO
CPF Nome Sexo
111 Ana F
222 Bruno M
333 Carla F
444 Diego M
PESSOA

113
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(1, 1) (0, 1)
CONCEITUAL
LÓGICO
CPF Nome Sexo
111 Ana F
222 Bruno M
333 Carla F
444 Diego M
PESSOA
Placa Modelo Ano
A1 Versa 2010
C3 Corolla 2014
D4 Ranger 2011
CARRO

114
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(1, 1) (0, 1)
CONCEITUAL
LÓGICO
CPF Nome Sexo
111 Ana F
222 Bruno M
333 Carla F
444 Diego M
PESSOA
A1 Versa 2010 111
C3 Corolla 2014 222
D4 Ranger 2011 333
CARRO

115
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(1, 1) (0, 1)
CONCEITUAL
LÓGICO
111 Ana F A1 Versa 2010
222 Bruno M C3 Corolla 2014
333 Carla F D4 Ranger 2011
444 Diego M NULL NULL NULL
PESSOA_CARRO

116
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(0, 1) (1, 1)
CONCEITUAL
LÓGICO
CPF Nome Sexo
111 Ana F
222 Bruno M
333 Carla F
PESSOA

117
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(0, 1) (1, 1)
CONCEITUAL
LÓGICO
CPF Nome Sexo
111 Ana F
222 Bruno M
333 Carla F
PESSOA
Placa Modelo Ano
A1 Versa 2010
B2 Civic 2015
C3 Corolla 2014
D4 Ranger 2011
CARRO

118
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(0, 1) (1, 1)
CONCEITUAL
LÓGICO
CPF Nome Sexo Placa
111 Ana F A1
222 Bruno M C3
333 Carla F D4
PESSOA
Placa Modelo Ano
A1 Versa 2010
B2 Civic 2015
C3 Corolla 2014
D4 Ranger 2011
CARRO

119
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(0, 1) (1, 1)
CONCEITUAL
LÓGICO

120
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(0, 1) (1, 1)
CONCEITUAL
LÓGICO
NULL NULL NULL B2 Civic 2015
CARRO_PESSOA

121
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(1, 1) (1, 1)
CONCEITUAL
LÓGICO

122
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(1, 1) (1, 1)
CONCEITUAL
LÓGICO
444 Diego M B2 Civic 2015
CARRO_PESSOA

124
Cardinalidade 1:n (Situação 1)
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(0, 1) (0, n)
CONCEITUAL
LÓGICO

125
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(0, 1) (0, n)
CONCEITUAL
LÓGICO
CPF Nome Sexo
111 Ana F
222 Bruno M
333 Carla F
444 Diego M
PESSOA
Placa Modelo Ano
A1 Versa 2010
B2 Civic 2015
C3 Corolla 2014
D4 Ranger 2011
CARRO

126
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(0, 1) (0, n)
CONCEITUAL
LÓGICO
CPF Nome Sexo Placa
111 Ana F A1, B2
222 Bruno M NULL
333 Carla F C3
444 Diego M NULL
PESSOA
Placa Modelo Ano
A1 Versa 2010
B2 Civic 2015
C3 Corolla 2014
D4 Ranger 2011
CARRO

127
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(0, 1) (0, n)
CONCEITUAL
LÓGICO
CPF Nome Sexo Placa
111 Ana F A1, B2
222 Bruno M NULL
333 Carla F C3
444 Diego M NULL
PESSOA
Placa Modelo Ano
A1 Versa 2010
B2 Civic 2015
C3 Corolla 2014
D4 Ranger 2011
CARRO

128
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(0, 1) (0, n)
CONCEITUAL
LÓGICO
CPF Nome Sexo
111 Ana F
222 Bruno M
333 Carla F
444 Diego M
PESSOA
A1 Versa 2010 111
B2 Civic 2015 111
C3 Corolla 2014 333
D4 Ranger 2011 NULL
CARRO

129
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(1, 1) (0, n)
CONCEITUAL
LÓGICO

130
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(1, 1) (0, n)
CONCEITUAL
LÓGICO
CPF Nome Sexo
111 Ana F
222 Bruno M
333 Carla F
444 Diego M
PESSOA
A1 Versa 2010 111
B2 Civic 2015 111
C3 Corolla 2014 333
D4 Ranger 2011 NULL
CARRO

131
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(1, 1) (0, n)
CONCEITUAL
LÓGICO
CPF Nome Sexo
111 Ana F
222 Bruno M
333 Carla F
444 Diego M
PESSOA
A1 Versa 2010 111
B2 Civic 2015 111
C3 Corolla 2014 333
D4 Ranger 2011 NULL
CARRO

132
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(1, 1) (0, n)
CONCEITUAL
LÓGICO
CPF Nome Sexo
111 Ana F
222 Bruno M
333 Carla F
444 Diego M
PESSOA
A1 Versa 2010 111
B2 Civic 2015 111
C3 Corolla 2014 333
D4 Ranger 2011 222
CARRO

133
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(1, 1) (0, n)
CONCEITUAL
LÓGICO
Data

134
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(1, 1) (0, n)
CONCEITUAL
LÓGICO
CPF Nome Sexo
111 Ana F
222 Bruno M
333 Carla F
444 Diego M
PESSOA
A1 Versa 2010 111
B2 Civic 2015 111
C3 Corolla 2014 333
D4 Ranger 2011 222
CARRO
Data

135
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(1, 1) (0, n)
CONCEITUAL
LÓGICO
CPF Nome Sexo
111 Ana F
222 Bruno M
333 Carla F
444 Diego M
PESSOA
Placa Modelo Ano CPF Data
A1 Versa 2010 111 01-01-2022
B2 Civic 2015 111 02-01-2022
C3 Corolla 2014 333 02-01-2022
D4 Ranger 2011 222 03-01-2022
CARRO
Data

136
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(1, 1) (1, n)
CONCEITUAL
LÓGICO

137
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(1, 1) (1, n)
CONCEITUAL
LÓGICO
CPF Nome Sexo
111 Ana F
222 Bruno M
333 Carla F
444 Diego M
PESSOA
A1 Versa 2010 111
B2 Civic 2015 111
C3 Corolla 2014 333
D4 Ranger 2011 222
CARRO

138
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(1, 1) (1, n)
CONCEITUAL
LÓGICO
CPF Nome Sexo
111 Ana F
222 Bruno M
333 Carla F
444 Diego M
PESSOA
A1 Versa 2010 111
B2 Civic 2015 111
C3 Corolla 2014 333
D4 Ranger 2011 222
CARRO

139
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(1, 1) (1, n)
CONCEITUAL
LÓGICO
CPF Nome Sexo
111 Ana F
222 Bruno M
333 Carla F
444 Diego M
PESSOA
A1 Versa 2010 111
B2 Civic 2015 111
C3 Corolla 2014 333
D4 Ranger 2011 222
CARRO

141
Cardinalidade n:n (Situação 1)
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(0, n) (0, n)
LÓGICO
CONCEITUAL

142
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(0, n) (0, n)
LÓGICO
CPF Nome Sexo
111 Ana F
222 Bruno M
333 Carla F
444 Diego M
PESSOA
Placa Modelo Ano
A1 Versa 2010
B2 Civic 2015
C3 Corolla 2014
D4 Ranger 2011
CARRO
CONCEITUAL

143
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(0, n) (0, n)
LÓGICO
CPF Nome Sexo Placa
111 Ana F A1, B2
222 Bruno M B2
333 Carla F C3
444 Diego M NULL
PESSOA
Placa Modelo Ano
A1 Versa 2010
B2 Civic 2015
C3 Corolla 2014
D4 Ranger 2011
CARRO
CONCEITUAL

144
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(0, n) (0, n)
LÓGICO
CPF Nome Sexo Placa
111 Ana F A1, B2
222 Bruno M B2
333 Carla F C3
444 Diego M NULL
PESSOA
Placa Modelo Ano
A1 Versa 2010
B2 Civic 2015
C3 Corolla 2014
D4 Ranger 2011
CARRO
CONCEITUAL

145
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(0, n) (0, n)
LÓGICO
PESSOA
Placa Modelo Ano
A1 Versa 2010
B2 Civic 2015
C3 Corolla 2014
D4 Ranger 2011
CARRO
CPF Nome Sexo Placa
111 Ana F A1
111 Ana F B2
222 Bruno M B2
333 Carla F C3
444 Diego M NULL
CONCEITUAL

146
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(0, n) (0, n)
LÓGICO
PESSOA
Placa Modelo Ano
A1 Versa 2010
B2 Civic 2015
C3 Corolla 2014
D4 Ranger 2011
CARRO
CPF Nome Sexo Placa
111 Ana F A1
111 Ana F B2
222 Bruno M B2
333 Carla F C3
444 Diego M NULL
CONCEITUAL

147
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(0, n) (0, n)
LÓGICO
CPF Nome Sexo
111 Ana F
222 Bruno M
333 Carla F
444 Diego M
PESSOA
Placa Modelo Ano
A1 Versa 2010
B2 Civic 2015
C3 Corolla 2014
D4 Ranger 2011
CARRO
CONCEITUAL

148
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(0, n) (0, n)
LÓGICO
CPF Nome Sexo
111 Ana F
222 Bruno M
333 Carla F
444 Diego M
PESSOA
A1 Versa 2010 111
B2 Civic 2015 111, 222
C3 Corolla 2014 333
D4 Ranger 2011 NULL
CARRO
CONCEITUAL

149
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(0, n) (0, n)
LÓGICO
CPF Nome Sexo
111 Ana F
222 Bruno M
333 Carla F
444 Diego M
PESSOA
A1 Versa 2010 111
B2 Civic 2015 111, 222
C3 Corolla 2014 333
D4 Ranger 2011 NULL
CARRO
CONCEITUAL

150
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(0, n) (0, n)
LÓGICO
CPF Nome Sexo
111 Ana F
222 Bruno M
333 Carla F
444 Diego M
PESSOA
A1 Versa 2010 111
B2 Civic 2015 111
C3 Corolla 2014 333
D4 Ranger 2011 NULL
B2 Civic 2015 222
CARRO
CONCEITUAL

151
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(0, n) (0, n)
LÓGICO
CPF Nome Sexo
111 Ana F
222 Bruno M
333 Carla F
444 Diego M
PESSOA
A1 Versa 2010 111
B2 Civic 2015 111
C3 Corolla 2014 333
D4 Ranger 2011 NULL
B2 Civic 2015 222
CARRO
CONCEITUAL

152
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(0, n) (0, n)
LÓGICO
CPF Nome Sexo
111 Ana F
222 Bruno M
333 Carla F
444 Diego M
PESSOA
Placa Modelo Ano
A1 Versa 2010
B2 Civic 2015
C3 Corolla 2014
D4 Ranger 2011
CARRO
CONCEITUAL

153
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(0, n) (0, n)
LÓGICO
CPF Nome Sexo
111 Ana F
222 Bruno M
333 Carla F
444 Diego M
PESSOA
Placa Modelo Ano
A1 Versa 2010
B2 Civic 2015
C3 Corolla 2014
D4 Ranger 2011
CARRO
P_CPF C_Placa
111 A1
111 B2
222 B2
333 C3
DIRIGE
CONCEITUAL

154
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(1, 1) (1, 1)
LÓGICO
CPF Nome Sexo
111 Ana F
222 Bruno M
333 Carla F
444 Diego M
PESSOA
Placa Modelo Ano
A1 Versa 2010
B2 Civic 2015
C3 Corolla 2014
D4 Ranger 2011
CARRO
P_CPF C_Placa
111 A1
111 B2
222 B2
333 C3
DIRIGE
(0, n) (0, n)
P_CPF C_Placa
CONCEITUAL

155
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(0, n) (0, n)
LÓGICO
CPF Nome Sexo
111 Ana F
222 Bruno M
333 Carla F
444 Diego M
PESSOA
Placa Modelo Ano
A1 Versa 2010
B2 Civic 2015
C3 Corolla 2014
D4 Ranger 2011
CARRO
Data
CONCEITUAL

156
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(0, n) (0, n)
LÓGICO
CPF Nome Sexo
111 Ana F
222 Bruno M
333 Carla F
444 Diego M
PESSOA
Placa Modelo Ano
A1 Versa 2010
B2 Civic 2015
C3 Corolla 2014
D4 Ranger 2011
CARRO
Data
P_CPF C_Placa Data
111 A1 01/01/22
111 B2 03/02/22
222 B2 10/04/22
333 C3 05/05/22
DIRIGE
CONCEITUAL

157
LÓGICO
CPF Nome Sexo
111 Ana F
222 Bruno M
333 Carla F
444 Diego M
PESSOA
Placa Modelo Ano
A1 Versa 2010
B2 Civic 2015
C3 Corolla 2014
D4 Ranger 2011
CARRO
P_CPF C_Placa Data
111 A1 01/01/22
111 B2 03/02/22
222 B2 10/04/22
333 C3 05/05/22
DIRIGE
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(1, 1) (1, 1)
CONCEITUAL
(0, n) (0, n)
P_CPF C_Placa
Data

158
Entidade Associativa e Relacionamento Ternário
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(0, n) (0, n)
LÓGICO
CPF Nome Sexo
111 Ana F
222 Bruno M
333 Carla F
444 Diego M
PESSOA
Placa Modelo Ano
A1 Versa 2010
B2 Civic 2015
C3 Corolla 2014
D4 Ranger 2011
CARRO
Data
P_CPF C_Placa Data
111 A1 01/01/22
111 B2 03/02/22
222 B2 10/04/22
333 C3 05/05/22
DIRIGE
CONCEITUAL
Na aula anterior, analisamos um relacionamento N:N entre duas entidades, e vimos que para modelar esse tipo de
relacionamento é necessário criar uma terceira tabela.

159
LÓGICO
CPF Nome Sexo
111 Ana F
222 Bruno M
333 Carla F
444 Diego M
PESSOA
Placa Modelo Ano
A1 Versa 2010
B2 Civic 2015
C3 Corolla 2014
D4 Ranger 2011
CARRO
P_CPF C_Placa Data
111 A1 01/01/22
111 B2 03/02/22
222 B2 10/04/22
333 C3 05/05/22
DIRIGE
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(1, 1) (1, 1)
CONCEITUAL
(0, n) (0, n)
P_CPF C_Placa
Data
Além disso, vimos que o relacionamento “dirige” acaba tendo o comportamento de uma entidade, podendo ter
portanto atributos.

160
Vejamos agora como criar relacionamentos entre mais de 2 tabelas.
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(0, n) (0, n)
Data
CONCEITUAL

161
Imagine que agora uma determinada pessoa dirige em uma data, um carro pertencente a uma concessionária (CNPJ).
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(0, n) (0, n)
Data
CONCEITUAL
CNPJ

162
De alguma forma precisaremos relacionar a tabela concessionária com as demais tabelas.
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(0, n) (0, n)
Data
CONCEITUAL
CNPJ
CONCESSIONÁRIA
CNPJ Nome Endereço
(0, n)

163
Para que isso seja possível, criamos uma Entidade Associativa.
CONCEITUAL
CONCESSIONÁRIA
CNPJ Nome Endereço
(0, n)
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(1, 1) (1, 1)
(0, n) (0, n)
P_CPF
C_Placa
Data
CNPJ
(1, 1)

164
Para que isso seja possível, criamos uma Entidade Associativa.
CONCEITUAL
CONCESSIONÁRIA
CNPJ Nome Endereço
(0, n)
PESSOA
CPF Nome Sexo
CARRO
Placa Modelo Ano
DIRIGE
(1, 1) (1, 1)
(0, n) (0, n)
P_CPF
C_Placa
Data
CNPJ
(1, 1)
Uma Entidade Associativa é um
relacionamento que possui propriedades
de entidade e assim se torna uma
entidade no nosso modelo.
Através da Entidade Associativa seremos
capazes de relacionar um relacionamento
a uma outra entidade.

165
CONCEITUAL LÓGICO
CPF Nome Sexo
111 Ana F
222 Bruno M
333 Carla F
444 Diego M
PESSOA
Placa Modelo Ano
A1 Versa 2010
B2 Civic 2015
C3 Corolla 2014
D4 Ranger 2011
CARRO
P_CPF C_Placa C_CNPJ Data
111 A1 0001 Janeiro
111 B2 0002 Janeiro
222 B2 0002 Fevereiro
333 C3 0001 Março
DIRIGE
CNPJ Nome Endereço
0001 Dirija RJ
0002 Localiza SP
CONCESSIONÁRIA

166
Dicionário de Dados
Um dicionário de dados é um documento usado para armazenar informações sobre o conteúdo, formato e estrutura de
um banco de dados, assim como o relacionamento entre os seus elementos.
Em resumo, se trata de um documento que explica e detalha todas as entidades, atributos e relacionamentos.
É importante criar um dicionário de dados para minimizar erros ao criar a estrutura física o banco de dados e também
permitir documentar a lógica por trás do projeto de banco de dados.

167
Exemplo Dicionário de Dados
Começamos listando todas as tabelas do banco de dados, com as suas respectivas descrições e identificação das
tabelas relacionadas.
Tabela Relacionamento Nome do Relacionamento Descrição
Funcionario Departamento Pertence Tabela para cadastro dos
funcionários de uma empresa
Localidade Reside
Departamento Funcionario Pertence Tabela para cadastro dos
departamentos de uma
empresa
Localidade Funcionario Reside Tabela para cadastro das
localidades de residência
Descrição das Tabelas (Relações)

168
Tabela Nome da Coluna Tipo de Dados Restrições Descrição
Funcionario Cod_Funcionario Inteiro PK, NOT NULL Código de identificação do
funcionário
Nome_Funcionario Caractere NOT NULL Nome do funcionário
Data_Contratacao Data NOT NULL Data de contratação do
funcionário
Salario Decimal NOT NULL Salário do funcionário
Cod_Departamento Inteiro FK, NOT NULL Código do departamento ao
qual o funcionário pertence
Cod_Localidade Inteiro FK, NOT NULL Código da localidade onde
reside o funcionário
Descrição dos Atributos

169
Departamento Cod_Departamento Inteiro PK, NOT NULL Código de identificação do
departamento
Nome_Departamento Caractere NOT NULL Nome do departamento

170
Localidade Cod_Localidade Inteiro PK, NOT NULL Código de identificação da
localidade
Cidade Caractere NOT NULL N/D
Estado Caractere NOT NULL N/D
País Caractere NOT NULL N/D

171
Relacionamento Tabela 1 - PK Tabela 2 – FK Descrição
Pertence Departamento Funcionario Relacionamento que descreve
como funcionários e
departamentos se associam
Reside Localidade Funcionario Relacionamento que descreve
como funcionários se associam às
localidades
Descrição dos Relacionamentos

172
Resumo do Módulo
O modelo lógico relacional é o momento em que vamos traduzir as entidades e atributos em
tabelas, compostas por linhas e colunas.
Um modelo relacional é composto por tabelas e chaves.
Uma tabela é um conjunto de linhas chamadas de registros (tuplas), onde cada coluna corresponde
aos atributos (campos) da entidade modelada.
As chaves são divididas em: Candidatas, Primárias, Alternadas e Estrangeiras.
Restrições de Integridade são regras da modelagem que garantem a consistência dos dados.
Quando temos um relacionamento N:N entre duas entidades, é necessário criar uma tabela
intermediária que nos permitam desmembrar 1 relacionamento N:N em dois 1:N.
Dicionário de dados é uma boa prática de documentação de projetos de banco de dados.

M Ó D UL O 4

174
Anomalias em Bancos de Dados
Antes de falar sobre Normalização, vamos entender os problemas associados às Anomalias de Bancos de Dados.
Anomalias são mudanças em dados que podem gerar uma inconsistência no banco de dados relacional.
Uma inconsistência é geralmente representada por situações em que dados que deveriam ser iguais, apresentam
valores diferentes em várias tabelas do banco de dados. Por exemplo, o valor de venda de um produto deve ser o
mesmo valor armazenado nas tabelas venda e nota fiscal. Se os valores forem diferentes, entende-se que existe uma
inconsistência.
Inconsistências geralmente aparecem quando o banco de dados é projetado de forma inadequada.
As anomalias de atualização são classificadas em 3 categorias:
Anomalias de Inserção
Anomalias de Exclusão
Anomalias de Atualização

175
Para entender melhor sobre cada uma das 3 anomalias, vamos trabalhar com uma tabela de exemplo. Essa tabela vai
armazenar as informações de funcionários de uma agência bancária.
CodFuncionario Nome Cargo Salario NumAg Endereco Telefone
100 Ana Gerente 6000 001 Viera Souto, 155 3333-4444
101 Bruno Caixa 3100 002 Presidente Vargas, 1004 2222-5555
102 Caio Caixa 2800 001 Vieira Souto, 155 3333-4444
103 Diana Gerente 7500 003 Castro Alves, 20 2121-2121
104 Erica Caixa 2500 002 Presidente Vargas, 1004 2222-5555

176
Anomalia de Inserção
Uma anomalia de inserção acontece quando, ao inserir um dado, geramos uma inconsistência no banco de dados.
Na tabela em questão, para inserir um novo funcionário, devemos tomar cuidado para preencher os dados exatamente
da mesma forma cadastrada por outros funcionários.
Por exemplo, um novo funcionário para a agência 001 deve ter exatamente o mesmo endereço dos outros funcionários
que trabalham nessa mesma agência.
Se isso não for feito, teremos uma inconsistência: dois funcionários que trabalham na mesma agência possuem
endereços diferentes.
ANOMALIA DE INSERÇÃO

177
Anomalia de Exclusão
Uma anomalia de exclusão acontece quando, ao excluir um dado, geramos uma inconsistência no banco de dados.
Na tabela em questão, se excluirmos o funcionário 103, excluímos também os dados da agência 003, que deixa de existir.
ANOMALIA DE EXCLUSÃO

178
Anomalia de Atualização
Uma anomalia de atualização acontece quando, ao atualizar um dado, geramos uma inconsistência no banco de dados.
Na tabela em questão, se atualizarmos o endereço da agência 002, precisaremos atualizar o endereço de todas as
agências 002. Caso contrário, teríamos funcionários da mesma agência, com endereços diferentes.
ANOMALIA DE ATUALIZAÇÃO

179
Observe que todas as anomalias acontecem devido à existência de redundância de informação na tabela.
Por exemplo, o mesmo endereço de uma agência é armazenado várias vezes, assim como o telefone, quando esses
dados poderiam ser armazenados uma única vez.
Assim, para evitar anomalias, é necessário evitar redundâncias.
A redundância é evitada através da normalização das tabelas, que veremos como fazer ao longo deste módulo.

180
5 Conceitos Importantes
Antes de dar início à apresentação das formas normais, vamos abordar 5 conceitos necessários para uma melhor
compreensão.
Os conceitos que falaremos agora serão:
Dependência Funcional
Dependência Funcional Parcial
Dependência Funcional Transitiva
Atributos Multivalorados
Atributos Compostos

181
Conceito 1: Dependência Funcional
Uma dependência funcional é um relacionamento entre dois ou mais atributos, de forma que o valor de um atributo
identifique o valor para cada um dos outros atributos, ou seja, um atributo está relacionado a outro.
Vejamos um exemplo.
Imagine que tenhamos uma tabela CLIENTE, com as informações de CPF e Nome. Para descobrirmos o nome do
cliente, primeiramente precisamos saber qual é o CPF dele. Assim, o campo/atributo Nome é dependente do
campo/atributo CPF. Observe que a recíproca não é verdadeira.
CPF Nome
111 Ana
222 Bruno
333 Carla
444 Diego
CLIENTE

182
Conceito 1: Dependência Funcional
Mas, você pode até pensar: “Eu consigo sim conhecer o nome do cliente e não saber seu CPF. Nem sempre vou
precisar saber o CPF para saber o nome.”
Então veja o novo exemplo. Será que conhecer apenas o nome do cliente é suficiente?
CPF Nome
111 Ana
222 Bruno
333 Carla
444 Diego
555 Ana
CLIENTE
Se eu te informo qualquer CPF, você facilmente saberá quem é o cliente. Mas, e se eu te digo o nome “Ana”, será que
você sabe qual cliente estou falando? Observe que existem duas pessoas com o nome igual: Ana. Isso é perfeitamente
possível, pessoas com nomes homônimos. Neste caso, apenas com o nome, não seria possível identificar o cliente.

183
Conceito 2: Dependência Funcional Parcial
Uma dependência funcional parcial ocorre quando os atributos não chave (não identificadores) não dependam de toda
a chave primária quando ela for composta.
Desta forma, nas tabelas onde a chave primária for composta, todos os atributos devem depender de toda a chave
primária. Caso a dependência seja de parte da chave, verificamos a dependência funcional parcial.
Vejamos um exemplo.
Matrícula_Aluno Cod_Disciplina Período Nome_Disciplina Nota
111 1 1 Cálculo I 8
111 2 1 Física I 9.5
111 3 1 Contabilidade I 10
111 4 1 Química 7.5
111 5 1 Intro. Eng. 8.5
BOLETIM
Na situação acima, temos que a chave primária da tabela será composta pelas colunas: Matrícula, Cod_Disciplina e
Período (sem saber a matrícula do aluno, o código da disciplina e o período, não tem como saber a nota; por isso, a
chave é composta pelas 3 colunas).

184
Conceito 2: Dependência Funcional Parcial
Matrícula_Aluno Cod_Disciplina Período Nome_Disciplina Nota
111 1 1 Cálculo I 8
111 2 1 Física I 9.5
111 3 1 Contabilidade I 10
111 4 1 Química 7.5
111 5 1 Intro. Eng. 8.5
BOLETIM
Observando a tabela, verificamos que o atributo Nome_Disciplina depende apenas de Cod_Disciplina e não depende
nem da matrícula do aluno e nem do período.
Assim, existe uma dependência funcional parcial. Isso pode trazer problemas para o modelo como redundância de
informações. Por exemplo, se o aluno precisa refazer uma determinada disciplina, precisaremos repetir tanto o
Cod_Disciplina como o Nome_Disciplina na tabela, o que não é desejado.
A solução para este problema seria criar uma tabela separada, contendo as informações de Disciplina (Cod_Disciplina
e Nome_Disciplina) e deixar na tabela BOLETIM apenas o Cod_Disciplina, que é o suficiente para identificar a
disciplina. Veremos essa solução mais a frente.

185
Conceito 3: Dependência Funcional Transitiva
Quando um ou mais campos de uma entidade não são dependentes diretamente da chave primária ou de parte dela,
mas sim dependente de outro campo da tabela (campo este que não a Chave Primária), temos uma dependência
funcional transitiva.
Aqui vale deixar clara a diferença entre a dependência funcional parcial e a dependência funcional transitiva.
Na parcial, pelo menos um atributo da tabela depende de parte da chave primária (e não dela toda).
Já na transitiva, pelo menos um atributo da tabela depende de outro atributo que não seja chave primária.

186
Conceito 3: Dependência Funcional Transitiva
Vejamos um exemplo. Temos uma tabela de funcionários, com as informações de: ID_Funcionario, Nome_Funcionario,
ID_Cargo, Nome_Cargo, Salario. Nesta tabela, a Chave Primária é a coluna ID_Funcionario.
ID_Funcionario Nome_Funcionario ID_Cargo Nome_Cargo Salario
1 João 1 Analista 3500
2 Katia 1 Analista 3500
3 Luis 2 Técnico 4100
4 Maria 2 Técnico 4100
5 Neto 3 Assistente 2200
Observe, no entanto, que o ID_Funcionario determina apenas o nome do funcionário. Já as colunas Nome_Cargo e
Salario são determinadas pela coluna ID_Cargo, que não depende da Chave Primária ID_Funcionario.
Nesta situação, temos portanto uma dependência funcional transitiva. Alguns pontos negativos: os valores das
colunas Nome_Cargo e Salario se repetem desnecessariamente (exemplo, João e Katia tem ID_Cargo = 1, e por isso o
Cargo Analista e Salario 3500 aparecem repetidamente na tabela).
Para esta situação, o ideal seria separar as colunas Nome_Cargo e Salario em uma outra tabela, e deixar apenas a
coluna ID_Cargo na tabela de funcionários.

187
Conceito 4: Atributos Multivalorados
Atributos multivalorados são atributos que podem conter mais de um valor para um mesmo registro. Na tabela abaixo,
temos uma lista de funcionários e seus respectivos telefones de contato. Perceba que na coluna Telefone temos mais
de um telefone para algumas pessoas. Isso faz do atributo Telefone um atributo multivalorado.
Não podemos ter em nossas tabelas atributos multivalorados, e mais a frente veremos uma forma de corrigir esse
problema.
ID_Funcionario Nome_Funcionario Telefone
1 João (21) 99999-0001
(21) 99999-0002
(21) 99999-0003
2 Katia (21) 99999-0004
3 Luis (21) 99999-0005
(21) 99999-0006
4 Maria (21) 99999-0007
5 Neto (21) 99999-0008

188
Conceito 5: Atributos Compostos
Atributos compostos são atributos que poderiam ser subdivididos em vários atributos. Vejamos um exemplo.
Na tabela abaixo, temos uma lista de funcionários e seus respectivos endereços. Nesta tabela, o atributo Endereço é
multivalorado, uma vez que poderia ser dividido em vários atributos (Rua, Bairro, Cidade, UF).
O ideal seria dividir esta única coluna em várias colunas, para que assim a gente elimine o atributo composto.
ID_Funcionario Nome_Funcionario Endereço
1 João Av. Mem de Sá, 100, apto 101 – Centro – Rio de Janeiro - RJ
2 Katia Av. Portugal, 324, casa 01 – Urca – Rio de Janeiro – RJ
3 Luis Av. Vieira Souto, 1300, apto 802, Leblon – Rio de Janeiro – RJ
ID_Funcionario Nome_Funcionario Endereço Bairro Cidade UF
1 João Av. Mem de Sá, 100, apto 101 Centro Rio de Janeiro RJ
2 Katia Av. Portugal, 324, casa 01 Urca Rio de Janeiro RJ
3 Luis Av. Vieira Souto, 1300, apto 802 Leblon Rio de Janeiro RJ

189
O que é a Normalização?
Podemos definir a Normalização como uma sequência de passos e verificações aplicadas a um banco de dados com o
objetivo de eliminar, ou pelo menos minimizar, as redundâncias e inconsistências no banco. Tal procedimento é feito a
partir da identificação de anomalias de inserção, exclusão e atualização em uma relação, decompondo-a em relações
melhor estruturadas e minimizando a redundância.
Eliminar a redundância nos dados possui algumas vantagens:
Reduzir o espaço necessário para armazenar o banco de dados
Melhorar a organização dos dados
Reduzir o impacto de atualizações, inserções e exclusões nos dados dos bancos de dados

190
O processo de normalização é aplicado em etapas, conhecidas como Formas Normais.
As Formas Normais especificam critérios que definem quando uma tabela está bem estruturada ou não. Assim, para
saber se uma tabela está bem estruturada ou não, devemos verificar se a estrutura da tabela satisfaz todas as formas
normais, ou pelo menos aquelas mais importantes.
Existem uma série de formas normais na literatura, são elas:
Primeira Forma Normal
Segunda Forma Normal
Terceira Forma Normal
Forma Normal de Boyce-Codd
Quarta Forma Normal
Quinta Forma Normal

191
As Formas Normais é como se fossem fases de um jogo. Você só pode passar para a próxima se estiver adequado à
Forma anterior.
Forma Normal de Boyce-Codd
Quarta Forma Normal
Quinta Forma Normal
Outras Formas Normais

192
Para muitos autores, a aplicação das três primeiras já é suficiente para garantir que o banco de dados não terá
redundâncias e inconsistências.
No curso, vamos focar portanto nas três primeiras formas normais.

193
Formas Normais
Vimos anteriormente 5 conceitos importantes antes de falar das formas normais, são eles:
1- Dependência Funcional
2- Dependência Funcional Parcial
3- Dependência Funcional Transitiva
4- Atributos Multivalorados
5- Atributos Compostos
Cada um desses conceitos tem por trás um problema a ser resolvido. Por exemplo, não poderemos ter em nossas
tabelas campos multivalorados.
Precisaremos então aplicar uma série de regras e assim corrigir estes problemas, que chamamos de anomalias de
bancos de dados.
É nesse momento que entram as Formas Normais.

194
Formas Normais
Como vimos anteriormente, o processo de normalização compreende o uso de um conjunto de regras, chamadas de
formas normais. As principais formas normais que temos, como já apresentado, são:
- 1ª Forma Normal
- 2ª Forma Normal
- 3ª Forma Normal
A seguir, entenderemos como cada uma dessas regras é aplicada na prática para garantir a consistência do nosso
banco de dados.

195
Primeira Forma Normal (1FN)
A primeira forma normal tem como objetivo eliminar atributos multivalorados (não atômicos) e atributos compostos.
Da definição de 1FN temos:
“Uma relação está na 1FN se e somente se todos os seus atributos contêm apenas valores atômicos, simples e
indivisíveis”.

196
Passo a passo da 1FN
Em resumo, para adequar uma tabela que não está na 1FN é necessário realizar os seguintes passos:
Criar uma tabela para armazenar os dados do atributo multivalorado. As colunas dessa nova tabela devem ser
compostas por: (1) atributo multivalorado da tabela original e (2) chave primária da tabela original. A chave
primária da tabela original se transforma na chave estrangeira da nova tabela.
Remover o atributo multivalorado da tabela original.
Na tabela original, para cada atributo composto, criar uma nova coluna para cada informação a ser desmembrada.
Identificar a existência de atributos multivalorados (não atômicos) e atributos compostos.

197
Exemplo Prático: Tabela PESSOA
Vejamos um exemplo. Na tabela abaixo, temos que uma série de atributos sobre a entidade PESSOA. Essa tabela não
está na Primeira Forma Normal. Vamos fazer a adequação.
CPF Nome Sexo Localização Telefone
111 Ana F Rio de Janeiro, RJ 999-444, 999-000
222 Bruno M São Paulo, SP 888-888, 444-333
333 Carla F Belo Horizonte, MG 555-777
444 Diego M Vitória, ES 999-999
PESSOA

198
Passo 1 da 1FN
Na tabela em questão, temos que o atributo Localização é um atributo composto, o que significa que ele poderia ser
desmembrado em mais de uma informação: Cidade e Estado.
PESSOA
Atributo
Composto

199
Passo 1 da 1FN
Por outro lado, o atributo Telefone é um atributo multivalorado (não atômico). Ou seja, um atributo que contém, na
mesma célula, várias ocorrências daquele mesmo atributo.
PESSOA
Atributo
Multivalorado

200
Passo 2 da 1FN
Na tabela original, identificamos como chave primária o atributo CPF, e como atributo multivalorado a coluna
Telefone. A partir dessas duas colunas, criamos uma tabela nova.
PESSOA
CPF Telefone
111 999-444
111 999-000
222 888-888
222 444-333
333 555-777
444 999-999

201
Passo 2 da 1FN
PESSOA
CPF Telefone
111 999-444
111 999-000
222 888-888
222 444-333
333 555-777
444 999-999
A chave primária da tabela original se transforma na chave
estrangeira da nova tabela.

202
Passo 2 da 1FN
PESSOA
CPF Telefone
111 999-444
111 999-000
222 888-888
222 444-333
333 555-777
444 999-999
O atributo multivalorado da
tabela original se transforma
em uma coluna da tabela nova.

203
Passo 2 da 1FN
Agora que criamos uma nova tabela para armazenar as informações de telefones das pessoas, não precisamos mais da
coluna Telefone na tabela PESSOA.
PESSOA
CPF Telefone
111 999-444
111 999-000
222 888-888
222 444-333
333 555-777
444 999-999
TELEFONE

204
Passo 2 da 1FN
Agora que criamos uma nova tabela para armazenar as informações de telefones das pessoas, não precisamos mais da
coluna Telefone na tabela PESSOA.
PESSOA
CPF Telefone
111 999-444
111 999-000
222 888-888
222 444-333
333 555-777
444 999-999
TELEFONE

Apostila Modelagem e Desenvolvimento de Banco de Dados.pdf

Apostila Modelagem e Desenvolvimento de Banco de Dados.pdf

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Apostila Modelagem e Desenvolvimento de Banco de Dados.pdf

Semelhante a Apostila Modelagem e Desenvolvimento de Banco de Dados.pdf (20)

Último

Último (20)

Apostila Modelagem e Desenvolvimento de Banco de Dados.pdf