Banco de dados relacional

Origem: Wikipdia, a enciclopdia livre.

Um banco de dados relacional um banco de dados que modela os dados de uma forma que eles sejam
percebidos pelo usurio como tabelas, ou mais formalmente relaes.

O termo aplicado aos prprios dados, quando organizados dessa forma, ou a um Sistema Gerenciador de
Banco de Dados Relacional (SGBDR) do ingls Relational database management system (RDBMS)
um programa de computador que implementa a abstrao.

ndice
1 Histrico
1.1 As 13 regras
2 Por que usar um Banco de Dados Relacional?
3 O Modelo Relacional
3.1 Tabelas (ou relaes, ou entidades)
3.2 Registros (ou tuplas)
3.3 Colunas (atributos)
3.4 Chave
4 Relacionamentos
5 Modelagem
5.1 Normalizao
5.2 Dependncia Funcional
5.3 Primeira Forma Normal (FN1)
5.4 Segunda Forma Normal (FN2)
5.5 Terceira Forma Normal (FN3)
6 Ver tambm
7 Referncias

Histrico
Os Bancos de dados relacionais (BDR) surgiram em meados da dcada de 1970. Porm, apenas alguns anos
mais tarde as empresas passaram a utiliz-los no lugar de arquivos simples (do ingls flat file), bancos de dados
hierrquicos e em rede.

As 13 regras

Em 1985, Edgar Frank Codd, criador do modelo relacional, publicou um artigo onde definia 13 regras para que
um Sistema Gerenciador de Banco de Dados (SGBD) fosse considerado relacional:

1. Regra Fundamental:
Um SGBD relacional deve gerir os seus dados usando apenas suas capacidades relacionais
2. Regra da informao:
Toda informao deve ser representada de uma nica forma, como dados em uma tabela
3. Regra da garantia de acesso:
Todo o dado (valor atmico) pode ser acedido logicamente (e unicamente) usando o nome da
tabela, o valor da chave primria da linha e o nome da coluna.
4. Tratamento sistemtico de valores nulos:
 Os valores nulos (diferente do zero, da string vazia, da string de caracteres em brancos e outros
valores no nulos) existem para representar dados no existentes de forma sistemtica e
independente do tipo de dado.
5. Catlogo dinmico on-line baseado no modelo relacional:
A descrio do banco de dados representada no nvel lgico como dados ordinrios (isto , em
tabelas), permitindo que usurios autorizados apliquem as mesmas formas de manipular dados
aplicada aos dados comuns ao consult-las.
6. Regra da sub-linguagem abrangente:
Um sistema relacional pode suportar vrias linguagens e formas de uso, porm deve possuir ao
menos uma linguagem com sintaxe bem definida e expressa por cadeia de caracteres e com
habilidade de apoiar a definio de dados, a definio de vises, a manipulao de dados, as
restries de integridade, a autorizao e a fronteira de transaes.
7. Regra da atualizao de vises:
Toda viso que for teoricamente atualizvel ser tambm atualizvel pelo sistema.
8. Insero, atualizao e eliminao de alto nvel:
Qualquer conjunto de dados que pode ser manipulado com um nico comando para retornar
informaes, tambm deve ser manipulado com um nico comando para operaes de insero,
atualizao e excluso. Simplificando, significa dizer que as operaes de manipulao de dados
devem poder ser aplicadas a vrias linhas de uma vez, ao invs de apenas uma por vez.
9. Independncia dos dados fsicos:
Programas de aplicao ou atividades de terminal permanecem logicamente inalteradas quaisquer
que sejam as modificaes na representao de armazenagem ou mtodos de acesso internos.
10. Independncia lgica de dados
Programas de aplicao ou atividades de terminal permanecem logicamente inalteradas quaisquer
que sejam as mudanas de informao que permitam teoricamente a no alterao das tabelas base.
11. Independncia de integridade:
As relaes de integridade especficas de um banco de dados relacional devem ser definidas em
uma sub-linguagem de dados e armazenadas no catlogo (e no em programas).
12. Independncia de distribuio:
A linguagem de manipulao de dados deve possibilitar que as aplicaes permaneam inalteradas
estejam os dados centralizados ou distribudos fisicamente.
13. Regra da No-subverso:
Se o sistema relacional possui uma linguagem de baixo nvel (um registro por vez), no deve ser
possvel subverter ou ignorar as regras de integridade e restries definidas no alto nvel (muitos
registros por vez).

