Artigos Banco de Dados Modelagem relacional e normalização de dados

Por que eu devo ler este artigo:A normalização de dados, às vezes, é vista como algo complicado no processo de modelagem relacional. Neste artigo veremos como funcionam as Formas Normais na prática, quais os conceitos teóricos envolvidos na normalização e, principalmente, quais vantagens sua utilização pode trazer para o banco de dados em produção.

Veremos também algumas dicas práticas de projeto físico de um modelo normalizado. Este artigo é útil em casos de modelagem de dados, onde o analista deseja garantir que seu modelo se enquadra no padrão ACID (Atomicidade, Consistência, Isolamento, Durabilidade) e mostra também como esse conceito, dentro da teoria de bancos de dados, pode ajudar o analista de dados a obter ganhos de armazenamento e desempenho em seu banco de dados.

O artigo intitulado “A Relational Model of Data for Large Shared Data Banks” - Um modelo relacional de dados para grandes bancos de dados compartilhados (em tradução livre), definiu as Relações que deram origem às entidades e as tabelas que usamos hoje em dia, definiu as propriedades que uma linguagem de manipulação de dados deveria apresentar e definiu também, o que hoje conhecemos como Primeira Forma Normal.

Isso tudo numa época onde o armazenamento de dados era um desafio, o acesso a computadores era muito menor, o hardware era muito mais modesto e caro do que hoje e os bancos de dados da época utilizavam modelos não relacionais, como o modelo hierárquico.

Nos anos seguintes, Codd ainda viria a publicar outros artigos a respeito do seu modelo relacional onde explicava em mais detalhes a sua ideia, baseada nos conceitos matemáticos de teoria dos conjuntos e definia novas regras de normalização, que tinham por objetivo proteger os usuários do que ele chamava de “mudanças potencialmente disruptivas” nos dados, causadas pelo crescimento do volume e da complexidade dos dados.

Tudo isso no início da década de 70, criando assim a base para a tecnologia que usamos até os dias de hoje nos nossos trabalhos, nas nossas contas bancárias e até mesmo no restaurante que almoçamos durante a semana.

Neste artigo, iremos abordar a concepção do modelo relacional e as formas normais definidas por Codd, veremos onde elas se enquadram e quais vantagens podemos ter com seu uso.

Vamos criar um modelo relacional para um agente imobiliário fictício, que controla seus negócios com uma planilha eletrônica em seu computador.

Como o artigo trata de um conceito teórico, não vamos utilizar nenhum sistema gerenciador de banco de dados relacional, tampouco ferramentas de modelagem de dados.

A propósito, eu quero convidar o leitor a deixar de lado os conceitos técnicos de modelagem para focar nos elementos principais de um modelo relacional: as “suposições semânticas” das quais Date fala a respeito, o projeto de relações e as regras e benefícios da normalização do modelo final.

Como você deve ter notado, ao longo deste artigo evitaremos falar em tabelas e usaremos o termo relações. Por que? Por dois motivos: o primeiro é manter a consistência com os artigos publicados por Codd, que afinal é o pai do conceito; e o segundo é para dissociar a prática que vemos em alguns bancos de dados, onde o analista precisa criar um banco “a toque de caixa” e não tem as condições necessárias, como tempo, para modelar um banco relacional normalizado.

Bem-vindo ao mundo real

Anteriormente, citamos o autor C.J. Date e suas suposições semânticas. Mas o que é isso? Como podemos criar essas suposições? Qual o melhor software para criar as suposições semânticas e transformá-las automaticamente em um banco de dados e em classes CRUD nas principais linguagens de programação do mercado?

Vamos por partes: o termo “suposição semântica” é um sinônimo para as conhecidas regras do mundo real. Sim, aquelas regrinhas definidas pelo dono do negócio ou então codificadas na cabeça do analista-programador responsável pelo sistema são o primeiro passo para a criação do modelo relacional normalizado.

É importante notar que este é também um passo imprescindível e insubstituível na criação de um banco de dados. E o melhor software? Fica a critério de cada um.

E com o que se parecem essas regras? Simples: são frases que descrevem cada parte do negócio, e as ações que elas realizam com outras partes. Para nosso modelo de controle imobiliário, o corretor fictício possui algumas regras, por exemplo:

- Eu posso trabalhar com venda, aluguel ou financiamento de imóveis;

- Existem diversos tipos de imóveis como: casas, apartamentos, flats, etc.;

- Eu trabalho apenas com pessoa física;

- Um cliente pode alugar vários imóveis.

Entre outras regras que vamos conferir durante o estudo de caso, note que cada regra é bem definida, mostrando quantidades como as três operações da primeira regra, definindo agentes específicos como o cliente e o imóvel da quarta regra e também listando propriedades de cada agente, como os tipos de imóveis.

Em uma relação séria

Ao longo do artigo, vamos utilizar os termos teóricos para referência aos objetos apresentados. Neste caso, usaremos o termo tupla, para definir um conjunto de elementos ordenados, onde cada um desses elementos pertence a um domínio definido.

Por exemplo: um conjunto que define um imóvel tem um elemento chamado tipo, e o domínio de tipos compreende os elementos “casa”, “apartamento”, “sala comercial”, entre outros. Cada tupla possui características de uma “coisa”, e essas características são ordenadas. Então, se nós tivermos uma interação de várias tuplas, onde cada uma possui os mesmos domínios, dizemos que temos uma Relação entre elas.

Se você tem experiência c ...

Quer ler esse conteúdo completo? Tenha acesso completo