[Com o crescente mercado de dispositivos computacionais sejam eles computadores, celulares, tablets ou outros dispositivos e com a disponibilidade de comunicação praticamente em tempo real através de redes de dados e da internet, o gerenciamentos de grandes volumes de dados dos mais diversos tipos se tornou a espinha dorsal dos sistemas de informação. Para auxiliar essas tarefas é que existem os SGDBs ou Sistemas Gerenciadores de Bancos de Dados, e este artigo visa apresentar alguns conceitos comuns a muitos deles, vamos lá…
Na atualidade, podemos afirmar categoricamente que a informação é o bem mais valioso de todos os segmentos de empresas e instituições ao redor do mundo, e administrar esses dados e gerenciar quem pode acessar ou manipular eles é uma das atividades que tem tido o maior crescimento de vagas e de salários no mercado. Porém, não é uma tarefa simples, pois garantir a segurança dos dados e a obtenção de resultados pode ser tanto o super trunfo de uma empresa como seu maior pesadelo levando ao fracasso. Por este motivo, inúmeros sistemas são especializados em auxiliar os profissionais e empresas no gerenciamento dessas enormes bases de dados, dos mais diversos tipos.
Os sistemas de bancos de dados, podem ser basicamente de 3 tipos, sendo que cada um possui responsabilidades e aplicações diferentes, o que nos interessa mais neste artigo são os do tipo BASES DE DADOS RELACIONAIS, que falaremos mais detalhadamente nas próximas seções. Já, os outros dois tipos vamos só dar uma explicação rápida pois serão temas de outros artigos.
Bancos de Dados Baseados em Arquivos (Imagem, Audio, Texto)
São bases de dados, baseadas no histórico e versionamento de arquivos binários ou conteúdos de texto, podem ser dos mais variados tipos, dois bons exemplos desse tipo de conteúdo são os serviços de Storage de dados como Google Docs, Google Drive, DropBox e uma centena de outros, geralmente se caracteriza não somente por um sistema centralizado mais um conjunto de ferramentas que permite manter o histórico de alterações de um determinado conteúdo no decorrer do tempo.
Um dos softwares que trouxe um grande avanço, principalmente no gerenciamento de conteúdos de texto, é o GIT, que é uma base de dados de conteúdos textuais que possui grandes recursos, principalmente no controle de versões e modificações em decorrer do tempo, permitindo de maneira simples um controle total sobre o versionamento.
Bancos de Dados Baseados em Documento (NOSQL)
São os mais novos no quesito idade, e são bases de dados baseadas em estruturas hierárquicas, que possuem algum tipo de similaridade entre sí, e se relacionam de alguma maneira com o todo. Diversos sistemas vem se tornando especialistas no gerenciamento destes tipos de dados.
O nome NOSQL diferente do que muitos pensam, significa em livre tradução, Não somente SQL, ou seja, ele vai um pouco além das bases relacionais, pois suas estruturas não são rígidas como as bases relacionais, porém, são agrupadas por similaridade e estruturada dessa mesma maneira.
Sua principal característica é a estrutura de GRAFOS que são estruturas matemáticas usadas para modelar relações de pares entre objetos, neste contexto, é composto de vértices (nós ou pontos) que são conectados por arestas (também chamados de links ou linhas). Na verdade existe todo um campo de estudo da matemática dedicado a essas estruturas. Mais o que nos interessa é que percebeu como elas se relacionam muito aos documentos baseados em hipertexto, e internet…. (mais são só cenas para os próximos capítulos).
Outras ferramentas nessa categoria são especializados em busca de texto (FTS – Full Text Search) que usa analise léxica para tokenização e ganho de performance e escalabilidade entre outras características que vem tornando esse tipo de mecanismo de armazenamento um grande diferencial se usado dentro das medidas e especificações corretas.
Bases de Dados Relacionais (SGDBS e SQL)
São as bases de dados mais tradicionais e mais amplamente utilizadas, armazenam os dados em formatos de tabelas, onde cada linha representa um registro, e deve ser identificada de maneira exclusiva por uma ou mais de suas colunas, a essa identificação damos no nome de chave primária, e esta tabela pode se relacionar com outras através da relação de similaridade de suas colunas, a essa relação que se dá pelo que chamamos de chaves estrangeiras.
Para garantir que os dados sejam sempre precisos e acessíveis, os bancos de dados relacionais seguem determinadas regras de integridade. O modelo relacional fornece uma maneira padrão de representar e consultar dados que poderiam ser usados por qualquer aplicativo e que todos que precisem acessar esses dados mantenham sua integridade, além de otimizarem a forma como estes são organizados e acessados.
O SQL (Structured Query Language – Linguagem de consulta estruturada) é a forma que a maioria dos SGDBs usa para extrair os dados, é uma linguagem baseada em álgebra relacional, que fornece uma forma matemática consistente, que melhora o desempenho das consultas e otimiza a estrutura de organização e acesso aos dados.
A consistência dos dados
O modelo relacional é o melhor em manter a consistência de dados entre aplicativos e cópias de banco de dados (chamadas de instâncias). É difícil para outros tipos de bancos de dados manter esse nível de consistência oportunamente com grandes quantidades de dados.
Os bancos de dados relacionais, lidam com regras e políticas de negócios em um nível muito granular, com políticas rígidas sobre compromisso em manter, as transações de dados, isso é feito pelas 4 propriedades essenciais que definem um banco relacional: atomicidade, consistência, isolamento e durabilidade, normalmente referidos como ACID.
A atomicidade define todos os elementos que compõem uma transação completa do banco de dados. Consistência define as regras para manter os pontos de dados em um estado correto após uma transação. Isolamento mantém o efeito de uma transação invisível para outras pessoas até ser confirmada, para evitar confusão. E durabilidade garante que as alterações de dados se tornem permanentes quando a transação for confirmada.
Os conflitos podem surgir em um banco de dados quando vários usuários ou aplicativos tentam alterar os mesmos dados ao mesmo tempo. Técnicas de bloqueio e simultaneidade reduzem o potencial de conflitos, mantendo a integridade dos dados.
Para garantir a consistência e qualidade outras medidas devem ser tomadas, alguns dos erros mais frequente são causados por dados incoerentes, se o banco de dados for projetado adequadamente, a ocorrência de dados incoerentes será pequena ou nula, sendo mais provável nesses casos dados digitados ou imputados com erros de grafia ou incorretamente, números trocados ou códigos faltantes, ocorre durante a entrada de dados, esses erros ficam mais comuns quando as empresas transferem parte dos seus dados para a Internet, e permite que clientes e fornecedores insiram seus dados no site e isso resulte em alterações no sistema interno. Os problemas com qualidade de dados não são só empresariais, eles também representam sérios problemas às pessoas, afetando sua condição financeira e até mesmo sua integridade moral, uma boa politica de dados garante que essas falhas sejam mitigadas.
As regras do jogo
Para que essa estrutura funcione perfeitamente, os administradores de bancos de dados, ou seja, os responsáveis pela criação das bases e administração dos softwares e servidores de bancos de dados devem seguir algumas regras, nas bases de dados relacionais essas regras recebem o nome de FORMAS NORMAIS e tem o objetivo de evitar falhas no projeto dessa base de dados, como redundância e mistura de diferentes conteúdos, bem como existem também as CHAVES que são colunas especialmente marcadas para permitir o relacionamento e filtragem correta de uma tabela com as demais, de maneira direta ou indireta.
AS CHAVES – Chave Primária, Chave Estrangeira, Chave Única, etc
OBS: Antes de mais nada, vamos falar de maneira genérica, como essa estrutura é implementada tecnicamente, lembrando que alguns SGDBs podem possuir recursos mais avançados ou mais eficientes para um determinado propósito, como permitir tipos de dados diferentes, e implementações diferentes, como chaves primárias em múltiplas colunas, outras formas de relacionamentos indiretos e associações, em outras oportunidades podemos estudar de maneira mais específica cada uma e sua aplicabilidade.
As bases de dados relacionais são organizadas em uma estrutura que se parece com um conjunto de tabelas, onde cada tabela é conhecida como ENTIDADE, a tabela é formada por um conjunto de colunas que são denominadas ATRIBUTOS, esses por sua vez, são sempre de um mesmo formato lógico, ou seja, possuem um TIPO DE DADO, um TAMANHO, e algumas informações especiais como serem partes de uma chave, ou serem parte de um índice, entre outros dados, veja um exemplo de tabela:
| ATRIBUTO1 | ATRIBUTO2 | ATRIBUTO3 | ….. OUTRAS COLUNAS OU ATRIBUTOS |
| R1 A1 | R1 A2 | R1 A3 | R1 Ax |
| R2 A1 | R2 A2 | R3 A2 | R2 Ax |
Veja, no exemplo acima, a TABELA ou ENTIDADE, possui um conjunto de ATRIBUTOS cada um agrupado na forma de uma COLUNA, por exemplo a coluna em ROSA identifica o ATRIBUTO1 que é nossa chave primária, cada uma das LINHAS identifica um REGISTRO. Vamos colocar dados mais reais nessa mesma tabela para facilitar a visualização e identificação:
| ID DE CLIENTE | NOME DO CLIENTE | TELEFONE DO CLIENTE | ENDEREÇO COMPLETO DO CLIENTE |
| 1 | Fulano de tal | 11 99999-9999 | Rua dos abacaxis, 200 |
| 2 | Ciclano da Silva | 21 3333-3333 | Rua do grito, SEM NÚMERO |
A primeira vista, essa tabela é um exemplo clássico, porém, contém erros, que vamos discutir mais a frente, porém, seu ID é a chave primária, ou seja, ela é a única para identificar cada registo, ou seja, o valor 1 não se repete e nunca poderá se repetir. Veja que todas as colunas devem possuir dados que identifiquem uma mesma informação, ou seja a coluna nome vai conter o nome em todos os registros, e devem ser de um mesmo tipo de dados, e podem conter outras informações como serem obrigatórios, por exemplo, para que exista um cliente ele deve ter um nome, mais pode não ter um telefone, para essas classificações é que cada um desses atributos possui as regras, que são colunas chave nessa estrutura, vamos ver as principais e comuns a todos os bancos de dados.
Como seu nome diz, as CHAVES são colunas especiais, existentes na tabela, que tem a função de fazer com que os relacionamentos funcionem, e que o SGDB possa validar ANTES de aceitar um registro, para garantir a integridade dos dados armazenados, que possa gerar resposta e acessar outras tabelas relacionadas de maneira rápida e simples, essas chaves são classificadas pelo seu tipo e conteúdo, e possuem algumas regras, vamos entender cada uma delas.
CHAVES PRIMÁRIAS – Como explicado anteriormente, é uma chave que identifica um determinado registro dentro da tabela, ou seja, ela nunca se repete dentro daquela tabela, é uma boa prática que ela seja numérica, pois é o tipo de dado mais fácil para ser comparado e indexado, gerando melhores tempos de resposta do sistema. Via de regra, ela deve existir em todas as tabelas, e ela que servirá de base para outras tabelas se relacionarem a esta no modelo de entidade relacionamento. Uma vez definida ela não pode ser vazia ou nula, e o próprio mecanismo do SGDB cria um índice para ela.
CHAVES ESTRANGEIRAS – É a chave primária de uma tabela, dentro de outra tabela, por exemplo, no nosso exemplo anterior, o que aconteceria se uma determinada pessoa tivesse mais de um telefone? Para garantir a integridade do banco de dados, seria criada uma segunda tabela para armazenar os telefones, e a nossa estrutura ficaria mais ou menos assim:
| ID DE CLIENTE | NOME DO CLIENTE | ENDEREÇO COMPLETO DO CLIENTE | |
| 1 | Fulano de tal | Rua dos abacaxis, 200 | |
| 2 | Ciclano da Silva | Rua do grito, SEM NÚMERO |
Removemos a coluna de TELEFONE da tabela anterior e criamos uma especifica para armazenar os telefones, com a estrutura abaixo:
| ID DO TELEFONE | ID DO CLIENTE | TELEFONE |
| 1 | 1 | 11 99999-9999 |
| 2 | 1 | 11 2222-2222 |
| 3 | 2 | 21 3333-3333 |
Desse modo, pelo ID do cliente é possivel relacionar as duas tabelas, e identificar que o cliente 1 possui 2 números de telefone. Ou seja, a chave estrangeira da tabela TELEFONES é obrigatoriamente uma chave primária da nossa outra tabela CLIENTES. Esse é o conceito que permite que os dados se relacionem entre as tabelas, e também que garante a integridade dos dados, pois podemos usar de outros tipos de chaves, por exemplo, ao determinar que essa é uma chave estrangeira, o próprio SGDB não permitiria que um registro de telefone fosse inserido, com o ID DO CLIENTE de numero 3, se esse não estivesse previamente inserido na tabela cliente.
As chaves estrangeiras, quando bem definidas garantem a propagação de exclusões e atualizações, garantindo que os dados inseridos respeitem as necessidades do projeto como determinadas pelo criador da base de dados. Ou seja, ao excluir um registro de clientes poderíamos propagar a exclusão de todos os registros de telefones pertencentes a esse cliente.
CHAVES ÚNICAS – Chaves únicas, são um conjunto de colunas (atributos) que identificam de maneira única um registro, por exemplo, podemos definir que RG e CPF são juntas a chave única da nossa tabela clientes, visto que tanto o RG quanto o CPF podem se repetir, porém, seria impossível para o cadastro de dados que ambos os documentos juntos se repitam, em resumo, podemos ter 2 registros com o RG iguais, e CPF diferentes, um de João da Silva outro de José Dos Santos por exemplo, só que com o mesmo RG e CPF nenhum registro pode existir. As chaves únicas diferem das chaves primárias, pois geralmente são compostas, e tem mais importância para a garantia da qualidade dos dados do que para funcionamento do mecanismo de banco de dados propriamente dito.
OS RELACIONAMENTOS
Como o próprio nome já diz, relacionamentos são a base os bancos de dados, é através deles que podemos agrupar os dados de maneira eficientes, dai, vem o conceito de CARDINALIDADE, ou seja, quais os limites mínimos e máximos para que o relacionamento funcione, a regra para identifica-los geralmente é a permissividade de registros em uma e na outra tabela os relacionamentos entre tabelas possui uma notação, eles podem ser unários ou múltiplos, um relacionamento unário, indica que um dado de uma tabela só pode se relacionar com 1 dado da outra tabela. Já nos relacionamentos múltiplo, um registro na tabela 1 pode ter vários registros na tabela 2. Vamos voltar ao nosso exemplo:
1 CLIENTE, pode ter N TELEFONES, ou seja é um relacionamento de 1:N e no diagrama de dados é representado por este desenho da figura ao lado esquerdo, ou seja, o lado das muitas pontas, indica que o cliente pode ter vários registros na tabela 2.
Em outra situação, temos dados onde o registro só pode ter 1 registro relacionado entre a tabela 1 e a tabela 2, por exemplo, nosso quadro de funcionários, um departamento tem 1 gerente, e cada gerente gerencia 1 departamento, isso é a regra para esta situação de negócio, ou seja, é a regra desta empresa, e os dados só estão válidos se atenderem esse requisito, de que um gerente não pode ter mais de 1 departamento, nem um mesmo departamento ter mais de um gerente.
O terceiro tipo de relacionamento pode ocorrer fisicamente, porém, quando ocorre fisicamente é necessário a criação de uma terceira tabela, chamada de tabela verdade ou tabela auxiliar ou tabela associativa e veremos adiante como ela é composta, o que ocorre é que como no exemplo, um banco de dados de registro das vendas, a mercadoria, pode ser vendida em diversos pedidos, e um mesmo pedido, pode ter mais de uma mercadoria, neste caso, a regra dos bancos de dados define que temos que ter uma tabela para permitir essa associação ou tornar essa relação verdadeira ou direta, desse modo, podemos chegar de um lado para outro, através de uma consulta ao banco de dados. Por exemplo, se escolhermos uma mercadoria X específica, podemos saber quantos pedidos tem essa mercadoria, e também, dado um pedido Y, quais mercadorias o compõem.
Para finalizar existem os AUTO RELACIONAMENTOS onde um item é relacionado com um próprio item da mesma tabela, este tipo de relacionamento é muito usado em estruturas onde pode ocorrer a recursividade, por exemplo uma tabela de itens de menu, podem ser tanto um único item, como serem filhos de outro item da mesma tabela, e estes também podem ser 1:1, ou 1:N e novamente lembramos que se ocorrer uma situação onde pode haver N:N é necessária também a criação de uma Tabela Auxiliar. Exemplos clássicos desse tipo de tabela, são produtos compostos, como em um supermercado as cestas básicas, onde na verdade um item (a cesta) é a explosão de uma série de itens diferentes (componentes) ou em controle de estoque de restaurantes, ou de fábricas, onde um item acabado, pode baixar diversos itens da montagem, que também podem ser vendidos em separado, e outras situações similares.
CARDINALIDADE, todos os relacionamentos possuem uma regra de existência, para a validação dos dados, além da relação ou seja quantos registros podem se relacionar entre uma tabela e outra, a cardinalidade indica os limites mínimos desses relacionamentos e podem ser 0 (zero), 1 (um) ou N (muitos), ou seja, aplicando este conceito nos exemplos anteriores, temos que, no primeiro exemplo, os clientes podem ou não ter telefone ou seja, pode existir um registro de cliente, sem existir um relacionado de telefone. Porém, não pode existir um registro na tabela de telefones sem que exista um cliente. No modelo ENTIDADE RELACIONAMENTO, são representados por parentes do lado da entidade e dentro destes parentes, são colocados os limites dos dois lados, sendo o primeiro numero o da tabela principal e o da esquerda o da tabela que recebe a chave estrangeira.
Por exemplo, um CLIENTES (0,N) e TELEFONES (1,1) indica que o cliente pode ter nenhum ou muitos telefones, e que o telefone tem que obrigatoriamente ter 1 cliente. Quando fazemos essas definições, conseguimos enxergar as regras claramente, na criação das tabelas físicas no banco de dados, fica claro que que na tabela de telefones o ID do cliente é um dado obrigatório.
MODELAGEM DO BANCO DE DADOS – FORMAS NORMAIS
A modelagem ou projeto do banco de dados é uma importante etapa do processo, uma base de dados bem projetada, garante a integridade dos dados, e também o perfeito relacionamento sem causar dependências ou desatualização de dados não obrigatórios, refletindo com exatidão as necessidades dos usuários desses dados. Para realizar essa modelagem com precisão, é necessário um levantamento dos dados junto com os usuários desses dados e em contra partida com os analistas de negócios da empresa e analistas de sistema para verificar todas as necessidades e politicas de acesso a essa massa de dados.
Neste processo são levantados as necessidades estruturais (tabelas e atributos) e também as necessidades de validação (regras de negócio) além de identificar os relacionamentos e criar as chaves necessárias, e normalizar esses dados, fazendo-os estarem moldados dentro da estrutura do SGDB que será utilizado, com os tipos de dados corretos e funcionais. Para isso, o Analista de Dados ou algum outro nome que tenha sido dado para o profissional responsável pelo banco de dados, tem a mão as famosas FORMAS NORMAIS, que são na verdade regras para avaliar e verificar se os dados encontrados nas tabelas atendem os requisitos principais. As básicas são 3, que já garantem o perfeito funcionamento, porém, em casos mais específicos outras regras podem ser usadas, e vamos falar delas a seguir.
Para aplicar essas regras, dadas a ideia inicial das entidades e de seus atributos, vamos percorrer cada uma delas, aplicando as regras na ordem que são definidas, ou seja, primeiro aplicamos a 1FN em todas as tabelas, para depois aplicar a 2FN também em todas as tabelas, e assim sucessivamente, lembrando que se em uma etapa posterior a regra aplicada exigir uma criação de tabela, devemos aplicar as regras anteriores também nessa tabela criada, isso garante que um modelo só esta por exemplo na 3FN se estiver também na 2FN e na 1FN.
1FN – Primeira Forma Normal – Atomicidade, dependências multivaloradas
ATOMICIDADE, essa primeira forma normal, garante que cada atributo, só possa ter um único valor possível para cada registro para estar presente, quando encontramos um atributo que não satisfaz essa situação, criamos uma segunda tabela, contendo no mínimo o dado que se repete na tabela principal e a chave primária exportada como chave estrangeira. Vamos tomar como exemplo novamente nosso conceito original de cadastro de clientes:
CLIENTE = {ID, NOME_COMPLETO, CPF, RG, TELEFONE, ENDEREÇO_COMPLETO} – Ao analisar, vemos que 2 colunas podem ter mais de um valor, o TELEFONE e o ENDEREÇO já que um cliente pode ter mais de 1 telefone e também mais de 1 endereço, após aplicar a 1FN temos a criação de 2 tabelas auxiliares, ficando:
CLIENTE = {ID, NOME_COMPLETO, CPF, RG} e TELEFONE = {ID, ID_CLIENTE, TELEFONE} e também ENDEREÇO = {ID, ID_CLIENTE, ENDEREÇO_COMPLETO}
Essa forma normal, garante que nenhum dado multivalorado fique presente nas tabelas, o que impediria uma expansão futura ou uma correta localização dos dados, ou mesmo dependências de dados desencontradas entre as diversas partes do projeto. A pergunta chave, que essa FN responde é “A ENTIDADE X, poder ter QUANTOS DO ATRIBUTO Y” se a resposta for mais de 1, esse dado não esta na 1FN e a regra deve ser aplicada. Ou seja, devemos questionar cada campo da tabela para saber se ele é ou não repetitivo. Após aplicada, todos os registros da tabela contém exatamente o mesmo número de campos.
2FN – Segunda Forma Normal – Dependência da Chave Primária ou Chave Única
Esta forma normal, garante que todos os campos não chave dependam exclusivamente do campo chave para serem existentes (quando a chave primaria é composta, eles devem depender de todo o conjunto de campos) e não somente de uma parte dele.
Quando dizemos que ela está na 2FN damos a garantia que quando temos uma chave única ou chave primária, todos os atributos dependam exclusivamente dela para existirem na tabela, ou seja, garante que todos os atributos não chave, dependam da chave da tabela para serem identificados ou existentes. Quando encontramos um campo não dependente, devemos remover e criar uma tabela auxiliar contendo, pelo menos esse dado. Veja, no exemplo anterior, uma das tabelas resultantes foi a tabela de ENDEREÇOS = {ID, ID_CLIENTE, ENDEREÇO_COMPLETO}, note que ENDEREÇO COMPLETO é um campo composto por um logradouro (rua ou avenida) e um número, além de um bairro ou distrito, uma cidade e um estado ou mesmo um pais, são diversos dados juntos, que não são dependentes entre sí, então, vamos decompor essa tabela em campos separados para fazer uma analise:
ENDEREÇO = {ID, ID_CLIENTE, TIPO_LOGRADOURO, LOGRADOURO, NUMERO, BAIRRO, CIDADE, DISTRITO, PAIS, CEP} – Tabela com o endereço (campo que era composto de vários dados, já decomposta)
Note que os campos TIPO LOGRADOURO, LOGRADOURO, CIDADE, DISTRITO, PAIS e CEP não dependem exclusivamente da chave (ID e ID_CLIENTE) para existirem então, para colocar essa tabela na 2FN, devemos mover esses dados para uma tabela AUXILIAR, e criar na tabela onde elas existiam uma chave estrangeira para elas, e mover todos os dados não dependentes para outra tabela, ficamos com:
ENDEREÇOS {ID, ID_CLIENTE, NUMERO, ID_LOGRADOURO) / LOGRADOUROS = {ID_LOGRADOURO, TIPO LOGRADOURO, LOGRADOURO, BAIRRO, CIDADE, DISTRITO, PAIS, CEP}
Note, que devemos aplicar a tabela criada, as dependências da 1FN neste caso específico a tabela resultante também atende a ela, e vamos novamente aplicar a 2FN nesta tabela resultante, identificamos que o campo TIPO_LOGRADOURO (RUA, AVENIDA, ALAMEDA) se repete, e não depende de ID_LOGRADOURO para ocorrer, para concluir essa 2FN devemos novamente re-fatorar essa tabela, criando uma tabela auxiliar TIPO_LOGRADOURO e assim sucessivamente até que todas as tabelas resultantes estejam na 2FN. Somente podemos dizer que nosso banco de dados está na 2FN se todas as tabelas existentes e também as criadas na aplicação da 1FN e da 2FN estiverem satisfazendo os requisitos.
OBS: Neste momento, o exemplo da tabela LOGRADOUROS é ilustrativo, e existem ainda mais dados que quando passarmos para uma nova analise serão alterados e excluídos, como o exemplo aqui é ilustrativo, ao percorrer as tabelas existente, você verá que outros campos como CEP, BAIRRO, CIDADE, DISTRITO, PAIS serão movidos e re-fatorados para que o resultado de todos os dados esteja na 2FN.
3FN – Terceira Forma Normal – Dependência Transitória
Esta forma normal, lembra muito a definição da segunda, pois garante que os campos não sejam interdependentes, ou seja, o resultado de um calculo ou uma forma de associação diversa, em resumo, quando um campo não depende totalmente da chave única ou da chave primária para existir, nem pode ser recriado a partir de outros dados. Por exemplo:
PEDIDOS = {ID, ID_CLIENTE, ID_VENDEDOR, DATA, FRETE, DESCONTOS, TOTAL_GERAL} / ITENS_PEDIDO = {ID, ID_PEDIDO, ID_PRODUTO, QUANTIDADE, TOTAL} / PRODUTOS = {ID, DESCRICAO, VALOR}
Veja, para a segunda FN estas tabelas estão em conformidade, porém na 3FN verificamos que ITENS_PEDIDO.TOTAL é um resultado de calculo, proveniente de PRODUTO.VALOR * ITENS_PEDIDO.QUANTIDADE neste caso, para esta tabela se enquadrar na 3FN, devemos remover essa coluna e recria-la usando as formulas de calculo, pois, se em algum momento algum valor da tabela PRODUTOS for alterado, teremos que percorrer a tabela de PEDIDOS ITEM e atualiza-la.
CONCLUSÃO
Neste ponto, quando uma base de dados já está na 3FN ela pode ser colocada em produção, num proximo artigo, vamos falar sobre as situações especiais, e sobre outras formas normais como 4FN, 5FN, 6FN e BOYCE que tem funções específicas e também sobre DESNORMALIZAÇÃO onde em situações extremas, podemos melhorar a performance quando temos alguma entidade fora da estrutura tradicional, ou situações onde não é possível representar os dados dessa maneira estruturada e resolvemos utilizar outras técnicas de bancos de dados.
