You are on page 1of 94

PARTE I - INTRODUO A BANCO DE DADOS CAPTULO I - CONCEITOS BSICOS

Introduo ...........................................................................01 1. Arquivo ............................................................................02 2. Registro ...........................................................................02 3. Campo ............................................................................ 03 4. Chave Primria ................................................................04 5. Chave Secundria............................................................05 6. Chave Candidata..............................................................06

CAPTULO II - ORGANIZAO DE ARQUIVOS


1. Mtodo De Acesso ...........................................................07 2. Organizao Seqencial ..................................................09 3. Organizao Serial...........................................................10 4. Organizao Indexada .....................................................11

CAPTULO III - SGBD


1. Sistema Geranciador de Banco de Dados - SGBD.........13 2. Banco de Dados..............................................................13 3. Sistema em Banco de Dados.......................................... 14

CAPTULO IV - OBJETIVOS DE BANCO DE DADOS


1. Independncia de dados.................................................15 2. Compartilhamento de dados...........................................16 3. Menor redundncia.........................................................16 4. Privacidade de dados ....................................................16 5. Segurana de dados .....................................................17 6. Tratamento de concorrncia .........................................17 7. Integridade de dados ....................................................18

CAPTULO V - LINGUAGENS DE BD
1. SQL...............................................................................19 2. Autocontidas..................................................................22 3. Hospedeiras...................................................................22 4. Visuais...........................................................................23 5. Linguagens para INTERNET..........................................23 Concluso..........................................................................24

CAPTULO VI - BANCO DE DADOS RELACIONAL


1. Terminologia do Modelo Relacional..... .........................25 2. Regras de integridade...................................................26 a. Integridade Declarativa..................................................27 b. Integridade Procedural..................................................29 c. Integridade Referencial.................................................30 3. Operadores Relacionais...............................................32 4. Propriedades Relacionais.............................................33 5. Vantagens do Modelo Relacional.................................34

CAPTULO VII - LGEBRA RELACIONAL


1. Estudo de caso ...........................................................36 2. Generalidades ...........................................................38 3. Operadores de Conjunto ..........................................39 a. Unio...........................................................................40 b. Interseo....................................................................41 c. Diferena.....................................................................42 d. Produto carteziano......................................................43 4. Operadores Relacionais ............................................44 e. Projeo......................................................................44 f. Seleo........................................................................45 g. Juno........................................................................46

PARTE II - PROJETO DE BANCO DE DADOS


Introduo ......................................................................48 CAPTULO VIII - NVEIS DE ABSTRAO 1. Mundo Real ...............................................................50 2. Modelo Descritivo ......................................................50 3. Modelo Conceitual .....................................................51 4. Modelo Operacional ...................................................51 5. Modelo Interno ...........................................................52

CAPTULO IX - MODELO DE ENTIDADES E RELACIONAMENTOS (MER) Generalidades ................................................................53 1. MER - Notao e terminologia.....................................54 2. Regras para atribuio de nomes entidades.............55 3. Atributo .......................................................................56 4. Dicionrio de Dados.....................................................57 5. Relacionamento...........................................................59 6. Cardinalidade.............................. ................................60 7. Nome do relacionamento.. ......... ................................62 8. Papel ...........................................................................63 9. Sentenas ...................................................................64 10. Integridade Referencial .............................................65 11. Regras gerais para o MER ........................................66 12. Vantagens e desvantagens do MER .........................67 CAPTULO X - TIPOS ESPECIAIS DE RELACIONAMENTO 1. Auto-relacionamento ...................................................68 2. Mais de um relacionamento ........................................69 3. Relacionamento Mltiplo .............................................70 CAPTULO XI - EXTENSES AO MER 1. Generalizao .............................................................72 2. Especializao ............................................................73 3. Agregao ..................................................................74 4. Variao do conceito de Agregao ............................75 CAPTULO XII - NORMALIZAO 1. Anomalias de Atualizao ...........................................76 2. Terminologia ...............................................................77 Dependncia Funcional Completa (DFC) ...................78 Dependncia Funcional Parcial (DFP) .......................79 Dependncia Funcional Transitiva (DFT) ...................80 3. Notao para as estruturas de dados .........................81 4. Esquema de normalizao ..........................................83 5. Relaes no Normalizadas ........................................84 6. Primeira forma normal (1FN) ........................................85 7. Escolha da chave primria ...........................................86 8. Segunda forma normal (2FN) ......................................88 9. Terceira forma normal (3FN) ........................................89 Bibliografia........................................................................91

INTRODUO

No incio da dcada de 60, foram lanados os primeiros sistemas gerenciadores de banco de dados (SGBD), tendo como principal proposta o aumento na produtividade nas atividades de desenvolvimento e manuteno de sistemas, at ento realizadas de forma artezanal em linguagens de programao convencionais de primeira e segunda gerao. Oriundos do ambiente de mainframes, os SGBD tornaram-se mais populares e amigveis com o advento da microinformtica. Cada vez mais as fronteiras entre esses dois mundos estreitam-se e a concorrncia pelo domnio do mercado de SGBD, tem levado seus diversos fabricantes a sofisticarem seus produtos. Cada nova verso lanada, incorpora novidades como interfaces grficas, ferramentas de apoio ao desenvolvimento, utilitrios para gerenciamento de BD e facilidades para extrao de dados. Essa evoluo vem tornando o trabalho de programadores, analistas e usurios menos artezanal, com reflexos na qualidade e produtividade. A literatura classifica os SGBD como HIERRQUICO, REDE e RELACIONAL. Essa classificao representa a evoluo desses produtos no curso da histria. Atualmente, o mercado dominado pelos SGBD RELACIONAIS e caminha para a colocao em escala comercial dos SGBD ORIENTADOS A OBJETOS. Este texto introduz a teoria de BANCO DE DADOS, a partir de conceitos bsicos da teoria de arquivos que perpetuaram-se na terminologia de banco de dados. Na sequencia aborda superficialmente os modelos HIERRQUICO e REDE (por razes de mercado) e de forma mais aprofundada o MODELO RELACIONAL, o qual designaremos neste texto pela sigla SGBD-R.

CAPTULO I CONCEITOS BSICOS


Para compreender com maior facilidade os conceitos relativos a BANCO DE DADOS de suma importncia revisar-mos alguns conceitos bsicos referentes teoria e terminologia de arquivos convencionais, haja vista, que os primeiros SGBD foram criados a partir do aperfeioamento de sistemas gerenciadores de arquivo, e ainda utilizam muito da base conceitual e da terminologia de arquivos.

1. ARQUIVO
Um arquivo uma coleo de REGISTROS do mesmo tipo, ou seja, referentes a um mesmo assunto e com o mesmo formato padro (layout). Constitui o componente do sistema no qual so armazenados os dados, que combinados atravs dos programas servem de base para a gerao da informao desejada pelo usurio, atravs de relatrios e consultas on-line. Um sistema de controle de notas, por exemplo, pode armazenar seus dados em diversos arquivos, cada um contendo informaes sobre um determinado item do sistema: ALUNO, PROFESSOR, MATRIA, NOTA, etc. Essas informaes podem ser combinadas atravs de programas para gerar, por exemplo, o BOLETIM ESCOLAR, a PAUTA ou uma tela de CONSULTA DE NOTAS.

