Modelos de Banco de Dados: o que são, quais os tipos e como usar
Quando atuamos em Programação, Engenharia de Dados ou Ciência de Dados , “banco de dados” é uma expressão comum em nosso dia a dia.
Quando atuamos em Programação, Engenharia de Dados ou Ciência de Dados , “banco de dados” é uma expressão comum em nosso dia a dia.
No desenvolvimento de software backend e na Engenharia de Dados, saber trabalhar com banco de dados é fundamental. Afinal, onde iremos salvar e de onde iremos recuperar os dados que nossos programas devem processar?
Na Ciência de Dados, para obtermos dados que alimentam análises ou modelos de Machine Learning, também precisamos recuperá-los de bancos de dados.
Ocorre que não há um único “jeito” de guardar esses dados e de fazer com que se relacionem entre si, a fim de gerarem informações.
Ter o nome “Maria Souza” e o número “5000” soltos em algum lugar não significa nada. Eles só são úteis se conseguimos relacioná-los, a fim de saber, por exemplo, que “Maria Souza” é funcionária de uma empresa e “5000” é seu salário.
Quais seriam, então, essas maneiras de guardar dados e relacioná-los? Por que, como programador, engenheiro ou cientista de dados, devo entender isso? Vamos descobrir.
Glossário
O que são modelos de banco de dados?
Os “jeitos” de armazenar e relacionar dados são chamados, tecnicamente, de “modelos de dados”, do qual deriva o conceito de “modelos de bancos de dados”.
Pense em um modelo como uma representação (conceitual ou visual) da forma como os dados são organizados e ligados uns aos outros.
É inevitável que um banco de dados assuma um determinado modelo. A partir do momento em que relacionamos os dados de uma forma ou de outra, um modelo emergirá naturalmente, como um padrão.
Por exemplo, podemos ter os dados “Maria”, “João” e “José”. Se eles são amigos, temos um relacionamento de todos para todos, o que tecnicamente forma um relacionamento em grafo. Agora, se Maria é mãe de “João”, que é pai de “José”, isso será melhor modelado em um relacionamento hierárquico.
Importância à Programação e à Ciência de Dados
O que isso tem a ver com Programação, Engenharia de Dados e Ciência de Dados? A forma como os dados são organizados e relacionados afeta três aspectos computacionais, que estão na base dessas três áreas:
- eficiência na forma como os dados são armazenados, recuperados e alterados dos diversos sistemas de bancos de dados, isto é, a rapidez, consumo de energia, entre outros fatores, para os dados transitarem entre o banco de dados (normalmente “existente” em discos rígidos) e a memória do computador;
- design técnico de cada sistema de banco de dados disponíveis no mercado;
- maneiras como os programadores, engenheiros e cientistas de dados têm de construir soluções para criar, ler, alterar ou excluir dados em um determinado sistema de banco de dados.
Como essas formas de relacionamento de dados não se resumem apenas a grafos e hierarquias, vamos ver a variedade de modelos criados para lidar com a quantidade e complexidade crescente dos dados (big data).
Quais os tipos?
Os modelos de bancos de dados seguem um curso histórico. Começam simples, atrelados às restrições da tecnologia, por volta das décadas de 1950 e 1960, e ganham complexidade à medida que novas tecnologias surgem.
1. Modelos pré-relacionais
Os modelos pré-relacionais são bastante simples, antigos e, na maioria, já estão, por serem ineficientes às demandas atuais.



