Introducao BD PDF

Introduo a Banco de Dados
O.K. Takai; I.C.Italiano; J.E. Ferreira.
INTRODUO A BANCO DE DADOS
Osvaldo Kotaro Takai Isabel Cristina Italiano Joo Eduardo Ferreira DCC-IME-USP Fevereiro - 2005
ndice
1 INTRODUO ................................................................................................................. 6 1.1 MODELOS DE DADOS ...................................................................................................... 6 1.1.1 Modelo Hierrquico.................................................................................................. 6 1.1.2 Modelo em Rede ..................................................................................................... 7 1.1.3 Modelo Relacional ................................................................................................... 8 1.1.4 Modelo Orientado a Objetos.................................................................................... 8 1.1.5 Sistemas Objeto-Relacionais .................................................................................. 9 1.2 ARQUITETURAS DE BANCO DADOS .................................................................................. 9 1.2.1 Introduo................................................................................................................ 9 1.2.2 Arquiteturas ........................................................................................................... 10 1.2.3 Resumo das arquiteturas de SGBDs .................................................................... 11 1.3 AMBIENTE DE IMPLEMENTAO CLIENTE-SERVIDOR ....................................................... 12 2 DEFINIO GERAL....................................................................................................... 14 2.1 PROPRIEDADES:........................................................................................................... 14 2.2 CARACTERSTICAS DA ABORDAGEM DE BASE DE DADOS X PROCESSAMENTO TRADICIONAL DE ARQUIVOS ............................................................................................................................ 15 2.3 CAPACIDADES DO SGBD.............................................................................................. 16 2.4 VANTAGENS ADICIONAIS DA ABORDAGEM DA BASE DE DADOS ........................................ 17 2.5 QUANDO NO UTILIZAR UM SGBD................................................................................. 18 2.6 PROFISSIONAIS E ATIVIDADES ENVOLVIDAS EM UM SGBD .............................................. 18 3 CONCEITOS E ARQUITETURAS DE SGBDS ............................................................. 19 3.1 MODELOS DE DADOS, ESQUEMAS E INSTNCIAS ............................................................ 19 3.1.1 Categorias de Modelos de Dados ......................................................................... 19 3.1.2 Esquemas e Instncias ......................................................................................... 19 3.2 ARQUITETURA E INDEPENDNCIA DE DADOS DE SGBDS ............................................... 20 3.3 LINGUAGENS DE BASE DE DADOS.................................................................................. 21 4 MODELAGEM DE DADOS USANDO O MODELO ENTIDADE-RELACIONAMENTO (MER) 22 4.1 MODELO DE DADOS CONCEITUAL DE ALTO-NVEL E PROJETO DE BASE DADOS ............... 22 4.2 UM EXEMPLO ............................................................................................................... 22 4.3 CONCEITOS DO MODELO ENTIDADE-RELACIONAMENTO.................................................. 23 4.3.1 Entidades e Atributos ............................................................................................ 23 4.3.2 Tipos de Entidades, Conjunto de Valores e Atributos-Chaves ............................. 24 4.3.3 Relacionamentos, Papis e Restries Estruturais .............................................. 25 4.3.4 Tipo de Entidade-Fraca ......................................................................................... 30 4.3.5 Projeto da Base de Dados COMPANHIA utilizando o MER ................................. 31 4.4 DIAGRAMA ENTIDADE-RELACIONAMENTO (DER)............................................................ 31 4.5 TIPOS DE RELACIONAMENTOS DE GRAU MAIOR QUE DOIS .............................................. 33 4.6 QUESTES PARA A SNTESE ......................................................................................... 37 5 O MODELO DE DADOS RELACIONAL ........................................................................ 38 5.1 CONCEITOS DO MODELO RELACIONAL ........................................................................... 38 5.1.1 Notao do Modelo Relacional.............................................................................. 39 5.1.2 Atributos-chaves de uma Relao......................................................................... 40 5.1.3 Esquemas de Bases de Dados Relacionais e Restries de Integridade ............ 41 5.1.4 Operaes de Atualizaes sobre Relaes ........................................................ 44

6 7
MAPEAMENTO DO MER PARA O MODELO DE DADOS RELACIONAL ................... 45 LINGUAGENS FORMAIS DE CONSULTA.................................................................... 49 7.1 LGEBRA RELACIONAL ................................................................................................. 49 7.1.1 Operaes SELECT e PROJECT ......................................................................... 49
7.1.1.1 7.1.1.2 O Operador SELECT................................................................................................. 49 O Operador PROJECT .............................................................................................. 50
7.1.2 Seqncia de Operaes ...................................................................................... 51 7.1.3 Renomeando Atributos.......................................................................................... 52 7.1.4 Operaes da Teoria dos Conjuntos..................................................................... 52 7.1.5 A Operao JOIN .................................................................................................. 55 7.1.6 Conjunto completo de Operaes da lgebra Relacional..................................... 57 7.1.7 A Operao DIVISION........................................................................................... 57 7.1.8 Operaes Relacionais Adicionais ........................................................................ 58 7.1.9 Funes de Agregao ......................................................................................... 58 7.1.10 Operaes de Clausura Recursiva ................................................................... 60 7.2 EXEMPLOS DE CONSULTAS NA LGEBRA RELACIONAL.................................................... 60 7.3 QUESTES DE REVISO................................................................................................ 62 7.4 CLCULO RELACIONAL ................................................................................................. 63 7.4.1 Clculo Relacional de Tuplas ................................................................................ 63 7.4.2 Clculo Relacional de Domnio ............................................................................. 65 8 A LINGUAGEM SQL ...................................................................................................... 67 8.1 ESTRUTURA BSICA ..................................................................................................... 67 8.1.1 A operao RENAME ............................................................................................ 68 8.1.2 Operaes com Strings ......................................................................................... 68 8.1.3 Ordenao e Apresentao de Tuplas.................................................................. 68 8.1.4 Operaes com Conjuntos .................................................................................... 68 8.1.5 Funes Agregadas............................................................................................... 69 8.1.6 Subconsultas Aninhadas ....................................................................................... 69 8.1.7 Vises .................................................................................................................... 70 8.1.8 Insero ................................................................................................................. 70 8.1.9 Atualizao ............................................................................................................ 71 8.1.10 Remoo ........................................................................................................... 71 8.1.11 SQL DDL ........................................................................................................... 71 9 DEPENDNCIAS FUNCIONAIS E NORMALIZAO DE BASE DE DADOS RELACIONAIS ............................................................................................................................ 75 9.1 DIRETRIZES PARA O PROJETO INFORMAL DE ESQUEMAS DE RELAES .......................... 75 9.1.1 Semntica de atributos de relao ........................................................................ 75 Informao redundante em tuplas e anomalias de atualizaes ....................................... 76 9.2 ANOMALIA DE INSERO ............................................................................................... 77 9.2.1 Anomalia de remoo............................................................................................ 77 9.2.2 Anomalia de modificao ...................................................................................... 77 9.2.3 Discusso .............................................................................................................. 78 9.2.4 Valores null em tuplas ........................................................................................... 78 9.2.5 Tuplas esprias ..................................................................................................... 78 9.3 DEPENDNCIAS FUNCIONAIS ......................................................................................... 80 9.3.1 Definio de Dependncia Funcional.................................................................... 80 9.3.2 Formas Normais Determinados pelas Chaves Primrias ..................................... 82
9.2.1.1. 9.2.1.2. 9.2.1.3. Primeira Forma Normal (1FN) ................................................................................... 82 Segunda Forma Normal (2FN) .................................................................................. 82 Terceira Forma Normal (3FN) ................................................................................... 83
10
DATA WAREHOUSE UMA VISO GERAL ................................................................ 89 10.1 O QUE O DATA WAREHOUSE ...................................................................................... 89 10.2 O MODELO DIMENSIONAL E SUAS IMPLEMENTAES ....................................................... 90 10.2.1 O modelo formal da base de dados multidimensional ...................................... 93 10.3 ASPECTOS DA MODELAGEM DIMENSIONAL ..................................................................... 95 10.3.1 Caractersticas .................................................................................................. 95

10.3.2
10.3.2.1 10.3.2.2 10.3.2.3
Conceitos da modelagem.................................................................................. 95
A granularidade das informaes .............................................................................. 96 As dimenses ............................................................................................................ 97 Os fatos ..................................................................................................................... 98
10.3.3 Os trs tipos de mtricas................................................................................... 98 10.3.4 Outros elementos da tabela fato ....................................................................... 99 10.4 OS ESQUEMAS BSICOS E SUAS VARIAES ................................................................ 101 10.4.1 O esquema Star clssico ................................................................................ 101
10.4.1.1 10.4.1.2 10.4.1.3 As variaes do esquema Star................................................................................ 105 O esquema Snowflake ............................................................................................ 109 As variaes do esquema Snowflake...................................................................... 109
10.5 AGREGAES DAS INFORMAES ............................................................................... 115 10.5.1 Definindo os agregados .................................................................................. 115 10.5.2 Implementando os agregados......................................................................... 117 10.6 UTILIZANDO OS AGREGADOS COM UM NOVO COMPONENTE: O NAVEGADOR DE AGREGADOS 119 10.6.1 O processo de carga ....................................................................................... 119
Prefcio
Esta apostila foi escrita para apoiar a aprendizagem dos alunos nas disciplinas de introduo a Sistemas Banco de Dados do IME-USP. Seu contedo uma pesquisa de vrios autores, sendo em partes transcries e tradues dos mesmos. Os captulos de 1 a 9 foram baseados nas referncias [1], [2], [3], [4], [5], [6] e [7]. O Captulo 10 foi baseado nas demais referncias que constam no final deste documento. O Apndice A foi baseado em [5]. Esta apostila tem como objetivo ser uma primeira leitura para os alunos iniciantes no curso de banco de dados e tenta sempre mostrar os temas abordados de forma simples e clara, propiciando subsdios para aprofundar-se nos temas tratados utilizando outras bibliografias. No intuito de ser didtica, esta apostila est estruturada da seguinte forma: O Captulo 1 apresenta uma introduo aos modelos e arquiteturas de banco de dados. O Captulo 2 traz os conceitos bsicos de sistemas de banco de dados, necessrios compreenso do restante deste material. No Captulo 3, as arquiteturas de banco de dados so apresentadas. O Captulo 4 trata de modelagem de banco de dados usando o paradigma entidade relacionamento. O Captulo 5 aborda o modelo relacional. O Captulo 6 ilustra como efetuar o mapeamento de um diagrama entidade relacionamento para o modelo relacional, de forma intuitiva. O Captulo 7 traz uma discusso e exemplos de linguagens de consultas formais, quais sejam: lgebra relacional, Clculo relacional de Tuplas e Clculo Relacional de Domnio. No Captulo 8, a linguagem SQL linguagem de consulta comercial mais difundida para o modelo relacional introduzida, por meio de sua teoria e exemplos prticos. O Captulo 9 trata de projeto de banco de dados, normalizao e dependncias funcionais entre os dados. No Captulo 10 uma viso geral sobre Data warehouse fornecida ao leitor. Finalmente, o Apndice A traz exemplos de consultas nas linguagens de consultas vistas anteriormente. Os autores agradecem imensamente aos alunos: Bianka M.M.T. Gonalves, Clodis Boscarioli, Rodolpho Iemini Atoji e Fernando Henrique Ferraz P. da Rosa, pelas valorosas correes, edies e sugestes do texto em questo.
Base de Dados
1 Introduo
O primeiro Sistema Gerenciador de Banco de Dados (SGBD) comercial surgiu no final de 1960 com base nos primitivos sistemas de arquivos disponveis na poca, os quais no controlavam o acesso concorrente por vrios usurios ou processos. Os SGBDs evoluram desses sistemas de arquivos de armazenamento em disco, criando novas estruturas de dados com o objetivo de armazenar informaes. Com o tempo, os SGBDs passaram a utilizar diferentes formas de representao, ou modelos de dados, para descrever a estrutura das informaes contidas em seus bancos de dados. Atualmente, os seguintes modelos de dados so normalmente utilizados pelos SGBDs: modelo hierrquico, modelo em redes, modelo relacional (amplamente usado) e o modelo orientado a objetos.
1.1
Modelos de Dados
1.1.1 Modelo Hierrquico

O modelo hierrquico foi o primeiro a ser reconhecido como um modelo de dados. Seu desenvolvimento somente foi possvel devido consolidao dos discos de armazenamento endereveis, pois esses discos possibilitaram a explorao de sua estrutura de endereamento fsico para viabilizar a representao hierrquica das informaes. Nesse modelo de dados, os dados so estruturados em hierarquias ou rvores. Os ns das hierarquias contm ocorrncias de registros, onde cada registro uma coleo de campos (atributos), cada um contendo apenas uma informao. O registro da hierarquia que precede a outros o registro-pai, os outros so chamados de registros-filhos. Uma ligao uma associao entre dois registros. O relacionamento entre um registro-pai e vrios registros-filhos possui cardinalidade 1:N. Os dados organizados segundo este modelo podem ser acessados segundo uma seqncia hierrquica com uma navegao do topo para as folhas e da esquerda para a direita. Um registro pode estar associado a vrios registros diferentes, desde que seja replicado. A replicao possui duas grandes desvantagens: pode causar inconsistncia de dados quando houver atualizao e o desperdcio de espao inevitvel. O sistema comercial mais divulgado no modelo hierrquico foi o Information Management System da IBM Corp(IMS). Grande parte das restries e consistncias de dados estava contida dentro dos programas escritos para as aplicaes. Era necessrio escrever programas na ordem para acessar o banco de dados. Um diagrama de estrutura de rvore descreve o esquema de um banco de dados hierrquico. Tal diagrama consiste em dois componentes bsicos: Caixas, as quais correspondem aos tipos de registros e Linhas, que correspondem s ligaes entre os tipos de registros. Como exemplo do modelo hierrquico, considere a Figura 1.1 abaixo.
Figura 1.1 - Diagrama de estrutura de rvore Cliente - Conta Corrente 1.1.2 Modelo em Rede
O modelo em redes surgiu como uma extenso ao modelo hierrquico, eliminando o conceito de hierarquia e permitindo que um mesmo registro estivesse envolvido em vrias associaes. No modelo em rede, os registros so organizados em grafos onde aparece um nico tipo de associao (set) que define uma relao 1:N entre 2 tipos de registros: proprietrio e membro. Desta maneira, dados dois relacionamentos 1:N entre os registros A e D e entre os registros C e D possvel construir um relacionamento M:N entre A e D. O gerenciador Data Base Task Group (DBTG) da CODASYL (Committee on Data Systems and Languages) estabeleceu uma norma para este modelo de banco de dados, com linguagem prpria para definio e manipulao de dados. Os dados tinham uma forma limitada de independncia fsica. A nica garantia era que o sistema deveria recuperar os dados para as aplicaes como se eles estivessem armazenados na maneira indicada nos esquemas. Os geradores de relatrios da CODASYL tambm definiram sintaxes para dois aspectos chaves dos sistemas gerenciadores de dados: concorrncia e segurana. O mecanismo de segurana fornecia uma facilidade na qual parte do banco de dados (ou rea) pudesse ser bloqueada para prevenir acessos simultneos, quando necessrio. A sintaxe da segurana permitia que uma senha fosse associada a cada objeto descrito no esquema. Ao contrrio do Modelo Hierrquico, em que qualquer acesso aos dados passa pela raiz, o modelo em rede possibilita acesso a qualquer n da rede sem passar pela raiz. No Modelo em Rede o sistema comercial mais divulgado o CAIDMS da Computer Associates. O diagrama para representar os conceitos do modelo em redes consiste em dois componentes bsicos: Caixas, que correspondem aos registros e Linhas, que correspondem s associaes. A Figura 1.2 ilustra um exemplo de diagrama do modelo em rede.
Figura 1.2 - Diagrama de estrutura de dados Cliente - Conta Corrente
Estes dois modelos: Hierrquico e Rede so Orientados a Registros, isto , qualquer acesso base de dados insero, consulta, alterao ou remoo feito em um registro de cada vez.
1.1.3 Modelo Relacional

O modelo relacional apareceu devido s seguintes necessidades: aumentar a independncia de dados nos sistemas gerenciadores de banco de dados; prover um conjunto de funes apoiadas em lgebra relacional para armazenamento e recuperao de dados; permitir processamento ad hoc1. O modelo relacional, tendo por base a teoria dos conjuntos e lgebra relacional, foi resultado de um estudo terico realizado por CODD[1]2. O Modelo relacional revelou-se ser o mais flexvel e adequado ao solucionar os vrios problemas que se colocam no nvel da concepo e implementao da base de dados. A estrutura fundamental do modelo relacional a relao (tabela). Uma relao constituda por um ou mais atributos (campos) que traduzem o tipo de dados a armazenar. Cada instncia do esquema (linha) chamada de tupla (registro). O modelo relacional no tem caminhos pr-definidos para se fazer acesso aos dados como nos modelos que o precederam. O modelo relacional implementa estruturas de dados organizadas em relaes. Porm, para trabalhar com essas tabelas, algumas restries precisaram ser impostas para evitar aspectos indesejveis, como: Repetio de informao, incapacidade de representar parte da informao e perda de informao. Essas restries so: integridade referencial, chaves e integridade de junes de relaes. A Figura 1.3, abaixo, traz exemplos de tabelas sob o modelo relacional.
Figura 1.3 Tabelas do modelo relacional Cliente - Conta Corrente 1.1.4 Modelo Orientado a Objetos
Os bancos de dados orientados a objeto comearam a se tornar comercialmente viveis em meados de 1980. A motivao para seu surgimento est em funo dos limites de armazenamento e representao semntica impostas no modelo relacional. Alguns exemplos so os sistemas de informaes geogrficas (SIG), os sistemas CAD e CAM, que so mais facilmente construdos usando tipos complexos de dados. A habilidade para criar os tipos de dados necessrios uma caracterstica das linguagens de programao orientadas a objetos. Contudo, estes sistemas necessitam guardar representaes das estruturas de dados que utilizam no armazenamento permanente. A estrutura padro para os bancos de dados orientados a objetos foi feita pelo Object Database Management Group (ODMG). Esse grupo Processamento dedicado, exclusivo. Codd era investigador da IBM. O modelo foi apresentado num artigo publicado em 1970, mas s nos anos 80 o modelo foi implementado.
2 1
formado por representantes dos principais fabricantes de banco de dados orientados a objeto disponveis comercialmente. Membros do grupo tm o compromisso de incorporar o padro em seus produtos. O termo Modelo Orientado a Objetos usado para documentar o padro que contm a descrio geral das facilidades de um conjunto de linguagens de programao orientadas a objetos e a biblioteca de classes que pode formar a base para o Sistema de Banco de Dados. Quando os bancos de dados orientados a objetos foram introduzidos, algumas das falhas perceptveis do modelo relacional pareceram ter sido solucionadas com esta tecnologia e acreditava-se que tais bancos de dados ganhariam grande parcela do mercado. Hoje, porm, acredita-se que os Bancos de Dados Orientados a Objetos sero usados em aplicaes especializadas, enquanto os sistemas relacionais continuaro a sustentar os negcios tradicionais, onde as estruturas de dados baseadas em relaes so suficientes. O diagrama de classes UML serve geralmente como o esquema para o modelo de dados orientado a objetos. Observe o exemplo da Figura 1.4, e compare as diferenas com o modelo anterior.
Figura 1.4 - Diagrama UML Cliente - Conta Corrente 1.1.5 Sistemas Objeto-Relacionais
A rea de atuao dos sistemas Objeto-Relacional tenta suprir a dificuldade dos sistemas relacionais convencionais, que o de representar e manipular dados complexos, visando ser mais representativos em semntica e construes de modelagens. A soluo proposta a adio de facilidades para manusear tais dados utilizando-se das facilidades SQL (Structured Query Language) existentes. Para isso, foi necessrio adicionar: extenses dos tipos bsicos no contexto SQL; representaes para objetos complexos no contexto SQL; herana no contexto SQL e sistema para produo de regras.
1.2
Arquiteturas de Banco Dados
1.2.1 Introduo
Atualmente, devem-se considerar alguns aspectos relevantes para atingir a eficincia e a eficcia dos sistemas informatizados desenvolvidos, a fim de atender seus usurios nos mais variados domnios de aplicao: automao de escritrios, sistemas de apoio a decises, controle de reserva de recursos, controle e planejamento de produo, alocao e estoque de recursos, entre outros. Tais aspectos so: a) Os projetos Lgico e Funcional do Banco de Dados devem ser capazes de prever o volume de informaes armazenadas a curto, mdio e longo prazo. Os projetos devem ter uma grande capacidade de adaptao para os trs casos mencionados; b) Deve-se ter generalidade e alto grau de abstrao de dados, possibilitando confiabilidade e eficincia no armazenamento dos dados e permitindo a utilizao de diferentes tipos de gerenciadores de dados atravs de linguagens de consultas padronizadas; c) Projeto de uma interface gil e com uma "rampa ascendente" para propiciar aprendizado suave ao usurio, no intuito de minimizar o esforo cognitvo;
10
d) Implementao de um projeto de interface compatvel com mltiplas plataformas (UNIX, Windows NT, Windows Workgroup, etc); e) Independncia de Implementao da Interface em relao aos SGBDs que daro condies s operaes de armazenamento de informaes (ORACLE, SYSBASE, INFORMIX, PADRO XBASE, etc). f) Converso e mapeamento da diferena semntica entre os paradigmas utilizados no desenvolvimento de interfaces (Imperativo (ou procedural), Orientado a Objeto, Orientado a evento), servidores de dados (Relacional) e programao dos aplicativos (Imperativo, Orientado a Objetos).
1.2.2 Arquiteturas
As primeiras arquiteturas usavam mainframes para executar o processamento principal e de todas as funes do sistema, incluindo os programas aplicativos, programas de interface com o usurio, bem como a funcionalidade dos SGBDs. Esta a razo pela qual a maioria dos usurios fazia acesso aos sistemas via terminais que no possuam poder de processamento, apenas a capacidade de visualizao. Todos os processamentos eram feitos remotamente, apenas as informaes a serem visualizadas e os controles eram enviados do mainframe para os terminais de visualizao, conectados a ele por redes de comunicao. Como os preos do hardware foram decrescendo, muitos usurios trocaram seus terminais por computadores pessoais (PC) e estaes de trabalho. No comeo os SGBDs usavam esses computadores da mesma maneira que usavam os terminais, ou seja, o SGBD era centralizado e toda sua funcionalidade, execuo de programas aplicativos e processamento da interface do usurio eram executados em apenas uma mquina. Gradualmente, os SGBDs comearam a explorar a disponibilidade do poder de processamento no lado do usurio, o que levou arquitetura cliente-servidor. A arquitetura cliente-servidor foi desenvolvida para dividir ambientes de computao onde um grande nmero de PCs, estaes de trabalho, servidores de arquivos, impressoras, servidores de banco de dados e outros equipamentos so conectados juntos por uma rede. A idia definir servidores especializados, tais como servidor de arquivos, que mantm os arquivos de mquinas clientes, ou servidores de impresso que podem estar conectados a vrias impressoras; assim, quando se desejar imprimir algo, todas as requisies de impresso so enviadas a este servidor. As mquinas clientes disponibilizam para o usurio as interfaces apropriadas para utilizar esses servidores, bem como poder de processamento para executar aplicaes locais. Esta arquitetura se tornou muito popular por algumas razes. Primeiro, a facilidade de implementao dada a clara separao das funcionalidades e dos servidores. Segundo, um servidor inteligentemente utilizado porque as tarefas mais simples so delegadas s mquinas clientes mais baratas. Terceiro, o usurio pode executar uma interface grfica que lhe familiar, ao invs de usar a interface do servidor. Desta maneira, a arquitetura cliente-servidor foi incorporada aos SGBDs comerciais. Diferentes tcnicas foram propostas para se implementar essa arquitetura, sendo que a mais adotada pelos Sistemas Gerenciadores de Banco de Dados Relacionais (SGBDRs) comerciais a incluso da funcionalidade de um SGBD centralizado no lado do servidor. As consultas e a funcionalidade transacional permanecem no servidor, sendo que este chamado de servidor de consulta ou servidor de transao. assim que um servidor SQL fornecido aos clientes. Cada cliente tem que formular suas consultas SQL, prover a interface do usurio e as funes de interface usando uma linguagem de programao. O cliente pode tambm se referir a um dicionrio de dados o qual inclui informaes sobre a distribuio dos dados em vrios servidores SQL, bem como os mdulos para a decomposio de uma consulta global em um nmero de consultas locais que podem ser executadas em vrios stios. Comumente o servidor SQL tambm chamado de back-end machine e o cliente de front-end machine. Como SQL prov uma linguagem padro para o SGBDRs, esta criou o ponto de diviso lgica entre o cliente e o servidor. Atualmente, existem vrias tendncias para arquitetura de Banco de Dados, nas mais diversas direes.
Introduo a Banco de Dados 1.2.3 Resumo das arquiteturas de SGBDs
11
Plataformas centralizadas. Na arquitetura centralizada, existe um computador com grande capacidade de processamento, o qual o hospedeiro do SGBD e emuladores para os vrios aplicativos. Esta arquitetura tem como principal vantagem a de permitir que muitos usurios manipulem grande volume de dados. Sua principal desvantagem est no seu alto custo, pois exige ambiente especial para mainframes e solues centralizadas. Sistemas de Computador Pessoal - PC. Os computadores pessoais trabalham em sistema stand-alone, ou seja, fazem seus processamentos sozinhos. No comeo esse processamento era bastante limitado, porm, com a evoluo do hardware, tem-se hoje PCs com grande capacidade de processamento. Eles utilizam o padro Xbase e quando se trata de SGBDs, funcionam como hospedeiros e terminais. Desta maneira, possuem um nico aplicativo a ser executado na mquina. A principal vantagem desta arquitetura a simplicidade. Banco de Dados Cliente-Servidor. Na arquitetura Cliente-Servidor, o cliente (front_end) executa as tarefas do aplicativo, ou seja, fornece a interface do usurio (tela, e processamento de entrada e sada). O servidor (back_end) executa as consultas no DBMS e retorna os resultados ao cliente. Apesar de ser uma arquitetura bastante popular, so necessrias solues sofisticadas de software que possibilitem: o tratamento de transaes, as confirmaes de transaes (commits), desfazer transaes (rollbacks), linguagens de consultas (stored procedures) e gatilhos (triggers). A principal vantagem desta arquitetura a diviso do processamento entre dois sistemas, o que reduz o trfego de dados na rede. Banco de Dados Distribudos (N camadas). Nesta arquitetura, a informao est distribuda em diversos servidores. Como exemplo, observe a Figura 1.5. Cada servidor atua como no sistema cliente-servidor, porm as consultas oriundas dos aplicativos so feitas para qualquer servidor indistintamente. Caso a informao solicitada seja mantida por outro servidor ou servidores, o sistema encarrega-se de obter a informao necessria, de maneira transparente para o aplicativo, que passa a atuar consultando a rede, independente de conhecer seus servidores. Exemplos tpicos so as bases de dados corporativas, em que o volume de informao muito grande e, por isso, deve ser distribudo em diversos servidores. Porm, no dependente de aspectos lgicos de carga de acesso aos dados, ou base de dados fracamente acopladas, em que uma informao solicitada vai sendo coletada numa propagao da consulta numa cadeia de servidores. A caracterstica bsica a existncia de diversos programas aplicativos consultando a rede para acessar os dados necessrios, porm, sem o conhecimento explcito de quais servidores dispem desses dados.
12
Figura 1.5 - Arquitetura Distribuda N camadas
1.3
Ambiente de Implementao Cliente-Servidor
13
Figura 1.6 - Ambiente genrico para desenvolvimento de aplicativos

A Figura 1.6 ilustra um ambiente genrico de desenvolvimento de aplicativos. Nesta Figura, a diferena (gap semntico) entre os paradigmas utilizados para: a construo de interfaces, o armazenamento de informaes, e a programao dos aplicativos so detalhadas para ressaltar a importncia de estruturas "Case" e "Cursores". As estruturas "Case" so utilizadas para converter as alteraes e solicitaes ocorridas na interface do aplicativo em uma linguagem que seja capaz de ser processada pelos servidores de dados. A construo da linguagem feita atravs da composio de cadeias de caracteres usualmente utilizando o padro SQL utilizado nos servidores de dados relacionais. Quando um acesso ao SGBD requerido, o programa estabelece uma conexo com o SGBD que est instalado no servidor. Uma vez que a conexo criada, o programa cliente pode se comunicar com o SGBD. Um padro chamado de Conectividade Base de Dados Aberta (Open DataBase Connectivity ODBC) prov uma Interface para Programao de Aplicaes (API) que permite que os programas no lado cliente possam chamar o SGBD, desde que as mquinas clientes como o servidor tenham o necessrio software instalado. Muitos vendedores de SGBDs disponibilizam drivers especficos para seus sistemas. Desta maneira, um programa cliente pode se conectar a diversos SGBDRs e enviar requisies de consultas e transaes usando API, que so processados nos servidores. Aps o processamento de uma chamada de funo (levando uma cadeia de caracteres ou programas armazenados), o resultado fornecido pelo servidor de dados atravs de tabelas em memria. Os resultados das consultas so enviados para o programa cliente, que pode process-lo ou visualiz-lo conforme a necessidade. O conjunto resposta para uma consulta pode ser uma tabela com zero, uma ou mltiplas tuplas, dependendo de quantas linhas foram encontradas com o critrio de busca. Quando uma consulta retorna mltiplas linhas, necessrio declarar um "CURSOR" para process-las. Um cursor similar a uma varivel de arquivo ou um ponteiro de arquivo, que aponta para uma nica linha (tupla) do resultado da consulta. Em SQL os cursores so controlados por trs comandos: OPEN, FETCH, CLOSE. O cursor iniciado com o comando OPEN, que executa a consulta, devolve o conjunto resultante de linhas e coloca o cursor para a posio anterior primeira linha do resultado da consulta. O comando FETCH, quando executado pela primeira vez, devolve a primeira linha nas variveis do programa e coloca o cursor para apontar para aquela linha. Subseqentes execues do comando FETCH avanam o cursor para a prxima linha no conjunto resultante e retornam a linha nas variveis do programa. Quando a ltima linha processada, o cursor desbloqueado com o comando CLOSE. Os cursores existem principalmente para que linguagens de programao que no permitem abstrao para conjunto de registros, como C, possam receber as linhas da resposta de uma consulta SQL uma de cada vez. Com a utilizao de "CURSORES", apresentam-se esses dados como resultados das consulta, atravs de itens que representam os elementos de interface com o usurio, atendendo os preceitos impostos pelos diferentes paradigmas possivelmente envolvidos. Com isso os resultados so mostrados utilizando o objeto padro da interface, disponveis nas ferramentas de construo de interfaces. Dessa forma, o ciclo de busca de informao nos mais variados servidores tem incio e fim na interface com o usurio. de fundamental importncia que se construam aplicativos cujos projetos de interface sejam "ortogonais" aos projetos de implementao de acesso aos servidores de dados. Na implementao de sistemas de informao, deve-se utilizar uma arquitetura de base de dados relacional que seja independente de um determinado repositrio de dados (gerenciadores Access, Oracle, Sybase, Informix, etc). A Figura 1.7 ilustra a utilizao de conversores genricos tanto para interfaces como para os servidores de dados. Estes conversores so construdos para padronizar o controle de compartilhamento de dados, independente da ferramenta de interface ou do servidor de dados. Em situaes prticas esses conversores so denominados comumente de drivers.
14
Figura 1.7 - Conversor genrico para interface e servidores de dados
2 Definio Geral
Base de Dados: Coleo de dados relacionados; Dados: Valor de um campo armazenado, matria-prima para obteno de informao; Informao: Dados compilados e processados de acordo com solicitao de consultas e anlises
2.1
Propriedades:
Uma base de dados uma coleo de dados logicamente relacionados, com algum significado. Associaes aleatrias de dados no podem ser chamadas de base de dados; Uma base de dados projetada, construda e preenchida (instanciada) com dados para um propsito especfico. Ela tem um grupo de usurios e algumas aplicaes pr-concebidas para atend-los; Uma base de dados representa algum aspecto do mundo real, algumas vezes chamado de mini-mundo. Mudanas no mini-mundo provocam mudanas na base de dados.
15
Uma base de dados tem alguma fonte de dados, algum grau de interao com eventos do mundo real e uma audincia que est ativamente interessada no seu contedo. Um Sistema Gerenciador de Base de Dados (SGBD) uma coleo de programas que permitem aos usurios criarem e manipularem uma base de dados. Um SGBD , assim, um sistema de software de propsito geral que facilita o processo de definir, construir e manipular bases de dados de diversas aplicaes.
Definir uma base de dados envolve a especificao de tipos de dados a serem armazenados na base de dados. Construir uma base de dados o processo de armazenar os dados em algum meio que seja controlado pelo SGBD. Manipular uma base de dados indica a utilizao de funes como a de consulta, para recuperar dados especficos, modificao da base de dados para refletir mudanas no mini-mundo (inseres, atualizaes e remoes), e gerao de relatrios.
A base de dados e o software de gerenciamento da base de dados compem o chamado Sistema de Base de Dados. A Figura 2.1 apresenta um esquema genrico de um Sistema de Banco de Dados em sua interao com seus usurios.
Usurios/Programadores Sistema de Base de Dados Consultas/Programas de Aplicaes
SGBD Software p/ processar consultas/programas
Software p/ acessar a Base de Dados Meta Base
Base
Figura 2.1 Sistema de Banco de Dados
2.2
Caractersticas da Abordagem de Base de Dados x Processamento Tradicional de Arquivos
A tabela abaixo traz as principais caractersticas que diferem um sistema desenvolvido na perspectiva de banco de dados versus um desenvolvimento pelo tradicional gerenciamento de arquivos.