Por que usar um Banco de Dados Relacional?

Os Bancos de Dados Relacionais foram desenvolvidos para prover acesso facilitado aos dados, possibilitando
que os usurios utilizassem uma grande variedade de abordagens no tratamento das informaes. Pois,
enquanto em um banco de dados hierrquico os usurios precisam definir as questes de negcios de maneira
especfica, iniciando pela sua raiz , nos Bancos de Dados Relacionais os usurios podem fazer perguntas
relacionadas aos negcios por meio de vrios pontos. A linguagem padro dos Bancos de Dados Relacionais
a Structured Query Language, ou simplesmente SQL, como mais conhecida.

O Modelo Relacional
Um Banco de Dados Relacional segue o Modelo Relacional.

A arquitetura de um banco de dados relacional pode ser descrita de maneira informal ou formal. Na descrio
informal estamos preocupados com aspectos prticos da utilizao e usamos os termos tabela, linha e coluna.
Na descrio formal estamos preocupados com a semntica formal do modelo e usamos termos como relao
(tabela), tupla(linhas) e atributo(coluna).

Tabelas (ou relaes, ou entidades)

Todos os dados de um banco de dados relacional (BDR) so armazenados em tabelas. Uma tabela uma
simples estrutura de linhas e colunas. Em uma tabela, cada linha contm um mesmo conjunto de colunas. Em
um banco de dados podem existir uma ou centenas de tabelas, sendo que o limite pode ser imposto tanto pela
ferramenta de software utilizada, quanto pelos recursos de hardware disponveis no equipamento.

As tabelas associam-se entre si por meio de regras de relacionamentos, que consistem em associar um ou vrios
atributos de uma tabela com um ou vrios atributos de outra tabela.

Exemplo: A tabela funcionrio relaciona-se com a tabela cargo. Por este relacionamento, esta ltima
tabela fornece a lista de cargos para a tabela funcionrio.

Modelo terico usado para representar conceitualmente um BD, Idealizado por Codd (1970). Baseado numa
estrutura de dados simples chamada relao. o modelo mais amplamente usado, principalmente em
aplicaes convencionais de BD.

Registros (ou tuplas)

Cada linha formada por uma lista ordenada de colunas representa um registro, ou tupla. Os registros no
precisam conter informaes em todas as colunas, podendo assumir valores nulos quando assim se fizer
necessrio.

Resumidamente, um registro uma instncia de uma tabela, ou entidade. O start da modelagem se d a partir
das ENTIDADES. Uma entidade uma representao de um conjunto de informaes sobre determinado
conceito do sistema. Toda entidade possui ATRIBUTOS, que so as informaes que referenciam a entidade.
Para exemplificar no sistema de controle de Biblioteca, partimos do conceito principal que o emprstimo de
obras por usurios da biblioteca. A partir deste conceito inicial, vamos ramificando e descobrindo novos
conceitos. Podemos iniciar nosso raciocnio da seguinte forma:

"Uma biblioteca possui Obras literrias que podem ser tomadas em emprstimos pelos usurios credenciados."

Podemos rapidamente enxergar um cadastro de livros, um cadastro de usurios e um registro de emprstimos,

certo? essa viso que temos que ter ao modelarmos um banco, isto , devemos detectar as informaes que
devemos armazenar.

Para identificar se aquele conceito pode ser uma entidade voc deve apenas se perguntar: "Eu desejo armazenar
quais informaes sobre este conceito ?" Se houver informaes a serem armazenadas, voc tem uma
ENTIDADE. Exemplificando: Eu desejo armazenar os seguintes dados do livro: Ttulo, Autor, Editora, Ano,
Edio e Volume. Temos ento a entidade Livro.

Exemplo: O empregado Pedro uma instncia (registro) da tabela funcionrio, e a funo Analista
Comercial a instncia (registro) da tabela cargo. Uma associao entre estas duas tabelas criaria a
seguinte instncia de relacionamento: Pedro Analista Comercial, onde o verbo ser representa uma
ligao entre os registros distintos.

Colunas (atributos)

As colunas de uma tabela so tambm chamadas de atributos. Ex.: O campo Nome, ou endereo de uma tabela
de um BD relacional.

Chave