2. REGISTRO
Um registro constitudo por conjunto de campos valorados (contendo dados. Consiste na unidade de armazenamento e recuperao da informao em um arquivo. Geralmente, os registros de um arquivo possuem um formato padro (layout), definido pela seqncia, tipo e tamanho dos campos que o compem. Porm, algumas linguagens de programao permitem a criao de registros com layouts deferentes em um mesmo arquivo, recurso este que raramente utilizado.

3. CAMPO
a unidade bsica formadora de um registro. Constitui a clula da informao. a menor poro de um arquivo que pode ser referenciada por um programa. Cada campo possui NOME, TIPO e TAMANHO. Os tipos de campo mais comuns so: _ Armazena somente nmeros NUMBER CHAR ou ALFANUMRICO DATE _ Pode conter casas decimais _ Pode ser utilizado em operaes matemticas _ Pode armazenar letras, nmeros e caracteres especiais _ Armazena datas fazendo consistncia automtica

MEMO ou LONG _ Armazena textos em formato livre

A figura a seguir sintetiza os conceitos de ARQUIVO, REGISTRO e CAMPO:

ARQUIVO ALUNO LAYOUT CAMPOS TIPO e TAM. REGISTROS


MATRICULA NOME ENDEREO DT_NASC NUMBER (03) CHAR (30) CHAR (50) DATE 001 002 003 . . Jos Maria Ana . . SQS 308 ... 23/08/78 QND 14 .... 25/09/70 SQN 410 ... 10/08/85 . . . .

4. CHAVE PRIMRIA (PRIMARY KEY - PK)


3

A CHAVE PRIMRIA (ou simplesmente CHAVE) o identificador nico de um registo em um arquivo. Pode ser constituda de um campo (CHAVE SIMPLES) ou pela combinao de dois ou mais campos (CHAVE COMPOSTA), de tal maneira, que no existam dois registros no arquivo com o mesmo valor de chave primria. Em regra, todo arquivo deve possuir uma chave primria, que permita a identificao inequvoca do registro, especialmente, para dar maior consistncia aos processos de incluso, alterao e excluso de dados. Para que no ocorram duplicatas nos valores da chave, os campos que a compem so de PREENCHIMENTO OBRIGATRIO (NOT NULL). Na escolha da chave primria de um arquivo deve-se buscar campos que possuam ESTABILIDADE no valor armazenado. A escolha do NMERO DO TELEFONE como chave de um cadastro de clientes, por exemplo, seria inadequada, por que esse valor pode mudar com freqncia. Sem considerar que o cliente pode ter mais de um telefone... Deve-se tambm evitar a escolha de campos que possam causar AMBIGIDADE em relao aos valores nele contidos. Nesse sentido, seria inadequado a escolha do campo NOME para chave de um cadastro de clientes, haja vista, que um mesmo nome pode ser escrito de vrias formas. Por exemplo: LUS, LUIZ, LOUIS, LOYS, LUYS. Se desejssemos cobrar uma fatura de um cliente com um nome como esse, a probabilidade de erramos o cliente seria grande. Alm disso, a extenso do campo (30 ou mais caracteres) um outro aspecto que aumenta a possibilidade de erros. DICAS PARA ESCOLHA DA CHAVE PRIMRIA: _ Todo arquivo deve possuir uma chave primria. _ VALOR NICO para cada registro. _ SIMPLES ou COMPOSTA. _ Campos de PREENCHIMENTO OBRIGATRIO. _ Valor ESTVEL. _ No AMBGUO. _ PEQUENA EXTENSO (menor possvel). _ De preferncia CAMPOS NUMRICOS

5. CHAVE SECUNDRIA

A chave secundria pode ser formada por um campo ou pela combinao de campos (SIMPLES / COMPOSTA). utilizada como parmetro (filtro) para seleo de registros no arquivo em consultas, emisso de relatrios ou processos de atualizao simultnea de um grupo de registros. Por exemplo, para aumentarmos o valor do salrio dos analistas em 10%, poderamos utilizar o campo FUNO do arquivo CADASTRO DE FUNCIONRIOS como parmetro (chave secundria) no processo de seleo dos registros a serem alterados. Em sntese, a chave secundria o campo ou combinao de campos do arquivo que permite a recuperao de mais de um registro no arquivo. Portanto, no possui a caracterstica de unicidade proposta para a chave primria.
A figura a seguir ilustra os conceitos de CHAVE PRIMRIA e SECUNDRIA

ARQUIVO ALUNO

PK
MATRICULA 001 003 002 005 . NOME Jos Maria Ana Jos . ENDEREO SQS 308 ... QND 14 .... SQN 410 ... GAMA . DT_NASC 23/08/78 25/09/70 10/08/85 05/04/76 .

Acesso via CHAVE SECUNDRIA (NOME) no arquivo ALUNO:

PROGRAMA X INCIO.... . . SE NOME = JOS ENTO IMPRIMIR ..... . . FIM

6. CHAVE CANDIDATA
Pode ocorrer uma situao em que mais de um campo satisfaa a condio de chave primria, constituindo duas ou mais CHAVES CANDIDATAS. Neste caso, o analista dever eleger somente uma delas como CHAVE PRIMRIA, as demais permanecero na condio de CANDIDATAS, indicando que tratam-se de campos de preenchimento obrigatrio e com valores nicos para cada registro, o que ser garantido atravs de mecanismos de integridade de coluna, que veremos no captulo relativo a banco de dados.
A figura a seguir mostra um exemplo de arquivo com CHAVE CANDIDATA

ARQUIVO ALUNO

CHAVE CANDIDATA CHAVE PRIMRIA


MATRICULA 001 003 002 005 . . NOME Jos Maria Ana Jos . . ENDEREO SQS 308 ... QND 14 .... SQN 410 ... GAMA . . CPF 72993246500 12354789065 09876587659 28746503645 . .

CAPTULO II ORGANIZAO DE ARQUIVOS


O tema organizao de arquivos refere-se a forma como os registros so armazenados em um arquivo baseado em computador. Confunde-se com MTODO DE ACESSO, que consiste na forma como esses podem ser recuperados. A organizao do arquivo determina os mtodos de acesso que podem ser utilizados na recuperao dos registros, mas tratam-se de coisas distintas. Apesar de este ser um assunto muito abrangente e com muitas variantes em termos de abordagem, trataremos de apenas trs tipos de organizao (SEQENCIAL, SERIAL E INDEXADA) e seus respectivos mtodos de acesso. Essa escolha baseia-se na necessidade de discutirmos alguns conceitos essenciais para o estudo do modelo Relacional de banco de dados, que constitui o objeto principal desse texto.

1. MTODOS DE ACESSO
Para recuperarmos um registro em um arquivo, podemos utilizar acesso SEQENCIAL ou DIRETO. O mtodo SEQENCIAL de acesso o mais tradicional e consiste em efetuar a leitura dos registros, um aps o outro, comparando o ARGUMENTO DE PESQUISA, com o valor do campo CHAVE (primria ou secundria) no registro corrente, at encontrar os registros desejados ou o final do arquivo. exemplo: PROGRAMA Y INCIO.... . Repita at fim ler registro

chave secundria (campo chave) argumento de pesquisa

SE NOME = JOS ENTO IMPRIMIR Fim repita (volte a ler) . FIM DO PROGRAMA

O mtodo DIRETO consiste em recuperar o(s) registro(s) desejado(s), sem a necessidade de efetuar a leitura dos registros que o(s) antecede(m), o que pode ser feito atravs de um NDICE (que abordaremos no item organizao indexada) ou com o auxlio de um algoritmo de RANDOMIZAO que localiza o registro, calculando a posio ocupada pelo registro no disco, com base no valor do argumento de pesquisa, que deve ser um campo numrico. Em ambos os casos, a localizao do registro ocorre a cargo do gerenciador de arquivos, de maneira transparente para o programador, que s precisa escolher a organizao adequada para o arquivo e fornecer no programa o argumento de pesquisa. exemplo: PROGRAMA Z INCIO.... . . ABRIR ARQUIVO ALUNO INDEXADO POR NOME . NOME=JOS argumento de pesquisa LOCALIZAR REGISTRO acesso direto (indexado) SE ENCONTROU REGISTRO ENTO IMPRIMIR . . FIM DO PROGRAMA

2. ORGANIZAO SEQENCIAL
A ORGANIZAO SEQENCIAL caracteriza-se pela existncia de uma CHAVE DE ORDENAO. Essa chave determina a ordem em que os registros so armazenados e pode ser SIMPLES ou COMPOSTA por dois ou mais campos. Geralmente, coincide com a chave primria, mas no obrigatoriamente. A organizao seqencial somente permite o ACESSO SEQENCIAL.
A figura a seguir apresenta um arquivo com ORGANIZAO SEQENCIAL e CHAVE PRIMRIA(MATRICULA) distinta da CHAVE DE ORDENAO (NOME - ordem alfabtica).

ARQUIVO ALUNO

chave primria
MATRICULA 001 003 002 005 . . NOME Ana Jos Jos Maria . .

chave de ordenao
ENDEREO SQS 308 ... QND 14 .... SQN 410 ... GAMA . . DT_NASC 23/08/78 25/09/70 10/08/85 05/04/76 . .

3. ORGANIZAO SERIAL
Nesta forma de organizao os registros so armazenados de acordo com a ordem de incluso. o arquivo no possui chave de ordenao, portanto no existe preocupao com a ordem de armazenamento dos registros. No entanto, sempre recomendvel o arquivo possua uma chave primria. A organizao serial somente permite o ACESSO SEQENCIAL. No deve ser utilizada em processos de excluso e alterao de registros na modalidade bacth (atualizao em lote), pois degrada a performance. muito utilizada em processos de incluso de registros onde no haja preocupao em manter a seqncia dos mesmos (pools de digitao). tambm empregada no arquivo de dados que serve de base para a organizao indexada, que estudaremos no prximo item.
A figura a seguir apresenta um arquivo com ORGANIZAO SERIAL. Note que ele no possui CHAVE DE ORDENAO.

ARQUIVO ALUNO

chave primria
MATRICULA 005 003 002 001 . NOME Maria Jos Ana Jos . ENDEREO SQS 308 ... QND 14 .... SQN 410 ... GAMA . DT_NASC 23/08/78 25/09/70 10/08/85 05/04/76 .

10

4. ORGANIZAO INDEXADA
Nesta forma de organizao, os registros so armazenados em um arquivo de dados com organizao serial e para cada campo (ou combinao deles) atravs do qual se deseja obter acesso direto (indexado) deve-se criar um arquivo de ndice (processo de indexao). Um mesmo arquivo de dados pode possuir diversos arquivos de ndice a ele associados. Porm, apesar da flexibilidade para a criao de ndices, esse recurso deve ser utilizado com critrio, pois a manuteno de muitos ndices pode degradar a performance no processo de atualizao do arquivo. Ou seja, ganha-se na consulta on-line, mas pode-se perder na atualizao de dados. O arquivo de ndice composto basicamente por duas colunas. A primeira corresponde ao campo utilizado no processo de indexao (endereo lgico) e a segunda armazena um valor (endereo fsico) que serve como referncia, para que o gerenciador de arquivos localize o registro no disco magntico. Os registros dos arquivos ndice so ordenados pelo endereo lgico. Portanto, se utilizarmos um algoritmo de leitura seqencial em um arquivo indexado por nome, por exemplo, obteremos os registros em ordem alfabtica, mesmo sendo o arquivo de dados um arquivo serial. Ou seja prevalece a ordem do ndice. Porm nesse exemplo, a performance a performance do arquivo indexado seria menor, se comparada a de um arquivo seqencial por nome. Sempre que um arquivo ndice for referenciado por um programa, ele ser carregado para memria principal, o que torna desprezvel o tempo de busca dos registros nesse arquivo. Alm disso, o algoritmo utilizado na busca o de pesquisa binria, o que reduz ainda mais o tempo. Os ndices constitudos com base no valor da chave primria ou candidata so conhecidos como NDICES PRIMRIOS e os demais como NDICES SECUNDRIOS.

11

Em resumo, a organizao indexada formada pela combinao de pelo menos um arquivo de dados e um ou mais arquivos de ndice.
A figura a seguir apresenta o cenrio da ORGANIZAO INDEXADA.

ARQUIVO ALUNO
NDICE PRIMRIO

TRILHA, SETOR E LADO DO DISCO


MATR 001 002 003 005 . TSL 220 321 231 110 (endereo fsico)

chave primria (endereo lgico)

NDICE SECUNDRIO NOME TSL Ana 321 Jos 220 Jos 231 Maria 110 . 331

TSL MATR NOME 110 005 Maria 231 003 Jos 321 002 Ana 220 001 Jos 331 . .

ENDEREO SQS 308 ... QND 14 .... SQN 410 ... GAMA .

DT_NASC 23/08/78 25/09/70 10/08/85 05/04/76 .

12

CAPTULO III SISTEMA GERENCIADOR DE BANCO DE DADOS - SGBD


A expresso BANCO DE DADOS, coloquialmente empregada com os mais diversos significados, de tal sorte que, ao indagarmos de algum sobre o BANCO DE DADOS com o qual trabalha em sua empresa, poderemos obter as seguintes respostas: 1. Trabalho com ORACLE, ACCESS, SQL SERVER, SYBASE, etc.. 2. Trabalho com o banco de dados de PESSOAL, MATERIAL ou FINANAS; 3. Trabalho com o CADASTRO DE PESSOAL, SISTEMA DE VENDAS, etc. Para evitar conflitos terminolgicos, definimos a seguir trs expresses, consagradas na a literatura clssica, que seriam melhor aplicadas a cada uma das situaes anteriores. 1. SISTEMA GERENCIADOR DE BANCO DE DADOS - SGBD Essa expresso estar corretamente empregada, quando utilizada para designar o SOFTWARE utilizado para criar um BANCO DE DADOS. Portanto, tratando-se de SGBD estaremos nos referindo a produtos como ACCESS, ORACLE, SYBASE, SQL SERVER, ADABAS, etc. 2. BANCO DE DADOS - BD Esse enunciado refere-se a um conjunto de informaes relacionadas, que so armazenadas no computador e recuperadas com a utilizao dos recursos de um SGBD. Essas informaes devem ser estruturadas, de tal maneira, que independam de aplicaes especficas. Ou seja, um BD de PESSOAL, adequadamente estruturado, pode fornecer dados, tanto para um sistema de Folha de Pagamento, quanto para um sistema de Treinamento de Recursos Humanos.

13

3. SISTEMA EM BANCO DE DADOS - SBD Essa expresso refere-se s APLICAES desenvolvidas para atender a necessidades especficas da empresa, que acessam um ou mais BD, para leitura ou atualizao de informaes. Tome como exemplo de aplicaes especficas os sistemas de folha de pagamento e Treinamento de Recursos Humanos, citados no item anterior.

A figura abaixo ilustra um ambiente onde o BANCO DE DADOS de alunos foi estruturado para atender a quatro SISTEMAS distintos: CADASTRO DE ALUNOS, CONTROLE DE MENSALIDADES, EMPRSTIMO DE LIVROS e CONTROLE DE NOTAS. O BD foi montado utilizando os recursos do SGBD SQL SERVER.
TESOURARIA SECRETARIA
CADASTRO DE ALUNOS

BD DE ALUNOS

CONTROLE DE MENSALIDADE

SGBD SQL SERVER

CONTROLE DE NOTAS

EMPRSTIMOS DE LIVROS

PEDAGOGA

BIBLIOTECA

14

CAPTULO IV OBJETIVOS DE BANCO DE DADOS


O desenvolvimento da tecnologia de banco de dados tem se pautado por buscar alcanar, como objetivo permanente o aumento de produtividade nas atividades de desenvolvimento e manuteno de sistemas. Nesse sentido os fabricantes de SGBD vem dotando seus produtos com mecanismos que facilitam a adaptao dos BD s novas necessidades que surgem no dia a dia e que reduzem o trabalho de programao. Aliado a esses dois fatores existe toda uma filosofia que orienta os tcnicos na escolha do melhor produto para a sua empresa e no trabalho de projeto de banco de dados. Dessa filosofia destacamos, a seguir, alguns objetivos de BD, os quais um profissional deve ter em mente ao lidar com essa tecnologia. 1. INDEPENDNCIA DE DADOS Os SGBD devem ser dotados de recursos que possibilitem a descrio das estruturas de dados (layout de arquivos e/ou tabelas) de forma independente dos procedimentos de manipulao (leitura e gravao) de dados no BD. Esse objetivo visa tornar transparente para os programas que acessam o BD as alteraes que, por ventura, venham a ocorrer nas estruturas de dados, como por exemplo o acrscimo de um novo campo de informao ao banco. Da mesma forma, alteraes em lgicas de programas que acessam o BD no devem afetar as estruturas de dados. Quanto maior o grau de independncia de dados, menor ser o tempo em que o BD ficar fora de operao para atividades de manuteno como, por exemplo, recompilao. At hoje, a maneira mais eficiente adotada pelos fornecedores de SGBD para implementao desse objetivo foi a utilizao do SQL (structured query language) nos produtos que seguem o Modelo Relacional. O SQL possui grupos de comandos especficos e independentes para as tarefas de criao e alterao de tabelas (DDL - data definition language) e leitura e atualizao do BD (DML - data manipulation language).

15

2. COMPARTILHAMENTO DE DADOS Consiste na reutilizao dos dados do BD pelo maior nmero possvel de aplicaes dentro da empresa. Nesse sentido, os dados do BD devem ser muito bem planejados e estruturados. Portanto, este objetivo de banco de dados esta mais ligado a atividade de anlise e projeto de BD. O compartilhamento de dados visa diminuir a redundncia de dados, considerando-o como um recurso da empresa e no propriedade de setores isolados da organizao. Para implementar o compartilhamento de dados necessrio que a empresa disponha de recursos de rede, que permitam colocar o BD ao alcance dos diversos usurios. Alm disso, necessrio que o SGBD possua um competente sistema de segurana, para que se estabelea a privacidade de dados, atravs de mecanismos de restrio de acesso. 3. MENOR REDUNDNCIA DE DADOS Redundncia de dados consiste na repetio de um mesmo dado em diversos arquivos (tabelas) de um sistema, banco de dados, ambiente computacional ou empresa. Como exemplo, pode-se tomar a ocorrncia do dado NOME DO FUNCIONRIO, em bases de dados no compartilhadas dos sistemas de CADASTRO, FOLHA DE PAGAMENTO e TREINAMENTO de uma empresa. A redundncia danosa para o ambiente computacional, pois aumenta os custos com o armazenamento de dados, com o pessoal para manuteno de sistema. Alm disso, a redundncia gera inconsistncia de dados, ou seja, o dado redundante extrado a partir de arquivos diferentes apresenta valores divergentes. Tal fato, pode afetar a credibilidade do usurio no sistema e no pessoal de informtica. 4. PRIVACIDADE DE DADOS O COMPARTILHAMENTO DE DADOS leva um grande nmero de usurios, com funes diversificadas na empresa, a acessar um mesmo banco de dados. Nesse contexto, o objetivo de privacidade de dados ressalta a preocupao que o projetista de BD deve ter em vedar o acesso de usurios no autorizados a informaes sigilosas ou de acesso restrito.
16

Nesse sentido, o sistema de segurana dos SGBD, devem possuir meios para que o projetista possa definir perfis diferenciados de acesso ao BD, com a criao de grupos de usurios e atribuio de direitos de acesso a esses grupos, a partir da utilizao de senhas. 5. SEGURANA DE DADOS A segurana das informaes armazenadas no BD pode ser encarada sob dois prismas: SEGURANA LGICA e SEGURANA FSICA. A SEGURANA LGICA alcanada com a utilizao dos mecanismos de restrio de acesso disponveis nos SGBD para implementao do objetivo de privacidade de dados, tais como senhas e sistemas de LOG e AUDIT que registram dados sobre as operaes que so efetuadas no BD (data, hora, usurio, comando, etc.). A SEGURANA FSICA dos dados obtida a partir de utilitrios e aplicativos que os fabricantes colocam em seus produtos, visando facilitar o trabalho de proteo aos dados contra danos fsicos, que podem ser causados por falhas de hardware ou queda da rede. Nessa linha destacam-se as ROTINAS DE BACKUP, GRAVAO COM ESPELHAMENTO e SISTEMAS DE MONITORAO DE TRANSAES DISTRIBUDAS (TWO-PHASE-COMMIT). 6. TRATAMENTO DE CONCORRNCIA Este objetivo de BD aborda o aspecto do acesso simultneo de dois usurios a um mesmo conjunto de informaes. O SGBD deve possuir mecanismos para a identificao e tratamento desses acessos concorrentes, para garantir a consistncia das informaes do BD no sentido de sua veracidade. Os sistemas de bloqueio (LOCK) e desbloqueio (UNLOCK) so os mecanismos utilizados para evitar que uma informao que est sendo manipulada por um usurio (USU1) seja alterada por outro (usu2). Enquanto o USU1 dela se utiliza o USU2, no ter acesso a mesma ou o ter apenas para leitura e receber um aviso do SGBD de que a informao est sendo acessada por outro usurio e pode ser modificada. Existem vrios nveis de LOCK. As opes variam conforme o produto (SGBD) analisado, sendo que os mais comuns ocorrem a nvel de tabela, pgina (conjunto de registros) e linha (nvel mais baixo).
17

Cabe lembrar que o nvel de bloqueio influi na performance do SGBD em ambientes de misso crtica (altos ndices de acesso concorrente), sendo que quanto menor o nvel de LOCK, a performance tende a ser melhor. Ressalta-se que alm desse, existem outros fatores que influenciam na performance do SGBD.

7. INTEGRIDADE DE DADOS A integridade de dados refere-se a mecanismos que esto disponveis nos SGBD, que garantem a consistncia dos dados armazenados no SGBD, segundo parmetros de validao, especificados no momento de criao do BD, em conjunto com as estruturas de dados. Esse objetivo s se tornou disponvel, como recurso do SGBD, com o advento dos modelos Relacionais e consta como pr-requisito para enquadramento de produtos nessa categoria de SGBD. No captulo dedicado aos SGBD relacionais trataremos esse assunto com maior riqueza de detalhes.

18

CAPTULO V LINGUAGENS DE BANCO DE DADOS


As linguagens de banco de dados consistem na interface do usurio para interagir com o SGBD. Neste texto destacamos cinco modalidades de linguagens que so mais comunmente utilizadas nessa interao: SQL, autocontida, hospedeira, visuais e aquelas voltadas para INTERNET. Esta uma classificao meramente didtica que objetiva apenas demostrar formas diferenciadas de interao com o BD. Outros autores possuem diferentes classificaes. 1. SQL (STRUCTURED QUERY LANGUAGE) A liguagem SQL (anteriormente escrita SEQUEL) foi criada junto com o Sistema R, primeiro prottipo de SGBD-R, desenvolvido de 1974 a 1979 no IBM San Jose Research Laboratory. A veso original do SQL foi baseada em uma linguagem anterior chamada SQUARE. As duas linguagens so essencialmente a mesma, mas a SQUARE usa uma sintaxe bem mais matemtica, enquanto a SQL mais parecida com o ingls. A linguagem SQL mais do que somente uma linguagem de consulta, sem que isto se oponha ao query no seu nome. Ela fornece funes de recuperao e atualizao de dados, alm de criao, manuteno da estrutura de dados e controle do ambiente do BD. uma linguagem essencialmente interativa, porm pode ser embutida em outras linguagens procedurais (que neste texto chamamos linguagem hospedeira) para ser utilizada em programas batch ou on-line, que acessam o BD. Suas principais caractersticas so: _ Padro ANSI (American National Standard Institute). O ANSI estabeleceu-se como um padro de fato de SQL para os fornecedores de produtos relacionais, que atualmente lideram o mercado. Este aspecto facilita a interoperabilidade entre BDs de diferentes fornecedores. _ Padro de acesso. Todo o acesso ao BD Relacional feito em SQL, mesmo que embutida em outra linguagem. _ Interpretada (no compilada), caracteristica que prov maior grau de independncia de dados aos BD relacionais, ou seja, faz com que a aplicao reconhea alteraes nas estruturas de dados, sem necessidade de ser recompilada.

19

_ DDL, DML e DCL. O SQL possui esses trs grupos de comandos, montados conforme a funo do comando no banco de dados. Esta caracterstica tambm relaciona-se independncia de dados, uma vez que pode-se descrever os dados (DCL) de forma independente das aplicaes (DML). _ DDL (Data Definition Languge). Linguagem para definio de dados, que compreende os seguintes comandos SQL: _ CREATE - Utilizado para criar objetos (tabela, ndice, view, sequence, etc.) no BD. Exemplo: Criao da tabela funcionrio com os atributos matricula e nome. CREATE TABLE funcionrio (matricula number(05) nome char (30); _ ALTER - Utilizado para alterar objetos do BD (adicionar colunas, modificar tipo de dados, adcionar integridade, etc.). Exemplo: Adio da integridade de chave primria tabela funcionrio. ALTER TABLE funcionrio ADD CONSTRAINT PRIMARY KEY (matricula); _ DROP - Exclui objetos do BD. Exemplo: Excluso da tabela funcionrio do BD. DROP TABLE funcionrio

20

_ DML (Data Manipulation Languge). Linguagem para manipulao de de dados, que compreende os comandos para que o usrio interaja com os dados armazenados no BD. SELECT - Comando de leitura, utilizado para que o usurio possa efetuar consultas (query) nas tabelas do banco de dados. o comando mais poderoso do SQL, efetua as sete operaes da algebra relacional conforme veremos no captulo sobre banco de dados Relacional. Seu formato bsico SELECT-FROM-WHERE (leia-de-onde). Pode ser combinado com os demais comandos SQL constituindo sub-queries. O resultado de todo comando SELECT uma tabela, que pode conter uma, nenhuma ou N linhas. Exemplo: Ler da tabela funcionrio matricula e nome, onde o salrio seja maior do que 500,00. SELECT matricula, nome FROM funcionrio WHERE salrio > 500,00;

INSERT - Utilizado para incluir registros nas tabelas do banco de dados. Exemplo: Incluso de um registro na tabela funcionrio. INSERT INTO funcionrio (matricula, nome) VALUES ( 20,Maria do Carmo); UPDATE - Utilizado para alterar dados nas tabelas do banco de dados. Exemplo: Alterao no salrio do funcionrio de matrcula igual a 20. UPDATE funcionrio SET salrio=1200 WHERE matricula=20; DELETE - Utilizado para excluir registros das tabelas do banco de dados. Exemplo: Excluso do funcionrio de matrcula igual a 20. DELETE funcionrio WHERE matricula=20;

21

2. LINGUAGEM AUTOCONTIDA Esta modalidade de linguagem a extenso procedural do SQL, que nos SGBD-R utilizada para desenvolvimento de programas que ficam residentes no banco de dados (TRIGGERS, STORED PROCEDURES, FUNCES). Acrescenta ao SQL interativo estruturas de deciso (IFTHEN-ELSE) e repetio (LOOP, FOR e/ou DO WHILE). uma linguagem proprietria (Cada SGBD possui a sua). Os programas escritos nessa linguagem geralmente assemelham-se a programas PASCAL. 3. LINGUAGEM HOSPEDEIRA So linguagens procedurais de 3 gerao (notadamente o COBOL) utilizadas como hospedeiras (host) de comandos prprios de banco de dados. Linguagens hospedeiras foram muito utilizadas nos SGBD dos modelos Hierrquicos e Rede, dado que nestas geraes de SGBD ainda no existia o SQL com toda a sua simplicidade e potencialidade. Por outro lado, imperava uma forte cultura nas linguagens COBOL, PL/1, FORTRAN, etc.... que foi aproveitada pelos fabricantes de SGBD, facilitando a introduo dessa nova cultura. Os SGBD que utilizam linguagens hospedeiras. possuem um software PR-COMPILADOR, que inserido na rotina de compilao do fonte do programa hospedeiro, para converter os comandos de BD (estranhos linguagem HOST) em linguagem objeto ou chamadas (CALL) de rotinas intelegveis pelo compilador a linguagem. Esquema de compliao com linguagem hospedeira:
PROGRAMA FONTE HOSPEDEIRO

PR_ COMPILADOR

PROGRAMA PR_ COMPILADO

PROCESSO NORMAL DE COMPILAO

22

4. LINGUAGEM VISUAL As linguagens visuais atualmente dominam o ambiente de desenvolvimento para a arquitetura Cliente/Servidor. Nessa arquitetura, so utilizadas para desenvolver a interface Cliente da aplicao. Recebem a denominao de FRONT-END. Geram aplicaes para ambiente grfico, padro WINDOWS. So orientadas a eventos e em sua maioria, baseiam-se na tecnologia de Orientao a Objetos, apresentando recursos como classe, objeto, herana, polimorfismo, etc.. Utilizam o SQL como linguagem para acesso aos bancos de dados relacionais, atravs de APIs (Aplication Program Interface) nativas ou genricas (ex: ODBC e ODAPI). Como exemplos de linguagem dessa categoria podemos citar: DELPHI, VISUAL BASIC, POWER BUILDER, CENTURA, etc.. Nossa maior preocupao neste texto chamar a ateno do leitor para o fato de que essas linguagens so FRONT_ENDs de SGBD relacionais. Apesar de serem orientadas a objeto, no devem ser confundidas com os BD relacionais ou Orientados a Objeto, este ltimo, ainda uma tecnologia que ocupa um espao restrito no mercado. Esquema de acesso a BD relacional com linguagem visual:

SQL PRGRAMA EM LIGUAGEM VISUAL DADOS

SQL PARO

API
DADOS

BD-R

5. LINGUAGENS PARA INTERNET Nesse grupo de linguagens, incluem-se aquelas utilizadas para manipular, formatar, manipular e apresentar as informaes que so acessadas na INTERNET atravs dos Browsers, das quais, destacam-se: HTML, JAVA SCRIPT, ASP e JAVA.

23

CONCLUSO O banco de dados constitui a parte esttica da aplicao. A dinmica de um sistema dada pelas linguagens que armazenam, recuperam e manipulam as informaes contidas no BD e existem diversas maneiras para se executar essas tarefas. A evoluo das linguagens aponta para utilizao de produtos no proprietrios e que privilegiem a reutilizao do cdigo, alm dos dados que j so amplamente reutilizados atravs da tecnologia relacional. Isso porque, o cdigo contm a inteligncia das aplicaes (regras do negcio) que, em ltima anlise, refletem o conhecimento da empresa a respeito do seu negcio. A reutilizao do cdigo pode trazer, como benefcios imediatos, a reduo no tempo e custo de desenvolvimento e manuteno de novas aplicaes, a padronizao de processos e a melhoria constante na qualidades dos sistemas gerados. A medida que surgem novas tecnologias para acesso s informaes do BD, muitos sistemas antigos permanecem como legados, porque so sistemas crticos, de difcil substituio, ou porque so satisfatrios e, em anlise de custo / benefcio, tem o seu redesenvolvimento desaconselhado. Alm disso, as necessidades de acesso s informaes esto se diversificando, as empresas esto abrindo suas fronteiras e oferecendo acesso direto do cliente a suas bases de dados. Como resultado, comum observarmos ambientes de sistemas heterogneos, desenvolvidos com tecnologias diferentes, em termos de linguagens e banco de dados, onde observamos COBOL convivendo com DELPHI, VB, HTM, JAVA, etc.. Nesse contexto, tambm surge como uma tendncia o desenvolvimento de aplicaes em trs ou N camadas. O foco principal dessa tecnologia maximizar a reutilizao de cdigo, atravs do desenvolvimento das regras do negcio em componentes reutilizveis, que obedeam a padres de mercado (CORBA, COM/DCOM, EJB) e que funcionem como linguagens universais, podendo ser acionados a partir de interfaces clientes desenvolvidas em diferentes linguagens. Em sntese, o bancos de dados relacionais tornaram-se grandes repositrios de dados, constituindo uma tecnologia madura que tem atendido satisfatoriamente o mercado. Do lado das aplicaes, observase uma tendncia a diversificao de tecnologias, sem descuidar dos benefcios que podem trazer a reutilizao das regras de negcio.

24

CAPTULO VI

BANCO DE DADOS RELACIONAL


O Modelo Relacional de Banco de Dados, utiliza a teoria de conjuntos como base conceitual para a formulao de seus conceitos. Esse pressuposto facilita o entendimento por parte do usurio e possibilita a representao do mundo real de forma mais natural. O Modelo Relacional, comeou a ser divulgado a partir de 1970, por E. F. Codd, um cientista da IBM, que utilizou o SISTEMA-R como produto experimental para a comprovao da teoria Relacional, publicada em uma srie de artigos, que apresentaram os requisitos desse modelo em doze regras atualmente seguidas pelos Sistemas Gerenciadores de Banco de Dados Relacionais (SGBD-R). As doze regras de Codd, foram reeditadas por diversos autores que escreveram sobre o modelo Relacional. Em nossa pesquisa bibliogrfica para elaborao desse material, notamos que, existem interpretaes ambiguas e at contraditrias em relao a essas regras. Portanto, para notear o estudo do modelo Relacional, adotamos a abordagem de C. J. DATE, que apresenta o Modelo Relacional como possuindo as seguintes caractersticas fundamentais, que o distingue dos demais modelos: _ Estrutura de dados tabular _ Regras de integridade _ Operadores relacionais _ Utilizao do SQL (Structured Query Language) O modelo Relacional, assim como seus antecessores, nasceu no ambiente dos computadores de grande porte (mainframe). Sofreu resties ao uso, por demandar muita memria principal para alcanar uma performance (tempos de resposta) que o tornasse comercialmente vivel. Ganhou fora a partir do incio a dcada de 80, com a revoluo tecnolgica provocada pela produo em larga escala dos microcomputadores PC, o que propiciou o barateamento do harware. Atualmente o modelo relacional um padro seguido, praticamente por todos os formecedores de SGBD do mercado, Dentre os quais destacam-se: ORACLE, SYBASE, MYCROSOFT (SQL SERVER e ACCESS), INFORMIX e IBM DB/2.

1. TERMINOLIGIA DO MODELO RELACIONAL


25

a. Os SGBD RELACIONAIS representam os dados sob a forma de TABELAS bidimensionais (linhas X colunas), denominadas RELAES. b. As linhas das tabelas so conhecidas como TUPLAS e as colunas como ATRIBUTOS. c. O nmero de atributos (colunas) de uma relao (tabela) determina o GRAU DA RELAO. Portanto uma relao com quatro colunas possui grau quatro. d. A interseo CLULA. linha X coluna de uma tabela demomina-se

e. O contedo de uma clula denomina-se valor de atributo . f. Cada clula de uma tabela relacional comporta apenas um valor de atributo, caracterstica a qual designa-se por ATOMICIDADE (valor atmico). g. O conjunto de valores possveis para um atributo de tabela denominase DOMNIO. Por exemplo, o domnio para o atributo cargo pode ser definido como: Valor numrico entre 1 e 10.

ATRIBUTO

RELAO: FUNCIONRIO MATR NOME CARGO DT_NASC 01 MIRIAM 01 25/09/62 02 JUVENAL 03 18/04/70 02 10/02/68 03 GABRIELA
VALOR DE ATRIBUTO

TUPLA

CLULA

2. REGRAS DE INTEGRIDADE
26

Integridade de dados o conjunto de parmetros (regras do negcio) previamente estabelecidos e criados no banco de dados, aos quais os dados so submetidos, para garantir que de um processo de atualizao no resultem dados inconsistentes. Uma das caractersticas mais fortes dos SGBD-R, est em oferecer mecanismos para a criao de regras de integridade diretamente no banco de dados. Nesse ponto a grande vantagem em relao aos demais modelos (Hierrquico e Rede), consiste n o gerenciamento automtico e centralizado de rotinas de integridade pelo SGBD, do que decorrem fatores como a eliminao de cdigos redundntes e maior segurana no que se refere consistncia das informaes. Por outro lado, a possibilidade de de definir integridade no BD, no descarta a hiptese de mante-la no fonte da aplicao que acessa o BD. Na arquitetura Cliente/Servidor, essa prtica muito corriqueira e pode trazer significativos ganhos de performance. As regras de integridade de dados podem ser implementadas nos SGBDR de forma DECLARATIVA ou PROCEDURAL: a. INTEGRIDADE DECLARATIVA A integridade declarativa implementada no BD, atravs de parmetros opcionais da linguagem de definio de dados (DDL). Os tipos mais comus de integridade declarativa so: CHAVE PRIMRIA, DOMNIO e INTEGRIDADE REFERENCIAL. A integridade de CHAVE PRIMRIA garante que a chave primria da tabela no contenha valores em duplicata e nem valor NULO. A integridade de DOMNIO permite restringir o universo de valores vlidos para uma coluna. A integridade REFERENCIAL garante o sincronismo de valores entre a chave estrangeira (foreign key) e a respectiva chave primria. Esse tipo de integridade ser tratado com maiores detalhes no item c deste capitulo.

27

Na DDL do ORACLE, por exemplo, o comando CREATE apresenta as seguintes opes de integridade declarativa: _ PRIMARY KEY - Garante a integridade de chave primria. _ NOT NULL - Torna o campo de preenchimento obrigatrio. _ CHECK - Permite a integridade de domnio. _ UNIQUE - Evita a ocorrncia de valores em duplicata. _ FOREIGN KEY - Implementa a integridade referencial. Exemplo: CREATE TABLE funcionrio (matricula number(05) PRIMARY KEY nome char (30) NOT NULL sexo char (01) CHECK sexo = F or M; No exemplo, o ORACLE encarrega-se da integridade de chave primria (PRIMARY KEY), da condio de campo obrigatrio (NOT NULL) e da integridade de domnio (CHECK), todas especificadas de forma declarativa. Nenhuma linha de cdigo necessria nos programas que acessam BD para garantir essas integridades.

28

b. INTEGRIDADE PROCEDURAL A Integridade Procedural apresenta-se sob a forma de um programa, cuja lgica escrita pelo programador, na linguagem procedural nativa do SGBD. Esse tipo de integridade supre as necessidades no cobertas pelos parmetros de integridade declarativa. No ORACLE a integridade procedural pode ser criada atravs de TRIGGERS, STORED PROCEDURES ou FUNES DO USURIO. Estes elementos so escritos em PL/SQL que a extenso procedural do SQL desse SGBD. Um TRIGGER (gatilho) criado para disparar, automaticamente, sempre que o SGBD detectar a ocorrncia de um ou mais comandos de acesso a tabela. Exemplo: CREATE TRIGGER atualiza_saldo AFTER INSERT ON TABLE lanamentos BEGIN UPDATE Tab_saldo SET saldo_atual=saldo_atual + valor_lanamento; END; No exemplo, sempre que um registro for includo na tabela lanamentos o trigger dispara e atualiza o saldo_atual na tabela tab_saldo. Nem todos os SGBD possuem integridade procedural. Esse recurso mais frequente nos SGBD de maior porte como ORACLE, DB/2, INFORMIX, SQL SERVER, etc..

29

c. INTEGRIDADE REFERENCIAL A Integridade Referencial o mecanismo dos SGBD-R que, no processo de atualizao do BD, mantm o sincronismo entre duas tabelas relacionadas, em relao aos valores da chave estrangeira e da respectiva chave primria.
FUNCIONRIO MATRICULA- PK 1

TABELA PAI

TABELA FILHO

DEPENDENTE MATRICULA- FK

A integridade referencial evita a ocorrncia de registros orfos no banco de dados, ou seja, registros filhos sem a correspondente linha de referencia na tabela pai. Os SGBD_R que seguem o padro SQL ANSI/92, suportam a integridade referencial de forma declarativa. Possuem ainda aes referenciais, que propagam atualizaes e excluses efetuadas na tabela pai para a tabela filho. As aes referenciais propiciam, por exemplo, que a excluso de um registro pai provoque a excluso automtica de seus respectivos filhos (excluso em cascata), ou que a alterao no valor de uma chave primria reflitam automticamente para os registros que a referenciam (atualizao em cascata).

30

Exemplo: CREATE TABLE funcionrio (matricula number(05) PRIMARY KEY nome char (30) sexo char (01)); CREATE TABLE dependente (id_dependente number(05) PRIMARY KEY nome_dependente char (30) data nascimento date matricula_funcionrio number(05) FOREIGN KEY REFERENCES funcionrio.matricula ON DELETE CASCADE); O exemplo apresenta a integridade referencial, declarada na tabela dependente, indicando que o campo matricula_funcionrio dessa tabela, refere-se ao campo matricula da tabela funcionrio. Com essa declarao o SGBD garante que a incluso de um DEPENDENTE, somente ser valida caso exista o FUNCIONRIO correspondente. Por outro lado, a clusula ON DELETE CASCADE indica que sempre que for excludo um registro da tabela funcionrio, o SGBD deve excluir automticamente os registros da tabela dependente a ele relacionados.

31

3. OPERADORES RELACIONAIS Os Operadores Relacionais constituem mecanismos do SGBD-R para recuperao de informaes no Banco de Dados. Inserem-se no contexto da Algebra Relacional que possui sete operadores, sendo trs relacionais (PROJEO, SELEO e JUNO) e quatro operadores tradicionais de conjunto (UNIO, INTERSEO, DIFERENA e PRODUTO CARTEZIANO). Para que um SGBD seja considerado relacional basta que possua apenas os operadores relacionais. Os operadores de conjunto podem ser simulados a partir dos primeiros. No SQL/ANSI, os sete operadores so implementados por variaes nas clusulas do comando SELECT. No prximo captulo trataremos dos operadores relacionais com exemplos da aplicao de cada um deles.

32

4. PROPRIEDADES RELACIONAIS As Propriedades relacionais so consideraes bvias, porm elucidativas a respeito do funcionamento e da filosofia que norteia o desenvolvimento dos SGBD-R. Essas propriedades derivam da teoria de conjuntos e algumas se sobrepem ou confirmam as regras de integridade. a. Uma tabela no deve possuir duas linhas iguais. Isto se explica pelo fato de que as linhas so componentes de um conjunto (a tabela) e se faz necessrio poder distinguir os elementos de um conjunto. Assim sendo, pelo menos um atributo componente da linha deve possuir um valor que a diferencie das demais. Nos modelos relacionais o diferencial mnimo entre duas linhas de uma tabela a chave primria. b. Toda a tabela de um BD relacional deve possuir chave primria. Essa propriedade decorre da anterior. Atualmente, todos os SGBD-R disponveis no mercado mantm automaticamente a unicidade da chave primria. Por outro lado, alguns produtos relacionais permitem a criao de tabelas sem PK, deixando a critrio do analista a sua declarao ou no, o que contraria esta propriedade mas atribui maior flexibilidade ao produto. c. Cada tabela deve possuir um nome prprio, distinto das demais tabelas do mesmo banco de dados. Essa propriedade tambm deriva da teoria de conjuntos, j que as tabelas so componentes do conjunto BD. Ressalta-se que em banco de dados distintos duas tabelas podem ter o mesmo nome. d. Cada atributo de uma mesma tabela deve possuir um nome diferente. Por outro lado, o mesmo atributo pode aparecer em outra tabela com o mesmo nome ou com nome diferente (sinnimo). e. Os SGBD-R somente operam com estruturas de dados de formato tabular, normalizadas pelo menos em !FN (1 forma normal), onde a principal caracterstica a atmicidade, ou seja, ocorrncia de apenas um valor de atributo para cada clula da tabela. Esse nvel de normalizao exigido para tornar possvel a aplicao da lgebra Relacional para recuperar informaes contidas nas tabelas do BD. Nveis mais altos de normalizao (2FN a $FN) so teis para diminuir a redundncia, melhorar a consistncia e integridade dos dados.

33

f. A ordem das linhas e colunas na tabela irrelevante, pois pode ser facilmente modificada nas consultas, atravs dos recursos da lingugem SQL (Structured Query Language). g. Os SGBD-R devem ser capazes de tratar, de maneira diferenciada o valor NULO (NULL), que indica ausncia de valor para um atributo em determinada linha. Nulo corresponde na teoria de conjuntos a conjunto vazio e diferente de zero ou branco. 5. VANTAGENS DO MODELO RELACIONAL As vantagens em relao aos sistemas de arquivos convencionais e SGBD Hierrquicos e Rede so: a. Linguagem SQL interativa e muito prxima da linguagem natural escrita (ingls); b. Facilidade no entendimento da estrutura de dados tabular; c. Maior possibilidade de utilizao direta pelo usurio final; d. Centralizao da integridade no BD. e. Reduo no tamanho dos cdigos de programa; f. Maior integridade e consitncia de dados; g. Maior segurana; h. Maior flexibilidade para acrscimo de novas informaes no BD; i. Possibilidade de criar gatilhos (TRIGGERS) armazenados (STORED PROCEDURE); j. Maior Produtividade. l. Padronizao dos produtos facilitando a difuso e preservao da cultura relacional. e procedimentos

34

CAPTULO VII

LGEBRA RELACIONAL
A lgebra Relacional uma teoria matemtica baseada nas relaes entre conjuntos. Da sua aplicao ao Modelo Relacional de Banco de Dados, resultou a possibilidade de armazenar estruturas de dados complexas (como uma ficha cadastro de clientes), de maneira fragmentada, no formato tabular dos SGBR-R e recompor a informao original, a partir da formulao de relaes entre as tabelas do banco de dados. Essas relaes so providas pelos operadores da lgebra relacional, que se encontram disponveis nos recursos da linguagem SQL (Structured Query Language). Os operadores da lgebra relacional classificam-se em dois grupos: _ OPERADORES TRADICIONAIS DE CONJUNTO . UNIO . INTERSEO . DIFERENA . PRODUTO CARTESIANO _ OPERADORES RELACIONAIS . PROJEO . SELEO . JUNO Para classificar-se um SGBD como Relacional, fundamental que ele possua, entre outras caractersticas, no mnimo os trs operadores relacionais, haja vista que, nem todos os SGBD-R possuem os sete operadores. Os Operadores Tradicionais so mais encontrados em SGBD mais robustos, como ORACLE, SYBASE e DB/2.

35

1. ESTUDO DE CASO

O grfico abaixo corresponde ao Modelo de Entidades e Relacionamentos (MER) de um banco de dados, que ser utilizado como referncia para o estudo dos operadores relacionais.

CLIENTE 1

N CONTA

36

Segue uma amostragem das tabelas do banco de dados representado no MER: CLIENTE ID-CLI 001 002 003 004 005 006 007 008 NOME RITA MARCELO CARLA VTOR RAQUEL BRUNA SNIA GETLIO ENDEREO TIPO SQN V GUAR C GAMA E SQS C SQS E GUAR V CRUZEIRO C SQN C
C = COMUM E= ESPECIAL V= VIP

CONTA_CORRENTE NUMAGENCIA CONT ID-CLI A 106 001 004 106 002 003 106 040 003 167 001 005 167 005 007 167 006 008 202 001 001 202 002 003 202 003 002 202 004 004

SIT 0 2 0 0 0 2 0 1 0 2

SALDO 20.000,00 250,00 500,00 50,00 10,00 20,00 150,00 0 30,00 50.000,00
0 = ATIVA 1 = INATIVA 2 = BLOQUEADA

37

2. GENERALIDADES a. Nos SGBD que utilizam o SQL padro ANSI (Americam National Standard Institute), os operadores da lgebra Relacional so implementados por variaes de parmetros na sintaxe do comando SELECT, que um comando de leitura da base de dados. b. A sintaxe utilizada para os comandos SELECT, que aparecero nos exemplos, foi extrada dos manuais do SGBD ORACLE, que segue o padro SQL ANSI. A estrutura bsica do comando SELECT : SELECT colunas.... ou * (que significa todas as colunas) FROM tabelas ..... WHERE condio........

c. As operaes da lgebra relacional geram sempre uma tabela resultado residente em memria principal (tabela virtual), que em analogia com a teoria de conjuntos, pode ser vazia, unitria ou conter N linhas. d. As operaes podem ser efetuadas entre duas tabelas virtuais atravs da combinao de dois comandos SELECT em uma nica sentena. e. comum a combinao de diversos operadores da gebra Relacional em um nico comando SELECT. A anlise individual de cada um deles um exerccio meramente didtico. f. As situaes criadas, so apenas ensaios, que no esgotam as possibilidades de utilizao dos operadores. Alm disso, uma mesma necessidade pode ter mais de uma soluo. Portanto a utilidade dos operadores depende do problema tratado e da criatividade do tcnico.

38

3. OPERADORES DE CONJUNTO a. UNIO A unio de duas tabelas A e B, resulta numa tabela virtual C, contendo o total de linhas das tabelas envolvidas na operao. No sistema exemplo, imagine que cada agncia mantenha os dados cadastrais de CLIENTE em servidores locais de sua rede, e que esses servidores esto ligados em um servidor corporativo. Para se obter no servidor corporativo uma viso nica, que contenha os dados de todos os clientes do Banco, pode-se utilizar o operador UNION da seguinte maneira: SELECT * FROM cliente@agencia1; UNION SELECT * FROM cliente@agencia2; . . UNION SELECT * FROM cliente@agenciaN; O resultado seria idntico ao que temos na amostragem da tabela CLIENTE do sistema exemplo: ID-CLI 001 002 003 004 005 006 007 008 NOME RITA MARCELO CARLA VTOR RAQUEL BRUNA SNIA GETLIO ENDEREO SQN GUAR GAMA SQS SQS GUAR CRUZEIRO SQN TIPO V C E C E V C C

Obs: Os SELECTs devem referenciar os mesmos atributos e na mesma seqncia.

39

b. INTERSEO A Interseo entre duas tabelas A e B, resulta numa tabela virtual C, contendo as linhas comus s duas tabelas envolvidas na operao. No sistema exemplo, considere a necessidade de se listar o IDCLI" de clientes que possuam, simultaneamente, CONTAS_CORRENTES ativas e bloqueadas. Para atender a esse requerimento, pode-se utilizar o operador INTERSECT da seguinte maneira: SELECT id_cli FROM conta_corrente WHERE sit = 0 INTERSECT SELECT id_cli FROM conta_corrente WHERE sit = 2; Considerando a amostragem da tabela CONTA_CORRENTE do sistema exemplo, o resultado do SQL anterior seria: ID-CLI 004 003

Obs: Os SELECTs devem referenciar os mesmos atributos e na mesma seqncia.

40

c. DIFERENA A Diferena entre duas tabelas A e B (na ordem A - B), resulta numa tabela virtual C, contendo as linhas pertencentes exclusivamente tabela A e no a B. No sistema exemplo, considere a necessidade de se listar o ID-CLI" de clientes que no possuam contas_correntes INATIVAS ou BLOQUEADAS, somente ATIVAS. Para atender a esse requerimento, pode-se utilizar o operador MINUS da seguinte maneira: SELECT id_cli FROM conta_corrente WHERE sit = 0 MINUS SELECT id_cli FROM conta_corrente WHERE sit = 2 OR sit = 1; Considerando a amostragem da tabela CONTA_CORRENTE do sistema exemplo, o resultado do SQL anterior seria: ID-CLI 005 007 001 002

Obs: Os SELECTs devem referenciar os mesmos atributos e na mesma seqncia.

41

d. PRODUTO CARTESIANO A Produto Cartesiano entre duas tabelas A x B resulta numa tabela virtual C, contendo todas as linhas da tabela A combinadas com todas as linhas da tabela B, atravs da concatenao de suas linhas. Essa operao tem uma certa semelhana com a JUNO, pois combina dados de mais de uma tabela, exceto que no estabelece nenhum critrio (join condition) para isso. Geralmente o Produto utilizado para construo de massas de teste ou quando o tcnico esquece de colocar o join condition em um SELECT que envolva duas ou mais tabelas. Nesse caso, pode resultar numa tabela enorme. Por exemplo, o produto entre uma tabela A com 50 linhas e uma tabela B com 100 linhas resulta numa tabela C com 5.000 linhas. O SELECT a seguir efetua um produto entre as tabelas CLIENTE e CONTA_CORRENTE: SELECT nome, saldo FROM cliente, conta_corrente;

42

Considerando as amostragens das tabelas do sistema exemplo referenciadas no comando anterior, a tabela resultado teria 80 linhas, com o seguinte aspecto: NOME SALDO RITA 20.000,00 RITA 250,00 RITA 500,00 . . . . MARCELO 20.000,00 . . MARCELO 50,000,00 . . . . SNIA 30,00 . . . . . . GETLIO 50,000,00

43

3. OPERADORES RELACIONAIS e. PROJEO A Projeo consiste em obter um subconjunto de colunas de uma ou mais tabelas_base, como resultado de uma consulta parcial aos dados disponveis no banco de dados. Geralmente utilizada em conjunto com as demais operaes para produzir resultados de consultas, ou ainda, para criar vises (VIEWs), que restringem o acesso do usurio a determinados atributos da base de dados. No sistema exemplo, uma consulta contendo nome e endereo dos clientes, corresponde a uma PROJEO elaborada a partir da tabelabase CLIENTE, atravs da seguinte sentena SQL: SELECT nome, endereo FROM cliente; Considerando a amostragem da tabela CLIENTE do sistema exemplo, o resultado do SQL anterior seria: NOME RITA MARCELO CARLA VITOR RAQUEL BRUNO SNIA GETLIO ENDEREO SQN GUAR GAMA SQS SQS GUAR CRUZEIRO SQN

44

f. SELEO Tambm conhecida como Restrio, essa operao tem por finalidade selecionar um subconjunto de linhas de uma ou mais tabelas_base, de acordo com critrios (where criteria), que envolvem atributos e valores para filtrar os dados desejados, gerando uma consulta parcial aos dados disponveis no banco de dados. Geralmente utilizada em conjunto com as demais operaes para produzir resultados de consultas, ou ainda, para criar vises (VIEWs), que restringem o acesso do usurio a determinadas linhas de tabelas na base de dados. Os Critrios de Seleo so traduzidos na sintaxe do comando SELECT, pela combinao de operadores lgicos (AND, OR, NOT), aritimticos (=, <>, >, <, >= e <=) e operadores SQL (BETWEEM, LIKE, IN, NULL), representados na clusula WHERE. No sistema exemplo, uma consulta contendo somente os clientes VIP, corresponde a uma SELEO elaborada a partir da tabela-base CLIENTE, atravs da seguinte sentena SQL. SELECT * FROM cliente WHERE tipo = V; Considerando a amostragem da tabela CLIENTE do sistema exemplo, o resultado do SQL anterior seria: ID-CLI NOME ENDEREO 001 RITA SQN 006 BRUNA GUAR TIPO V V

45

g. JUNO Essa operao relacional utilizada para compor informaes complexas a partir de tabelas relacionadas. A juno de duas tabelas A e B concatena as linhas das tabelas envolvidas, resultando numa tabela virtual C. Para efetuar a JUNO de duas tabelas essencial que elas estejam logicamente relacionadas, conforme prev o modelo relacional, ou seja, o grau do relacionamento deve ser no mximo 1 : N, sendo que a chave primria da entidade 1 deve figurar como chave estrangeira da entidade N. Alm disso, os valores dessas chaves devem ser coincidentes, para as linhas que se deseja concatenar. A juno notada na sintaxe do SQL, pela comparao de atributos chave primria / chave estrangeira, atravs da clusula WHERE do comando SELECT, o que denominamos condio de juno (join condition). Quando o tcnico esquece de colocar o join condition em um SELECT que envolva duas ou mais tabelas o SGBD geralmente efetua o PRODUTO.

O SELECT a seguir efetua uma juno entre as tabelas CLIENTE e CONTA_CORRENTE: SELECT nome, saldo FROM cliente, conta_corrente WHERE cliente.id-cli = conta_corrente.id-cli;

46

Considerando as amostragens das tabelas do sistema exemplo referenciadas no comando anterior, a tabela resultado seria: NOME RITA MARCELO CARLA CARLA VITOR VITOR RAQUEL SNIA GETLIO SALDO 150,00 30,00 500,00 0,00 20.000,00 50.000,00 50,00 10,00 20,00

Note que a cliente de nome BRUNA no figura na tabela resultado porque no possui registro na tabela CONTA_CORRENTE.

47

PARTE II - PROJETO DE BANCO DE DADOS

INTRODUO
A modelagem de um sistema de processamento de dados pode ser feita a partir de dois enfoques: 1) Enfoque dos DADOS que so processados; 2) Enfoque das FUNES que tratam esses dados. Esses dois enfoques so complementares e, usados conjuntamente, fornecem ao analista os dois principais ngulos do problema em anlise: DADOS E FUNES. O Diagrama de fluxo de dados (DFD) e o Diagrama Hierrquico Funcional (DHF) so exemplos de ferramentas com enfoque FUNCIONAL e o Modelo de Entidade e Relacionamentos (MER) o diagrama utilizado para prover a viso dos DADOS. Os modelos Funcional e de Dados, ao integrarem um projeto de sistemas, constituem-se em importantes instrumentos para, entre outras coisas: _ Apresentar, atravs de diagramas, uma sntese do problema, destacando seus aspectos mais relevantes; _ Oferecer uma viso contextual do sistema em anlise. _ Facilitar a comunicao entre os integrantes da equipe de desenvolvimento (gerentes, analistas, usurios, etc); _ Motivar a participao do usurio no projeto; _ Documentar o processo de anlise, para que o trabalho no sofra soluo de continuidade; Apesar dos dois enfoques (Funcional e de Dados) do processo de anlise de sistemas, este texto trata, especificamente, da MODELAGEM DE DADOS, com o emprego do MODELO DE ENTIDADES E RELACIONAMENTOS e da tcnica de NORMALIZAO, adotando a METODOLOGIA DE PROJETO DESCENDENTE (Setzer, Valdemar) como referencial metodolgico para o proceso de modelagem.

48

CAPTULO VIII NVEIS DE ABSTRAO


Ao projetar um sistema de informaes para ser implantado no computador, o projetista elabora um modelo da realidade, visando adequa-la s limitaes do ambiente do computador. Devido complexidade do mundo real e seguindo a linha de abordagem TOP DOWN, o processo de modelagem atravessa diversas fases, s quais Setzer1 denominou NVEIS DE ABSTRAO, em sua Metodologia de Projeto Descendente, que usaremos como referncia neste texto e que encontra esquematizada na figura a seguir: MUNDO REAL

MODELO DESCRITIVO

Texto, documentos, entrevistas, relatrios, etc..

MODELO CONCEITUAL

MER ou DFD

NORMALIZAO MODELO OPERACIONAL

MER Normalizado

MODELO INTERNO

DDL do banco de dados

Waldemar W. setzer - livro:Projeto de Banco de Dados

49

Os NVEIS DE ABSTRAO, propostos por Setzer, representam as diferentes vises que um analista obtm de uma realidade (MUNDO REAL), a medida que avana no processo de modelagem, at chegar ao sistema implantado. A partir do MUNDO REAL, Setzer prope quatro nveis de abstrao, que so os modelos DESCRITIVO, CONCEITUAL, OPERACIONAL E INTERNO.

1. MUNDO REAL
O MUNDO REAL envolve todos os objetos (normas, pessoas, eventos, fatos, organismos sociais, etc..), que compem o CENRIO, do qual, o analista dever extrair a parte a ser representada no computador, que pode ser uma empresa, um departamento, setor, processo de negcio, etc..

2. MODELO DESCRITIVO
Este modelo representado por um texto contendo a descrio do mundo real (ambiente alvo do estudo), explicitando as caractersticas do problema a ser tratado atravs de regras do negcio, elenco de necessidades, a anlise de requisitos, questionrios, formulrios, relatrios, informaes sobre volume, etc.. Constitui o primeiro nvel da modelagem, onde o analista estabelece as fronteiras do sistema. Neste nvel de abstrao, o modelador identifica a rea alvo da modelagem, descreve o problema a ser solucionado e identifica os componentes sobre os quais se deseja armazenar e recuperar informaes. Deve-se relatar o maior o nvel de detalhes possvel a respeito do problema, cuidando-se para no perder a objetividade. O maior problema do modelo descritivo a falta de padro. Existem vrias maneiras de se descrever o mesmo problema, as palavras possuem significados variados e podem causar dupla interpretao, ou seja, ambigidade. Para amenizar esse problema, deve-se evitar perodos longos, procurar trabalhar com tpicos, frases curtas e utilizar palavras precisas e adequadas ao vocabulrio profissional do usurio.

50

3. MODELO CONCEITUAL
um modelo baseado em smbolos PADRONIZADOS, que expressa, graficamente, os CONCEITOS do MUNDO REAL delineados no Modelo Descritivo. A utilizao de uma simbologia padronizada torna a linguagem mais precisa, o que facilita a comunicao entre os integrantes da equipe de desenvolvimento, especialmente, entre analistas e usurios. Portanto, esse modelo o mais adequado para o registro e validao dos conceitos do mundo real, nas fases do projeto que envolvem o usurio. O produto dessa fase da anlise deve ser um MODELO DE ENTIDADES E RELACIONAMENTOS (MER) enfocando a viso dos DADOS com alto nvel de abstrao, ou seja, voltado para o MUNDO REAL e sem preocupar-se com detalhes do ambiente operacional, como, por exemplo, o software e hardware no qual o sistema ser implantado. Neste nvel da modelagem, deve-se ressaltar os aspectos mais relevantes do problema, ou seja, representa-se principais entidades, relacionamentos, estruturas de dados e integrao com outros sistemas. Os detalhes do banco de dados (chaves primrias, estrangeiras, integridades, etc.) devem ser deixados para a fase seguinte, de construo do modelo operacional.

4. MODELO OPERACIONAL
O modelo Operacional decorre da anlise do modelo Conceitual, visando torna-lo adequado ao ambiente operacional, no qual o sistema ser implantado. No caso especfico deste texto, essa anlise visa adaptar o modelo Conceitual s limitaes de um Sistema Gerenciador de Banco de Dados Relacional (SGBD-R). Obter o projeto das tabelas do banco de dados o principal objetivo dessa fase e para alcana-lo, o analista deve investigar cada entidade do Modelo Conceitual, decompor estruturas em elementos de dados, utilizar a NORMALIZAO e o conhecimento sobre o MODELO RELACIONAL como balizadores de suas aes. Nesta fase, o dicionrio de dados do Modelo Conceitual enriquecido com a escolha das chaves primrias, definio de chaves estrangeiras, ndices, integridades, e outros detalhes essenciais para a criao do banco de dados.

51

5. MODELO INTERNO
Corresponde ao sistema implementado no computador, ou seja, representado pelo conjunto de linhas de cdigo geradas na linguagem do SGBD, que no caso dos modelos Relacionais o SQL (structured query language). Do ponto de vista terico, o modelo Operacional seria o ideal para ser implantado. Porm, a prtica revela que esse modelo ainda pode sofrer modificaes antes que o BD seja criado. Os principais fatores que determinam essas modificaes so a MELHORIA DE PERFORMANCE e a DISTRIBUIO DE DADOS. Visando aumentar a performance, podem ser criadas redundncias, com a desnormalizao e criao de tabelas totalizadoras para gerao de informaes gerenciais. Nesses casos, deve-se ter especial cuidado com a consistncia do BD no processo de atualizao dos dados. Alm disso, deve-se considerar que a redundncia de dados aumenta os custos com processamento e armazenamento de dados, que devem ser compensados pelo benefcio esperado. Com relao distribuio de dados comum a criao de cpias de tabelas (distribuio por replicao) ou a fragmentao de uma entidade do modelo operacional em vrias tabelas no redundantes (distribuio por particionamento). Em ambos os casos, as partes resultantes so distribudas em diversos ns da rede e a manuteno dessas partes ser facilitada caso o SGBD possua algum mecanismo de gerenciamento automtico de distribuio de dados.

52

CAPITULO IX MODELO DE ENTIDADES E RELACIONAMENTOS


O MODELO DE ENTIDADE E RELACIONAMENTOS (MER), foi proposto originalmente por PETER CHEN em 1976. Seu objetivo, ao publicar esse trabalho, era consagrar um mtodo eficiente para representar os dados e ressaltar a diferena entre as estruturas suportadas pelos SGBD HIERRQUICOS, REDE e RELACIONAL. Atualmente o MER tem sido utilizado para representar a viso dos dados no projeto de banco de dados. A principal vantagem do MER a simplicidade. O Modelo de Entidades e Relacionamentos possui apenas trs componentes bsicos: ENTIDADE, ATRIBUTO e RELACIONAMENTO (e seus respectivos smbolos para diagramao). A proposta original de CHEN foi enriquecida por trabalhos de diversos autores, que procuraram atribuir maior capacidade semntica ao MER, o que gerou as camadas EXTENSES. As extenses ao MER possibilitam representar o mundo real com maior riqueza de detalhes. Por outro lado, elas provocaram a diversificao dos padres de notao e terminologia, contrastando com a proposta original de simplicidade e acarretando problemas para a disseminao da cultura. Este captulo procura exprimir uma viso objetiva do Modelo de Entidades, para instrumentalizar o analista frente necessidade de representar a viso dos dados de um projeto de sistema.

53

1. NOTAO E TERMINOLOGIA ENTIDADE a representao genrica de um COMPONENTE DO MUNDO REAL, SOBRE O QUAL DESEJAMOS ARMAZENAR INFORMAES (ATRIBUTOS). As ENTIDADES podem representar coisas tangveis (pessoal, material, patrimnio, etc.) ou intangveis (eventos, conceitos, planos, etc.). Para NOTAR graficamente uma entidade emprega-se um RETNGULO identificado por um substantivo (simples ou composto). Exemplo:

CLIENTE

CONTA_CORRENTE

54

2. REGRAS PARA ATRIBUIO DE NOMES ENTIDADES A literatura no consagra um padro para a atribuio de nomes a entidades, mas, para alcanarmos um mnimo de padronizao, indicamos observar as seguintes regras: - Nomes breves e objetivos, grafados em maisculas e, que identifiquem facilmente o contedo da entidade; - No singular, j que a pluralidade decorre, naturalmente, do nmero de ocorrncias (linhas / tuplas), caracterstica prpria de toda entidade. - Nomes compostos separados por hfen, eliminando-se o uso de preposies ou outros termos de ligao. - Evitar abreviao de nomes. Se necessrio, ampliar o tamanho da figura representativa da entidade.

55

3. ATRIBUTO Os atributos so os dados que devemos armazenar a respeito da entidade, para atender s necessidades de informaes demandadas pelo usurio. Constituem tudo o que se pode relacionar como prprio (propriedade) da entidade e que, de alguma forma, estejam contidos no escopo do problema em anlise. Os atributos qualificam e distinguem as entidades no MER. Em relao ao banco de dados, os atributos representam as colunas, que formam a estrutura de dados das tabelas. As colunas armazenam um valor para cada linha. Esse valor armazenado designado por VALOR DE ATRIBUTO. O conjunto de valores de atributos, distintos por um identificador nico (chave primria) denomina-se OCORRNCIA. Esse conceito anlogo ao de linha (tupla) em tabela relacional e de registro em arquivo convencional. Pode-se exprimir os atributos no MER, conforme mostrado na figura abaixo:

CLIENTE

CONTA_CORRENTE

0 endereo 0 nome 0 identificador

0 tipo (1-poupana, 2- C/C) 0 cod-agncia 0 num-conta

Cabe observar, que a representao de atributos no MER pode poluir o grfico, comprometendo sua objetividade e viso contextual. Esse recurso deve ser reservado para situaes especiais, em que voc queira destacar um atributo, por considera-lo elucidativo para o contexto.

56

4. DICIONRIO DE DADOS Os ATRIBUTOS so usualmente descritos sob a forma de estruturas e elementos no Dicionrio de Dados, onde deve constar uma relao de atributos para cada entidade do MER. As notaes mais utilizadas para criao de dicionrios de dados so as definidas por GANE2 e YOURDON3. Exemplo da notao de Gane para descrio de estruturas de dados: CLIENTE IDENTIFICADOR NOME ENDEREO CONTA_CORRENTE NUMERO_CONTA TIPO-CONTA (1-poupana, 2-c/c) AGNCIA CDIGO_AGNCIA ENDEREO_AGNCIA LANAMENTOS* NUMERO_LANAMENTO DATA TIPO (deb, cre) VALOR

2 3

GANE, CHRIS - LIVRO: ANLISE ESTRUTURADA DE SISTEMAS YOURDON, EDWARD - LIVRO: ANLISE ESTRUTURADA MODERNA

57

A figura a seguir ilustra conceitos vistos nesse captulo, representando a entidade FUNCIONRIO sob a forma de uma tabela do banco de dados.

ENTIDADE DO MER

FUNCIONRIO

TABELA DO BD

ENTIDADE FUNCIONRIO MATRIC 01 02 03 NOME MIRIAM JUCA JOO CARGO 01 03 02 DT-NASC 25/09/62 18/04/70 10/02/68
ATRIBUTOS OCORRNCIA

VALOR DE ATRIBUTO CLULA

58

5. RELACIONAMENTO O relacionamento representa a relao existente entre entidades integrantes de um MER. notado por uma LINHA ligando as ENTIDADES envolvidas e possuem NOME e CARDINALIDADE. Veja a figura a seguir.
RELACIONAMENTO

CLIENTE

1 MOVIMENTA

CONTA_CORRENTE

NOME DO RELACIONAMENTO

CARDINALIDADE DO RELACIONAMENTO

utiliza um LOSANGO para representar o Peter Chen4 RELACIONAMENTO entre entidades, porm, a experincia demostra que o uso dessa notao contribui para poluir o grfico e no produz resultado prtico, exceto em casos de relacionamentos que envolvam mais de duas entidades (relacionamento mltiplo - modelo conceitual).

CLIENTE

1
movimenta

CONTA_CORRENTE

Notao de CHEN

CHEN, PETER - LIVRO: MODELO DE ENTIDADES E RELACIONAMENTOS

59

6. CARDINALIDADE (GRAU DO RELACIONAMENTO) A cardinalidade constitui um indicativo genrico da quantidade de ocorrncias (mxima e mnima) de cada ENTIDADE envolvida no relacionamento. expressa por sinais (flechas, ps-de-galinha, nmeros, letras, etc..), que so grafados sobre a linha do relacionamento, nas duas extremidades do mesmo. A notao para a cardinalidade o item que apresenta maior variao entre os autores que escrevem sobre o MER. Neste texto usaremos uma barra para notar a cardinalidade 1 e o p-de-galinha para a cardinalidade N. Exemplo:
CARDINALIDAD CARDINALIDADE N

CLIENTE

MOVIMENT

CONTA_CORRENTE

Considerando a cardinalidade, o relacionamento pode ser de trs tipos: 1) 1:1 - L-se UM para UM Exemplo:
CLIENTE MOVIMENTA CONTA_CORRENTE