Processamento tradicional de Arquivos Definio dos dados parte do cdigo de programas de aplicao Dependncia entre aplicao especfica e dados Base de Dados Meta Dados
16
Vantagens da base de Dados eliminao de redundncias
Representao de dados ao nvel fsico Cada viso implementada por mdulos especficos
Capaz de permitir diversas aplicaes independncia entre dados e programas Representao conceitual atravs de dados e programas Permite mltiplas vises
eliminao de redundncias facilidade de manuteno facilidade de manuteno
facilidade de consultas
2.3
Capacidades do SGBD
Controle de Redundncia: no processamento tradicional de arquivos, muitos grupos de usurios mantm seus prprios arquivos para manipular suas aplicaes de processamento, que pode provocar o armazenamento de informaes redundantes; Problemas: Duplicao de esforos; Desperdcio de espao; Inconsistncia: alterao em alguns arquivos e em outros no, ou em todos os arquivos, porm, de maneira independente; Compartilhamento de Dados: SGBDs multiusurios devem fornecer controle de concorrncia para assegurar que atualizaes simultneas resultem em modificaes corretas. Um outro mecanismo que permite a noo de compartilhamento de dados em um SGBD multiusurio a facilidade de definir vises de usurio, que usada para especificar a poro da base de dados que de interesse para um grupo particular de usurios; Restries de Acesso Multiusurio: quando mltiplos usurios compartilham uma base de dados, comum que alguns usurios no autorizados no tenham acesso a todas as informaes da base de dados. Por exemplo, os dados financeiros so freqentemente considerados confidenciais e, desse modo, somente pessoas autorizadas devem ter acesso. Alm disso, pode ser permitido a alguns usurios, apenas a recuperao dos dados. J, para outros, so permitidas a recuperao e a modificao. Assim, o tipo de operao de acesso - recuperao ou modificao - pode tambm ser controlado. Tipicamente, usurios e grupos de usurios recebem uma conta protegida por palavraschaves, que usada para se obter acesso base de dados, o que significa dizer que contas diferentes possuem restries de acesso diferentes. Um SGBD deve fornecer um subsistema de autorizao e segurana, que usado pelo DBA para criar contas e especificar restries nas contas. O SGBD deve ento obrigar estas restries automaticamente. Note que um controle similar pode ser aplicado ao software do SGBD; Fornecimento de Mltiplas Interfaces: devido aos vrios tipos de usurios, com variados nveis de conhecimento tcnico, um SGBD deve fornecer uma variedade de interfaces atend-los. Os tipos de interfaces incluem linguagens de consulta para usurios ocasionais, interfaces de linguagem de programao para programadores de aplicaes, formulrios e interfaces dirigidas por menus para usurios comuns; Representao de Relacionamento Complexo entre Dados: uma base de dados pode possuir uma variedade de dados que esto inter-relacionados de muitas maneiras. Um SGBD deve ter a capacidade de representar uma variedade de relacionamentos complexos entre dados, bem como recuperar e modificar dados relacionados de maneira fcil e eficiente; Reforar Restries de Integridade: muitas aplicaes de base de dados tero certas restries de integridade de dados. A forma mais elementar de restrio de integridade a
17
especificao do tipo de dado de cada item. Existem tipos de restries mais complexas. Um tipo de restrio que ocorre freqentemente a especificao de que um registro de um arquivo deve estar relacionado a registros de outros arquivos. Um outro tipo de restrio especifica a unicidade sobre itens de dados. Estas restries so derivadas da semntica dos dados e do mini-mundo que eles representam. Algumas restries podem ser especificadas ao SGBD e automaticamente executadas. Outras restries podem ser verificadas pelos programas de atualizao ou no tempo da entrada de dados. Note que um item de dados pode ser inserido erroneamente, mas ainda atender as restries de integridade; Fornecer Backup e Restaurao: Um SGBD deve fornecer recursos para restaurao caso ocorram falhas de hardware ou software. O subsistema de backup e restaurao do SGBD o responsvel pela restaurao. Por exemplo, se o sistema de computador falhar no meio da execuo de um programa que esteja realizando uma alterao complexa na base de dados, o subsistema de restaurao responsvel por assegurar que a base de dados seja restaurada ao estado anterior ao incio da execuo do programa. Alternativamente, o subsistema de restaurao poderia assegurar que o programa seja reexecutado a partir do ponto em que havia sido interrompido.
2.4
Vantagens Adicionais da Abordagem da Base de Dados
Potencial para obrigar a Padronizao: a abordagem de base de dados permite que o DBA defina e obrigue a padronizao entre os usurios da base de dados em grandes organizaes. Isso facilita a comunicao e a cooperao entre vrios departamentos, projetos e usurios. Padres podem ser definidos para formatos de nomes, elementos de dados, telas, relatrios, terminologias, etc. O DBA pode obrigar a padronizao em um ambiente de base de dados centralizado, muito mais facilmente que em um ambiente onde cada usurio ou grupo tem o controle de seus prprios arquivos e programas de aplicao; Flexibilidade: mudanas na estrutura de uma base de dados podem ser necessrias devido a mudanas nos requisitos. Por exemplo, um novo grupo de usurios pode surgir com necessidade de informaes adicionais, ainda no disponveis na base de dados. Alguns SGBDs permitem que tais mudanas na estrutura da base de dados sejam realizadas sem afetar a maioria dos programas de aplicaes existentes; Reduo do Tempo de Desenvolvimento de Aplicaes: uma das principais caractersticas de venda da abordagem de base de dados o tempo reduzido para o desenvolvimento de novas aplicaes, como a recuperao de certos dados da base de dados para a impresso de novos relatrios. Projetar e implementar uma nova base de dados pode tomar mais tempo do que escrever uma simples aplicao de arquivos especializada. Porm, uma vez que a base de dados esteja em uso, geralmente o tempo para se criar novas aplicaes, usando-se os recursos de um SGBD, bastante reduzido. O tempo para se desenvolver uma nova aplicao em um SGBD estimado em 1/4 a 1/6 do que o tempo de desenvolvimento, usando-se apenas o sistema de arquivos tradicional, devido s facilidades de interfaces disponveis em um SGBD; Disponibilidade de Informaes Atualizadas: to logo um usurio modifique uma base de dados, todos os outros usurios sentem imediatamente esta modificao. Esta disponibilidade de informaes atualizadas essencial para muitas aplicaes, tais como sistemas de reservas de passagens areas ou bases de dados bancrias. Isso somente possvel devido ao subsistema de controle de concorrncia e restaurao do SGBD; Economia de Escala: a abordagem de SGBDs permite a consolidao de dados e de aplicaes reduzindo-se, desse modo, o desperdcio em atividades redundantes de processamento em diferentes projetos ou departamentos. Isto possibilita organizao como um todo investir em processadores mais poderosos, e perifricos de armazenamento e de comunicao mais eficientes.
18
2.5

Quando no utilizar um SGBD
bases de dados e aplicaes simples, bem definidas sem expectativa de mudana; existem restries de tempo que no podem ser satisfeitas em SGBDs; no h necessidade de acesso multiusurio.
2.6
Profissionais e Atividades envolvidas em um SGBD
Administrador da Base de Dados: em qualquer organizao onde muitas pessoas compartilham muitos recursos, existe a necessidade de um administrador chefe para supervisionar e gerenciar estes recursos. Num ambiente de base de dados, o recurso primrio a prpria base de dados e os recursos secundrios so o prprio SGBD e softwares relacionados. A administrao desses recursos de responsabilidade do DBA (Database Administrator). O DBA responsvel por autorizar acesso base de dados e coordenar e monitorar seu uso. O DBA responsvel por problemas, tais como, quebra de segurana ou baixo desempenho. Em grandes organizaes, o DBA auxiliado por tcnicos; Projetistas da Base de Dados: os projetistas de base de dados tm a responsabilidade de identificar os dados a serem armazenados na Base de Dados e escolher estruturas apropriadas para representar e armazenar tais dados. Estas tarefas so geralmente executadas antes que a base de dados seja utilizada. responsabilidade destes projetistas obter os requisitos necessrios dos futuros usurios da base. Tipicamente, os projetistas interagem com cada grupo de usurios em potencial e definem vises da base de dados para adequar os requisitos e processamentos de cada grupo. Estas vises so ento analisadas e, posteriormente, integradas para que, ao final, o projeto da base de dados possa ser capaz de dar subsdio aos requisitos de todos os grupos de usurios; Analistas de Sistemas e Programadores de Aplicao: analistas de sistemas determinam os requisitos de usurios finais, especialmente dos usurios comuns, e desenvolvem especificaes das transaes para atender a estes requisitos; programadores de aplicaes implementam estas especificaes produzindo programas e, ento, testam, depuram, documentam e mantm estes programas. Analistas e programadores devem estar familiarizados com todas as capacidades fornecidas pelo SGBD para desempenhar estas tarefas. Usurios Finais: existem profissionais que precisam ter acesso base de dados para consultar, modificar e gerar relatrios. A base de dados existe para estes usurios. Existem algumas categorias de usurios finais: usurios ocasionais: ocasionalmente fazem acesso base de dados, mas eles podem necessitar de diferentes informaes a cada vez que fazem acesso. Eles podem usar uma linguagem de consulta sofisticada para especificar suas requisies e so, tipicamente, gerentes de mdio ou alto-nvel; usurios comuns ou paramtricos: estes usurios realizam operaes padres de consultas e atualizaes, chamadas TRANSAES PERMITIDAS, que foram cuidadosamente programadas e testadas. Estes usurios constantemente realizam recuperaes e modificaes na base de dados; usurios sofisticados: incluem engenheiros, analistas de negcios e outros que procuraram familiarizar-se com as facilidades de um SGBD para atender aos seus complexos requisitos; Profissionais de Apoio: Projetistas e Implementadores de SGBD Desenvolvedores de Ferramentas Operadores de Manuteno
19
3 Conceitos e Arquiteturas de SGBDs

3.1 Modelos de Dados, Esquemas e Instncias
Uma das caractersticas fundamentais da abordagem de base de dados que ela fornece algum nvel de abstrao de dados, pela omisso de detalhes de armazenamento de dados que no so necessrios para a maioria dos usurios. O modelo de dados a principal ferramenta que fornece esta abstrao. Um Modelo de Dados um conjunto de conceitos que podem ser usados para descrever a estrutura de uma base de dados. Por estrutura de uma base de dados entende-se os tipos de dados, relacionamentos e restries pertinentes aos dados. Muitos modelos de dados tambm definem um conjunto de operaes para especificar como recuperar e modificar a base de dados.
3.1.1 Categorias de Modelos de Dados

Muitos modelos de dados tm sido propostos. Pode-se classificar os modelos de dados baseando-se nos tipos de conceitos que fornecem para descrever a estrutura da base de dados. Modelos de Dados Conceituais ou de Alto-Nvel fornecem conceitos prximos percepo dos usurios. J os Modelos de Dados Fsicos ou de Baixo-Nvel fornecem conceitos que descrevem os detalhes de como os dados so armazenados no computador. Modelos de alto-nvel utilizam conceitos tais como Entidades, Atributos e Relacionamentos. Uma entidade um objeto que representado na base de dados. Um atributo uma propriedade que descreve algum aspecto de um objeto. Relacionamentos entre objetos so facilmente representados em modelos de dados de alto-nvel, que so algumas vezes chamados de Modelos Baseados em Objeto devido, principalmente, a sua caracterstica de descreverem objetos e seus relacionamentos. Modelos de Dados de Baixo-Nvel descrevem como os dados so armazenados no computador, representando informaes em formato de registros, ordem dos registros e caminho de acesso. Um Caminho de Acesso uma estrutura de que facilita a busca de um registro particular na base de dados.
3.1.2 Esquemas e Instncias

Em qualquer modelo de dados importante distinguir entre a descrio da base de dados e a base de dados propriamente dita. A descrio de uma base de dados chamada Esquema da Base de Dados. Um esquema de base de dados especificado durante o projeto da base de dados, sendo que a expectativa de mudanas no grande. A forma de visualizao de um esquema chamada Diagrama do Esquema. Muitos modelos de dados tm certas convenes para, diagramaticamente, mostrar esquemas especificados no modelo. Os dados atualmente existentes em uma base de dados podem mudar com relativa freqncia. Os dados da base de dados em um particular momento do tempo so chamados Instncias da Base de Dados (ou Ocorrncias ou Estados). A base-esquema algumas vezes chamada de Base-Intencional e uma instncia chamada de Base-Extensional do esquema.
20
3.2
Arquitetura e Independncia de Dados de SGBDs
A arquitetura mais difundida na literatura a Arquitetura Three-Schema (tambm conhecida como arquitetura ANSI/SPARC), proposta por Tsichritzis & Klug em 1978. A meta desta arquitetura, exibida na Figura 3.1, separar as aplicaes de usurios da base de dados fsica. Nesta arquitetura, esquemas podem ser definidos em trs nveis: 1. O nvel interno tem um esquema interno que descreve a estrutura de armazenamento fsico da base de dados. O esquema interno usa um modelo de dados fsico e descreve todos os detalhes de armazenamento de dados e caminhos de acesso base de dados; 2. O nvel conceitual tem um esquema conceitual que descreve a estrutura de toda a base de dados. O esquema conceitual uma descrio global da base de dados, que omite detalhes da estrutura de armazenamento fsico e se concentra na descrio de entidades, tipos de dados, relacionamentos e restries. Um modelo de dados de alto-nvel ou um modelo de dados de implementao podem ser utilizados neste nvel. 3. O nvel externo ou viso possui esquemas externos ou vises de usurios. Cada esquema externo descreve a viso da base de dados de um grupo de usurios da base de dados. Cada viso descreve, tipicamente, a parte da base de dados que um particular grupo de usurios est interessado e esconde deste o restante da base de dados. Um modelo de dados de alto-nvel ou um modelo de dados de implementao podem ser usados neste nvel. USURIOS FINAIS
NVEL EXTERNO
VISO EXTERNA 1
VISO EXTERNA N
mapeamento externo/conceitual NVEL CONCEITUAL mapeamento conceitual/interno NVEL INTERNO ESQUEMA INTERNO ESQUEMA CONCEITUAL
BASE DE DADOS ARMAZENADA
Figura 3.1 Arquitetura Three-Schema

Muitos SGBDs no separam os trs nveis completamente. Pode acontecer que alguns SGBDs incluam detalhes do nvel interno no esquema conceitual. Em muitos SGBDs que permitem vises, os esquemas externos so especificados com o mesmo modelo de dados usado no nvel conceitual. Note que os trs esquemas so apenas descries dos dados. A arquitetura three-schema pode ser utilizada para explicar conceitos de independncia de dados, que podem ser definidos como a capacidade de alterar o esquema de um nvel sem ter que alterar o esquema no prximo nvel superior. Dois tipos de independncia de dados podem ser definidos:
21
Independncia Lgica de Dados: a capacidade de alterar o esquema conceitual sem ter que mudar os esquemas externos ou programas de aplicao. Pode-se mudar o esquema conceitual para expandir a base de dados, com a adio de novos tipos de registros (ou itens de dados), ou reduzir a base de dados removendo um tipo de registro. Neste ltimo caso, esquemas externos que se referem apenas aos dados remanescentes no devem ser afetados; Independncia Fsica de Dados: a capacidade de alterar o esquema interno sem ter que alterar o esquema conceitual externo. Mudanas no esquema interno podem ser necessrias devido a alguma reorganizao de arquivos fsicos para melhorar o desempenho nas recuperaes e/ou modificaes. Aps a reorganizao, se nenhum dado foi adicionado ou perdido, no haver necessidade de modificar o esquema conceitual.
3.3
Linguagens de Base de Dados
Linguagem de Definio de Dados (Data Definition Language - DDL): utilizada pelo DBA e projetistas de base de dados para definir seus esquemas. O SGBD tem um compilador para processar descries em DDL e construir a descrio do esquema armazenado no catlogo; Linguagem de Manipulao de Dados (Data Manipulation Language - DML): uma vez que o esquema compilado e a base de dados preenchida com dados, os usurios tm que ter algum modo de manipular os dados. Manipulaes comuns como recuperao, insero, remoo e modificao de dados so realizadas pela DML.
22
4 Modelagem de Dados Usando o Modelo EntidadeRelacionamento (MER)

O MER um modelo de dados conceitual de alto-nvel, ou seja, seus conceitos foram projetados para serem compreensveis a usurios, descartando detalhes de como os dados so armazenados. Atualmente, o MER usado principalmente durante o processo de projeto da base de dados. Existem expectativas para que uma classe de SGBDs baseados diretamente no MER esteja disponvel no futuro.
4.1
Modelo de Dados Conceitual de Alto-Nvel e Projeto de Base Dados
Mini-Mundo
OBTENO E ANLISE DE REQUISITOS Requisitos da Base de Dados PROJETO CONCEITUAL
Esquema Conceitual (em um Modelo de Dados de Alto-Nvel) Independente de qualquer SGBD MAPEAMENTO DO MODELO DE DADOS SGBD especfico Esquema Conceitual (em um Modelo de Dados de um SGBD especfico)
PROJETO FSICO
Esquema Interno (para o mesmo SGBD)
Figura 4.1 Esquema geral de modelagem de dados usando MER
4.2
Um Exemplo
Neste exemplo, descrita uma base de dados COMPANHIA que ser utilizada para ilustrar o processo de projeto de base de dados. So listados os requisitos da base de dados e criado o seu esquema conceitual passo-a-passo ao mesmo tempo em que so introduzidos os conceitos de modelagem usando o MER. A base de dados COMPANHIA armazena os dados dos empregados, departamentos e projetos. Supe-se que aps a Obteno e Anlise dos Requisitos, os projetistas da base de dados produziram a seguinte descrio do mini-mundo parte da companhia a ser representada na base de dados:
23
A companhia organizada em departamentos. Cada departamento tem um nome, um nmero e um empregado que gerencia o departamento. Armazena-se a data de incio que o empregado comeou a gerenciar o departamento. Um departamento pode ter diversas localizaes; Um departamento controla inmeros projetos, sendo que cada um tem um nome, um nmero e uma localizao; Do empregado armazena-se o nome, o nmero do seguro social, endereo, salrio, sexo e data de nascimento. Todo empregado associado a um departamento, mas pode trabalhar em diversos projetos, que no so necessariamente controlados pelo mesmo departamento. Armazena-se, tambm, o nmero de horas que o empregado trabalha em cada projeto. Mantm-se, ainda, a indicao do supervisor direto de cada projeto; Os dependentes de cada empregado so armazenados para propsito de garantir os benefcios do seguro. Para cada dependente ser armazenado o nome, sexo, data de nascimento e o relacionamento com o empregado.
4.3
Conceitos do Modelo Entidade-Relacionamento
4.3.1 Entidades e Atributos

O objeto bsico que o MER representa a entidade. Uma entidade algo do mundo real que possui uma existncia independente. Uma entidade pode ser um objeto com uma existncia fsica - uma pessoa, carro ou empregado - ou pode ser um objeto com existncia conceitual uma companhia, um trabalho ou um curso universitrio. Cada entidade tem propriedades particulares, chamadas atributos, que a descrevem. Por exemplo, uma entidade EMPREGADO pode ser descrita pelo seu nome, o trabalho que realiza, idade, endereo e salrio. Uma entidade em particular ter um valor para cada um de seus atributos. Os valores de atributos que descrevem cada entidade ocupam a maior parte dos dados armazenados na base de dados. A Figura 4.2 ilustra duas entidades. A entidade e1, EMPREGADO, tem quatro atributos: Nome, Endereo, Data de nascimento e Telefone residencial. Os seus valores so: Joo da Silva, Rua Gois 711, So Paulo, SP, 1301100, 31/07/1973 e 713-749, respectivamente. A entidade c1, COMPANHIA, tem trs atributos: Nome, Sede e Presidente. Seus valores so: Cooper Sugar, Ribeiro Preto e Joo da Silva.
Nome=Joo da Silva Endereo=Rua Gois 711, So Paulo, SP, 1301100 Idade=55 Data de nascimento = 31/07/1973 Telefone residencial=713-749
Nome=Cooper Sugar c Sede=Ribeiro Preto Presidente=Joo da Silva
Figura 4.2 Exemplo de entidades e seus respectivos atributos

Alguns atributos podem ser divididos em subpartes com significados independentes. Por exemplo, Endereo da entidade e1 pode ser dividido em Endereo da Rua, Cidade, Estado e CEP. Um atributo que composto de outros atributos mais bsicos chamado composto. J, atributos que no so divisveis so chamados simples ou atmicos. Atributos compostos podem formar uma hierarquia, conforme pode ser observado no exemplo da Figura 4.3.

Endereo
24
Endereo da Rua
Cidade
Estado
CEP
Nome da Rua
Nmero
Apartamento
Figura 4.3 Um exemplo de atributo composto

Atributos compostos so teis quando os usurios referenciam o atributo composto como uma unidade e, em outros momentos, referenciam especificamente a seus componentes. Se o atributo composto for sempre referenciado como um todo, no existe razo para subdividi-lo em componentes elementares. Muitos atributos tm apenas um nico valor. Tais atributos so chamados atributos univalorados (exemplo, Data de nascimento da entidade e1). Em outros casos, um atributo pode ter um conjunto de valores. Tais atributos so chamados de atributos multivalorados (exemplo, Telefone residencial da entidade e1). Atributos multivalorados podem possuir uma multiplicidade, indicando as quantidades mnima e mxima de valores. Em alguns casos, dois ou mais atributos so relacionados. Por exemplo, Idade e Data de Nascimento de uma pessoa. Para uma entidade pessoa em particular, a Idade pode ser determinada a partir da data atual e da Data de Nascimento. Atributos como Idade so
chamados atributos derivados3. Alguns valores de atributos podem ser derivados de entidades relacionadas. Por exemplo, um atributo Nmero de Empregados de uma entidade departamento que pode ser calculado contando-se o nmero de empregados relacionados com o departamento. Outras situaes: uma entidade pode no ter quaisquer valores para um atributo. Por exemplo, o atributo Apartamento aplica-se somente queles empregados que residam em algum prdio. Para tais situaes, um valor especial chamado null criado. O valor null pode tambm ser utilizado para denotar que o valor desconhecido, como por exemplo, quando o cliente em um cadastro no responde o nmero do CEP da rua onde reside. O significado para o primeiro uso do null no aplicvel e, para o segundo, desconhecido.
4.3.2 Tipos de Entidades, Conjunto de Valores e Atributos-Chaves

Uma base de dados ir conter normalmente grupos de entidades que so similares. Uma companhia com centenas de empregados pode querer agrupar as informaes similares com respeito a empregados. Estas entidades, empregados, compartilham os mesmos atributos, mas cada entidade ter seus prprios valores para cada atributo. Tais entidades similares definem o tipo de entidade, que um conjunto de entidades que tm os mesmos atributos. Na maioria das bases de dados podem-se identificar muitos tipos de entidades. A Figura 4.4 mostra dois tipos de entidades denominadas EMPREGADO e COMPANHIA, e uma lista de atributos. Algumas instncias so tambm ilustradas, juntamente com os seus valores de atributos:
Atributos derivados no necessitam ser armazenados na base de dados, podendo ser calculados por meio de uma consulta.

ESQUEMA (INTENO) INSTNCIAS (EXTENSO) EMPREGADO Nome, Idade, Salrio
1 (Joo da Silva, 55, 800) 2 (Roberto Carlos, 40, 300) 3 (Camlia Colina, 25, 200) e e e

COMPANHIA Nome, Sede, Presidente
25
1 (Cooper Sugar, Ribeiro Preto, Joo da Silva) 2 (FastCom, Dallas, Paulo Paz) c
Figura 4.4 Exemplo de entidades e suas instncias

A descrio do tipo de entidade chamada esquema do tipo de entidade e especifica uma estrutura comum compartilhada por todas as entidades individuais. O esquema especifica o nome do tipo de entidade, o significado de cada um de seus atributos e qualquer restrio que exista sobre entidades individuais. O conjunto de instncias de entidades em um particular momento do tempo chamado extenso do tipo de entidade. O esquema no alterado com freqncia porque descreve a estrutura das entidades individuais. A extenso pode mudar com freqncia, por exemplo, quando se adiciona ou remove-se uma entidade de um tipo de entidade. Atributo-Chave de um Tipo de Entidade: Uma restrio importante sobre entidades de um tipo de entidade a restrio de atributo-chave ou unicidade. Um tipo de entidade tem, normalmente, atributos cujos valores so distintos para cada entidade. Tal atributo chamado atributo-chave, e o seu valor pode ser usado para identificar cada entidade unicamente. Algumas vezes, um conjunto de atributos pode formar uma chave. Nestes casos, os atributos podem ser agrupados em um atributo composto, que vir a ser um atributo-chave do tipo de entidade. A especificao de um atributo-chave para um tipo de entidade significa que a propriedade de unicidade deve valer para quaisquer extenses deste tipo de entidade. Assim, esta restrio probe que duas entidades tenham, simultaneamente, o mesmo valor para o atributo-chave. Alguns tipos de entidades podem ter mais que um atributo-chave.
4.3.3 Relacionamentos, Papis e Restries Estruturais

Tipo e Instncia de Relacionamento: Um tipo de relacionamento R entre n tipos de entidades E1, E2, ..., En um conjunto de associaes entre entidades desses tipos. Diz-se que cada entidade E1, E2, ..., En participa no tipo de relacionamento R e que as entidades individuais e1, e2, ..., en participam na instncia do relacionamento ri=(e1, e2, ..., en). O ndice i indica que podem existir vrias instncias de relacionamento. Por exemplo, considere-se que um tipo de relacionamento TRABALHA-PARA exista entre tipos de entidades EMPREGADO e DEPARTAMENTO. Este relacionamento associa cada
26
empregado com o departamento em que este trabalha. Cada instncia de relacionamento em TRABALHA-PARA associa uma entidade empregado e uma entidade departamento. A Figura 4.5 ilustra este exemplo, onde cada instncia de relacionamento ri conectada a uma entidade empregado e a uma entidade departamento. No mini-mundo representado nesta Figura, os empregados e1, e3 e e6 trabalham para o departamento d1; e2 e e4 trabalham para d2; e e5 e e7 trabalham para d3.
TRABALHA-PARA EMPREGADO r e
1 2 3 4 5 6 7 1
DEPARTAMENTO
r r r r r r
e e e e e e
d 1
3
d 2
4
d 3
5
6 7
Figura 4.5 Exemplo de um Relacionamento Binrio

O Grau de um Tipo de Relacionamento: O grau de um tipo de relacionamento indica o nmero de tipos de entidades participantes. Assim, o tipo de relacionamento TRABALHAPARA de grau dois. Um tipo de relacionamento de grau dois chamado binrio e de grau trs de ternrio. Um exemplo de um tipo de relacionamento ternrio FORNECE, ilustrado na Figura 4.6. Cada instncia de relacionamento ri associa trs entidades - um fornecedor s, uma pea p e um projeto j - onde o fornecedor s fornece a pea p para o projeto j. Podem existir tipos de relacionamento de qualquer grau, porm mais freqente encontrar o tipo de relacionamento de grau dois.
FORNECE FORNECEDOR s
1 2
r r r r
PROJETO
j 1
3
j 2
4
PEA p
1 2 3
r r r
j 3
5
p p
6 7
Figura 4.6 Exemplo de um Relacionamento Ternrio
27
Em geral, um tipo de relacionamento ternrio representa mais informao do que trs tipos de relacionamentos binrios. Por exemplo, considere os trs tipos de relacionamentos binrios: PODE-FORNECER, USA e FORNECE-ALGO. Supe-se que: a. PODE-FORNECER, entre os tipos de entidades FORNECEDOR e PEA, possui uma instncia (s, p) com o significado: "o fornecedor s pode fornecer a pea p" (para qualquer projeto); b. USA, entre os tipos de entidades PROJETO e PEA, possui uma instncia (j, p) com o significado: "o projeto j usa a pea p"; e c. FORNECE-ALGO, entre os tipos de entidades FORNECEDOR e PROJETO, possui uma instncia (s, j) com o significado: "o fornecedor s fornece alguma pea para o projeto j". A existncia dessas trs instncias de relacionamentos (s, p), (j, p) e (s, j) em PODEFORNECER, USA e FORNECE-ALGO, respectivamente, no necessariamente implica que uma instncia (s, j, p) exista no tipo de relacionamento ternrio FORNECE. Isto tem sido chamado armadilha de conexo. Relacionamento como Atributo: Convm, algumas vezes, pensar em um tipo de relacionamento em termos de atributos. Considere-se o tipo de relacionamento TRABALHA-PARA discutido anteriormente. Pode-se pensar em colocar um atributo chamado Departamento no tipo de entidade EMPREGADO onde o valor deste atributo em cada entidade empregado a entidade departamento em que ele trabalha. Quando se pensa em um tipo de relacionamento binrio como atributo, existem duas alternativas: Departamento como atributo do tipo de entidade EMPREGADO ou Empregado como atributo do tipo de entidade DEPARTAMENTO. Neste ltimo caso, o atributo Empregado um atributo multivalorado, onde os valores pertencem ao tipo de entidade EMPREGADO. Qualquer uma dessas alternativas representada pelo tipo de relacionamento TRABALHAPARA. Nomes de Papis e Relacionamentos Recursivos: Cada tipo de entidade que participa de um tipo de relacionamento possui um papel especfico no relacionamento. O nome do papel indica o papel que uma entidade de um tipo de entidade tem para cada instncia de relacionamento. Por exemplo, no tipo de relacionamento TRABALHA-PARA, EMPREGADO tem o papel empregado ou trabalhador e DEPARTAMENTO tem o papel de departamento ou empregador. A escolha do nome nem sempre simples. Para o tipo de relacionamento ternrio FORNECE, difcil encontrar-se um nome. O nome de papel no exclusividade do tipo de relacionamento onde os tipos de entidades participantes so distintos. Em alguns casos, um mesmo tipo de entidade participa mais que uma vez em um tipo de relacionamento com diferentes papis. Nesses casos, essencial identificar os nomes dos papis a fim de distinguir o significado de cada participao. Tais tipos de relacionamentos so chamados recursivos. Para ilustrar, considere a Figura 4.7:
SUPERVISIONA EMPREGADO 1 e
1 2 3
r r
2 2
e e e
4
1 1 r
Figura 4.7 Exemplo de auto-relacionamento (Papel do relacionamento)

O tipo de relacionamento SUPERVISIONA relaciona um empregado com o seu supervisor, onde ambas entidades so membros do mesmo tipo de entidade EMPREGADO. Assim, o tipo de entidade EMPREGADO participa duas vezes: uma vez no papel de supervisor e outra no papel de supervisionado. Na 4.7 acima, as linhas marcadas com "1" representam
28
o papel de supervisor e os marcados com "2" representam o papel de supervisionado. Assim, e1 supervisiona e2, e2 supervisiona e3 e e3 supervisiona e4. Restries sobre Tipos de Relacionamentos: Os tipos de relacionamento possuem certas restries que limitam as combinaes possveis de entidades participando nas instncias de relacionamento. Estas restries so determinadas pelas situaes do mini-mundo que os relacionamentos representam. Por exemplo, na Figura 4.5, se existir uma regra que um empregado trabalha para apenas um departamento, ento esta restrio deve ser descrita no esquema. Pode-se distinguir dois principais tipos de restries de relacionamento que ocorrem com relativa freqncia: razo de cardinalidade e participao. A restrio razo de cardinalidade especifica a quantidade de instncias de relacionamento que uma entidade pode participar. No tipo de relacionamento binrio TRABALHA-PARA, DEPARTAMENTO:EMPREGADO tem razo de cardinalidade 1:N. Isto significa que cada entidade departamento pode estar relacionada a inmeras entidades empregado (muitos empregados podem trabalhar para um departamento) mas uma entidade empregado pode estar relacionada a apenas um departamento (um empregado pode trabalhar apenas para um departamento). As razes de cardinalidade mais comuns para tipos de relacionamento binrio so 1:1, 1:N e M:N. Um exemplo de um tipo de relacionamento binrio 1:1 pode ser observado na Figura 4.8, entre DEPARTAMENTO e EMPREGADO GERENCIA, que relaciona uma entidade departamento com o empregado que gerencia esse departamento. Este relacionamento 1:1 pois sabe-se que um empregado pode gerenciar apenas um departamento e que um departamento pode ter apenas um gerente.
GERENCIA EMPREGADO DEPARTAMENTO
e
1 2 3 4 5 6 7
e e e e e e
r r r
d d d
Figura 4.8 Exemplo de um relacionamento binrio 1:1

O tipo de relacionamento TRABALHA-EM entre EMPREGADO e PROJETO tem a razo de cardinalidade M:N (Figura 4.9) considerando que um empregado pode trabalhar em diversos projetos e que diversos empregados podem trabalhar em um projeto.

TRABALHA-EM EMPREGADO
29
PROJETO r
e
1 2 3 4
e e e
r r r r r
p 1 p 2 p 3
p 4
5
Figura 4.9 Exemplo de um relacionamento binrio M:N

A restrio de participao especifica se a existncia de uma entidade depende dela estar relacionada com outra entidade atravs de um relacionamento. Existem dois tipos de restries de participao: total e parcial. Se uma companhia estabelece a regra de que todo empregado deve trabalhar para um departamento, ento uma entidade empregado somente pode existir se ele participar em uma instncia de relacionamento TRABALHAPARA. A participao de EMPREGADO em TRABALHA-PARA chamada total, o que significa que toda entidade empregado deve estar relacionada a uma entidade departamento via TRABALHA-PARA. A restrio de participao total algumas vezes chamada dependncia existencial. No esperado, na Figura 4.8, que todo empregado gerencie um departamento, assim a participao de EMPREGADO no tipo de relacionamento GERENCIA parcial. Isso significa que algumas entidades, do conjunto de entidades EMPREGADO, podero estar relacionadas a uma entidade departamento via GERENCIA, mas no necessariamente todas. As restries de participao e razo de cardinalidade podem ser derivadas da restrio estrutural de um tipo de relacionamento. simples especificar as restries estruturais, embora no seja to intuitiva quanto s restries de participao e razo de cardinalidade. Pode-se associar um par de nmeros inteiros (min, max) para cada participao de um tipo de entidade E em um tipo de relacionamento R, onde 0 min max e max 1. Os nmeros indicam que para cada entidade e em E, e deve participar ao menos min e no mximo max vezes em instncias de relacionamento de R. Note-se, que se min=0 ento a restrio de participao parcial e se min>0 ento a participao total. A vantagem de usar este mtodo que ele mais preciso e pode ser usado facilmente para especificar restries estruturais para tipos de relacionamentos de qualquer grau. Atributos em Tipos de Relacionamento: Os tipos de relacionamento tambm podem ter atributos da mesma maneira que os tipos de entidades. Por exemplo, pode haver a necessidade de se representar a quantidade de horas semanais trabalhadas por um empregado em um dado projeto. Isto pode ser representado em cada instncia de relacionamento TRABALHA-EM na forma de atributo denominado Horas. Um outro
30
exemplo o caso de representar a data em que um gerente comeou a gerenciar um departamento atravs de um atributo DataIncio para o tipo de relacionamento GERENCIA (Figura 4.8). Note-se que atributos de tipos de relacionamento 1:1 ou 1:N podem ser includos como atributos de um dos tipos de entidades participantes. Por exemplo, o atributo DataIncio para o tipo de relacionamento GERENCIA pode ser um atributo tanto de EMPREGADO quanto de DEPARTAMENTO; embora, conceitualmente, ele pertena ao relacionamento GERENCIA. Isso ocorre porque GERENCIA um relacionamento 1:1. Assim, toda entidade departamento ou empregado participam em apenas uma instncia de relacionamento e, dessa forma, o valor do atributo DataIncio pode ser representado em uma das entidades participantes. Para um tipo de relacionamento 1:N, um atributo de relacionamento pode somente ser colocado no tipo de entidade que est do lado N do relacionamento. Por exemplo, na Figura 4.5, se o relacionamento TRABALHA-PARA tiver um atributo DataIncio indicando quando um empregado comeou a trabalhar para um departamento, este atributo pode ser colocado como atributo de EMPREGADO. Isto acontece porque o relacionamento 1:N, tal que cada entidade empregado participa apenas uma nica vez em uma instncia de TRABALHA-PARA. Em ambos os tipos de relacionamento 1:1 e 1:N, a deciso de onde colocar um atributo de relacionamento determinada subjetivamente pelo projetista de esquemas. Se o valor de um atributo determinado pela combinao das entidades participantes em uma instncia de relacionamento, e no apenas por uma das entidades, ento o atributo deve ser especificado como um atributo de relacionamento. Esta condio aplica-se a atributos de tipos de relacionamentos M:N, porque as entidades dos tipos de entidades participantes podem participar em inmeras instncias de relacionamento. Um exemplo disso o atributo Horas do relacionamento M:N TRABALHA-EM (Figura 4.9). O nmero de horas que um empregado trabalha em um projeto determinado pela combinao empregado-projeto e no separadamente.
4.3.4 Tipo de Entidade-Fraca

Alguns tipos de entidades podem no ter quaisquer atributos-chaves. Isto implica que no se pode distinguir as entidades porque a combinao dos valores de atributos podem ser idnticas. Tais tipos de entidades so chamadas tipos de entidades-fracas. Entidades que pertencem a um tipo de entidade-fraca so identificadas por estarem associadas a entidades especficas de um outro tipo de entidade em combinao com alguns de seus valores de atributos. Este outro tipo de entidade denominado proprietrio da identificao, e o tipo de relacionamento que relaciona um tipo de entidade-fraca com o proprietrio da identificao chamado relacionamento de identificao do tipo de entidade-fraca. Um tipo de entidadefraca sempre tem uma restrio de participao total (dependncia existencial) com respeito ao seu relacionamento de identificao, porque no possvel identificar uma entidade-fraca sem a correspondente entidade proprietria. Por exemplo, considere o tipo de entidade DEPENDENTE, relacionado a EMPREGADO, que usado para representar os dependentes de cada empregado atravs do relacionamento 1:N. Os atributos de DEPENDENTE so Nome (apenas o primeiro nome do dependente), DataNasc, Sexo e Relao com o empregado (esposa, marido, filho, sogra, etc.). Dois dependentes de empregados distintos podem ter os mesmos valores para os atributos, mesmo assim eles ainda sero entidades distintas. Os dependentes sero identificados como entidades distintas aps a determinao da entidade empregado com a qual cada um est relacionado.
31
Um tipo de entidade-fraca tem uma chave-parcial, que um conjunto de atributos que pode univocamente identificar entidades-fracas relacionadas mesma entidade proprietria. No exemplo, assume-se que nenhum dependente de um mesmo empregado ter o mesmo nome, ento o atributo Nome de DEPENDENTE ser a chave-parcial. Um tipo de entidade-fraca pode, algumas vezes, ser representado como atributo composto e multivalorado. No exemplo, pode-se especificar um atributo composto e multivalorado denominado Dependente para EMPREGADO, onde os atributos componentes so Nome, DataNasc, Sexo e Relao, substituindo-se assim, o tipo de entidade-fraca DEPENDENTE. A escolha de qual representao usar determinada pelo projetista da base de dados. Um critrio usado para se adotar a representao de tipo de entidade-fraca quando o tipo de entidade-fraca tem muitos atributos ou participa, independentemente, em outros tipos de relacionamentos alm do tipo de relacionamento que o identifica.
4.3.5 Projeto da Base de Dados COMPANHIA utilizando o MER

