Elementos do modelo de banco de dados relacionais, como fazer isso, exemplo

Ele Modelo relacional de bancos de dados É um método para estruturar dados usando relacionamentos, através de estruturas em forma de grade, que consistem em colunas e linhas. É o princípio conceitual dos bancos de dados relacionais. Foi proposto por Edgar F. CODD em 1969.

Desde então, tornou -se o modelo de banco de dados dominante para aplicativos comerciais, se comparado a outros modelos de banco de dados, como hierárquico, rede e objeto.

Fonte: Pixabay.com

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

O modelo relacional é definido como o banco de dados que permite agrupar seus elementos de dados em uma ou mais tabelas independentes, que podem estar relacionadas entre si usando campos comuns para cada tabela relacionada.

[TOC]

Gerenciamento de banco de dados

Um 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 eficientemente uma grande quantidade de dados, que podem ser recuperados efetivamente.

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

Por outro lado, eles permitem.

A maioria dos bancos de dados relacionais usa o idioma SQL para a consulta e definição dos dados. Atualmente, existem muitos sistemas de gerenciamento de banco de dados relacionais ou RDBMS (Relational Data Base Management System), como Oracle, IBM DB2 e Microsoft SQL Server.

Características e elementos

- Todos os dados são conceitualmente representados como uma disposição ordenada de dados em linhas e colunas, chamadas de relacionamento ou tabela.

- Cada mesa 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, organizada em linhas.

- Todos os valores são subidas. Isto é, em qualquer posição de linha/coluna na tabela, há apenas um valor único.

-Unid

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 é um TUPLA, também conhecido como registro. Cada linha é um n-tupla, mas o "n-" é geralmente descartado.

Coluna

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

Dica

Cada linha tem uma ou mais colunas chamadas de tabela. Este valor combinado é único para todas as fileiras de uma tabela. Através dessa chave, cada tupla será identificado de maneira unívoca. Isto é, a chave não pode ser duplicada. É chamado de chave primária.

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

-Regras de integridade

Ao projetar o modelo relacional, algumas condições que devem ser atendidas no banco de dados, chamadas regras de integridade são definidas.

Pode atendê -lo: Macrocomputadores: História, Características, Usos, Exemplos

Principal integridade

A chave primária deve ser única para todas as tuplas e não pode ter o valor nulo (nulo). Caso contrário, você não poderá identificar a linha exclusivamente.

Para uma chave composta por várias colunas, nenhuma dessas colunas pode conter nulo.

Integridade referencial

Cada valor de uma chave externa deve coincidir com um valor da chave primária na tabela referenciada ou primária.

Na tabela secundária, apenas uma linha pode ser inserida com uma chave externa se esse valor existir em uma tabela primária.

Se o valor das principais alterações na tabela primária, para atualizar ou eliminar a linha, todas as linhas nas tabelas secundárias com essa chave externa devem ser atualizadas ou eliminadas de acordo.

Como fazer um modelo relacional?

-Coletar dados

Os dados necessários para armazená -los no banco de dados devem ser coletados. 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.

-Defina as chaves primárias

Para cada tabela, você deve escolher uma coluna (ou poucas colunas) como uma chave primária, que identificará exclusivamente cada linha da tabela. A chave primária também é usada para se referir a outras tabelas.

-Crie relacionamentos entre tabelas

Um banco de dados que consiste em tabelas independentes e não relacionadas tem pouco propósito.

O aspecto mais crucial no design de um banco de dados relacional é identificar as relações entre as tabelas. Os tipos de relacionamento são:

Um para muitos

Em um banco de dados de "aulas", um professor pode dar zero ou mais aulas, enquanto uma aula é ensinada por um único professor. Este tipo de relacionamento é conhecido como um a muitos.

Este relacionamento não pode ser representado em uma única tabela. No banco de dados "Listagem de classe", você pode ter uma tabela chamada Professores, que armazena informações sobre professores.

Para armazenar as aulas ministradas por cada professor, colunas adicionais podem ser criadas, mas um problema enfrentaria: quantas colunas criam.

Por outro lado, se você tiver uma tabela chamada Classes, ele armazena informações sobre uma aula, colunas adicionais podem ser criadas para armazenar informações sobre o professor.

No entanto, como professor pode dar em muitas aulas, seus dados seriam dobrados em muitas fileiras na tabela de aulas.

Projete duas tabelas

Portanto, duas tabelas precisam ser projetadas: uma tabela de aulas para armazenar informações sobre aulas, com a classe com a chave principal e uma tabela mestre para armazenar informações sobre professores, com professor_id como a chave principal.

Então você pode criar o relacionamento um para muitos armazenando a chave primária da tabela mestre (master_id) na tabela de aulas, como ilustrado abaixo.

A coluna master_id na tabela de classes é conhecida como chave externa ou secundária.