Indica que UMA ocorrncia da entidade CLIENTE relaciona-se com UMA ocorrncia da entidade CONTA-CORRENTE e vice-versa,

60

2) 1:N - L-se UM para MUITOS


Exemplo:

CLIENTE

MOVIMENT

CONTA_CORRENTE

Indica que UMA ocorrncia da entidade CLIENTE relaciona-se com muitas ocorrncias da entidade CONTA-CORRENTE e vice-versa, 3) M:N - L-se MUITOS para MUITOS exemplo:

CLIENTE

MOVIMENTA

CONTA_CORRENTE

Indica que:

- UMA ocorrncia da entidade CLIENTE relaciona-se com MUITAS ocorrncias da entidade CONTA- CORRENTE e; - UMA ocorrncia da entidade CONTA-CORRENTE relaciona-se com MUITAS ocorrncias da entidade CLIENTE. (cada das contas conjuntas)

61

7. NOME DO RELACIONAMENTO o componente do modelo E-R que identifica o relacionamento, justificando e esclarecendo a importncia de sua existncia para o contexto estudado. Exemplo:
NOME DO RELACIONAMENTO

CLIENTE

MOVIMENTA

CONTA_CORRENTE

Nos casos onde o relacionamento bvio torna-se dispensvel a atribuio de nome ao mesmo. O nome do relacionamento recomendvel nas seguintes situaes: - Quando existirem diversas possibilidades bvias de relacionamentos entre o par de entidades, sendo que, deseja-se representar apenas em; - Por questo documentacional, para dar maior clareza ao modelo; - Caso ocorra mais do que um relacionamento entre o par de entidades (relacionamento duplo, triplo, etc.); - No caso de AUTO-RELACIONAMENTOS (entidade relacionando-se com ela mesma- recursividade) - Quando da utilizao do MER para representar modelos a serem implementados em SGBD REDE - Quando da utilizao de CASE para desenho do MER ( caso a ferramenta obrigue)

