O modelo relacional de bancos de dados é 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..
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 uma relação 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..
Índice do artigo
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, permitem que o software do sistema de gerenciamento de banco de dados se encarregue de descrever as estruturas de dados a serem armazenadas 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.
- 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 posição de linha / coluna na tabela, há apenas um único valor.
A figura a seguir mostra uma tabela com os nomes de seus elementos básicos, que compõem uma estrutura completa.
Cada linha de dados é uma tupla, também conhecida como registro. Cada linha é uma n-tupla, mas o "n-" geralmente é descartado.
Cada coluna em uma tupla é chamada de atributo ou campo. A coluna representa o conjunto de valores que um atributo específico pode ter.
Cada linha possui uma ou mais colunas chamadas de 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.
Ao projetar o modelo relacional, você define algumas condições que devem ser atendidas no banco de dados, chamadas de regras de integridade.
A chave primária deve ser exclusiva para todas as tuplas e não pode ser nula. Caso contrário, você não será capaz de identificar exclusivamente a linha.
Para uma chave de várias colunas, nenhuma dessas colunas pode conter NULL.
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 pai, atualizando ou deletando a linha, então todas as linhas nas tabelas filho com esta chave estrangeira devem ser atualizadas ou deletadas de acordo.
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..
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.
Um banco de dados que consiste em tabelas independentes e não relacionadas tem pouco propósito.
O aspecto mais crucial no projeto de um banco de dados relacional é identificar os relacionamentos entre as tabelas. Os tipos de relacionamento são:
Em um banco de dados de "Listagem de turmas", um professor pode dar zero ou mais turmas, enquanto uma turma é 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 você enfrentaria um problema: quantas colunas criar.
Por outro lado, se você tiver uma tabela chamada Classes, que armazena informações sobre uma classe, poderá criar colunas adicionais para armazenar informações sobre o professor..
No entanto, como um professor pode ensinar em muitas turmas, seus dados seriam duplicados em muitas linhas da tabela Classes.
Portanto, duas tabelas precisam ser projetadas: 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..
Em seguida, o relacionamento um-para-muitos pode ser criado, armazenando a chave primária da tabela Master (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.
Em um banco de dados de "Venda de produtos", o pedido de um cliente pode conter vários produtos, e um produto pode aparecer em vários pedidos. Este 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 o ID do pedido como chave primária.
Você não pode armazenar os produtos pedidos na tabela Pedidos, pois você não sabe quantas colunas reservar para os produtos. Nem os pedidos podem ser armazenados na tabela de 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..
No banco 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.
No modelo de banco de dados relacional, as mudanças 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.
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.
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, manutenção, administração e uso do banco de dados muito mais fácil do que os outros modelos..
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 Structured Query Language, ou SQL, torna as consultas ad hoc uma realidade. SQL é uma linguagem de quarta geração (4GL).
A 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.
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 e dispositivos de armazenamento de dados mais poderosos..
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..
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. Uma vez que 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 mais lento e levam à degradação do desempenho e corrupção de dados..
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..
Suponha um banco de dados que consiste 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 tem um número de peça único (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 das tabelas 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 ser obtido como informação 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. Nenhum envio de parafusos vermelhos.
Ainda sem comentários