Fundamentos da Modelagem de Dados
Olá, Mundo!
Estive um pouco atarefado entre provas, trabalho, e pesquisas que tenho feito ultimamente, e não pude atualizar o Blog de maneira mais presente, vamos em frente.
O assunto de hoje é de suma importância, se trata da base de um eventual sistema que seja desenvolvido. Edgar Frank Codd nos brindou na década de 1970 com a teoria do Banco de dados relacional – caso não tenha conhecimento prévio, clique sobre o assunto que você será redirecionado ao Wikipedia para lhe dar base ao assunto! ; ) – e neste fundamento, a premissa é a integridade dos dados, ou seja, eles devem ser armazenados de maneira que ocupem menos espaço em disco, e por sua vez, não incorra em informações repetitivas, que por exemplo podem levar a um erro na elaboração de um relatório analítico, já que a informação não possui um crivo de qualidade em sua forma de armazenamento. Para que possamos entender, de fato, na práxis, o que vem a ser o modelo relacional, observe o esquema abaixo:
/* Cria o Schema Vendas no MySQL*/ CREATE DATABASE IF NOT EXISTS vendas; /* Usa o Schema Vendas para eventuais alterações/inserções/remoções */ USE vendas; /* Cria Novas Tabelas no Banco de Dados */ CREATE TABLE produtos ( id INT PRIMARY KEY AUTO_INCREMENT, nome_produto VARCHAR(100), preco DECIMAL(13,2 ) ); CREATE TABLE lojas ( id INT PRIMARY KEY AUTO_INCREMENT, nome_loja VARCHAR(100) ); CREATE TABLE vendas ( produto_id INT, loja_id INT, quantidade DECIMAL(13 , 2 ) NOT NULL, data_venda DATE NOT NULL, PRIMARY KEY (produto_id , loja_id), FOREIGN KEY (produto_id) REFERENCES produtos (id) ON DELETE CASCADE ON UPDATE CASCADE, FOREIGN KEY (loja_id) REFERENCES lojas (id) ON DELETE CASCADE ON UPDATE CASCADE );
Conforme o código acima observamos o seguinte cenário:
No exemplo, as relações são básicas, em que uma loja pode realizar muitas vendas (cardinalidade 1:n), e um produto (na qualidade de sua especificidade) pode ser envolvido em muitas vendas também (cardinalidade 1:n).
Não entrarei ainda no mérito das Formas Normais de Codd, e sim no conceito básico que concerne o que fora proposto. Na última tabela, a tabela Vendas é possível observar no código SQL as restrições de integridades referencial, ON DELETE CASCADE, ON UPDATE CASCADE, o que isso significa? Significa que caso eu apagar um registro, este também será apagado na tabela a qual ele está relacionado, assim como sua respectiva atualização. Isto dá consistência e integridade a informação, além de ocupar menos espaço em disco, serve para dar atomicidade dos dados para que sejam confiáveis, dependendo da regra de negócio em que fizer parte. Cabe ressaltar que o artigo em questão não visa aprofundar sobre as ferramentas que tangem um SGBD (Sistema de Gerenciamento de Banco de Dados), e sim prover princípios para que o conceito seja aplicado de maneira correta.
Iremos agora popular estas tabelas com alguns dados:
/* Insere na Tabela Produtos */ INSERT INTO produtos(nome_produto, preco) VALUES('Chinelo', 25), ('Tênis',125), ('Bermuda',85); /* Insere na Tabela Lojas */ INSERT INTO lojas(nome_loja) VALUES('B&D'), ('ZESNI'); /* Insere na Tabela Vendas */ INSERT INTO vendas(loja_id,produto_id,quantidade,data_venda) VALUES(1,1,20,'2021-07-05'), (1,2,15,'2021-07-04'), (1,3,25,'2021-07-05'), (2,1,30,'2021-07-03'), (2,2,35,'2021-07-05');
Bom, mas o que tem a ver com matemática isso?! Tudo, meu caro leitor!Tudo! Senão vejamos.
Já ouviu falar de René Descartes?!Sim, ele mesmo um dos influenciadores do Método Científico aplicado ao racionalismo, e percursor da Matemática Moderna com o seu Plano Cartesiano, que por sua vez deu origem a Geometria Analítica, matéria esta utilizada para resolução de problemas envolvendo Função de Primeiro Grau, dentre outros problemas complexos. (Desculpa, me empolgo com facilidade!)
Iremos aplicar o CROSS JOIN para relacionar as tabelas e gerar um produto cartesiano.
/* Efetua a seleção das tabelas e as relaciona com a junção cruzada (CROSS JOIN), obtendo produto cartesiano de A x B */ SELECT nome_loja, nome_produto FROM lojas AS a CROSS JOIN produtos AS b;
Você irá observar que ambos os produtos (Chinelo, Tênis e Bermuda) estão disponíveis em ambas as Lojas (B&D e ZESNI). Perceba que o conceito matemático aplicado é análogo à Teoria dos Conjuntos, em que podemos vislumbrar no Diagrama de Venn abaixo:
Como podem observar, o que está contido em lojas, também tem relação com produtos. Mas o que quer dizer tudo isso?!Simples, se você alterar um registro, ele automaticamente será alterado sem a real necessidade de se fazer novamente, sem o controle indevido. Isto é só um exemplo sobre a integridade referencial, o assunto não se esgota aqui.
Vamos prosseguir agora com um relatório acerca do total de vendas por loja e os respectivos produtos, ordenados pelo o maior valor de receita:
/* Realiza as seleções dos campos: nome da loja, nome do produto, efetua a multiplicação da quantidade com preço e cria a coluna RECEITA */ SELECT nome_loja, nome_produto, SUM(quantidade * preco) AS receita FROM vendas INNER JOIN produtos ON produtos.id = vendas.produto_id INNER JOIN lojas ON lojas.id = vendas.loja_id GROUP BY nome_loja , nome_produto ORDER BY receita DESC;
E após efetuarmos esta seleção, obtemos o seguinte resultado:
Podemos observar que a Loja “ZESNI” é a que possui maior receita em termos de produto “Tênis”, por essa razão a modelagem de dados é de fundamental importância para agregar valor, e por consequência, ofertar dados fidedignos e precisos.
Imagine um cenário em que múltiplas tabelas, com milhares de linhas de registros, e não há esta boa prática?!Seria o caos, algo que causaria a desordem, e a inconsistência da informação. Infelizmente, muito comum em projetos diversos que já vi. O mais fácil nem sempre é o conveniente a se fazer.
Espero que tenha sido de grande utilidade.
Parafraseando nosso estimado e importante cientista René Descartes:
“Cogito, Ergo Sum”
“Penso, Logo Existo!”
; )