Escola SENAI Antnio Souza Noschese

Vincius de Oliveira Gama Vitor de Almeida

Banco de Dados Relacional

Santos SP 2012

Vincius de Oliveira Gama Vitor de Almeida

Banco de Dados Relacional

Trabalho avaliao

apresentado no

para

componente

curricular BCD Banco de Dados. Orientador: Prof. Lidiane

Santos SP 2012

Vincius de Oliveira Gama Vitor de Almeida

Banco de Dados Relacional

Trabalho apresentado para avaliao no componente

curricular BCD Banco de Dados. Orientador: Prof. Lidiane

Folha de Avaliao

___________________________________ Prof. Lidiane Orientador Escola SENAI Antnio Souza Noschese

Santos, SP ___ de ___________ de2012

Resumo
A tecnologia de banco de dados tem evoludo rapidamente nas ltimas trs dcadas desde a ascenso e eventual domnio dos sistemas de banco de dados relacionais. Enquanto muitos sistemas de bancos de dados especializados (orientado a objeto, espacial, multimdia, etc.) tm encontrado usurios substanciais nas comunidades cientficas e engenharia, os sistemas relacionais continuam dominando a tecnologia de banco de dados para negcios empresariais. O banco de dados relacional gerou uma indstria multibilionria, o tipo mais utilizado de banco de dados no mundo de hoje, e uma parte essencial de nossas vidas cotidianas. muito provvel que estejamos usando um banco de dados relacional toda vez que compramos mercadorias em uma loja, fazemos planos de viagem com um agente de viagens, conferimos um livro na biblioteca, ou fazemos uma compra na Internet. Esse trabalho tem por finalidade mostrar o funcionamento desse modelo de banco de dados bem como as regras empregadas em sua formao.

Palavras-chave: Banco de dados, Banco de dados relacional, BCD

Summary

The database technology has evolved rapidly over the past three decades since the rise and eventual dominance of systems relational database. While many systems specialized databases (object-oriented, spatial, multimedia, etc..) Users have found substantial scientific and engineering communities, systems continue to dominate the relational database technology for enterprise business. The relational database spawned a multibillion dollar industry, is the most used database in the world today, and is an essential part of our everyday lives. It is very likely that we are using a relational database every time we buy goods in a store, make travel plans with a travel agent, we checked a book in the library, or make a purchase on the Internet. This study aims to show the functioning of this model database and rules used in its formation.

Keywords: Databases, Relational Database, DB

Sumrio
1. Introduo......................................................................................................1 2. Histria............................................................................................................1 2.1. Surgimento do banco de dadosrelacional.....................................................1 2.2. As 13 Regras de Frank Codd.......................................................................2 3. O modelo relacional.......................................................................................4 3.1. Tabelas.........................................................................................................4 3.2. Colunas.........................................................................................................4 3.3. Linhas ..........................................................................................................4 3.4. Valores..........................................................................................................4 3.5. Chaves..........................................................................................................5 4. Relacionamentos...........................................................................................5 4.1. Um para um..................................................................................................5 4.2. Um para muitos.............................................................................................6 4.3. Muitos para muitos........................................................................................6 5. Modelagem.....................................................................................................6 5.1. Normalizao................................................................................................6 5.2. Primeira forma normal (FN1)........................................................................7 5.3. Segunda forma normal (FN2).......................................................................8 5.4. Terceira forma normal (FN3)........................................................................9 5.5. Quarta forma normal (FN4).........................................................................10 5.6. Quinta forma normal (FN5).........................................................................11 6. Concluso.....................................................................................................12 7. Referncias...................................................................................................12

1. Introduo

Com o constante aumento do fluxo de informao digital nos dias atuais, impossvel no se pensar em como organizado e armazenado todos esses dados. Pois quanto maior a quantidade que se tem, mais difcil se torna guardar esses dados. Pensando nisso, esse trabalho foi desenvolvido com o objetivo de apresentar um pouco da histria do banco de dado relacionale tambm se aprofundar no estudo desse modelo e sua formao.

