Banco de Dados - Apostilas - Ciência da Computação Parte1, Notas de estudo de Informática

Baixe Banco de Dados - Apostilas - Ciência da Computação Parte1 e outras Notas de estudo em PDF para Informática, somente na Docsity! Introdução a Banco de Dados O.K. Takai; I.C.Italiano; J.E. Ferreira. 4 10.3.2 Conceitos da modelagem.................................................................................. 95 10.3.2.1 A granularidade das informações ..............................................................................96 10.3.2.2 As dimensões ............................................................................................................97 10.3.2.3 Os fatos .....................................................................................................................98 10.3.3 Os três tipos de métricas................................................................................... 98 10.3.4 Outros elementos da tabela fato ....................................................................... 99 10.4 OS ESQUEMAS BÁSICOS E SUAS VARIAÇÕES ................................................................ 101 10.4.1 O esquema Star clássico ................................................................................ 101 10.4.1.1 As variações do esquema Star................................................................................105 10.4.1.2 O esquema Snowflake ............................................................................................109 10.4.1.3 As variações do esquema Snowflake......................................................................109 10.5 AGREGAÇÕES DAS INFORMAÇÕES ............................................................................... 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 Introdução a Banco de Dados O.K. Takai; I.C.Italiano; J.E. Ferreira. 1 INTRODUÇÃO A BANCO DE DADOS Osvaldo Kotaro Takai Isabel Cristina Italiano João Eduardo Ferreira DCC-IME-USP – Fevereiro - 2005 Introdução a Banco de Dados O.K. Takai; I.C.Italiano; J.E. Ferreira. 2 Índice 1 INTRODUÇÃO ................................................................................................................. 6 1.1 MODELOS DE DADOS...................................................................................................... 6 1.1.1 Modelo Hierárquico.................................................................................................. 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 Introdução................................................................................................................ 9 1.2.2 Arquiteturas ........................................................................................................... 10 1.2.3 Resumo das arquiteturas de SGBDs .................................................................... 11 1.3 AMBIENTE DE IMPLEMENTAÇÃO CLIENTE-SERVIDOR....................................................... 12 2 DEFINIÇÃO GERAL....................................................................................................... 14 2.1 PROPRIEDADES:........................................................................................................... 14 2.2 CARACTERÍSTICAS 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 NÃO UTILIZAR UM SGBD................................................................................. 18 2.6 PROFISSIONAIS E ATIVIDADES ENVOLVIDAS EM UM SGBD .............................................. 18 3 CONCEITOS E ARQUITETURAS DE SGBD’S............................................................. 19 3.1 MODELOS DE DADOS, ESQUEMAS E INSTÂNCIAS............................................................ 19 3.1.1 Categorias de Modelos de Dados ......................................................................... 19 3.1.2 Esquemas e Instâncias ......................................................................................... 19 3.2 ARQUITETURA E INDEPENDÊNCIA DE DADOS DE SGBD’S ............................................... 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-NÍVEL 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, Papéis e Restrições 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 QUESTÕES PARA A SÍNTESE ......................................................................................... 37 5 O MODELO DE DADOS RELACIONAL ........................................................................ 38 5.1 CONCEITOS DO MODELO RELACIONAL........................................................................... 38 5.1.1 Notação do Modelo Relacional.............................................................................. 39 5.1.2 Atributos-chaves de uma Relação......................................................................... 40 5.1.3 Esquemas de Bases de Dados Relacionais e Restrições de Integridade ............ 41 5.1.4 Operações de Atualizações sobre Relações ........................................................ 44 Introdução a Banco de Dados O.K. Takai; I.C.Italiano; J.E. Ferreira. 3 6 MAPEAMENTO DO MER PARA O MODELO DE DADOS RELACIONAL ................... 45 7 LINGUAGENS FORMAIS DE CONSULTA.................................................................... 49 7.1 ÁLGEBRA RELACIONAL ................................................................................................. 49 7.1.1 Operações SELECT e PROJECT ......................................................................... 49 7.1.1.1 O Operador SELECT.................................................................................................49 7.1.1.2 O Operador PROJECT..............................................................................................50 7.1.2 Seqüência de Operações ...................................................................................... 51 7.1.3 Renomeando Atributos.......................................................................................... 52 7.1.4 Operações da Teoria dos Conjuntos..................................................................... 52 7.1.5 A Operação JOIN .................................................................................................. 55 7.1.6 Conjunto completo de Operações da Álgebra Relacional..................................... 57 7.1.7 A Operação DIVISION........................................................................................... 57 7.1.8 Operações Relacionais Adicionais ........................................................................ 58 7.1.9 Funções de Agregação ......................................................................................... 58 7.1.10 Operações de Clausura Recursiva ................................................................... 60 7.2 EXEMPLOS DE CONSULTAS NA ÁLGEBRA RELACIONAL.................................................... 60 7.3 QUESTÕES DE REVISÃO................................................................................................ 62 7.4 CÁLCULO RELACIONAL ................................................................................................. 63 7.4.1 Cálculo Relacional de Tuplas ................................................................................ 63 7.4.2 Cálculo Relacional de Domínio ............................................................................. 65 8 A LINGUAGEM SQL ...................................................................................................... 67 8.1 ESTRUTURA BÁSICA ..................................................................................................... 67 8.1.1 A operação RENAME............................................................................................ 68 8.1.2 Operações com Strings ......................................................................................... 68 8.1.3 Ordenação e Apresentação de Tuplas.................................................................. 68 8.1.4 Operações com Conjuntos .................................................................................... 68 8.1.5 Funções Agregadas............................................................................................... 69 8.1.6 Subconsultas Aninhadas ....................................................................................... 69 8.1.7 Visões .................................................................................................................... 70 8.1.8 Inserção ................................................................................................................. 70 8.1.9 Atualização ............................................................................................................ 71 8.1.10 Remoção ........................................................................................................... 71 8.1.11 SQL DDL ........................................................................................................... 71 9 DEPENDÊNCIAS FUNCIONAIS E NORMALIZAÇÃO DE BASE DE DADOS RELACIONAIS ............................................................................................................................ 75 9.1 DIRETRIZES PARA O PROJETO INFORMAL DE ESQUEMAS DE RELAÇÕES .......................... 75 9.1.1 Semântica de atributos de relação........................................................................ 75 Informação redundante em tuplas e anomalias de atualizações ....................................... 76 9.2 ANOMALIA DE INSERÇÃO ............................................................................................... 77 9.2.1 Anomalia de remoção............................................................................................ 77 9.2.2 Anomalia de modificação ...................................................................................... 77 9.2.3 Discussão .............................................................................................................. 78 9.2.4 Valores null em tuplas ........................................................................................... 78 9.2.5 Tuplas espúrias ..................................................................................................... 78 9.3 DEPENDÊNCIAS FUNCIONAIS......................................................................................... 80 9.3.1 Definição de Dependência Funcional.................................................................... 80 9.3.2 Formas Normais Determinados pelas Chaves Primárias ..................................... 82 9.2.1.1. Primeira Forma Normal (1FN) ...................................................................................82 9.2.1.2. Segunda Forma Normal (2FN) ..................................................................................82 9.2.1.3. Terceira Forma Normal (3FN) ...................................................................................83 10 DATA WAREHOUSE – UMA VISÃO GERAL................................................................ 89 10.1 O QUE É O DATA WAREHOUSE ...................................................................................... 89 10.2 O MODELO DIMENSIONAL E SUAS IMPLEMENTAÇÕES ....................................................... 90 10.2.1 O modelo formal da base de dados multidimensional ...................................... 93 10.3 ASPECTOS DA MODELAGEM DIMENSIONAL..................................................................... 95 10.3.1 Características .................................................................................................. 95 Introdução a Banco de Dados O.K. Takai; I.C.Italiano; J.E. Ferreira. 12 Figura 1.5 - Arquitetura Distribuída N camadas 1.3 Ambiente de Implementação Cliente-Servidor Introdução a Banco de Dados O.K. Takai; I.C.Italiano; J.E. Ferreira. 9 formado por representantes dos principais fabricantes de banco de dados orientados a objeto disponíveis comercialmente. Membros do grupo têm o compromisso de incorporar o padrão em seus produtos. O termo Modelo Orientado a Objetos é usado para documentar o padrão que contém a descrição geral das facilidades de um conjunto de linguagens de programação 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 perceptíveis do modelo relacional pareceram ter sido solucionadas com esta tecnologia e acreditava-se que tais bancos de dados ganhariam grande parcela do mercado. Hoje, porém, acredita-se que os Bancos de Dados Orientados a Objetos serão usados em aplicações especializadas, enquanto os sistemas relacionais continuarão a sustentar os negócios tradicionais, onde as estruturas de dados baseadas em relações são 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 diferenças com o modelo anterior. Figura 1.4 - Diagrama UML Cliente - Conta Corrente 1.1.5 Sistemas Objeto-Relacionais A área de atuação 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 semântica e construções de modelagens. A solução proposta é a adição de facilidades para manusear tais dados utilizando-se das facilidades SQL (Structured Query Language) existentes. Para isso, foi necessário adicionar: extensões dos tipos básicos no contexto SQL; representações para objetos complexos no contexto SQL; herança no contexto SQL e sistema para produção de regras. 1.2 Arquiteturas de Banco Dados 1.2.1 Introdução Atualmente, devem-se considerar alguns aspectos relevantes para atingir a eficiência e a eficácia dos sistemas informatizados desenvolvidos, a fim de atender seus usuários nos mais variados domínios de aplicação: automação de escritórios, sistemas de apoio a decisões, controle de reserva de recursos, controle e planejamento de produção, alocação e estoque de recursos, entre outros. Tais aspectos são: a) Os projetos Lógico e Funcional do Banco de Dados devem ser capazes de prever o volume de informações armazenadas a curto, médio e longo prazo. Os projetos devem ter uma grande capacidade de adaptação para os três casos mencionados; b) Deve-se ter generalidade e alto grau de abstração de dados, possibilitando confiabilidade e eficiência no armazenamento dos dados e permitindo a utilização de diferentes tipos de gerenciadores de dados através de linguagens de consultas padronizadas; c) Projeto de uma interface ágil e com uma "rampa ascendente" para propiciar aprendizado suave ao usuário, no intuito de minimizar o esforço cognitvo; Introdução a Banco de Dados O.K. Takai; I.C.Italiano; J.E. Ferreira. 10 d) Implementação de um projeto de interface compatível com múltiplas plataformas (UNIX, Windows NT, Windows Workgroup, etc); e) Independência de Implementação da Interface em relação aos SGBDs que darão condições às operações de armazenamento de informações (ORACLE, SYSBASE, INFORMIX, PADRÃO XBASE, etc). f) Conversão e mapeamento da diferença semântica entre os paradigmas utilizados no desenvolvimento de interfaces (Imperativo (ou procedural), Orientado a Objeto, Orientado a evento), servidores de dados (Relacional) e programação dos aplicativos (Imperativo, Orientado a Objetos). 1.2.2 Arquiteturas As primeiras arquiteturas usavam mainframes para executar o processamento principal e de todas as funções do sistema, incluindo os programas aplicativos, programas de interface com o usuário, bem como a funcionalidade dos SGBDs. Esta é a razão pela qual a maioria dos usuários fazia acesso aos sistemas via terminais que não possuíam poder de processamento, apenas a capacidade de visualização. Todos os processamentos eram feitos remotamente, apenas as informações a serem visualizadas e os controles eram enviados do mainframe para os terminais de visualização, conectados a ele por redes de comunicação. Como os preços do hardware foram decrescendo, muitos usuários trocaram seus terminais por computadores pessoais (PC) e estações de trabalho. No começo os SGBDs usavam esses computadores da mesma maneira que usavam os terminais, ou seja, o SGBD era centralizado e toda sua funcionalidade, execução de programas aplicativos e processamento da interface do usuário eram executados em apenas uma máquina. Gradualmente, os SGBDs começaram a explorar a disponibilidade do poder de processamento no lado do usuário, o que levou à arquitetura cliente-servidor. A arquitetura cliente-servidor foi desenvolvida para dividir ambientes de computação onde um grande número de PCs, estações de trabalho, servidores de arquivos, impressoras, servidores de banco de dados e outros equipamentos são conectados juntos por uma rede. A idéia é definir servidores especializados, tais como servidor de arquivos, que mantém os arquivos de máquinas clientes, ou servidores de impressão que podem estar conectados a várias impressoras; assim, quando se desejar imprimir algo, todas as requisições de impressão são enviadas a este servidor. As máquinas clientes disponibilizam para o usuário as interfaces apropriadas para utilizar esses servidores, bem como poder de processamento para executar aplicações locais. Esta arquitetura se tornou muito popular por algumas razões. Primeiro, a facilidade de implementação dada a clara separação das funcionalidades e dos servidores. Segundo, um servidor é inteligentemente utilizado porque as tarefas mais simples são delegadas às máquinas clientes mais baratas. Terceiro, o usuário pode executar uma interface gráfica que lhe é familiar, ao invés de usar a interface do servidor. Desta maneira, a arquitetura cliente-servidor foi incorporada aos SGBDs comerciais. Diferentes técnicas foram propostas para se implementar essa arquitetura, sendo que a mais adotada pelos Sistemas Gerenciadores de Banco de Dados Relacionais (SGBDRs) comerciais é a inclusão 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 transação. É assim que um servidor SQL é fornecido aos clientes. Cada cliente tem que formular suas consultas SQL, prover a interface do usuário e as funções de interface usando uma linguagem de programação. O cliente pode também se referir a um dicionário de dados o qual inclui informações sobre a distribuição dos dados em vários servidores SQL, bem como os módulos para a decomposição de uma consulta global em um número de consultas locais que podem ser executadas em vários sítios. Comumente o servidor SQL também é chamado de back-end machine e o cliente de front-end machine. Como SQL provê uma linguagem padrão para o SGBDRs, esta criou o ponto de divisão lógica entre o cliente e o servidor. Atualmente, existem várias tendências para arquitetura de Banco de Dados, nas mais diversas direções. Introdução a Banco de Dados O.K. Takai; I.C.Italiano; J.E. Ferreira. 11 1.2.3 Resumo das arquiteturas de SGBDs • Plataformas centralizadas. Na arquitetura centralizada, existe um computador com grande capacidade de processamento, o qual é o hospedeiro do SGBD e emuladores para os vários aplicativos. Esta arquitetura tem como principal vantagem a de permitir que muitos usuários manipulem grande volume de dados. Sua principal desvantagem está no seu alto custo, pois exige ambiente especial para mainframes e soluções centralizadas. • Sistemas de Computador Pessoal - PC. Os computadores pessoais trabalham em sistema stand-alone, ou seja, fazem seus processamentos sozinhos. No começo esse processamento era bastante limitado, porém, com a evolução do hardware, tem-se hoje PCs com grande capacidade de processamento. Eles utilizam o padrão Xbase e quando se trata de SGBDs, funcionam como hospedeiros e terminais. Desta maneira, possuem um único aplicativo a ser executado na máquina. 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 usuário (tela, e processamento de entrada e saída). O servidor (back_end) executa as consultas no DBMS e retorna os resultados ao cliente. Apesar de ser uma arquitetura bastante popular, são necessárias soluções sofisticadas de software que possibilitem: o tratamento de transações, as confirmações de transações (commits), desfazer transações (rollbacks), linguagens de consultas (stored procedures) e gatilhos (triggers). A principal vantagem desta arquitetura é a divisão do processamento entre dois sistemas, o que reduz o tráfego de dados na rede. • Banco de Dados Distribuídos (N camadas). Nesta arquitetura, a informação está distribuída em diversos servidores. Como exemplo, observe a Figura 1.5. Cada servidor atua como no sistema cliente-servidor, porém as consultas oriundas dos aplicativos são feitas para qualquer servidor indistintamente. Caso a informação solicitada seja mantida por outro servidor ou servidores, o sistema encarrega-se de obter a informação necessária, de maneira transparente para o aplicativo, que passa a atuar consultando a rede, independente de conhecer seus servidores. Exemplos típicos são as bases de dados corporativas, em que o volume de informação é muito grande e, por isso, deve ser distribuído em diversos servidores. Porém, não é dependente de aspectos lógicos de carga de acesso aos dados, ou base de dados fracamente acopladas, em que uma informação solicitada vai sendo coletada numa propagação da consulta numa cadeia de servidores. A característica básica é a existência de diversos programas aplicativos consultando a rede para acessar os dados necessários, porém, sem o conhecimento explícito de quais servidores dispõem desses dados. Introdução a Banco de Dados O.K. Takai; I.C.Italiano; J.E. Ferreira. 16 Processamento tradicional de Arquivos Base de Dados Vantagens da base de Dados Definição dos dados é parte do código de programas de aplicação Meta Dados eliminação de redundâncias Dependência entre aplicação específica e dados Capaz de permitir diversas aplicações eliminação de redundâncias independência entre dados e programas facilidade de manutenção Representação de dados ao nível físico Representação conceitual através de dados e programas facilidade de manutenção Cada visão é implementada por módulos específicos Permite múltiplas visões facilidade de consultas 2.3 Capacidades do SGBD • Controle de Redundância: no processamento tradicional de arquivos, muitos grupos de usuários mantêm seus próprios arquivos para manipular suas aplicações de processamento, que pode provocar o armazenamento de informações redundantes; Problemas: ⇒ Duplicação de esforços; ⇒ Desperdício de espaço; ⇒ Inconsistência: alteração em alguns arquivos e em outros não, ou em todos os arquivos, porém, de maneira independente; • Compartilhamento de Dados: SGBD’s multiusuários devem fornecer controle de concorrência para assegurar que atualizações simultâneas resultem em modificações corretas. Um outro mecanismo que permite a noção de compartilhamento de dados em um SGBD multiusuário é a facilidade de definir visões de usuário, que é usada para especificar a porção da base de dados que é de interesse para um grupo particular de usuários; • Restrições de Acesso Multiusuário: quando múltiplos usuários compartilham uma base de dados, é comum que alguns usuários não autorizados não tenham acesso a todas as informações da base de dados. Por exemplo, os dados financeiros são freqüentemente considerados confidenciais e, desse modo, somente pessoas autorizadas devem ter acesso. Além disso, pode ser permitido a alguns usuários, apenas a recuperação dos dados. Já, para outros, são permitidas a recuperação e a modificação. Assim, o tipo de operação de acesso - recuperação ou modificação - pode também ser controlado. Tipicamente, usuários e grupos de usuários recebem uma conta protegida por palavras- chaves, que é usada para se obter acesso à base de dados, o que significa dizer que contas diferentes possuem restrições de acesso diferentes. Um SGBD deve fornecer um subsistema de autorização e segurança, que é usado pelo DBA para criar contas e especificar restrições nas contas. O SGBD deve então obrigar estas restrições automaticamente. Note que um controle similar pode ser aplicado ao software do SGBD; • Fornecimento de Múltiplas Interfaces: devido aos vários tipos de usuários, com variados níveis de conhecimento técnico, um SGBD deve fornecer uma variedade de interfaces atendê-los. Os tipos de interfaces incluem linguagens de consulta para usuários ocasionais, interfaces de linguagem de programação para programadores de aplicações, formulários e interfaces dirigidas por menus para usuários comuns; • Representação de Relacionamento Complexo entre Dados: uma base de dados pode possuir uma variedade de dados que estão 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 fácil e eficiente; • Reforçar Restrições de Integridade: muitas aplicações de base de dados terão certas restrições de integridade de dados. A forma mais elementar de restrição de integridade é a Introdução a Banco de Dados O.K. Takai; I.C.Italiano; J.E. Ferreira. 13 Figura 1.6 - Ambiente genérico para desenvolvimento de aplicativos A Figura 1.6 ilustra um ambiente genérico de desenvolvimento de aplicativos. Nesta Figura, a diferença (gap semântico) entre os paradigmas utilizados para: a construção de interfaces, o armazenamento de informações, e a programação dos aplicativos são detalhadas para ressaltar a importância de estruturas "Case" e "Cursores". As estruturas "Case" são utilizadas para converter as alterações e solicitações ocorridas na interface do aplicativo em uma linguagem que seja capaz de ser processada pelos servidores de dados. A construção da linguagem é feita através da composição de cadeias de caracteres usualmente utilizando o padrão SQL utilizado nos servidores de dados relacionais. Quando um acesso ao SGBD é requerido, o programa estabelece uma conexão com o SGBD que está instalado no servidor. Uma vez que a conexão é criada, o programa cliente pode se comunicar com o SGBD. Um padrão chamado de Conectividade Base de Dados Aberta (Open DataBase Connectivity - ODBC) provê uma Interface para Programação de Aplicações (API) que permite que os programas no lado cliente possam chamar o SGBD, desde que as máquinas clientes como o servidor tenham o necessário software instalado. Muitos vendedores de SGBDs disponibilizam drivers específicos para seus sistemas. Desta maneira, um programa cliente pode se conectar a diversos SGBDRs e enviar requisições de consultas e transações usando API, que são processados nos servidores. Após o processamento de uma chamada de função (levando uma cadeia de caracteres ou programas armazenados), o resultado é fornecido pelo servidor de dados através de tabelas em memória. Os resultados das consultas são 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 múltiplas tuplas, dependendo de quantas linhas foram encontradas com o critério de busca. Quando uma consulta retorna múltiplas linhas, é necessário declarar um "CURSOR" para processá-las. Um cursor é similar a uma variável de arquivo ou um ponteiro de arquivo, que aponta para uma única linha (tupla) do resultado da consulta. Em SQL os cursores são controlados por três 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 posição anterior à primeira linha do resultado da consulta. O comando FETCH, quando executado pela primeira vez, devolve a primeira linha nas variáveis do programa e coloca o cursor para apontar para aquela linha. Subseqüentes execuções do comando FETCH avançam o cursor para a próxima linha no conjunto resultante e retornam a linha nas variáveis do programa. Quando a última linha é processada, o cursor é desbloqueado com o comando CLOSE. Os cursores existem principalmente para que linguagens de programação que não permitem abstração para conjunto de registros, como C, possam receber as linhas da resposta de uma consulta SQL uma de cada vez. Com a utilização de "CURSORES", apresentam-se esses dados como resultados das consulta, através de itens que representam os elementos de interface com o usuário, atendendo os preceitos impostos pelos diferentes paradigmas possivelmente envolvidos. Com isso os resultados são mostrados utilizando o objeto padrão da interface, disponíveis nas ferramentas de construção de interfaces. Dessa forma, o ciclo de busca de informação nos mais variados servidores tem início e fim na interface com o usuário. É de fundamental importância que se construam aplicativos cujos projetos de interface sejam "ortogonais" aos projetos de implementação de acesso aos servidores de dados. Na implementação de sistemas de informação, deve-se utilizar uma arquitetura de base de dados relacional que seja independente de um determinado repositório de dados (gerenciadores Access, Oracle, Sybase, Informix, etc). A Figura 1.7 ilustra a utilização de conversores genéricos tanto para interfaces como para os servidores de dados. Estes conversores são construídos para padronizar o controle de compartilhamento de dados, independente da ferramenta de interface ou do servidor de dados. Em situações práticas esses conversores são denominados comumente de drivers. Introdução a Banco de Dados O.K. Takai; I.C.Italiano; J.E. Ferreira. 18 2.5 Quando não utilizar um SGBD ° bases de dados e aplicações simples, bem definidas sem expectativa de mudança; ° existem restrições de tempo que não podem ser satisfeitas em SGBD’s; ° não há necessidade de acesso multiusuário. 2.6 Profissionais e Atividades envolvidas em um SGBD • Administrador da Base de Dados: em qualquer organização 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 primário é a própria base de dados e os recursos secundários são o próprio SGBD e softwares relacionados. A administração desses recursos é de responsabilidade do DBA (“Database Administrator”). O DBA é responsável por autorizar acesso à base de dados e coordenar e monitorar seu uso. O DBA é responsável por problemas, tais como, quebra de segurança ou baixo desempenho. Em grandes organizações, o DBA é auxiliado por técnicos; • Projetistas da Base de Dados: os projetistas de base de dados têm 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 são geralmente executadas antes que a base de dados seja utilizada. É responsabilidade destes projetistas obter os requisitos necessários dos futuros usuários da base. Tipicamente, os projetistas interagem com cada grupo de usuários em potencial e definem visões da base de dados para adequar os requisitos e processamentos de cada grupo. Estas visões são então analisadas e, posteriormente, integradas para que, ao final, o projeto da base de dados possa ser capaz de dar subsídio aos requisitos de todos os grupos de usuários; • Analistas de Sistemas e Programadores de Aplicação: ⇒ analistas de sistemas determinam os requisitos de usuários finais, especialmente dos usuários comuns, e desenvolvem especificações das transações para atender a estes requisitos; ⇒ programadores de aplicações implementam estas especificações produzindo programas e, então, testam, depuram, documentam e mantêm estes programas. Analistas e programadores devem estar familiarizados com todas as capacidades fornecidas pelo SGBD para desempenhar estas tarefas. • Usuários Finais: existem profissionais que precisam ter acesso à base de dados para consultar, modificar e gerar relatórios. A base de dados existe para estes usuários. Existem algumas categorias de usuários finais: ⇒ usuários ocasionais: ocasionalmente fazem acesso à base de dados, mas eles podem necessitar de diferentes informações a cada vez que fazem acesso. Eles podem usar uma linguagem de consulta sofisticada para especificar suas requisições e são, tipicamente, gerentes de médio ou alto-nível; ⇒ usuários comuns ou paramétricos: estes usuários realizam operações padrões de consultas e atualizações, chamadas TRANSAÇÕES PERMITIDAS, que foram cuidadosamente programadas e testadas. Estes usuários constantemente realizam recuperações e modificações na base de dados; ⇒ usuários sofisticados: incluem engenheiros, analistas de negócios 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 Manutenção Introdução a Banco de Dados O.K. Takai; I.C.Italiano; J.E. Ferreira. 19 3 Conceitos e Arquiteturas de SGBD’s 3.1 Modelos de Dados, Esquemas e Instâncias Uma das características fundamentais da abordagem de base de dados é que ela fornece algum nível de abstração de dados, pela omissão de detalhes de armazenamento de dados que não são necessários para a maioria dos usuários. O modelo de dados é a principal ferramenta que fornece esta abstração. 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 restrições pertinentes aos dados. Muitos modelos de dados também definem um conjunto de operações para especificar como recuperar e modificar a base de dados. 3.1.1 Categorias de Modelos de Dados Muitos modelos de dados têm 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-Nível fornecem conceitos próximos à percepção dos usuários. Já os Modelos de Dados Físicos ou de Baixo-Nível fornecem conceitos que descrevem os detalhes de como os dados são armazenados no computador. Modelos de alto-nível 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 são facilmente representados em modelos de dados de alto-nível, que são algumas vezes chamados de Modelos Baseados em Objeto devido, principalmente, a sua característica de descreverem objetos e seus relacionamentos. Modelos de Dados de Baixo-Nível descrevem como os dados são armazenados no computador, representando informações 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 Instâncias Em qualquer modelo de dados é importante distinguir entre a descrição da base de dados e a base de dados propriamente dita. A descrição 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 mudanças não é grande. A forma de visualização de um esquema é chamada Diagrama do Esquema. Muitos modelos de dados têm certas convenções para, diagramaticamente, mostrar esquemas especificados no modelo. Os dados atualmente existentes em uma base de dados podem mudar com relativa freqüência. Os dados da base de dados em um particular momento do tempo são chamados Instâncias da Base de Dados (ou Ocorrências ou Estados). A base-esquema é algumas vezes chamada de Base-Intencional e uma instância é chamada de Base-Extensional do esquema. Introdução a Banco de Dados O.K. Takai; I.C.Italiano; J.E. Ferreira. 24 Endereço Endereço da Rua Cidade Estado CEP Nome da Rua Número Apartamento Figura 4.3 – Um exemplo de atributo composto Atributos compostos são úteis quando os usuários 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, não existe razão para subdividi-lo em componentes elementares. Muitos atributos têm apenas um único valor. Tais atributos são chamados atributos uni- valorados (exemplo, Data de nascimento da entidade e1). Em outros casos, um atributo pode ter um conjunto de valores. Tais atributos são chamados de atributos multivalorados (exemplo, Telefone residencial da entidade e1). Atributos multivalorados podem possuir uma multiplicidade, indicando as quantidades mínima e máxima de valores. Em alguns casos, dois ou mais atributos são 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 são chamados atributos derivados3. Alguns valores de atributos podem ser derivados de entidades relacionadas. Por exemplo, um atributo Número de Empregados de uma entidade departamento que pode ser calculado contando-se o número de empregados relacionados com o departamento. Outras situações: uma entidade pode não ter quaisquer valores para um atributo. Por exemplo, o atributo Apartamento aplica-se somente àqueles empregados que residam em algum prédio. Para tais situações, um valor especial chamado null é criado. O valor null pode também ser utilizado para denotar que o valor é desconhecido, como por exemplo, quando o cliente em um cadastro não responde o número do CEP da rua onde reside. O significado para o primeiro uso do null é “não aplicável” 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 são similares. Uma companhia com centenas de empregados pode querer agrupar as informações similares com respeito a empregados. Estas entidades, empregados, compartilham os mesmos atributos, mas cada entidade terá seus próprios valores para cada atributo. Tais entidades similares definem o tipo de entidade, que é um conjunto de entidades que têm 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 instâncias são também ilustradas, juntamente com os seus valores de atributos: 3 Atributos derivados não necessitam ser armazenados na base de dados, podendo ser calculados por meio de uma consulta. Introdução a Banco de Dados O.K. Takai; I.C.Italiano; J.E. Ferreira. 21 • Independência Lógica de Dados: É a capacidade de alterar o esquema conceitual sem ter que mudar os esquemas externos ou programas de aplicação. Pode-se mudar o esquema conceitual para expandir a base de dados, com a adição 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 não devem ser afetados; • Independência Física de Dados: É a capacidade de alterar o esquema interno sem ter que alterar o esquema conceitual externo. Mudanças no esquema interno podem ser necessárias devido a alguma reorganização de arquivos físicos para melhorar o desempenho nas recuperações e/ou modificações. Após a reorganização, se nenhum dado foi adicionado ou perdido, não haverá necessidade de modificar o esquema conceitual. 3.3 Linguagens de Base de Dados • Linguagem de Definição 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 descrições em DDL e construir a descrição do esquema armazenado no catálogo; • Linguagem de Manipulação de Dados (“Data Manipulation Language” - DML): uma vez que o esquema é compilado e a base de dados preenchida com dados, os usuários têm que ter algum modo de manipular os dados. Manipulações comuns como recuperação, inserção, remoção e modificação de dados são realizadas pela DML. Introdução a Banco de Dados O.K. Takai; I.C.Italiano; J.E. Ferreira. 22 4 Modelagem de Dados Usando o Modelo Entidade- Relacionamento (MER) O MER é um modelo de dados conceitual de alto-nível, ou seja, seus conceitos foram projetados para serem compreensíveis a usuários, descartando detalhes de como os dados são armazenados. Atualmente, o MER é usado principalmente durante o processo de projeto da base de dados. Existem expectativas para que uma classe de SGBD’s baseados diretamente no MER esteja disponível no futuro. 4.1 Modelo de Dados Conceitual de Alto-Nível e Projeto de Base Dados Mini-Mundo OBTENÇÃO E ANÁLISE DE REQUISITOS Requisitos da Base de Dados PROJETO CONCEITUAL Esquema Conceitual (em um Modelo de Dados de Alto-Nível) MAPEAMENTO DO MODELO DE DADOS Esquema Conceitual (em um Modelo de Dados de um SGBD específico) PROJETO FÍSICO Esquema Interno (para o mesmo SGBD) Independente de qualquer SGBD SGBD específico 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. São listados os requisitos da base de dados e criado o seu esquema conceitual passo-a-passo ao mesmo tempo em que são introduzidos os conceitos de modelagem usando o MER. A base de dados COMPANHIA armazena os dados dos empregados, departamentos e projetos. Supõe-se que após a Obtenção e Análise dos Requisitos, os projetistas da base de dados produziram a seguinte descrição do mini-mundo - parte da companhia a ser representada na base de dados: Introdução a Banco de Dados O.K. Takai; I.C.Italiano; J.E. Ferreira. 23 • A companhia é organizada em departamentos. Cada departamento tem um nome, um número e um empregado que gerencia o departamento. Armazena-se a data de início que o empregado começou a gerenciar o departamento. Um departamento pode ter diversas localizações; • Um departamento controla inúmeros projetos, sendo que cada um tem um nome, um número e uma localização; • Do empregado armazena-se o nome, o número do seguro social, endereço, salário, sexo e data de nascimento. Todo empregado é associado a um departamento, mas pode trabalhar em diversos projetos, que não são necessariamente controlados pelo mesmo departamento. Armazena-se, também, o número de horas que o empregado trabalha em cada projeto. Mantém-se, ainda, a indicação do supervisor direto de cada projeto; • Os dependentes de cada empregado são armazenados para propósito de garantir os benefícios 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 básico que o MER representa é a entidade. Uma entidade é algo do mundo real que possui uma existência independente. Uma entidade pode ser um objeto com uma existência física - uma pessoa, carro ou empregado - ou pode ser um objeto com existência conceitual - uma companhia, um trabalho ou um curso universitário. 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, endereço e salário. 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, Endereço, Data de nascimento e Telefone residencial. Os seus valores são: “João da Silva”, “Rua Goiás 711, São Paulo, SP, 1301100”, “31/07/1973” e “713-749”, respectivamente. A entidade c1, COMPANHIA, tem três atributos: Nome, Sede e Presidente. Seus valores são: “Cooper Sugar”, “Ribeirão Preto” e “João da Silva”. Figura 4.2 – Exemplo de entidades e seus respectivos atributos Alguns atributos podem ser divididos em subpartes com significados independentes. Por exemplo, Endereço da entidade e1 pode ser dividido em Endereço da Rua, Cidade, Estado e CEP. Um atributo que é composto de outros atributos mais básicos é chamado composto. Já, atributos que não são divisíveis são chamados simples ou atômicos. Atributos compostos podem formar uma hierarquia, conforme pode ser observado no exemplo da Figura 4.3. e 1 Nome=João da Silva Endereço=Rua Goiás 711, Idade=55 Telefone residencial=713-749 c 1 Nome=Cooper Sugar Sede=Ribeirão Preto Presidente=João da Silva São Paulo, SP, 1301100 D ta de nascimento = 31/07/1973 Introdução a Banco de Dados O.K. Takai; I.C.Italiano; J.E. Ferreira. 32 Os tipos de entidades-fracas são distinguidos por retângulos com linhas duplas e os relacionamentos de identificação por losângulos com linhas duplas (tipo de entidade-fraca DEPENDENTE e tipo de relacionamento de identificação DEPENDENTE-DE). A chave-parcial de um tipo de entidade-fraca é sublinhada com linha tracejada. TRABALHA-PARA GERENCIA Pnome Mnome Snome Nome Nss DataNasc Endereço SalárioSexo DEPARTAMENTO Nome Número Localização NúmeroDeEmpregadosDataInício CONTROLA PROJETO EMPREGADO TRABALHA-EM HorasSUPERVISIONA DEPENDENTE-DE DEPENDENTE Nome Sexo DataNasc Relação supervisor supervisiona 1 N 1 N M N 1 N 1 1 N 1 Nome Número Localização Figura 4.10 – Diagrama Entidade Relacionamento para o Esquema Companhia Na Figura 4.10 são mostradas as razões de cardinalidade para cada tipo de relacionamento binário. A razão de cardinalidade de DEPARTAMENTO:EMPREGADO em GERENCIA é 1:1, para DEPARTAMENTO:EMPREGADO em TRABALHA-PARA é 1:N e M:N para TRABALHA- EM. As restrições de participação parcial são especificadas por linhas simples. As linhas paralelas denotam participação total (dependência existencial). Na Figura 4.10 foram mostrados os nomes de papéis para o tipo de relacionamento SUPERVISIONA porque o tipo de entidade EMPREGADO ocupa dois papéis neste relacionamento. Na Figura 4.11 é mostrado o mesmo esquema da Figura 4.10, porém com a utilização da notação alternativa para ilustrar as restrições estruturais de tipos de relacionamentos. Introdução a Banco de Dados O.K. Takai; I.C.Italiano; J.E. Ferreira. 29 EMPREGADO TRABALHA-EM PROJETO e 1 e 2 e 3 e 4 ♦ ♦ ♦ ♦ r 1 r 2 r 3 p 1 p 2 p 3 ♦ ♦ ♦r 4 r 5 r 6 r 7 p 4♦ Figura 4.9 – Exemplo de um relacionamento binário M:N A restrição de participação especifica se a existência de uma entidade depende dela estar relacionada com outra entidade através de um relacionamento. Existem dois tipos de restrições de participação: total e parcial. Se uma companhia estabelece a regra de que todo empregado deve trabalhar para um departamento, então uma entidade empregado somente pode existir se ele participar em uma instância de relacionamento TRABALHA- PARA. A participação 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 restrição de participação total é algumas vezes chamada dependência existencial. Não é esperado, na Figura 4.8, que todo empregado gerencie um departamento, assim a participação de EMPREGADO no tipo de relacionamento GERENCIA é parcial. Isso significa que algumas entidades, do conjunto de entidades EMPREGADO, poderão estar relacionadas a uma entidade departamento via GERENCIA, mas não necessariamente todas. As restrições de participação e razão de cardinalidade podem ser derivadas da restrição estrutural de um tipo de relacionamento. É simples especificar as restrições estruturais, embora não seja tão intuitiva quanto às restrições de participação e razão de cardinalidade. Pode-se associar um par de números inteiros (min, max) para cada participação de um tipo de entidade E em um tipo de relacionamento R, onde 0 ≤ min ≤ max e max ≥1. Os números indicam que para cada entidade e em E, e deve participar ao menos min e no máximo max vezes em instâncias de relacionamento de R. Note-se, que se min=0 então a restrição de participação é parcial e se min>0 então a participação é total. A vantagem de usar este método é que ele é mais preciso e pode ser usado facilmente para especificar restrições estruturais para tipos de relacionamentos de qualquer grau. • Atributos em Tipos de Relacionamento: Os tipos de relacionamento também 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 instância de relacionamento TRABALHA-EM na forma de atributo denominado Horas. Um outro Introdução a Banco de Dados O.K. Takai; I.C.Italiano; J.E. Ferreira. 30 exemplo é o caso de representar a data em que um gerente começou a gerenciar um departamento através de um atributo DataInício para o tipo de relacionamento GERENCIA (Figura 4.8). Note-se que atributos de tipos de relacionamento 1:1 ou 1:N podem ser incluídos como atributos de um dos tipos de entidades participantes. Por exemplo, o atributo DataInício para o tipo de relacionamento GERENCIA pode ser um atributo tanto de EMPREGADO quanto de DEPARTAMENTO; embora, conceitualmente, ele pertença ao relacionamento GERENCIA. Isso ocorre porque GERENCIA é um relacionamento 1:1. Assim, toda entidade departamento ou empregado participam em apenas uma instância de relacionamento e, dessa forma, o valor do atributo DataInício 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 DataInício indicando quando um empregado começou 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 instância de TRABALHA-PARA. Em ambos os tipos de relacionamento 1:1 e 1:N, a decisão de onde colocar um atributo de relacionamento é determinada subjetivamente pelo projetista de esquemas. Se o valor de um atributo é determinado pela combinação das entidades participantes em uma instância de relacionamento, e não apenas por uma das entidades, então o atributo deve ser especificado como um atributo de relacionamento. Esta condição aplica-se a atributos de tipos de relacionamentos M:N, porque as entidades dos tipos de entidades participantes podem participar em inúmeras instâncias de relacionamento. Um exemplo disso é o atributo Horas do relacionamento M:N TRABALHA-EM (Figura 4.9). O número de horas que um empregado trabalha em um projeto é determinado pela combinação empregado-projeto e não separadamente. 4.3.4 Tipo de Entidade-Fraca Alguns tipos de entidades podem não ter quaisquer atributos-chaves. Isto implica que não se pode distinguir as entidades porque a combinação dos valores de atributos podem ser idênticas. Tais tipos de entidades são chamadas tipos de entidades-fracas. Entidades que pertencem a um tipo de entidade-fraca são identificadas por estarem associadas a entidades específicas de um outro tipo de entidade em combinação com alguns de seus valores de atributos. Este outro tipo de entidade é denominado proprietário da identificação, e o tipo de relacionamento que relaciona um tipo de entidade-fraca com o proprietário da identificação é chamado relacionamento de identificação do tipo de entidade-fraca. Um tipo de entidade- fraca sempre tem uma restrição de participação total (dependência existencial) com respeito ao seu relacionamento de identificação, porque não é possível identificar uma entidade-fraca sem a correspondente entidade proprietária. Por exemplo, considere o tipo de entidade DEPENDENTE, relacionado a EMPREGADO, que é usado para representar os dependentes de cada empregado através do relacionamento 1:N. Os atributos de DEPENDENTE são Nome (apenas o primeiro nome do dependente), DataNasc, Sexo e Relação 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 serão entidades distintas. Os dependentes serão identificados como entidades distintas após a determinação da entidade empregado com a qual cada um está relacionado. Introdução a Banco de Dados O.K. Takai; I.C.Italiano; J.E. Ferreira. 31 Um tipo de entidade-fraca tem uma chave-parcial, que é um conjunto de atributos que pode univocamente identificar entidades-fracas relacionadas à mesma entidade proprietária. No exemplo, assume-se que nenhum dependente de um mesmo empregado terá o mesmo nome, então 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 são Nome, DataNasc, Sexo e Relação, substituindo-se assim, o tipo de entidade-fraca DEPENDENTE. A escolha de qual representação usar é determinada pelo projetista da base de dados. Um critério usado para se adotar a representação de tipo de entidade-fraca é quando o tipo de entidade-fraca tem muitos atributos ou participa, independentemente, em outros tipos de relacionamentos além 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 extraídos do exemplo apresentado na seção 4.2. a. GERENCIA (1:1) entre EMPREGADO e DEPARTAMENTO. A participação de EMPREGADO é parcial. A participação de DEPARTAMENTO é total. O atributo DataInício é associado a este tipo de relacionamento. b. TRABALHA-PARA (1:N) entre DEPARTAMENTO e EMPREGADO. Ambos têm participação total. c. CONTROLA (1:N) entre DEPARTAMENTO e PROJETO. A participação de PROJETO é total e de DEPARTAMENTO é parcial. d. SUPERVISIONA (1:N) entre EMPREGADO (no papel de supervisor) e EMPREGADO (no papel de supervisionado). A participação 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 têm participação total. f. DEPENDENTE-DE (1:N) entre EMPREGADO e DEPENDENTE. É um tipo de relacionamento de identificação para o tipo de entidade-fraca DEPENDENTE. A participação 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 extensões (as entidades e instâncias de relacionamentos). Em diagramas do MER, ou simplesmente DER, a ênfase está na representação de esquemas ao invés de instâncias. Isso porque o esquema de uma base de dados raramente sofre mudanças, já instâncias podem mudar freqüentemente. Também, o esquema é de fácil visualização 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 são mostrados em retângulos. Tipos de relacionamentos tais como TRABALHA-PARA, GERENCIA, CONTROLA e TRABALHA-EM são mostrados em losângulos interligados a tipos de entidades participantes. Atributos são mostrados em elipses conectadas a tipos de entidades ou relacionamentos. Os componentes de um atributo composto são também representados em elipses, porém conectadas ao atributo ao qual eles pertencem (atributo Nome de EMPREGADO). Atributos multivalorados são denotados em elipses com linhas duplas (atributo Localização de DEPARTAMENTO). Os atributos-chaves são sublinhados. Atributos derivados em elipses com linhas tracejadas (atributo NumeroDeEmpregados de DEPARTAMENTO). Introdução a Banco de Dados O.K. Takai; I.C.Italiano; J.E. Ferreira. 36 Sumário da Notação do Diagrama Entidade-Relacionamento (DER) Símbolo Significado Tipo de Entidade Tipo de Entidade-Fraca Tipo de Relacionamento Tipo de Relacionamento Identificador Atributo Atributo-Chave Atributo Multivalorado Atributo Composto .... Atributo Derivado E1 R E2 Participação Total de E2 em R Razão de Cardinalidade 1:N para E1:E2 em R E1 R E2 1 N R E (min, max) Restrição Estrutural (min, max) na participação de E em R Introdução a Banco de Dados O.K. Takai; I.C.Italiano; J.E. Ferreira. 33 TRABALHA-PARA GERENCIA Pnome Mnome Snome Nome Nss DataNasc Endereço SalárioSexo DEPARTAMENTO Nome Número Localização NúmeroDeEmpregadosDataInício CONTROLA PROJETO EMPREGADO TRABALHA-EM HorasSUPERVISIONA DEPENDENTE-DE DEPENDENTE Nome Sexo DataNasc Relação supervisor supervisiona (0,n) (0,1) (0,n) (1,1) (1,n) (1,n) (0,n) (1,1) (0,1) (1,1) (1,1) (4,n) Nome Número Localização Figura 4.11 – DER para o Esquema Companhia com notação alternativa 4.5 Tipos de Relacionamentos de Grau maior que Dois Na Seção 4.3.3 definiu-se grau de um tipo de relacionamento como o número de tipos de entidades participantes e chamou-se o tipo de relacionamento de grau dois de binário e de grau três de ternário. A notação do DER para um tipo de relacionamento ternário é mostrada na Figura 4.13(a), que mostra o esquema para o tipo de relacionamento FORNECE que foi mostrado no nível de extensão 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 binário PODE-FORNECER, USA E FORNECE-ALGO. Como visto na Seção 4.3.3, estes três tipos de relacionamento binário não são equivalentes ao tipo de relacionamento ternário FORNECE. É freqüentemente difícil 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 semântica, ou pelo significado da situação particular que estiver representando, para decidir qual alternativa adotar. Um outro exemplo é mostrado na Figura 4.13(c). O tipo de relacionamento ternário FORNECE representa a informação sobre os instrutores que oferecem cursos em um dado semestre. Assim, ele possui uma instância de relacionamento (i, s, c) onde o instrutor i oferece o curso c Introdução a Banco de Dados O.K. Takai; I.C.Italiano; J.E. Ferreira. 38 5 O Modelo de Dados Relacional O Modelo de Dados Relacional foi introduzido por Codd (1970). Entre os modelos de dados de implementação, o modelo relacional é o mais simples, com estrutura de dados uniforme, e também o mais formal. 5.1 Conceitos do Modelo Relacional O modelo de dados relacional representa os dados da base de dados como uma coleção de relações. Informalmente, cada relação 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. Porém, existem diferenças importantes entre relações e arquivos. ESTUDANTE Nome Número Classe Departamento Soares 17 1 DCC Botelho 8 2 DCC CURSO Nome Número Créditos Departamento Introd. Ciências de Comp. DCC1310 4 DCC Estrutura de Dados DCC3320 4 DCC Matemática Discreta MAT2410 4 MAT Base de Dados DCC3380 4 DCC PRÉ-REQUISITO Número Pré-requisito DCC3380 DCC3320 DCC3380 MAT2410 DCC3320 DCC1310 SEÇÃO Número Curso Semestre Ano Professor 85 MAT2410 1 86 Kotaro 92 DCC1310 1 86 Alberto 102 DCC3320 2 87 Kleber 112 MAT2410 1 87 Carlos 119 DCC1310 1 87 Alberto 135 DCC3380 1 87 Souza HISTÓRICO NúmeroEstudante NúmeroSeção Nível 17 112 B 17 119 C 8 85 A 8 92 A 8 102 B 8 135 A Figura 5.1 – Exemplo de uma base de dados relacional Quando uma relação é vista como uma tabela de valores, cada linha representa uma coleção de valores relacionados. Esses valores podem ser interpretados como um fato que descreve uma entidade ou uma instância de relacionamento. O nome da tabela e os nomes das colunas são usados para ajudar a interpretar o significado dos valores em cada linha da tabela. Por Introdução a Banco de Dados O.K. Takai; I.C.Italiano; J.E. Ferreira. 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, Número, 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 são, 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 relação. O tipo de dado que especifica o tipo dos valores que podem aparecer em uma coluna é chamado de domínio. Uma relação esquema R, denotada por R(A 1 , A 2 , ..., A n ), é um conjunto de atributos R={A 1 , A 2 , ..., A n }. Cada atributo A i indica o nome do papel de algum domínio D na relação esquema R. D é chamado domínio de A i e denotado por dom(A i ). Uma relação esquema é utilizada para descrever uma relação e R é o nome dessa relação. O grau de uma relação é o número de atributos da relação. Considere o exemplo de uma relação esquema de grau 7, que descreve estudantes universitários: ESTUDANTE(Nome, NSS, Telefone, Endereço, TelComercial, Anos, MPA) Nesta relação esquema, ESTUDANTE é o nome da relação esquema, que tem 7 atributos. Pode-se especificar alguns domínios para atributos da relação ESTUDANTE: dom(Nome)=Nomes dom(NSS)=Número do seguro social dom(Telefone)=Número de telefone nacional dom(TelComercial)=Número de telefone nacional dom(MPA)=Média dos Pontos Acumulados Uma relação r (ou instância de relação) da relação esquema R(A 1 , A 2 , ..., A n ), também denotada por r(R), é um conjunto de tuplas r={ t 1 , t 2 , ..., t m }. Cada tupla t é uma lista ordenada de n valores t=<v 1 , v 2 , ..., v n >, onde cada valor v i , 1 ≤ i ≤ n, é um elemento do dom(A i ) ou um valor especial null. São utilizados, com freqüência, os termos intenção da relação para o esquema R e extensão da relação para a instância r(R). Atributos ESTUDANTE Nome NSS Telefone Endereço TelComercial Anos MPA Joaquim 305 555-444 R. X, 123 null 19 3.21 Katarina 381 555-333 Av. K, 43 null 18 2.89 tuplas Daví 422 null R. D, 12 555-678 25 3.53 Carlos 489 555-376 R. H, 9 555-789 28 3.93 Barbara 533 555-999 Av. f, 54 null 19 3.25 Figura 5.2 – Exemplos de instâncias para uma relação ESTUDANTE. A Figura 5.2 mostra um exemplo de uma relação ESTUDANTE, que corresponde ao esquema estudante especificado anteriormente. Cada tupla na relação representa uma entidade estudante. A relação é mostrada em forma de tabela, onde cada tupla é representada pelas linhas e cada atributo na linha de cabeçalho indicando os papéis ou a interpretação dos valores encontrados em cada coluna. 5.1.1 Notação do Modelo Relacional As seguintes notações serão utilizadas para apresentar alguns conceitos do modelo relacional: Introdução a Banco de Dados O.K. Takai; I.C.Italiano; J.E. Ferreira. 44 Todas as restrições de integridade deveriam ser especificadas no esquema da base de dados relacional se o projetista tiver interesse em manter essas restrições válidas para toda a base de dados. Assim, em um sistema relacional, a linguagem de definição de dados (DDL) deveria fornecer recursos para especificar os vários tipos de restrições tal que o SGDB possa verificá- las automaticamente. Muitos sistemas de gerenciamento de base de dados relacionais permitem restrições de chave e de integridade de entidade mas, infelizmente, alguns não permitem a integridade referencial. Além dos tipos de restrições descritas acima, existem outras mais gerais, algumas vezes chamadas de restrições de integridade semânticas, que podem ser especificadas e verificadas numa base de dados relacional. Exemplos de tais restrições são "o salário de um empregado não deve ultrapassar o salário de seu supervisor" e "o número máximo de horas por semana que um empregado pode trabalhar num projeto é 56". Tais restrições não são verificadas por SGBD relacionais atualmente encontrados no mercado. 5.1.4 Operações de Atualizações sobre Relações Existem três tipos básicos de operação de atualização sobre relações - inserção, remoção e modificação. A inserção é usada para inserir novas tuplas em uma relação, a remoção elimina tuplas e a modificação modifica os valores de alguns atributos. Quando são aplicadas operações de atualização, o projetista deve verificar que as restrições de integridade especificadas no esquema da base de dados relacional não sejam violadas. Introdução a Banco de Dados O.K. Takai; I.C.Italiano; J.E. Ferreira. 41 Em geral, uma relação esquema pode ter mais que uma chave. Nestes casos, cada chave é chamada chave-candidata. Por exemplo, o esquema da relação ESTUDANTE poderia ter um atributo adicional Código, para indicar o código interno de estudantes na escola. Assim, o esquema teria duas chaves candidatas: NSS e Código. É comum designar uma das chaves candidatas como a chave-primária da relação. A indicação no modelo de qual chave- candidata é a chave-primária é realizada sublinhado-se os atributos que formam a chave- candidata escolhida. Quando uma relação esquema tem muitas chaves-candidatas, a escolha da chave-primária é arbitrária; no entanto, é sempre melhor escolher a chave-primária com o menor número de atributos. 5.1.3 Esquemas de Bases de Dados Relacionais e Restrições de Integridade • Definição de um esquema de base de dados relacional e instância da base de dados relacional: um esquema da base de dados relacional, S, é um conjunto de relações esquemas S={R 1 , R 2 , ..., R m } e um conjunto de restrições de integridade (RI). Uma instância da base de dados relacional, DB de S, é um conjunto de instâncias de relações DB={r 1 , r 2 , ..., r m } tal que r i é uma instância de R i e que satisfaz as restrições 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 instâncias. EMPREGADO PNOME MNOME SNOME NSS DATANASC ENDEREÇO SEXO SALARIO NSSSUPER NDEP DEPARTAMENTO DNOME DNÚMERO NSSGER DATINICGER LOCAIS_DEPTO DNÚMERO DLOCALIZAÇÃO PROJETO PNOME PNÚMERO PLOCALIZAÇÃO DNUM TRABALHA_EM NSSEMP PNRO HORAS DEPENDENTE NSSEMP NOMEDEPENDENTE SEXO DATANIV RELAÇÃO Figura 5.3 – Esquema da base de dados relacional COMPANHIA Observa-se, na Figura 5.3 acima, que o atributo DNÚMERO tanto de DEPARTAMENTO quanto de LOCAIS_DEPTO referem-se ao mesmo conceito do mundo real - o número 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, também, que atributos que representam conceitos diferentes tenham o mesmo nome desde que em relações diferentes. Por exemplo, poderia ter sido usado NOME ao invés de PNOME e DNOME nas relações esquemas PROJETO e DEPARTAMENTO, respectivamente. • Restrições de Integridade sobre um Esquema de Base de Dados Relacional: as restrições de chave especificam as chaves-candidatas de cada relação esquema; os valores das chaves-candidatas devem ser únicos para todas as tuplas de quaisquer instâncias da relação esquema. Além da restrição de chave, dois outros tipos de restrições são consideradas no modelo relacional: integridade de entidade e integridade referencial. Introdução a Banco de Dados O.K. Takai; I.C.Italiano; J.E. Ferreira. 42 A restrição de integridade de entidade estabelece que nenhum valor da chave-primária pode ser nulo. Isso porque, o valor de uma chave-primária é utilizado para identificar tuplas em uma relação. Por exemplo, se duas ou mais tuplas tiverem o valor null para a chave- primária, não haverá como diferenciar uma tupla da outra. As restrições de chave e de integridade de entidade aplicam-se apenas a relações individuais. A restrição de integridade referencial é uma restrição que é especificada entre duas relações e é usada para manter a consistência entre tuplas de duas relações. Informalmente, a restrição de integridade referencial estabelece que uma tupla de uma relação que se refere à outra relação deve se referir a uma tupla existente naquela relação. Por exemplo, na Figura 5.4, o atributo NDEP de EMPREGADO indica o número do departamento que cada empregado trabalha. Assim, todos os valores de NDEP nas tuplas da relação EMPREGADO devem pertencer ao conjunto de valores do atributo DNÚMERO da relação DEPARTAMENTO. EMPREGADO PNOME MNOME SNOME NSS DATANASC ENDEREÇO SEXO SALARIO NSSSUPER NDEP John B Smith 123456789 09-JAN-55 R. A, 1 M 3000 333445555 5 Franklin T Wong 333445555 08-DEZ-45 R. B, 2 M 4000 888665555 5 Alicia J Zelaya 999887777 19-JUL-58 Av. C, 3 F 2500 987654321 4 Jennifer S Wallace 987654321 20-JUN-31 Trav. D, 4 F 4300 888665555 4 Ramesh K Narayan 666884444 15-SET-52 R. E, 5 M 3800 333445555 5 Joyce A English 453453453 31-JUL-62 R. F, 6 F 2500 333445555 5 Ahmad V Jabbar 987987987 29-MAR-59 Av G, 7 M 2500 987654321 4 James E Borg 888665555 10-NOV-27 Av H, 8 M 5500 null 1 DEPARTAMENTO DNOME DNÚMERO NSSGER DATINICGER Pesquisa 5 333445555 22-MAI-78 Administrativo 4 987654321 01-JAN-85 Gerencial 1 888665555 19-JUN-71 LOCAIS_DEPTO DNÚMERO DLOCALIZAÇÃO 1 Houston 4 Stafford 5 Bellaire 5 Sugariand 5 Houston PROJETO PNOME PNÚMERO PLOCALIZAÇÃO DNUM ProdutoX 1 Bellaire 5 ProdutoY 2 Sugarland 5 ProdutoZ 3 Houston 5 Automação 10 Stafford 4 Reorganização 20 Houston 1 Beneficiamento 30 Stafford 4 TRABALHA_EM NSSEMP PNRO HORAS 123456789 1 32.5 123456789 2 7.5 666884444 3 40.0 453453453 1 20.0 453453453 2 20.0 333445555 2 10.0 333445555 3 10.0 333445555 10 10.0 333445555 20 10.0 999887777 30 30.0 999887777 10 10.0 987987987 10 35.0 987987987 30 5.0 987654321 30 20.0 987654321 20 Null DEPENDENTE NSSEMP NOMEDEPENDENTE SEXO DATANIV RELAÇÃO 333445555 Alice F 05-ABR-76 FILHA 333445555 Theodore M 25-OUT-73 FILHO 333445555 Joy F 03-MAI-48 ESPOSA 987654321 Abner M 29-FEV-78 MARIDO 123456789 Michael M 01-JAN-78 FILHO 123456789 Alice F 31-DEZ-78 FILHA 123456789 Elizabeth F 05-MAI-57 ESPOSA Figura 5.4 – Instâncias para a base de dados relacional COMPANHIA Introdução a Banco de Dados O.K. Takai; I.C.Italiano; J.E. Ferreira. 43 Para definir formalmente a restrição de integridade referencial, há a necessidade de antes definir o conceito de chave-estrangeira (CE). As condições para uma chave-estrangeira, descritas abaixo, especificam uma restrição de integridade referencial entre duas relações esquemas R 1 e R 2 . Um conjunto de atributos CE na relação esquema R 1 será uma chave- estrangeira de R 1 se ele satisfizer as seguintes regras: 1. Os atributos em CE têm o mesmo domínio dos atributos da chave-primária CP da outra relação esquema R 2 . Diz-se que os atributos CE referenciam ou referem-se à relação R 2 . 2. Uma CE na tupla t 1 ou tem um valor que ocorre como CP de alguma tupla t 2 de R 2 ou tem o valor null. No primeiro caso, tem-se t 1 [CE]=t 2 [CP], e diz-se que t 1 referencia ou refere-se à tupla t 2 . Uma base de dados tem muitas relações, e usualmente possuem muitas restrições de integridade referencial. Para especificar estas restrições, o projetista deve ter um claro entendimento do significado ou papel que os atributos desempenham nas diversas relações esquemas da base de dados. Normalmente, as restrições de integridade referencial são derivadas dos relacionamentos entre entidades representadas pelas relações esquemas. Por exemplo, considere a base de dados mostrada na 5.4. Na relação 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 relação DEPARTAMENTO. Isso significa que um valor de NDEP em alguma tupla t 1 da relação EMPREGADO deve ter um valor correspondente para a chave-primária da relação DEPARTAMENTO - o atributo DNÚMERO - em alguma tupla t 2 da relação DEPARTAMENTO ou o valor de NDEP pode ser null se o empregado não 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 própria relação. Por exemplo, o atributo NSSSUPER em EMPREGADO refere-se ao supervisor de um empregado; isto é, um outro empregado. Pode-se, diagramaticamente, mostrar as restrições de integridade desenhando-se arcos direcionados partindo da chave-estrangeira para a relação referenciada. A Figura 5.5 ilustra o esquema apresentado na Figura 5.3 com as restrições de integridade referencial anotadas desta maneira. EMPREGADO PNOME MNOME SNOME NSS DATANASC ENDEREÇO SEXO SALARIO NSSSUPER NDEP DEPARTAMENTO DNOME DNÚMERO NSSGER DATINICGER LOCAIS_DEPTO DNÚMERO DLOCALIZAÇÃO PROJETO PNOME PNÚMERO PLOCALIZAÇÃO DNUM TRABALHA_EM NSSEMP PNRO HORAS DEPENDENTE NSSEMP NOMEDEPENDENTE SEXO DATANIV RELAÇÃO Figura 5.5 - Esquema COMPANHIA com restrições de integridade