O que é um banco de dados relacional?

Os dados normalmente são estruturados em várias tabelas, que podem ser unidas por meio de chave primária ou chave estrangeira. Esses identificadores únicos demonstram as diferentes relações existentes entre as tabelas e geralmente são ilustrados por meio de diferentes tipos de modelos de dados. Analistas usam consultas SQL para combinar diversos pontos de dados e resumir o desempenho dos negócios, permitindo que as organizações obtenham insights, otimizem fluxos de trabalho e identifiquem novas oportunidades.

Por exemplo, imagine que sua empresa mantém uma tabela de banco de dados com informações do cliente, que contém dados da empresa no nível da conta. Pode haver também uma tabela diferente, que descreve todas as transações individuais que correspondem a essa conta. Juntas, essas tabelas podem fornecer informações sobre as diferentes setores que compram um produto de software específico.

As colunas (ou campos) para a tabela do cliente podem incluir identidade do cliente, nome da empresa, endereço da empresa, setor etc.; as colunas para uma tabela de transação podem incluir data da transação, identidade do cliente, valor da transação, método de pagamento etc. As tabelas podem ser unidas pelo campo comum de identidade do cliente. Portanto, você pode consultar a tabela para produzir relatórios valiosos, como relatórios de vendas por setor ou empresa, que podem informar a mensagem para clientes em potencial.

Os bancos de dados relacionais também são tipicamente associados a bancos de dados transacionais, que executam comandos ou transações coletivamente. Um exemplo popular usado para ilustrar isso é uma transferência bancária. Um valor definido é retirado de uma conta e, em seguida, depositado em outra. O valor total do dinheiro é retirado e depositado, e essa transação não pode ocorrer de forma parcial. As transações têm propriedades específicas. Representadas pela sigla ACID, as propriedades ACID são definidas como:

• Atomicidade: todas as alterações nos dados são executadas como se fossem uma única operação. Ou seja, todas as alterações são realizadas ou nenhuma delas é.

• Consistência: os dados permanecem em um estado consistente do início ao fim, reforçando a integridade dos dados.

• Isolamento: o estado intermediário de uma transação não é visível para outras transações, e, como resultado, transações que ocorrem simultaneamente parecem ser serializadas.

• Durabilidade: após a conclusão bem-sucedida de uma transação, as alterações nos dados persistem e não são desfeitas, mesmo no caso de uma falha do sistema.

Essas propriedades permitem um processamento de transações confiável.

Enquanto um banco de dados relacional organiza os dados com base em um modelo de dados relacional, um sistema de gerenciamento de banco de dados relacional (RDBMS) é uma referência mais específica ao software de banco de dados subjacente que permite aos usuários mantê-lo. Esses programas permitem que os usuários criem, atualizem, insiram ou excluam dados no sistema e fornecem:

• estrutura de dados

• Acesso multiusuário

• Controle de privilégios

• Acesso à rede

Exemplos de sistemas populares de RDBMS incluem MySQL, PostgreSQL e IBM Db2. Além disso, um sistema de banco de dados relacional difere de um sistema básico de gerenciamento de banco de dados (DBMS), pois armazena dados em tabelas enquanto um DBMS armazena informações como arquivos.

Inventada por Don Chamberlin e Ray Boyce na IBM, a Structured Query Language (SQL) é a linguagem de programação padrão para interagir com sistemas de gerenciamento de bancos de dados relacionais, permitindo que administradores adicionem, atualizem ou excluam linhas de dados com facilidade. Originalmente chamada SEQUEL, foi simplificada para SQL devido a uma questão de marca registrada. Consultas SQL também permitem que usuários recuperem dados de bancos usando apenas algumas linhas de código. Dada essa relação, fica claro por que bancos de dados relacionais também são chamados às vezes de “bancos SQL”.

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 forma ajuda a reduzir a redundância em nossos sistemas de dados, permitindo que as equipes de dados mantenham uma tabela mestre de clientes em vez de duplicar essas informações a cada nova transação. Para saber mais, Don detalha mais da história do SQL em seu artigo aqui.