As tabelas relacionam-se umas as outras atravs de chaves. Uma chave um conjunto de um ou mais atributos
que determinam a unicidade de cada registro.
Por exemplo, se um banco de dados tem como chaves Cdigo do Produto e ID Sistema, sempre que acontecer
uma insero de dados o sistema de gerenciamento de banco de dados ir fazer uma consulta para identificar se
o registro j no se encontra gravado na tabela. Neste caso, um novo registro no ser criado, resultando esta
operao apenas da alterao do registro existente.

A unicidade dos registros, determinada por sua chave, tambm fundamental para a criao dos ndices.

Temos dois tipos de chaves:

Chave primria: (PK - Primary Key) um identificador exclusivo de todas as informaes de cada
registro dando-lhe unicidade. A chave primria nunca se repetir.[1]

Chave Estrangeira: (FK - Foreign Key) a chave formada atravs de um relacionamento com a chave
primria de outra tabela. Define um relacionamento entre as tabelas e pode ocorrer repetidas vezes. Caso
a chave primria seja composta na origem, a chave estrangeira tambm o ser.

Relacionamentos
Com o advento do Modelo de Entidades e Relacionamentos foi causada uma confuso entre os termos relao
e relacionamento

O Modelo Relacional, quando descrito de forma matemtica, definido como um modelo formado por relaes
(no sentido matemtico) entre os domnios. Cada tupla um elemento do conjunto relao.

Ou seja, a relao a tabela.

Um relacionamento do Modelo de Entidades e Relacionamentos uma associao entre entidades distintas.

No h relao direta entre o nome relacionamento e o nome relao.

Porm, um relacionamento, do Modelo de Entidades e Relacionamentos traduzido para a criao de atributos

com chaves externas do Modelo Relacional. Esta traduo feita ligando-se um campo de uma tabela X com
um campo de uma tabela Y, por meio da incluso do campo chave da tabela Y como um campo (conhecido
como chave estrangeira) da tabela X.

Por meio das chaves estrangeiras, possvel implementar restries nos SGBDR.

Existem alguns tipos de relacionamentos possveis no MER:

Um para um (1 para 1) - indica que as tabelas tm relao unvoca entre si. Voc escolhe qual tabela vai
receber a chave estrangeira;
Um para muitos (1 para N) - a chave primria da tabela que tem o lado 1 est para ir para a tabela do lado
N. No lado N ela chamada de chave estrangeira;
Muitos para muitos (N para N) - quando tabelas tm entre si relao n..n, necessrio criar uma nova
tabela com as chaves primrias das tabelas envolvidas, ficando assim uma chave composta, ou seja,
formada por diversos campos-chave de outras tabelas. A relao ento se reduz para uma relao 1..n,
sendo que o lado n ficar com a nova tabela criada.

Os relacionamentos 1 para 1 e 1 para N podem ser mapeados diretamente em chaves estrangeiras nas tabelas
originais. J o relacionamento N para N exige o uso de uma tabela auxiliar. No relacionamento N:N no h
chave estrangeira.

Modelagem
Normalizao
A normalizao de dados um processo que simplifica grupos complexos de dados para evitar redundncias e
possibilitar um maior desempenho nas pesquisas.[1]

o processo de organizao eficiente dos dados dentro de um banco de dados cujos objetivos principais so:

1. Eliminar dados redundantes (por exemplo, armazenando os mesmos dados em mais de uma tabela).
2. Garantir que as dependncias entre os dados faam sentido (armazenando apenas dados logicamente
relacionados em uma tabela).

Existem cinco estgios de normalizao, 1, o 2, o 3, o 4 e o 5. Para um banco de dados se encontrar em

cada um desses estgios ou formas (denominadas formas normais), cada uma de suas tabelas deve atender a
alguns pr-requisitos. Os pr-requisitos so cumulativos, isto , para alcanar a 3 forma normal (3NF), um
banco de dados precisa atender aos pr-requisitos das 1 e 2 formas normais, acrescidos dos requisitos
exclusivos da 3NF.

Dependncia Funcional

Um atributo B possui uma dependncia funcional do atributo A se, para cada valor do atributo A, existe
exatamente um nico valor do atributo B. A dependncia funcional representada por A B.

Exemplo: Observe os conjuntos:

Cliente
CPF Nome
1 Jos
2 Joo
3 Gabriel
4 M. Guedes

Observe que existe uma dependncia entre os valores dos conjuntos, ou seja, nome funo do CPF, se eu
estiver com numero do CPF, poderei encontrar o nome da pessoa correspondente.

