Optimização de Tabelas Normalizadas no Banco de Dados
Tags: sql, database, mysql
Published: 2022-03-02 14:47:25

Após a Normalização da Base de Dados, ainda podemos ter muitas tabelas. Para isso podemos recorrer a outras análises alternativas. Existem várias formas d reduzir o número de tabelas na base de dados. 

Depois de várias tentativas, testei uma forma fácil de reduzir o número de tabelas na Base de Dados.

**Problema: **Suponhamos que precisamos armazenar informações dos Clientes e Funcionários, sabendo que têm dados em comum.

**Clientes:** nome, sexo, nif, estado civil,  código, contactos(telefone e email) e endereço(município, bairro, rua, casa).

**Funcionário:** nome, sexo, nif, estado civil,  código, contactos(telefone e email) e endereço(município, bairro, rua, casa).

Para este problema, temos 3 soluções:

**Solução 1:** Criamos as entidades com os atributos compostos e multivalorados, para cada Item. 
No modelo lógico normalizamos a base de dados. Criamos uma tabela para cada os atributos (_telefone_ e _email_) e dividimos o atributo endereço em atributos atómicos que ficarão nas tabelas _Cliente_ e _Funcionário_.

**Modelo Conceitual**
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6dq9hvb1jjo9ogpckkp3.jpg)

**Modelo Lógico**
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/fc0yaq11ww9qn7rc9ley.jpg)

**Vantagens**
- Separação dos atributos mutivalorados (ex: telefone e email);
- Demposição dos atributos compostos (ex: endereço);
- Análise mais fácil de ser feita e modelada.

**Desvantagens**
- Se o endereço crescer o número de atributos da tabela cresce, tronando mais difícil a manipulação;
- Uma tabela com muitos campos, resulta numa classe com muitos atributos, logo teremos um objecto muito grande (*e difícil de manipular).

<br>

**Solução 2:** Criamos as Entidades para cada Contexto. 
Nesse caso, teremos endereço e contactos para os clientes e funcionários. Se tivéssemos **N** tabelas (por ex: Forencedor, Transportador, Despachante…) teríamos, contactos e endereço para cada tabela.

**Modelo Conceitual**
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/udbo4brftavz5r264nml.jpg)

**Modelo Lógico**
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/fk12sjvsfz2f4fbks9x1.jpg)

**Vantagens**
- Cada Item terá a sua relação correspondente;
- Organização da Base de dados;
- Separação de cada contexto (contactos para clientes e contactos para os funcionários).

**Desvantagens**
- Necessidade de criar uma nova tabela com os mesmos atributos, para cada caso;
- Se o número de tabelas cresce, então o número de classes também cresce;
- O número de classes contribui para o aumento de nº de arquivos que implica o aumento de número de kilobytes da aplicação.

<br>

**Solução 3:** Criamos uma tabela _Pessoa_, que terá será relacionado com _contacto_ e _endereço_. 
As tabelas _Cliente_ e _Funcionario_ só precisam estar relacionados com a tabela _Pessoa_.

**Modelo Conceitual**
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/bmc8zuvr910doecvy2bf.jpg)

**Modelo Lógico**
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6azxrk3cebsnmmwgl76x.jpg)

**Vantagens**
- Facilita a escalabilidade da base de dados, porque essa solução está aberta ao crescimento;
- Redução do número de tabelas;
- Redução do número de classes;
- Redução do número de arquivos.

**Desvantagens**
- Para obter todos os dados do cliente, serão feitas junções


**Nota:** Neste caso, parece que apenas reduzimos 1 tabela. Mas na verdade simplificamos a normalização. Se tivéssemos mais n tabelas com os mesmos dados. Com o aumento de tabelas mesmos atributos, apenas teríamos relacionar com a tabela Pessoa.

Qual seria a solução mais eficaz?