Banco de Dados Páginaprincipal

Pular para o conteúdo inicial Lição 1 Liçãopara

Pular 2 Lição 3
a navegação Lição 4 Lição 5 Lição 6

PDF - VERSÃO DE IMPRESSÃO

RELAÇÕES X VARIÁVEL DE RELAÇÃO ( RELVAR )

objetivo
Nesta aula vamos aprofundar nosso conhecimento sobre o que acontece com os dados dentro de um relacionamento .

Aprenderemos também como a compreensão da teoria das variáveis de relação pode nos auxiliar a compreender melhor o
armazenamento dos dados, como eles se relacionam entre si e quais são as características principais dos relacionamentos que
garantem aos usuários a integridade dos dados.
 problematização
Agora que você já está entendendo um pouco mais sobre Banco de Dados, chegou a hora de começarmos a trabalhar
especificamente alguns termos técnicos, pois, no mundo profissional as pessoas até entendem quando falamos termos
genéricos, mas o uso de termos técnicos corretos ajuda a compreender sobre qual etapa do processo estamos falando
durante uma reunião, ou na hora de repassar alguma informação para outro profissional.
A fim de que você entenda bem a importância de compreendermos os termos corretamente, vamos fazer uma analogia com a

área médica durante um processo cirúrgico.

Para uma pessoa de fora da área, todos os profissionais que estão dentro do centro cirúrgico são médicos, mas, quando
olhamos tecnicamente, em geral, teremos a(o) cirurgiã(o) responsável. Caso seja uma cirurgia mais complexa ou de maior
risco, haverá mais do que uma(um) cirurgiã(o), já sabendo que se a cirurgia for de coração, eles devem ser da “categoria”
cardiologista, caso a cirurgia seja em uma fratura óssea, teremos um(a) ortopedista, caso seja um parto, provavelmente será
um(a) obstetra, e assim por diante.
Além da(o) cirurgiã(o), haverá também um(a) anestesista, que irá acompanhar a cirurgia durante todo o processo, garantindo
o bem-estar do paciente. Deverá haver também instrumentistas, que são profissionais que provêem os instrumentos
cirúrgicos durante o procedimento. Além desses profissionais, podem estar na sala outros profissionais de suporte, como, por
exemplo, durante um parto é comum a presença de um(a) pediatra para receber a criança e proceder com os primeiros
cuidados.

Quando falamos de Banco de Dados é comum utilizarmos termos de forma genérica inicialmente para não complicarmos
muito o processo de entendimento, mas, conforme avançamos com o conhecimento dentro do tema, é importante nos
acostumarmos com os termos mais profissionais.
Mas quais são os termos profissionais corretos? Quais os problemas que podem ocorrer se não utilizarmos as nomenclaturas
devidas? Se fosse no exemplo da cirurgia, confundir o(a) anestesista com o cirurgiã(o) poderia ser caso de vida ou morte, não
é mesmo? Então vamos nos aprofundar sobre o tema para que em seu futuro profissional você utilize os termos
adequadamente.

case
Para que possamos exemplificar o nosso problema, vamos analisar um caso simples, que podemos encontrar em várias
empresas, quando o empresário faz controles com base em planilhas de cálculo. Para essa análise, vamos considerar o
seguinte levantamento:
O cliente necessita fazer um controle da quantidade de peças de cada fornecedor que está no seu estoque. Hoje, o controle é
feito por meio de uma planilha de cálculos, na qual o cliente faz todos os lançamentos de compra e venda, atualizando a
quantidade em estoque diariamente.
Para não deixar nosso problema muito complexo, vamos considerar que, após passar os dados para um Banco de Dados, os
lançamentos de estoque continuarão a ser realizados diariamente e de forma manual, ou seja, a nossa preocupação nesse
exercício será apenas o controle de estoque peças/fornecedor e não a movimentação de compras e vendas, que são outra
parte da realidade do nosso cliente, que não vamos considerar no momento.
Na tabela abaixo, fornecida pelo cliente, podemos observar algumas características importantes. Faça uma análise geral da
tabela, antes de prosseguirmos.
Tabela 1: Peças em estoque por fornecedor / Fonte : o autor