62

8. PAPEL O papel das entidades no relacionamento fica implcito no nome e na cardinalidade do mesmo e pode ser inferido a partir desses componentes. Porm, especificar o PAPEL que cada entidade desempenha uma alternativa, que pode substituir, com maior preciso, a colocao do nome no relacionamento, atribuindo ao MER maior capacidade semntica. EXEMPLO:

GERENTE

LIDER

LIDERADO

PROJETO

OBS: A maioria das ferramentas CASE no utilizam o PAPEL como alternativa para a construo de MER.

63

9. SENTENAS (REGRAS DO NEGCIO) Duas sentenas so derivadas da leitura do relacionamento. Elas refletem as regras do negcio e ajudam na validao do modelo junto ao usurio. Exemplo:

CLIENTE

TITULAR

CONTA_CORRENTE

_ Sentena-1: UM CLIENTE titular de VRIAS CONTAS-CORRENTES.


CARDINALIDADE

_ Sentena-2: UMA CONTA-CORRENTE tem como titular UM CLIENTE.


CARDINALIDADE 1

OBS: As sentenas sempre comeam com UM / UMA e a cardinalidade considerada a do lado oposto ao da primeira entidade citada na sentena.

64

10. INTEGRIDADE REFERENCIAL (IR) A Integridade Referencial notada no MER atravs de sinalizao colocada no relacionamento junto marca de carnalidade, que indica se o relacionamento OBRIGATRIO ou OPCIONAL (TOTAL / PARCIAL). Os sinais utilizados para notar a IR, variam muito, conforme os autores ou ferramenta CASE adotados e se confundem com a marca de cardinalidade.
Veja no quadro a seguir as notaes mais utilizadas para IR: OPCIONAL
(bolinha aberta) sem marcao | (uma barra vertical) linha do relacionamento tracejada