2. Histria

2.1 Surgimento do banco de dados relacional Na dcada de 1950 e nos primeiros anos da dcada de 1960, o armazenamento e acesso aos dados eram ainda bastante rudimentares. Enquanto algumas iniciativas de projetos mais avanados estavam em andamento e at mesmo em uso por um nmero muito restrito de pessoas, a grande maioria dos desenvolvedores ainda armazenava dados em arquivos de texto. Tais arquivos eram normalmente formados por campos de tamanho fixo, e o acesso a eles no requeria mais do que as operaes de leitura e escrita em arquivos. Embora essa fosse uma metodologia bastante simples para armazenamento de dados, no tardou par que se percebesse que ela no era a forma mais eficiente, na maioria dos casos. Visando resolver esse problema, foi criada pelo Departamento de Defesa dos Estados Unidos da Amrica, em 1957, a Conferenceon Data Systems Languages (Conferncia sobre as Linguagens de Sistemas de Dados), tambm conhecida simplesmente por CODASYL, para desenvolver linguagens de programao de computador voltadas para o armazenamento de dados. CODASYL famosa pela criao da linguagem de programao COBOL, como tambm pela criao da base de todos os sistemas de armazenamento de dados desde ento. Em 19070, Edgar Codd, um cientista da computao britnico que trabalhava na IBM, publicou um artigo chamado A Relational Modelo f Data for LargeShared Data Banks (Um modelo relacional de dados para grandes bancos de dados compartilhados), no qual ele introduziu a idia de modelo relacional usando tabelas (linhas e colunas) e

operaes matemticas para recuper-las destas tabelas (UNION, SELECT, SUM, etc...). Inicialmente, a IBM no quis implementar as ideias de Codd, que buscou clientes da IBM para mostrar seu modelo relacional. Com a presso de seus clientes, a IBM iniciou um projeto chamado System R, do qual se originou a linguagem SQL (Structured Query Language) que, embora no sendo relacional, de muita simplicidade e facilidade, o que fez com que alcanasse grande sucesso. 2.2 As 13 Regras de Frank Codd Em 1985, Codd 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 apresentada de uma nica forma, como dados em uma tabela; 3. Regra da garantia de acesso: Todo dado pode ser acessado logicamente (e unicamente) usando o nome da tabela, o valor da chave primria de 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 branco 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);

3. O modelo Relacional

3.1

Tabelas

Os bancos de dados relacionais so compostos de relaes, mais comumente chamadas de tabelas. Uma tabela exatamente o que o nome sugere - uma tabela de dados. Tabelas relacionais so muito utilizadas em planilhas eletrnicas. Toda tabela composta por colunas, cada uma correspondendo a um fragmento diferente de dados e linhas que correspondem a registros individuais.

3.2

Colunas

Cada coluna na tabela tem um nome nico e contm dados diferentes. Cada coluna tem um tipo de dados associados. As colunas so comumente chamadas de campos ou atributos.

3.3

Linha

Cada linha em uma tabela representa um registro diferente. Por causa do formato tabular, todas elas tm os mesmos atributos. As linhas tambm so comumente chamadas de registros ou tuplas.

3.4

Valores

Cada linha consiste em um conjunto de valores individuais que correspondem a colunas. Cada valor deve ter o tipo de dados especificado pela sua coluna.

3.5

Chaves

A coluna de identificao em uma tabela chamada de chave ou chave primria. Uma chave tambm pode consistir em mltiplas colunas. Por exemplo, podemos referir a um registro especfico combinando os campos correspondentes a ele, mas no tendo a garantia de ser nica. Normalmente os bancos de dados consistem em mltiplas tabelas e utilizam uma chave como uma referncia de uma tabela para outra. O termo de banco de dados relacional para esse relacionamento chave estrangeira. O identificador de uma tabela, quando aparece em outra tabela, referido como uma chave estrangeira.