#PraCegoVer – tabela com 14 linhas e 11 colunas. Na primeira linha, em negrito, temos na primeira coluna id_forn, na segunda coluna nome_f, na
terceira status, na quarta a palavra cidade, na quinta coluna id_peça, na sexta nome_p, na sétima coluna cor, na oitava coluna peso, na nona coluna
qtde, na décima coluna, vlr unit e na décima primeira coluna vlr_total. Na segunda linha, temos na primeira coluna S1, na segunda coluna Smith,
na terceira 20, na quarta coluna Londres, na quinta coluna P1, na sexta Selim, na sétima coluna vermelha, na oitava coluna 250, na nona coluna
300, na décima coluna 2,00 e na décima primeira coluna 600,00. Na terceira linha, temos na primeira coluna S1, na segunda coluna Smith, na
terceira 20, na quarta coluna Londres, na quinta coluna P2, na sexta Pneu, na sétima coluna Preto, na oitava coluna 180, na nona coluna 200, na
décima coluna 3,25 e na décima primeira coluna 650,00. Na quarta linha, temos na primeira coluna S1, na segunda coluna Smith, na terceira 20, na
quarta coluna Londres, na quinta coluna P3, na sexta Pedal, na sétima coluna Prata, na oitava coluna 330, na nona coluna 400, na décima coluna
4,00 e na décima primeira coluna 1600,00. Na quinta linha, temos na primeira coluna S1, na segunda coluna Smith, na terceira 20, na quarta coluna
Londres, na quinta coluna P4, na sexta Pedal, na sétima coluna Preto, na oitava coluna 320, na nona coluna 200, na décima coluna 3,90 e na décima
primeira coluna 780,00. Na sexta linha, temos na primeira coluna S1, na segunda coluna Smith, na terceira 20, na quarta coluna Londres, na quinta
coluna P5, na sexta Canote, na sétima coluna Prata, na oitava coluna 280, na nona coluna 100, na décima coluna 8,00 e na décima primeira coluna
800,00. Na sétima linha, temos na primeira coluna S1, na segunda coluna Smith, na terceira 20, na quarta coluna Londres, na quinta coluna P6, na
sexta Canote, na sétima coluna Preto, na oitava coluna 275, na nona coluna 100, na décima coluna 7,50 e na décima primeira coluna 750,00. Na
oitava linha, temos na primeira coluna S2, na segunda coluna Jones, na terceira 30, na quarta coluna Paris, na quinta coluna P1, na sexta Selim, na
sétima coluna vermelha, na oitava coluna 250, na nona coluna 300, na décima coluna 2,10 e na décima primeira coluna 630,00. Na nona linha,
temos na primeira coluna S3, na segunda coluna Blake, na terceira 30, na quarta coluna Paris, na quinta coluna P2, na sexta Pneu, na sétima coluna
Preto, na oitava coluna 180, na nona coluna 200, na décima coluna 3,52 e na décima primeira coluna 704,00. Na décima linha, temos na primeira
coluna S4, na segunda coluna Clark, na terceira 20, na quarta coluna Londres, na quinta coluna P2, na sexta Pneu, na sétima coluna Preto, na oitava
coluna 180, na nona coluna 200, na décima coluna 3,49 e na décima primeira coluna 698,00. Na décima-primeira linha, temos na primeira coluna
S4, na segunda coluna Clark, na terceira 20, na quarta coluna Londres, na quinta coluna P4, na sexta Pedal, na sétima coluna Preto, na oitava coluna
320, na nona coluna 300, na décima coluna 3,95 e na décima primeira coluna 1185,00. Na décima-segunda linha, temos na primeira coluna S4, na
segunda coluna Clark, na terceira 20, na quarta coluna Londres, na quinta coluna P5, na sexta Canote, na sétima coluna Prata, na oitava coluna 280,
na nona coluna 400, na décima coluna 7,50 e na décima primeira coluna 3000,00. Na décima-terceira linha, temos na primeira coluna S2, na
segunda coluna Jones, na terceira 30, na quarta coluna Paris, na quinta coluna P2, na sexta Pneu, na sétima coluna Preto, na oitava coluna 180, na
nona coluna 400, na décima coluna 3,50 e na décima primeira coluna 1400,00. Na décima-quinta linha, temos na primeira coluna S5, na segunda
coluna Adams, na terceira 30, na quarta coluna Rio, e nas demais colunas a sigla N/D, indicando não disponibilidade de dados.

Em uma análise bem simples, inicialmente podemos observar que temos três tipos de informação misturadas nessa
planilha/tabela: informações sobre os fornecedores, informações sobre as peças e informações sobre o estoque, observando
que o estoque sempre está vinculado ao fornecedor de cada peça, pois, como podemos observar, temos mais do que um
fornecedor por peça e cada fornecedor tem um preço diferente para a mesma peça.
Como você já aprendeu a olhar a realidade de uma forma diferenciada, por meio da lente dos dados, como seria uma boa
forma de reorganizar essas informações?
Pense bem e tente resolver em uma folha de papel, ou até mesmo no computador, separando essa tabela em 3 novas tabelas:
fornecedores, peças e estoque.
Após fazer essa separação, assista ao vídeo a seguir e veja uma explicação de como seria uma solução genérica para essa
situação:
 Conceitualização
