MODELO DE BANCO DE DADOS RELACIONAL: ELEMENTOS, COMO FAZER, EXEMPLO - TECNOLOGIA - 2025

O modelo de banco de dados relacional é um método de estruturação de dados usando relacionamentos, usando estruturas semelhantes a grades, consistindo em colunas e linhas. É o princípio conceitual dos bancos de dados relacionais. Foi proposto por Edgar F. Codd em 1969.

Desde então, ele se tornou o modelo de banco de dados dominante para aplicativos de negócios, quando comparado a outros modelos de banco de dados, como hierárquico, rede e objeto.

Fonte: pixabay.com

Codd não tinha ideia de como seria extremamente vital e influente seu trabalho como plataforma para bancos de dados relacionais. A maioria das pessoas está familiarizada com a expressão física de um relacionamento em um banco de dados: a tabela.

O modelo relacional é definido como a base de dados que permite agrupar seus elementos de dados em uma ou mais tabelas independentes, que podem ser relacionadas entre si através da utilização de campos comuns a cada tabela relacionada.

Gerenciamento de banco de dados

Uma tabela de banco de dados é semelhante a uma planilha. No entanto, os relacionamentos que podem ser criados entre as tabelas permitem que um banco de dados relacional armazene com eficiência uma grande quantidade de dados, que podem ser recuperados com eficácia.

O objetivo do modelo relacional é fornecer um método declarativo para especificar dados e consultas: os usuários declaram diretamente quais informações o banco de dados contém e quais informações desejam dele.

Por outro lado, eles deixam para o software do sistema de gerenciamento de banco de dados descrever as estruturas de dados para armazenamento e o procedimento de recuperação para responder às consultas.

A maioria dos bancos de dados relacionais usa a linguagem SQL para consultar e definir os dados. Atualmente existem diversos sistemas de gerenciamento de banco de dados relacional ou RDBMS (Relational Data Base Management System), como Oracle, IBM DB2 e Microsoft SQL Server.

Recursos e elementos

- Todos os dados são conceitualmente representados como um arranjo ordenado de dados em linhas e colunas, chamado de relação ou tabela.

- Cada tabela deve ter um cabeçalho e um corpo. O cabeçalho é simplesmente a lista de colunas. O corpo é o conjunto de dados que preenche a tabela, organizado em linhas.

- Todos os valores são escalares. Ou seja, em qualquer determinada posição de linha / coluna na tabela, há apenas um único valor.

-Elementos

A figura a seguir mostra uma tabela com os nomes de seus elementos básicos, que compõem uma estrutura completa.

Tupla

Cada linha de dados é uma tupla, também conhecida como registro. Cada linha é uma n-tupla, mas o "n-" geralmente é descartado.

Coluna

Cada coluna em uma tupla é chamada de atributo ou campo. A coluna representa o conjunto de valores que um atributo específico pode ter.

Chave

Cada linha possui uma ou mais colunas denominadas chave de tabela. Este valor combinado é exclusivo para todas as linhas de uma tabela. Por meio dessa chave, cada tupla será identificada de maneira única. Ou seja, a chave não pode ser duplicada. É chamada de chave primária.

Por outro lado, uma chave estrangeira ou secundária é o campo em uma tabela que se refere à chave primária de alguma outra tabela. É usado para fazer referência à tabela primária.

-Regras de integridade

Ao projetar o modelo relacional, você define algumas condições que devem ser atendidas no banco de dados, chamadas de regras de integridade.

Integridade da chave

A chave primária deve ser única para todas as tuplas e não pode ser nula (NULL). Caso contrário, você não conseguirá identificar a linha com exclusividade.

Para uma chave com várias colunas, nenhuma dessas colunas pode conter NULL.

Integridade referencial

Cada valor de uma chave estrangeira deve corresponder a um valor da chave primária da tabela referenciada ou primária.

Uma linha com uma chave estrangeira só pode ser inserida na tabela secundária se esse valor existir em uma tabela primária.

Se o valor da chave mudar na tabela primária, devido à linha sendo atualizada ou excluída, todas as linhas nas tabelas secundárias com esta chave estrangeira devem ser atualizadas ou excluídas de acordo.

Como fazer um modelo relacional?

-Coletar dados

Os dados necessários devem ser coletados para serem armazenados no banco de dados. Esses dados são divididos em diferentes tabelas.

Um tipo de dados apropriado deve ser escolhido para cada coluna. Por exemplo: números inteiros, números de ponto flutuante, texto, data, etc.

-Definir chaves primárias