4. Relacionamentos

As chaves estrangeiras representam um relacionamento entre dados em duas tabelas. Existem trs tipos bsicos de relacionamentos em um banco de dados relacional. Esses tipos so classificados de acordo com o nmero de coisas em cada lado do relacionamento. Os relacionamentos podem ser de um para um, de um para muitos ou de muitos para muitos.

4.1

Um para um

Um relacionamento de um para um indica que as tabelas tm relao unvoca entre si. Ou seja, para cada registro em uma tabela (chave primria), h um nico registro relacionado na outra (chave primria).

4.2

Um para muitos

Em um relacionamento de um para muitos, uma linha que chave primria em uma tabela vinculada a muitas linhas na outra tabela, que so chamadas de chave estrangeira

4.3

Muitos para muitos

Em um relacionamento de muitos para muitos, muitas linhas em uma tabela so vinculadas a muitas linhas de outra tabela. Com isso, necessrio criar uma nova tabela com as chaves primrias das tabelas envolvidas, ficando assim, uma chave composta, ou seja, formada por diversos campos de outras tabelas. A relao ento se reduz para uma relao um para muitos, sendo que a chave estrangeira ficar com a nova tabela criada.

5. Modelagem

5.1

Normalizao

O objetivo da normalizao evitar os problemas provocados por falhas no Projeto do Banco de Dados, bem como eliminar dados redundantes (por exemplo, armazenando os mesmos dados em mais de uma tabela) e garantir que as dependncias entre os dados faam sentido (armazenando apenas dados logicamente relacionados em uma tabela). Existem cinco estgios de normalizao (tambm denominadas formas normais), que se aplicam de forma cumulativa aos bancos de

dados, ou seja, para um banco de dados alcanar a 3 forma normal, ele precisa atender aos requisitos das 1 e 2 formas normais, mais os requisitos da 3 forma normal. No trabalho original de Frank Codd foram definidas trs dessas formas, mas com o passar do tempo, foram criadas outras formas normais que tambm so aceitas, mas para efeitos prticos, considerase que um banco de dados est normalizado se atender aos requisitos da 3 forma normal.

5.2

Primeira forma normal (FN1)

Uma tabela est na FN1 quando seus atributos no contm grupos de repetio. Exemplo:
Tabela 1 - Clientes

ClienteID 123 456 789

Nome Rachel Ingarm James Wright Maria Fernandez

Telefone 555-861-2025 555-403-1656 555-779-4100 555-808-9633

Esta tabela acima no est na FN1 porque apresenta grupos de repetio (possibilidade de mais de um telefone por cliente) Para passar essa tabela para a FN1 precisamos fazer o seguinte:
Tabela 2 Clientes Tabela 3 Telefone

ClienteID 123 456 789

Nome Rachel James Maria

ClienteID 123 456 456 789

Telefone 555-861-2025 555-403-1656 555-779-4100 555-808-9633

5.3

Segunda forma normal (FN2)

Ocorre quando a chave primria composta por mais de um campo. Neste caso, devemos observar se todos os campos que no fazem parte da chave dependem de todos os campos que compem a chave. Exemplo:
Tabela 4 - Cursos

Cursos NumMatricula (pk) CodCurso (pk) Avaliacao DescCurso Na tabela acima, achave primria composta formada pela combinao dos campos "NumMatricula" e "CodCurso". O campo Avaliao depende tanto do CodCurso quanto do NumMatricula, porm o campo DescCurso, depende apenas do CodCurso, ou seja, dado o cdigo do curso possvel localizar a respectiva descrio, independentemente do NumMatricula. Para passar essa tabela para FN2, feito o seguinte:
Tabela 5Avaliaes Tabela 6 Cursos

Avaliacoes NumMatricula (pk) CodCurso (pk) Avaliacao

Cursos CodCurso (pk) DescCurso

