Professional Documents
Culture Documents
Introduo ...........................................................................01 1. Arquivo ............................................................................02 2. Registro ...........................................................................02 3. Campo ............................................................................ 03 4. Chave Primria ................................................................04 5. Chave Secundria............................................................05 6. Chave Candidata..............................................................06
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 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.
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
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 .
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
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
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
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 .
12
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
CONTROLE DE NOTAS
EMPRSTIMOS DE LIVROS
PEDAGOGA
BIBLIOTECA
14
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
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
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 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
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
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
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
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
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
MODELO DESCRITIVO
MODELO CONCEITUAL
MER ou DFD
MER Normalizado
MODELO INTERNO
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
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
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
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
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
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
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
FUNCIONRIO
GERENCIA
PEA
COMPE
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
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
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
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
76
1. ANOMALIAS DE ATUALIZAO
So problemas presentes em estruturas de dados modeladas de forma inadequada.
TABELA FUNCIONRIO
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 . . .
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
1FN
2FN
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