Como nós já vimos anteriormente, quando trabalhamos em um projeto de Banco de Dados, é muito comum misturarmos as
camadas da arquitetura do sistema, principalmente quando fazemos referência às tabelas do sistema, e, em português, é
muito comum trazermos as palavras que são utilizadas em atividades práticas (ou físicas) como sendo as palavras principais no
nosso vocabulário.
Date (2015), em seu livro Projeto de Banco de Dados e Teoria Relacional – Formas Normais e Tudo mais ele cita a importância
,

de usarmos referências corretas para as etapas de análise, principalmente quando nos aprofundamos no projeto para
desenvolver as lógicas e relacionamentos que serão implementados no Banco de Dados:

“[...] ao termo design me refiro ao design lógico, não ao design físico. O design lógico está
preocupado como o usuário compreende o banco de dados [...] o design físico, em contraste, está
preocupado com a forma como um determinado design lógico é mapeado para o armazenamento
físico” (DATE, 2015, p. 27).

Uma boa interpretação desta frase de Date (2015) é que o projetista de Banco de Dados deve se preocupar em usar termos
corretos em cada camada que está trabalhando, principalmente porque, como você deve se lembrar de outras aulas, as
camadas da arquitetura devem manter independência entre si.
Nesse momento então, vamos dar sequência ao que vimos no modelo conceitual, quando trabalhamos basicamente com
entidades, relacionamentos e cardinalidades e, vamos desenvolver um modelo lógico, que vai possibilitar validarmos o
modelo conceitual e já deixar a estrutura praticamente preparada para ser convertida em um Banco de Dados.
Para iniciar e deixarmos todos alinhados com os conceitos, precisamos revisar o que é o conceito de variável em Tecnologia
da Informação (TI). Sempre que fazemos referência a algo que tem um conceito e que, durante o processo, pode alterar seu
valor, denominamos “ variável ” para que possamos fazer referências durante o processo de programação e indicar aos
algoritmos criados (programas) sobre o que estamos querendo processar em determinado momento.
Por exemplo, em um programa com uma linguagem de programação qualquer, precisamos solicitar ao usuário do sistema que
informe o valor da hora trabalhada e quantas horas foram trabalhadas em um mês. Esses valores serão armazenados em
variáveis identificadas, por exemplo, como valor_hora e qtd_horas_me s Enquanto o programa executa essas informações, os
.

valores podem ser utilizados de diversas formas, pois estão armazenados na memória do computador. Digamos que eu
necessite calcular o valor do salário do funcionário dentro de um mês, eu vou colocar uma instrução dentro do meu programa
que faça a multiplicação entre valor_hora e qtd_horas_mes e armazene em outra variável denominada, por exemplo, salário .

O conceito de variável é utilizado basicamente para que não tenhamos preocupação com os valores que serão utilizados,
apenas com a lógica que será realizada pelo programa.

Quando pensamos em Banco de Dados também é importante trabalharmos com as terminologias corretas, pois,
dessa forma, todos os envolvidos no projeto saberão sobre qual camada da arquitetura estamos fazendo referência.
Vale, aqui, uma observação técnica que alguns autores trabalham utilizando os mesmos termos nas camadas
conceitual e lógica, ou até fazem referência às duas como sendo apenas uma camada, como vimos até agora. Mas,
de acordo com Date (e vários outros autores), no nível conceitual a preocupação é entendermos, de forma mais
genérica, quais são as “coisas” que vão ter que ser abstraídas para compor a base do sistema e qual é o
relacionamento que existe entre elas.
Desse modo, de forma conceitual, temos o objetivo de compreender como as regras de negócios vão exigir que
os dados sejam armazenados, e quando passamos ao modelo lógico, ainda no nível conceitual, temos que ter a
preocupação de converter toda essa realidade em um modelo pré-dados. Isto é, temos que transformar o que
fizemos em variáveis e relacionamentos que, posteriormente, servirão de base para criação do Banco de Dados.
,

Relvars X Relacões

Já aprendemos que, ao criarmos um Diagrama Entidade Relacionamento (DER) dentro do modelo conceitual, transformamos
as “coisas” do mundo real, ou melhor do minimundo que separamos para nossa análise, em Entidades. Cada entidade é criada
para compreendermos seus conceitos e regras e as entidades são vinculadas entre si por relacionamentos, que, na verdade,
explicam quais são as ações que as entidades realizam entre si.
Eventualmente podemos até abstrair algum conteúdo dentro das entidades para compreendê-la, mas, em um DER não é
comum representarmos o conteúdo das entidades ou dos relacionamentos.
Porém, dentro da teoria do modelo relacional, quando necessitamos criar um modelo lógico para o Banco de Dados, é
importante a visualização de dados representativos das Entidades que vieram do modelo conceitual, que, no modelo lógico,
passam a ser denominadas de “Variáveis de Relação", tecnicamente são denominadas relvars .