Para cada valor master_id na tabela mestre, pode haver zero ou mais linhas na tabela de classes. Para cada valor de classe_id na tabela de classes, há apenas uma linha na tabela mestre.

Muitos para muitos

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.

Pode atendê -lo: TIC (tecnologias de informação e comunicação)

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

Por outro lado, os pedidos contêm pedidos de clientes, com solicitação como código primário.

Você não pode armazenar os produtos solicitados na tabela ordenada, pois não se sabe quantas colunas se reservam para os produtos. Nem os pedidos podem ser armazenados nos produtos da tabela pelo mesmo motivo.

Para admitir um relacionamento muitos para muitos, é necessário criar uma terceira tabela, conhecida como tabela de união (solicitando), onde cada linha representa um elemento de uma ordem específica.

Para a tabela de solicitação, a chave primária consiste em duas colunas: ordem e produto, identificando cada linha cada linha.

As colunas solicitadas e de produtos na solicitação de métodos são usadas para fazer referência aos pedidos e produtos. Portanto, eles também são chaves externas para o pedido de solicitação.

Um a um

No banco de dados de "venda de produtos", um produto pode ter informações opcionais, como uma descrição adicional e sua imagem. Mantenha -o dentro dos produtos geraria muitos espaços vazios.

Portanto, você pode criar outra tabela (Excexts Product) para armazenar dados opcionais. Apenas um registro para produtos com dados opcionais será criado.

As duas tabelas, produtos e produtos, têm um relacionamento de um -aone. Para cada linha na tabela de produtos, há uma linha máxima no produto Tablexts. O mesmo produto deve ser usado como a chave principal para as duas tabelas.

Vantagens

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 dos DBMs 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 simples no nível conceitual do que o modelo hierárquico ou a rede de banco de dados.

Como o modelo de banco de dados relacional libera o designer a partir dos detalhes do armazenamento físico dos dados, os designers podem se concentrar na visualização lógica do banco de dados.

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

O modelo de banco de dados relacional alcança a independência dos dados e a independência da estrutura, o que torna muito mais fácil o design, manutenção, administração e uso do banco de dados do que os outros modelos.

Capacidade de consulta ad-hoc

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

O idioma de consulta do modelo de banco de dados relacional, chamado de linguagem de consulta estruturada ou SQL, torna as consultas ad-hoc se tornarem 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 os usuários do SQL pode especificar quais informações desejam e deixar os detalhes sobre 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.

Pode atendê -lo: o que são códigos g? (Com exemplo)

Para fazer isso, os sistemas de banco de dados relacionais precisam de computadores com hardware e armazenamento 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 em um ritmo exponencial, a necessidade de mais poder de processamento no cenário atual não é mais um problema muito grande.

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 dos dados. Eles não precisam saber como os dados são realmente armazenados para acessá -los.

Esse design e uso de facilidade podem levar ao desenvolvimento e implementação de sistemas de gerenciamento de banco de dados muito 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.

À medida que o banco de dados cresce, os bancos de dados mal projetados diminuem o sistema e causarão uma degradação do desempenho e corrupção dos dados.

Fenômeno de "Ilhas da Informação"

Como dito 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.

Essas ilhas de informação evitarão a integração da informação, o que é essencial para o funcionamento fluido e eficiente 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 que consiste nas mesas, peças e remessas que suputas. A estrutura das tabelas e alguns registros de amostra são apresentados abaixo:

Cada linha na tabela de suprimentos é identificada por um número único de fornecedores (SNO), identificando de forma única cada linha da 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 um determinado fornecedor / combinação de peças na tabela de remessa, uma vez que essa combinação é a chave de remessa primária, que serve como uma tabela de união, pois muitos são um relacionamento para muitos para muitos.

A relação das tabelas e remessas é dada por ter em comum o campo PNO (número da peça) e a relação entre fornecedores e remessas surge de ter em comum o campo SNO (número do fornecedor).

Analisar a tabela de remessas pode ser obtida como informações que estão sendo enviadas um total de 500 nozes dos fornecedores de sol e ankit, 250 cada.

Da mesma forma, 1 foi enviado.100 parafusos no total de três fornecedores diferentes. 500 parafusos azuis foram enviados do fornecedor do sol. Não há remessas de parafuso vermelho.

Referências

1. Wikipedia, The Free Encyclopedia (2019). Modelo relacional. Retirado de: em.Wikipedia.org.
2. Ravepedia (2019). Modelo relacional. Retirado de: ravepedia.com.
3. Diesh Thakur (2019). Modelo relacional. Notas 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 partida rápida sobre design de banco de dados relacional. Retirado de: NTU.Edu.Sg.
6. Adrienne Watt (2019). Capítulo 7 O Modelo de Dados Relacionários. BC Livros Abertos. Retirado de: OpenTextBC.AC.
7. TOPPR (2019). Bancos de dados e esquemas relacionais. Retirado de: TOPPR.com.