Estamos imersos em um oceano de dados.
Ao simplesmente caminhar pelas ruas, geramos informações que alimentam uma vasta rede de bancos de dados globais. A conexão constante à internet permite que empresas monitorem nossos movimentos, nossas companhias, preferências, e até detalhes mais íntimos de nossas vidas. Esses dados revelam desde o esporte favorito até hábitos de mobilidade, preferências musicais, escolhas alimentares e de bebidas, e os serviços que utilizamos. Tudo isso compõe um perfil detalhado de consumidor, indicando nosso nível social, estado de saúde, entre outros aspectos.
Os dados são as novas commodities, comparados frequentemente ao petróleo em termos de valor. As empresas os buscam incansavelmente para compreender o que vender, como, para quem e em que momento.
Esses dados existem em diversos formatos e em volumes imensos. Atualmente, dispomos de múltiplas técnicas de armazenamento e análise de dados. Contudo, a necessidade de trabalhar com bancos de dados relacionais permanece essencial.
Bancos de dados relacionais organizam a informação de maneira estruturada, em um formato de linhas e colunas previamente definido e amplamente reconhecido. Neste sistema, campos específicos são preenchidos para compor tabelas com os dados relevantes. É provável que você já tenha interagido com um banco de dados relacional, seja através de uma instituição financeira ou no ERP da empresa onde trabalha. Quem nunca ouviu a frase: "Vamos verificar seu cadastro"?
O armazenamento de dados em tabelas é eficiente e organizado. As colunas representam diferentes atributos da informação, enquanto as linhas correspondem aos valores desses atributos, formando assim os registros.
A figura 1 mostra uma tabela:
1) Nome das colunas.
2) Destaque de um registro.
Figura 1 - Exemplo de uma tabela
Em um banco de dados, é crucial manter as informações distintas e organizadas. Cada categoria de dados é armazenada em tabelas separadas, prevenindo inconsistências e a mistura indevida de informações – como, por exemplo, confundir dados de clientes com os de fornecedores, ou associar pedidos a produtos não cadastrados.
Um banco de dados é formado pelo conjunto dessas tabelas.
Existem dois tipos principais de bancos de dados: OLTP (Online Transaction Processing) e OLAP (Online Analytical Processing).
Banco de Dados OLTP:
O OLTP é voltado para o processamento de transações em tempo real. Sua principal característica é a capacidade de gerir transações, que são qualquer tipo de alteração no banco de dados.
Exemplos de atividades transacionais incluem:
Reservas de voo
Compras de livros
Cadastro de pedidos e seus detalhes
Operações bancárias como saques, transferências e depósitos
Para suportar essas transações, é crucial que as tabelas sejam adequadamente modeladas. O processo de relacionar as tabelas corretamente é conhecido como 'Modelagem de Dados'. Dentro da modelagem de dados, temos a 'Modelagem Relacional' ou 'Modelagem Entidade-Relacionamento', aplicada em sistemas como ERPs e CRMs. Este processo, também chamado de Normalização de Dados, visa evitar a redundância. As transações são intensas e, ao atualizar um valor, o anterior é excluído.
Para assegurar a unicidade dos registros, usamos a 'Chave Primária' (Primary Key). Ao definir um campo como chave primária, garantimos que não haverá dois registros com o mesmo valor. Por exemplo, ao marcar o 'Número do CPF' em uma tabela de clientes como chave primária, estamos dizendo que cada cliente terá um CPF único.
Este conceito é vital, pois está diretamente ligado às noções de 'Integridade Referencial' e 'Normalização'.
A relação entre tabelas diferentes é estabelecida através de uma 'Chave Estrangeira' (Foreign Key). Visualmente, a chave primária é representada por um símbolo de chave e a chave estrangeira pelo símbolo do infinito.
Além disso, para assegurar a exclusividade de cada registro em situações mais complexas, podemos utilizar 'Chaves Primárias Compostas', formadas por mais de uma coluna.
Figura 2 - Diagrama com o relacionamento entre tabelas.
Relacionamento Entre Tabelas
Em um Banco de Dados Relacional existem diversas tabelas.
Embora as informações estejam separadas em cada uma das tabelas, devemos ter algum mecanismo que nos permita reunir dados de duas ou mais tabelas. Por exemplo, para fazer um relatório do total anual de vendas por funcionário, precisaremos de informações das tabelas “Funcionários”, “Pedidos” e “Detalhes do Pedido”.
O mecanismo que nos permite acessar, de maneira consolidada, dados de diversas tabelas é o “Relacionamento entre Tabelas”, que pode ser de três tipos:
Um para Um
Um para Vários
Vários para Vários
Relacionamento do Tipo Um para Um (1:1)
Esta relação existe quando os campos que se relacionam são ambos chaves primárias em suas respectivas tabelas.
Cada um dos campos não apresenta valores repetidos. Na prática existem poucas situações onde utilizaremos um relacionamento deste tipo.
Por exemplo, uma escola possui uma banda aonde uma pequena parte dos alunos participa desta atividade.
Por questões de projeto do Banco de Dados podemos optar por criar as tabelas “Alunos” e “Alunos da Banda”, que terão um relacionamento Um para Um. Cada aluno é cadastrado uma vez na tabela “Alunos” e uma vez na tabela “Alunos da Banda”.
Na tabela “Alunos” podemos colocar os campos “Matrícula do Aluno”, “Nome do Aluno”, “Data de Nascimento”, “Endereço”, etc., enquanto na tabela “Alunos da Banda” podemos colocar os campos “Matrícula do Aluno” e “Instrumento”.
Considere o exemplo da Figura 2.3.1, onde temos um relacionamento do tipo Um para Um entre as tabelas “Alunos” e “Alunos da Banda”.
Figura 3 - Relacionamento uma para um entre tabelas.
Relacionamento do Tipo Um para Vários (1:N)
Este relacionamento é o mais comum entre duas tabelas.
Uma das tabelas possui um campo que é a chave primária (Tipo Um do relacionamento) e a outra tabela se relaciona através de um campo cujos valores podem se repetir (Tipo Vários do relacionamento).
Considere o exemplo entre a tabela “Clientes” e a tabela “Pedidos”.
Cada cliente é cadastrado uma única vez na tabela “Clientes”, porém, cada cliente pode efetuar diversos pedidos de compra, podendo aparecer várias vezes na tabela “Pedidos”.
Por exemplo, o cliente cujo “Código do Cliente” é 5012 tiver feito 10 pedidos de compra, este código aparecerá em 10 registros diferentes na tabela “Pedidos”, enquanto será exibido uma única vez na tabela “Clientes”.
Considere o exemplo da Figura 4, onde temos um relacionamento do tipo Um para Vários entre as tabelas “Clientes” e “Pedidos”.
Figura 4 - Relacionamento do Tipo Um para Vários
Relacionamento do Tipo Vários para Vários (N:N)
Este tipo de relacionamento ocorre em uma situação onde, em ambos os lados do relacionamento, os valores podem se repetir.
Vamos considerar o caso entre as tabelas “Produtos” e “Pedidos”. Podemos ter vários pedidos nos quais aparece um determinado produto, além disso, vários produtos podem aparecer no mesmo pedido.
Esta é uma situação em que temos um relacionamento do tipo Vários para Vários.
Na prática não temos como implementar um relacionamento deste tipo, devido a uma série de problemas que este tipo de relacionamento traria (informações repetidas, inconsistência de dados e a junção de dois ou mais assuntos na mesma tabela).
Para evitarmos problemas, é muito comum “quebrarmos” um relacionamento do tipo Vários para Vários em dois relacionamentos do tipo Um para Vários. Isso é feito através da criação de uma nova tabela, a qual fica com tipo Vários dos relacionamentos. No nosso exemplo criaremos a tabela “Detalhes do Pedido”, onde ficam armazenadas as informações sobre os diversos itens de cada pedido.
Considere o exemplo da Figura 5, onde temos um relacionamento do tipo Vários para Vários entre as tabelas “Produtos”, “Detalhes do Pedido” e “Pedidos”.
Figura 5 - Relacionamento do Tipo Um para Vários
Integridade Referencial
A Integridade Referencial é utilizada para garantir a consistência dos dados entre as diversas tabelas relacionadas em um banco de dados.
Por exemplo, existe um relacionamento do tipo Um para Vários entre a tabela “Clientes” e a tabela “Pedidos” (um cliente pode fazer vários pedidos).
Com a Integridade Referencial, o Banco de Dados não permite que seja cadastrado um Pedido para um Cliente que ainda não foi cadastrado na tabela de Clientes. Também podemos garantir outros mecanismos importantes:
Quando o código de um cliente for alterado na tabela “Clientes”, o Banco de Dados atualiza automaticamente todos os Códigos do Cliente na tabela “Pedidos”, de tal maneira que não fiquem registros órfãos, isto é, registros de pedidos com um código de cliente que não existe mais na tabela “Clientes”;
Quando um cliente for excluído da tabela “Clientes”, podemos solicitar que o Banco de Dados exclua da tabela “Pedidos” todos os pedidos para o cliente que está sendo excluído.
Essas opções são definidas no momento da criação do Banco de Dados, quando da criação das tabelas e dos relacionamentos entre as tabelas.
A opção de atualização dos campos relacionados é utilizada na maioria das situações, já a opção de exclusão dos registros relacionados deve ser estudada caso a caso.
Normalização de Dados
Normalização de dados é o processo formal e passo a passo que examina os atributos de uma tabela, com o objetivo de evitar ou corrigir erros antes da criação e utilização do banco de dados. É bem mais simples corrigir os erros na fase de projeto do que depois que o banco de dados já está em utilização.
Uma “Regra de Ouro” que devemos observar quando do projeto de Banco de Dados é a de “não misturar assuntos em uma mesma Tabela”, conforme já descrito anteriormente.
O processo de Normalização aplica uma série de regras sobre as tabelas de um Banco de Dados, para verificar se estas estão corretamente projetadas. Embora existam cinco Formas Normais (ou regras de Normalização), na prática usamos um conjunto de três Formas Normais.
Frequentemente, após a aplicação das regras de Normalização, algumas tabelas acabam sendo divididas em duas ou mais, o que no final gera um número maior de tabelas do que originalmente projetado. Este processo causa a simplificação dos atributos de uma tabela, colaborando significativamente para a estabilidade do projeto do banco de dados, reduzindo-se as necessidades de manutenção e alterações, após o banco ter sido colocado em produção.
Vamos estudar e entender o processo de Normalização através de exemplos práticos.
Primeira Forma Normal
Uma tabela estará na Primeira Forma Normal (1FN) se não houver grupo de dados repetidos, isto é, se todos os valores forem únicos. Em outras palavras podemos definir que a primeira forma normal não admite repetições ou campos que tenha mais que um valor.
Os procedimentos mais recomendados para aplicar a 1FN são os seguintes:
Identificar a chave primária da tabela;
Identificar o grupo repetitivo e removê-lo da tabela;
Criar uma nova tabela com o grupo repetitivo e a chave primária da tabela anterior.
Considere o exemplo da Figura 6, onde temos a tabela “Clientes” Não Normalizada.
Figura 6 - Exemplo da Tabela “Clientes” Não Normalizada
Todos os clientes possuem Logradouro, Bairro, Cidade, Estado e CEP e estas informações estão na mesma célula da tabela, logo ela não está na 1FN. Para normalizar, deveremos colocar cada informação em uma coluna diferente, como no exemplo da Figura 7.
Figura 7 - Exemplo da Tabela “Clientes” que ainda não está na Primeira Forma Normal.
Mesmo com o ajuste acima, a tabela “Clientes” ainda não está na 1FN, pois há clientes com mais de um telefone e os valores estão em uma mesma célula. Para normalizar será necessário criar uma nova tabela para armazenar os números dos telefones e o campo-chave da tabela cliente.
Considere o exemplo da Figura 8, onde temos as tabelas “Clientes” e “Telefones do Cliente” na 1FN.
Figura 8 - Exemplo das Tabelas “Clientes” e “Telefones do Cliente” na Primeira Forma Normal.
Segunda Forma Normal
Uma tabela está na Segunda Forma Normal (2FN) se ela estiver na 1FN e todos os atributos não chave forem totalmente dependentes da chave primária (dependente de toda a chave e não apenas de parte dela).
Se o nome do produto já existe na tabela produtos, então não é necessário que ele exista na tabela de produtos. A segunda forma normal trata destas anomalias e evita que valores fiquem em redundâcia no banco de dados.
Os procedimentos para aplicar a 2FN são os seguintes:
Identificar os atributos que não são funcionalmente dependentes de toda a chave primária;
Remover da tabela todos esses atributos identificados e criar uma nova tabela com eles.
Considere o exemplo da Figura 9, onde temos a tabela “Pedidos” que não está na 2FN.
Figura 9 - Exemplo da Tabela “Pedidos” que ainda não está na Segunda Forma Normal
Analisando a tabela “Pedidos”, veremos que o “Nome do Produto” depende do “Código do Produto”, porém não depende de “Número do Pedido” que é a chave primária da tabela, portanto, não está na 2FN. Isto gera problemas com a manutenção dos dados, pois se houver alteração no nome do produto teremos que alterar todos os registros da tabela “Pedidos”:
Para normalizarmos esta tabela teremos de criar a tabela “Produtos”, que ficará com os atributos “Código do Produto” e “Nome do Produto”, enquanto que na tabela “Pedidos” manteremos somente os atributos “Número do Pedido”, “Código do Produto”, “Quantidade”, “Valor Unitário” e “Valor Total”.
Figura 10 - Exemplo das Tabelas “Pedidos” e “Produtos” na Segunda Forma Normal
Terceira Forma Normal
Terceira Forma Normal
Uma tabela está na Terceira Forma Normal (3FN) se ela estiver na 2FN e se nenhuma coluna não-chave depender de outra coluna não-chave, em resumo, temos de eliminar aqueles campos que podem ser obtidos pela equação de outros campos da mesma tabela.
Os procedimentos para aplicar a 3FN são os seguintes:
Identificar todos os atributos que são funcionalmente dependentes de outros atributos não chave;
Removê-los.
Considere o exemplo da Figura 11, onde temos a tabela “Pedidos” que não está na 3FN.
Figura 11 - Exemplo da Tabela “Pedidos” que ainda não está na Terceira Forma Normal.
Considerando ainda a tabela “Pedidos”, veremos que a mesma não está na 3FN, pois o “Valor Total” é o resultado da operação “Quantidade * Valor Unitario”, desta forma a coluna “Valor Total” depende de outras colunas não-chave.
Para normalizar esta tabela na 3FN, teremos de eliminar a coluna “Valor Total”, como no exemplo da Figura 12.
Figura 12 - Exemplo da Tabela “Pedidos” na Terceira Forma Normal
Concluindo...
Este artigo apenas fomentou sua motivação para começar a estudar banco de dados. Em breve teremos mais artigos mostrando esse fascinante mundo.