Para entendermos o porquê dessa denominação, em um modelo lógico vamos observar cada “Entidade” (Modelo Conceitual)
ou cada “Tabela” (Modelo Físico) em um momento T (Tempo).

A relvar é uma “fotografia” em um momento T que extraímos do Banco de Dados para nossa análise.

Por exemplo, podemos pegar a tabela de fornecedores que

geramos no nosso estudo de caso e representá-la conforme
a Tabela 2, a seguir:

Tabela 02 Relvar
: F (Fornecedores) / Fonte : o autor.

#PraCegoVer – tabela com 6 linhas e 4 colunas. Na primeira linha, em negrito, temos na primeira coluna id_forn, na segunda coluna nome_f, na
terceira status e na quarta a palavra cidade. Na segunda linha, na primeira coluna tem escrito S1, na segunda coluna Smith, na terceira coluna o
número 20 e na quarta coluna está escrito Londres. Na terceira linha, na primeira coluna tem escrito S2, na segunda coluna Jones, na terceira
coluna o número 30 e na quarta coluna está escrito Paris. Na quarta linha, na primeira coluna tem escrito S3, na segunda coluna Blake, na terceira
coluna o número 30 e na quarta coluna está escrito Paris. Na quinta linha, na primeira coluna tem escrito S4, na segunda coluna Clark, na terceira
coluna o número 20 e na quarta coluna está escrito Londres. Na sexta linha, na primeira coluna tem escrito S5, na segunda coluna Adams, na
terceira coluna o número 30 e na quarta coluna está escrito Rio.

Para não confundir com o Modelo Físico, vamos chamar a nossa relvar de “ F ”(Fornecedores). Nesse momento então, a nossa
variável de relação – relvar – F conta com 5 tuplas ou seja, 5 linhas ou registros do modelo físico, por exemplo: temos a 1ª
,

tupla como S1, Smith, 20 e Londres .

Caso seja inserido um novo Fornecedor no Banco de Dados, a relvar F terá um novo valor, ou seja, todas as relvars a que F está
relacionada poderão alterar o seu valor em razão da alteração realizada em F, com a inclusão de uma nova informação. O valor
de uma determinada relvar em um determinado momento T recebe o nome de valor da relação ou apenas relação , .

Resumindo: Nesse exemplo temos que a nossa relvar F tem, neste momento 5 tuplas que, em conjunto, são o valor da
,

relação, ou apenas, relação .

Dependências Funcionais

Quando estamos falando de relação e relvar , é fundamental o conhecimento do que são dependências funcionais.
As dependências funcionais como o próprio nome já diz, são as dependências que os atributos da relvar têm entre si, ou
,

seja, por conceito cada relvar somente pode possuir um tipo de informação. Cada tupla (linha ou registro) da nossa relvar
pode fazer referência a apenas uma “coisa” do minimundo (fração mundo real que foi selecionada para o sistema).
Para entender melhor, vamos considerar a planilha de estoque (Tabela 1 do nosso estudo de caso) que foi coletada junto ao
cliente que solicitou o desenvolvimento do sistema e, para não sofrermos influência de conhecimentos externos, vamos
chamar apenas de relvar E .

Observando a nossa relvar E temos que, em um primeiro passo identificar qual seria a chave nessa relação. Como ainda não
,

sabemos qual é a chave de forma clara, vamos tentar identificar se há algum atributo (campo), ou conjunto de atributos, que
atenda a característica necessária para ser chave primária, ou seja, se há um atributo que identifique, de forma única toda a
tupla.
Lembrando que nessa busca podemos encontrar mais de um conjunto de atributos. Considerando isso, nesse momento, todos
os atributos, ou grupos de atributos, que encontrarmos vamos denominar de chave candidata .

Olhando a Tabela 1 cuidadosamente, não conseguimos identificar um único atributo candidato a ser chave na relação, pois
não podemos afirmar que por apenas um atributo conseguimos identificar, de forma única, as tuplas da relação. Passamos
então a combinar os atributos e observamos que se utilizarmos id_forn junto com id_peça é possível atender ao requisito da
chave, então vamos chamá-la de chave candidata e continuar a análise para ver se há algum outro conjunto de atributos que
possa se candidatar a ser chave. Nessa nova análise teremos nome_f e nome_p que, nos dados coletados, poderiam também
se candidatar a ser a chave da relação. Temos então, como chaves candidatas :

