Inventado por Don Chamberlin e Ray Boyce na IBM, SQL (linguagem de consulta estruturada) é a linguagem de programação padrão para interagir com sistemas de gerenciamento de banco de dados relacional, permitindo que administradores de banco de dados adicionem, atualizem ou excluam linhas de dados facilmente. Originalmente conhecido como SEQUEL, foi simplificado para SQL devido a um problema de marca registrada. Consultas SQL também permitem que os usuários recuperem dados dos bancos de dados usando apenas algumas linhas de código. Dada essa relação, é fácil ver por que os bancos de dados relacionais são também referidos como "bancos de dados SQL" às vezes.

Usando o exemplo acima, você pode construir uma consulta para encontrar as 10 maiores transações por empresa para um ano específico com o seguinte código:

SELECT COMPANY_NAME, SUM(TRANSACTION_AMOUNT)

FROMTRANSACTION_TABLE A

LEFT JOIN CUSTOMER_TABLE B

ON A.CUSTOMER_ID = B.CUSTOMER_ID

WHERE YEAR(DATE) = 2022

GROUP BY 1

ORDER BY 2 DESC

LIMIT 10

A capacidade de unir dados dessa maneira nos ajuda a reduzir a redundância dentro de nossos sistemas de dados, permitindo que as equipes de dados mantenham uma tabela mestre para clientes em vez de duplicar essa informação se houvesse outra transação no futuro. Para saber mais, Don detalha mais da história do SQL em seu artigo aqui (link fora de IBM).

Antes dos bancos de dados relacionais, as empresas usavam um sistema de banco de dados hierárquico com uma estrutura em árvore para as tabelas de dados. Esses primeiros sistemas de gerenciamento de banco de dados (DBMS) permitiam que os usuários organizassem grandes quantidades de dados. No entanto, eles eram complexos, muitas vezes proprietários de uma aplicação específica e limitados nas maneiras pelas quais podiam descobrir dentro dos dados. Essas limitações acabaram levando o pesquisador da IBM, Edgar F. Codd, a publicar um artigo (link fora da IBM) (PDF, 1.5 MB) em 1970, intitulado "A Relational Model of Data for Large Shared Data Banks", que teorizava o modelo de banco de dados relacional. Neste modelo proposto, as informações poderiam ser recuperadas sem conhecimento especializado em computação. Ele propôs organizar os dados com base em relacionamentos significativos como tuplas ou pares atributo-valor. Os conjuntos de tuplas eram chamados de relações, o que, em última análise, permitia a fusão de dados entre tabelas.

Em 1973, o Laboratório de Pesquisa de San Jose — agora conhecido como Centro de Pesquisa Almaden — iniciou um programa chamado Sistema R (R de relacional) para comprovar essa teoria relacional com o que chamou de "uma implementação de força industrial". Em última análise, tornou-se também um campo de testes para o SQL, permitindo que ele fosse mais amplamente adotado em um curto período de tempo. No entanto, a adoção do SQL pela Oracle também não prejudicou sua popularidade entre os administradores de banco de dados.

Até 1983, a IBM introduziu a família Db2 de bancos de dados relacionais, assim nomeada porque era a segunda família de software de gerenciamento de banco de dados da IBM. Hoje, é um dos produtos mais bem-sucedidos da IBM, continuando a lidar com bilhões de transações todos os dias em infraestrutura de nuvem e estabelecendo a camada fundamental para aplicações de aprendizado de máquina.

Enquanto os bancos de dados relacionais estruturam dados em um formato tabular, os bancos de dados não relacionais não possuem um esquema de banco de dados tão rígido. Na verdade, os bancos de dados não relacionais organizam os dados de maneira diferente com base no tipo de banco de dados. Independentemente do tipo de banco de dados não relacional, todos eles visam resolver problemas de flexibilidade e escalabilidade inerentes aos modelos relacionais, que não são ideais para formatos de dados não estruturados, como texto, vídeo e imagens. Esses tipos de bancos de dados incluem:

• Armazenamento de valores-chave: este modelo de dados sem esquema é organizado em um dicionário de pares de chave-valor, onde cada item tem uma chave e um valor. A chave poderia ser algo semelhante ao encontrado em um banco de dados SQL, como uma identificação de carrinho de compras, enquanto o valor é um conjunto de dados, como cada item individual no carrinho de compras desse usuário. É comumente usado para cache e armazenamento de informações de sessão do usuário, como carrinhos de compras. No entanto, não é ideal quando você precisa extrair vários registros de uma vez. Redis e Memcached são exemplos de bancos de dados de código aberto com esse modelo de dados.

• Armazenamento de documentos: como sugerido pelo nome, os bancos de dados de documentos armazenam dados como documentos. Eles podem ser úteis no gerenciamento de dados semi-estruturados, e os dados são tipicamente armazenados em formatos JSON, XML ou BSON. Isso mantém os dados juntos quando são usados em aplicações, reduzindo a quantidade de tradução necessária para usar os dados. Os desenvolvedores também ganham mais flexibilidade, já que os esquemas de dados não precisam coincidir entre os documentos (por exemplo, name vs. first_name). No entanto, isso pode ser problemático para transações complexas, levando à corrupção de dados. Casos de uso populares de bancos de dados de documentos incluem sistemas de gerenciamento de conteúdo e perfis de usuário. Um exemplo de banco de dados orientado a documentos é o MongoDB, o componente de banco de dados do stack MEAN.