1.1 Modelo plano
É o modelo mais simples e primitivo de todos. Consiste em um banco de dados onde todos os dados são armazenados em uma única tabela.
Crie uma lista de contatos de dez amigos em um bloco de notas qualquer ou no Excel, com nome e número do WhatsApp ou Telegram de cada pessoa. Pronto. Você tem um modelo de dado plano.
1.2 Modelo hierárquico
No modelo hierárquico, os dados são dispostos em “árvore”, como já demonstrado acima. As relações são chamadas “de um para muitos” e podem ser entendidas como relacionamentos de campos “pais” para campos “filhos”.
Tornou-se defasado por questões computacionais. Se você tem dez, cem ou mil níveis na hierarquia, o sistema teria de percorrer toda a árvore para chegar ao último nível, o que é muito ineficiente.
1.3 Modelo em rede
É uma melhoria do sistema hierárquico, mas, ainda assim, ineficiente para padrões atuais. Neste caso, há relacionamentos “um para muitos” e “muitos para um”, porém, apenas em determinados níveis. Na prática, o modelo permite que um campo “filho” possa ter vários campos “pais”.
2. Modelo relacional
O modelo relacional suplantou os anteriores e permanece como um dos mais usados até hoje. A maioria dos bancos de dados comerciais o usa. Nele, os dados podem ser organizados em várias tabelas (matrizes de duas dimensões, com linhas e colunas), as quais se relacionam entre si.
Em um e-commerce, por exemplo, podemos ter uma uma tabela chamada “Clientes”, onde os dados de cada cliente é uma linha e onde seus atributos (nome, endereço de entrega, número de cartão de crédito etc.) são as colunas.
Outra tabela pode ser “Produtos”, com os dados dos produtos ofertados. Uma terceira tabela pode ser “Compras”, que relaciona dados das tabelas “Clientes” e “Produtos” para sabermos quem comprou o quê.
3. Modelos pós-relacionais
Modelos pós-relacionais podem ser considerados uma evolução do modelo relacional. Por questões de padronização, nem todos se tornaram alternativas ao modelo relacional, mas acabaram incorporados a este.
3.1 Modelo orientado a objetos
O modelo de banco de dados orientado a objetos surgiu na década de 1990, com a ascensão da Programação Orientada a Objetos (Object-Oriented Programming ou OOP).
Os dados são modelados da mesma forma que nos programas criados com tal paradigma de programação. Para isso, são usadas classes — “moldes”, que determinam as características e os comportamentos de um objeto — e as instâncias dessas classes, que são objetos em si.
Por exemplo, podemos ter uma classe “Carro”, com os atributos “marca”, “modelo”, “ano”, “cor” etc. A partir dela, podemos, então, criar um objeto “carro” da marca BMW, modelo X1, ano 2018, cor preta. O banco de dados Postgres nasceu dentro dessa filosofia e mantém recursos do modelo.
3.2 Variantes do modelo orientado a objetos
Embora não tenha substituído o modelo relacional, o modelo orientado a objetos acabou sendo incorporado a este de uma série de formas. Uma delas se chama modelo objeto-relacional.
Vários sistemas de bancos de dados relacionais atuais, como MySQL, Oracle e Microsoft SQL Server, utilizam esse modelo, na verdade. Isso permite comunicação mais precisa entre classes e objetos criados em uma linguagem de programação e os dados gerados a partir deles em um banco de dados relacional.
3.3 NewSQL
NewSQL é o nome dado a sistemas de bancos de dados relacionais bem mais recentes, com desempenho superior aos tradicionais.
Bancos de dados deste tipo são usados, por exemplo, onde há muitas transações por segundos ou até milésimos de segundos (pense em transações financeiras, por exemplo), mas que dependem da segurança que só bancos relacionais oferecem.
Bancos de dados que rodam em nuvem já oferecem este tipo de modelo, como Amazon Aurora, Couchbase e Google Spanner.
4. Modelos não relacionais
Modelos não relacionais (ou “não somente relacionais”) compõe um paradigma que ascendeu com a necessidade de processar big data (dados gerados em larga escala com a web). Têm esse nome porque não usam as tabelas relacionais.
4.1 Modelo chave-valor
Bancos NoSQL do tipo chave-valor são como “dicionários”. Eles permitem cadastrar uma chave (um registro único e inconfundível) e associar quaisquer valores (informações) a essas chaves.
A estratégia permite muita flexibilidade e rapidez nas consultas. Podemos associar muitos campos de dados diferentes a uma única chave, bastando acessar tal chave para recuperá-los.
Redis, Apache Ignite e Memcached são exemplos populares de bancos do modelo chave-valor.