id_forn, id_peça ou nome_f, nome_p

Como sabemos que nomes, em geral, não são um bom identificador para chaves em Banco de Dados, pois tem maior
probabilidade de ter homônimos (nomes iguais) no mundo real, vamos descartar o conjunto nome_f nome_p e eleger ,

id_forn id_peça como sendo a chave primária nessa relação.

,

Reordenando os atributos (colunas) na nossa relação teremos agora o par id_forn, id_peça como sendo a chave primária, ou
seja, o conjunto de atributos que identifica de forma única cada tupla (registro) na nossa relvar (tabela).
Tabela 3: Relvar E, com chave primária identificada. / Fonte : o autor.

#PraCegoVer: tabela com 14 linhas e 11 colunas. Na primeira linha, em negrito, temos na primeira coluna, destacado em azul, id_forn, na segunda
coluna, destacado em azul, id_peça, na terceira nome_f, na quarta status, na quinta a palavra cidade, na sexta coluna nome_p, na sétima coluna
cor, na oitava coluna peso, na nona coluna qtde, na décima coluna, vlr unit e na décima primeira coluna vlr_total. Na segunda linha, temos na
primeira coluna, destacado em azul, S1, na segunda coluna, destacado em azul P1 na terceira coluna Smith, na quarta 20, na quinta coluna
Londres, na sexta Selim, na sétima coluna vermelha, na oitava coluna 250, na nona coluna 300, na décima coluna 2,00 e na décima primeira
600,00. Na terceira linha, temos na primeira coluna, destacado em azul, S1, na segunda coluna, destacado em azul, P2, na terceira coluna Smith,
na quarta 20, na quinta coluna Londres, na sexta Pneu, na sétima coluna Preto, na oitava coluna 180, na nona coluna 200, na décima coluna 3,25 e
na décima primeira 650,00. Na quarta linha, temos na primeira coluna, destacado em azul, S1, na segunda coluna, destacado em azul, P3, na
terceira coluna Smith, na quarta 20, na quinta coluna Londres, na sexta Pedal, na sétima coluna Prata, na oitava coluna 330, na nona coluna 400,
na décima coluna 4,00 e na décima primeira 1600,00. Na quinta linha, temos na primeira coluna, destacado em azul, S1, na segunda coluna,
destacado em azul, P4, na terceira coluna Smith, na quarta 20, na quinta coluna Londres, na sexta Pedal, na sétima coluna Preto, na oitava coluna
320, na nona coluna 200, na décima coluna 3,90 e na décima primeira 780,00. Na sexta linha, temos na primeira coluna, destacado em azul, S1, na
segunda coluna, destacado em azul, P5, na terceira coluna Smith, na quarta 20, na quinta coluna Londres, na sexta Canote, na sétima coluna Prata,
na oitava coluna 280, na nona coluna 100, na décima coluna 8,00 e na décima primeira 800,00. Na sétima linha, temos na primeira coluna,
destacado em azul, S1, na segunda coluna, destacado em azul, P6, na terceira coluna Smith, na quarta 20, na quinta coluna Londres, na sexta
Canote, na sétima coluna Preto, na oitava coluna 275, na nona coluna 100, na décima coluna 7,50 e na décima primeira 750,00. Na oitava linha,
temos na primeira coluna, destacado em azul, S2, na segunda coluna, destacado em azul, P1, na terceira coluna Jones, na quarta 30, na quinta
coluna Paris, na sexta Selim, na sétima coluna vermelha, na oitava coluna 250, na nona coluna 300, na décima coluna 2,10 e na décima primeira
630,00. Na nona linha, temos na primeira coluna, destacado em azul, S3, na segunda coluna, destacado em azul, P2, na terceira coluna Blake, na
quarta 30, na quinta coluna Paris, na sexta Pneu, na sétima coluna Preto, na oitava coluna 180, na nona coluna 200, na décima coluna 3,52 e na
décima primeira 704,00. Na décima linha, temos na primeira coluna, destacado em azul, S4, na segunda coluna, destacado em azul, P2, na terceira
coluna Clark, na quarta 20, na quinta coluna Londres, na sexta Pneu, na sétima coluna Preto, na oitava coluna 180, na nona coluna 200, na décima
coluna 3,49 e na décima primeira 698,00. Na décima-primeira linha, temos na primeira coluna, destacado em azul, S4, na segunda coluna,
destacado em azul, P4, na terceira coluna Clark, na quarta 20, na quinta coluna Londres, na sexta Pedal, na sétima coluna Preto, na oitava coluna
320, na nona coluna 300, na décima coluna 3,95 e na décima primeira 1185,00. Na décima-segunda linha, temos na primeira coluna, destacado em
azul, S4, na segunda coluna, destacado em azul, P5, na terceira coluna Clark, na quarta 20, na quinta coluna Londres, na sexta Canote, na sétima
coluna Prata, na oitava coluna 280, na nona coluna 400, na décima coluna 7,50 e na décima primeira 3000,00. Na décima-terceira linha, temos na
primeira coluna, destacado em azul, S2, na segunda coluna, destacado em azul, P2, na terceira coluna Jones, na quarta 30, na quinta coluna Paris,
na sexta Pneu, na sétima coluna Preto, na oitava coluna 180, na nona coluna 400, na décima coluna 3,50 e na décima primeira 1400,00. Na décima-
quinta linha, temos na primeira coluna, destacado em vermelho, S5, na segunda coluna, destacado em vermelho, N/D, na terceira coluna
destacado em vermelho, Adams, na quarta destacado em vermelho, 30, na quinta coluna destacado em vermelho, Rio, e nas demais colunas
destacadas em vermelho, a sigla N/D, indicando não disponibilidade de dados