Para cada tabela, uma coluna (ou algumas colunas) deve ser escolhida como a chave primária, o que identificará exclusivamente cada linha na tabela. A chave primária também é usada para se referir a outras tabelas.

-Crie relacionamentos entre tabelas

Um banco de dados consistindo de tabelas independentes e não relacionadas tem pouca utilidade.

O aspecto mais crucial no projeto de um banco de dados relacional é identificar os relacionamentos entre as tabelas. Os tipos de relacionamento são:

Um para muitos

Em um banco de dados de "Listagem de classes", um professor pode dar zero ou mais classes, enquanto uma classe é ministrada por um único professor. Esse tipo de relacionamento é conhecido como um para muitos.

Esta relação não pode ser representada em uma única tabela. No banco de dados «Lista de turmas» você pode ter uma tabela chamada Professores, que armazena informações sobre os professores.

Para armazenar as aulas ministradas por cada professor, você poderia criar colunas adicionais, mas enfrentaria um problema: quantas colunas criar.

Por outro lado, se você tiver uma tabela chamada Classes, que armazena informações sobre uma classe, pode criar colunas adicionais para armazenar informações sobre o professor.

No entanto, como um professor pode dar várias aulas, seus dados seriam duplicados em muitas linhas da tabela Classes.

Projete duas tabelas

Portanto, você precisa criar duas tabelas: uma tabela Classes para armazenar informações sobre as classes, com Class_Id como a chave primária, e uma tabela Professores para armazenar informações sobre os professores, com Teacher_Id como a chave primária.

O relacionamento um-para-muitos pode então ser criado armazenando a chave primária da tabela Mestre (Master_Id) na tabela Classes, conforme ilustrado abaixo.

A coluna Master_Id na tabela Classes é conhecida como chave estrangeira ou chave secundária.

Para cada valor Master_Id na tabela Master, pode haver zero ou mais linhas na tabela Classes. Para cada valor Class_Id na tabela Classes, há apenas uma linha na tabela Professores.

Muitos para muitos

Em um banco de dados de "Venda de produtos", um pedido de cliente pode conter vários produtos e um produto pode aparecer em vários pedidos. Esse tipo de relacionamento é conhecido como muitos para muitos.

Você pode iniciar o banco de dados "Vendas de produtos" com duas tabelas: Produtos e Pedidos. A tabela Produtos contém informações sobre os produtos, com productID como a chave primária.

Por outro lado, a tabela Pedidos contém os pedidos do cliente, com orderID como a chave primária.

Você não pode armazenar os produtos pedidos dentro da tabela Pedidos, pois você não sabe quantas colunas reservar para os produtos. Os pedidos também não podem ser armazenados na tabela Produtos pelo mesmo motivo.

Para oferecer suporte a um relacionamento muitos para muitos, você precisa criar uma terceira tabela, conhecida como tabela de junção (OrderDetails), onde cada linha representa um item em uma ordem específica.

Para a tabela OrderDetails, a chave primária consiste em duas colunas: orderID e productID, identificando exclusivamente cada linha.

As colunas orderID e productID na tabela OrderDetails são usadas para fazer referência às tabelas Pedidos e Produtos. Portanto, eles também são chaves estrangeiras na tabela OrderDetails.

Um a um

Na base de dados "Venda de produtos", um produto pode conter informações opcionais, como descrição adicional e sua imagem. Mantê-lo dentro da tabela Produtos geraria muitos espaços vazios.

Portanto, outra tabela (ProductExtras) pode ser criada para armazenar os dados opcionais. Apenas um registro será criado para produtos com dados opcionais.

As duas tabelas, Products e ProductExtras, têm uma relação de um para um. Para cada linha na tabela Produtos, há no máximo uma linha na tabela ProductExtras. O mesmo productID deve ser usado como chave primária para ambas as tabelas.

Vantagem

Independência estrutural

No modelo de banco de dados relacional, as alterações na estrutura do banco de dados não afetam o acesso aos dados.

Quando é possível fazer alterações na estrutura do banco de dados sem afetar a capacidade do SGBD de acessar os dados, pode-se dizer que a independência estrutural foi alcançada.

Simplicidade conceitual

O modelo de banco de dados relacional é ainda mais conceitualmente simples do que o modelo de banco de dados hierárquico ou de rede.

Uma vez que o modelo de banco de dados relacional libera o designer dos detalhes do armazenamento físico dos dados, os designers podem se concentrar na visão lógica do banco de dados.

Facilidade de design, implementação, manutenção e uso

O modelo de banco de dados relacional atinge tanto a independência de dados quanto a independência de estrutura, o que torna o projeto, a manutenção, o gerenciamento e o uso do banco de dados muito mais fácil do que outros modelos.