4.2 Modelo documental
Aqui, os dados são armazenados em “textos”. Por exemplo, neste modelo, dados de clientes estarão organizados de forma sequencial, como em uma folha de formulário.
Tais textos podem ser altamente estruturados (ter campos bem definidos e comuns a todos os documentos, como CPF e nome de cada cliente) ou podem ser semiestruturados ou não estruturados (quando não há padronização dos campos).
MongoDB, Elasticsearch e CouchDB são exemplos populares de bancos do modelo documental.
4.3 Modelo em grafo
Grafo é uma coleção de nós ligados por arestas. Neste modelo, os dados são os nós e os relacionamentos entre eles, as arestas. Por meio dessa característica, podemos relacionar facilmente clientes aos produtos que cada um mais compra, por exemplo.
Tais bancos de dados são muito usados para mecanismos de recomendação (indicar um produto que o cliente pode gostar, com base em suas preferências) e para detecção de fraude (comparar se o número de cartão de crédito usado por ele é sempre o mesmo, por exemplo).
Neo4J, OrientDB e AllegroGraph são exemplos populares de bancos de dados deste modelo.
Como usar?
O uso de um modelo de banco de dados costuma ser uma questão crítica para programadores e engenheiros de dados.
O sistema ou aplicativo a ser criado e os dados que ele irá processar (tarefa de desenvolvedores de software) ou a forma de organizar dados e fornecê-los para consumo analítico de uma empresa (tarefa de engenheiros de dados) é o que ditará a escolha do modelo de banco de dados.
Por exemplo, transações financeiras que requerem segurança ainda são implementadas, em muitos casos, em bancos de dados relacionais ou similares.
Já para aplicações menos críticas, mas com um número massivo de usuários, como um site de conteúdos ou um aplicativo de rede social, um banco de dados NoSQL de modelo documental pode ser uma boa escolha.
Como a programação orientada a objetos continua muito popular no mercado, uma dica a programadores e engenheiros de dados é ter uma compreensão de como dados do modelo objeto-relacional funcionam e aprender a linguagem SQL (Structure Query Language), que é padrão para esses bancos de dados.
A partir daí, fica fácil migrar para bancos de dados NoSQL, como o MongoDB, e evoluir para grandes bancos de dados em nuvem, que costumam ser “multi-modelos”, isto é, oferecer várias formas diferentes de modelar dados.
No caso de cientistas de dados, a recomendação é um pouco diferente. Caso o profissional trabalhe em uma empresa madura no ciclo de dados, provavelmente receberá dados prontos da Engenharia de Dados para analisar ou alimentar modelos de Machine Learning. Neste caso, vale conhecer os conceitos para conversar com os engenheiros, quando necessário.
Em empresas menores, porém, pode ser que o data scientist tenha de buscar e limpar dados diretamente de bancos relacionais, por meio da SQL, por exemplo. Neste caso, não tem jeito: é preciso conhecer a linguagem, pedir permissão ao administrador do banco de dados e fazer consultas para obter os dados a serem analisados.
Quer ingressar em Programação ou Ciência de Dados? Conheça a Awari!
A Awari é uma plataforma completa com mentorias individuais, cursos com aulas ao vivo e assessoria de carreira nas áreas de Programação e de Dados.
Conheça nossos cursos de Programação, com intensivos de Front-End com React, Back-End com Javascript, DevOps, Desenvolvimento Web e React Native.
Ou confira nossos cursos de Data Science, com intensivos de Ciência de Dados, Machine Learning, Engenharia de Dados e Data Analytics.
Saiba mais sobre a nossa jornada personalizada e materiais complementares feitos por especialistas no mercado.