OBRIGATRIO
(bolinha fechada) | ( uma barra vertical) || (duas barras verticais) linha cheia no relacionamento

AUTOR
JAMES MARTIN DIVERSOS DIVERSOS BACHMAN / GANE

Exemplo:

CLIENTE

MOVIMENT

CONTA_CORRENTE

65

11. REGRAS GERAIS - No podem existir duas entidades iguais no mesmo modelo, ou seja, que representem o mesmo objeto do mundo real e possuam os mesmos atributos; mesmo que elas possuam nomes diferentes. - Cada entidade deve possuir pelo menos dois atributos (colunas) e duas ocorrncias (linhas). _ No Modelo Operacional os relacionamentos devem envolver, no mximo, duas entidades. - Os relacionamentos Mltiplos do Modelo Conceitual devem ser transformados em entidades em sua passagem para o modelo operacional. - Pode existir mais do que um relacionamento entre o mesmo par de entidades (relacionamento duplo, triplo, etc..) - Para cada relacionamento com cardinalidade N:N do Modelo Conceitual, deve ser criada, no Modelo Operacional, uma ENTIDADE ASSOCIATIVA. Essa entidade ser ligada s demais por dois relacionamentos 1:N, sendo que as cardinalidades N de cada relacionamento, sero marcadas ao seu lado. - Deve-se avaliar os relacionamentos com cardinalidade 1:1, verificando se o par de entidades envolvidas pode ser representado por uma entidade nica. - Cada entidade do MER deve participar de pelo menos um relacionamento. Caso isso no ocorra provvel que a entidade isolada no faa parte do contexto modelado.

