PDF - VERSÃO DE IMPRESSÃO

LIÇÃO 3 - Relações x Variável de Relação (relvars)

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.

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.

De acordo com CJ Date, no 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 é 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_mes. 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.

Ou seja, 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.

Como funciona o ETL em Data Warehouse?

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 2 - 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, chamaremos 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, consideraremos 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 à 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 denominaremos 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, descartaremos o conjunto nome_f, nome_p e elegeremos id_forn, id_peça como chave primária nessa relação.

Reordenando os atributos (colunas) em nossa relação, teremos agora o par id_forn, id_peça como chave primária, ou seja, o conjunto de atributos que identifica de forma única cada tupla (registro) em 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, abaixo:

Tabela 4 - 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, abaixo:

Tabela 5 - 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 5 - 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, elas derivam de Fornecedores, Peças e Estoque, como definimos no modelo conceitual.

Para entendermos bem, visualizaremos 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 CJ Date, 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.

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: vamos ter 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: vamos ter 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, vamos voltar ao fornecedor S5 e a 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 atribuitos 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, pois teremos dois valores distintos: um que seria a multiplicação de qtde e vlr_unit e, em caso de esquecimento de atualização, e 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 neste assunto, explicando a funcionalidade do que vimos até aqui dentro do 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

Page updated

Google Sites

Report abuse