Essa dependncia expressa por:

CPF Nome

Leia da seguinte maneira: - com um nmero de CPF posso encontrar nome da pessoa, ou - nome depende da
funcionalidade do CPF.

Primeira Forma Normal (FN1)

Uma relao est na primeira forma normal se os valores de seus atributos so atmicos (simples, indivisveis)
e monovalorados. Em outras palavras, FN1 no permite relaes dentro de relaes ou relaes como
atributos de tuplas[2]. Uma tabela est na primeira forma normal quando seus atributos no contm grupos de
repetio, ou seja, multivalorados.

Exemplo:
 Cliente
ClienteID Nome Telefone
123 Rachel Ingram 555-861-2025
555-403-1659
456 James Wright
555-776-4100
789 Maria Fernandez 555-808-9633

Esta tabela logo acima no est na primeira forma normal porque apresenta grupos de repetio (possibilidade
de mais de um telefone por cliente).

J estas tabelas logo abaixo, Cliente e Telefone, esto na primeira forma normal.

Tabela Cliente:

Cliente
ClienteID Nome
123 Rachel
456 James
789 Maria

Tabela Telefone:

Telefone
ClienteID Telefone
123 555-861-2025
456 555-403-1659
456 555-776-4100
789 555-808-9633

Segunda Forma Normal (FN2)

Uma relao est na FN2 quando duas condies so satisfeitas:

1 - A relao est na 1FN;

2 - Todo atributo da tabela seja dependente funcional da chave completa e no de parte da chave. Ou seja,
Todos os atributos no-chave dependem funcionalmente de toda a chave primria.

Terceira Forma Normal (FN3)

A 3FN exige que no existam atributos transitivamente dependentes da chave.

Um exemplo de uma tabela 2FN que no atende o critrio para 3FN :

Vencedores de Torneios
Torneio Ano Vencedor Data de nascimento do vencedor
Indiana Invitational 1998 Al Fredrickson 21 de julho de 1975
Cleveland Open 1999 Bob Albertson 28 de setembro de 1968
Des Moines Masters 1999 Al Fredrickson 21 de julho de 1975
Indiana Invitational 1999 Chip Masterson 14/3/1977
A chave primria composta {Torneio, Ano}.

A tabela no est na terceira forma normal porque o atributo "data de nascimento do vencedor" dependente
transitivamente de {Torneio, Ano} via o atributo "Vencedor". O fato da data de nascimento do vencedor no ser
dependente do vencedor torna a tabela vulnervel a inconsistncias lgicas, j que nada impediria de uma
mesma pessoa aparecer com datas de nascimento diferentes em dois registros.

Para atender a terceira forma normal, a mesma informao deveria ser dividida em duas tabelas:

Vencedores de Torneios
Torneio Ano Vencedor
Indiana Invitational 1998 Al Fredrickson
Cleveland Open 1999 Bob Albertson
Des Moines Masters 1999 Al Fredrickson
Indiana Invitational 1999 Chip Masterson

Datas de nascimento de jogadores

Jogador Data de nascimento
Chip Masterson 14/3/1977
Al Fredrickson 21 de julho de 1975
Bob Albertson 28 de setembro de 1968

As duas tabelas acima esto na terceira forma normal.

Ver tambm
Administrao de dados
Banco de dados
Data warehouse
Cincia da Computao
Arquitetura de dados
Modelo de Entidades e Relacionamentos

Referncias
1. Laudon, Kenneth; Jane (2011). Sistemas de Informao gerenciais. [S.l.: s.n.] ISBN 9788576059233
2. Cercola, Osvaldo Vicente (1991). Banco de Dados Relacional e Distribudo. Rio de Janeiro: LTC. p. 115. ISBN 85-
216-0769-5

Obtida de "https://pt.wikipedia.org/w/index.php?title=Banco_de_dados_relacional&oldid=47959773"

Categorias: SGBDs Modelo relacional Tipos de bancos de dados

Esta pgina foi modificada pela ltima vez (s) 17h55min de 8 de fevereiro de 2017.
Este texto disponibilizado nos termos da licena Creative Commons - Atribuio - Compartilha Igual
3.0 No Adaptada (CC BY-SA 3.0); pode estar sujeito a condies adicionais. Para mais detalhes,
consulte as condies de uso.