66

12. VANTAGENS E DESVANTAGENS DO MER Vantagens: - Simplicidade da notao e terminologia - Rpida absoro dos conceitos por parte dos tcnicos - Facilidade de compreenso por parte dos usurios - Grande possibilidade de validao do modelo por parte do usurio - Capacidade de representar diversos nveis de abstrao - Compreenso mais objetiva, mais formal e portanto menos ambgua da do problema.

Desvantagens do MER: - Diversidade da notao e terminologia - Nenhuma nfase aos processos que manipulam as informaes.

67

CAPITULO X TIPOS ESPECIAIS DE RELACIONAMENTO


Os casos apresentados a seguir representam situaes especiais que ocorrem esporadicamente. Geralmente os relacionamentos do MER so do tipo 1:N entre um par de entidades. 1. AUTO-RELACIONAMENTO O auto-relacionamento representa a relao entre linhas de uma mesma tabela. tambm conhecido como RECURSIVIDADE. Exemplos:

FUNCIONRIO

GERENCIA

PEA

COMPE

UM funcionrio gerencia N funcionrios UM funcionrio gerenciado por 1 funcionrio

UMA pea compe N peas UMA pea componente de N peas

68

2. MAIS DE UM RELACIONAMENTO (duplo, triplo, etc.) Ocasionalmente pode ser necessrio representar mais de um relacionamento entre o mesmo par de entidades. Esses relacionamentos sero vlidos desde que denotem situaes distintas e independentes. Neste caso, existiro no Modelo Operacional, tantas chaves estrangeiras quantos forem os relacionamentos.
LOTA