• Armazenamento de coluna ampla: esses bancos de dados armazenam informações em colunas, permitindo que os usuários acessem apenas as colunas específicas de que precisam sem alocar memória adicional em dados irrelevantes. Este banco de dados tenta resolver as deficiências dos armazenamentos de chave-valor e de documentos, mas, como pode ser um sistema mais complexo de gerenciar, não é recomendado para uso por equipes iniciantes e projetos mais novos. Apache HBase e Apache Cassandra são exemplos de bancos de dados de coluna larga de código aberto. Apache HBase é desenvolvido sobre o Hadoop Distributed Files System que fornece uma maneira de armazenar conjuntos de dados esparsos, comumente usados em muitas aplicações de big data. Apache Cassandra, por outro lado, foi projetado para gerenciar grandes quantidades de dados em vários servidores e clusters que abrangem vários data centers. Ele tem sido usado para uma variedade de casos de uso, como sites de redes sociais e análise de dados em tempo real.

• Armazenamento de gráficos: este tipo de banco de dados normalmente abriga dados de um gráfico de conhecimento. Os elementos de dados são armazenados como nós, edges e propriedades. Qualquer objeto, lugar ou pessoa pode ser um nó. Um edge define a relação entre os nós. Bancos de dados de gráfico são usados para armazenar e gerenciar uma rede de conexões entre elementos dentro do gráfico. Neo4j (link fora da IBM), um serviço de banco de dados baseado em gráfico baseado em Java com uma edição da comunidade de código aberto, onde os usuários podem comprar licenças para backup on-line e extensões de alta disponibilidade, ou uma versão licenciada pré-embalada com backup e extensões incluídas.

Os bancos de dados NoSQL também priorizam a disponibilidade em detrimento da consistência.

Quando computadores operam em rede, eles inevitavelmente precisam decidir priorizar resultados consistentes (onde cada resposta é sempre a mesma) ou alto tempo de atividade, chamado de "disponibilidade". Isso é chamado de "CAP Theory," que significa Consistência, Disponibilidade ou Tolerância de Partição. Bancos de dados relacionais garantem que as informações estejam sempre sincronizadas e consistentes. Alguns bancos de dados NoSQL, como o Redis, preferem sempre fornecer uma resposta. Isso significa que as informações que você recebe de uma consulta podem estar incorretas por alguns segundos — talvez até meio minuto. Em sites de redes sociais, isso significa ver uma foto de perfil antiga quando a mais nova tem apenas alguns instantes. A alternativa poderia ser um tempo de espera ou erro. Por outro lado, em transações bancárias e financeiras, um erro e reenvio podem ser melhores do que informações antigas e incorretas.

Para uma descrição completa das diferenças entre SQL e NoSQL, veja "SQL vs. NoSQL Databases: What's the Difference?"

O principal benefício da abordagem de banco de dados relacional é a capacidade de criar informações significativas ao unir as tabelas. Unir tabelas permite que você entenda as relações entre os dados, ou como as tabelas se conectam. O SQL inclui a capacidade de contar, adicionar, agrupar e também combinar consultas. O SQL pode realizar funções matemáticas básicas e subtotais e transformações lógicas. Os analistas podem ordenar os resultados por data, nome ou qualquer coluna. Esses recursos tornam a abordagem relacional a ferramenta de consulta mais popular nos negócios hoje em dia.

Bancos de dados relacionais têm várias vantagens em comparação com outros formatos de banco de dados:

Facilidade de uso

Pela virtude de seu tempo de vida no mercado, há mais uma comunidade em torno dos bancos de dados relacionais, o que parcialmente perpetua seu uso contínuo. O SQL também facilita a recuperação de conjuntos de dados de várias tabelas e a realização de transformações simples, como filtragem e agregação. O uso de índices dentro dos bancos de dados relacionais também permite que eles localizem essas informações rapidamente, sem necessidade de pesquisar cada linha na tabela selecionada.

Embora os bancos de dados relacionais tenham sido historicamente vistos como uma opção de armazenamento de dados mais rígida e inflexível, os avanços na tecnologia e as opções de DBaaS estão mudando essa percepção. Embora ainda haja mais sobrecarga para desenvolver esquemas em comparação com as ofertas de bancos de dados NoSQL, os bancos de dados relacionais estão se tornando mais flexíveis à medida que migram para ambientes de nuvem.

Redundância reduzida

Os bancos de dados relacionais podem eliminar a redundância de duas maneiras. O próprio modelo relacional reduz a redundância de dados por meio de um processo conhecido como normalização. Como mencionado anteriormente, uma tabela de clientes deve registrar apenas registros únicos de informações do cliente, em vez de duplicar essas informações para várias transações.

Procedimentos armazenados também ajudam a reduzir o trabalho repetitivo. Por exemplo, se o acesso ao banco de dados for restrito a certos papéis, funções ou equipes, um procedimento armazenado pode ajudar a gerenciar o controle de acesso. Essas funções reutilizáveis liberam o tempo precioso do desenvolvedor de aplicações para lidar com trabalhos de alto impacto.

Facilidade de backup e recuperação de desastres

Bancos de dados relacionais são transacionais — eles garantem que o estado de todo o sistema seja consistente a qualquer momento. A maioria dos bancos de dados relacionais oferece opções fáceis de exportação e importação, tornando o backup e a restauração triviais. Essas exportações podem ocorrer mesmo enquanto o banco de dados está em execução, facilitando a restauração em caso de falha. Bancos de dados relacionais modernos baseados em nuvem podem fazer espelhamento contínuo, fazendo com que a perda de dados na restauração seja medida em segundos ou menos. A maioria dos serviços gerenciados na nuvem permite que você crie réplicas de leitura, como no IBM Cloud Databases for PostgreSQL.Essas réplicas de leitura permitem que você armazene uma cópia somente leitura dos seus dados em um data center na nuvem. Réplicas podem ser promovidas a instâncias de Leitura/Escrita para recuperação de desastres também.