Tendo visto os conceitos pertinentes ao MER, pode-se agora especificar os seguintes tipos de relacionamentos extrados do exemplo apresentado na seo 4.2. a. GERENCIA (1:1) entre EMPREGADO e DEPARTAMENTO. A participao de EMPREGADO parcial. A participao de DEPARTAMENTO total. O atributo DataIncio associado a este tipo de relacionamento. b. TRABALHA-PARA (1:N) entre DEPARTAMENTO e EMPREGADO. Ambos tm participao total. c. CONTROLA (1:N) entre DEPARTAMENTO e PROJETO. A participao de PROJETO total e de DEPARTAMENTO parcial. d. SUPERVISIONA (1:N) entre EMPREGADO (no papel de supervisor) e EMPREGADO (no papel de supervisionado). A participao de ambos parcial, pois nem todo empregado supervisor e nem todo empregado tem um supervisor. e. TRABALHA-EM (M:N) entre EMPREGADO e PROJETO com o atributo Horas. Ambos tm participao total. f. DEPENDENTE-DE (1:N) entre EMPREGADO e DEPENDENTE. um tipo de relacionamento de identificao para o tipo de entidade-fraca DEPENDENTE. A participao de EMPREGADO parcial e de DEPENDENTE total. Nas Figuras de 4.5 a 4.9 foram representados os tipos de entidades e relacionamentos mostrando suas extenses (as entidades e instncias de relacionamentos). Em diagramas do MER, ou simplesmente DER, a nfase est na representao de esquemas ao invs de instncias. Isso porque o esquema de uma base de dados raramente sofre mudanas, j instncias podem mudar freqentemente. Tambm, o esquema de fcil visualizao por conter menor quantidade de elementos visuais.
4.4
Diagrama Entidade-Relacionamento (DER)
A Figura 4.10 ilustra um DER para o esquema da base de dados COMPANHIA. Os tipos de entidades tais como EMPREGADO, DEPARTAMENTO e PROJETO so mostrados em retngulos. Tipos de relacionamentos tais como TRABALHA-PARA, GERENCIA, CONTROLA e TRABALHA-EM so mostrados em losngulos interligados a tipos de entidades participantes. Atributos so mostrados em elipses conectadas a tipos de entidades ou relacionamentos. Os componentes de um atributo composto so tambm representados em elipses, porm conectadas ao atributo ao qual eles pertencem (atributo Nome de EMPREGADO). Atributos multivalorados so denotados em elipses com linhas duplas (atributo Localizao de DEPARTAMENTO). Os atributos-chaves so sublinhados. Atributos derivados em elipses com linhas tracejadas (atributo NumeroDeEmpregados de DEPARTAMENTO).
32
Os tipos de entidades-fracas so distinguidos por retngulos com linhas duplas e os relacionamentos de identificao por losngulos com linhas duplas (tipo de entidade-fraca DEPENDENTE e tipo de relacionamento de identificao DEPENDENTE-DE). A chave-parcial de um tipo de entidade-fraca sublinhada com linha tracejada.
Nmero Pnome Mnome Snome Nome Nome Nss Endereo Sexo Salrio
N 1
Localizao
TRABALHA-PARA
EMPREGADO DataNasc
DataIncio
NmeroDeEmpregados
DEPARTAMENTO
1 supervisor supervisiona
GERENCIA
CONTROLA
SUPERVISIONA
Horas
N M 1 N
TRABALHA-EM
PROJETO
DEPENDENTE-DE
Nome Nmero Localizao
DEPENDENTE
Nome
Sexo
DataNasc
Relao
Figura 4.10 Diagrama Entidade Relacionamento para o Esquema Companhia

Na Figura 4.10 so mostradas as razes de cardinalidade para cada tipo de relacionamento binrio. A razo de cardinalidade de DEPARTAMENTO:EMPREGADO em GERENCIA 1:1, para DEPARTAMENTO:EMPREGADO em TRABALHA-PARA 1:N e M:N para TRABALHAEM. As restries de participao parcial so especificadas por linhas simples. As linhas paralelas denotam participao total (dependncia existencial). Na Figura 4.10 foram mostrados os nomes de papis para o tipo de relacionamento SUPERVISIONA porque o tipo de entidade EMPREGADO ocupa dois papis neste relacionamento. Na Figura 4.11 mostrado o mesmo esquema da Figura 4.10, porm com a utilizao da notao alternativa para ilustrar as restries estruturais de tipos de relacionamentos.
33
Nmero Pnome Mnome Snome Nome Nome Nss Endereo

(1,1)
Localizao
TRABALHA-PARA
(4,n)
Sexo
Salrio
EMPREGADO DataNasc
supervisor (0,n) supervisiona (0,1)
DataIncio
(0,1)
NmeroDeEmpregados
(1,1)
DEPARTAMENTO
(0,n)
GERENCIA CONTROLA
(1,n)
SUPERVISIONA
(0,n)
Horas
(1,1)
(1,n)
TRABALHA-EM
PROJETO
DEPENDENTE-DE
Nome Nmero Localizao
(1,1)
DEPENDENTE
Nome
Sexo
DataNasc
Relao
Figura 4.11 DER para o Esquema Companhia com notao alternativa
4.5
Tipos de Relacionamentos de Grau maior que Dois
Na Seo 4.3.3 definiu-se grau de um tipo de relacionamento como o nmero de tipos de entidades participantes e chamou-se o tipo de relacionamento de grau dois de binrio e de grau trs de ternrio. A notao do DER para um tipo de relacionamento ternrio mostrada na Figura 4.13(a), que mostra o esquema para o tipo de relacionamento FORNECE que foi mostrado no nvel de extenso na Figura 4.6. Em geral, um tipo de relacionamento R de grau n ir ter n arestas no DER, cada um conectando R para cada tipo de entidade participante. A Figura 4.13(b) mostra um DER para os tipos de relacionamento binrio PODE-FORNECER, USA E FORNECE-ALGO. Como visto na Seo 4.3.3, estes trs tipos de relacionamento binrio no so equivalentes ao tipo de relacionamento ternrio FORNECE. freqentemente difcil decidir se um determinado relacionamento deve ser representado como um tipo de relacionamento de grau n ou dividido em muitos tipos de relacionamentos de menor grau. O projetista da base de dados deve guiar-se pela semntica, ou pelo significado da situao particular que estiver representando, para decidir qual alternativa adotar. Um outro exemplo mostrado na Figura 4.13(c). O tipo de relacionamento ternrio FORNECE representa a informao sobre os instrutores que oferecem cursos em um dado semestre. Assim, ele possui uma instncia de relacionamento (i, s, c) onde o instrutor i oferece o curso c
34
durante o semestre s. Os trs tipos de relacionamento binrios mostrados na Figura 4.13(c) tm os seguintes significados: a. PODE-DAR: relaciona os instrutores que podem dar um dado curso. b. D: relaciona os instrutores que do algum curso num dado semestre. c. OFERECIDO: relaciona os cursos oferecidos num dado semestre por algum professor. Em geral, os relacionamentos binrios e ternrios representam informaes diferentes, mas certas restries podem ser feitas entre estes relacionamentos. Por exemplo, uma instncia de relacionamento (i, s, c) somente ir existir em OFERECE se a instncia (i, s) em D, a instncia (s, c) em OFERECIDO e a instncia (i, c) em PODE-DAR existirem. No entanto, o inverso no sempre verdade; pode ser que existam instncias (i, s), (s, c) e (i, c) nos trs tipos de relacionamentos binrios e, mesmo assim, no existir nenhuma instncia (i, s, c) em OFERECE. Sobre certas restries adicionais (i, s, c) pode existir, por exemplo, se o tipo de relacionamento PODE-DAR for 1:1, ou seja, se um instrutor somente puder dar aulas em apenas um curso e um curso puder ter apenas um instrutor. O projetista da base de dados deve analisar cada situao especfica para decidir qual tipo de relacionamento binrio e ternrio ir necessitar.
Nome Quantidade Nome
FORNECEDOR Nmero
FORNECE
PROJETO
(a)
PEA
Nome
M
FORNECE-ALGO
Nome
FORNECEDOR Nmero N
PODE-FORNECER
PROJETO
(b)
M N PEA USA
Semestre M D N
Ano
Nome
Sem-Ano
INSTRUTOR Nmero N PODE-DAR
FORNECE
SEMESTRE
(c)
M N CURSO OFERECIDO
Figura 4.13 Comparao entre relacionamentos binrios e ternrios.
35
Note-se que possvel ter um tipo de entidade-fraca com um tipo de relacionamento de identificao ternrio (ou n-rio). Neste caso, o tipo de entidade-fraca pode ter muitos tipos de entidades proprietrias da identificao. Um exemplo mostrado na Figura 4.14. As razes de cardinalidade tambm so aplicveis em tipos de relacionamentos n-rios.
Nome
Quantidade
Nome
CANDIDATO
REALIZA
COMPANHIA
Departamento
Data ENTREVISTA TRABALHO
Dept/Data
RESULTA
Figura 4.14 Exemplo de relacionamento ternrio com entidade fraca.
36
Sumrio da Notao do Diagrama Entidade-Relacionamento (DER)
Smbolo
Significado
Tipo de Entidade Tipo de Entidade-Fraca Tipo de Relacionamento Tipo de Relacionamento Identificador Atributo Atributo-Chave Atributo Multivalorado
....
Atributo Composto
Atributo Derivado Participao Total de E2 em R
E1
1
R
N
E2
E1
R
(min, max)
E2
Razo de Cardinalidade 1:N para E1:E2 em R
Restrio Estrutural (min, max) na participao de E em R
37
4.6
Questes para a Sntese
1. Discuta o papel de um modelo de dados de alto-nvel no processo de projeto de base de dados. 2. Cite alguns casos onde o valor null pode ser aplicado. 3. Defina os seguintes termos: entidade, atributo, valor de atributo, instncia de relacionamento, atributo composto, atributo multivalorado, atributo derivado e atributochave. 4. O que um tipo de entidade? Descreva as diferenas entre entidade e tipo de entidade. 5. O que um tipo de relacionamento? Descreva as diferenas entre instncia e tipo de relacionamento. 6. Quando necessrio utilizar nome de papis na descrio de tipos de relacionamentos? 7. Descreva as duas alternativas para especificar as restries estruturais sobre tipos de relacionamentos. Quais so as vantagens e desvantagens de cada uma? 8. Sobre quais condies pode um atributo de um tipo de relacionamento binrio ser promovido a um atributo de um dos tipos de entidades participantes? 9. Sobre quais condies um tipo de relacionamento pode se tornar um atributo de um tipo de entidade? 10. Qual o significado de um tipo de relacionamento recursivo? D alguns exemplos disso. 11. Quando o conceito de entidade-fraca til na modelagem de dados? Defina os termos: tipo de entidade proprietrio, tipo de relacionamento de identificao e chave-parcial. 12. Um tipo de relacionamento de identificao pode ter grau maior que dois? 13. Discuta as condies em que um tipo de relacionamento ternrio pode ser representado por um nmero de tipos de relacionamentos binrios.
38
5 O Modelo de Dados Relacional

O Modelo de Dados Relacional foi introduzido por Codd (1970). Entre os modelos de dados de implementao, o modelo relacional o mais simples, com estrutura de dados uniforme, e tambm o mais formal.
5.1
Conceitos do Modelo Relacional
O modelo de dados relacional representa os dados da base de dados como uma coleo de relaes. Informalmente, cada relao pode ser entendida como uma tabela ou um simples arquivo de registros. Por exemplo, a base de dados de arquivos representada pela Figura 5.1, considerada estando no modelo relacional. Porm, existem diferenas importantes entre relaes e arquivos.
ESTUDANTE
Nome Soares Botelho
Nmero 17 8
Classe 1 2 Nmero DCC1310 DCC3320 MAT2410 DCC3380
Departamento DCC DCC Crditos 4 4 4 4 Departamento DCC DCC MAT DCC
CURSO
Nome Introd. Cincias de Comp. Estrutura de Dados Matemtica Discreta Base de Dados Nmero DCC3380 DCC3380 DCC3320 Curso MAT2410 DCC1310 DCC3320 MAT2410 DCC1310 DCC3380
PR-REQUISITO
Pr-requisito DCC3320 MAT2410 DCC1310 Semestre 1 1 2 1 1 1 Ano 86 86 87 87 87 87 Professor Kotaro Alberto Kleber Carlos Alberto Souza Nvel B C A A B A
SEO
Nmero 85 92 102 112 119 135
HISTRICO
NmeroEstudante 17 17 8 8 8 8
NmeroSeo 112 119 85 92 102 135
Figura 5.1 Exemplo de uma base de dados relacional

Quando uma relao vista como uma tabela de valores, cada linha representa uma coleo de valores relacionados. Esses valores podem ser interpretados como um fato que descreve uma entidade ou uma instncia de relacionamento. O nome da tabela e os nomes das colunas so usados para ajudar a interpretar o significado dos valores em cada linha da tabela. Por
39
exemplo, na Figura 5.1 anterior, a primeira tabela chamada ESTUDANTE porque cada linha representa o fato sobre uma particular entidade estudante. Os nomes das colunas - Nome, Nmero, Classe, Departamento - especificam como interpretar os valores em cada linha, baseando-se nas colunas em que cada um se encontra. Todos os valores de uma mesma coluna so, normalmente, do mesmo tipo. Na terminologia de base de dados relacional, a linha chamada de tupla, a coluna chamada de atributo e a tabela de relao. O tipo de dado que especifica o tipo dos valores que podem aparecer em uma coluna chamado de domnio. Uma relao esquema R, denotada por R(A1, A2, ..., An), um conjunto de atributos R={A1, A2, ..., An}. Cada atributo Ai indica o nome do papel de algum domnio D na relao esquema R. D chamado domnio de Ai e denotado por dom(Ai). Uma relao esquema utilizada para descrever uma relao e R o nome dessa relao. O grau de uma relao o nmero de atributos da relao. Considere o exemplo de uma relao esquema de grau 7, que descreve estudantes universitrios: ESTUDANTE(Nome, NSS, Telefone, Endereo, TelComercial, Anos, MPA) Nesta relao esquema, ESTUDANTE o nome da relao esquema, que tem 7 atributos. Pode-se especificar alguns domnios para atributos da relao ESTUDANTE: dom(Nome)=Nomes dom(NSS)=Nmero do seguro social dom(Telefone)=Nmero de telefone nacional dom(TelComercial)=Nmero de telefone nacional dom(MPA)=Mdia dos Pontos Acumulados Uma relao r (ou instncia de relao) da relao esquema R(A1, A2, ..., An), tambm denotada por r(R), um conjunto de tuplas r={ t1, t2, ..., tm}. Cada tupla t uma lista ordenada
de n valores t=<v1, v2, ..., vn>, onde cada valor vi, 1 i n, um elemento do dom(Ai) ou um valor especial null. So utilizados, com freqncia, os termos inteno da relao para o esquema R e extenso da relao para a instncia r(R).
Atributos
ESTUDANTE
tuplas
Nome Joaquim Katarina Dav Carlos Barbara
NSS 305 381 422 489 533
Telefone 555-444 555-333 null 555-376 555-999
Endereo R. X, 123 Av. K, 43 R. D, 12 R. H, 9 Av. f, 54
TelComercial null null 555-678 555-789 null
Anos 19 18 25 28 19
MPA 3.21 2.89 3.53 3.93 3.25
Figura 5.2 Exemplos de instncias para uma relao ESTUDANTE.

A Figura 5.2 mostra um exemplo de uma relao ESTUDANTE, que corresponde ao esquema estudante especificado anteriormente. Cada tupla na relao representa uma entidade estudante. A relao mostrada em forma de tabela, onde cada tupla representada pelas linhas e cada atributo na linha de cabealho indicando os papis ou a interpretao dos valores encontrados em cada coluna.
5.1.1 Notao do Modelo Relacional

As seguintes notaes sero utilizadas para apresentar alguns conceitos do modelo relacional:
40
Uma relao esquema R de grau n representada como R(A1, A2, ..., An). Uma tupla t em uma relao r(R) representada como t=<v1, v2, ..., vn>, onde vi o valor correspondente para atributos Ai. Sero utilizadas as seguintes notaes para se referir aos valores dos componentes de tuplas: t[Ai] indica o valor de vi em t para o atributo Ai. t[Au, Aw, ..., Az] onde Au, Aw, ..., Az uma lista de atributos de R, indica o conjunto de valores <vu, vw, ..., vz> de t correspondentes aos atributos especificados na lista. As letras Q, R e S denotam nomes de relao. As letras q, r e s denotam instncias de relao. As letras t, u e v denotam tuplas. Em geral, o nome de uma relao tal como ESTUDANTE indica o conjunto atual de tuplas na relao - instncia corrente da relao - e ESTUDANTE(Nome, NSS, ...) refere-se relao esquema. Os nomes de atributos so algumas vezes qualificados com o nome da relao a qual pertencem, por exemplo, ESTUDANTE.Nome ou ESTUDANTE.Anos.
Considere uma tupla t=<'Barbara', '533', '555-999', 'Av. f, 54', null, 19, 3.25> da relao ESTUDANTE da Figura 5.2; t[Nome]=<'Barbara'> e t[NSS, MPA, Anos]=<'533', 3.25, 19>.
5.1.2 Atributos-chaves de uma Relao

Uma relao definida como um conjunto de tuplas. Pela definio, todos os elementos de um conjunto so distintos. Assim, todas as tuplas de uma relao tambm so distintas. Isto significa que nenhuma tupla pode ter a mesma combinao de valores para todos os seus atributos. Normalmente, existem subconjuntos de atributos de uma relao esquema R com a propriedade de que nenhuma tupla de uma relao r de R tenha a mesma combinao de valores para esses atributos. Suponha que esse subconjunto seja denotado por SC; ento para quaisquer tuplas t1 e t2 em r de R, deve valer a regra: t1[SC]t2[SC] Assim, SC chamada super-chave da relao esquema R. Toda relao tem ao menos uma super-chave, que o conjunto de todos os seus atributos. Uma chave C, de uma relao esquema R, uma super-chave de R com a propriedade adicional de no se poder remover qualquer atributo A de C e continuar a ser super-chave de R. Assim, uma chave uma superchave mnima; uma super-chave da qual no se pode remover qualquer atributo. Por exemplo, considere a relao ESTUDANTE da Figura 5.2. O conjunto de atributos {NSS} uma super-chave de ESTUDANTE porque sabe-se que nenhum estudante ir ter o mesmo valor para NSS e tambm uma chave, pois no se pode remover nenhum atributo. Qualquer conjunto de atributos que inclua NSS - por exemplo, {NSS, Nome, Anos} - ser uma superchave. No entanto, o conjunto {NSS, Nome, Anos} no uma chave de ESTUDANTE porque removendo Nome ou Anos, ou ambos, o conjunto resultante ser ainda uma super-chave. O valor de um atributo-chave pode ser usado para identificar unicamente uma tupla em uma relao. Por exemplo, o valor 533, do atributo NSS, identifica unicamente a tupla correspondente 'Barbara' na relao ESTUDANTE. Note-se, que a indicao de quais atributos que formam a chave deve ser feita na relao esquema, a fim de restringir qualquer duplicao de tuplas em quaisquer instncias do esquema. A chave deve ser determinada pelo significado dos atributos na relao esquema e deve ser invariante ao tempo. Por exemplo, o atributo Nome da relao ESTUDANTE no pode ser indicada como chave, uma vez que nada garante a no ocorrncia de homnimos.
41
Em geral, uma relao esquema pode ter mais que uma chave. Nestes casos, cada chave chamada chave-candidata. Por exemplo, o esquema da relao ESTUDANTE poderia ter um atributo adicional Cdigo, para indicar o cdigo interno de estudantes na escola. Assim, o esquema teria duas chaves candidatas: NSS e Cdigo. comum designar uma das chaves candidatas como a chave-primria da relao. A indicao no modelo de qual chavecandidata a chave-primria realizada sublinhado-se os atributos que formam a chavecandidata escolhida. Quando uma relao esquema tem muitas chaves-candidatas, a escolha da chave-primria arbitrria; no entanto, sempre melhor escolher a chave-primria com o menor nmero de atributos.
5.1.3 Esquemas de Bases de Dados Relacionais e Restries de Integridade

Definio de um esquema de base de dados relacional e instncia da base de dados relacional: um esquema da base de dados relacional, S, um conjunto de relaes esquemas S={R1, R2, ..., Rm} e um conjunto de restries de integridade (RI). Uma instncia da base de dados relacional, DB de S, um conjunto de instncias de relaes DB={r1, r2, ..., rm} tal que ri uma instncia de Ri e que satisfaz as restries de integridade especificadas em RI. A Figura 5.3 ilustra um esquema da base de dados relacional denominada COMPANHIA. O termo base de dados relacional refere-se, implicitamente, ao esquema e s suas instncias.
EMPREGADO
PNOME MNOME SNOME NSS DATANASC ENDEREO SEXO SALARIO NSSSUPER NDEP
DEPARTAMENTO
DNOME DNMERO NSSGER DATINICGER
LOCAIS_DEPTO
DNMERO DLOCALIZAO
PROJETO
PNOME PNMERO PLOCALIZAO DNUM
TRABALHA_EM
NSSEMP PNRO HORAS
DEPENDENTE
NSSEMP NOMEDEPENDENTE SEXO DATANIV RELAO
Figura 5.3 Esquema da base de dados relacional COMPANHIA

Observa-se, na Figura 5.3 acima, que o atributo DNMERO tanto de DEPARTAMENTO quanto de LOCAIS_DEPTO referem-se ao mesmo conceito do mundo real - o nmero dado a um departamento. Este mesmo conceito chamado NDEP em EMPREGADO e DNUM em PROJETO. Isto significa que permitido dar nomes de atributos distintos para um mesmo conceito do mundo real. Permite-se, tambm, que atributos que representam conceitos diferentes tenham o mesmo nome desde que em relaes diferentes. Por exemplo, poderia ter sido usado NOME ao invs de PNOME e DNOME nas relaes esquemas PROJETO e DEPARTAMENTO, respectivamente. Restries de Integridade sobre um Esquema de Base de Dados Relacional: as restries de chave especificam as chaves-candidatas de cada relao esquema; os valores das chaves-candidatas devem ser nicos para todas as tuplas de quaisquer instncias da relao esquema. Alm da restrio de chave, dois outros tipos de restries so consideradas no modelo relacional: integridade de entidade e integridade referencial.
42
A restrio de integridade de entidade estabelece que nenhum valor da chave-primria pode ser nulo. Isso porque, o valor de uma chave-primria utilizado para identificar tuplas em uma relao. Por exemplo, se duas ou mais tuplas tiverem o valor null para a chaveprimria, no haver como diferenciar uma tupla da outra. As restries de chave e de integridade de entidade aplicam-se apenas a relaes individuais. A restrio de integridade referencial uma restrio que especificada entre duas relaes e usada para manter a consistncia entre tuplas de duas relaes. Informalmente, a restrio de integridade referencial estabelece que uma tupla de uma relao que se refere outra relao deve se referir a uma tupla existente naquela relao. Por exemplo, na Figura 5.4, o atributo NDEP de EMPREGADO indica o nmero do departamento que cada empregado trabalha. Assim, todos os valores de NDEP nas tuplas da relao EMPREGADO devem pertencer ao conjunto de valores do atributo DNMERO da relao DEPARTAMENTO.
EMPREGADO PNOME MNOME John B Franklin T Alicia J Jennifer S Ramesh K Joyce A Ahmad V James E SNOME Smith Wong Zelaya Wallace Narayan English Jabbar Borg NSS 123456789 333445555 999887777 987654321 666884444 453453453 987987987 888665555 DATANASC 09-JAN-55 08-DEZ-45 19-JUL-58 20-JUN-31 15-SET-52 31-JUL-62 29-MAR-59 10-NOV-27 ENDEREO R. A, 1 R. B, 2 Av. C, 3 Trav. D, 4 R. E, 5 R. F, 6 Av G, 7 Av H, 8 SEXO M M F F M F M M SALARIO 3000 4000 2500 4300 3800 2500 2500 5500 NSSSUPER 333445555 888665555 987654321 888665555 333445555 333445555 987654321 null NDEP 5 5 4 4 5 5 4 1
DEPARTAMENTO DNOME DNMERO Pesquisa 5 Administrativo 4 Gerencial 1 LOCAIS_DEPTO DNMERO 1 4 5 5 5 PROJETO PNOME ProdutoX ProdutoY ProdutoZ Automao Reorganizao Beneficiamento
NSSGER 333445555 987654321 888665555
DATINICGER 22-MAI-78 01-JAN-85 19-JUN-71
DLOCALIZAO Houston Stafford Bellaire Sugariand Houston
PNMERO 1 2 3 10 20 30
PLOCALIZAO Bellaire Sugarland Houston Stafford Houston Stafford
DNUM 5 5 5 4 1 4
TRABALHA_EM NSSEMP PNRO 123456789 1 123456789 2 666884444 3 453453453 1 453453453 2 333445555 2 333445555 3 333445555 10 333445555 20 999887777 30 999887777 10 987987987 10 987987987 30 987654321 30 987654321 20 DEPENDENTE NSSEMP 333445555 333445555 333445555 987654321 123456789 123456789 123456789
HORAS 32.5 7.5 40.0 20.0 20.0 10.0 10.0 10.0 10.0 30.0 10.0 35.0 5.0 20.0 Null
NOMEDEPENDENTE Alice Theodore Joy Abner Michael Alice Elizabeth
SEXO F M F M M F F
DATANIV 05-ABR-76 25-OUT-73 03-MAI-48 29-FEV-78 01-JAN-78 31-DEZ-78 05-MAI-57
RELAO FILHA FILHO ESPOSA MARIDO FILHO FILHA ESPOSA
Figura 5.4 Instncias para a base de dados relacional COMPANHIA
43
Para definir formalmente a restrio de integridade referencial, h a necessidade de antes definir o conceito de chave-estrangeira (CE). As condies para uma chave-estrangeira, descritas abaixo, especificam uma restrio de integridade referencial entre duas relaes esquemas R1 e R2. Um conjunto de atributos CE na relao esquema R1 ser uma chaveestrangeira de R1 se ele satisfizer as seguintes regras: 1. Os atributos em CE tm o mesmo domnio dos atributos da chave-primria CP da outra relao esquema R2. Diz-se que os atributos CE referenciam ou referem-se relao R2. 2. Uma CE na tupla t1 ou tem um valor que ocorre como CP de alguma tupla t2 de R2 ou tem o valor null. No primeiro caso, tem-se t1[CE]=t2[CP], e diz-se que t1 referencia ou refere-se tupla t2. Uma base de dados tem muitas relaes, e usualmente possuem muitas restries de integridade referencial. Para especificar estas restries, o projetista deve ter um claro entendimento do significado ou papel que os atributos desempenham nas diversas relaes esquemas da base de dados. Normalmente, as restries de integridade referencial so derivadas dos relacionamentos entre entidades representadas pelas relaes esquemas. Por exemplo, considere a base de dados mostrada na 5.4. Na relao EMPREGADO, o atributo NDEP refere-se ao departamento em que cada empregado trabalha; desse modo, designa-se NDEP como a chave-estrangeira de EMPREGADO referenciando a relao DEPARTAMENTO. Isso significa que um valor de NDEP em alguma tupla t1 da relao EMPREGADO deve ter um valor correspondente para a chave-primria da relao DEPARTAMENTO - o atributo DNMERO - em alguma tupla t2 da relao DEPARTAMENTO ou o valor de NDEP pode ser null se o empregado no pertencer a nenhum departamento. Na Figura 5.4, a tupla do empregado "John Smith" referencia a tupla departamento de "Pesquisa", indicando que "John Smith" trabalha para este departamento. Note-se que uma chave-estrangeira pode referenciar sua prpria relao. Por exemplo, o atributo NSSSUPER em EMPREGADO refere-se ao supervisor de um empregado; isto , um outro empregado. Pode-se, diagramaticamente, mostrar as restries de integridade desenhando-se arcos direcionados partindo da chave-estrangeira para a relao referenciada. A Figura 5.5 ilustra o esquema apresentado na Figura 5.3 com as restries de integridade referencial anotadas desta maneira.
EMPREGADO
PNOME MNOME SNOME NSS DATANASC ENDEREO SEXO SALARIO NSSSUPER NDEP
DEPARTAMENTO
DNOME DNMERO NSSGER DATINICGER
LOCAIS_DEPTO
DNMERO DLOCALIZAO
PROJETO
PNOME PNMERO PLOCALIZAO DNUM
TRABALHA_EM
NSSEMP PNRO HORAS
DEPENDENTE
NSSEMP NOMEDEPENDENTE SEXO DATANIV RELAO
Figura 5.5 - Esquema COMPANHIA com restries de integridade
44
Todas as restries de integridade deveriam ser especificadas no esquema da base de dados relacional se o projetista tiver interesse em manter essas restries vlidas para toda a base de dados. Assim, em um sistema relacional, a linguagem de definio de dados (DDL) deveria fornecer recursos para especificar os vrios tipos de restries tal que o SGDB possa verificlas automaticamente. Muitos sistemas de gerenciamento de base de dados relacionais permitem restries de chave e de integridade de entidade mas, infelizmente, alguns no permitem a integridade referencial. Alm dos tipos de restries descritas acima, existem outras mais gerais, algumas vezes chamadas de restries de integridade semnticas, que podem ser especificadas e verificadas numa base de dados relacional. Exemplos de tais restries so "o salrio de um empregado no deve ultrapassar o salrio de seu supervisor" e "o nmero mximo de horas por semana que um empregado pode trabalhar num projeto 56". Tais restries no so verificadas por SGBD relacionais atualmente encontrados no mercado.
5.1.4 Operaes de Atualizaes sobre Relaes

Existem trs tipos bsicos de operao de atualizao sobre relaes - insero, remoo e modificao. A insero usada para inserir novas tuplas em uma relao, a remoo elimina tuplas e a modificao modifica os valores de alguns atributos. Quando so aplicadas operaes de atualizao, o projetista deve verificar que as restries de integridade especificadas no esquema da base de dados relacional no sejam violadas.
45
6 Mapeamento do MER para o Modelo de Dados Relacional

comum, em projetos de banco de dados realizarem a modelagem dos dados atravs de um modelo de dados de alto-nvel. Os produtos gerados por esse processo so os esquemas de vises que so posteriormente integradas para formar um nico esquema. O modelo de dados de alto-nvel normalmente adotado o Modelo Entidade-Relacionamento (MER) e o esquema das vises e de toda a base de dados so especificados em diagramas entidaderelacionamento (DER). O passo seguinte modelagem dos dados o mapeamento do diagrama da base de dados global, obtido na fase anterior, para um modelo de dados de implementao. Existem trs tipos de modelos de dados de implementao: hierrquico, rede e relacional. Para cada um desses modelos, pode-se definir estratgias de traduo a partir de um DER especfico. A estratgia de traduo, ou de mapeamento, tratada neste captulo para o modelo de dados relacional. Para isso, considere o esquema relacional mostrado na Figura 6.1 (semelhante Figura 5.5) que foi derivado do DER da Figura 4.11 seguindo um procedimento de mapeamento. Este procedimento apresentado passo-a-passo, a partir do exemplo do DER COMPANHIA.
EMPREGADO
PNOME MNOME SNOME NSS cp DATANASC ENDEREO SEXO SALARIO ce NSSSUPER ce DNUM
DEPARTAMENTO
DNOME DNMERO cp ce NSSGER * DATINICGER
LOCAIS_DEPTO
Ce DNMERO DLOCALIZAO \________________________/ Cp
PROJETO
PNOME PNMERO cp PLOCALIZAO ce DNUM
TRABALHA_EM
Ce ce PNRO NSSEMP \_______________/ Cp HORAS*
DEPENDENTE
Ce NOMEDEPENDENTE NSSEMP \___________________________/ Cp SEXO DATANIV RELAO
Figura 6.1 Modelo Relacional para o esquema COMPANHIA.
46
Passo 1: Para cada entidade regular E no DER, criar uma relao R que inclua todos os atributos simples de E. Para um atributo composto, inclua apenas os atributos simples que compem o atributo composto. Escolha um dos atributos-chave de E como sendo a chave-primria de R. Se a chave escolhida de E for composta, ento o conjunto de atributos simples que o compem iro formar a chave-primria de R. No exemplo, foram criadas as relaes EMPREGADO, DEPARTAMENTO e PROJETO correspondentes s entidades regulares EMPREGADO, DEPARTAMENTO e PROJETO presentes no DER. Os atributos indicados com ce (chave-estrangeira) ou * (atributos de relacionamento) no foram includos ainda; eles sero adicionados durante os passos subseqentes. Foram escolhidas as chavesprimrias NSS, DNMERO e PNMERO para as relaes EMPREGADO, DEPARTAMENTO e PROJETO respectivamente. Passo 2: Para cada tipo de entidade fraca W do DER com o tipo de entidade de identificao E, criar uma relao R e incluir todos os atributos simples (ou os componentes simples de atributos compostos) de W como atributos de R. Alm disso, incluir como a chave-estrangeira de R a chave-primria da relao que corresponde ao tipo de entidade de identificao; isto resolve o problema do tipo do relacionamento de identificao de W. A chave-primria de R a combinao da chave-primria do tipo de entidade de identificao e a chave-parcial do tipo de entidade fraca W. No exemplo, foi criada a relao DEPENDENTE correspondente ao tipo de entidade fraca DEPENDENTE do DER. Foi includa a chave-primria da relao EMPREGADO - que corresponde ao tipo de entidade de identificao - como um atributo de DEPENDENTE; foi renomeado o atributo NSS para NSSEMP, embora no seja necessrio. A chave-primria da relao DEPENDENTE a combinao {NSSEMP, NOMEDEPENDENTE} porque NOMEDEPENDENTE chave-parcial de DEPENDENTE. Passo 3: Para cada tipo de relacionamento binrio 1:1 R do DER, criar as relaes S e T que correspondem aos tipos de entidade participantes em R. Escolher uma das relaes, por exemplo S, que inclua como chave-estrangeira de S a chave-primria de T. melhor escolher o tipo de entidade com participao total em R como a relao S. Inclua todos os atributos simples (ou os componentes simples de atributos compostos) do tipo de relacionamento 1:1 R como atributos de S. No exemplo, foi mapeado o tipo de relacionamento 1:1 GERENCIA da Figura 4.10, escolhendo o tipo de entidade participante DEPARTAMENTO para fazer o papel de S porque sua participao no tipo de relacionamento GERENCIA total (todo departamento tem um gerente). Foi includa a chave-primria da relao EMPREGADO como a chave-estrangeira na relao DEPARTAMENTO que foi chamado de NSSGER . Tambm foi includo o atributo simples DataIncio do tipo de relacionamento GERENCIA na relao DEPARTAMENTO e foi renomeado como DATINICGER. Note-se que, uma alternativa para o mapeamento de um tipo de relacionamento 1:1 seria unir os dois tipos de entidades e o tipo de relacionamento numa nica relao. Isto particularmente apropriado quando ambas as participaes so total e quando os tipos de entidade no participam em quaisquer outros tipos de relacionamentos. Passo 4: Para cada tipo de relacionamento binrio regular 1:N (no fraca) R, identificar a relao S que representa o tipo de entidade que participa do lado N do tipo de relacionamento. Inclua como chave-estrangeira de S a chave-primria da relao T que representa o outro tipo de entidade que participa em R; isto porque cada instncia da entidade do lado 1 est relacionada a mais de uma instncia de entidade no lado N do tipo de relacionamento. Por exemplo, no tipo de relacionamento 1:N TRABALHA-PARA cada empregado est relacionado a um nico departamento. Inclua tambm quaisquer atributos simples (ou componentes simples de atributos compostos) do tipo de relacionamento 1:N como atributos de S.
47
No exemplo, foram mapeados os tipos de relacionamentos 1:N TRABALHA-PARA e SUPERVISIONA. Para TRABALHA-PARA incluiu-se a chave-primria da relao DEPARTAMENTO como a chave-estrangeira na relao EMPREGADO e foi chamado DNUM. Para SUPERVISIONA incluiu-se a chave-primria da relao EMPREGADO como a chave-estrangeira na relao EMPREGADO e foi denominado NSSSUPER. O relacionamento CONTROLA mapeado da mesma maneira. Passo 5: Para cada tipo de relacionamento binrio M:N R, criar uma nova relao S para representar R. Incluir como chave-estrangeira em S as chaves-primrias das relaes que representam os tipos de entidade participantes; sua combinao ir formar a chave-primria de S. Inclua tambm qualquer atributo simples do tipo de relacionamento M:N (ou componentes simples dos atributos compostos) como atributos de S. Note-se que no se pode representar um tipo de relacionamento M:N como uma simples chave-estrangeira em uma das relaes participantes - como foi feito para os tipos de relacionamentos 1:1 e 1:N - por causa da razo de cardinalidade M:N. Relacionamentos M:N sempre derivam uma nova relao, para o tipo relacionamento. No exemplo foi mapeado o tipo de relacionamento M:N TRABALHA-EM criando-se a relao TRABALHA_EM na Figura 4.6. Incluiu-se as chaves-primrias das relaes PROJETO e EMPREGADO como chaves-estrangeiras em TRABALHA_EM e foi renomeado NSS para NSSEMP e Nmero para PNRO respectivamente. Tambm foi includo um atributo HORAS para representar o atributo Horas do tipo de relacionamento. A chave-primria da relao TRABALHA_EM a combinao das chaves-estrangeiras {NSSEMP, PNRO}. Note-se que sempre possvel mapear relacionamentos 1:1 ou 1:N da mesma maneira que os relacionamentos M:N. Esta alternativa pode ser adotada desde que existam poucas instncias de relacionamento a fim de evitar valores null em chavesestrangeiras, ou em casos em que cardinalidade ir ser futuramente modificada de 1:1 ou 1:N para M:N. Passo 6: Para cada atributo A multivalorado, criar uma nova relao R que inclua um atributo correspondendo a A e a chave-primria K da relao que representa o tipo de entidade ou o tipo de relacionamento que tem A como atributo. A chave-primria de R a combinao de A e K. Se o atributo multivalorado composto inclua os atributos simples que o compem. No exemplo foi criada a relao LOCAIS_DEPTO. O atributo DLOCALIZAO representa o atributo multivalorado Localizao de DEPARTAMENTO, enquanto DNMERO - como chave-estrangeira - representa a chave-primria da relao DEPARTAMENTO. A chave-primria de LOCAIS_DEPTO a combinao de {DNMERO, DLOCALIZAO}. Uma tupla ir existir em LOCAIS_DEPTO para cada localizao que um departamento tiver. A Figura 6.1 mostra o esquema da base de dados relacional obtida aplicando-se os passos acima, e a Figura 5.4 mostra uma instncia deste esquema. Observa-se que no foi discutido o mapeamento de tipos de relacionamento n-rio (n > 2) porque no existem na Figura 4.10. Estes tipos de relacionamentos podem ser mapeados da mesma forma que os tipos de relacionamentos M:N, apenas observando o seguinte passo adicional no procedimento de mapeamento. Passo 7: Para cada tipo de relacionamento n-rio R, n>2, criar uma nova relao S para representar R. Inclua como chave-estrangeira em S as chaves-primrias das relaes que representam os tipos de entidades participantes. Incluindo-se tambm qualquer atributo simples do tipo de relacionamento n-rio (ou componentes simples dos atributos compostos) como atributo de S. A chave-primria de S normalmente uma combinao de todas as chaves-estrangeiras e referencia as relaes que representam os tipos de entidades participantes. Porm, se a restrio de
48
participao (min, max) de um dos tipos de entidades E que participa em R tiver max=1, ento a chave-primria de S pode ser a chave-estrangeira que referencia a relao E' correspondente a E; isto porque cada entidade e em E ir participar em apenas uma instncia de R e, portanto, pode identificar univocamente esta instncia de relacionamento. Por exemplo, considere o tipo de relacionamento da Figura 4.13a. Este relacionamento triplo pode ser mapeado para a relao FORNECE mostrada na Figura 6.2, onde a chave-primria a combinao das chaves-estrangeiras {FNOME, PNOME, NMERO}.
FORNECEDOR
FNOME
...
PROJETO
PNOME
...
PEA
NMERO
...
FORNECE
FNOME PNOME NMERO
QUANTIDADE
Figura 6.2 Exemplo de mapeamento de um relacionamento ternrio.