5.4

Terceira forma normal (FN3)

Na FN3, os campos de uma tabeladevem depender diretamente da chave primria, e no de outros campos que no fazem parte dessachave. Exemplo:
Tabela 7 - Funcionrios

Funcionarios NumMatricula (pk) Nome CodCargo DescCargo

Nesse

exemplo,

campo DescCargo depende

apenas

do

campo CodCargo, o qual no faz parte da chave primria. Por isso, esta tabela no est na FN3. A Soluo deste problema a seguinte:
Tabela 8Funcionrios Tabela 9 Cargos

Funcionarios NumMatricula (pk) Nome CodCargo

Cargos CodCargo (pk) DescCargo

Muitas vezes adistino entre a FN2 e a FN3 confusa. Devemos observar que FN2 est ligada a ocorrncia de chaves primrias compostas, e que um campo depende apenas de parte dessa chave. J na FN3, a chave primria simples, e um campo depende de outro que no essa chave.

10

5.5

Quarta forma normal (FN4)

Uma tabela est na FN4 quanto ela est na FN3 e no existirem dependncias multivaloradas. Exemplo:
Tabela 10 Livros Tabela 11 - Editora Tabela 12 - AutAssLiv

Livros CodLivro (pk) Titulo CodEditora AnoPublicacao

Editora CodEditora (pk) Editora

AutAssLiv CodLivro (pk) Autor Assunto

No exemplo acima, existe uma dependncia multivalorada na tabela AutAssLiv nos campos Autor e Assunto em relao chave primria CodLivro, pois um livro pode ter vrios autores, como tambm tratar de vrios assuntos.Para resolver isso, feito o seguinte:
Tabela 13 Livros Tabela 14 - Editora

Livros CodLivro (pk) Titulo CodEditora AnoPublicacao

Tabela 15 AutLiv

Editora CodEditora (pk) Editora

Tabela 16 - AssLiv

AutLiv CodLivro Autor

AssLiv CodLivro Assunto

11

5.6

Quinta forma normal (FN5)

A FN5 ocorre quando tabelas que esto na FN4 no podem ser juntadas sem que haja perda de informao. Isso compreendido mais facilmente com o exemplo:
Tabela 17 Fornecimentos

Fornecimentos Fornecedor Componente Projeto Na tabela acima, todos os campos so dependentes entre si, pois tanto um fornecedor pode encomendar um componente para um projeto, quanto um projeto pode requisitar um componente para um fornecedor. Quando essa tabela passada para FN4, ocorre o seguinte:
Tabela 18 FornComp Tabela 19 - FornProj Tabela 20 - CompProj

FornComp Fornecedor Componente

FornProj Fornecedor Projeto

CompProj Componente Projeto

Reparamos que se juntarmos apenas duas tabelas, haver a perda de uma informao (fornecedor, componente ou projeto), sendo assim essas tabelas esto em FN5.

12

6. Concluso

Nesse trabalho, vimos como surgiu o modelo relacional de banco de dados e suas regras de normalizao. O conhecimento dessas regras fundamental para garantir a integridade e evitar a redundncia de registros em um banco de dados, evitando assim problemas futuros de inconsistncia entre tabelas.

7. Referncias

http://www.htmlstaff.org/ver.php?id=1841 http://www.juliobattisti.com.br/artigos/office/modelorelacional_p1.asp http://erinaldosn.files.wordpress.com/2012/02/aula1-banco-de-dados-relacional1.pdf http://pt.wikipedia.org/wiki/Banco_de_dados_relacional http://pt.wikipedia.org/wiki/Edgar_frank_Codd http://pt.wikipedia.org/wiki/SEQUEL http://www.sirmacstronger.eti.br/bd/introbd.php http://www.dcc.fc.up.pt/~ricroc/aulas/0506/bd/apontamentos/parteVIII.pdf http://www.noginfo.com.br/arquivos/CC_EBD_02.pdf