SETOR
CHEFIA

FUNCIONRIO

69

3. RELACIONAMENTO MLTIPLO O Relacionamento Mltiplo, previsto por PETER CHEN, aquele que relaciona mais do que duas entidades. Este tipo de relacionamento somente ocorre em Modelos Conceituais e geralmente denota eventos. Para implementa-lo nos SGBD-R necessrio criar uma entidade, em procedimento anlogo ao que adotado nos casos de relacionamento N:N. Exemplo:

VENDEDOR

VENDE

PRODUTO

CLIENTE

70

CAPITULO XI EXTENSES AO MER


EXTENSES AO MER so conceitos e simbologias criados por diversos autores que escrevem sobre o Modelo de Entidades, para representar situaes especficas, no cobertas pela proposta original de PETER CHEN. As extenses possibilitam ao modelador tornar o modelo mais genrico (conceitual) ou mais especfico (operacional), conforme a necessidade. Neste captulo destacamos algumas extenses as quais julgamos importantes para a abordagem metodolgica que adotamos neste texto. As extenses que abordaremos so as seguintes: _ Generalizao (Setzer e outros) ou Supertipo (Gane) _ Especializao (Setzer e Outros), Subtipo (Gane), particionamento ou classificao (outros). _ Agregao (Setzer)

71

1. GENERALIZAO o resultado da unio de dois ou mais conjuntos de entidades afins, de mais baixo nvel de abstrao, produzindo uma entidade mais genrica. Portanto, a generalizao parte de entidades ESPECFICAS para criar uma GENRICA. O exemplo a seguir apresenta dois tipos de conta (corrente e poupana). No Modelo Conceitual elas apresentam-se como entidades independentes. Verificado que elas possuem atributos em comum, criouse no Modelo Operacional a entidade genrica CONTA, que contm os atributos comuns aos dois tipos de conta, alm de um atributo TIPO para diferenci-las. Essa soluo pode simplificar o processo de atualizao e facilitar determinadas consultas que manipulem informaes gerais sobre os dois tipos de conta. Exemplo:
MODELO CONCEITUAL MODELO OPERACIONAL

CLIENTE

CLIENTE

CONTA_CORRENTE

POUPANA

CONTA

GENERALIZAO ENTIDADES ESPECFICAS


CONTA_CORRENTE

TIPO

POUPANA

72

2. ESPECIALIZAO o resultado da diviso de uma entidade genrica, em subconjuntos de entidades, que contenham atributos especficos de determinadas categorias de entidades. Portanto, a Especializao parte de uma entidade GENRICA para criar ESPECFICAS. Exemplo:
MODELO CONCEITUAL
CLIENTE

MODELO OPERACIONAL

CLIENTE

CONTA

CONTA

ENTIDADE GENRICA
TIPO

ESPECIALIZAO

CONTA_CORRENTE

POUPANA

73

3. AGREGAO Na abordagem top-down (do geral para o especfico) comum representar-se no Modelo Conceitual apenas as entidades mais importantes para a elucidao do problema. Assim, uma nica entidade do Conceitual, ao ser normalizada, pode dar origem a um conjunto de entidades e seus relacionamentos no Modelo Operacional. Portanto, a AGREGAO um recurso do Modelo Conceitual, que representa atravs de uma nica entidade no-normalizada, um conjunto de entidades e relacionamentos do nvel Operacional. A Agregao permite visualizar um modelo complexo, com muitas entidades, de uma maneira mais genrica. Com isso, obtm-se uma melhor viso do contexto, com destaque para as entidades e relacionamentos mais importantes e omisso dos detalhes irrelevantes.

MODELO CONCEITUAL

MODELO OPERACIONAL

CLIENTE

CLIENTE

NOTA-FISCAL

NOTA-FISCAL

ENTIDADES AGREGADAS NORMALIZAO AGREGAO

ITENS-NOTA

PRODUTO

74

4. VARIAO DO CONCEITO DE AGREGAO Alguns autores no admitem o relacionamento mltiplo e utilizam a Agregao para representar o relacionamento de uma entidade com um par de entidades, conforme mostrado no grfico a seguir. Neste texto no adotaremos essa linha de pensamento. Exemplo:
CLIENTE

COMPRA

VENDEDOR

PRODUTO

75

CAPTULO XII NORMALIZAO


A NORMALIZAO uma tcnica de modelagem de dados, criada por E. F. CODD, nos laboratrios de pesquisa da IBM, lanada junto com as bases do modelo Relacional de SGBD. Essa tcnica de modelagem nos proporciona critrios objetivos, para determinarmos quando uma relao (tabela / estrutura de dados) apresenta problemas no tocante observncia de princpios do enfoque relacional, tais como: - Tabela bidimensional (valores atmicos) - Regras de integridade - Mnima redundncia - Nenhuma inconsistncia - Inexistncia de anomalias de atualizao (incluso, alterao e excluso) O processo de NORMALIZAO proposto por CODD, deu origem a trs FORMAS NORMAIS: _ PRIMEIRA FORMA NORMAL - 1FN; _ SEGUNDA FORMA NORMAL 2FN e; _ TERCEIRA 3FN. Outras formas normais foram propostas, por diversos autores, configurando situaes que ocorrem mais raramente, sendo a 4FN a mais significativa. Conforme veremos mais adiante, a 1FN visa to somente colocar as estruturas de dados oriundas dos modelos conceituais no formato tabular adequado, que permita que elas possam ser criadas nos SGBD-R. Nesse sentido, considera-se que relaes em 1FN j esto NORMALIZADAS. As demais formas normais esto dirigidas para evitar REDUNDNCIA DE DADOS, INCONSISTNCIAS e ANOMALIAS DE ATUALIZAO. Redundncia de dados um fato gerador de inconsistncias, j as anomalias de atualizao criam dificuldades operacionais para a manuteno do BD. Esses aspectos reforam a importncia de aplicao da 2FN e 3FN.

76

1. ANOMALIAS DE ATUALIZAO
So problemas presentes em estruturas de dados modeladas de forma inadequada.
TABELA FUNCIONRIO

MATR NOME ENDEREO COD-ORGO SIGLA-ORG QTD-FUNC


03 05 01 02 08 06 . . . JOO JOS VILMA ANA JUCA ANA . . . SQS SQS GAMA GUARA SQN SQN . . . 01 01 05 02 02 02 . . . GETAE GETAE GEPAC GEPRO GEPRO GEPRO . . . 2 2 1 3 3 3 . . .

Exenplos de anomalias de atualizao na tabela FUNCIONRIOS: - A INCLUSO de um novo ORGO na tabela fica condicionada a que algum funcionrio seja alocado nele; - A ALTERAO de nome do rgo GERAE para GETAE provoca atualizao em vrias tuplas, haja vista, que o mesmo pode repetir-se numerosas vezes na relao; - A INCLUSO de um novo funcionrio para o GEORG causa ALTERAO no atributo QT-FUNC em diversas tuplas; - A EXCLUSO da funcionria VILMA da tabela ocasiona perda de informaes sobre o GEPAC;

77

2. TERMINOLOGIA O vocabulrio de NORMALIZAO se confunde com o empregado nos SGBD do modelo RELACIONAL. Isso ocorre por que a tcnica de normalizao uma das bases desse modelo. Os termos abaixo so relevantes para o entendimento das trs formas normais. a. CLULA Interseo (LINHA X COLUNA) de uma relao. b. ITEM REPETITIVO (VALOR NO-ATMICO ou ATRIBUTO NOSIMPLES). Ocorre quando uma clula possui mais do que um valor de atributo, representado por estruturas de dados dos tipos VETOR, MATRIZ ou ITENS DE GRUPO, que impedem a adequada aplicao das operaes relacionais, com SQL (Structured Query Language). c. VALOR ATMICO (ATRIBUTO SIMPLES) Caracterizado quando uma clula possui apenas um valor de atributo. Esta a situao adequada no modelo Relacional. d. CHAVE PRIMRIA CHAVE PRIMRIA, PRIMARY KEY (PK) ou simplesmente CHAVE o atributo ou combinao de atributos que permite a IDENTIFICAO NICA de cada tupla na relao. A PK no admite duplicata e nem valor nulo. Ex: Se pesquisarmos uma relao de FUNCIONRIOS, de PK = MATRICULA, utilizando a matricula como chave de acesso, deveremos obter uma nica tupla como resultado da pesquisa.

78

A chave primria pode ser simples ou composta: - SIMPLES: Constituda de apenas um atributo Exemplo: COD-PRODUTO ==> NOME-PROD NUM-CONTA ==> NOME-CLI, DT-NASC, SALDO - COMPOSTA: formada pela concatenao de dois ou mais atributos. Exemplo: COD-PROD + COD-FORNECEDOR ==> PREO-PROD MATR-ALUNO + MATR-PROF + DATA-PROVA ==> NOTA-PROVA NUM-CONTA + TIPO-APLICAO + DATA ==> SALDO-APLIC