O principal ponto que deve ser considerado em um esquema relacional, quando comparado ao esquema do MER, que os tipos de relacionamento no so representados explicitamente; eles so representados por dois atributos A e B, um para a chave-primria e outra para a chave-estrangeira sobre o mesmo domnio includos em duas relaes S e T. Duas tuplas em S e T esto relacionadas quando elas tiverem o mesmo valor para A e B, ou seja, os relacionamentos so definidos pelos valores dos atributos A e B.
49
7 Linguagens Formais de Consulta

7.1 lgebra Relacional
As discusses anteriores sobre o modelo relacional contemplaram apenas os aspectos estruturais. Agora, a ateno ser voltada para a lgebra relacional, que uma coleo de operaes utilizadas para manipular relaes. Essas operaes so usadas para selecionar tuplas de uma determinada relao ou para combinar tuplas relacionadas a diversas relaes com o propsito de especificar uma consulta - uma requisio de recuperao - sobre a base de dados. As operaes da lgebra relacional so normalmente divididas em dois grupos. O primeiro deles inclui um conjunto de operaes da teoria de conjuntos. As operaes so UNION, INTERSECTION, DIFFERENCE e CARTESIAN PRODUCT. O segundo grupo consiste de operaes desenvolvidas especificamente para bases de dados relacionais, tais como: SELECT, PROJECT e JOIN entre outras.
7.1.1 Operaes SELECT e PROJECT
7.1.1.1 O Operador SELECT

A operao SELECT usada para selecionar um subconjunto de tuplas de uma relao as quais devem satisfazer uma condio de seleo. Por exemplo, a seleo de um subconjunto de tuplas da relao EMPREGADOS que trabalham para o departamento 4 ou que tenham salrio maior que 3000. Cada uma dessas condies especificada individualmente usando a operao SELECT como segue:
NDEP = 4 (EMPREGADO) SALRIO > 3000 (EMPREGADO)

Em geral, a operao SELECT denotada por:
<condio de seleo> (<nome da relao>)

onde o smbolo usado para denotar o operador SELECT e a condio de seleo uma expresso Booleana especificada sobre atributos da relao especificada. A relao resultante da operao SELECT tem os mesmos atributos da relao especificada em <nome da relao>. A expresso booleana especificada em <condio de seleo> construda a partir de clusulas da forma: <nome de atributo> <operador de comparao> <valor constante>, ou <nome de atributo> <operador de comparao> <nome de atributo> Onde <nome de atributo> o nome de um atributo da <nome da relao>, <operador de comparao> normalmente um dos operadores relacionais {=,<,>, ...} <valor constante> um valor constante. As clusulas podem ser utilizadas em conjunto com os operadores lgicos {AND, OR NOT} para formar uma condio de seleo composta. Por exemplo, suponha que se deseja selecionar as tuplas de todos os empregados que ou trabalham no departamento 4
50
com salrio superior a R$2.500,00 ou trabalham no departamento 5 e ganham mais que R$3.000,00. Neste caso, pode-se especificar a consulta da seguinte forma:
(NDEP = 4 AND SALRIO > 2500) OR (NDEP = 5 AND SALRIO > 3000) (EMPREGADO)
O resultado mostrado na Figura 7.1a.
(a) PNOME Franklin Jennifer Ramesh MNOME T S K SNOME Wong Wallace Narayan NSS 333445555 987654321 666884444 DATANASC 08-DEZ-45 20-JUN-31 15-SET-52 ENDEREO R. B, 2 Trav. D, 4 R. E, 5 SEXO M F M SALARIO 4000 4300 3800 NSSSUPER 888665555 888665555 333445555 NDEP 5 4 5
(b)
SNOME Smith Wong Zelaya Wallace Narayan English Jabbar Borg
PNOME John Franklin Alcia Jennifer Ramesh Joyce Ahmad James
SALARIO 3000 4000 2500 4300 3800 2500 2500 5500
(c)
SEXO M M F F M M M
SALARIO 3000 4000 2500 4300 3800 2500 5500
Figura 7.1 Exemplo de utilizao do operador SELECT

O operador SELECT unrio; isto , ele aplicado somente a uma relao. Assim, o SELECT no pode ser usado para selecionar tuplas de mais de uma relao. Observe tambm que a operao de seleo aplicada individualmente para cada tupla. Assim, as condies de seleo no podem ser aplicadas a mais que uma tupla. O grau da relao resultante a mesma que a relao original. O nmero de tuplas da relao resultante sempre menor ou igual ao nmero de tuplas da relao original. Note que o operador SELECT comutativo; isto ,
<cond1> ( <cond2> (R))= <cond2> (<cond1> (R))

Assim, uma seqncia de SELECTs pode ser aplicada em qualquer ordem. Alm disso, podese sempre trocar operadores SELECT em cascata com a conjuntiva AND; isto :
<cond1> ( <cond2> (...( <condn> (R))...))= <cond1> AND <cond2> AND ... AND <condn>(R)
7.1.1.2 O Operador PROJECT

Pensando na relao como uma tabela, o operador SELECT seleciona algumas linhas da tabela enquanto descarta outras. O operador PROJECT, por outro lado, seleciona certas colunas da tabela e descarta outras. Se existir o interesse sobre certos atributos da relao, pode-se usar o PROJECT para projetar a relao sobre esses atributos. Por exemplo, suponha a necessidade de listar, para cada empregado, os atributos PNOME, SNOME e SALRIO; ento pode-se usar o PROJECT como segue:
SNOME, PNOME, SALRIO (EMPREGADO)

A relao resultante mostrada na Figura 7.1b. A forma geral do operador PROJECT :
<lista de atributos>
(<nome da relao>)
51
onde o smbolo usado para representar o operador PROJECT e <lista de atributos> uma lista de atributos da relao especificada por <nome da relao>. A relao resultante tem apenas os atributos especificados em <lista de atributos> e estes atributos aparecem na mesma ordem em que foram especificados. Assim, o grau igual ao nmero de atributos em <lista de atributos>. Convm salientar que, caso a lista de atributos no contenha atributos chaves, ento provvel que tuplas duplicadas apaream no resultado. A operao PROJECT remove implicitamente quaisquer tuplas duplicadas, tal que o resultado da operao PROJECT seja um conjunto de tuplas e assim, uma relao vlida. Por exemplo, considere a seguinte operao:
SEXO, SALRIO (EMPREGADO)

O resultado mostrado na Figura 7.1c, onde a tupla <F, 2500> aparece apenas uma vez, mesmo que esta combinao de valores aparea duas vezes na relao EMPREGADO. Dessa maneira, se duas ou mais tuplas idnticas aparecerem quando aplicada a operao PROJECT, apenas uma ser mantida no resultado; isto conhecido como eliminao de duplicidade e necessrio para assegurar que o resultado da operao tambm seja uma relao - um conjunto de tuplas. O nmero de tuplas na relao resultante sempre ser igual ou menor que a quantidade de tuplas na relao original. Note-se que:
<lista1> ( <lista2> (R)) = <lista1> (R)

caso <lista2> contenha os atributos de <lista1>; caso contrrio, o lado esquerdo da igualdade acima estar incorreto. A comutatividade no vlida para PROJECT.
7.1.2 Seqncia de Operaes

As relaes mostradas na Figura 7.1 no possuem nomes. Em geral, existe a necessidade de se aplicar vrias operaes da lgebra relacional uma aps a outra. Pode-se escrever essas operaes em apenas uma nica expresso da lgebra relacional ou aplicar uma nica operao por vez e criar relaes intermedirias. Neste ltimo caso, deve-se dar nomes s relaes intermedirias. Por exemplo, deseja-se recuperar o primeiro nome, o ltimo nome e o salrio de todos os empregados que trabalham no departamento 5. Isto pode ser feito aplicando-se os operadores SELECT e PROJECT:
PNOME, SNOME, SALRIO ( NDEP=5 (EMPREGADO))

A Figura 7.2a mostra o resultado desta expresso da lgebra relacional. Alternativamente, pode-se explicitar a seqncia de operaes, dando um nome para cada relao intermediria: DEP5_EMPS RESULT
NDEP=5 (EMPREGADO)
PNOME, SNOME, SALRIO
(DEP5_EMPS)
52
(a)
PNOME John Franklin Alcia Jennifer Ramesh Joyce Ahmad James
SNOME Smith Wong Zelaya Wallace Narayan English Jabbar Borg
SALRIO 3000 4000 2500 4300 3800 2500 2500 5500
DEP5_EMPS (b)
PNOME John Franklin Ramesh Joyce
MNOME B T K A
SNOME Smith Wong Narayan English
NSS 123456789 333445555 666884444 453453453
DATANASC 09-JAN-55 08-DEZ-45 15-SET-52 31-JUL-62
ENDEREO R. A, 1 R. B, 2 R. E, 5 R. F, 6
SEXO M M M F
SALRIO 3000 4000 3800 2500
NSSSUPER 333445555 888665555 333445555 333445555
NDEP 5 5 5 5
RESULT PRIMEIRO_NOME John Franklin Ramesh Joyce SOBRENOME Smith Wong Narayan English SALRIO 3000 4000 3800 2500
Figura 7.2 Exemplo de execuo de uma expresso da lgebra Relacional 7.1.3 Renomeando Atributos
Normalmente, mais simples dividir uma seqncia de operaes especificando as relaes intermedirias ao invs de escrever uma nica expresso da lgebra relacional. Pode-se, tambm, utilizar a tcnica de renomear atributos nas relaes intermedirias. Para renomear atributos de uma relao, que resultou da aplicao de uma operao da lgebra relacional, basta listar os nomes dos atributos entre parnteses: DEP5_EMPS
NDEP=5 (EMPREGADO) PNOME, SNOME, SALRIO
RESULT(PRIMEIRO_NOME, SOBRENOME, SALRIO)
(DEP5_EMPS)
Os resultados das duas operaes acima so ilustrados na Figura 7.2b.
7.1.4 Operaes da Teoria dos Conjuntos

O prximo grupo de operaes da lgebra relacional so as operaes matemticas padres sobre conjuntos. Elas se aplicam ao modelo relacional porque uma relao definida como um conjunto de tuplas. Por exemplo, suponha a necessidade de se recuperar o nmero do seguro social de todos os empregados que trabalham no departamento 5 ou, diretamente supervisione um empregado que trabalha no departamento 5. Esta operao pode ser realizada usando o operador UNION. DEP5_EMPS RESULT1
NSS NDEP=5 (EMPREGADO)
(DEP5_EMPS)
NSSSUPER
RESULT2(NSS)
(DEP5_EMPS)
RESULTRESULT1 RESULT2 A relao RESULT1 contm o nmero do seguro social de todos os empregados que trabalham no departamento 5. RESULT2 contm o nmero do seguro social de todos os empregados que diretamente supervisionam empregados que trabalham no departamento 5. A
53
operao UNION gera uma relao que contm tanto as tuplas de RESULT1 quanto de RESULT2. A Figura 7.3 ilustra este exemplo.
RESULT1 NSS 123456789 333445555 666884444 453453453 RESULT2 NSS 333445555 888665555 RESULT NSS 123456789 333445555 666884444 453453453 888665555
Figura 7.3 Exemplo de aplicao do operador UNION.

Existem vrias operaes da teoria de conjuntos que so utilizadas para agrupar elementos de dois conjuntos, entre elas esto: UNION, INTERSECTION e DIFFERENCE. Estas operaes so binrias; isto , elas necessitam de dois conjuntos. Quando essas operaes so adaptadas para a base de dados relacional, deve-se assegurar que essas operaes resultem sempre em relaes vlidas. Para conseguir isso, as duas relaes aplicadas a qualquer uma das trs operaes acima devem ter o mesmo tipo de tuplas; esta condio chamada unio compatvel. Duas relaes R(A1, A2, ..., An) e S(B1, B2, ..., Bn) so unio compatvel se elas tiverem o mesmo grau n, e dom(Ai)=dom(Bi) para 1 i n. Isso significa que as duas relaes tm o mesmo nmero de atributos e que cada par de atributos correspondentes tem o mesmo domnio. Pode-se definir as trs operaes UNION, INTERSECTION e DIFFERENCE sobre duas relaes que sejam unio compatvel R e S: UNION O resultado da operao, denotado por R S, uma relao que inclui todas as tuplas de R e todas as tuplas de S. Tuplas duplicadas so eliminadas. INTERSECTION O resultado desta operao, denotado por R S, a relao que inclui todas as tuplas que so comuns a R e S. DIFFERENCE O resultado desta operao, denotado por R - S, a relao que inclui todas as tuplas de R, mas que no esto em S.
Note que as operaes UNION e INTERSECTION so operaes comutativas:
R S = S R, e R S = S R.
Estas operaes podem ser aplicadas a qualquer nmero de relaes, e ambas so associativas: R (S T) = (R S) T, e R (S T) = (R S) T.
A operao DIFFERENCE no comutativa: R - S S - R. A operao CARTESIAN PRODUCT, denotada por , tambm uma operao de conjunto binria, mas as relaes sobre as quais so aplicadas no necessitam ser unio compatvel. Esta operao usada para combinar tuplas de duas relaes tal que tuplas relacionadas possam ser identificadas. Em geral, o resultado de R(A1, A2, ..., An) S(B1, B2, ..., Bm) a relao Q com n + m atributos Q(A1, A2, ..., An, B1, B2, ..., Bm) nesta ordem. A relao resultante Q tem uma tupla para cada
combinao de tuplas. Assim, se R tem nR tuplas e S tem nS tuplas, ento RS ter nR*nS tuplas. Para ilustrar, considere que se deseja recuperar para cada empregado do sexo feminino uma lista de nomes de seus dependentes; isso pode ser feito da seguinte forma:

EMP_FEMSEXO='F' (EMPREGADO) EMP_NOMESPNOME, SNOME, NSS (EMP_FEM) EMP_DEPEMP_NOMES DEPENDENTE DEP_ATUALNSS=NSSEMP (EMP_DEP)
54
RESULTPNOME, SNOME, NOMEDEPENDENTE(DEP_ATUAL) As tuplas geradas a partir da seqncia de operaes acima so mostradas na Figura 7.4. A relao EMP_DEP o resultado da operao CARTESIAN PRODUCT entre EMP_NOMES da Figura 7.4, e DEPENDENTE da Figura 5.4. Em EMP_DEP, cada tupla de EMP_NOMES combinada com todas as tuplas de DEPENDENTE, gerando um resultado que no tem muito significado. Deseja-se apenas combinar tuplas de empregado feminino com seus dependentes, o que significa dizer: tuplas de DEPENDENTES onde os valores de NSSEMP so iguais aos valores de NSS de EMPREGADO. Em DEP_ATUAL, foi obtido isto. O CARTESIAN PRODUCT cria tuplas com atributos combinados de duas relaes. Pode-se ento selecionar apenas as tuplas que estejam relacionadas especificando uma condio de seleo apropriada, como foi feita no exemplo. Devido seqncia: CARTESIAN PRODUCT seguido de SELECT, ser muito comum para se identificar tuplas relacionadas de duas relaes, uma operao especial JOIN foi criada para especificar esta seqncia como uma nica operao. Assim, a operao CARTESIAN PRODUCT raramente utilizada isoladamente.
EMP_FEM PNOME Alicia Jennifer Joyce
MNOME J S A
SNOME Zelaya Wallace English
NSS 999887777 987654321 453453453
DATANASC 19-JUL-58 20-JUN-31 31-JUL-62
ENDEREO Av. C, 3 Trav. D, 4 R. F, 6
SEXO F F F
SALARIO 2500 4300 2500
NSSSUPER 987654321 888665555 333445555
NDEP 4 4 5
EMP_NOMES PNOME SNOME Alicia Zelaya Jennifer Wallace Joyce English EMP_DEP PNOME Alicia Alicia Alicia Alicia Alicia Alicia Alicia Jennifer Jennifer Jennifer Jennifer Jennifer Jennifer Jennifer Joyce Joyce Joyce Joyce Joyce Joyce Joyce
NSS 999887777 987654321 453453453
SNOME Zelaya Zelaya Zelaya Zelaya Zelaya Zelaya Zelaya Wallace Wallace Wallace Wallace Wallace Wallace Wallace English English English English English English English
NSS 999887777 999887777 999887777 999887777 999887777 999887777 999887777 987654321 987654321 987654321 987654321 987654321 987654321 987654321 453453453 453453453 453453453 453453453 453453453 453453453 453453453
NSSEMP 333445555 333445555 333445555 987654321 123456789 123456789 123456789 333445555 333445555 333445555 987654321 123456789 123456789 123456789 333445555 333445555 333445555 987654321 123456789 123456789 123456789
NOMEDEPENDENTE Alice Theodore Joy Abner Michael Alice Elizabeth Alice Theodore Joy Abner Michael Alice Elizabeth Alice Theodore Joy Abner Michael Alice Elizabeth
SEXO F M F M M F F F M F M M F F F M F M M F F
DATANIV 05-ABR-76 25-OUT-73 03-MAI-48 29-FEV-78 01-JAN-78 31-DEZ-78 05-MAI-57 05-ABR-76 25-OUT-73 03-MAI-48 29-FEV-78 01-JAN-78 31-DEZ-78 05-MAI-57 05-ABR-76 25-OUT-73 03-MAI-48 29-FEV-78 01-JAN-78 31-DEZ-78 05-MAI-57
RELAO FILHA FILHO ESPOSA MARIDO FILHO FILHA ESPOSA FILHA FILHO ESPOSA MARIDO FILHO FILHA ESPOSA FILHA FILHO ESPOSA MARIDO FILHO FILHA ESPOSA
DEP_ATUAL PNOME SNOME Jennifer Wallace RESULT PNOME Jennifer
NSS 987654321
NSSEMP 987654321
NOMEDEPENDENTE Abner
SEXO M
DATANIV 29-FEV-78
RELAO MARIDO
SNOME Wallace
NOMEDEPENDENTE Abner
Figura 7.4 Resultado da aplicao de uma operao de produto cartesiano
Introduo a Banco de Dados 7.1.5 A Operao JOIN
55
A operao JOIN, denotada por , usada para combinar tuplas relacionadas de relaes em uma nica tupla. Esta operao muito importante para quaisquer bases de dados relacionais, pois permite processar relacionamentos entre relaes. Para ilustrar a operao JOIN, suponha que se deseja recuperar os nomes dos gerentes de cada departamento. Para obter-se o nome dos gerentes, necessrio combinar cada tupla de departamento com tuplas de empregados cujo valor NSS seja igual ao valor de NSSGER na tupla departamento. Isto feito usando a operao JOIN, ento projeta-se o resultado sobre aqueles atributos necessrios: DEPT_GERDEPARTAMENTO NSSGER=NSS EMPREGADO
RESULTDNOME, SNOME, PNOME (DEPT_GER)
O resultado da primeira operao mostrado na Figura 7.5. O exemplo utilizado para ilustrar o CARTESIAN PRODUCT pode ser especificado usando o operador JOIN trocando as duas operaes: EMP_DEPEMP_NOMES DEPENDENTE DEP_ATUALNSS=NSSEMP (EMP_DEP) por DEP_ATUALEMP_NOME NSS=NSSEMP DEPENDENTE
DEPT_GER DNOME Pesquisa Administrativo Gerencial
DNMERO 5 4 1
NSSGER 333445555 987654321 888665555
... ... ... ...
PNOME Franklin Jennifer James
MNOME T S E
SNOME Wong Wallace Borg
NSS 333445555 987654321 888665555
... ... ... ...
Figura 7.5 Resultado da execuo de um operador de juno

A forma geral da operao JOIN sobre duas relaes R(A1, A2, ..., An) e S(B1, B2, ..., Bm) :
R <condio join> S.
O resultado de JOIN uma relao Q com n+m atributos Q(A1, A2, ..., An, B1, B2, ..., Bm) nesta ordem; Q tem um tupla para cada combinao de tuplas uma de R e uma de S onde quer que a combinao satisfaa a condio join. Esta a principal diferena entre CARTESIAN PRODUCT e JOIN; em JOIN, apenas combinaes de tuplas que satisfazem a condio join que aparecer no resultado, j no CARTESIAN PRODUCT, todas as combinaes de tuplas so includas no resultado. A condio join especificada sobre atributos de R e de S, e avaliada para cada combinao de tuplas. Uma condio join tem a forma: <condio> AND <condio> AND,...,OR, ..., AND <condio> onde cada condio da forma Ai Bj, Ai um atributo de R, Bj um atributo de S, Ai e Bj tm
o mesmo domnio e um dos operadores de comparao { =, <, , >, , }. Uma operao JOIN de condio especificada denominada THETA JOIN. Tuplas cujos valores dos atributos join so null no aparecem no resultado. muito comum encontrar JOIN que envolva condies joins com apenas a comparao de igualdade. Um JOIN, onde apenas o operador de comparao = utilizado chamado EQUIJOIN. Os dois exemplos anteriores eram EQUIJOIN. Note-se, que no resultado de uma EQUIJOIN sempre ter um ou mais pares de atributos que tem valores idnticos em todas as tuplas. Por exemplo, na Figura 7.5 os valores dos atributos NSSGER e NSS so idnticos em todas as tuplas de DEPT_GER porque condio join de igualdade especificada sobre estes
56
atributos. Devido a esta duplicao ser desnecessria, uma nova operao chamada NATURAL JOIN foi criada. Denota-se o join natural por *, que basicamente um equijoin seguido da remoo de atributos desnecessrios. Um exemplo : PROJ_DEPTPROJETO *
DNUM=DNMERO
DEPARTAMENTO
Os atributos DNUM e DNMERO so chamados atributos de unio. A relao resultante mostrada na Figura 7.6a. Na relao PROJ_DEPT, cada tupla combina uma tupla de PROJETO com a tupla de DEPARTAMENTO que controla o projeto. Na relao resultante, manteve-se apenas o primeiro atributo de unio. Devido s comparaes em uma condio join de um join natural serem sempre comparaes de igualdade, pode-se descartar o operador de comparao e apenas listar os atributos de unio como segue: PROJ_DEPTPROJETO * Assim, a forma geral de um NATURAL JOIN : QR *
(<lista1>),(<lista2>) (DNUM), (DNMERO)
DEPARTAMENTO
Neste caso, <lista1> especifica uma lista de i atributos de R e <lista2> especifica uma lista de i atributos de S. Apenas os atributos da primeira relao R <lista1> sero mantidos na relao resultante Q. Se os atributos sobre os quais o join natural especificado tiverem os mesmos nomes em ambas relaes, pode-se tirar a condio join totalmente. Por exemplo, para aplicar um join natural sobre DNMERO de DEPARTAMENTO e LOCAIS_DEPTO, suficiente escrever: DEPT_LOCSDEPARTAMENTO * LOCAIS_DEPTO A relao resultante mostrada na Figura 7.6b, que combina cada departamento com suas localizaes e tem uma tupla para cada localizao. Esta operao executada igualando-se todos os pares de atributos que tenham o mesmo nome nas duas relaes. Note que, se nenhuma combinao de tuplas satisfizer a condio join, ento o resultado ser uma relao vazia. Em geral, se R tiver nR tuplas e S tiver nS tuplas, o resultado de uma operao JOIN R <condio join> S ter entre zero e nR*nS tuplas. Se no existir <condio join> para satisfazer, ento todas as combinaes de tuplas sero includas. Nestes casos, JOIN torna-se um CARTESIAN PRODUCT.
PROJ_DEPT (a) PNOME ProdutoX ProdutoY ProdutoZ Automao Reorganizao Beneficiamento PNMERO 1 2 3 10 20 30 PLOCALIZAO Bellaire Sugarland Houston Stafford Houston Stafford DNUM 5 5 5 4 1 4 DNOME Pesquisa Pesquisa Pesquisa Administrativo Gerencial Administrativo NSSGER 333445555 333445555 333445555 987654321 888665555 987654321 DATINICGER 22-MAI-78 22-MAI-78 22-MAI-78 01-JAN-85 19-JUN-71 01-JAN-85
DEPT_LOCS (b) DNOME Gerencial Administrativo Pesquisa Pesquisa Pesquisa
DNMERO 1 4 5 5 5
NSSGER 888665555 987654321 333445555 333445555 333445555
DATINICGER 19-JUN-71 01-JAN-85 22-MAI-78 22-MAI-78 22-MAI-78
Figura 7.6 Resultado da execuo de um operador Natural Join.
57
7.1.6 Conjunto completo de Operaes da lgebra Relacional

Ser mostrado que o conjunto de operaes da lgebra relacional {, , , -, } um conjunto completo; isto , quaisquer outras operaes da lgebra relacional podem ser expressas como uma seqncia de operaes deste conjunto. Por exemplo, a operao de INTERSECTION pode ser expressa usando UNION e DIFFERENCE como segue: R S (R S)-((R - S) (S - R)) Embora, estritamente falando, a INTERSECTION, seja desnecessria, inconveniente especificar esta complexa expresso todas as vezes que for necessrio utilizar a interseo. Como um outro exemplo, uma operao JOIN pode ser especificada como uma CARTESIAN PRODUCT seguida pela operao SELECT como discutido anteriormente: R
<condio>
<condio>
(R S)
Similarmente, uma operao NATURAL JOIN pode ser especificada como um CARTESIAN PRODUCT seguida pelas operaes SELECT e PROJECT. Assim, as vrias formas de JOIN tambm no so estritamente necessrias para expressar o poder da lgebra relacional. No entanto, elas so muito convenientes assim como a operao INTERSECTION porque elas so utilizadas com freqncia pelas aplicaes de base de dados relacional. Outras operaes foram includas por convenincia. Ser discutida uma delas: DIVISION.
7.1.7 A Operao DIVISION

A operao DIVISION til para um tipo especial de consulta que ocorre freqentemente em aplicaes de base de dados. Esta requisio pode ser ilustrada pela seguinte consulta: "Recupere os nomes dos empregados que trabalham em todos os projetos em que 'John Smith' trabalha. Para expressar esta consulta usando DIVISION deve-se fazer o seguinte: primeiro recuperar a lista de nmeros de projetos em que 'John Smith' trabalha em uma relao intermediria SMITH_PNOS: SMITH
PNOME = 'John' AND SNOME = 'Smith' PNRO
(EMPREGADO)
NSSEMP = NSS
SMITH_PNOS
(TRABALHA_EM *
SMITH)
Depois, criar uma relao que inclua tuplas da forma <PNRO, NSSEMP> que lista todos os empregados, cujo nmero do seguro social NSSEMP, que trabalham num determinado projeto PNRO: NSS_PNRO PNRO, NSSEMP (TRABALHA_EM) Finalmente, aplicar a operao DIVISION para as relaes obtidas a fim de obter os nmeros dos seguros sociais desejados: NSS_DESEJADO(NSS)NSS_PNRO SMITH_PNOS RESULT PNOME, SNOME (NSS_DESEJADO * EMPREGADO) Os resultados das operaes acima so mostrados na Figura 7.7a. Em geral, a operao DIVISION aplicada para duas relaes R(Z) S(X), onde X Z. Seja Y=Z - X; isto , Y o conjunto de atributos de R que no so atributos de S. O resultado da diviso uma relao T(Y) que incluir uma tupla t se tR cujo tR[Y] = t aparecer em R com tR[X] = Ts para toda tupla tS em S. Isto significa que para uma tupla aparecer no resultado T da diviso, os valores em t devem aparecer em R em combinao com todas as tuplas de S.
58
A Figura 7.7b ilustra a utilizao da operao DIVISON onde R = Z = {A, B}, S = X = {A}, e T = Y = {B}; isto , X e Y so (ambos) atributos simples. A relao resultante T ter apenas um nico atributo B = Z - X. Note que b1 e b4 aparecem em R em combinao com todas as trs tuplas de S; por isso que eles aparecem na relao resultado T. Todos os outros valores de B em R no apareceram com todas as tuplas de S e no foram selecionados; b2 no aparece com a2; e b3 no aparece com a1. A operao de diviso pode ser expressa como uma seqncia de operaes , e -: T1Y (R) T2Y ((S T1) - R) TT1 - T2
(a)
NSS_PNRO NSSEMP 123456789 123456789 666884444 453453453 453453453 333445555 333445555 333445555 333445555 999887777 999887777 987987987 987987987 987654321 987654321 8886655555 PNRO 1 2 3 1 2 2 3 10 20 30 10 10 30 30 20 20 SMITH_PNO PNRO 1 2 NSS_DESEJADO NSS 123456789 453453453
(b)
R A a1 a2 a3 a4 a1 a3 a2 a3 a4 a1 a2 a3 B b1 b1 b1 b1 b2 b2 b3 b3 b3 b4 b4 b4 S A a1 a2 a3 T B b1 b4
Figura 7.7 Resultado da aplicao de um operador de diviso 7.1.8 Operaes Relacionais Adicionais
Existem algumas consultas comuns em bases de dados relacionais que no podem ser realizadas como as operaes da lgebra descritas na seo anterior. Muitas linguagens de consulta de SGBD possuem a capacidade de realizar essas consultas. Nesta seo sero discutidas algumas dessas consultas e define-se operaes adicionais que so usadas para expressar essas consultas.
7.1.9 Funes de Agregao

O primeiro tipo de consulta que no pode ser expressa na lgebra relacional conhecido como funes agregadas sobre colees de valores da base de dados. Por exemplo, pode-se querer recuperar a mdia ou total salarial de todos os empregados ou o nmero de tuplas de empregados. As funes normalmente aplicadas para colees de valores numricos so:
59
SUM, AVERAGE, MAXIMUM e MINIMUM. A funo de contagem de tuplas normalmente chamada COUNT. Cada uma destas funes pode ser aplicada a todas as tuplas de uma relao. Um outro tipo comum de consulta envolve o agrupamento de tuplas de uma relao pelo valor de alguns de seus atributos e ento a aplicao de alguma funo agregada independente para cada grupo de tuplas. Um exemplo o agrupamento de tuplas de empregados pelo NDEP. Pode-se ento listar, para cada NDEP a mdia salarial de empregados num determinado departamento. Pode-se definir uma operao FUNCTION, que pode ser usada para especificar estes tipos de consultas.
<atributos de agrupamento> <lista de funes> (<nome
da relao>)
onde <atributos de agrupamento> uma lista de atributos da relao especificada em <nome da relao> e <lista de funes> uma lista de pares (<funo><atributo>). Em cada par, <funo> uma das funes seguintes: SUM, AVERAGE, MAXIMUM, MINIMUM, COUNT, e <atributo> um atributo da relao especificada por <nome da relao>. A relao resultante tem tantos atributos quanto aqueles que existirem em atributos de agrupamento alm da lista de funes combinada. Por exemplo, para recuperar cada nmero de departamento, o nmero de empregados em departamento, e sua mdia salarial, escreve-se: R(DNO, NRO_EMPS, MDIA)NDEP
COUNT NSS, AVERAGE SALRIO (EMPREGADO)
O resultado desta operao mostrado na Figura 7.8a. No exemplo acima, foi especificada uma lista de nomes de atributos - entre parnteses - para a relao R. Se nenhuma lista tivesse sido especificada, ento os atributos da relao resultante teriam como o nome a concatenao do nome da funo com o nome do atributo especificado. Por exemplo, o resultado da seguinte operao mostrado na Figura 7.8b.
NDEP COUNT NSS, AVERAGE SALRIO (EMPREGADO)
Se nenhum atributo de agrupamento for especificado, as funes sero aplicadas para todos os valores de tuplas na relao, tal que a relao resultante ter uma nica tupla. Por exemplo, o resultado da seguinte operao mostrado na Figura 7.8
COUNT NSS, AVERAGE SALRIO (EMPREGADO)

importante destacar que o resultado da aplicao de qualquer funo de agregao sempre ser uma relao e no um nmero.
(a) R DNO 5 4 1 NRO_EMPS 4 3 1 MDIA 3325 3100 5500
(b) NDEP 5 4 1 COUNT_NSS 4 3 1 AVERAGE_SALRIO 3325 3100 5500
(c) COUNT_NSS 8 AVERAGE_SALRIO 3512.5
Figura 7.8 Exemplo de aplicao de funes de agregao
60
7.1.10 Operaes de Fechamento Recursivo (Clausura Recursiva)