Antes dos bancos de dados relacionais, empresas usavam um sistema de banco de dados hierárquico com estrutura em árvore para as tabelas. Esses primeiros sistemas de gerenciamento de banco de dados (DBMS) permitiam organizar grandes volumes de dados. No entanto, eram complexos, muitas vezes proprietários de uma aplicação específica e limitados na forma de extrair informações dos dados. Essas limitações levaram o pesquisador da IBM Edgar F. Codd a publicar um artigo em 1970, intitulado “A Relational Model of Data for Large Shared Data Banks”, que teorizou o modelo relacional de dados. Nesse modelo, a informação podia ser recuperada sem conhecimento especializado de computação. Ele propôs organizar os dados com base em relações significativas como tuplas, ou pares atributo-valor. Conjuntos de tuplas eram chamados de relações, o que permitiu a fusão de dados entre as 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 do carrinho de compras desse usuário. É comumente utilizado em cache e armazenamento de informações de sessões de usuários, como carrinhos de compras. No entanto, não é a solução ideal para 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 reunidos quando utilizados em aplicações, reduzindo a quantidade de conversão necessária para utilizar os dados. Os desenvolvedores também ganham mais flexibilidade, já que os esquemas de dados não precisam ser os mesmos entre os documentos (por exemplo, nome vs. primeiro_nome). No entanto, isso pode ser problemático em transações complexas, levando ao corrompimento de dados. São casos de uso populares de bancos de dados de documentos os sistemas de gerenciamento de conteúdo e os 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. Esse banco de dados tenta resolver as deficiências dos armazenamentos baseados em chave-valor e de documentos, mas como pode ser um sistema mais complexo de gerenciar, não é recomendado para 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. O Apache Cassandra, por outro lado, foi projetado para gerenciar grandes quantidades de dados em vários servidores e clusters que abrangem diversos data centers. Tem sido utilizado em 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, arestas e propriedades. Qualquer objeto, lugar ou pessoa pode ser um nó. A borda 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.

Bancos de dados NoSQL também priorizam disponibilidade em vez de consistência.

Quando computadores operam em uma rede, eles inevitavelmente precisam decidir entre priorizar resultados consistentes (onde toda resposta é sempre a mesma) ou alto tempo de atividade, chamado “disponibilidade”. Isso é chamado de "CAP Theory," que significa consistência, disponibilidade ou tolerância de partição. Bancos de dados relacionais garantem que a informação esteja sempre sincronizada e consistente. Alguns bancos NoSQL, como Redis, preferem sempre fornecer uma resposta. Isso significa que a informação retornada por uma consulta pode estar desatualizada em alguns segundos — talvez até meio minuto. Em sites de mídia social, isso pode resultar em ver uma foto de perfil antiga quando a mais recente foi atualizada há poucos instantes. A alternativa seria um tempo limite ou erro. Por outro lado, em transações bancárias e financeiras, um erro e nova submissão pode ser melhor do que informação antiga e incorreta.

Para uma visão completa das diferenças entre SQL e NoSQL, consulte “SQL vs. NoSQL Databases: qual é a diferença?”.

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:

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.

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.

Bancos de dados relacionais são transacionais — garantem que o estado de todo o sistema seja consistente a qualquer momento. A maioria oferece opções fáceis de exportação e importação, tornando backup e restauração triviais. Essas exportações podem ocorrer mesmo com o banco em operação, facilitando a restauração em caso de falha. Bancos relacionais modernos na nuvem podem fazer espelhamento contínuo, reduzindo a perda de dados na restauração a segundos ou menos. A maioria dos serviços gerenciados na nuvem permite criar 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. As réplicas também podem ser promovidas a instâncias de leitura/gravação para recuperação de desastre.