1

1 relatrio 01: Projeto Conceitual do Banco de Dados 1.1 Conceitos fundamentais de Banco de Dados 1.1.1 Conceitos bsicos Segundo Korth (1994), um banco de dados uma coleo de dados interrelacionados, representando informaes sobre um domnio especfico, ou seja, sempre que for possvel agrupar informaes que se relacionam e tratam de um mesmo assunto, posso dizer que tenho um banco de dados. Podemos exemplificar situaes clssicas como uma lista telefnica, um catlogo de CDs ou um sistema de controle de RH de uma empresa. J um sistema de gerenciamento de banco de dados (SGBD) um software que possui recursos capazes de manipular as informaes do banco de dados e interagir com o usurio. Exemplos de SGBDs so: Oracle, SQL Server, DB2, PostgreSQL, MySQL, o prprio Access ou Paradox, entre outros. Por ltimo, temos que conceituar um sistema de banco de dados como o conjunto de quatro componentes bsicos: dados, hardware, software e usurios. Date (1991) conceituou que um sistema de bancos de dados pode ser considerado como uma sala de arquivos eletrnica. A figura 1 ilustra os componentes de um sistema de banco de dados. Figura 1 - Componentes de um sistema de banco de dados

Os objetivos de um sistema de banco de dados so o de isolar o usurio dos detalhes internos do banco de dados (promover a abstrao de dados) e promover a independncia dos dados em relao s aplicaes, ou seja, tornar independente da aplicao, a estratgia de acesso e a forma de armazenamento. 1.1.2 Abstrao de dados O sistema de banco de dados deve garantir uma viso totalmente abstrata do banco de dados para o usurio, ou seja, para o usurio do banco de dados pouco importa qual unidade de armazenamento est sendo usada para guardar seus dados, contanto que os mesmos estejam disponveis no momento necessrio. Esta abstrao se d em trs nveis (figura 2):

a) nvel de viso do usurio: as partes do banco de dados que o usurio tem acesso de acordo com a necessidade individual de cada usurio ou grupo de usurios; b) nvel conceitual: define quais os dados que esto armazenados e qual o relacionamento entre eles; c) nvel fsico: o nvel mais baixo de abstrao, em que define efetivamente de que maneira os dados esto armazenados. 1.1.3 Projeto de banco de dados Todo bom sistema de banco de dados deve apresentar um projeto, que vise a organizao das informaes e utilizao de tcnicas para que o futuro sistema

obtenha boa performance e tambm facilite infinitamente as manutenes que venham a acontecer. O projeto de banco de dados se d em duas fases: a) modelagem conceitual; b) projeto lgico. Estas duas etapas se referem a um sistema de banco de dados ainda no implementado, ou seja, que ainda no exista, um novo projeto. Para os casos em que o banco de dados j exista, mas um sistema legado, por exemplo, ou um sistema muito antigo sem documentao, o processo de projeto de banco de dados se dar atravs da utilizao de uma tcnica chamada de Engenharia Reversa, que ser visto em outra oportunidade. 1.1.4 Modelo conceitual a descrio do BD de maneira independente ao SGBD, ou seja, define quais os dados que aparecero no BD, mas sem se importar com a implementao que se dar ao BD. Desta forma, h uma abstrao em nvel de SGBD Uma das tcnicas mais utilizadas dentre os profissionais da rea a abordagem entidade-relacionamento (ER), onde o modelo representado graficamente atravs do diagrama entidade-relacionamento (DER). O modelo acima, entre outras coisas, nos traz informaes sobre Alunos e Turmas. Para cada Aluno, ser armazenado seu nmero de matrcula, seu nome e endereo, enquanto para cada turma, teremos a informao de seu cdigo, a sala utilizada e o perodo. 1.1.5 Modelo lgico Descreve o BD no nvel do SGBD, ou seja, depende do tipo particular de SGBD que ser usado. No podemos confundir com o Software que ser usado. O tipo de SGBD que o modelo lgico trata se o mesmo relacional, orientado a objetos, hierrquico, etc. Abordaremos o SGBD relacional, por serem os mais difundidos. Nele, os dados so organizados em tabelas (quadro 1).

|ALUNOS |MAT_ALUNO |1 |2 |NOME |Gerson Silva |Jeam Calos Luiz |ENDERECO |Rua dos Ips, 37 |Rua dos Pinheiros, 69

|3

|Paulo Roberto Junior

|Rua das Rosas, 24

|TURMA |COD_TURMA |SALA |1 |2 |8 |5 |PERIODO |Manh |Noite

Quadro 1 - Exemplo de tabelas em um SGBD relacional. O modelo lgico do BD relacional deve definir quais as tabelas e o nome das colunas que compem estas tabelas. Para o nosso exemplo, poderamos definir nosso modelo lgico conforme o seguinte:

Aluno (mat_aluno, nome, endereo Turma (cod_turma, sala, periodo) importante salientar que os detalhes internos de armazenamento, por exemplo, no so descritos no modelo lgico, pois estas informaes fazem parte do modelo fsico, que nada mais que a traduo do modelo lgico para a linguagem do software escolhido para implementar o sistema. 1.2 Caractersticas tpicas de um SGBD Um SGBD possui algumas caractersticas que so elementares para o seu funcionamento, essas caractersticas iro determinar se o SGBD est devidamente estruturado oferecendo assim as condies necessrias para seu bom uso. A seguir, iremos enumerar algumas caractersticas operacionais elementares que sempre devem fazer parte de um SGBD. So elas: Controle de redundncias - a redundncia consiste no armazenamento de uma mesma informao em locais diferentes, provocando inconsistncias. Em um Banco de Dados as informaes s se encontram armazenadas em um nico local, no existindo duplicao descontrolada dos dados. Quando existem replicaes dos dados, estas so decorrentes do processo de armazenagem tpica do ambiente Cliente-Servidor, totalmente sob controle do Banco de Dados.

Compartilhamento dos dados - o SGBD deve incluir software de controle de concorrncia ao acesso dos dados, garantindo em qualquer tipo de situao a escrita/leitura de dados sem erros. Controle de acesso - o SGDB deve dispor de recursos que possibilitem selecionar a autoridade de cada usurio. Assim um usurio poder realizar qualquer tipo de acesso, outros podero ler alguns dados e atualizar outros e outros ainda podero somente acessar um conjunto restrito de dados para escrita e leitura. Interfaceamento - um Banco de Dados dever disponibilizar formas de acesso grfico, em linguagem natural, em SQL ou ainda via menus de acesso, no sendo uma "caixa-preta" somente sendo passvel de ser acessada por aplicaes. Esquematizao - um Banco de Dados dever fornecer mecanismos que possibilitem a compreenso do relacionamento existente entre as tabelas e de sua eventual manuteno. Recuperao de paradas e falhas - no caso de pane o Banco de Dados possa ser recuperado de maneira confivel. 1.3 Arquitetura de SGBD A principal meta da arquitetura de um SGBD separar as aplicaes dos usurios do banco de dados fsico. Os esquemas podem ser definidos como: Nvel interno - ou esquema interno, o qual descreve a estrutura de armazenamento fsico do banco de dados; utiliza um modelo de dados e descreve detalhadamente os dados armazenados e os caminhos de acesso ao banco de dados. Nvel conceitual - ou esquema conceitual, o qual descreve a estrutura do banco de dados como um todo; uma descrio global do banco de dados, que no fornece detalhes do modo como os dados esto fisicamente armazenados. Nvel externo - ou esquema de viso, o qual descreve as vises do banco de dados para um grupo de usurios; cada viso descreve quais pores do banco de dados de um grupo de usurios ter acesso. 2 Relatrio 02: Projeto Lgico do Banco de Dados - Parte I. 2.1 Normalizao do Banco de Dados 2.1.1 Introduo as formas normais O conceito de normalizao foi introduzido por Codd em 1972.

Inicialmente Codd criou as trs primeiras formas de normalizao chamando-as de: primeira forma normal (1NF), segunda forma normal (2NF) e terceira forma normal (3NF). Uma definio mais forte da 3NF foi proposta depois por BoyceCodd, e conhecida como forma normal de Boyce-Codd (FNBC). Atravs do processo de normalizao pode-se, gradativamente, substituir um conjunto de entidades e relacionamentos por um outro, o qual se apresenta "purificado" em relao s anomalias de atualizao (incluso, alterao e excluso) as quais podem causar certos problemas, tais como: a) grupos repetitivos (atributos multivalorados) de dados; b) variao temporal de certos atributos, dependncias funcionais totais ou parciais em relao a uma chave concatenada; c) redundncias de dados desnecessrias; d) perdas acidentais de informao; e) dificuldade na representao de fatos da realidade observada; f) dependncias transitivas entre atributos.

Normalizao de relaes portanto uma tcnica que permite depurar um projeto de banco de dados, atravs da identificao de inconsistncias (informaes em duplicidade, dependncias funcionais mal resolvidas, etc). medida que um conjunto de relaes passa para uma forma normal, vamos construindo um banco de dados mais confivel. O objetivo da normalizao no eliminar todas as inconsistncias e sim control-las. 2.1.1.1 Forma normal (1FN) Primeira forma normal: Uma relao est na primeira forma normal se todos os seus atributos so monovaloradoseatmicos. Quando encontrarmos um atributo multivalorado, deve-se criar um novo atributo que individualize a informao que esta multivalorada: BOLETIM = {matricula-aluno, materia, notas} No caso acima, cada nota seria individualizada identificando a prova a qual aquela nota se refere:

BOLETIM = {matricula-aluno, materia, numero-prova, nota} Quando encontrarmos um atributo no atmico, deve-se dividi-lo em outros atributos que sejam atmicos: PESSOA = {CPF, nome-completo} Vamos supor que, para a aplicao que utilizar esta relao, o atributo nomecompleto no atmico, a soluo ento ser: PESSOA = {CPF, nome, sobrenome} 2.1.1.2 Forma Normal (2FN): Segunda forma normal: Uma relao est na segunda forma normal quando duas condies so satisfeitas: a) a relao estiver na primeira forma normal; b) todos os atributos primos dependerem funcionalmente de toda a chave primria. Observe a relao abaixo: BOLETIM = {matricula-aluno, codigo-materia, numero-prova, nota, data-daprova, nome-aluno, endereo-aluno, nome-materia} Fazendo a anlise da dependncia funcional de cada atributo primo, chegamos s seguintes dependncias funcionais: matricula-aluno, codigo-materia, numero-prova -> nota codigo-materia, numero-prova -> data-da-prova matricula-aluno -> nome-aluno, endereo-aluno codigo-materia -> nome-materia Conclumos ento que apenas o atributo primo nota depende totalmente de toda chave primria. Para que toda a relao seja passada para a segunda forma normal, deve-se criar novas relaes, agrupando os atributos de acordo com suas dependncias funcionais: BOLETIM = {matricula-aluno, codigo-materia, numero-prova, nota} PROVA = {codigo-materia, numero-prova, data-da-prova} ALUNO = {matricula-aluno, nome-aluno, endereo-aluno} MATERIA = {codigo-materia, nome-materia}

O nome das novas relaes deve ser escolhido de acordo com a chave. 2.1.1.3 Forma normal (3FN) Terceira forma normal: Uma relao est na terceira forma normal quando duas condies forem satisfeitas: a) a relao estiver na segunda forma normal; b) todos os atributos primos dependerem no transitivamente de toda a chave primria. Observe a relao abaixo: PEDIDO = {numero-pedido, codigo-cliente, data-pedido, nome-cliente, codigo-cidade-cliente, nome-cidade-cliente} Fazendo a anlise da dependncia funcional de cada atributo primo, chegamos s seguintes dependncias funcionais: numero-pedido -> codigo-cliente numero-pedido -> data-pedido codigo-cliente -> nome-cliente codigo-cliente -> codigo-cidade-cliente codigo-cidade-cliente -> nome-cidade-cliente Conclumos ento que apenas os atributos primos codigo-cliente e datapedido dependem no transitivamente totalmente de toda chave primria. Observe que: numero-pedido -> codigo-cliente -> nome-cliente numero-pedido -> codigo-cliente -> codigo-cidade-cliente numero-pedido -> codigo-cliente -> codigo-cidade-cliente -> nome-cidadecliente

Isto dependncia transitiva, devemos resolver inicialmente as dependncias mais simples, criando uma nova relao onde codigo-cliente a chave, o codigo-cliente continuar na relao PEDIDO como atributo primo, porm, os atributos que dependem dele devem ser transferidos para a nova relao:

PEDIDO = {numero-pedido, codigo-cliente, data-pedido CLIENTE = {codigo-cliente, nome-cliente, codigo-cidade-cliente, nome-cidadecliente} As dependncias transitivas da relao PEDIDO foram eliminadas, porm ainda devemos analisar a nova relao CLIENTE: codigo-cliente -> codigo-cidade-cliente -> nome-cidade-cliente Observe que o nome-cidade-cliente continua com uma dependncia transitiva, vamos resolv-la da mesma maneira: PEDIDO = {numero-pedido, codigo-cliente, data-pedido} CLIENTE = {codigo-cliente, nome-cliente, codigo-cidade-cliente} CIDADE = {codigo-cidade-cliente, nome-cidade-cliente} O nome das novas relaes deve ser escolhido de acordo com a chave. 2.2 DER (Diagrama Entidade-Relacionamento)

10

REFERNCIAS Banco de Dados. 2011. [texto na Internet]. [Citado em 2011 mar 27]. Disponvel em: http://www.reocities.com/kelseiabreu/Banco_de_Dados.htm Banco de Dados. 2011. [texto na Internet]. [Citado em 2011 mar 27]. Disponvel em: http://topicosdeinformaticaadm.blogspot.com/2009/11/conceito-earquitetura-de-um-sgbd_8293.html Date CJ. Int. a Sistemas de Bancos de Dados, traduo da 4a ed. norteamericana. So Paulo: Campus; 1991. IMEI. Instituto de Matemtica e Estatstica - USP. [texto na Internet]. [Citado em 2011 mar 27]. http://www.ime.usp.br Korth HF, Silberschatz A. Sistemas de bancos de dados. 2a ed. revisada. So Paulo: Makron Books; 1994.