Observando agora a tabela 3 temos que considerar quais são as dependências funcionais que existem nela, ou seja, vamos
,

iniciar observando a dependência funcional que existe entre a chave primária, que está definida, e os demais atributos da
tupla.

Decomposição sem perda de informação

Com o conceito de dependência funcional entre os atributos, podemos trazer um novo conceito que é a decomposição da
relvar em outras menores, sem que haja a perda da informação. Esse conceito auxilia a tratar a integridade de dados do Banco
de Dados pela ótica das dependências funcionais.
Temos então que nome_p cor e peso têm dependência funcional apenas de id_peça e não têm vínculo direto com os demais
, ,

atributos, ou seja, somente quando id_peça varia, há variação nos valores de nome_p cor e peso. Dessa forma podemos
,

extraí-los da relvar E e criar uma nova relvar que vamos chamar de P (peças), que vai ficar então:
,
P id_peça,nome_p cor e peso). Importante
( ,

reforçar que a chave primária já criada não pode

ser alterada, ou seja, o atributo id_peça tem que
continuar a relvar E pois compõe a chave
,

primária. Os demais atributos serão extraídos.

Observe a Tabela 4, ao lado:

Tabela 04: Relvar P / Fonte : o autor

#PraCegoVer – tabela com 7 linhas e 4 colunas. Na primeira linha, destacado em azul e em negrito, temos na primeira coluna id_forn, na segunda
coluna nome_p, na terceira cor e na quarta a palavra peso. Na segunda linha, na primeira coluna destacado em azul e em negrito, tem escrito P1,
na segunda coluna Selim, na terceira coluna vermelho e na quarta coluna está escrito 250. Na terceira linha, na primeira coluna destacado em azul
e em negrito, tem escrito P2, na segunda coluna Pneu, na terceira coluna preto e na quarta coluna 180. Na quarta linha, na primeira coluna

destacado em azul e em negrito, tem escrito P3, na segunda coluna, Pedal na terceira Prata e na quarta coluna está escrito 330. Na quinta linha, na
primeira coluna destacado em azul e em negrito, tem escrito P4, na segunda coluna Pedal, na terceira coluna preto e na quarta coluna está 320. Na
sexta linha, na primeira coluna destacado em azul e em negrito, tem escrito P5, na segunda coluna Canote, na terceira coluna Prata e na quarta
coluna está escrito 280. Na sétima linha, na primeira coluna destacado em azul e em negrito, tem escrito P6, na segunda coluna Canote, na terceira
coluna Preto e na quarta coluna está escrito 275.

Observando a outra parte da relvar E podemos afirmar que nome_f status

, , e cidade tem dependência funcional apenas de
id_forn não tendo relação direta com os demais atributos desta relvar.
,
Desta forma, podemos tirar esses atributos e
levá-los para uma nova relvar, colocando,
automaticamente, o identificador da
dependência funcional como chave Desta forma .

temos a relvar F que teria: F( id_forn, nome_f,

,

status e cidade). Observe na Tabela 5, ao lado:

Tabela 05 Relvar
: F / Fonte : o autor.

#PraCegoVer – tabela com 6 linhas e 4 colunas. Na primeira linha, em negrito, temos na primeira coluna, destacado em azul, id_forn, na segunda
coluna nome_f, na terceira status e na quarta a palavra cidade. Na segunda linha, na primeira coluna, destacado em azul, tem escrito S1, na
segunda coluna Smith, na terceira coluna o número 20 e na quarta coluna está escrito Londres. Na terceira linha, na primeira coluna, destacado em
azul, tem escrito S2, na segunda coluna Jones, na terceira coluna o número 30 e na quarta coluna está escrito Paris. Na quarta linha, na primeira
coluna, destacado em azul, tem escrito S3, na segunda coluna Blake, na terceira coluna o número 30 e na quarta coluna está escrito Paris. Na
quinta linha, na primeira coluna, destacado em azul, tem escrito S4, na segunda coluna Clark, na terceira coluna o número 20 e na quarta coluna
está escrito Londres. Na sexta linha, na primeira coluna, destacado em azul, tem escrito S5, na segunda coluna Adams, na terceira coluna o
número 30 e na quarta coluna está escrito Rio.

Por último, vamos ter uma relvar E reestruturada, retirados os atributos desnecessários:
Tabela 6: Relvar E, após decomposição. / Fonte : o autor.

#PraCegoVer: tabela com 13 linhas e 5 colunas. Na primeira linha, em negrito, temos na primeira coluna destacado em azul, id_forn, na segunda
coluna, destacado em azul, id_peça, na coluna qtde, na quarta coluna, vlr_unit e na quinta coluna vlr_total. Na segunda linha, temos na primeira
coluna, em negrito e destacado em azul, S1, na segunda coluna, em negrito e destacado em azul, P1, na terceira coluna 300, na quarta coluna 2,00
e na quinta coluna 600,00. Na terceira linha, temos na primeira coluna, em negrito e destacado em azul, S1, na segunda coluna, em negrito e

destacado em azul, P2, na terceira coluna 200, na quarta coluna 3,25 e na quinta coluna 650,00. Na quarta linha, temos na primeira coluna, em
negrito e destacado em azul, S1, na segunda coluna, em negrito e destacado em azul, P3, na terceira coluna 400, na quarta coluna 4,00 e na
quinta coluna 1600,00. Na quinta linha, temos na primeira coluna, em negrito e destacado em azul, S1, na segunda coluna, em negrito e destacado
em azul, P4, na terceira coluna 200, na quarta coluna 3,90 e na quinta coluna 780,00. Na sexta linha, temos na primeira coluna, em negrito e
destacado em azul, S1, na segunda coluna, em negrito e destacado em azul, P5, na terceira coluna 100, na quarta coluna 8,00 e na quinta coluna
800,00. Na sétima linha, temos na primeira coluna, em negrito e destacado em azul, S1, na segunda coluna, em negrito e destacado em azul, P6,
na terceira coluna 100, na quarta coluna 7,50 e na quinta coluna 750,00. Na oitava linha, temos na primeira coluna, em negrito e destacado em
azul, S2, na segunda coluna, em negrito e destacado em azul, P1, na terceira coluna 300, na quarta coluna 2,10 e na quinta coluna 630,00. Na
nona linha, temos na primeira coluna, em negrito e destacado em azul, S3, na segunda coluna, em negrito e destacado em azul, P2, na terceira
coluna 200, na quarta coluna 3,52 e na quinta coluna 704,00. Na décima linha, temos na primeira coluna, em negrito e destacado em azul, S4, na
segunda coluna, em negrito e destacado em azul, P2, na terceira coluna 200, na quarta coluna 3,49 e na quinta coluna 698,00. Na décima-primeira
linha, temos na primeira coluna, em negrito e destacado em azul, S4, na segunda coluna, em negrito e destacado em azul, P4, na terceira coluna
300, na quarta coluna 3,95 e na quinta coluna 1185,00. Na décima-segunda linha, temos na primeira coluna, em negrito e destacado em azul, S4,
na segunda coluna, em negrito e destacado em azul, P5, na terceira coluna 400, na quarta coluna 7,50 e na quinta coluna 3000,00. Na décima-
terceira linha, temos na primeira coluna, em negrito e destacado em azul, S2, na segunda coluna, em negrito e destacado em azul, P2, na terceira
coluna 400, na quarta coluna 3,50 e na quinta coluna 1400,00.

Observe que a última tupla (linha), que tem o id_forn “S5”, foi retirada, pois ela saiu integralmente para a relvar F.

Conclusão desta forma teremos então 3 relvars inicialmente para o

:

nosso Banco de Dados, que vão ser: F, P e E, que derivam de

Fornecedores, Peças e Estoque como definimos no modelo conceitual.
,

Para entendermos bem, vamos visualizar o DER que teríamos no modelo conceitual:

Figura 1: DER modelo conceitual. / Fonte : o autor.

#PraCegoVer – diagrama com 3 retangulos e 2 losangos em azul interligados. Da esquerda para a direita temos o primeiro retângulo, onde está
escrito fornecedor, com o número 1 do lado de fora no canto superior direito, ligado a um losango, onde está escrito fornece, que está interligado a

outro retângulo, com a inscrição estoque. Externamente a esse retângulo há duas letras N nos cantos superiores. Interligado ainda há um losango,
com a inscrição tem, ligado a um retângulo, onde está inscrito peças que tem o número 1, no canto superior esquerdo, externo ao retângulo.
Note que, mesmo fazendo alterações no modelo lógico, o modelo conceitual não sofre alterações, o que reforça o conceito de
independência entre as camadas da arquitetura do Banco de Dados.

Por último, de acordo com o que está definido por Date (2015), cada relvar deve ser capaz de preencher predicados com as
relações que ela possui. Desta forma, para validar essa regra teríamos:
relvar F: O Fornecedor id_forn é conhecido como nome_f está sediado em cidade que tem um status atual status.
,

relvar P:A peça id_peça é nomeada por nome_p tem, a cor cor e pesa peso gramas.
relvar E O fornecedor id_forn forneceu a peça id_peça com
: , a quantidade de qtde unidades, ao valor unitário de
vlr_unit gerando um valor total de estoque de vlr_total
, .

Ficou interessado(a) sobre esse tema? Clique no play, a seguir, e assista ao vídeo:

saiba aplicar
Com base nas 3 relvars finais que obtivemos da decomposição realizada, nós podemos validar se perdemos ou não
informações no nosso Banco de Dados. Para fazer uma validação simples, você consegue responder as perguntas abaixo?
 Quais são os nomes dos fornecedores da peça P2?
Quantas peças diferentes temos em estoque do fornecedor Jones ?

Quantas peças diferentes temos em estoque do fornecedor Adams?

Após a decomposição perdemos alguma informação do fornecedor
S5?
Caso eu retire o atributo vlr_total da relvar E, há perda de
informação?

RESPOSTAS
Pergunta 1: teremos que olhar a relvar E para fazer a relação entre F e P Desta forma, conseguimos ver que S1, S2, S3
. e S4
fornecem P2 e o nome deles, respectivamente, são: Smith, Jones, Blake e Clark.

Pergunta 2: teremos que observar quem é o fornecedor Jones na relvar F Conseguimos saber que a chave de acesso será S2
. ,

que vamos levar para a relvar E e encontrar as relações que S2 participa. Então, facilmente, conseguimos a resposta de que
Jones fornece apenas P1 e P2 ou seja, 2 peças.
,

Pergunta 3: segue a mesma lógica da pergunta anterior, porém, depois que identificamos a chave em F vemos que a relação
,

entre F e E vai dar um conjunto de dados vazio, ou seja, Adams S5 não forneceu produtos para o nosso estoque atual.
( )

Pergunta 4: dando sequência a pergunta 3, voltaremos ao fornecedor S5 e à relvar E original. Podemos observar que na relvar
E original não há informações sobre peças fornecidas por S5 logo, ao retirarmos S5 da relvar E (juntamente com as suas
,

dependências funcionais) não perdemos quaisquer informação, pois somente tínhamos originalmente os dados do fornecedor
S5 e nenhuma peça relacionada a ele.

Pergunta 5: a última resposta necessita de um entendimento da origem do dado, ou melhor, o atributo vlr_total é um campo
calculado, resposta da multiplicação dos atributos qtde e vlr_unit logo, caso eu retire esse atributo da relação, não
;

perderemos a informação, pois os atributos originais continuarão a fazer parte da relação, podendo recompô-la a qualquer
momento. Desta forma, é indicado que se retire esse atributo, pois, durante a programação, caso um desenvolvedor esqueça
de atualizar o campo, isso pode trazer falha de integridade na relação. Isso porque teremos dois valores distintos: um que
seria a multiplicação de qtde e vlr_unit e, em caso de esquecimento de atualização, vlr_total com um valor desatualizado ,

mas isso será assunto para nossa próxima lição.

Por enquanto, vamos encerrar por aqui, pois já demos um passo bem grande em direção ao entendimento da integridade do
Banco de Dados. Na próxima lição, vamos dar continuidade a este assunto, explicando a funcionalidade do que vimos, até
aqui, sobre o Banco de Dados Relacional e fechando as principais regras de integridade. Até a nossa próxima lição.

REFERÊNCIAS
DATE, CJ. Introdução aos Sistemas de Banco de Dados , 8ª Edição. São Paulo: GEN LTC, 2004.
DATE, CJ. Projeto de Banco de Dados e Teoria Relacional – Formas Normais e tudo mais . 1ª Edição. São Paulo: Novatec, 2015.

MENU PDF - VERSÃO DE IMPRESSÃO