e. DEPENDNCIA FUNCIONAL a correspondncia (identificao unvoca) existente entre dois atributos de uma mesma relao. pode ser de trs tipos: COMPLETA, PARCIAL e TRANSITIVA f. DEPENDNCIA FUNCIONAL COMPLETA (DFC) Relao de identificao unvoca entre o ATRIBUTO-CHAVE e os demais atributos da relao. Ex: COD-CLIENTE ==> NOME-CLIENTE, ENDEREO; COD-CLIENTE + NUM-PRESTAO ==> DT-VENCIMENTO, VALOR;

79

g. DEPENDNCIA FUNCIONAL PARCIAL (DFP) Relao de identificao unvoca entre parte da CHAVE PRIMRIA (PK composta por dois ou mais atributos) e algum dos demais atributos da relao. Ex: COD-PRODUTO + COD-FORNECEDOR ==> NOME-PROD, PREO COD-PRODUTO identifica univocamente o NOME-PROD e um componente da chave primria. Obs.: Para que ocorra dependncia parcial necessrio chave primria composta. Por outro lado, nem sempre que ocorre PK composta haver dependncia parcial. h. DEPENDNCIA FUNCIONAL TRANSITIVA (DFT) Relao de identificao unvoca entre atributos que no fazem parte da chave primria da relao. Ex: PK-MATR ==> NOME, DT-NASC, COD-SETOR, NOME-SETOR COD-SETOR identifica univocamente o NOME-SETOR e no faz parte da chave.

80

3. NOTAO PARA AS ESTRUTURAS DE DADOS Existem diversas notaes, segundo as quais, podemos representar genericamente uma relao. Neste trabalho iremos adotar, principalmente, a notao empregada por CHRIS GANE para a descrio de depsitos de dados e, opcionalmente, a notao de YORDON/DE MARCO.
TABELA VENDA: NUM-NF 001 02 03 . . . NOME-CLI Antnio Juliana Cludia . . . END-CLI SQS SQN SQS . . . DT-VENDA 22/08 10/09 20/07 . . .

ITENS-DE-VENDA COD-PROD QUANT P-U 01 10 20 02 20 10 05 8 5 01 6 20 05 10 5 . . . . . .

A representao genrica da relao VENDA, conforme a notao de GANE, corresponde seguinte:


VENDA ==> nome da relao # NUM-NF NOME-CLI END-CLI DT-VENDA ITENS-DE-VENDA*===========================> grupo repetitivo # COD-PROD QUANT P-UNIT

81

Observaes: - ITENS DE GRUPO so IDENTADOS, com deslocamento para a direita dando idia de hierarquia; - GRUPOS REPETITIVOS so sinalizados com * e/ou grafados no PLURAL. - Os atributos componentes da CHAVE devem receber uma das seguintes notaes: . sublinhados, ou; . Um # ou um C colocados esquerda dos atributos. A representao genrica da tabela VENDA segundo a notao de YORDON/DE MARCO :
VENDA = NUM-NF, NOME-CLI, END-CLI, DATA-VENDA, ITENS-DE-VENDA {COD-PROD, QUANT, P-UNIT}

Observaes: - GRUPOS REPETITIVOS so representados entre chaves; - O ATRIBUTO-CHAVE deve ser sublinhado. - Para relaes com grande nmero de atributos a notao de GANE mais eficiente;

82

4. ESQUEMA DA NORMALIZAO

RELAO NO NORMALIZADA

Tabela com itens de grupo

Eliminar ITENS DE GRUPO

1FN

Escolher a chave primria

Eliminar DEPNDNCIA PARCIAL

2FN

Eliminar DEPENDNCIA TRANSITIVA

3FN

83

5. RELAES NO-NORMALIZADAS Uma relao NO NORMALIZADA aquela que possui atributos do tipo NOSIMPLES (NO-ATMICOS). Para a devida utilizao dos OPERADORES RELACIONAIS necessrio que a relao no-normalizada seja transformada numa forma onde os atributos s contenham VALORES ATMICOS, em outras palavras, preciso tornar a estrutura de dados plana. Esse processo de planificao da relao concretizado aps a sua transposio para a 1FN. Considere a relao abaixo: Relao: CONTA CORRENTE
CONTA-CORRENTE CONTA AGENCIA NUMERO NOME-CLIENTE ENDEREO-CLIENTE DEPENDENCIA TIPO-AGENCIA DESCRIO-TIPO-AGENCIA ENDEREO-DEPENDENCIA LANAMENTOS* NUM-DOCUMENTO DATA-DOCUMENTO VALOR-LANAMENTO Observaes:

- Os atributos CONTA , DEPENDNCIA e LANAMENTOS so itens de grupo; - O atributo LANAMENTOS um grupo repetitivo; - Esses atributos so do tipo no-atmicos, pois suas clulas no contm valores nicos. - A relao CONTA-CORRENTE est na forma NO-NORMALIZADA.

84

6. PRIMEIRA FORMA NORMAL (1FN) Uma relao est em 1FN se todos seus ATRIBUTOS so SIMPLES (ATMICOS). Para colocarmos uma relao em 1FN devemos PLANIFICA-LA, eliminando de sua estrutura os atributos NO-ATMICOS (VETOR, MATRIZ e ITEM DE GRUPO), de modo que, cada clula da tabela possua apenas um valor de atributo. Isto porque os atributos NO-ATMICOS no podem ser implementados nos SGBD RELACIONAIS. A especificao abaixo, corresponde relao CONTA-CORRENTE aps o processo de normalizao (1FN):
CONTA-CORRENTE AGENCIA NUMERO-CONTA NOME-CLIENTE ENDEREO-CLIENTE TIPO-AGENCIA DESCRIO-TIPO-AGENCIA ENDEREO-DEPENDENCIA NUM-DOCUMENTO DATA-DOCUMENTO VALOR-LANAMENTO

Observaes: - O esquema genrico passou a contar somente com ATRIBUTOS SIMPLES. Todos os ITENS DE GRUPO foram eliminados. - Assim como toda a relao em 1FN, a estrutura de dados acima apresenta redundncias e anomalias de atualizao. - CODD estabelece um outro procedimento para normalizao (1FN), que o de decompor a relao no-normalizada em tantas relaes quantos forem os grupos repetitivos alm de incluir uma relao para o conjunto de colunas atmicas. No processo que descrevemos essas relaes surgem naturalmente na derivao das formas normais seguintes (2FN e 3FN).

85

7. ESCOLHA DA CHAVE PRIMRIA Estando a relao em 1FN, o prximo passo no esquema de normalizao a escolha da CHAVE PRIMRIA. CHAVE PRIMRIA Atributo (chave simples) ou combinao de atributos (chave composta) que identifica univocamente as tuplas de uma relao. Na escolha do ATRIBUTO-CHAVE os seguintes aspectos so relevantes: a. No pode conter valor nulo para evitar duplicatas; b. No pode conter duplicatas para garantir a identificao unvoca; c. Deve ser um atributo estvel (no sujeito constantes mudanas); Estvel: MATRICULA, CPF, NUM-CONTA-CORRENTE No estvel: MOEDA-NACIONAL, SALDO, INDICE-ECONMICO d. No deve dar margem ambiguidades para garantir a eficincia de acesso (dar preferncia a cdigos numricos e o mais curtos possveis); Obs1: atributos alfabticos podem gerar dvidas quanto grafia. Ex: Nome de pessoa - Lus ou Luiz; Melo ou Mello Nome de rgo - GERAD; GEDAD; GEPAD; Obs2: Cdigos alfanumricos ou atributos muito extensos so mais propensos a erros de digitao. e. Os grupos repetitivos, constantes da relao no-normalizada, devem ceder pelo menos um atributo para formar a chave composta da relao em 1FN; f. CHAVES CANDIDATAS ocorrem quando numa relao existem vrios atributos (ou combinaes) com potencial de CHAVE PRIMRIA. Nesse caso, para escolher-se a CHAVE da relao, deve-se considerar os critrios anteriormente definidos. Somente uma CHAVE PRIMRIA ser escolhida, as demais sero chamadas CHAVES ALTERNATIVAS.

86

g. O processo de escolha de CHAVES PRIMRIAS em um BD relacional constitui um fator crtico, que afeta a estabilidade do Banco de dados, pois, os relacionamentos so implementados atravs da redundncia das CHAVES. Portanto, qualquer alterao na chave repercute em todos os relacionamentos nos quais a entidade detentora da mesma esteja envolvida (direta ou indiretamente). Exemplo: Consideremos a relao CONTA-CORRENTE em 1FN (ITEM 5.5):
CONTA-CORRENTE AGENCIA NUMERO-CONTA NOME-CLIENTE ENDEREO-CLIENTE TIPO-AGENCIA DESCRIO-TIPO-AGENCIA ENDEREO-DEPENDENCIA NUM-DOCUMENTO DATA-DOCUMENTO VALOR-LANAMENTO

Qual o atributo ou combinao de atributos que identificam singularmente cada tupla da relao CONTA-CORRENTE? R1: O atributo AGNCIA-CONTA isoladamente deve ser descartado, pois, o cdigo de uma agncia relaciona-se com diversos nmeros de conta; R2: O NUMERO-CONTA isoladamente no adequado, haja vista, que podem existir duas contas com o mesmo nmero em agncias diferentes; R3: A combinao AGNCIA + NUMERO-CONTA ainda no satisfatria, porque podem existir diversos lanamentos (NUM-DOC, DATA, VALOR) para cada conta vinculada a uma agncia; R4: Como LANAMENTOS um grupo repetitivo na forma NONORMALIZADA da relao CONTA-CORRENTE, naturalmente, ele deve ceder um atributo para compor a chave primria. Assim, a CHAVE dessa relao COMPOSTA pela concatenao dos atributos: - AGNCIA + NUMERO-CONTA + NUM-DOC R5: Se considerssemos possvel dois documentos, com o mesmo nmero, em sua mesma conta, deveramos buscar um outro arranjo para a chave-primria.

87

8. SEGUNDA FORMA NORMAL (2FN) Uma relao est em 2FN se: - est em 1FN; - no contm atributos que dependam funcionalmente de subconjuntos da CHAVE PRIMRIA COMPOSTA, em outras palavras, no contm DEPENDNCIA FUNCIONAL PARCIAL (DFP). Para passarmos uma relao da 1FN para a 2FN devemos ELIMINAR as DEPENDNCIAS PARCIAIS. Para tanto, utilizamos o conceito de PROJEO, gerando novas tabelas contendo as colunas que se encontram em DFP com a chave primria. A aplicao da 2FN sobre a relao CONTA-CORRENTE resulta na criao das seguintes tabelas:
CONTA # NUMERO-CONTA NOME-CLIENTE ENDEREO-CLIENTE AGENCIA # NUM-AGENCIA TIPO-AGENCIA DESCRIO-TIPO-AGENCIA ENDEREO-DEPENDENCIA LANAMENTOS # AGENCIA # NUMERO-CONTA # NUM-DOCUMENTO DATA-DOCUMENTO VALOR-LANAMENTO

88

9. TERCEIRA FORMA NORMAL (3FN) Uma relao est em 3FN se: - Est em 1FN; - Est em 2FN; - No possui DEPENDNCIA FUNCIONAL TRANSITIVA (DFT). Para passarmos uma relao da 2FN para a 3FN devemos ELIMINAR as DEPENDNCIAS TRANSITIVAS utilizando a operao de PROJEO. Assim, so geradas novas tabelas correspondentes s DFT identificadas. Ao decompormos a tabela CONTA-CORRENTE, gerando as relaes em 2FN, restou apenas uma DFT, que encontra-se na relao DEPENDNCIA. Fazendo a PROJEO dessa relao para eliminar a DFT obtemos as relaes abaixo:
AGENCIA # NUM-AGENCIA TIPO-AGENCIA ENDEREO-DEPENDENCIA TIPO-AGENCIA # TIPO-AGENCIA DESCRIO-TIPO-AGENCIA CONTA # NUMERO-CONTA NOME-CLIENTE ENDEREO-CLIENTE LANAMENTOS # AGENCIA # NUMERO-CONTA # NUM-DOCUMENTO DATA-DOCUMENTO VALOR-LANAMENTO

89

Observaes: - A chave da relao TIPO-AGNCIA permaneceu na relao principal como CHAVE ESTRANGEIRA, possibilitando o relacionamento entre as duas tabelas. - As relaes CONTA e LANAMENTO j se encontram em 3FN, porque no contm DFT. - Com a aplicao da 3FN, TODAS as DEPENDNCIAS FUNCIONAIS restantes nas relaes so do tipo COMPLETAS.

90

BIBLIOGRAFIA
1. CHU, SHAO YONG BANCO DE DADOS - ATLAS 2. KORTH, HENRY F. SISTEMAS DE BANCO DE DADOS - MAC GRAW 3. DATE , C. J. BANCO DE DAODS - TPICOS AVANADOS - CAMPUS 4. SETZER, VALDEMAR W. BANCO DE DADOS 5. ACCIO FELICIANO NETO ENGENHARIA DA INFORMAO - MAC GRAW 6. GANE, CHRIS ANLISE ESTRUTURADA DE SISTEMAS - LTC 7. GANE, CHRIS DESENVOLVIMENTO RPIDO DE SISTEMAS - LTC 8. YORDON, EDWARD ANLISE ESTRUTURADA MODERNA - CAMPUS 9. CHEN, PETER MODELO ENTIDADE x RELACIONAMENTOS

91

You might also like