Um outro tipo de operao que, em geral, no pode ser definido na lgebra relacional a fechamento recursivo. Esta operao aplicada em relacionamentos recursivos, como verificado no relacionamento entre empregado e supervisor. Este relacionamento descrito por uma chave-estrangeira NSSSUPER da relao empregado nas Figura 5.4 e 5.5, que relaciona cada tupla de empregado (no papel de supervisionado) a uma outra tupla empregado (no papel de supervisor). Um exemplo de uma operao recursiva recuperar todos os supervisionados de um empregado e em todos os nveis, isto , todos os empregados e' diretamente supervisionados por e, todos os empregados e'' diretamente supervisionados por e', todos os empregados e''' diretamente supervisionados por e'', e assim por diante. Embora seja simples especificar, na lgebra relacional, todos os empregados supervisionados por e num nvel especfico, difcil especificar todos os supervisionados em todos os nveis. Por exemplo, para especificar os NSSs de todos os empregados e' diretamente supervisionados no nvel um por e cujo nome 'James Borg' (veja Figura 5.4), pode-se aplicar as seguintes operaes: BORG_NSSNSS (
PNOME = 'James' AND SNOME = 'Borg' (EMPREGADO))
SUPERVISO(SNN1, SNN2)NSS, NSSSUPER (EMPREGADO) RESULT1SNN1 (SUPERVISO SNN2 = NSS BORG_NSS) Para recuperar todos os empregados supervisionados por Borg no nvel dois, isto , todos os empregados e'' supervisionados pelo empregado e' que diretamente supervisionado por Borg, pode-se aplicar um outro JOIN ao resultado da primeira consulta: RESULT2SNN1 (SUPERVISO SNN2 = NSS RESULT1) Para obter todos os empregados supervisionados nos nveis um e dois por 'James Borg', podese aplicar a operao UNION como segue: RESULT3(RESULT1 RESULT2) Embora seja possvel recuperar os empregados supervisionados em cada nvel, no possvel especificar uma consulta tal como " recupere todos os supervisionados de 'James Borg' em todos os nveis" se no for conhecido o nmero mximo de nveis.
7.2
Exemplos de Consultas na lgebra Relacional
Nesta seo sero apresentados exemplos para ilustrar o uso das operaes da lgebra relacional. Todos os exemplos referem-se base de dados da Figura 5.4. Em geral, a mesma consulta pode ser realizada de vrias maneiras usando diferentes operadores relacionais. Consulta 1: Encontrar o nome e o endereo de todos os empregados que trabalham para o departamento 'Pesquisa'. PESQUISA_DEPTO DNOME = 'Pesquisa' (DEPARTAMENTO) PESQUISA_DEPTO_EMPS(PESQUISA_DEPTO DNMERO = NDEP EMPREGADO) RESULT
PNOME, SNOME, ENDEREO
(PESQUISA_DEPTO_EMPS)
61
Esta consulta poderia ser especificada de outra maneira; por exemplo, a ordem das operaes JOIN e SELECT poderia ser invertida ou o JOIN poderia ser trocado pelo NATURAL JOIN. Consulta 2: Para todo projeto localizado em 'Stafford', listar o nmero do projeto, o nmero do departamento responsvel, e o sobrenome, endereo e data de nascimento do gerente responsvel pelo departamento. STAFFORD_PROJS
PLOCALIZAO = 'Stafford'
(PROJETO) DEPARTAMENTO) EMPREGADO)
CONTR_DEPT(STAFFORD_PROJS PROJ_DEPT_MGR(CONTR_DEPT RESULT
DNUM = DNMERO
SSNGER = NSS
PNMERO, DNUM, SNOME, ENDEREO, DATANASC (PROJ_DEPT_MGR)
Consulta 3: Encontrar os nomes de empregados que trabalham em todos os projetos controlados pelo departamento 5. DEPT5_PROJS(PNO)
PNMERO
( DNUM=5 (PROJETO)))
EMP_PROJ(NSS, PNO) NSSEMP, PNRO (TRABALHA_EM) RESULT_EMP_SSNSEMP_PROJ DEPT5_PROJS RESULT SNOME, PNOME (RESULT_EMP_SSNS * EMPREGADO) Consulta 4: Fazer uma lista de nmeros de projetos no qual um empregado, cujo sobrenome 'Smith' , trabalha no projeto ou gerente do departamento que controla o projeto.
( SNOME='Smith' (EMPREGADO)) SMITH_WORKER_PROJS PNRO (TRABALHA_EM * SMITH) MGRS SNOME, DNMERO (EMPREGADO NSS = NSSGER DEPARTAMENTO) SMITH_MGS SNOME = 'Smith' (MGRS) SMITH_MANAGED_DEPTS(DNUM) DNMERO (SMITH_MGRS) SMITH_MGR_PROJS(PNRO) PNMERO (SMITH_MANAGED_DEPTS * PROJETO) RESULT(SMITH_WORKER_PROJS SMITH_MGR_PROJS)
NSS
SMITH(NSSEMP)
Consulta 5: Listar os nomes de todos os empregados com dois ou mais dependentes. Esta consulta no pode ser realizada usando apenas a lgebra relacional. Devese utilizar a operao FUNCTION com a funo de agregao COUNT, que no da lgebra relacional. Nas formulaes que se seguiro, assume-se que dependentes de um mesmo empregado possuem nomes distintos. T1(NSS, NO_DE_DEPS)NSSEMP T2
NO_DE_DEPS >= 2 COUNT NOMEDEPENDENTE
(DEPENDENTE)
(T1) (T2 * EMPREGADO)
RESULT
SNOME, PNOME
Consulta 6: Listar os nomes dos empregados que no possuem dependentes. TODOS_EMPS

NSS (EMPREGADO)
EMPS_COM_DEPS(NSS) NSSEMP (DEPENDENTE) EMPS_SEM_DEPS(TODOS_EMPS - EMPS_COM_DEPS) RESULT SNOME, PNOME (EMPS_SEM_DEPS * EMPREGADO)
62
Consulta 7: Listar os nomes dos gerentes que tm ao menos um dependente. MGRS(NSS)

NSSGER (DEPARTAMENTO) NSSEMP (DEPENDENTE)
EMPS_COM_DEPS(NSS)
MGRS_COM_DEPS(MGRS EMPS_COM_DEPS) RESULT SNOME, PNOME (MGRS_COM_DEPS * EMPREGADO)
7.3
1. 2. 3. 4.
Questes de Reviso
O que unio compatvel? Por que as operaes UNION, INTERSECTION e DIFFERENCE so operaes que necessitam que as relaes sejam: unio compatvel? Discuta algumas das consultas onde seja necessrio renomear atributos a fim de especificar consultas no ambguas. Discuta os vrios tipos de operaes JOIN. Resuma em forma de tabela que contenha o nome da operao, o propsito da operao e a notao. Especifique as seguintes consultas sobre a base de dados mostrada na Figura 5.3 usando operaes relacionais discutidas neste captulo. Mostra tambm os resultados de cada consulta se aplicada base de dados da Figura 5.4. a) b) c) d) e) f) g) h) i) Recuperar os nomes de empregados do departamento 5 que trabalham mais que 10 horas no projeto 'ProdutoX'. Listar os nomes dos empregados que tenham um dependente com o mesmo nome (PNOME). Encontrar os nomes de empregados que so diretamente supervisionados por 'Franklin Wong'. Para cada projeto, listar o nome do projeto e o total de horas (de todos os empregados) gastos em cada projeto. Recuperar os nomes dos empregados que trabalham em todos os projetos. Recuperar os nomes dos empregados que no trabalham em quaisquer projetos. Para cada departamento, recuperar o nome do departamento e a mdia salarial dos empregados que trabalham no departamento. Recuperar a mdia salarial de todos os empregados femininos. Encontrar os nomes e endereos de empregados que trabalham em ao menos um projeto localizado em Houston mas cujo departamento no possua localizao em Houston. Listar os sobrenomes dos gerentes de departamentos que no tenham dependentes. Generalize a consulta i) acima para listar os nomes e endereos de empregados que trabalham em um projeto em alguma cidade , mas que o departamento no tenha nenhuma localizao nessa cidade.
j) k)
63
7.4
Clculo Relacional
O Clculo Relacional (CR) uma linguagem de consulta formal onde, por meio de uma expresso declarativa, pode-se especificar uma solicitao de recuperao. No h nenhuma restrio na forma de avaliar uma solicitao. Uma expresso de clculo permite a descrio da consulta desejada sem especificar os procedimentos para obteno dessas informaes, ou seja, no-procedural. Contudo, deve ser capaz de descrever formalmente a informao desejada, com exatido. Existem dois tipos: Clculo Relacional de Tuplas (CRT) e Clculo Relacional de Domnio (CRD), ambos subconjuntos simples de lgica de primeira ordem. No Clculo Relacional existem variveis, constantes, operadores lgicos, de comparao e quantificadores. As expresses de Clculo so chamadas de frmulas. Uma tupla de respostas essencialmente uma atribuio de constantes s variveis que levam a frmula a um estado verdadeiro. Em CRT, as variveis so definidas sobre (isto , associam) tuplas. J em CRD, variveis so definidas sobre o domnio dos elementos (ou seja, sobre os valores dos campos). Todas as expresses de consulta descritas em CR possuem equivalentes em AR.
7.4.1 Clculo Relacional de Tuplas
baseado na especificao de um nmero de variveis de tuplas. Cada varivel de tupla pode assumir como seu valor qualquer tupla da relao especificada. Uma consulta em CRT especificada da seguinte forma: {varivel tupla | predicado} O resultado de tal consulta o conjunto de todas as variveis tuplas para as quais o predicado indicado como verdadeiro. Uma expresso genrica do clculo relacional de tuplas tem a forma{t1.A1, t2.A2,..., tn.An | predicado(t1, t2,..., tn, tn+1, tn+2, ...,tn+m)} onde t1, t2,..., tn, tn+1, tn+2, ...,tn+m so variveis de tuplas, cada Ai um atributo da relao na qual ti se encontra e o predicado uma frmula do clculo relacional de tuplas. As frmulas atmicas de clculo de predicados podem ser uma das seguintes: 1-) Uma frmula atmica R(ti), onde R o nome de uma relao e ti uma varivel de tupla. Este tomo identifica a extenso da varivel de tupla ti como a relao cujo nome seja R. 2-) Uma frmula atmica ti.A op tj.B, onde op um dos operadores de comparao no conjunto {=, >, <, ...}, ti e tj so variveis de tuplas, A um atributo da relao na qual ti se encontra, B um atributo da relao na qual tj se encontra. 3-) Um frmula atmica ti.A op c ou c op tj.B, onde op um dos operadores de comparao no conjunto {=, >, <, ...}, ti e tj so variveis de tuplas, A um atributo da relao na qual ti se encontra, B um atributo da relao na qual tj se encontra e c um valor constante. Cada uma das frmulas atmicas anteriormente especificadas tem seu valor verdade avaliado como TRUE ou FALSE para uma combinao especfica de tuplas. Para frmulas do tipo 1, caso a varivel de tupla seja atribuda a uma tupla da relao R dada, esta assume valor TRUE; caso contrrio, FALSE. J nas frmulas do tipo 2 e 3, se as variveis de tupla forem designadas de forma que os valores dos atributos especificados satisfaam o predicado, esta assumir valor verdade TRUE.
64
Todas as variveis tuplas abordadas at ento so consideradas variveis livres4, uma vez que estas no aparecem quantificadas. Contudo, alm das definies acima, quantificadores (universal () ou existencial ()) podem aparecer nas frmulas. Neste caso, as variveis que os sucedem so denominadas variveis limite. Uma frmula definida, de forma recursiva, por uma ou mais frmulas atmicas, conectadas por operadores lgicos (AND, OR, NOT), como segue: 1-) Qualquer frmula atmica. 2-) Se F1 e F2 so frmulas atmicas, ento (F1 AND F2), (F1 OR F2), NOT (F1) e NOT (F2) tambm o so, tendo seus valores verdade derivados a partir de F1 e F2, da seguinte forma: a-) (F1 AND F2) ser TRUE apenas se ambos, F1 e F2, forem TRUE; b-) (F1 OR F2) ser TRUE quando uma das duas frmulas F1 e F2, for TRUE; c-) NOT(F1) ser TRUE quando F1 for FALSE; c-) NOT(F2) ser TRUE quando F2 for FALSE. 3-) Se F1 uma frmula atmica, ento ( t5)(F1) tambm o , e seu valor verdade apenas ser TRUE se a frmula F for avaliada como verdadeira para pelo menos uma tupla atribuda para ocorrncias livres de t em F. 4-) Se F1 uma frmula atmica, ento ( t)(F1) tambm o , e seu valor verdade apenas ser TRUE se a frmula F for avaliada como verdadeira para todas as tuplas atribudas para ocorrncias livres de t em F. possvel escrever expresses equivalentes manipulando operadores quantificadores. Alguns casos dessa manipulao podem ser declarados da seguinte forma: 1-) F1 AND F2 NOT(NOT F1 OR NOT F2). 2-) ( t) r (F1(t)) NOT ( t) r (NOT F1(t)). 3-) F1 F2 NOT F1 OR F2. 4-) ( x) (F(x)) NOT ( x) (NOT (F(x)) 5-) ( x) (F(x)) NOT ( x) (NOT (F(x)) 6-) ( x) (F(x) AND P(x)) NOT ( x) (NOT (F(x)) OR NOT (P(x))) 7-) ( x) (F(x) OR P(x)) NOT ( x) (NOT (F(x)) AND NOT (P(x))) 8-) ( x) (F(x) OR P(x)) NOT ( x) (NOT (F(x)) AND NOT (P(x))) 9-) ( x) (F(x) AND P(x)) NOT ( x) (NOT (F(x)) OR NOT (P(x))) Abaixo seguem exemplos de consultas em CRT. 1-) Encontre todos os empregados cujos salrios estejam acima de R$3.500,00. {t | EMPREGADO(t) AND t.SALARIO > 3500} 2-) D apenas os nomes e sobrenomes dos empregados cujos salrios estejam acima de R$3.500,00. {t.NOME, t.SOBRENOME | EMPREGADO(t) AND t.SALARIO > 3500} 3-) Selecione o nome e o endereo dos empregados que trabalham para o departamento de Informtica. {t.NOME, t.SOBRENOME, t.ENDERECO | EMPREGADO(t) AND ( d) (DEPARTAMENTO (d) AND d.NOMED = Informtica AND d.NUMERODEP = t.NUD)} e
As nicas variveis de tupla livres em uma expresso de clculo relacional devem ser aquelas esquerda da barra ( | ). 5 t uma varivel de tupla.
65
4-) Para cada projeto localizado em So Paulo, liste o nmero do mesmo, o nome do departamento proponente, bem como sobrenome, data de nascimento e endereo do gerente responsvel. {p.NUMEROP, p.NUMD, m.SOBRENOME, m.DATANASCIMENTO, m.ENDERECO | PROJETO(p) AND EMPREGADO(m) AND p.LOCALIZACAO = So Paulo AND (( d) (DEPARTAMENTO(d) AND d.NUMD = d.NUMERODEP AND d.NSSGER = m.NSS) )}
5-) Encontre os nomes dos empregados que trabalham em todos os projetos controlados pelo departamento de nmero 5. {e.SOBRENOME, e.NOME | EMPREGADO(e) AND (( x) (NOT(PROJETO(x)) OR NOT(x.NUMD = 5) OR (( w) (TRABALHA_EM(w) AND w.NSSE = e.NUMEROP AND x.NUMEROP = w.NUMP))))}
Expresses Seguras
Uma expresso em CRT pode gerar uma infinidade de relaes. Para a expresso {t | NOT (R(t))} pode existir uma infinidade de tuplas que no esto em R, de forma que esta nosegura. A maioria dessas tuplas contm valores que no esto no banco de dados, logo, no so desejveis como resultados. Uma expresso segura no CR uma expresso que garante a produo de um nmero finito de tuplas como resultado. Para melhor definir expresso segura, o conceito de domnio pode ser utilizado. O domnio de uma expresso P o conjunto de todos os valores referenciados por P. Isso inclui os valores mencionados em P propriamente dito, assim como os valores que aparecem na tupla de uma relao referenciada por P. Assim, o domnio de P um conjunto de valores que aparecem explicitamente em P ou que aparecem em uma ou mais relaes cujos nomes aparecem em P.
7.4.2 Clculo Relacional de Domnio
A diferena bsica entre CRT e CRD que neste ltimo as variveis estendem-se sobre valores nicos de domnios de atributos. Para formar uma relao de grau n para um resultado de consulta, faz-se necessrio criar n variveis de domnio, uma para cada atributo. Uma expresso genrica do clculo relacional de tuplas tem a forma {x1, x2,..., xn | predicado(x1, x2,..., xn, xn+1, xn+2, ...,xn+m)} onde x1, x2,..., xn, xn+1, xn+2, ...,xn+m so variveis de domnio aplicadas sobre o domnio dos atributos requeridos na consulta e predicado uma frmula atmica do CRD, que pode ser especificada em uma das formas que segue: 1-) Uma frmula atmica R(x1, x2,..., xn), onde R o nome de uma relao de grau j e cada xi, 1 i j, uma varivel de domnio. Isto implica que uma lista de valores de <x1, x2,..., xj> deve ser uma tupla na relao R, onde xi o valor do i-simo valor de atributo da tupla. 2-) Uma frmula atmica xi op xj, onde op um operador de comparao {=, <, >, ...} e xi e xj so variveis de domnio.
66
3-) Uma frmula atmica xi op c ou c xj, onde op um operador de comparao {=, <, >, ...} e xi e xj so variveis de domnio e c um valor constante qualquer. Como em CRT, as frmulas so avaliadas em valores verdade para um conjunto especfico de valores. Para a frmula do tipo 1, o valor verdade ser TRUE apenas se houver valores de domnio correspondentes a uma tupla de R atribudos s variveis de domnio que representam. Para os casos 2 e 3, o valor verdade ser TRUE caso as variveis de domnio possuam valores que satisfaam o predicado.
Expresses Seguras
Uma expresso em CRD dita segura se: 1-) Todos os valores que aparecem nas tuplas da expresso so valores dentro do domnio da mesma. 2-) Para todas as sub-frmulas ( x) (P(x)), a sub-frmula verdadeira se, e somente se, existir um valor x no domnio de P tal que P(x) seja verdadeiro. 3-) Para toda sub-frmula ( x) (P(x)), a sub-frmula verdadeira se, e somente se, P(x) for verdadeiro para todos os valores de x dentro do domnio de P. As proposies acima garantem que possamos testar todas as sub-frmulas existe um e para todo sem a necessidade de testar todas as suas infinitas possibilidades de ocorrncia. Abaixo, para fins de comparao, seguem em CRD os mesmos exemplos de consultas j escritos em CRT. 1-) Encontre todos os empregados cujos salrios estejam acima de R$3.500,00. {qrstuvwxyz | ( x) EMPREGADO(qrstuvwxyz) AND x > 3500} 2-) D apenas os nomes e sobrenomes dos empregados cujos salrios estejam acima de R$3.500,00. {qs | ( x) EMPREGADO(qrstuvwxyz) AND x > 3500} 3-) Selecione o nome e o endereo dos empregados que trabalham para o departamento de Informtica. {qsv | ( z) ( l) ( m) (EMPREGADO(qrstuvwxyz) AND DEPARTAMENTO(lmno) AND l = Informtica AND m = z)} 4-) Para cada projeto localizado em So Paulo, liste o nmero do mesmo, o nome do departamento proponente, bem como sobrenome, data de nascimento e endereo do gerente responsvel. {iksuv | ( j) ( m) ( n) ( t) (PROJETO(hijk) AND EMPREGADO(qrstuvwxyz) AND DEPARTAMENTO(lmno) AND k = m AND n = t AND j = So Paulo)} 5-) Encontre os nomes dos empregados que trabalham em todos os projetos controlados pelo departamento de nmero 5. {qs | ( a) ( t) ( b) ( z) EMPREGADO(qrstuvwxyz) AND (( i) (NOT(PROJETO(hijk)) OR NOT(k = 5) OR (TRABALHA_EM(abc) AND a = t AND i = b))))}
67
8 A Linguagem SQL
A linguagem SQL um padro de linguagem de consulta comercial que usa uma combinao de construtores em lgebra e Clculo Relacional e possui as seguintes partes: Linguagem de definio de dados (DDL) Linguagem interativa de manipulao de dados (DML) Incorporao DML (Embedded SQL) Definio de Vises Autorizao Integridade Controle de Transaes O SQL permite que uma tabela (relao) tenha duas ou mais tuplas idnticas em todos os seus valores de atributos. Assim, em geral, uma relao SQL no um conjunto de tuplas porque um conjunto no permite elementos idnticos. Ao invs disso, SQL um multi-conjunto (algumas vezes chamado de bag) de tuplas.
8.1
Estrutura Bsica
Uma expresso bsica em SQL consiste em trs clusulas: select, from e where. A clusula SELECT corresponde operao de projeo da lgebra relacional. usada para relacionar os atributos desejados no resultado de uma consulta. O resultado de uma consulta SQL , obviamente, uma relao. SQL permite duplicidades nas tuplas de resposta.Quando desejamos forar a eliminao de duplicidade, podemos inserir a palavra chave DISTINCT depois de SELECT. Para especificar explicitamente que as duplicidades no sero eliminadas a SQL nos permite usar a palavra-chave all depois de select. Uma vez que a manuteno de duplicidade padro, o uso de all facultativo. O asterisco * pode ser usado para denotar todos os atributos. A clusula FROM corresponde operao de produto cartesiano da lgebra relacional. Ela associa as relaes que sero pesquisadas durante a avaliao de uma expresso. A clusula WHERE corresponde seleo do predicado da lgebra relacional. Consiste em um predicado envolvendo atributos da relao que aparece na clusula FROM. A clusula where pode conter expresses aritmticas envolvendo os operadores de comparao <, <=, >, >=, = e <>, e operandos constantes ou atributos das tuplas. Em SQL, nessa clusula pode-se usar os conectores lgicos AND, OR e NOT; SQL possui o operador de comparao BETWEEN AND para simplificar a clusula where que especifica que um valor pode ser menor ou igual a algum valor e maior ou igual a algum outro valor.
Uma consulta tpica em SQL tem a forma: select A1, A2, ..., An from r1, r2, ..., rn where P
68
Cada Ai representa um atributo e cada ri, uma relao. P um predicado a ser satisfeito. Esta consulta equivale seguinte expresso em AR: A1, A2, ..., An ( p (r1 x r2 x ... rm)) A SQL forma um produto cartesiano das relaes indicadas na clusula FROM, executa uma seleo em AR usando o predicado da clusula WHERE e, ento, projeta o resultado nos atributos da clusula SELECT. Na prtica, ela pode converter em outra expresso equivalente que seja mais eficiente no processamento.
8.1.1 A operao RENAME

SQL proporciona um mecanismo para renomear tanto atributos quanto relaes, usando a clusula AS, da seguinte forma: nome_antigo as nome_novo Pode aparecer tanto na clusula SELECT quanto na clusula FROM. A clusula AS particularmente til na definio de varivel tupla (quando utilizada na clusula FROM), como feito no clculo relacional. Uma varivel tupla em SQL precisa estar associada a uma relao.
8.1.2 Operaes com Strings

As operaes em strings mais usadas so as checagens para verificao de coincidncias de pares, utilizando o operador LIKE. Esses pares so identificados por meio do uso de dois caracteres especiais: Porcentagem ( % ): compara qualquer string; Sublinhado ( _ ): compara qualquer caracter. Exemplos: _ _ _ _% corresponde a qualquer string com pelo menos quatro caracteres. Uni% corresponde a qualquer string que comece com Uni, como, universo, universal, universidade. Utilizando not LIKE pode-se pesquisar diferenas, ao invs de coincidncias. Obs.: Essas comparaes so case sensitive.
8.1.3 Ordenao e Apresentao de Tuplas

A linguagem de consulta SQL possui a clusula ORDER BY que possibilita a apresentao dos resultados de uma consulta segundo uma determinada ordem de tuplas. Para completar uma solicitao de ORDER BY a SQL precisa realizar uma SORT (intercalao). Uma intercalao com muitas tuplas pode ser custosa, portanto, s usar quando necessria. Para listarmos uma relao em ordem ascendente usamos order by nome do campo asc. Em ordem descendente, usamos order by nome do campo desc. Por default, a relao dos itens efetuada em ordem ascendente.
8.1.4 Operaes com Conjuntos

SQL possui as operaes de unio (union), interseo (intersect) e exceto (except), que correspondem s operaes , e lgebra relacional.
69
Contudo, existem vrias restries para o uso destes operadores e certos produtos no oferecem suporte para estas operaes.
8.1.5 Funes Agregadas

Funes que tomam uma coleo (um conjunto ou subconjunto) de valores como entrada, retornando um nico valor. Funes ofertadas pela SQL: Sum: soma/total avg: mdia count: contagem Min: mnimo Max: Maximo A entrada para sum e avg precisa, obrigatoriamente, ser um conjunto de nmeros, mas as demais operaes no impem esta restrio. Exemplo: select A1, A2, ..., An from r1, r2, ..., rn where P group by A1; Por vezes, precisamos aplicar uma funo agregada no apenas a um conjunto de tuplas, mas tambm a um grupo de conjunto de tuplas. Isto feito por meio da clusula group by (onde os seus atributos so utilizados para formar os grupos). Em outros casos, pode ser mais interessante definir condies e aplic-las a grupos do que aplic-las a tuplas. Isto feito pela clusula having. Como os predicados da clusula so aplicados aps a formao dos grupos, funes agregadas podem ser usadas. select A1, A2, ..., An from r1, r2, ..., rn where P group by A1 having <funo agregada>;
8.1.6 Subconsultas Aninhadas

Uma expresso select-from-where aninhada dentro de outra consulta considerada uma subconsulta. Aplicaes: Membros de Conjuntos; Verificar se uma tupla membro ou no de uma relao. O conectivo in testa os membros de um conjunto, no qual este conjunto a coleo de valores produzidos na clsula select. select A1, A2, ..., An from r1, r2, ..., rn where P in (select A1, A2, ..., An from r1, r2, ..., rn where P); Comparaes de Conjuntos;
70
Permite usar comparaes do tipo > some (maior que ao menos uma), <= some, = some, etc... ou > all (maior que todas), >= all, etc. select A1, A2, ..., An from r1, r2, ..., rn where P > all (select A1, A2, ..., An from r1, r2, ..., rn where P); Verificao de relaes vazias Pode-se testar se o resultado de uma subconsulta vazio. O construtor exists retorna o valor true se o argumento da subconsulta no-vazio.
select A1, A2, ..., An from r1, r2, ..., rn where P exists (select A1, A2, ..., An from r1, r2, ..., rn where P);
8.1.7 Vises
Uma viso qualquer relao que no faz parte do modelo lgico do banco de dados, mas que visvel ao usurio, como uma relao virtual. O conjunto de tuplas de uma relao viso resultado de uma expresso de consulta que foi definido no momento de sua execuo. Logo, se uma relao viso computada e armazenada, esta pode tornar-se desatualizada se as relaes usadas em sua gerao sofrerem modificaes. Quando uma viso definida, o sistema de banco de dados armazena sua definio ao invs do resultado da expresso SQL que a definiu. Sempre que a relao viso usada, ela sobreposta pela expresso da consulta armazenada, de maneira que, sempre que a consulta for solicitada, a relao viso ser recomputada. Alguns sistemas de banco de dados permitem que as relaes de vises sejam materializadas, garantindo que se ocorrerem modificaes nas relaes reais usadas na definio da viso, tambm a viso ser modificada. Contudo, esta abordagem pode incorrer em custos de armazenamento e atualizaes de sistema. As vises em SQL so geradas a partir do comando create view. A clusula padro : CREATE VIEW <nome da viso> AS <expresso de consulta>; Caso no necessitemos mais de uma dada viso, podemos elimin-la por meio do comando: DROP VIEW <nome da viso>;
Modificaes no Banco de Dados por meio de SQL
8.1.8 Insero
O comando INSERT utilizado para adicionar uma nica tupla a uma relao. Para inserirmos dados em uma relao devemos especificar a relao e uma lista de valores para a tupla a ser inserida. Obs.: Os valores devem ser inseridos na mesma ordem na qual os atributos correspondentes foram especificados na criao da tabela de dados.
71
A clusula padro : INSERT INTO <relao> VALUES <lista com valores dos atributos>
8.1.9 Atualizao
O comando UPDATE utilizado para modificar valores de atributos de uma ou mais tuplas selecionadas. As atualizaes servem para modificar valores de tuplas que esto inseridas em um certo critrio. Para tal usa-se o comando update. A clusula padro : UPDATE <relao> SET <lista dos atributos a serem alterados e seus respectivos valores> WHERE <condio>
8.1.10 Remoo
O comando DELETE remove tuplas de uma relao. A remoo de valores num banco de dados consiste na excluso de tuplas que satisfaam certa condio especificada na clusula WHERE. As tuplas so explicitamente excludas de uma tabela a cada vez. A expresso padro : DELETE FROM r WHERE P
8.1.11 SQL DDL

Por meio da SQL DDL pode ser especificado no apenas o conjunto de relaes, mas tambm informaes sobre cada uma das relaes existentes no banco de dados: O esquema de cada relao. O domnio dos valores associados a cada atributo. As regras de integridade. O conjunto de ndices para manuteno de cada relao. Informaes sobre segurana e autoridade sobre cada relao. A estrutura de armazenamento fsico de cada relao no disco.
Exemplos de Consultas SQL Bsicas: A forma bsica do comando SELECT, algumas vezes chamada de mapping ou bloco SELECT FROM WHERE, formada por trs clusulas - SELECT, FROM e WHERE:
Consulta 0: Recuperar a data de nascimento e o endereo do empregado cujo nome 'John B. Smith'. Q0: SELECT DATANASC, ENDEREO FROM EMPREGADO WHERE PNOME = 'John' AND MNOME = 'B' AND SNOME = 'Smith' Esta consulta envolve apenas a relao EMPREGADO declarada na clusula FROM. A consulta seleciona as tuplas de EMPREGADO que satisfazem a condio da clusula WHERE, e ento projeta o resultado sobre os atributos listados na clusula SELECT. Q0 similar expresso da lgebra relacional:
72
DATANASC, ENDEREO ( PNOME = 'John' AND MNOME = 'B' AND SNOME='Smith' (EMPREGADO)) Assim, uma simples consulta SQL com uma nica relao similar ao par SELECT-PROJECT. A nica diferena da consulta SQL que, na relao resultante, as tuplas podem estar duplicadas, exceto se tiver o operador DISTINCT. Consulta 1: Encontrar o nome e o endereo de todos os empregados que trabalham para o departamento 'Pesquisa'. Q1: SELECT PNOME, SNOME, ENDEREO FROM EMPREGADO, DEPARTAMENTO WHERE DNOME = 'Pesquisa' AND DNUMERO = NDEP Esta consulta similar seqncia SELECT-PROJECT-JOIN da lgebra relacional. Na clusula WHERE a condio DNOME='Pesquisa' uma condio de seleo e corresponde operao SELECT lgebra relacional. A condio DNUMERO = NDEP uma condio join, que corresponde condio da operao JOIN. Consulta 2: Para todo projeto localizado em 'Stafford', listar o nmero do projeto, o nmero do departamento responsvel, e o sobrenome, endereo e data de nascimento do gerente responsvel pelo departamento. Q2: SELECT PNUMERO, DNUM, SNOME, ENDEREO, DATANASC FROM PROJETO, DEPARTAMENTO, EMPREGADO WHERE DNUM = DNUMERO AND SSNGER = NSS AND PLOCALIZAO = 'Stafford'
Consulta 3: Encontrar os nomes de empregados que trabalham em todos os projetos controlados pelo departamento 5. Q3: SELECT PNOME, SNOME FROM EMPREGADO WHERE ((SELECT PNRO FROM TRABALHA_EM WHERE NSS = NSSEMP) CONTAINS (SELECT PNUMERO FROM PROJETO WHERE DNUM = 5))
O operador CONTAINS compara dois conjuntos de valores e retorna TRUE se um conjunto contm todos os valores do outro. A segunda consulta dentro dos parnteses recupera todos os nmeros de projetos controlados pelo departamento 5. Para cada tupla de EMPREGADO, a primeira consulta dentro dos parnteses recupera os nmeros de projetos sobre os quais os empregados trabalham. Se o resultado desta consulta contiver todos os projetos controlados pelo departamento 5, a tupla de EMPREGADO selecionada e o nome deste empregado recuperado. Note que a operao de comparao CONTAINS similar em sua funo operao DIVISION da lgebra relacional. Consulta 4: Fazer uma lista de nmeros de projetos no qual um empregado, cujo sobrenome 'Smith' , trabalha no projeto ou gerente do departamento que controla o projeto. Q4: (SELECT PNUMERO FROM PROJETO, DEPARTAMENTO, EMPREGADO WHERE DNUM=DNUMERO AND NSSGER=NSS AND SNOME='Smith') UNION (SELECT PNUMERO
73
FROM PROJETO, TRABALHA_EM, EMPREGADO WHERE PNUMERO=PNRO AND NSSEMP=NSS AND SNOME='Smith') Consulta 5: Listar os nomes de todos os empregados com dois ou mais dependentes. Q5: SELECT SNOME, PNOME FROM EMPREGADO WHERE ( SELECT COUNT (*) FROM DEPENDENTE WHERE NSS=NSSEMP) >= 2 onde (*) indica o nmero de tuplas.
74
Consulta 6: Listar os nomes dos empregados que no possuem dependentes. Q6: SELECT PNOME, SNOME FROM EMPREGADO WHERE NOT EXISTS ( SELECT * FROM DEPENDENTE WHERE NSS=NSSEMP) onde * indica todos os valores de atributos das tuplas selecionadas.
Consulta 7: Listar os nomes dos gerentes que tm ao menos um dependente. Q7: SELECT PNOME, SNOME FROM EMPREGADO WHERE EXISTS ( SELECT * FROM DEPENDENTE WHERE NSS=NSSEMP) AND EXISTS ( SELECT * FROM DEPARTAMENTO WHERE NSS=NSSGER)
75
9 Dependncias Funcionais e Normalizao de Base de Dados Relacionais

9.1 Diretrizes para o Projeto Informal de Esquemas de Relaes
Nessa seo sero discutidas mtricas de qualidade informal para projeto de esquemas de relaes, quais sejam: Semntica de atributos. Reduo de valores redundantes em tuplas. Reduo de valores nulos em tuplas. No permisso de tuplas esprias. Essas mtricas no so sempre independentes uma das outras, como ser visto.
9.1.1 Semntica de atributos de relao

Assume-se que certo significado esteja associado aos atributos, para todo agrupamento de atributos que formam uma relao esquema. Intuitivamente, verifica-se que cada relao pode ser interpretada como um conjunto de fatos ou declaraes. Este significado, ou semntica, especifica como podem ser interpretados os valores de atributos armazenados em uma tupla da relao, em outras palavras, como os valores de atributos esto relacionados uns com os outros. Em geral, mais simples descrever a semntica de relaes, ao invs da semntica de atributos de uma relao. Para ilustrar, considere a verso simplificada da base de dados COMPANHIA da Figura 5.4. O significado do esquema da relao simples - cada tupla representa um empregado, com valores para nome, nmero do seguro social, data de aniversrio, endereo, e o nmero do departamento em que cada empregado trabalha. Alm desses atributos existem aqueles atributos que so utilizados para estabelecer um relacionamento entre relaes. Assim, todas os esquemas de relaes da Figura 5.4. podem ser considerados como um bom ponto de partida para manter clara a semntica. Pode-se assim, estabelecer as seguintes diretrizes para projetar esquemas de relaes: Diretriz 1: Projetar um esquema de relao de maneira que seja simples descrever seu significado. Normalmente, isso significa que no se pode combinar atributos de mltiplos tipos de entidades e tipos de relacionamentos numa simples relao. Intuitivamente, se um esquema de relao corresponde a um tipo de entidade ou tipo de relacionamento, o significado tende a ser claro. Por outro lado, tende ser uma mistura de mltiplas entidades e relacionamentos e, assim, semanticamente no-clara. A relao esquema da Figura 9.1 a e b possuem semntica clara. Uma tupla na relao esquema EMP_DEPT da Figura 9.1a representa um mero empregado, mas inclui informaes adicionais, tais como o nome do departamento em que o empregado trabalha (DNOME) e o nmero do seguro social do gerente do departamento (NSSGER). Na relao esquema EMP_PROJ da Figura 9.1b, cada tupla relaciona um empregado a um projeto, mas tambm, incluem nome do empregado (ENOME), nome do projeto (PNOME) e a localizao do projeto (PLOCALIZAO). Embora no exista, logicamente, nada de errado com esses esquemas, eles so considerados um projeto pobre, pois viola a Diretriz 1 porque mistura atributos de entidades distintas do mundo real; EMP_DEPT mistura atributos de empregados e departamentos, e EMP_PROJ mistura atributos de empregados e projetos. Eles podem ser usados como vises, mas podem causar problemas quando usados como relaes da base de dados, como ser discutido mais adiante.
76
(a)
ENOME
EMP_DEPT NSS EMP_PROJ PNUMERO
DATANASC
ENDEREO
DNUMERO
DNOME
NSSGER
(b)
NSS
HORAS
ENOME
PNOME
PLOCALIZAO
Figura 9.1 Informao redundante em tuplas e anomalias de atualizaes

Uma das metas do projeto de esquemas a minimizao do espao de armazenamento que relaes da base ocupam. O agrupamento de atributos em esquemas de relaes tem um efeito significativo no espao de armazenamento. Por exemplo, compare o espao usado pelas duas relaes base EMPREGADO e DEPARTAMENTO na Figura 9.2 com o espao utilizado por EMP_DEPT na relao base da Figura 9.3, que o resultado da aplicao do JOIN NATURAL entre EMPREGADO e DEPARTAMENTO.
EMPREGADO ENOME John Smith Franklin Wong Alcia Zelaya Jennifer Wallace Ramesh Narayan Joyce English Ahmad Jabbar James Borg DEPARTAMENTO DNOME Pesquisa Administrativo Gerencial NSS 123456789 333445555 999887777 987654321 666884444 453453453 987987987 888665555 DATANASC 09-JAN-55 08-DEZ-45 19-JUL-58 20-JUN-31 15-SET-52 31-JUL-62 29-MAR-59 10-NOV-27 ENDEREO R. A, 1 R. B, 2 Av. C, 3 Trav. D, 4 R. E, 5 R. F, 6 Av G, 7 Av H, 8 DNUMERO 5 5 4 4 5 5 4 1 LOCAIS_DEPTO DNUMERO 1 4 5 5 5 PROJETO PNOME ProdutoX ProdutoY ProdutoZ Automao Reorganizao Beneficiamento
DNUMERO 5 4 1
NSSGER 333445555 987654321 888665555
TRABALHA_EM NSSEMP PNRO 123456789 1 123456789 2 666884444 3 453453453 1 453453453 2 333445555 2 333445555 3 333445555 10 333445555 20 999887777 30 999887777 10 987987987 10 987987987 30 987654321 30 987654321 20 888775555 20
HORAS 32.5 7.5 40.0 20.0 20.0 10.0 10.0 10.0 10.0 30.0 10.0 35.0 5.0 20.0 15.0 null
PNUMERO 1 2 3 10 20 30
PLOCALIZAO Bellaire Sugarland Houston Stafford Houston Stafford
DNUM 5 5 5 4 1 4
Figura 9.2
EMP_DEPT ENOME John Smith Franklin Wong Alcia Zelaya Jennifer Wallace Ramesh Narayan Joyce English Ahmad Jabbar James Borg NSS 123456789 333445555 999887777 987654321 666884444 453453453 987987987 888665555 DATANASC 09-JAN-55 08-DEZ-45 19-JUL-58 20-JUN-31 15-SET-52 31-JUL-62 29-MAR-59 10-NOV-27 ENDEREO R. A, 1 R. B, 2 Av. C, 3 Trav. D, 4 R. E, 5 R. F, 6 Av G, 7 Av H, 8 DNUMERO 5 5 4 4 5 5 4 1 DNOME Pesquisa Pesquisa Administrativo Administrativo Pesquisa Pesquisa Administrativo Gerencial NSSGER 333445555 333445555 987654321 987654321 333445555 333445555 987654321 888665555
EMP_PROJ NSS PNUMERO 123456789 1 123456789 2 666884444 3 453453453 1 453453453 2 333445555 2 333445555 3 333445555 10 333445555 20 999887777 30
HORAS 32.5 7.5 40.0 20.0 20.0 10.0 10.0 10.0 10.0 30.0
ENOME John Smith John Smith Ramesh Narayan Joyce English Joyce English Franklin Wong Franklin Wong Franklin Wong Franklin Wong Alcia Zelaya
PNOME ProdutoX ProdutoY ProdutoZ ProdutoX ProdutoY ProdutoY ProdutoZ Automao Reorganizao Beneficiamento
PLOCALIZAO Bellaire Sugarland Houston Bellaire Sugarland Sugarland Houston Stafford Houston Stafford

999887777 987987987 987987987 987987987 987987987 888665555 10 10 30 30 20 20 10.0 35.0 5.0 20.0 15.0 null Alcia Zelaya Ahmad Jabbar Ahmad Jabbar Jennifer Wallace Jennifer Wallace James Borg Automao Automao Beneficiamento Beneficiamento Reorganizao Reorganizao

Stafford Stafford Stafford Stafford Houston Houston
77
Figura 9.3
Em EMP_DEPT, os valores de atributos pertencentes a um particular departamento (DNUMERO, DNOME, NSSGER) esto repetidos para todos os empregados que trabalham para um departamento. Em contraste, as informaes de departamento aparecem apenas uma vez para cada departamento na relao DEPARTAMENTO da Figura 9.2, e apenas o nmero do departamento (DNUMERO) repetido na relao EMPREGADO para cada empregado que trabalha no departamento. Similarmente, o mesmo comentrio se aplica para a relao EMP_PROJ. Um outro problema srio identificado, quando se utilizam relaes similares s encontradas na Figura 9.3 como relaes base, o problema da anomalia de alteraes. Podem ser classificadas em anomalias de insero, remoo e modificaes.
9.2
Anomalia de insero
Pode-se diferenciar dois tipos de anomalias de insero. Para inserir uma nova tupla empregado em EMP_DEPT, deve-se incluir valores de atributos do departamento em que o empregado trabalha, ou null se o empregado ainda no pertencer a um departamento. Por exemplo, para inserir uma nova tupla para o empregado que trabalha no departamento 5, deve-se tomar cuidado em assegurar que os valores de atributos sejam inseridos corretamente, tal que fiquem consistentes com os valores do departamento 5 em outras tuplas de EMP_DEPT. No projeto ilustrado na Figura 9.2 esse cuidado no precisa ser tomado, uma vez que apenas o nmero do departamento necessrio em cada tupla de empregado; os outros valores de atributos do departamento 5 so registrados apenas uma vez na base de dados, como uma simples tupla na relao DEPARTAMENTO. difcil inserir um novo departamento que ainda no tenha empregados na relao EMP_DEPT. A nica maneira de fazer isso colocar valores null em atributos de empregados. Isso provoca um problema pois NSS a chave primria de EMP_DEPT, e supe-se que cada tupla representa uma entidade empregado no uma entidade departamento. Mais do que isso, quando o primeiro empregado for associado a esse departamento, no ser mais necessrio a tupla com valores null. Este problema no ocorre no projeto da Figura 9.2, porque um departamento inserido na relao DEPARTAMENTO sem que nenhum empregado trabalhe nele, e quando um empregado for associado ao departamento, uma tupla correspondente inserida em EMPREGADO.
9.2.1 Anomalia de remoo

Este problema est relacionado segunda anomalia de insero discutida acima. Se for removida uma tupla empregado de EMP_DEPT e esta tupla for ltima de um particular departamento, a informao correspondente ao departamento ser perdida. Este problema no ocorre na base de dados da Figura 9.2 pois as tuplas de DEPARTAMENTO so armazenadas separadamente das tuplas de EMPREGADO, somente o atributo DNMERO de EMPREGADO relaciona os dois.
9.2.2 Anomalia de modificao

Em EMP_DEPT, se for mudado o valor de um dos atributos de um departamento qualquer, por exemplo, o gerente do departamento 5, deve ser mudado as tuplas de todos os empregados que trabalham neste departamento; por outro lado, a base de dados se tornar inconsistente.
Introduo a Banco de Dados 9.2.3 Discusso
78
De acordo com as anomalias acima, pode-se estabelecer a seguinte diretriz: Diretriz 2: Projetar esquemas de relaes de maneira que nenhuma anomalia de alterao ocorra em relaes. Se existir alguma anomalia, isso dever ser considerado para que as modificaes pelos programas ocorram corretamente. A segunda diretriz consistente e refora a primeira diretriz. Verifica-se, porm, que existe a necessidade de uma abordagem mais formal para auxiliar na avaliao de que projetos obedecem estas diretrizes. Nas sees seguintes isso ser fornecido. importante notar que estas diretrizes podem, algumas vezes, ter que ser violadas a fim de aumentar o desempenho de certas consultas. Por exemplo, se for importante recuperar, rapidamente, informaes pertinentes ao departamento, atravs de atributos de um empregado que trabalhe no departamento, o esquema EMP_DEPT pode ser usado como uma relao base. No entanto, deve-se assegurar que as anomalias sejam bem conhecidas para que as modificaes nesta relao base no a tornem inconsistente. Em geral aconselhvel utilizar relaes base livre de anomalias e especificar vises utilizando JOINs para unir atributos freqentemente referenciados em consultas importantes. Isso reduz o nmero de JOINs especificados em consultas, simplifica as consultas, e em alguns casos, eleva o desempenho.
9.2.4 Valores null em tuplas

Em alguns projetos de esquemas pode-se agrupar atributos em uma grande relao. Se muitos atributos no se aplicarem a todas as tuplas da relao, ter-se- muitos valores nulls na relao. Isto pode despender espao armazenamento e pode tambm trazer problemas de entendimento do significado dos atributos na especificao de operaes JOINs. Um outro problema com valores nulls que no se pode cont-los quando operaes de agregao, tais como COUNT ou SUM so aplicadas. Mais que isso, os valores nulls podem ter mltiplas interpretaes, tais como: O atributo pode no se aplicar a tupla. O valor de atributo para a tupla desconhecido. O valor conhecido, porm no foi registrado ainda. Ter a mesma representao, null, para diferentes significados pode comprometer as consultas. Assim, pode-se estabelecer uma outra diretriz: Diretriz 3: Tanto quanto possvel, evite colocar atributos em um esquema de relao base cujos valores possam ser null. Se forem inevitveis os valores nulls, esteja seguro que eles se apliquem apenas em casos excepcionais e no se apliquem na maioria das tuplas da relao. Por exemplo, se apenas 10% dos empregados tiverem secretrias, no existe razo para incluir um atributo NMERO_SECRETRIA na relao EMPREGADO; ao invs disso, uma relao EMP_SEC(ESSN, NMERO_SECRETRIA) poderia ser criada para conter apenas as tuplas indicando o ESSN de empregados que possuem secretrias.
9.2.5 Tuplas esprias

Considere os esquemas de relao EMP_LOCS e EMP_PROJ1 da Figura 9.4a, que pode substituir a relao EMP_PROJ da Figura 9.1b.
(a)
ENAME EMP_LOCS PLOCALIZAO EMP_PROJ1 PNUMERO
NSS
HORAS
PNOME
PLOCALIZAO
(b) EMP_LOCS ENAME PLOCALIZAO John Smith Bellaire John Smith Sugarland

Ramesh Narayan Joyce English Joyce English Franklin Wong Franklin Wong Franklin Wong Alcia Zelaya Ahmad Jabbar Jennifer Wallace Jennifer Wallace James Borg Houston Bellaire Sugarland Sugarland Houston Stafford Stafford Stafford Stafford Houston Houston
79
EMP_PROJ1 PNUMERO NSS 123456789 1 123456789 2 666884444 3 453453453 1 453453453 2 333445555 2 333445555 3 333445555 10 333445555 20 999887777 30 999887777 10 987987987 10 987987987 30 987987987 30 987987987 20 888665555 20
HORAS 32.5 7.5 40.0 20.0 20.0 10.0 10.0 10.0 10.0 30.0 10.0 35.0 5.0 20.0 15.0 null
PNOME ProdutoX ProdutoY ProdutoZ ProdutoX ProdutoY ProdutoY ProdutoZ Automao Reorganizao Beneficiamento Automao Automao Beneficiamento Beneficiamento Reorganizao Reorganizao
PLOCALIZAO Bellaire Sugarland Houston Bellaire Sugarland Sugarland Houston Stafford Houston Stafford Stafford Stafford Stafford Stafford Houston Houston
Figura 9.4
Uma tupla em EMP_LOCS significa que o empregado cujo nome ENOME trabalha em algum projeto cuja localizao PLOCALIZAO. Uma tupla em EMP_PROJ1 significa que o empregado cujo nmero do seguro social NSS trabalha HORAS por semana em um projeto cujo nome, nmero e localizao so PNOME, PNUMERO e PLOCALIZAO. A Figura 9.4b mostra a extenso de EMP_LOCS e EMP_PROJ1 correspondente relao extenso EMP_PROJ da Figura 9.3, aplicando-se operaes de projeo () adequadas. Suponha agora que EMP_PROJ1 e EMP_LOCS sejam utilizadas como relaes base ao invs de EMP_PROJ. Isto seria, particularmente, um projeto ruim, pois no se pode recuperar as informaes que existiam originalmente em EMP_PROJ a partir de EMP_PROJ1 e EMP_LOCS. Se uma operao JOIN-NATURAL for aplicada em EMP_PROJ1 e EMP_LOCS, surgiro mais tuplas que existiam em EMP_PROJ. A Figura 9.5 ilustra o resultado obtido aplicando-se o join, considerando apenas as tuplas existentes acima da linha pontilhada, para reduzir o tamanho da relao resultante. As tuplas adicionais so chamadas tuplas esprias porque elas representam informaes esprias ou erradas, e por isso elas no vlidas. As tuplas esprias esto marcadas por asteriscos (*) na Figura 9.5. A decomposio de EMP_PROJ em EMP_PROJ1 e EMP_LOCS ruim porque quando aplicada a operao JOIN-NATURAL, no so obtidas as informaes originais corretas. Isto porque foi escolhido PLOCALIZAO como o atributo que relaciona EMP_LOCS e EMP_PROJ1, e PLOCALIZAO no nem uma chave-primria e nem uma chaveestrangeira. Pode-se agora estabelecer uma outra diretriz para projeto: Diretriz 4: Projetar esquemas de relaes tal que, quando aplicadas operaes JOINNATURAIS, os atributos nas condies-joins envolvam atributos que sejam ou chavesprimrias ou chaves-estrangeiras de maneira a garantir que nenhuma tupla espria seja gerada.
* * * * *
NSS 123456789 123456789 123456789 123456789 123456789 666884444 666884444 453453453
PNUMERO 1 1 2 2 2 3 3 1
HORAS 32.5 32.5 7.5 7.5 7.5 40.0 40.0 20.0
PNOME ProdutoX ProdutoX ProdutoY ProdutoY ProdutoY ProdutoZ ProdutoZ ProdutoX
PLOCALIZAO Bellaire Bellaire Sugarland Sugarland Sugarland Houston Houston Bellaire
ENAME John Smith Joyce English John Smith Joyce English Franklin Wong Ramesh Narayan Franklin Wong John Smith

453453453 453453453 453453453 453453453 333445555 333445555 333445555 333445555 333445555 333445555 333445555 333445555 1 2 2 2 2 2 2 3 3 10 20 20 20.0 20.0 20.0 20.0 10.0 10.0 10.0 10.0 10.0 10.0 10.0 10.0

ProdutoX ProdutoY ProdutoY ProdutoY ProdutoY ProdutoY ProdutoY ProdutoZ ProdutoZ Automao Reorganizao Reorganizao Bellaire Sugarland Sugarland Sugarland Sugarland Sugarland Sugarland Houston Houston Stafford Houston Houston Joyce English John Smith Joyce English Franklin Wong John Smith Joyce English Franklin Wong Ramesh Narayan Franklin Wong Franklin Wong Ramesh Narayan Franklin Wong
80
* * * * *
Figura 9.5
Obviamente, estas diretrizes informais necessitam ser estabelecidas de maneira mais formal.
9.3
Dependncias Funcionais
Um conceito simples, porm, muito importante em projetos de esquemas relacionais o de dependncia funcional. Nesta seo ser definido formalmente este conceito, e na seo 9.2.2 ser verificado como trabalhar com esquemas de relaes em formas normais.
9.3.1 Definio de Dependncia Funcional

Dependncias Funcionais so restries ao conjunto de relaes vlidas. Elas permitem expressar determinados fatos em banco de dados relativos ao empreendimento que se deseja modelar. Anteriormente foi definido o conceito de superchave. Seja R o esquema de uma relao. Um subconjunto K de R uma superchave de R em qualquer relao vlida r(R) para todos os pares t1 e t2 de tuplas em r tal que t1 t2, ento t1[K] t2[K]. Isto , nenhum par de tuplas em qualquer relao vlida r(R) deve ter o mesmo valor no conjunto de atributos K. A noo de dependncia funcional generaliza a noo de superchave. Seja R e R. A dependncia funcional : realiza-se em R se, em qualquer relao vlida r(R), para todos os pares de tuplas t1 e t2 em r tal que t1 [] = t2 [], t1 [] = t2 [] tambm ser verdade. Usando a notao de dependncia funcional, dizemos que K uma superchave de R se K R. Isto , K uma superchave se, para todo t1[K] = t2[K], t1[R] = t2[R] (isto t1 = t2). A dependncia funcional permite expressar restries que as superchaves no expressam. Considere o esquema: Esquema_info_emprstimo = (nome_agncia, nmero_emprstimo, nome_cliente, total) O conjunto de dependncias funcional que queremos garantir para esse esquema de relao : nmero_emprstimototal nmero_emprstimonome_agncia Entretanto, no se espera realizar dependncia funcional para: nmero_emprstimonome_cliente j que, em geral, um emprstimo pode ser contrado por mais de um cliente (por exemplo para ambos os membros de um casal, marido-mulher). Podemos usar dependncia funcional de dois modos: 1. Usando-as para o estabelecimento de restries sobre um conjunto de relaes vlidas. Deve-se assim, concentr-las somente quelas que devem satisfazer um dado conjunto de dependncias funcionais. Se desejasse restringi-las a relaes do
81
esquema em R que satisfaam o conjunto F de dependncias funcionais, diz-se que F realiza-se em R. 2. Usando-as para verificaes de relaes, de modo a saber se as ltimas so vlidas sob um conjunto de dependncias funcionais. Se uma relao r legal sobre um conjunto F de dependncias funcionais, diz-se que r satisfaz F. Considera-se a relao r mostrada abaixo para verificar quais dependncias funcionais so satisfeitas. Observa-se que A C satisfeita. Duas tuplas tm valor a1 em A. Essas tuplas tm o mesmo valor de C denominado c1. De modo similar, duas tuplas com valor a2 em A tm o mesmo valor c2 em C. No existe outro par de tuplas distintas que tenha, em A, os mesmos valores. A dependncia funcional C A, entretanto no satisfeita. Para confirmar esta afirmao, considere as tuplas t1 = (a2, b2, c2, d3) e t2 = (a3, b3, c2, d4). Essas tuplas tm os mesmos valores c2 em C, mas elas possuem valores diferentes em A, a2 e a3, respectivamente. Assim, encontra-se um par de tuplas t1 e t2 tal que t1 [C] = t2 [C], mas t1 [A] t2 [A]. A a1 a1 a2 a2 a3 B b1 b2 b2 b3 b3 C c1 c1 c2 c2 c2 D d1 d2 d2 d3 d4
Figura 9.6 - Relao r de exemplo

Uma dependncia funcional uma restrio entre dois conjuntos de atributos da base de dados. Considere-se que o esquema da base de dados relacional tenha n atributos A1, A2, ..., An ; e que toda a base de dados seja descrita por um nico esquema de relao universal R = { A1, A2, ..., An }. Isso no significa que isso de fato dever acontecer; esta suposio feita apenas para desenvolver uma teoria formal sobre dependncia de dados. Uma dependncia funcional, denotada por X Y, entre dois conjuntos de atributos X e Y que so subconjuntos de R, especifica uma restrio sobre as possveis tuplas que podem existir na relao instncia r de R. A restrio estabelece que para quaisquer tuplas t1 e t2 em r, se t1[X]= t2[X], ento t1[Y]= t2[Y]. Isto significa que os valores da componente Y das tuplas em r dependem, ou so determinados pelos valores da componente X ou, alternativamente, os valores da componente X de uma tupla determinam de maneira nica (ou funcionalmente) os valores da componente Y. Pode-se tambm dizer que existe uma dependncia funcional de X para Y ou que Y dependente funcionalmente de X. A abreviatura de dependncia funcional DF. Note que: Se uma restrio sobre R estabelece que no pode existir mais que uma tupla com um dado valor de X, em quaisquer instncias de relao r(R) - isto , X uma chave-candidata de R - isto implica que X Y para quaisquer subconjuntos de atributos Y de R. Se X Y em R, isto no significa que Y X em R. Uma dependncia funcional uma propriedade do significado ou semntica dos atributos em um esquema de relao R. Utiliza-se o entendimento da semntica de atributos de R - isto , como eles se relacionam - para especificar as dependncias funcionais envolvidas em todas as instncias da relao r (extenso) de R. As instncias r que satisfazem as restries de dependncia funcional especificadas sobre atributos de R so chamadas extenses legais, pois obedecem as restries de dependncia funcional. Assim, a principal utilizao das dependncias funcionais o de descrever um esquema de relao R especificando restries sobre seus atributos que devem ser vlidas todas s vezes.
82
Isto significa que uma dependncia funcional uma propriedade do esquema da relao (inteno) R e no de uma instncia particular legal r (extenso) de R. Assim, uma DF no pode ser automaticamente inferida a partir de uma extenso de relao r, mas deve ser definida por algum que conhea a semntica dos atributos de R. Por exemplo, na Figura 9.7, uma instncia particular de um esquema de relao ENSINO mostrada. Embora num primeiro momento possa parecer que TEXTO CURSO, no se pode afirmar isso a menos que se conhea que isso seja verdade para todas as instncias da relao ENSINO.
PROFESSOR Smith Smith Hall Brown CURSO Estrutura de Dados Gerenciamento de dados Compiladores Estrutura de Dados TEXTO Bartram Al-Nour Hoffman Augenthaler
Figura 9.7
9.3.2 Formas Normais Determinadas pelas Chaves Primrias

O processo de normalizao foi proposto inicialmente por Codd em 1972. Esta uma maneira mais formal de garantir as diretrizes descritas anteriormente.
9.3.2.1 Primeira Forma Normal (1FN)

A primeira forma normal agora genericamente considerada como parte da definio formal de uma relao; historicamente foi definida para no permitir atributos multivalorados, compostos e suas combinaes.
9.3.2.2 Segunda Forma Normal (2FN)

A segunda forma normal baseada no conceito de dependncia funcional total. Uma dependncia funcional X Y uma dependncia funcional total se, na remoo de qualquer atributo A de X significar que a dependncia no mais existe; isto , para todo atributo A X, (X-{A}) -x Y. Por exemplo, na Figura 9.8b, {NSS, PNUMERO} HORAS uma dependncia funcional total (nem NSS HORAS e nem PNUMERO HORAS so DF. Porm, a dependncia {NSS, PNUMERO} ENOME parcial, pois NSS ENOME. Um esquema de relao R est na 2FN se qualquer atributo no-primo A de R for totalmente dependente funcionalmente de qualquer chave de R. Atributo no-primo qualquer atributo que no seja membro de uma chave-candidata. A relao EMP_PROJ da Figura 9.8b est na 1FN, mas no na 2FN. O atributo no-primo ENOME viola a 2FN devido df2, o mesmo acontece com os atributos no-primos PNOME e PLOCALIZAO em df3. As dependncias funcionais df2 e df3 indicam a dependncia parcial da chave-primria {NSS, PNUMERO}, violando assim a 2FN.
(a)
ENOME df1 df2 EMP_DEPT NSS
DATANASC
ENDEREO
DNUMERO
DNOME
NSSGER
(b)
NSS df1
EMP_PROJ PNUMERO
HORAS
ENOME
PNOME
PLOCALIZAO
df2
df3
Figura 9.8
83
Se uma relao no est na 2FN, ela pode ser normalizada em um nmero de relaes na 2FN. As dependncias funcionais df1, df2 e df3 indicadas na Figura 9.9 podem ser consideradas para decompor a relao EMP_PROJ em 3 esquemas de relaes EP1, EP2 e EP3, como mostra a Figura 9.9a. Cada um desses esquemas de relao satisfaz a 2FN. Verifica-se que as relaes EP1, EP2 e EP3 evitam as anomalias que estava sujeita a relao EMP_PROJ.
(a)
NSS df1 EMP_PROJ PNUMERO
HORAS
ENOME
PNOME
PLOCALIZAO
df2
df3 EP1 NSS EP2 PNUMERO HORAS NSS ENOME PNUMERO EP3 PNOME
PLOCALIZAO
df1
df2
df3
(b)
ENOME df1
EMP_DEPT NSS
DATANASC
ENDEREO
DNUMERO
DNOME
NSSGER
ED1 ENOME
NSS
DATANASC
ENDEREO
DNUMERO
ED2 DNUMERO
DNOME
NSSGER
Figura 9.9
9.3.2.3 Terceira Forma Normal (3FN)

A terceira forma normal baseada no conceito de dependncia transitiva. Uma dependncia XY em uma relao R uma dependncia transitiva se existir um conjunto de atributos Z que no um subconjunto de qualquer chave de R, e tanto XZ quanto ZY. Por exemplo, a dependncia NSSNSSGER uma dependncia transitiva em EMP_DEPT da Figura 9.9b. Diz-se que a dependncia de NSSGER sobre o atributo chave NSS transitiva via DNUMERO. Intuitivamente, verifica-se que a dependncia de NSSGER sobre DNUMERO indesejvel uma EMP_DEPT desde que DNUMERO no chave de EMP_DEPT. Um esquema de relao R est na 3FN se ele estiver na 2FN e nenhum atributo no-primo de R dependente transitivamente de qualquer chave de R. A relao EMP_DEPT da Figura 9.9b est na 2FN, pois no h dependncia parcial de nenhum atributo no-primo sobre a chave. Porm, no est na 3FN, pois NSSGER e DNOME so dependentes transitivos de NSS via DNUMERO. Pode-se normalizar EMP_DEPT decompondo-o em dois esquemas de relao na 3FN, ED1 e ED2, como mostra a Figura 9.9b.
84
9.4
Definio Geral (2FN, 3FN, FNBC)
Em geral desejamos projetar nossos esquemas de relaes de modo que eles no tenham dependncias parciais nem transitivas. Esses tipos de dependncias causam as anomalias de atualizao discutidas nas sees anteriores. Os passos para normalizao para as relaes na 3FN que discutimos at aqui probem dependncias parciais e transitivas na chave primria. Essas definies, entretanto, no levam em conta outras chaves candidatas de uma relao, se que existem!! Entretanto nesta seo, trataremos de definies mais gerais de 2FN e 3FN para introduzirmos a Forma Normal de Boyce-Codd. Essas definies mais gerais no afetam a definio de 1FN. Utilizaremos aqui a definio de atributo primo (principal), ou seja, um atributo integrante (parte) de qualquer chave candidata. Assim as dependncias parcial e plenamente funcionais e dependncias transitivas sero agora com relao a todas as chaves candidatas de uma relao.
9.4.2 Definio geral de segunda Forma Normal

Um esquema de relao R est na segunda forma normal (2FN) se todo atributo A em R no for parcialmente dependente de qualquer chave de R, ou em outras palavras, se todo atributo no-primo A em R for completamente dependente em termos funcionais de todas as chaves de R. Considere o esquema da relao LOTES mostrado na figura 9.10a, que descreve pedaos de terra para venda em vrios municpios de um estado. Suponha que existam duas chaves candidatas: #ID_Propriedade e (Nome_Municipio, #LOTE); ou seja, nmeros de lotes so nicos somente dentro de cada municpio, mas nmeros de ID_PROPRIEDADE so nicos ao longo dos municpios em todo seu estado. Com base nas duas chaves candidatas #ID_Propriedade e (Nome_Municipio, #LOTE), sabemos que as dependncias funcionais DF1 e DF2 da figura 9.10a se mantm. Escolhemos #ID_Propriedade como chave primria. Alm disso, tambm supomos que existam mais duas dependncias funcionais adicionais na relao LOTES: - DF3: Nome_Municipio - DF4: rea Preo Imposto
Traduzindo o significado das dependncias funcionais temos que a DF3 diz que o imposto fixo para um dado municpio (no varia lote por lote dentro do mesmo municpio). Enquanto DF4 diz que o preo de um lote determinado por sua rea, independentemente do municpio em que esteja localizado. O esquema da relao LOTES desrespeita a definio geral da 2FN porque IMPOSTO parcialmente dependente da chave candidata (Nome_Municipio, #Lote), devido a DF3. Para normalizar LOTES para 2FN, decompomos o mesmo em duas relaes LOTES1 e LOTES2, mostradas na figura 9.10b. Construmos LOTES1 removendo o atributo IMPOSTO que desrespeita a 2FN de LOTES e colocando-o com Nome_Municipio em uma outra relao LOTES2. Tanto LOTES1 como LOTES2 esto na 2FN. Note que DF4 no desrespeita a 2FN e transportada para LOTES1. (a) esquema relao lotes 1FN. LOTES
#ID_Propriedade Nome_Municipio #Lote rea Preo Imposto
df1 df2 df3 df4
85
(b) esquemas da relao lotes 2FN. LOTES 1

#ID_Propriedade Nome_Municipio #Lote rea Preo
df1 df2 df4 LOTES 2

Nome_Municipio Imposto
df3
(c) esquemas da relao lotes 3FN. LOTES 1A

#ID_Propriedade Nome_Municipio #Lote rea
df1 df2 LOTES 1B

rea Preo
df3 Figura 9.10 (a, b, c) - Normalizao do esquema da relao LOTES.
9.4.3 Definio geral de terceira Forma Normal

Um esquema da relao R est na terceira forma normal (3FN) sempre que uma dependncia funcional no trivial X A se mantiver em R, seja pelo motivo de que: a) X uma superchave de R, ou b) A um atributo primo de R. De acordo com essa definio, LOTES2 est na 3FN. Entretanto, DF4 em LOTES1 viola a 3FN porque AREA no um superchave e PREO no o atributo principal (primo) de LOTES1. Para normalizar LOTES1 para a 3FN, decompomos em LOTES1A e LOTES1B mostrados na figura 9.10c. Construmos LOTES1A retirando o atributo PREO que viola a 3FN de LOTES1 associando-o com AREA (o atributo do lado esquerdo de DF4 que causa a dependncia transitiva) em uma outra relao denominada LOTES1B. Tanto LOTES1A como LOTES1B esto na 3FN. LOTES1 viola a 3FN por que PREO transitivamente dependente de cada uma as chaves candidatas de LOTES1 atravs do atributo no-primo AREA.
9.4.4 Definio da Forma Normal de Boyce-Codd

A forma normal de Boyce-Codd (FNBC) foi proposta como uma forma mais simples que 3FN, mas foi considerada mais restrita na medida em que toda relao que est na FNBC tambm est na 3FN, entretanto o inverso no verdadeiro.
86
A definio formal da FNBC difere ligeiramente da definio da 3FN. Um esquema da relao R est na FNBC se, sempre uma dependncia funcional no-trivial X A se mantiver em R, X for uma superchave de R. A condio b da 3FN est ausente. Preferencialmente o projeto de um banco de dados relacional deve empenhar-se em alcanar a FNBC ou a 3FN para todo esquema da relao. Alcanar o status de normalizao somente na 1FN ou na 2FN no considerado adequado, uma vez que essas formas foram desenvolvidas como caminho para 3FN e FNBC. Para exemplificar a FNBC foi includa uma DF5, em LOTES1A como ilustra a figura 9.11a. Junto com tal dependncia funcional adicionada, assumimos que existam milhares de lotes, mas apenas dois municpios X e Y. Supomos tambm que as reas dos lotes do municpio X so 0,5; 06; ...; 1.0 alqueires e os lotes de Y so 1,1; 1,2; .....; 2,0 alqueires. Nesse caso teramos DF5: AREA Nome_Municipio. A rea de um lote que determina o municpio, conforme especificado por DF5, pode ser representada atravs de 16 tuplas numa relao em separado R(AREA, NOME_Municipio), uma vez que existam somente 16 possveis valores de AREA. Essa representao reduziria redundncia de se repetir a mesma informao em milhares de tuplas de LOTES1A. A FNBC uma forma normal mais restrita que no admitiria LOTES1A e sugeriria a decomposio da mesma, conforme ilustra a figura 9.11a. (a) Normalizao para FNBC com perda da df2 nas relaes decompostas. LOTES 1A
#ID_Propriedade Nome_Municipio #Lote rea
df1 df2 df5 LOTES1AX

#ID_Propriedade rea #Lote
LOTES1AY
rea Nome_Municipio
b) Relao R est na 3FN, mas no na FNBC. R

A B C
Figura 9.11(a, b) Forma normal de Boyce-Codd. Considere agora as seguintes dependncias funcionais da relao leciona da figura 12: DF1: (aluno, disciplina) instrutor DF2: instrutor disciplina Note que (aluno, disciplina) uma chave candidata para essa relao e que as dependncias mostradas seguem o padro da figura 9.11b. Portanto essa relao est na 3FN, mas no est na FNBC. A decomposio desse esquema em dois esquemas no simples porque pode ser decomposto em um de trs pares possveis:

1. (aluno, instrutor) e (aluno, disciplina) 2. (disciplina, instrutor) e (disciplina, aluno) 3. (instrutor, disciplina) e (instrutor, aluno)
87
LECIONA Aluno Disciplina

Narayan Smith Smith Smith Wallace Wallace Wong Zelaya Banco de Dados Banco de Dados Sistemas Operacionais Teoria Sistemas Operacionais Banco de Dados Banco de Dados Banco de Dados
Instrutor
Mark Navathe Ammar Schulman Ahamad Mark Omiecinski Navathe
Figura 9.12 relao leciona est na 3FN, mas no na FNBC. Todas as trs decomposies perdem a dependncia DF1. A mais desejvel dessas trs decomposies a terceira, porque no ir gerar tuplas invlidas aps uma juno. Em geral uma relao que no esteja na FNBC, deve ser decomposta de modo a satisfazer essa propriedade (de ser sem perda de juno), mesmo que isso signifique abster-se da preservao de todas as dependncias funcionais. Esse tpico ser tratado na seo 9.5.
Exerccios 1- Considere uma relao universal R = {A, B, C, D, E, F, G, H, I, J} e o conjunto de dependncias funcionais F = {{A, B} {C}, {A} {D, E}, {B} {F}, {F} {G, H}, {D} {I, J}}. Qual a chave para R? Decomponha R em relaes na 2FN e em seguida na 3FN. 2- Repita o exerccio anterior com o seguinte conjunto de dependncias funcionais G = {{A, B} {C}, {B, D} {E, F}, {A, D} {G, H}, {A} {I}, {H} {J}}. 3- Prove que qualquer esquema de uma relao com dois atributos est na FNBC. 4- Considere a seguinte relao: A 10 10 11 12 13 14 B b1 b2 b4 b3 b1 b3 C c1 c2 c1 c4 c1 c4 TUPLA# #1 #2 #3 #4 #5 #6
a) Dada extenso da relao apresentada, qual(is) dependncia(s) abaixo descritas podem ser mantida (s)? Se a dependncia no pode se manter, explique o porqu, especificando as tuplas que causam violao. A B B C C B B A C A b) A relao mostrada anteriormente tem uma chave candidata? Justifique sua reposta.
5) Considere a relao R(A, B, C, D, E) com as seguintes dependncias: AB C, CD E, DE B Existem chaves candidatas para essa relao? Justifique sua resposta.

6) Considere a relao para livros publicados:
88
LIVRO (ttulo_do_livro, nome_do_autor, tipo_do_livro, preo_de_tabela, afiliao_do_autor, editora) Suponha as que existam as seguintes dependncias: ttulo_do_livro editora, tipo_do_livro tipo_do_livro preo_de_tabela nome_do_autor afiliao_do_autor a ) Em que forma normal est a relao? Justifique sua resposta. b) Aplique a normalizao at que no possa mais decompor as relaes. Justifique as razes de cada decomposio.
89
10 Data Warehouse Uma viso geral

Warehousing6 uma tcnica utilizada para recuperao e integrao de dados a partir de fontes distribudas, autnomas e, possivelmente, heterogneas. Estes dados so armazenados em um grande depsito chamado de Data Warehouse. Um data warehouse sumaria os dados que so organizados em dimenses, disponibilizando-os para consultas e anlises atravs de aplicaes OLAP (On-Line Analytical Processing) e sistemas de suporte deciso. Os data warehouses vm sendo muito utilizados pelas empresas, j que proporcionam um alicerce slido de integrao de dados corporativos e histricos para a realizao de anlises gerenciais. Sua construo e implementao so feitas de uma maneira passo a passo, organizando e armazenado os dados sob uma perspectiva de longo prazo. Assim, partindo-se de dados histricos bsicos, pode-se realizar anlises de tendncias. Por sua caracterstica bsica integrao de dados provenientes de vrias fontes diferentes a etapa mais complexa na implementao de um data warehouse o processo de carga. Neste processo, os dados distribudos pelos vrios ambientes operacionais (bases de dados de produo, que contm os dados utilizados pelos vrios sistemas transacionais de uma empresa) devem ser selecionados, trabalhados com o objetivo de padronizao e limpeza, transferidos para o novo ambiente e finalmente carregados, sempre atendendo ao padro da modelagem utilizada para o data warehouse. Este processo feito periodicamente, sendo que sua freqncia depende de vrios fatores relacionados ao modelo de negcios utilizado pela empresa e, normalmente, no menor que 24 horas. Desta forma, podemos dizer que os dados armazenados no data warehouse so, para todos os propsitos prticos, uma longa srie de vises do banco de dados, tiradas ao longo do tempo. Uma vez que os dados so armazenados no data warehouse, eles no mais sofrem atualizaes, sendo, portanto, um ambiente apenas de carga e acesso. Aps sua criao e primeira carga, o data warehouse passa a sofrer cargas incrementais que devem refletir o ambiente operacional ao longo do tempo tornando-o um imenso repositrio para os sistemas de apoio deciso.
10.1 O que o Data Warehouse

Um data warehouse existe para responder as questes que as pessoas tm sobre os negcios. Esta funo contrasta fortemente com o propsito dos sistemas transacionais que as empresas utilizam e requer que o desenho ou o modelo de dados do data warehouse siga princpios completamente diferentes. As tcnicas de modelagem dimensional, se aplicadas corretamente, garantem que o projeto do data warehouse reflita a forma de pensar dos gerentes de negcio e possa ser utilizado para atend-los. Em todas as empresas, o processo de criao de negcios composto por uma srie de eventos que caracterizam suas atividades principais. A natureza e freqncia destes eventos variam conforme o tipo de negcio em que uma empresa est envolvida: um produto manufaturado, uma conta creditada enquanto outra debitada, um assento reservado, um pedido includo etc. O controle e processamento corretos destes eventos so crticos para uma empresa, sendo que estas atividades contribuem para seu sucesso ou fracasso. Para isso, a maioria das organizaes possui um conjunto de sistemas conhecidos como sistemas transacionais ou sistemas OLTP (OnLine Transaction Processing) que capturam os eventos de forma individual e todos os detalhes associados a eles. Cada um destes sistemas est encarregado de um tipo diferente de atividades e trata das transaes de negcios segundo um conjunto de regras que garanta sua consistncia e o armazenamento de todos os detalhes associados. Para um sistema OLTP, os princpios de desenho como normalizao e consistncia de transaes so extremamente crticos. Porm, por tratar as transaes de forma individual, os sistemas OLTP falham no que se refere a questes sobre o processo do
O termo Warehousing no possui traduo adequada para o portugus.
90
negcio, como quais foram os produtos mais vendidos durante o ms passado? ou quais produtos esto perdendo market share? ou ainda quais so nossos clientes mais fiis?. O data warehouse construdo para responder questes que no esto limitadas s transaes individuais, porm, tratam do processo como um todo. Para isso, o desenho do data warehouse deve refletir a forma com que os especialistas enxergam o negcio e este o ponto chave que distingue um data warehouse de um sistema OLTP. A tcnica utilizada para se obter um modelo para o data warehouse que identifique e represente a informao importante para o modelo de negcios a modelagem dimensional. Quando bem definido, o modelo dimensional pode ser uma ajuda de valor incalculvel para as reas de negcio, apoiando e otimizando todo o processo de tomada de decises. Um data warehouse corporativo pode ser definido em termos de seis caractersticas bsicas que o diferenciam dos outros sistemas na empresa. Os dados em um data warehouse so: 1. 2. 3. 4. 5. 6. Separados dos sistemas transacionais da empresa e populados a partir destes; Disponveis, na sua totalidade, para a atividade de serem interrogados pelos usurios de negcios; Integrados para ser uma base nica e padro para o modelo da empresa; Associados informao temporal e a perodos de tempo definidos, como fechamentos mensais ou baseados no ano fiscal; Orientados por assunto, ou seja, organizado para descrever o desempenho do negcio; Acessvel aos usurios que tenham um conhecimento limitado de sistemas computacionais ou estruturas de dados.
Alm destas caractersticas, podemos citar sua no-volatilidade, ou seja, uma vez que o dado foi carregado no data warehouse, no deve mais sofrer alteraes.
10.2 O modelo dimensional e suas implementaes

A modelagem de um data warehouse normalmente utiliza uma abordagem diferente da modelagem entidade-relacionamento, que a maneira convencional para desenhar uma base de dados relacional contemplando toda a teoria de normalizao dos dados. O modelo dimensional (tambm chamado de multidimensional), utilizado para definir um data warehouse, representa os indicadores importantes para uma rea de negcios, que so chamados de fatos ou mtricas e os parmetros, chamados dimenses, atravs dos quais estas mtricas so vistas. A Figura 1 mostra um exemplo de modelo dimensional para um processo de pedidos. As mtricas definidas esto no quadro central e as dimenses esto representadas nos quadros ao redor das mtricas. As mtricas so sumariadas ou detalhadas de acordo com o interesse da anlise a ser feita sobre os dados. Este modelo fcil de ser entendido por uma pessoa da rea de negcios, j que as coisas que eu avalio esto na parte central do diagrama e as formas de se olhar para elas esto nos quadros em volta.
91
Figura 1 - Modelo dimensional para um processo de pedidos
de fcil percepo que estes quadros facilmente se transformaro em tabelas, que podem ser utilizadas para armazenar toda a informao. Um modelo como este no muda muito ao ser implementado em um banco de dados relacional. Cada quadro com os atributos de uma dimenso se torna uma tabela, chamada de tabela dimenso, na base de dados e o quadro central se torna uma grande tabela, chamada tabela fato, que contm, por vezes, milhes ou bilhes de linhas. Contudo, os modelos dimensionais nem sempre so implementados em bases de dados relacionais. Existem no mercado os bancos de dados multidimensionais, ou MDDBs, que armazenam as informaes em um formato diferente, freqentemente chamados de cubos. Os cubos so construdos de tal forma que, cada combinao de atributos das dimenses com uma mtrica ou pr-calculado ou calculado muito rapidamente. Entretanto, a natureza de uma base de dados multidimensional tambm significa que no possvel manipular volumes de dados extremamente grandes j que, uma transao de anlise dos dados, com uma ferramenta OLAP, que envolva um grande volume de dados vai consumir grande quantidade de memria ou simplesmente no se efetua. Alm disso, o nmero de atributos dimensionais armazenados em um cubo pode impactar o tamanho e o desempenho do cubo. Uma das alternativas para solucionar estes problemas pode ser a implementao do modelo dimensional em um banco de dados relacional e, aps isto, utiliz-lo como fonte para os cubos. Esta abordagem muito utilizada em empresas que querem executar anlises em pequenos subconjuntos de um grande conjunto de dados armazenados em um data warehouse. Quando esta abordagem implementada, o data warehouse como um todo fica armazenado no banco de dados relacional, enquanto que os cubos, contm partes ou segmentos do data warehouse que so chamados de data marts. Uma outra alternativa utilizar uma ferramenta de consulta acessando o data warehouse no banco relacional transformando o resultado da consulta em um cubo que permita a anlise rpida dos dados. Estes cubos podem ser gerados no computador do usurio ou em um servidor de aplicaes. Esta abordagem interessante para os usurios, j que no requer a administrao centralizada destes cubos. importante notar, porm, que o usurio fica sujeito aos limites de capacidade de processamento de seu PC ou do servidor de aplicaes.
92
Uma arquitetura para o Data Warehouse apresentada na Figura 2. Nesta arquitetura, os dados so provenientes dos sistemas operacionais. Estas fontes so conectadas a wrappers ou monitores que efetuam o processo de seleo, transformao e limpeza dos dados. Alm disso, monitoram as alteraes nas fontes de dados propagando-as a um componente integrador, que combina os dados selecionados a partir das diferentes fontes operacionais. Estes dados, j consistentes, so propagados para o warehouse. O metadados contm informaes relevantes sobre a criao, gerenciamento e uso do data warehouse e funciona como uma ponte entre os usurios do data warehouse e os dados nele contidos. O warehouse pode ser acessado atravs de um servidor OLAP, que tem como objetivo, apresentar as informaes multidimensionais para as ferramentas de acesso, anlise, geradores de relatrios, planilhas e ferramentas de minerao de dados (Data Mining tools). Basicamente, o servidor OLAP interpreta as consultas dos usurios convertendo-as em instrues adequadas, muitas vezes complexas, para o acesso ao data warehouse. Atualmente existem dois tipos de soluo para implementao para acesso ao repositrio de data warehouse. Uma a utilizao de modelos relacionais associados a tecnologias de buscas multidimensionais em cubos pr-construdos (MOLAP). Outra, a utilizao de gerenciadores relacionais incrementados com tecnologias de ndices bitmap e recuperao de dados com listas invertidas (ROLAP). Na Figura 2 possvel tambm identificar as vrias camadas que compem tal arquitetura: 1. Ferramentas de acesso para os usurios; 2. Servidor OLAP (MOLAP-ROLAP) 3. Sistema de gerenciamento do data warehouse e ferramentas para selecionar, transformar, limpar, integrar e copiar os dados; 4. Dados dos sistemas operacionais.
93
Figura 2 Arquitetura de data warehouse proposta por [17]
10.2.1 O modelo formal da base de dados multidimensional

O modelo multidimensional implementado em uma base de dados relacional foi formalmente definido por (Baralis, Paraboschi &Teniente), e ser apresentado nesta seo. A estrutura bsica deste modelo pode ser representada por um diagrama entidaderelacionamento como na Figura 3. Definio 2.3.1 Dn, F, onde:

Uma base de dados multidimensional uma coleo de relaes D1,...,
Cada Di uma tabela dimenso, isto , uma relao caracterizada por um identificador que identifica unicamente cada tupla (di a chave primria de Di). F uma tabela fato, isto , uma relao que conecta todas as tabelas D1,..., Dn; o identificador de F composto pelas chaves estrangeiras di,..., dn de todas as tabelas dimenso conectadas. O esquema de F contm um conjunto de atributos
94
adicionais V (que representam os valores sobre os quais sero aplicadas as funes de agregao). As tabelas dimenso podem conter hierarquias.
Figura 3 Representao Entidade-Relacionamento de uma base de dados multidimensional
Definio 2.3.2 Seja D uma tabela dimenso com o identificador d. Uma hierarquia de atributos em D um conjunto de dependncias funcionais FDD = {fd0, fd1 ,..., fdn}, onde cada fdi caracterizado por dois conjuntos de atributos Ali Attr(D) e Ari Attr(D) (chamados respectivamente de lado esquerdo e lado direito da dependncia); a dependncia representada por fdi : Ali Ari . Cada dependncia funcional fdi uma restrio ao contedo da tabela dimenso D, sendo que: para cada par de tuplas t1 e t2 D, t1 [Ali] = t2 [Ali] t1 [Ali] = t2 [Ari] . Uma dependncia fd0 com Al0 = {d} e Ar0 = {Attr(D) - d} estar sempre presente em FDD. As dependncias funcionais devem ser acclicas, isto , o grafo obtido pelo desenho de um arco partindo de ax e chegando em ay, deve ser acclico, se fdi FDD | ax Ali ay Ari . Exemplo: Vamos considerar um exemplo prtico, a base de dados multidimensional para uma grande cadeia de lojas de varejo. Com um grande nmero de lojas, cada uma delas sendo um supermercado que vende uma ampla variedade de diferentes produtos. A base de dados multidimensional armazena informao sobre cada venda, por loja, por dia e considera tambm as promoes em cada produto vendido. Podemos identificar as seguintes dimenses: Product7, que caracteriza cada produto vendido, Store, que caracteriza cada ponto de venda, Time e Promotion, que descreve as caractersticas das promoes dos produtos. A tabela fato fornece as informaes sobre as vendas, sobre as quais sero realizadas as anlises financeiras. Inclui identificadores para todas as dimenses e vrios atributos descrevendo as vendas (como valor da venda, quantidade vendida, etc.) Se considerarmos a dimenso Store, do exemplo acima, com chave s e restrita a um conjunto de atributos {z, c, st, n}, que representam respectivamente zip code, county, state e number of sale clerks. A dimenso tem a seguinte hierarquia de atributos: {fd0 : s {z, c, st, n}, fd1 : z c, fd2 : c st} Definio 2.3.3 Uma hierarquia de atributos da base de dados multidimensional FDDB a unio das hierarquias de atributos DFDj de todas as dimenses Dj existentes na base de dados multidimensional.
7
Por razes didticas, os nomes de tabelas e atributos sero mantidos no idioma original, ingls.
95
10.3 Aspectos da Modelagem Dimensional

10.3.1 Caractersticas
Conforme j comentado, o modelo dimensional poderoso, pois reflete a maneira de pensar dos especialistas de negcios e responde s suas necessidades de informaes. A tecnologia relacional de bancos de dados possibilita ao data warehouse ser utilizado para responder as questes de forma rpida e precisa. Para isso, so necessrios trs componentes essenciais, a saber: 1. Os dados provenientes das vrias fontes distribudas pela empresa e armazenados em um nico local; 2. Ferramentas que possibilitem a anlise das informaes armazenadas de forma rpida, flexvel com alta qualidade de apresentao e 3. O conhecimento do especialista de negcios. Existem inmeras ferramentas, como as citadas no item 2 acima, disponveis no mercado e chamadas de OLAP. Estas ferramentas permitem ao usurio visualizar os vrios nveis de detalhamento da informao, sob as vises das diferentes dimenses definidas no modelo e tm sido alvo de vrios trabalhos acadmicos. O conhecimento do especialista de negcios outro componente essencial, j que apenas ele pode tirar as concluses das informaes apresentadas, com o objetivo de tomada de decises da corporao. Em linhas gerais, o processo de implementao de um data warehouse est dividido nas seguintes etapas: 1. Levantamento do processo de negcio a modelar; 2. Definio dos modelos conceitual, lgico e fsico; 3. Definio do processo de carga; Dentre todas as etapas citadas acima, a que envolve o processo de carga de longe a mais complexa. Alm de trazer os dados de vrios sistemas transacionais diferentes, o processo engloba atividades de verificao, padronizao, limpeza e transformao dos dados antes da carga. A definio da periodicidade da carga depende da natureza do negcio que compe o data warehouse e do tipo de informao armazenada. Algumas reas de negcios requerem carga diria, enquanto que outras necessitam apenas de cargas mensais. Seja qual for a periodicidade escolhida, fica claro que o data warehouse no est sincronizado em tempo real com os sistemas transacionais. Para algumas aplicaes, esta caracterstica esttica do data warehouse no compromete o resultado das anlises porm, para outras, um data warehouse dinmico, ou seja, sincronizado com os sistemas transacionais, essencial. Para implementar um data warehouse dinmico seria necessrio definir uma arquitetura que permitisse propagar as atualizaes nas bases transacionais no instante em que elas ocorrem. Atualmente, pode-se dizer que os data warehouses implantados so de natureza esttica, tendo processos de carga de alta complexidade e que requerem um grande tempo de processamento. As prximas sees detalham vrios aspectos envolvidos na modelagem do data warehouse.
10.3.2 Conceitos da modelagem

A modelagem dimensional combina tabelas fato que armazenam dados histricos temporais (normalmente numricos), indexadas por chaves dimensionais que esto descritas nas tabelas dimenso correspondentes. As tabelas dimenso contm informaes como, por exemplo: perodos de tempo, produtos, mercados, organizaes, contas, vendedores e clientes e inclui as descries e os atributos destas dimenses. Alm disso, as tabelas dimenso contemplam toda a estrutura da dimenso, como os agrupamentos dos produtos em marcas e em categorias, as cidades em estados, em regies e em pases e assim por diante. As tabelas fato contm as mtricas ou os fatos a serem analisados dentro do modelo de negcios. Cada um destes fatos est diretamente relacionado s dimenses, que descrevem suas condies de ocorrncia. Todo o relacionamento entre a tabela fato e as tabelas dimenso feito por meio de chaves.
96
Uma consulta executada neste modelo dimensional, geralmente se inicia por uma pesquisa nas tabelas dimenso, aplicando-se os filtros de valores e obtendo-se como resultado um conjunto de chaves. Aps isso, o acesso feito tabela fato, garantindo assim a preciso no acesso aos dados atravs de uma estrutura completa de chaves, eliminando-se um table scan e, com isso, obtendo-se o melhor desempenho possvel de uma tecnologia relacional. O conceito de armazenamento das dimenses separadamente garante que a base de dados trate os vetores esparsos de maneira eficaz, isto , sem armazenar vazios, assegurando o acesso mais eficiente possvel. O modelo dimensional pode ser implementado utilizando vrios tipos de esquemas diferentes. Provavelmente, o star schema, apresentado por R. Kimball, seja o primeiro esquema utilizado para representar o data warehouse implementado em um banco de dados relacional.
Figura 4 - Esquema para um processo de pedidos Apesar de ser o mais conhecido, o star schema no o nico. De fato, existe uma srie de variaes que sero analisadas a posteriori. Porm, antes de iniciar a modelagem em um esquema particular, temos que definir o processo de negcio a ser modelado. A Figura 4 mostra um exemplo de esquema para um processo de pedidos. A tabela central a tabela fato e as tabelas ao redor desta so as dimenses. Neste exemplo esto representadas as dimenses Produto, Tempo (data), Cliente e Vendedor (incluindo informaes de ordem geogrfica). Os fatos representados so: valor do pedido, margem, custo, quantidade pedida e nmero do pedido. Depois de definido o escopo do data warehouse, os prximos passos so: definir a granularidade das informaes representadas na tabela fato, identificar as dimenses e enumerar as mtricas ou fatos. A seguir daremos uma descrio sucinta sobre cada uma destas etapas e, na seqncia, mostraremos os tipos de esquemas bsicos e suas variaes.
10.3.2.1
A granularidade das informaes
Como j dito, uma das primeiras decises feita para modelar o data warehouse est relacionada com o nvel de detalhe das mtricas a serem armazenadas. Este nvel de detalhamento conhecido como granularidade da tabela fato. muito importante que todas as
97
linhas na tabela fato sejam armazenadas com informaes exatamente no mesmo nvel de detalhes. Como exemplo, um processo de pedidos teria sua granularidade definida no nvel de detalhe da linha individual do pedido. Se forem armazenados diferentes nveis de detalhamento na tabela fato, a utilizao da base de informaes ficaria bastante prejudicada. Suponha que a maioria das informaes no nvel da linha de detalhe do pedido esteja armazenada, sendo que algumas informaes foram armazenadas no nvel do cabealho do pedido. No nvel de detalhe da linha do pedido existe um relacionamento com cliente, produto, representante comercial e tempo. Porm, no nvel do cabealho do pedido, o relacionamento com os produtos especficos por pedido desaparece. As informaes relevantes que estejam em diferentes nveis de granularidade deveriam ser armazenadas em tabelas fato diferentes. Em geral, podemos dizer que, a aderncia de uma tabela fato a uma certa granularidade requer que as chaves que relacionam as linhas da tabela fato s linhas das dimenses nunca sejam nulas. Um relacionamento opcional a uma dimenso geralmente indica um problema de granularidade.
10.3.2.2
As dimenses
Uma vez que o nvel de granularidade esteja definido, a escolha das dimenses a serem utilizadas deve ser o prximo passo. O ideal seria definir uma dimenso com um grande nmero de atributos, representando um rico conjunto de detalhes sobres o processo de negcio ( comum que as dimenses apresentem 100 ou at mesmo 200 atributos em uma nica tabela dimenso). As tabelas dimenso contm informaes sobre as dimenses dos dados, ou seja, tempo, produto, mercado, contas e assim por diante e devem ser desenhadas a partir da perspectiva do usurio. Por esta razo, os atributos e suas descries devem ser definidos de forma significativa para o usurio e adequados para a posterior exibio em relatrios. As principais funes da tabela dimenso so reunir os atributos que sero utilizados para qualificar as consultas e cujos valores sero utilizados para agrupar e sumariar as mtricas. Cada tabela dimenso deve ter mltiplos atributos que contenham valores ou textos que possam ajudar a descrever a chave. Estas colunas de atributos so utilizadas para filtrar o contedo da dimenso. Alm disso, a utilizao de atributos do tipo inteiro, quando apropriados, favorecem as operaes de filtragem como maior que, menor que e entre. Os atributos de uma dimenso podem compor uma hierarquia ou ser apenas descritivos. Por exemplo, em uma dimenso produto, a hierarquia pode ser composta pelos atributos item, marca, tipo e diviso. A hierarquia definida na dimenso requisito bsico para as funes de agregao das mtricas contidas na tabela fato. Atravs dos agrupamentos dos elementos na hierarquia, os usurios podem analisar os fatos em um nvel maior ou menor de detalhes, conforme sua necessidade especfica. Este conceito de hierarquia, que permite a implementao de agregaes das mtricas, muito importante tambm para a dimenso Tempo e, vale ressaltar que muito raro um modelo dimensional que no inclua a dimenso Tempo como uma dimenso fundamental. Deve-se resistir ao impulso de aplicar as regras de normalizao nas tabelas dimenso. O processo de normalizao, separando os atributos em vrias tabelas diferentes faz com que as consultas fiquem bem mais complexas, o banco de dados gaste mais tempo para recuperar os dados e, por conseqncia, os usurios esperem mais por suas respostas. Este custo muito alto como resultado da economia de apenas uns poucos bytes em uma tabela dimenso que, em comparao com uma tabela fato, minscula. Manter as tabelas dimenso desnormalizadas faz com que as hierarquias naturais contidas nos dados fiquem bem definidas. No exemplo anterior, de pedidos, nota-se que alguns exemplos como a dimenso Tempo (Data) inclui os atributos Ano, Trimestre, Ms e Data (que inclui o dia), juntamente com outros atributos relacionados a uma data especfica. Estes componentes no foram colocados em uma srie de tabelas progressivamente mais detalhadas. Em vez disso, esto em uma nica tabela que deixa clara a hierarquia. Por exemplo, enquanto que a ocorrncia do ano de 2004 possa aparecer na tabela 365 vezes, isto ficar invisvel ao usurio. Quando as mtricas forem sumariadas por ano, apenas uma ocorrncia de 2004 aparecer no relatrio. Um atributo muito importante da tabela dimenso sua chave. A chave primria de uma tabela dimenso dever ser sempre um atributo nico e definido pelo sistema com um valor genrico. Por questes de desempenho, no se utilizam chaves compostas por vrias partes nem
98
tampouco chaves concatenadas. Tambm no so utilizados as chaves ou os identificadores provenientes de outros sistemas como, por exemplo, cdigo do cliente ou cdigo do produto. Existem vrias razes para se utilizar chaves genricas em vez de chaves com valores significativos. Em caso de alteraes de atributos de um cliente, por exemplo, seu endereo, um tratamento especial seria necessrio e a insero deste mesmo cliente, com seu novo endereo, com outra chave. Se o cdigo do cliente for utilizado como chave primria isto no ser possvel. Os tratamentos de alteraes sero analisados neste trabalho, em sees posteriores.
10.3.2.3
Os fatos
Aps identificao da granularidade e das dimenses, o momento de focalizar a tabela fato. Para isso, comea-se definindo quais mtricas ou fatos deseja-se avaliar no data warehouse. Estes fatos so os nmeros que sero analisados atravs das diferentes dimenses. A seleo dos fatos para compor o modelo do data warehouse relativamente simples: uma vez que a rea de negcios esteja definida, a lista de fatos a serem utilizados responde a questo: O que estamos avaliando?. O exemplo, representado pelas Figuras 1 e 4, ilustra em suas respectivas tabelas centrais, quais so os valores relevantes para a anlise do processo de pedidos. Existem trs tipos de mtricas ou fatos, discutidos na prxima seo.
10.3.3 Os trs tipos de mtricas

As mtricas mais comuns so as completamente aditivas. Diz-se que uma mtrica completamente aditiva, quando faz sentido sumariz-la adicionando seus valores ao longo de qualquer dimenso. No exemplo de pedidos, o valor do pedido, a margem, o custo e a quantidade pedida so todas mtricas completamente aditivas. Apesar de serem armazenadas na tabela fato para um determinado produto, um cliente, um vendedor e uma data especfica, pode-se facilmente sumariz-las da maneira que for de interesse. Para verificar os pedidos de um determinado ms, basta adicionar os valores dos pedidos de todas as datas daquele ms. O mesmo ocorre para verificar a margem obtida para uma determinada categoria de produtos. Basta adicionar os valores de margem para todos os produtos de uma determinada categoria. As mtricas completamente aditivas so bastante teis e poderosas, j que no existem limitaes em sua utilizao. Podem ser facilmente sumariadas para qualquer combinao de valores das dimenses. Em contraste total com este tipo de mtrica, tm-se as mtricas no aditivas, que no podem ser adicionadas ao longo dos valores das dimenses. Considere a mtrica margem, expressa como uma porcentagem de vendas, tambm denominada margem percentual. Esta mtrica representa a margem como percentual e no mais como valor expresso na moeda corrente. Seria muito simples adicionar esta mtrica tabela fato, porm, esta teria pouca utilidade, j que no poderia sumariz-la de acordo com a dimenso de interesse. Por exemplo, em uma determinada data, um vendedor vende a um cliente 4 tipos diferentes de produtos, cada um deles com uma margem percentual de 25%. No faz sentido incluir os quatro valores de margem percentual para calcular a margem total para este pedido. Aparentemente, conclui-se que este tipo de mtrica no pode ser utilizada na tabela fato do exemplo acima. Na verdade, esta mtrica derivada de outras duas mtricas que so aditivas: margem e valor do pedido. A soluo , portanto, armazenar na tabela fato apenas seus componentes, que so completamente aditivos, sendo que o clculo para expressar a margem percentual dever ser feito pela aplicao, que neste caso a diviso da margem pelo valor. O terceiro tipo de mtrica a semi-aditiva. A mtrica semi-aditiva pode ser sumariada ao longo de determinadas dimenses, porem no todas. Considere como exemplo o gerenciamento de saldo das contas de um banco. O saldo armazenado no final de cada dia, para cada cliente, por conta ao longo do tempo. Em alguns casos este saldo aditivo. Se um cliente tem uma conta corrente e uma conta poupana, pode-se adicionar os saldos de cada conta no final de um dia e obter resultado significativo. possvel tambm adicionar os saldos de uma determinada agncia para obter um panorama da situao geral de cada localidade. Entretanto, no faz o menor sentido adicionar o saldo de um cliente ao longo do tempo. Por esta razo, a mtrica saldo considerada semi-aditiva.
99
Esse tipo de atributo no aditivo ou semi-aditivo pode ser agregado ou sumariado utilizando-se outros operadores como mdia, mximo ou mnimo. o caso da mtrica temperatura, que considerada no aditiva, j que adicionar temperaturas dificilmente faz sentido.
10.3.4 Outros elementos da tabela fato

Alm das mtricas, cada tabela fato tem uma chave primria. Esta chave primria composta por vrias colunas, sendo que cada uma delas corresponde logicamente a uma chave na tabela dimenso. Cada elemento componente da chave deve, portanto, estar representado e descrito em uma tabela dimenso correspondente, que logicamente se une a uma ou mais tabelas fato atravs de colunas idnticas. Ento, a chave primria de uma tabela fato uma chave composta por um subconjunto de chaves estrangeiras para as tabelas dimenso. A dimenso Tempo sempre representada como parte da chave primria. A Figura 5 ilustra uma tabela fato que contm o valor das vendas e a quantidade de unidades vendidas, logicamente unida a uma tabela dimenso de Mercado correspondente. Esta Figura no representa as dimenses Produto e Tempo.
Figura 5 Juno lgica entre tabelas fato e dimenso
Ocasionalmente, no necessrio armazenar nenhuma mtrica em uma tabela fato. Por vezes, o simples armazenamento de um relacionamento entre as dimenses em um certo ponto do tempo tudo que uma rea de negcios necessita como mtrica. Este tipo de tabela fato a tabela sem fato (do original factless fact table). O exemplo mais tpico deste tipo de tabela fato o controle de freqncia de alunos em determinadas disciplinas. No existe uma mtrica associada. Apenas a existncia do relacionamento entre as dimenses j um indicativo suficiente para o processo de anlise. Este tipo de tabela encontra-se ilustrado na Figura 6. Pode ocorrer que a mesma tabela fato tenha mltiplas chaves estrangeiras, como parte de sua chave primria, que se relacionam com a mesma dimenso. Por exemplo, o mesmo fato ter mltiplas datas associadas a ele, como no caso da tabela fato de remessa de produtos, onde
O.K. Takai; I.C.Italiano; J.E. Ferreira. 100
duas chaves estrangeiras, data da remessa e data do pedido, esto associadas a uma mesma tabela dimenso tempo. A Figura 7 ilustra esta situao. Neste caso, no necessria a criao de duas tabelas dimenso data. Em vez disso, vises ou sinnimos podem ser utilizadas para referenciar duas cpias virtuais da mesma tabela dimenso em uma nica instruo SQL, no momento da consulta.
Figura 6 Um exemplo de tabela fato do tipo factless
Figura 7 Relacionamento mltiplo entre uma tabela fato e uma dimenso
10.4 Os esquemas bsicos e suas variaes

Aps a definio do modelo conceitual, inicia-se o modelo lgico e sua conseqente implementao fsica. A implementao fsica do modelo dimensional, em uma base de dados relacional, pode ser feita de vrias formas diferentes. No entanto, para todos os esquemas, os fatos e as dimenses so implementados em tabelas fsicas, onde cada linha nica e identificada por uma chave genrica, j discutida anteriormente. Nas prximas sees, os esquemas bsicos, conhecidos como star schema e snowflake schema, e suas variaes sero analisados.
10.4.1 O esquema Star clssico

Provavelmente, o Star schema, apresentado por R. Kimball, seja o primeiro esquema utilizado para projetar um data warehouse implementado em um banco de dados relacional. Neste esquema, a tabela fato contempla as seguintes caractersticas: Uma chave primria composta, sendo um elemento da chave para cada dimenso; Cada elemento chave para a dimenso deve ser representado e descrito na tabela dimenso correspondente, para efetuar o join; Opcionalmente, uma ou mais mtricas ou fatos a serem avaliados; Pode armazenar as mtricas sumariadas em diferentes nveis de agregao. Uma tabela dimenso definida para cada dimenso do negcio a ser analisada, contendo: Uma chave genrica, gerada pelo sistema; Uma coluna de descrio genrica para a dimenso ou colunas de descrio para cada atributo da hierarquia; Atributos que permitam efetuar os filtros;
Um indicador nvel, para estabelecer o nvel da hierarquia a que se refere a linha da tabela; Valores nulos ocasionais, dependendo do nvel hierrquico da linha. O objetivo de se armazenar toda a hierarquia possibilitar, durante as consultas, a utilizao de filtros que permitam a agregao ou sumrio dos fatos nos vrios nveis hierrquicos.
Figura 8 (genrica).
(a.) Tabela dimenso em detalhes com apenas uma descrio (b.) Tabela dimenso com uma descrio para cada nvel da hierarquia Star expandido.
A Figura 8 (itens a e b) mostram os detalhes de uma tabela dimenso, denominada Geografia, que descreve e define uma hierarquia entre a loja, a cidade, o estado (UF) e a regio onde esta se localiza. Na Figura 8a encontrada uma das possibilidades, com apenas uma descrio genrica para toda a dimenso; j na Figura 8b colunas de descrio especficas para cada elemento da hierarquia so definidas. importante notar que no existe uma preocupao com a normalizao das tabelas no data warehouse, conforme j exposto no item 3.2.2 acima. Este um dos aspectos que diferenciam bastante a modelagem do data warehouse da modelagem convencional. Outro aspecto a destacar que o indicador nvel no precisa ser numrico e pode conter o nome do nvel da hierarquia, como por exemplo: cidade, loja, ms etc. A dimenso Tempo uma dimenso especial, sendo diferente de todas as outras dimenses. Esta dimenso requer alguns atributos comuns a todas as dimenses e trs atributos especiais que sero de extrema importncia no momento das consultas. As colunas que devem compor a dimenso Tempo so:

Chave nica genrica, gerada pelo sistema, preferencialmente numrica e inteira, para ligao lgica com a tabela fato; Descrio do tempo contido naquela linha. Conforme os exemplos citados na Figura 8, esta descrio pode ser nica para a tabela ou especfica para cada nvel da hierarquia; Atributos da hierarquia, como nas outras dimenses; Nvel ou Resoluo, que indica o nvel da hierarquia representado naquela linha, que pode ser numrico ou um pequeno texto; Seqncia na resoluo, que indica a seqncia de um perodo de tempo dentro do nvel ou resoluo ao qual ele pertence. Este valor um nmero inteiro
consecutivo que designa a ordem cronolgica para todas os dias, meses, semestres, anos etc, ou seja, para todos os perodos de tempo existentes na tabela dimenso. A seqncia definida dentro de cada nvel ou perodo de resoluo, sem repeties e, h recomendaes de que sejam utilizados intervalos de valores para estabelecer a seqncia. Por exemplo, para a seqncia de anos a numerao seria de 1 a 10, para semestres, entre 100 e 200, todos os meses estariam entre 500 e 999 e todos os dias teriam seqncias numeradas a partir de 1.000. Na Figura 9 vemos que a seqncia na resoluo para Janeiro de 1999 500, para Fevereiro de 1999 501, Maro de 1999 tem seqncia 502 e assim por diante. importante ressaltar novamente que o valor para esta coluna deve ser nico dentro de um perodo de resoluo;
Indicador Corrente, se utilizado em conjunto com a coluna de seqncia na resoluo, descrita no item anterior, indica qual o perodo de tempo dentro da resoluo especificada, que deveria ser definido como corrente. Com isto, possvel definir qual ser o tempo corrente para as consultas: a informao carregada mais recentemente, a data de hoje ou algum perodo de tempo futuro. A utilizao desta coluna permite que determinadas condies de negcio estabeleam o momento em que os dados estaro disponveis para os usurios finais. Esta coluna , normalmente, definida como um caractere e preenchida com S ou N, onde S indica que o dado j foi carregado no data warehouse. O perodo de tempo corrente, dentro da resoluo (pode ser o dia corrente, o ms corrente etc.), ser aquele que contiver na coluna Indicador Corrente o valor de S e o maior valor na coluna Seqncia na Resoluo, descrita no item anterior.
Figura 9 Tabela representando a dimenso Tempo, com as colunas especficas para este tipo de dimenso. Nem sempre possvel capturar todas as mtricas e dimenses importantes para um modelo de negcios, em um nico esquema Star. Ao contrrio, a existncia de mltiplas tabelas fato a norma, definindo um modelo de mltiplas estrelas. Cada estrela composta por uma tabela fato e suas dimenses associadas.
O principal fator que pode levar separao das mtricas em diferentes tabelas fato o modelo de negcios analisado. Um processo de negcios pode envolver diferentes conjuntos de dimenses e as mtricas relacionadas a cada processo podem estar sendo coletadas em diferentes intervalos de tempo. O esquema Star desenhado para simplicidade e velocidade nas consultas. Podemos citar como vantagens, na sua utilizao, os seguintes aspectos:

Facilidade de entendimento do modelo, principalmente por parte do usurio final; Excelente desempenho, devido ao uso de chaves genricas, geralmente numricas e inteiras; Facilidade na definio das hierarquias; Nmero de operaes de join reduzidas, j que o modelo implementa todos os nveis da hierarquia das dimenses em apenas uma tabela por dimenso alm de estar bastante desnormalizado; O metadados simples.
Na Figura 10 est representado um esquema Star clssico, composto por uma tabela fato e suas dimenses Geografia, Produto e Tempo associadas.
Figura 10 Representao de um data warehouse em esquema Star clssico
Apesar de amplamente utilizado, o esquema Star apresenta alguns problemas. O primeiro deles est relacionado ao indicador nvel, presente em todas as tabelas dimenso. Este indicador deve ser utilizado em todas as consultas, j que a mesma tabela dimenso armazena informaes sobre todos os nveis da hierarquia. Durante a construo da consulta, o usurio deve conhecer a estrutura da base de dados, para poder especificar o nvel da informao a ser pesquisada. Este indicador pode ser causa potencial para erros j que, se for esquecido ou mal utilizado, pode levar a resultados incorretos e baixa flexibilidade. Alm disso, se a estrutura da dimenso for alterada, incluindo ou eliminando algum nvel da hierarquia, o data warehouse necessitar de alteraes fsicas, elevando os custos de manuteno.
O segundo problema que, por manter todos os nveis hierrquicos da dimenso fisicamente em uma nica tabela, esta se torna muito grande, em vrios casos. Outro fator que contribui para o aumento do tamanho da tabela a desnormalizao, que gera uma grande quantidade de valores de atributos repetidos. A desnormalizao fica bastante clara, ao analisar, por exemplo, a dimenso Geografia, que aparece na Figura 8b. No diagrama, representado na Figura 11, podemos ver as dependncias funcionais que ocorrem em uma tabela deste tipo.
Figura 11 Dependncias funcionais da tabela dimenso GEOGRAFIA
O esquema Star clssico pode apresentar algumas variaes, dependendo do problema de negcio apresentado. Nas sees seguintes seguem as variantes do Star.
10.4.1.1
As variaes do esquema Star
A primeira variao a ser discutida o esquema Partial Star. Nesta variao existem mltiplas tabelas para cada dimenso e para a tabela fato. Estas mltiplas tabelas esto lgica e fisicamente separadas em funo dos seus nveis de agregao. Este modelo cria mltiplas estrelas, cada uma representando uma combinao de nveis de agregao em cada dimenso. No existem ligaes lgicas entre as vrias tabelas fato ou dimenso, apenas entre a tabela dimenso e a tabela fato de cada grupo. Cada dimenso representada por mltiplas tabelas que so fisicamente separadas pelo nvel de agregao, sendo que as tabelas possuem como chave primria, uma chave genrica gerada pelo sistema, da mesma forma que o esquema Star clssico. Pode acontecer que uma mtrica ocorra apenas para um determinado nvel de uma dimenso. Por exemplo, a mtrica Preo existe unicamente no nvel Item da dimenso Produto. A Figura 12 retrata esta variao do Star, representando apenas a dimenso Geografia, separada nos nveis de Regio e de Cidade, e as tabelas fatos associadas a estes nveis.
Figura 12 Esquema Partial Star mostrando apenas a dimenso Geografia e as tabelas fato associadas.
Esta partio das informaes, pelos nveis hierrquicos de agregao, leva criao de duas estrelas: a primeira representando o nvel de Regio e a segunda representando o nvel de Cidade. Se forem adicionadas a este esquema as dimenses Tempo e Produto agregadas nos nveis de Fabricante e Marca, conforme o modelo representado na Figura 10 (Star Clssico), ocorrer uma expanso para Regio/Fabricante/Ano, Regio/Marca/Ano, Cidade/Fabricante/Ano e Cidade/Marca/Ano, sendo que cada combinao ser representada por uma estrela parcial separada:
Figura 13 Esquema Partial Star mostrando as dimenses Geografia e Produto separadas em diferentes nveis de agregao e as tabelas fato associadas.
So vrias as vantagens encontradas no esquema Partial Star, apesar de sua visvel complexidade. Uma delas a possibilidade de maior controle do tempo de carga, backup e manuteno das tabelas, pois seu tamanho fica reduzido em funo da partio. Estas parties possibilitam tambm a existncia de fatos em certos nveis especficos e possvel eliminar as colunas que no tenham significado em determinados nveis, reduzindo assim a esparsidade. Como j dito, a complexidade do modelo aumenta em relao ao Star clssico e cada estrela requer uma definio especfica nos metadados, dificultando o processo de manuteno. Com relao s consultas, sero necessrios mltiplos comandos SQL para analisar dados em mais de um nvel de agregao em um mesmo relatrio, o que pode degradar o desempenho da consulta. Alm disso, a estrutura fsica de cada tabela ou grupo de tabelas requer alteraes sempre que novos nveis de agregao ou novas combinaes forem adicionados ou removidos.
Para simplificar um pouco o esquema Partial Star, utiliza-se uma combinao de seus princpios com o Star clssico. Pode-se particionar apenas a tabela fato e manter cada dimenso como uma nica tabela ou o inverso, ou seja, manter a tabela fato nica e particionar as dimenses. O particionamento feito sempre baseado na agregao de determinados nveis da hierarquia. Estas variaes so chamadas de Fact Partitioning e Dimension Partition, respectivamente. A variao Fact Partitioning, tambm chamada Fact Constellation o esquema que particiona apenas a tabela fato. Este esquema utiliza uma nica tabela para cada dimenso que fica ligada s mltiplas tabelas fato, particionadas pelos diferentes nveis de agregao. Este esquema possibilita a existncia de fatos em certos nveis, j que as tabelas so particionadas, assim como o Partial Star. Ao particionar a informao em nveis de agregao desde o mais detalhado, para o caso de consultas executadas nos nveis de detalhe mais altos, o desempenho ser melhor. Deve-se levar em conta que, na implementao deste esquema, se a hierarquia extensa, numerosas tabelas fato sero criadas, aumentando a complexidade do desenho. Alm disso, consultas que requeiram a anlise das informaes em mais de um nvel de agregao emitiro mltiplos comandos SQL, o que pode acarretar em um desempenho inferior. A Figura 14, abaixo, representa um exemplo desta variao, onde a tabela fato est particionada em funo dos nveis hierrquicos Regio e Cidade, da dimenso Geografia (as demais dimenses no esto representadas):
Figura 14 Exemplo do esquema Fact Partitioning ou Fact Constellation para a dimenso Geografia e as tabelas fato correspondentes s parties por Regio e Cidade.
A variao Dimension Partitioning mantm uma nica tabela fato, que contm as mtricas dos vrios nveis de agregao, incluindo o nvel mais detalhado. Esta tabela fato est logicamente ligada s mltiplas tabelas de dimenso, particionadas por diferentes nveis de agregao. A Figura 15 representa um esquema deste tipo, onde a dimenso Geografia encontra-se particionada por Regio e por Cidade (as outras dimenses no esto representadas). As vantagens da Dimension Partitioning incluem a possibilidade de assinalar atributos que so especficos cada nvel de agregao e um bom desempenho, j que apenas um comando SQL emitido para a tabela fato, sem a necessidade de efetuar joins. Ao mesmo tempo, a vantagem de manter todos os fatos, detalhados e sumariados na mesma tabela, dificulta a recuperao das informaes dos nveis mais altos. A escolha do esquema a ser implementado, deve levar em conta vrios fatores do negcio, bem como os tipos de consultas e o tamanho de cada uma das tabelas definidas no data warehouse. Seja qual for a variao escolhida, o Star se carateriza pela simplicidade, rapidez no acesso e desnormalizao. O esquema Star pode ser refinado e transformado em um esquema chamado Snowflake que, para implementar as hierarquias dos atributos, se utiliza de
tabelas de subdimenses. Estas subdimenses facilitam a normalizao do modelo. Manter as tabelas desnormalizadas, implementando-se um esquema Star um aspecto bastante discutvel, pois a diviso das tabelas, como em um esquema Snowflake, em nome da normalizao, pode levar as consultas a um desempenho mais baixo.
Figura 15 Implementao do esquema Dimension Partitioning, representando o particionamento da tabela dimenso Geografia.
10.4.1.2
O esquema Snowflake
O esquema Snowflake pode ser considerado um Star normalizado, pois emprega uma combinao de normalizao da base de dados, para manter a integridade e reduzir os dados armazenados de forma redundante, com uma desnormalizao para obter melhor desempenho. Neste esquema as dimenses so normalizadas em subdimenses, sendo que cada nvel da hierarquia fica em uma subdimenso. Por esta razo, no h necessidade de utilizar o indicador de nvel que existe nos esquemas do tipo Star. A tabela principal da dimenso tem uma chave para cada nvel hierrquico representado na subdimenso e no mais uma nica chave, como no Star. O Snowflake apresenta duas variaes bsicas que diferem na disposio das tabelas que representam as subdimenses, os Snowflake Lookup e o Snowflake Chain, que sero descritos na prxima seo. Sua representao grfica fica similar a um floco de neve, devido ao particionamento das tabelas dimenso.
10.4.1.3
As variaes do esquema Snowflake
O esquema Snowflake Lookup emprega tabelas adicionais para nomes e descries dos atributos, todas ligadas a uma tabela principal da dimenso. Desta forma possvel reduzir o tamanho da tabela dimenso, eliminando a redundncia do armazenamento das mesmas descries em vrias linhas diferentes, sendo que as tabelas adicionais atuam como tabelas de lookup para a chave ou valores codificados da tabela principal da dimenso que, por sua vez, est logicamente ligada a uma nica tabela de fatos. A Figura 16 mostra o mesmo exemplo citado na Figura 10, porm, modelado em Snowflake Lookup, sendo representada apenas a dimenso Geografia e suas subdimenses Regio, Estado, Cidade e Loja.
Na Figura 16, pode-se notar que a ligao entre a tabela fato e a tabela da dimenso principal feita da mesma forma que no esquema Star, por meio de uma chave genrica gerada. A tabela principal da dimenso se conecta logicamente s subdimenses, que so as tabelas de lookup, atravs de suas chaves primrias.
Figura 16 Desenho lgico da dimenso Geografia em um data warehouse implementando o esquema Snowflake Lookup
As descries no precisam ser repetidas como no esquema Star, simplificando o armazenamento, reduzindo o tamanho relativo das tabelas dimenso e melhorando o controle de integridade dos dados. O uso das chaves geradas genricas, geralmente nmeros inteiros, levam a um melhor desempenho, menor manuteno do metadados e mais flexibilidade ao data warehouse. Vale ressaltar que o desempenho pode ficar afetado se mltiplas consultas ou mltiplos joins tm que ser emitidos para decodificar as chaves, ao buscar as descries nas tabelas adicionais. Alm disso, a manuteno da base de dados requer manuteno adicional dado o maior nmero de tabelas fsicas distintas. O esquema Snowflake apresenta um nvel muito maior de normalizao, se comparado aos esquemas do tipo Star. A Figura 17 mostra os diagramas que representam as dependncias funcionais do esquema que aparece na figura 16 em Snowflake Lookup.
Figura 17 Diagramas representando as dependncias funcionais em: a. Tabela principal da dimenso Geografia; b. Tabelas de Lookup (subdimenses) e c. Tabela Fato Vendas
A segunda variao do esquema Snowflake, conhecida por Snowflake Chain, utiliza tambm subdimenses, particionadas pelos nveis hierrquicos da dimenso, sendo que a tabela principal da dimenso representa o nvel mais baixo (mais detalhado) da hierarquia. As subdimenses esto encadeadas, partindo-se da tabela fato que est logicamente conectada tabela da subdimenso principal ou raiz. Na Figura 18 encontra-se um exemplo desta implementao, representando a dimenso Geografia com suas subdimenses e a tabela fato de vendas.
Figura 18 Exemplo de implementao do esquema Snowflake Chain, representando a ligao da tabela Fato com a dimenso Geografia (dividida em subdimenses encadeadas).
Cada tabela da subdimenso contm sua chave primria e suas descries associadas. Alm disso, contm tambm a chave para o prximo nvel da hierarquia da dimenso e assim por diante, at chegar ltima subdimenso, que contm o nvel mais alto (menos detalhado) da hierarquia. tipicamente utilizada quando os fatos contm informaes apenas sobre o nvel de detalhe mais baixo da hierarquia. Como verificado pela Figura 18, a tabela fato j no utiliza uma chave para a dimenso Geografia como um todo, a chave utilizada diretamente para a subdimenso principal. Fica claro que esta implementao no recomendada quando os relatrios necessitam freqentemente vrios nveis de agregao da informao, j que so necessrios vrios passos na cadeia para se chegar ao resultado. Este esquema oferece um alto grau de integridade de dados, pois os nomes e as descries so mantidos em um nico local, reduzindo o tamanho das tabelas de dimenso.
Figura 19 Exemplo de Snowflake Chain com chaves adicionais para melhorar o desempenho das consultas.
A maior desvantagem do Snowflake Chain est no baixo desempenho, uma vez que todos os nveis da cadeia devem ser acessados, mesmo quando se requer apenas os nveis mais altos de agregao. Em situaes prticas, existe uma alternativa para minimizar este efeito, adicionando-se, a cada subdimenso, chaves para todos os nveis superiores da hierarquia. Com isso, pode-se saltar determinados nveis, utilizando-se a chave que leva diretamente para o nvel requerido. A Figura 19 apresenta esta alternativa, que visa basicamente um melhor desempenho do Snowflake Chain.
Figura 20 Exemplo do esquema Snowflake Attribute agrupando os atributos Cor, Formato, Tamanho e Perfume, caractersticas dos produtos vendidos.
Podem ocorrer, em determinados modelos, vrios atributos diferentes que no esto associados a nenhuma dimenso especfica. Em vez de criar vrias dimenses com apenas um atributo, possvel agrup-los em apenas uma dimenso. Este esquema chamado de Snowflake Attribute, sendo que a dimenso artificial pode tambm implementar a combinao de dimenses pouco utilizadas com o objetivo de reduzir o nmero de dimenses do data warehouse, simplificar o modelo e melhorar o desempenho. A tabela principal desta dimenso artificial contm as chaves estrangeiras dos diferentes atributos ou das tabelas dimenso a serem agrupadas. A chave primria da dimenso artificial uma chave genrica gerada pelo sistema e uma nica linha adicionada para cada combinao vlida de todos os atributos ou dimenses envolvidas. Cada chave estrangeira da tabela principal leva a uma chave primria na tabela de descrio daquele atributo ou dimenso. A Figura 20 traz um exemplo, onde Tamanho, Cor, Formato e Perfume so atributos no dimensionais dos produtos vendidos, que no podem ser associados a nenhuma das dimenses existentes no modelo. Utilizando-se este tipo de esquema, os atributos podem ser agrupados em uma nica dimenso artificial que contm todas as combinaes vlidas destes atributos, sendo que a tabela fato contm uma chave para conectar-se logicamente a esta dimenso, da mesma forma que se conecta s outras dimenses do modelo.
Figura 21 Implementao alternativa sem a utilizao do esquema Snowflake Attribute.
As vantagens encontradas neste tipo de implementao so vrias: reduo do nmero de dimenses, que leva reduo do tamanho global dos ndices e da complexidade do SQL gerado, maior integridade dos dados e os vrios atributos juntos ou dimenses pouco usadas compartilham de um nico ponto de entrada na tabela de fatos. Sem este tipo de esquema, cada um destes atributos ou dimenses seria mantido como uma chave estrangeira na tabela fato, resultando em um ponto de entrada que no faria parte da chave primria e, provavelmente, sem ndice fsico para facilitar o acesso. Esta situao, retratada na Figura 21, deve ser evitada.
10.5 Agregaes das informaes

Apesar dos dados no data warehouse serem armazenados segundo a granularidade definida, muitas das consultas realizadas necessitam, alm das informaes detalhadas, de informaes sumariadas ao longo das dimenses. A informao armazenada no nvel de detalhe importante, porm o acesso informao em nveis sumariados permite aos analistas de negcio terem uma viso global do modelo de negcios analisado. Estas consultas, partindo de uma base onde existem apenas os dados de nvel bsico, ou seja, do nvel mais detalhado, se for necessrio sumariar os dados no momento da execuo, todo o processo de anlise ser sobrecarregado. Um determinado conjunto de vrios agregados pr-computados faz-se necessrio para acelerar cada uma das consultas, sendo que o efeito sobre o desempenho considervel, obtendo redues drsticas no tempo de processamento. Por esta razo, a utilizao de dados previamente sumariados (agregados) um recurso bastante eficiente para controlar o desempenho do data warehouse.
10.5.1 Definindo os agregados

A escolha dos agregados a serem previamente armazenados no data warehouse, j que armazenar todos os agregados impraticvel, no uma tarefa trivial. necessria uma
anlise das consultas que sero executadas pelos usurios, identificando os agrupamentos mais freqentes, alm de constante acompanhamento aps a implantao. Uma forma de descrever as agregaes a serem aplicadas na base como um agregado ndirecional, onde n indica o nmero de dimenses sumariadas como resultado da agregao. Um exemplo de um agregado uni-direcional seria sumariar uma dimenso (em algum nvel da hierarquia) enquanto que as outras dimenses ficam em seu nvel atmico, mais detalhado. Um agregado bi-direcional sumaria um nvel da hierarquia para duas dimenses deixando as demais em seu nvel atmico. Utilizando o exemplo expresso na Figura 10, que representa um esquema Star clssico com trs dimenses Geografia, Produto e Tempo e, quiser implementar no data warehouse exemplo, informaes sumariadas para totais de Categoria na dimenso Produto, totais de Estado na dimenso Geografia e totais mensais na dimenso Tempo, ter-se- sete tipos de agregados diferentes: 1. Agregado unidirecional: totais de categoria por loja por dia; 2. 3. 4. 5. 6. 7. Agregado unidirecional: totais de cidade por item de produto por dia; Agregado unidirecional: totais mensais por item de produto por loja; Agregado bidirecional: totais de categoria por totais de cidade por dia; Agregado bidirecional: totais de categoria por totais mensais por loja; Agregado bidirecional: totais de cidades por totais mensais por item de produto; Agregado tridirecional: totais de categoria por totais de cidade por totais mensais.
O exemplo evidencia a no representao de todos os possveis agregados para as dimenses do modelo, o que seria impraticvel, dada a grande quantidade de dados a ser administrada. Ainda assim, para os agregados escolhidos necessria uma avaliao do tamanho do resultado a ser gerado, levando-se em conta a exploso do nmero de linhas e a disperso das informaes armazenadas no data warehouse. Uma tabela de fatos de nvel bsico, para o exemplo em tela, normalmente bastante dispersa no preenchimento das chaves. Para entender este aspecto, lembre-se que apenas uma parte dos produtos vendida por dia em cada uma das lojas. Porm, ao calcular o tamanho do conjunto de agregados, deve-se considerar que sua criao aumenta drasticamente a taxa de ocupao, aumentando substancialmente o tamanho do data warehouse. Para comprovar este fato, observe um exemplo prtico em um data warehouse fictcio. Suponha que no modelo exemplo em anlise existem 10.000 itens produtos diferentes, 1.000 lojas e o perodo de tempo armazenado de 2 anos, equivalente a 730 dias. Alm disso, neste data warehouse exemplo, apenas aproximadamente 10 porcento dos produtos so vendidos em uma determinada loja em um determinado dia. Isto significa que a tabela de fatos ocupa apenas 10 porcento do que ocuparia caso todos os produtos fossem vendidos em todas as lojas, todos os dias. Entretanto, com a criao dos agregados esta taxa aumenta consideravelmente. Suponha ainda que, no caso de produtos, 10.000 itens levam a 2.000 categorias de produto e que as 1.000 lojas esto agrupadas em 100 cidades e o perodo de tempo total ser sumariado em 24 perodos mensais. Alm disso, vamos considerar a disperso e o nmero de linhas a tabela de fatos, de acordo com a tabela apresentada a seguir:
Tabela Base: item de produto por loja por dia Unidir.: categoria por loja por dia Unidir.: item por cidade por dia Unidir.: item por loja por ms Bidir.: categoria por cidade por dia Bidir.: categoria por loja por ms Bidir.: item por cidade por ms Tridir.: categoria por cidade por ms Produto Geografia Tempo Disperso 10.000 1.000 730 10% 2.000 1.000 730 50% 10.000 100 730 50% 10.000 1.000 24 50% 2.000 100 730 80% 2.000 1.000 24 80% 10.000 100 24 80% 2.000 100 24 100% Total aproximado: # Linhas 730 milhes 730 milhes 365 milhes 120 milhes 116 milhes 38 milhes 19 milhes 4,8 milhes 2.122 milhes
Se considerarmos o tamanho inicial da tabela de fatos base, que de aproximadamente 730 milhes de linhas, e o nmero de linhas aps a criao destes sete nveis de agregados,
verificamos que o aumento foi de 200%. O fator de disperso pode ser difcil de prever e a escolha dos agregados deve ser feita com bastante cuidado. Ainda assim, a forma mais eficiente para controlar a exploso de agregados, mas ainda assim beneficiar-se de seu valor, garantir que, em mdia, cada agregado resuma no mnimo 20 e, de preferncia, 20 ou mais itens de nvel bsico. importante lembrar que um determinado agregado pode servir para acelerar uma consulta que requeira um agregado de nvel superior, ou seja, se existe um agregado de nvel intermedirio na hierarquia, este pode ser utilizado, no sendo necessrio executar a consulta agregando o nvel mais detalhado.
10.5.2 Implementando os agregados

A implementao dos valores agregados no data warehouse conta com vrias opes de desenho. possvel manter os fatos sumariados na mesma tabela fato original ou separados por tipo de agregado, o mesmo ocorre com as dimenses. A forma de se implementar os agregados vai depender do esquema implementado para o data warehouse e do nmero de linhas geradas pelos agregados. Para um esquema do tipo Star, onde para cada categoria de informaes gerada uma estrela composta por uma tabela fato e uma tabela para cada dimenso, os agregados podem residir na tabela de fatos original e seus identificadores j esto presentes nas tabelas de dimenso. Cada linha da tabela fato identificada por uma chave composta, como j visto anteriormente, que identifica, nas dimenses, os elementos associados aos valores armazenados na fato. Antes da criao dos agregados, a tabela fato contm apenas valores associados ao nvel mais detalhado de cada dimenso. Assim, com a incluso dos valores agregados na tabela fato, estes devero relacionar-se com os outros nveis da hierarquia das dimenses. Isto possvel, j que cada tabela dimenso, no esquema Star, possui uma linha descrevendo cada elemento da hierarquia, sendo que o campo Nvel identifica esta estrutura hierrquica. claro que, se os agregados so representados nas tabelas de dimenso e fatos originais, por meio desta estrutura de campos Nvel, todas as consultas feitas a esse esquema devem restringir o campo Nvel a um nico valor, caso contrrio, ocorrer contagem dupla, envolvendo valores relacionados a nveis de agregao diferentes. A Figura 21 mostra este relacionamento, representando uma dimenso Geografia e uma tabela fato que possui valores para os vrios nveis da dimenso.
Figura 22 Representao de uma nica tabela fato contendo informaes de nvel detalhado e de agregados associados dimenso Geografia. Como podemos verificar, na Figura 22, a tabela fato continua sendo nica, contendo as linhas de fatos para os nveis detalhados e agregados da dimenso. No exemplo, foram representados parcialmente dois agregados unidirecionais, sendo: Agregado: Item de produto por dia por Estado e
Agregado: Item de produto por dia por Cidade.
Portanto, na tabela fato acima, as linhas (1), (2), (3) e (4) representam valores associados aos nveis detalhados Item de produto, Dia e Loja, enquanto que as linhas (5), (6), (7), (8) e (9) representam os agregados. A grande desvantagem desta implementao a utilizao do campo Nvel que, como citado anteriormente, pode acarretar contagem dupla, se no for utilizado corretamente. Uma alternativa seria manter os fatos agregados em tabelas distintas, ou seja, uma tabela de fatos para cada agregado. Como vantagens desta alternativa de implementao pode-se citar: No ocorrer contagem dupla em qualquer aplicao que utilize as tabelas;
Os vrios tipos de agregados podem ser criados, eliminados, carregados e indexados separadamente quando esto em tabelas diferentes. Como eles provavelmente sero introduzidos no banco de dados em momentos diferentes, o uso de tabelas separadas permite um gerenciamento incremental.
Em um esquema do tipo Snowflake, a implementao mais adequada , obviamente, a utilizao de tabelas fato separadas por agregado, j que as dimenses so tambm separadas. No h motivos para implementar o atributo Nvel em um esquema do tipo Snowflake unicamente para manter os agregados em apenas uma tabela fato.
10.6 Utilizando os agregados com um novo componente: o navegador de agregados

A melhor alternativa para a utilizao dos agregados , sem dvida, o pr-armazenamento dos agregados mais utilizados, sendo que algumas vezes a agregao, por no existir um agregado compatvel, efetuada pela consulta durante sua execuo. O controle deste procedimento no deve ficar a cargo do usurio final, pois a criao ou eliminao de algum agregado levaria a uma srie de procedimentos administrativos impraticveis. Por esta razo, em um data warehouse projetado corretamente, os usurios finais e desenvolvedores de aplicaes jamais vero quaisquer dessas tabelas de agregados. Torna-se necessria, portanto, a definio de um componente de software que escolha a tabela de agregados mais apropriada durante uma consulta, baseado, normalmente, em informaes existentes na camada de metadados do data warehouse. Assim, este componente chamado por R. Kimball de navegador e em em outras fontes bibliogrficas de Aggregate Aware, para citar apenas dois exemplos, capaz de criar as combinaes de agregao, que no estejam presentes no data warehouse, de forma dinmica durante a execuo da consulta. importante que este componente seja capaz de criar estas agregaes dinmicas partindo do agregado predefinido mais adequado para a consulta e otimizando ao mximo o desempenho destas agregaes. A utilizao deste navegador no elimina as preocupaes relacionadas aos agregados. Como estas agregaes dinmicas so mais lentas que o acesso a um agregado armazenado, recomenda-se uma anlise profunda para a definio destes agregados, seguida de acompanhamento ininterrupto de sua utilizao.
10.6.1 O processo de carga

Uma das leis imutveis do data warehousing sobre a complexidade do processo de carga. Vrios aspectos contribuem para aumentar a complexidade desta tarefa: baixa qualidade e ausncia de dados adequados, pssima documentao dos sistemas, mltiplas, redundantes e fontes de dados conflitantes. Muitas caractersticas complexas dos dados ficam ocultas, vindo tona somente no momento do processo de carga do data warehouse. A utilizao de ferramentas que automatizam este processo pode facilitar o trabalho, porm a complexidade semntica envolvida no processo de transformao dos dados no pode ser minimizada. O processo de carga , na grande maioria das vezes, redundante e desnecessariamente complicado, tornando-se um ponto crtico para a introduo de erros. A complexidade desta etapa surge devido diversidade e abrangncia das tarefas envolvidas, recuperando, convertendo e migrando os dados a partir das diversas fontes, executando sua transformao de modo a garantir que a base de dados resultante compreenda sempre informaes precisas, integradas, vlidas e disponveis em tempo hbil. O processo de extrao conta com vrias dificuldades operacionais como, por exemplo, encontrar uma janela de tempo adequada para a execuo do conjunto de programas necessrios para o processo, normalmente em batch, principalmente se a atualizao do data warehouse for diria. Outro problema a ser enfrentado refere-se ao ponto de sincronismo entre os vrios sistemas transacionais, que so atualizados em diferentes intervalos de tempo e que serviro de entrada para este processo de extrao. Uma vez que a periodicidade do processo de carga esteja definida, necessrio escolher um mtodo para identificar e capturar as informaes que foram atualizadas nas bases de origem desde a execuo da ltima carga. Existem algumas opes que podem ser empregadas para esta tarefa, podendo citar como as mais importantes: Utilizao de Logs: a maioria dos gerenciadores de bancos de dados mantm logs ou journals que podem ser utilizados para identificar as alteraes ocorridas nas bases de dados. Estas alteraes, uma vez identificadas, devem ser escritas em um arquivo diferente que ser utilizado para migrar as alteraes para o ambiente de data warehouse. Esta alternativa produz bons resultados se as atualizaes a serem capturadas so obtidas de forma simples e direta. Porm, se os dados necessrios para a atualizao do data warehouse estiverem em um nmero considervel de arquivos ou bases de dados separados, dificultando o sincronismo das logs, este processo comea a aumentar em complexidade. Adicionalmente,
pode-se citar os problemas relativos s alteraes necessrias no programas de carga devido a novas verses dos gerenciadores de bancos de dados que podem levar a modificaes na estrutura dos logs.
Comparao das informaes: apesar de conceitualmente simples, uma opo bastante trabalhosa para executar. Consiste em desenvolver um programa que leia os dados nas bases fonte e no data warehouse, identificando as alteraes ocorridas desde a ltima execuo da carga. Este mtodo caro, no que se refere aos recursos de mquina necessrios para comparao dos dados e pode ser muito demorado, dependendo do tamanho das bases pesquisadas e dos recursos disponveis para o processamento. Reengenharia dos sistemas aplicativos transacionais: esta opo no se mostra muito atrativa, j que requer que as aplicaes em produo sejam alteradas com o objetivo de armazenar, em arquivos destinados para este fim, as modificaes ocorridas nos dados fonte. Ocorre, porm, que a maioria das aplicaes no pode sofrer facilmente um processo de reengenharia, sendo que esta opo, em muitas situaes, s poderia ser empregada nas novas aplicaes a serem desenvolvidas. Neste caso, as necessidades do data warehouse passariam a fazer parte da especificao da aplicao.
Aps sua captura, os dados devem passar por uma etapa de transformao, j que, simplesmente obt-los do ambiente fonte e pass-los para o data warehouse no suficiente. necessrio, com o objetivo de otimizar o potencial do data warehouse, transformar as entidades obtidas em novas composies de entidades requeridas para processo de gerao de informao relevante para o usurio. Alm da transformao, os dados passam por um processo de enriquecimento, que , normalmente, um produto da integrao de dados e ocorre quando um atributo adicional acrescentado a uma entidade. Se um dado externo est sendo acrescentado ao data warehouse, uma entidade Cliente, por exemplo, pode ser enriquecida com este novo atributo que foi selecionado de fontes econmicas, demogrficas, financeiras, etc. Estas fontes podem ser valiosas para o enriquecimento das informaes, porm mais valiosas ainda, podem ser as prprias aplicaes do data warehouse cujos atributos podem ser derivados dos padres de comportamento analisados. Uma outra etapa necessria migrao dos dados envolve um mecanismo de transporte partindo do ambiente operacional para o data warehouse. Estes dois ambientes podem estar localizados em distintas plataformas, alm da possibilidade de estarem fisicamente remotas levando a uma maior dificuldade na transferncia dos dados. Por ser inconcebvel um meio de transporte de dados que no seja eletrnico, a implementao do mecanismo de transporte pode envolver uma avaliao de todas as opes disponveis, j que diferentes fabricantes podem oferecer diferentes opes proprietrias com custos, capacidades e limitaes bastante distintas. Ao considerar a velocidade da transferncia, deve-se levar em conta cada aspecto envolvido no processo, seja na plataforma de origem ou na plataforma destino. Esta anlise particularmente importante para determinar, no contexto considerado, o tempo disponvel para a execuo desta etapa nas plataformas envolvidas. Na seqncia do processo de carga um fator muito importante est relacionado a garantir a integridade dos dados que esto sendo adicionados ao data warehouse. Este controle de integridade deve ser implementado de forma a garantir dois aspectos. O primeiro deles a garantia de que os dados extrados dos sistemas de origem so exatamente os mesmos que esto sendo carregados no data warehouse. O segundo aspecto deve garantir que os dados que esto sendo carregados esto consistentes com os dados que foram pedidos para as bases de origem em um determinado instante no tempo. A reformatao dos dados pode tambm ser uma etapa necessria neste processo, uma vez que os ambientes de origem e o data warehouse podem estar em ambientes computacionais heterogneos, que muitas vezes causa problemas relacionados ao formato dos dados. O problema mais comumente encontrado refere-se s diferenas entre os formatos de arquivos em EBCDIC, encontrados nos ambientes IBM e os formatos ASCII utilizados pela maioria das outras plataformas. Como ltimo passo do processo, encontramos a etapa de carga dos dados que depende, obviamente, do volume de dados envolvido no processo. Pode ser que o tempo necessrio para a carga dos dados adicionado ao tempo requerido para transferi-los, provoque um impacto negativo na disponibilidade do data warehouse para os usurios. Portanto, devem ser
considerados todos os aspectos que possam dificultar este processo. Um destes aspectos a quantidade de ndices criados nas tabelas do data warehouse. Uma grande quantidade de ndices adequados agiliza a execuo das consultas, objetivo primrio de um data warehouse, no entanto, este alto nvel de indexao pode diminuir sensivelmente a velocidade do processo de carga. fcil perceber, aps uma anlise das etapas necessrias ao processo de carga, a alta complexidade desta tarefa que, se no for definida com bastante cuidado, pode levar introduo de erros, comprometendo todo o processo de tomada de deciso executado pelos usurios. Alm disso, qualquer alterao na arquitetura dos sistemas transacionais e nas bases de origem deve ser detalhadamente verificada, j que pode causar alteraes em vrias etapas do processo de carga.
APNDICE A
Em construo.
Para informaes provisrias acesse: http://www.ime.usp.br/~jef/RDBLang/
APNDICE B
Exerccios Processamento de transaes e controle de concorrncia 1) Defina o conceito de atomicidade de transaes e suas propriedades. 2) Considere o grafo de precedncia da figura abaixo. possvel encontrar um escalonamento serivel e seus escalonamentos seriais equivalentes? Justifique sua resposta.
T0 T1
T3
T2
T4
3) Quais dos seguintes escalonamentos so seriveis? Para cada escalonamento serivel determine os escalonamentos seriais equivalentes. a. r1(X); r3(X); w1(X); r2(X); w3(X); b. r1(X); r3(X); w3(X); w1(X); r2(X); c. r3(X); r2(X); w3(X); r1(X); w1(X); d. r3(X); r2(X); r1(X); w3(X); w1(X); 4) Considere as trs transaes T1, T2 e T3 e os escalonamentos S1 e S2 descritos abaixo. Esboce os grafos de seriao (precedncia) para S1 e S2. Verifique se so seriveis e se for o caso determine os respectivos escalonamentos seriais. T1: r1(X); r1(Z); w1(X); T2: r2(Z); r2(Y); w2(Z); w2(Y); T3: r3(X); r3(Y); w3(Y); S1: r1(X); r2(Z); r1(Z); r3(X); r3(Y); w1(X); w3(Y); r2(Y); w2(Z); w2(Y); S2: r1(X); r2(Z); r3(X); r1(Z); r2(Y); r3(Y); w1(X); w2(Z); w3(Y); w2(Y);
5) Considere as duas transaes abaixo com valores iniciais de X=Y=0. possvel encontrar um escalonamento serivel equivalente ao escalonamento serial T0, T1 ? T0: read(X); read(Y); if X = 0 then (Y = Y+1, write(Y)); T1: read(Y); read(X); if Y = 0 then (X = X+1; write(X)); 6) Mostre que o protocolo de bloqueio em duas fases garante a seriao de conflitos de escalonamentos. Tambm mostre que tal protocolo tambm garante escalonamentos estritos (escalonamentos nos quais as transaes no podem ler nem gravar um item X at que a ltima transao que gravou X tenha sido confirmada ou abortada).
Referncias Bibliogrficas
[1] E. F. Codd. A Relational Model of Data for Large Shared Data Banks. Revista CACM volume = 6,1970. C. J. Date. Introduo a Sistema de Banco de Dados. Editora Campus, 2000 S. Sudarshan and A. Silberschatz and F. Henry Korth. Sistemas de Banco de Dados. 3. Edio. Editora Makron Books, 1999 E. R. Elmasri and S. Navathe and. Fundamentals of Database Systems. Editora Addison Wesley Pub, 2001. Jennifer Widow and Jeffrey Ullman .A First Course in Database Systems. Editora Prentice Hall, 1997. M Jackson .Thirty years (and more) of databases .Revista Information and Software Technology, volume = "41", pginas =969-978, 1999. R. Ramakrishnan and J. Gehrke. Database Management Systems. 2a. Edio. McGraw-Hill, 2000. C. Adamson, M. Venerable. Data Warehouse Design Solutions, John Wiley & Sons, 1998. E. Baralis, S. Paraboschi, E. Teniente. Materialized view selection in a Multidimensional Database. Proceedings of the 23rd VLDB Conference, Atenas, Grcia, 1997. A. Gupta e I. S. Mumick. What is the data warehousing problem? (Are materialized views the answer?). Proceedings of the 22nd VLDB Conference, Mumbai (Bombay), ndia, 1996. M. Golfarelli, D. Maio, S. Rizzi. Conceptual Design of Data Warehouses from E/R Schemes, Proceedings of the Hawaii International Conference on System Sciences, Kona, Hawaii, USA, 1998. Information Advantage, Decision PathTMImplementation Methodology. MyEureka!TM data warehouse requirements guide, 1999. W. H. Inmon, R. D. Hackathorn. Como usar o Data Warehouse. Infobook, Rio de Janeiro, 1997. S. Kelly. Data Warehousing The Route to Mass Customization, John Wiley & Sons, 1994. R. Kimball. The data warehouse toolkit. John Wiley & Sons, 1996. N. Raden. Technology Tutorial: Modeling a Data Warehouse, disponvel em: http://techweb.cmp.com/iw/564/64oldat.htm, 1996. S. Samtani, M. Mohania, V. Kumar, Y. Kambayashi. ER Workshops, 1998, pg. 81-92. R. Tanler. The Intranet Data Warehouse, John Wiley & Sons, 1997. Y. Zhuge, H. Garcia-Molina, J. Hammer e J. Widom. View maintenance in a warehousing environment. Technical report, Stanford University. Disponvel: ftp://db.stanford.edu como pub/zhuge/1994/anomaly-full.ps. Outubro de 1994. [2] [3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15] [16]
[17] [18] [19]

Introducao BD PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Introducao BD PDF

Hochgeladen von

Copyright:

Verfügbare Formate

Introduo a Banco de Dados

O.K. Takai; I.C.Italiano; J.E. Ferreira.

INTRODUO A BANCO DE DADOS

Introduo a Banco de Dados

O.K. Takai; I.C.Italiano; J.E. Ferreira.

Introduo a Banco de Dados

O.K. Takai; I.C.Italiano; J.E. Ferreira.

Introduo a Banco de Dados

O.K. Takai; I.C.Italiano; J.E. Ferreira.

Introduo a Banco de Dados

O.K. Takai; I.C.Italiano; J.E. Ferreira.

Introduo a Banco de Dados

O.K. Takai; I.C.Italiano; J.E. Ferreira.

1.1.1 Modelo Hierrquico

Introduo a Banco de Dados

O.K. Takai; I.C.Italiano; J.E. Ferreira.

Figura 1.2 - Diagrama de estrutura de dados Cliente - Conta Corrente

Introduo a Banco de Dados

O.K. Takai; I.C.Italiano; J.E. Ferreira.

1.1.3 Modelo Relacional

Introduo a Banco de Dados

O.K. Takai; I.C.Italiano; J.E. Ferreira.

Arquiteturas de Banco Dados

Introduo a Banco de Dados

O.K. Takai; I.C.Italiano; J.E. Ferreira.

Introduo a Banco de Dados 1.2.3 Resumo das arquiteturas de SGBDs

O.K. Takai; I.C.Italiano; J.E. Ferreira.

Introduo a Banco de Dados

O.K. Takai; I.C.Italiano; J.E. Ferreira.

Figura 1.5 - Arquitetura Distribuda N camadas

Ambiente de Implementao Cliente-Servidor

Introduo a Banco de Dados

O.K. Takai; I.C.Italiano; J.E. Ferreira.

Figura 1.6 - Ambiente genrico para desenvolvimento de aplicativos

Introduo a Banco de Dados

O.K. Takai; I.C.Italiano; J.E. Ferreira.

Figura 1.7 - Conversor genrico para interface e servidores de dados

Introduo a Banco de Dados

O.K. Takai; I.C.Italiano; J.E. Ferreira.

SGBD Software p/ processar consultas/programas

Software p/ acessar a Base de Dados Meta Base

Figura 2.1 Sistema de Banco de Dados

Caractersticas da Abordagem de Base de Dados x Processamento Tradicional de Arquivos

Introduo a Banco de Dados

O.K. Takai; I.C.Italiano; J.E. Ferreira.

Vantagens da base de Dados eliminao de redundncias

eliminao de redundncias facilidade de manuteno facilidade de manuteno

Introduo a Banco de Dados

O.K. Takai; I.C.Italiano; J.E. Ferreira.

Vantagens Adicionais da Abordagem da Base de Dados

Introduo a Banco de Dados

O.K. Takai; I.C.Italiano; J.E. Ferreira.

Quando no utilizar um SGBD

Profissionais e Atividades envolvidas em um SGBD

Introduo a Banco de Dados

O.K. Takai; I.C.Italiano; J.E. Ferreira.

3 Conceitos e Arquiteturas de SGBDs

3.1.1 Categorias de Modelos de Dados

3.1.2 Esquemas e Instncias

Introduo a Banco de Dados

O.K. Takai; I.C.Italiano; J.E. Ferreira.

Arquitetura e Independncia de Dados de SGBDs

BASE DE DADOS ARMAZENADA