Capacidade de consulta ad-hoc

A presença de uma capacidade de consulta muito poderosa, flexível e fácil de usar é uma das principais razões para a imensa popularidade do modelo de banco de dados relacional.

A linguagem de consulta do modelo de banco de dados relacional, chamada linguagem de consulta estruturada ou SQL, torna as consultas ad-hoc uma realidade. SQL é uma linguagem de quarta geração (4GL).

Um 4GL permite ao usuário especificar o que deve ser feito, sem especificar como deve ser feito. Assim, com o SQL, os usuários podem especificar quais informações desejam e deixar os detalhes de como obter as informações para o banco de dados.

Desvantagens

Despesas de hardware

O modelo de banco de dados relacional oculta as complexidades de sua implementação e os detalhes do armazenamento físico dos dados do usuário.

Para fazer isso, os sistemas de banco de dados relacionais precisam de computadores com hardware mais poderoso e dispositivos de armazenamento de dados.

Portanto, o RDBMS precisa de máquinas poderosas para funcionar sem problemas. No entanto, como o poder de processamento dos computadores modernos está aumentando a uma taxa exponencial, a necessidade de mais poder de processamento no cenário atual não é mais um grande problema.

A facilidade de design pode levar a um design ruim

O banco de dados relacional é fácil de projetar e usar. Os usuários não precisam conhecer os detalhes complexos do armazenamento físico de dados. Eles não precisam saber como os dados são realmente armazenados para acessá-los.

Essa facilidade de design e uso pode levar ao desenvolvimento e implementação de sistemas de gerenciamento de banco de dados mal projetados. Como o banco de dados é eficiente, essas ineficiências de design não virão à tona quando o banco de dados for projetado e quando houver apenas uma pequena quantidade de dados.

Conforme o banco de dados cresce, bancos de dados mal projetados tornam o sistema lento e levam à degradação do desempenho e à corrupção de dados.

Fenômeno das «ilhas de informação»

Como mencionado antes, os sistemas de banco de dados relacionais são fáceis de implementar e usar. Isso criará uma situação em que muitas pessoas ou departamentos criarão seus próprios bancos de dados e aplicativos.

Estas ilhas de informação impedirão a integração de informação, essencial para o bom e eficiente funcionamento da organização.

Esses bancos de dados individuais também criarão problemas como inconsistência de dados, duplicação de dados, redundância de dados, etc.

Exemplo

Suponha que um banco de dados consista nas tabelas Fornecedores, Peças e Remessas. A estrutura das tabelas e alguns registros de amostra são os seguintes:

Cada linha na tabela de Fornecedores é identificada por um número de fornecedor exclusivo (SNo), identificando exclusivamente cada linha na tabela. Da mesma forma, cada peça possui um número de peça exclusivo (PNo).

Além disso, não pode haver mais de uma remessa para uma determinada combinação Fornecedor / Peça na tabela Remessas, uma vez que essa combinação é a chave primária das Remessas, que funciona como uma tabela de união, pois é uma relação muitos-para-muitos.

A relação entre as tabelas de Peças e Remessas é dada por ter o campo PNo (número da peça) em comum e a relação entre Fornecedores e Remessas surge por ter o campo SNo (número do fornecedor) em comum.

Analisando a tabela de Remessas, pode-se obter a informação de que um total de 500 castanhas estão sendo enviadas de fornecedores Suneet e Ankit, 250 cada.

Da mesma forma, 1.100 parafusos no total foram enviados de três fornecedores diferentes. 500 parafusos azuis foram enviados do fornecedor Suneet. Não há remessas de parafusos vermelhos.

Referências

1. Wikipedia, a enciclopédia livre (2019). Modelo relacional. Retirado de: en.wikipedia.org.
2. Techopedia (2019). Modelo Relacional. Retirado de: roofpedia.com.
3. Dinesh Thakur (2019). Modelo Relacional. Notas do Ecomputer. Retirado de: ecomputernotes.com.
4. Geeks for Geeks (2019). Modelo Relacional. Retirado de: geeksforgeeks.org.
5. Universidade Tecnológica de Nanyang (2019). Um tutorial de início rápido sobre design de banco de dados relacional. Retirado de: ntu.edu.sg.
6. Adrienne Watt (2019). Capítulo 7 O modelo de dados relacional. Livros didáticos abertos do BC. Retirado de: opentextbc.ca.
7. Toppr (2019). Bancos de dados relacionais e esquemas. Retirado de: toppr.com.