O surgimento da tecnologia de Banco de Dados (BD) ocorreu no momento em que os especialistas no desenvolvimento de sistemas computacionais perceberam que, para a informatização de grandes organizações, várias questões relacionadas com o gerenciamento de dados necessitavam ser resolvidas de uma forma mais eficiente.
Para ilustrar esta situação, pode-se tomar como exemplo uma organização como a Universidade. Na Universidade, vários setores são responsáveis pela administração de um grande volume de dados, sendo muitos destes dados comuns a vários setores. Pode-se imaginar três setores nesta organização: o setor Acadêmico, responsável pela controle das atividades de ensino; o setor Administrativo, que coordena a estrutura geral da Universidade; e o setor de Pessoal, responsável pela administração das pessoas que trabalham na Universidade e onde estão lotadas. A figura 1.1, a seguir, mostra alguns arquivos de dados que estes setores manipulam.
Figura 1.1: Dados manipulados por três setores da Universidade
Imagina-se, ainda, que cada setor apresenta um sistema aplicativo que automatiza a sua administração. Não existe a tecnologia de banco de dados nesta realidade. Assim, tem-se a seguinte situação:
Cada setor da Universidade descreve os seus arquivos: cada setor define registros com campos e formatos que julga adequados. Por exemplo, o arquivo de professores em Acadêmico mantém dados como nome, data do nascimento, titulação e área de interesse. Já o arquivo de mesmo nome em Pessoal necessita de nome, data do nascimento, CPF, salário e data de admissão. Mesmo os campos semelhantes em ambos os arquivos, como nome e data de nascimento, podem apresentar formatos (tipos de dados) diferentes;
Implementam-se organizações simples de arquivos: cada aplicação define arquivos através do seu ambiente de programação e implementa procedimentos para lidar com os seus dados. Por exemplo, para o arquivo de alunos, em Acadêmico, são necessárias rotinas para incluir um novo aluno e consultar registros com base na informação do número de matrícula do mesmo. De forma alternativa, cada aplicação poderia utilizar softwares rudimentares para gerenciamento de arquivos, que permitem a definição de um conjunto de arquivos e disponibilizam um conjunto limitado de funções, como por exemplo, inclusão de um registro, alteração de um campo de registro, consulta pela igualdade de valor de um campo, etc. Estes softwares podem ser considerados os sistemas predecessores dos atuais sistemas de gerência de BD;
O acesso aos dados é controlado pelas aplicações de cada setor: todo o esforço de gerenciamento de dados (definição de arquivos, manipulação de dados, consistência de dados, etc) é implementado em cada aplicação. Obviamente, quanto maior a quantidade de arquivos, maior é este esforço;
Não existe compartilhamento de dados entre as aplicações: o gerenciamento de dados é local, ou seja, é realizado individualmente por cada aplicação. Os dados são dependentes dos programas da aplicação, sendo manipulados apenas por estes programas (isolamento dos dados em relação a organização como um todo).
Através da análise desta realidade, é possível perceber uma série de problemas no que diz respeito à administração de dados da organização:
Redundância: existe replicação de dados (por exemplo, professores, disciplinas e centros) e de procedimentos para tratamento destes dados (por exemplo, consulta pelo nome de um professor e exclusão de uma disciplina);
Difícil manutenção: a atualização de um dado replicado exige que todos os setores que apresentam este dado sejam informados da atualização desejada e a efetivem esta autalização no seu arquivo. Inconsistências podem ocorrer facilmente, caso esta manutenção não seja controlada rigidamente. Por exemplo, suponha que um novo professor passou a trabalhar no departamento de informática. A inclusão dos seus dados foi feita no setor Acadêmico. Em virtude do não compartilhamento de dados, apenas alguns dias depois foi enviado um relatório para o setor Pessoal e a inclusão feita neste setor. Com isto, o novo professor perdeu alguns dias de salário;
Falta de padronização: como cada aplicação define os seus dados de interesse, sem um projeto global dos dados da organização, fica difícil a integração de aplicações, pois não é possível reutilizar definições de arquivos e procedimentos para manipulá-los. Pode-se tomar como exemplo as definições, mostradas anteriormente, dos arquivos de Professores feitas nos setores Acadêmico e Pessoal;
Formas restritas de acesso: no projeto inicial de cada aplicação, definem-se certas operações sobre cada arquivo. Caso, seja necessária, posteriormente, uma nova operação, como por exemplo, uma consulta a disciplinas pelo código do departamento, além do código da própria disciplina, deve-se implementar mais um procedimento e recompilar a aplicação. A manutenção da aplicação é trabalhosa, quando se deseja flexibilizar o acesso a dados;
Não há controle de segurança dos dados: imagina-se que cada aplicação implementa rotinas básicas para garantia de consistência dos dados, como verificação de valores válidos quando ocorre uma inclusão. Porém, controles mais sofisticados, como autorizações de acesso e prevenção contra falhas, não são suportados, devido à complexidade de implementação.
Banco de Dados
Definição
Um BD pode ser definido como sendo:
"Uma coleção de dados operacionais inter-relacionados. Estes dados são armazenados de forma independente dos programas que os utilizam, servindo assim a múltiplas aplicações de uma organização."
Algumas partes desta definição são fundamentais para a compreensão do conceito de BD:
Coleção: agrupamento com repetição;
Operacionais: vitais; estratégicos para a tomada de decisões; permanentes;
Inter-relacionados: um BD mantém um agrupamento de entidades (fatos da realidade em questão) e de relacionamentos entre estas entidades;
Independentes dos programas: dados são mantidos em um meio de armazenamento destinado aos dados da organização e não necessariamente no espaço local do programa de aplicação;
Serve à múltiplas aplicações: dados em um BD podem ser compartilhados por várias aplicações da organização. Cada uma delas define exatamente os dados que deseja manipular.
Um exemplo de BD para a Universidade pode ser visto na figura 1.2. Neste exemplo, todas as entidades (alunos, disciplinas, etc.) que compõem a realidade e os relacionamentos que existem entre elas estão definidas no BD. É possível também identificar a porção do BD que interessa para cada aplicação (setor) presente na Universidade.
O uso da tecnologia de BD traz inúmeras vantagens, se comparada com a situação descrita na seção 1.1:
Dados armazenados em um único local: o BD é o repositório único dos dados da organização. Com isto, reduz-se drasticamente a redundância e eliminam-se redefinições de dados semelhantes, que antes estavam replicadas nas várias aplicações;
Dados compartilhados pelas aplicações: o compartilhamento facilita a integração de novas aplicações à organização, uma vez que não é necessário redefinir o que já existe, nem incluir dados já presentes no BD (melhor reusabilidade de especificações e valores de itens de dados);
Independência dos dados: dados não necessariamente estão na área de armazenamento secundário do equipamento onde executa a aplicação. Além disso, todos os procedimentos para tratamento de dados são agora realizados pelo BD. Modificações nestes procedimentos não afetam a aplicação, ou seja, esta não necessita ser recompilada. Ainda, o código da aplicação fica mais enxuto;
Flexibilidade de acesso: o acesso ao BD é realizado através de linguagens de alto nível para manipulação de dados. A manutenção do código da aplicação é facilitado. Onde antes era necessário programar um procedimento para realizar uma operação sobre os dados, agora basta apenas escrever um pequeno comando nesta linguagem de manipulação;
Aplicações não se preocupam com a gerência dos dados: todo o gerenciamento de dados, no que diz respeito ao acesso, integridade, segurança, concorrência, autorização, etc, é incumbência de um software denominado sistema de gerência de BD (SGBD).
SGBDs, apesar de oferecerem todas estas vantagens para os desenvolvedores de aplicações, necessitam ser devidamente escolhidos, de forma a se adequarem com a plataforma computacional onde a aplicação executará. Muitas vezes, dependendo desta plataforma, os SGBDs podem ser mais ou menos poderosos. Alguns SGBDs de grande porte, consolidados no mercado, por exemplo, muitas vezes não apresentam versões disponíveis para plataformas pequenas, como o Windows 95.
Um SGBD pode ser definido como segue:
"Um sistema cujo objetivo principal é gerenciar o acesso e a correta manutenção dos dados armazenados em um banco de dados."
Acesso quer dizer que o SGBD deve disponibilizar uma interface, via linguagens, que permita a comunicação com a aplicação. Correta manutenção significa que devem ser gerenciados aspectos de integridade, segurança e concorrência, de maneira a evitar dados inconsistentes.
Com base na definição de um SGBD, as seguintes funções básicas são encontradas:
1) Métodos de acesso: duas categorias de linguagens devem ser suportadas:
DDL (Data Definition Language): permite a especificação do esquema da organização, ou seja, entidades com seus atributos e tipos de dados associados; os relacionamentos entre estas entidades e os índices de acesso associados aos atributos. Por esquema, entende-se uma organização lógica dos dados de uma realidade, adequados ao modelo de dados do SGBD;
DML (Data Manipulation Language): permite as operações usuais de manipulação de dados, executados pelas aplicações: inclusão, alteração, exclusão e consulta;
Consultas, de modo especial, devem ser executadas pelo SGBD de maneira eficaz, ou seja, procurando minimizar o número de acessos ao meio de armazenamento secundário assim como o volume de dados gerados nos resultados intermediários do processamento da mesma. Para tanto, a antecipação da aplicação de filtros e a busca apenas de dados relevantes para os relacionamentos, em uma certa etapa do processamento, são exemplos de estratégias que são consideradas.
2) Restrições de integridade (RIs): integridade está associada à idéia de dados corretos, dados consistentes no BD. RIs preocupam-se em manter dados sempre coerentes, verdadeiros com a realidade em questão. Devem garantir:
Estados possíveis de serem assumidos pelos dados: Por exemplo, a idade de um funcionário deve estar entre 16 e 80 anos. Alterações no salário de um funcionário não podem diminuir o valor existente, etc;
Manutenção de relacionamentos válidos entre os dados: Exemplos: uma turma não pode estar vinculada a mais de uma disciplina; Disciplinas não podem exisitir sem estarem vinculadas a um curso, etc.
Para tanto, o SGBD deve disponibilizar uma linguagem para especificação de RIs, chamada DCL (Data Constraint Language). Através dela deve ser possível programar testes (por exemplo, 16 <= idade <= 80) e ações (por exemplo, remover todas as turmas de uma disciplina quando a disciplina é removida).
3) Segurança: este controle evita a violação da consistência dos dados por agentes e/ou situações não previstas (falhas). Dois gerenciamentos devem ser realizados:
Autorização de acesso: permitir que apenas agentes autorizados, sejam usuários ou aplicações, realizem certas operações sobre certos dados. Para tanto, faz-se necessário manter uma matriz de autorização, que especifica, para cada agente e cada dado, a(s) operação(ões) autorizadas. Por dado entende-se alguma porção do BD, como um ou mais registros, um arquivo completo ou vários, alguns campos de um registro, etc. O mecanismo de visões permite especificar a porção do BD que um agente tem direito de acesso;
Recuperação de falhas (recovery): possibiltar o retorno do BD a um estado consistente de seus dados após a ocorrência de uma falha involuntária. Para tanto, o SGBD deve manter, por exemplo, arquivos históricos (chamados logs) que cadastram todas as atualizações realizadas no BD por transações. Por transação entende-se um conjunto de operações de manipulação de dados que é submetido ao BD, sendo que todas estas operações devem ser efetivadas ou, na ocorrência de uma falha, nada deve ser efetivado, para preservar a consistência dos dados. Os logs devem registrar, dentre outras coisas, a identificação das transações, os arquivos manipulados, os registros atualizados, a operação feita e os valores atual e antigo. No caso de falhas de transação ou de sistema (afetam uma ou várias transações, respectivamente), o log deve ser consultado e as ações realizadas por transações inacabadas devem ser desfeitas. Caso todas as modificações da transação estejam registradas, é possível refazê-la. Já para falhas de meio de armazenamento, que tornam inoperantes, por exemplo, as unidades de disco onde se encontra o BD, deve-se restaurar o BD a partir do último backup realizado e consultar o log para refazer ou desfazer as transações cadastradas após este backup.
4) Controle de concorrência: este controle evita conflitos de acesso simultâneo a um dado por mais de uma transação. Se este controle não existisse, os dados consultados por uma transação, por exemplo, poderiam se tornar inválidos caso fossem atualizados por outra transação. Este controle geralmente é feito através do uso de estratégias de bloqueio (lock), que garantem que apenas uma transação manipule um dado, durante o espaço de tempo que necessitar, sem que ocorra interferência de outras transações.
5) Independência dos dados: esta funcionalidade do SGBD é uma decorrência direta das vantagens trazidas pelo uso de um BD. Independência de dados significa transparência de gerenciamento e armazenamento, assim como do esquema global da organização, para as aplicações. O primeiro caso é chamado de independência física, ou seja, a aplicação não se preocupa com detalhes de localização física dos dados ou controles de integridade e segurança, por exemplo, quando deseja realizar um acesso ao BD. A independência lógica garante, através do mecanismo de visões, que uma aplicação tenha condições de especificar a porção do BD que deseja ter acesso, não precisando ter conhecimento do esquema global.
O DD é o catálogo do SGBD, responsável pela manutenção dos metadados (dados sobre os dados), que dizem respeito à:
Estrutura do esquema: entidades (com atributos e tipos de dados associados) e relacionamentos;
Integridade: RIs associadas às entidades e relacionamentos; autorizações de acesso;
Configurações do SGBD para efeitos de controle, segurança e performance, como por exemplo: localização dos dispositivos onde se encontram os dados, backups e logs; número de logs; número de buffers para log e para dados; tamanho dos buffers para log e para dados; número máximo de usuários e locks; tempo máximo de timeout; intervalo de backup automático dos dados; etc;
Estimativas de acesso e estimativas sobre os dados, como por exemplo: tamanho do log e suas informações; espaço ocupado/livre nos dispositivos de armazenamento; tamanho dos arquivos de dados (quantidade de registros); percentual de utilização de buffers; último acesso a um arquivo; média de tempo de processamento de transações; índices utilizados em acessos; etc.
O DD é constantemente consultado pelo SGBD durante a realização de várias das suas tarefas, como processamento de consultas, pré-compilação de comandos DML, verificação de integridade em operações de atualização, etc. O Administrador do BD também tem acesso às suas informações através de ferramentas especiais do SGBD. Estas ferramentas são responsáveis, por exemplo, pela monitoração de performance e configuração do sistema.
Arquitetura Básica de um SGBD
Um SGBD geralmente interage com diversas aplicações de uma organização, assim como com os meios de armazenamento de dados. No primeiro caso, a aplicação se vale de comandos DML embutidos no seu código. No segundo caso, geralmente existe uma interface com o sistema operacional do equipamento, para leitura e gravação de dados.
Assim, um SGBD lida com diversos níveis de visão de um mesmo dado, de maneira a abstrair detalhes da organização dos dados. Por exemplo, para um programa de aplicação não interessa saber que o dado de um empregado x apresenta y bytes e se encontra armazenado em um dispositivo t. Ele apenas deseja conhecer os seus atributos, informando, por exemplo, o seu nome, para efeitos de pesquisa.
Um SGBD lida basicamente com 3 níveis de visão (ou de abstração) de dados:
1) Nível Físico: nível menos abstrato, onde se sabe detalhes físicos da organização de um dado (Esquema físico). É uma estruturação de baixo nível, onde é descrito como os dados estão armazenados, em termos de bytes (tamanho de registros, tamanho e posição de campos, etc). O módulo de gerenciamento de arquivos do SGBD lida com este nível de visão dos dados, uma vez que localiza, lê e grava registros;
2) Nível Conceitual: nível intermediário, que suporta uma descrição de mais alto nível em relação ao nível físico, onde a preocupação está em descrever quais dados são significativos para uma organização (tem semântica, são relevantes para a o dia a dia da organização). Neste caso, lida-se com os dados a nível de entidades e relacionamentos, tal qual estão definidos no esquema. É similar, por analogia, à descrição de um registro em uma linguagem de programação, ou seja, lida-se com nomes de arquivos e campos e não com seqüências de bytes. Os usuários que lidam neste nível, devem ter conhecimento completo de todo o esquema da organização, como o administrador do BD ou usuário especializado, que enviam comandos ad hoc ao SGBD;
3) Nível de Visão: nível mais alto de abstração, sendo particular de cada aplicação que manipula dados do BD. Neste caso, cada aplicação pode determinar o universo de dados que deseja ter acesso. Este universo de dados pode ser uma porção do esquema global da organização. Assim sendo, cada aplicação abstrai detalhes irrelevantes, desnecessários para o seu processamento, como por exemplo, o setor de pessoal, que não tem interesse por dados de disciplinas e turmas e apenas manipula nome, CPF e salário de professores. Como já foi dito, os usuários deste nível são os programas de aplicação.
Para suportar a manipulação de dados nestes 3 níveis, o SGBD deve realizar mapeamentos entre os mesmos, de maneira a deixar transparente, para o usuário de um nível mais alto, a organização do dado nos níveis mais baixos. Para o mapeamento entre o nível conceitual e o nível de visão, o SGBD transfere dados das estruturas de dados (EDs) do nível conceitual (registros com todos os campos de uma entidade) para EDs das visões definidas sobre o esquema, que são adequadas às EDs da aplicação. Já no caso do mapeamento conceitual-físico, o SGBD se vale de funções de manipulação de registros, que são disponibilizadas pelo módulo de gerenciamento de arquivos. Estas funções retornam/gravam dados do/no nível físico para as/presentes nas EDs conceituais.
Agentes de Interação com o SGBD
Um SGBD deve se comunicar com vários agentes (usuários ou programas), com o objetivo de atender as necessidades de dados de diversas aplicações, permitir o desenvolvimento de aplicações que utilizem um BD, assim como possibilitar que aspectos de performance possam ser otimizados, conforme a demanda de acesso a dados pelas aplicações.
Os agentes de interação com um SGBD são os seguintes:
1) Administrador do BD (DBA): o DBA (Data Base Administrator) pode ser encarado como um superusuário do SGBD, uma vez que detém todos os privilégios no que diz respeito à definição e acesso a dados. As suas incumbências são, algumas vezes, separadas em 2 agentes:
Administrador de dados (DA): especializado em projeto de BD. Interage com os usuários da aplicação a ser desenvolvida, com o objetivo de definir os requisitos de dados e especificar o esquema do BD. Deve ser um especialista em desenvolvimento de sistemas;
Administrador do BD (DBA): especialista no SGBD adotado pela organização. Controla diversos aspectos funcionais do SGBD, como definição e modificação do esquema, das autorizações de acesso e das regras de integridade; controle dos procedimentos de segurança (como por exemplo: execução de backups e recuperação de falhas de meio de armazenamento); assim como monitoração de performance de acesso a dados e tomada de decisões para melhorá-la, como criação de índices, controle do tamanho de buffers, número de usuários permitidos, etc;
Esta classificação nem sempre é adotada em uma grande organização, podendo a figura denominada DBA acumular as 2 tarefas;
2) Programas de Aplicação: interagem com o SGBD através de comandos de manipulação de dados (DML) embutidos no seu código. Estes comandos são pré-compilados pelo SGBD, gerando código objeto. Este código executa procedimentos de acesso a dados que levam como parâmetros variáveis ou estruturas de dados da aplicação;
3) Programadores de aplicação: desenvolvem aplicações utilizando ferramentas disponibilizadas pelo SGBD. Estas ferramentas podem ser: compiladores de linguagens de programação tradicionais que permitem o embutimento da DML; linguagens de quarta geração (4GL), que oferecem um ambiente integrado para programação de sistemas e manipulação de dados, e outras ferramentas como geradores de interfaces gráficas com o usuário, geradores de relatórios, etc.
4) Usuários especializados: usuários familiarizados com a DML do SGBD. Estes usuários executam operações de atualização e consulta a dados (desde que tenham permissão para isto) sem serem usuários de uma aplicação. Diz-se que estes agentes solicitam operações ad hoc ao BD, ou seja, operações que são traduzidas em tempo de execução, enquanto o SGBD estiver on-line. É diferente de operações embutidas em programas de aplicação, que são traduzidas uma única vez pelo SGBD em tempo de compilação;
5) Gerenciador de Arquivos: módulo do SGBD responsável pela transparência do acesso físico aos dados armazenados, seja para aplicações, seja para os usuários especializados e o DBA. O SGBD apenas solicita dados a este módulo e o mesmo se encarrega de localizar os registros fisicamente em disco e transferí-los para as estruturas de dados do SGBD. Este módulo realiza a comunicação com o sistema operacional do equipamento onde se encontram os dados, através do mapeamento de registros em memória para as páginas de disco onde se encontram, ou vice-versa.
Para possibilitar a comunicação com estes agentes, um SGBD deve disponibilizar as seguintes interfaces:
Interface DDL/DCL: interface disponível para o DBA. Através dela, o mesmo especifica, através destas linguagens, as entidades e relacionamentos, as RIs e as autorizações de acesso que irão compor o esquema da organização;
Interface DML embutida: interface de comunicação dos programas de aplicação com o SGBD. Através dela, as tarefas de consulta e atualização de dados são realizadas pelas aplicações em execução;
Interface de Utilitários: interface representada por todas as ferramentas oferecidas pelo SGBD, seja para desenvolvimento de aplicações, controle e configuração do SGBD ou solicitações de acesso a dados ad hoc. Assim sendo, os agentes que se valem desta interface são, respectivamente, os programadores de aplicação, o DBA e os usuários especializados;
Interface de Manipulação de Arquivos e Registros: interface do SGBD com o módulo gerenciador de arquivos. Através dela, o SGBD solicita, envia, cria ou remove dados fisicamente. Esta interface é formada pelas várias funções que são disponibilizadas pelo gerenciador de arquivos, como por exemplo:
criação/destruição de arquivos;
criação/destruição de índices;
inclusão/exclusão/alteração de registros de arquivos;
consulta de registros de arquivos.
Funcionamento do SGBD
Detalhando um pouco mais a arquitetura de um SGBD, encontramos os seguintes módulos internos, fundamentais para o seu funcionamento:
1) Módulo Gerenciador do BD: módulo central; núcleo (coração) de um SGBD. Responsável pelo atendimento das requisições de dados e metadados feitas pelos módulos que interagem com os agentes. Atende também as solicitações de operações sobre dados enviadas pelo código objeto das aplicações. Retorna dados e/ou status (códigos) que indicam situações como execução Ok, erros de acesso, violações de integridade ou permissão, etc, a estes módulos. É o único módulo que se comunica com o módulo gerenciador de arquivos. Além disso, os controles de segurança e concorrência também são responsabilidade sua;
2) Módulo Gerenciador de Arquivos: gerencia o acesso aos dispositivos de armazenamento. Recebe e realiza requisições para leitura e gravação de dados, metadados e dados de segurança do módulo gerenciador do BD;
3) Módulo [Pré-] Compilador DML: responsável pela tradução de comandos DML, que podem ter sido embutidos em um programa de aplicação ou enviados de forma ad hoc por usuários especializados. No primeiro caso, ele realiza a pré-compilação e a geração de código objeto para estes comandos, criando um programa pré-compilado, que é remetido para o compilador do ambiente de desenvolvimento utilizado pelo programador de aplicações. No segundo caso, ele traduz e já executa o comando, caso esteja correto. Em ambos os casos, ele solicita metadados ao módulo gerenciador do BD, para poder traduzir os comandos e, caso a solicitação seja uma consulta, ele a remete ao módulo processador de consultas, recebendo-a modificada;
4) Módulo Processador de Consultas: recebe um comando de consulta do módulo [pré-] compilador DML e define a melhor estratégia de acesso para processá-la. Para tanto, ele necessita solicitar metadados ao módulo gerenciador do BD, com o objetivo de analisar, por exemplo, o tamanho dos arquivos envolvidos na consulta, relacionamentos existentes entre os dados, filtros definidos, índices existentes, estimativa de valores distintos de atributos, visando determinar um procedimento que processe a consulta mais rapidamente. Este procedimento, uma vez determinado, é enviado ao módulo [pré-] compilador DML para ser traduzido;
5) Módulo Compilador do Utilitário: traduz o programa fonte da aplicação, escrito em alguma das linguagens de programação suportadas pelo SGBD. Retorna um código de status à ferramenta de desenvolvimento e gera, no caso de uma tradução OK, o código objeto da aplicação;
6) Módulo Compilador DDL: traduz comandos DDL e gera, no caso de uma tradução OK, os esquemas conceitual e físico, ou seja, solicita a criação do BD da aplicação para o módulo gerenciador do BD, que por sua vez, solicita ao módulo gerenciador de arquivos a criação de arquivos de dados (BD) e metadados (DD). Sempre remete um status à interface DDL, indicando o resultado da compilação;
7) Módulo Compilador DCL/Autorização: traduz comandos DCL e de autorização de acesso e gera, no caso de uma tradução OK, procedimentos para verificação de integridade e permissões de acesso.Estes procedimentos são remetidos ao módulo gerenciador do BD, que por sua vez, solicita ao módulo gerenciador de arquivos o armazenamento dos mesmos no DD. Sempre remete um status à interface DCL/Autorização, indicando o resultado da compilação;
8) Módulo de Administração: mantém os procedimentos para monitoramento de performance e configuração do BD, e recuperação de falhas. A primeira classe de procedimentos solicita/modifica dados de configuração e solicita estimativas sobre performance ao módulo gerenciador do BD, que as obtêm no DD e/ou nos dispositivos que mantêm dados de segurança (BD de Recovery). A segunda classe de procedimentos solicita dados ao BD de Recovery, para restaurar os dados do BD, na ocorrência de uma falha.
Modelo de Dados
Um modelo de dados é uma estrutura de referência para organizar dados logicamente. Equivale à visão conceitual de dados em um SGBD. Todo SGBD deve suportar um modelo que permita uma representação dos dados de uma realidade. O esquema conceitual de uma aplicação é o resultado da adequação dos requisitos de dados desta aplicação ao modelo de dados do SGBD.
Todo modelo de dados deve suportar, no mínimo, a especificação de entidades e relacionamentos; o gerenciamento de restrições de integridade que garantam a semântica, ou seja, a coerência dos dados da realidade, quando ocorrem operações de atualização; e métodos de acesso a dados adequados à estrutura de dados do modelo.
Historicamente, os primeiros modelos de BD datam da década de sessenta. Desde então, a pesquisa científica na área procura evoluir no sentido de definir, encontrar modelos que representem da melhor maneira possível os dados de uma realidade, ou seja, que organizem os dados de uma forma mais próxima à maneira como estes são vistos e manipulados pelas pessoas no mundo real. A idéia é definir abstrações que facilitem a compreensão da organização dos dados pelo usuário, tornando cada vez mais transparente a organização física dos mesmos.
Além disso, na implementação de um modelo, busca-se também organizações de dados e estratégias de processamento que otimizem a performance de acesso e métodos de acesso que sejam independentes da aplicação, como por exemplo, linguagens de consulta, retirando da mesma a tarefa de programar procedimentos para realizar operações sobre dados.
A evolução histórica dos modelos de dados é a seguinte:
1o) Modelo Hierárquico: surgiu na década de sessenta. Organizava dados em uma estrutura hierárquica, ou melhor, uma estrutura em árvore. Os SGBDs mais conhecidos foram o IMS e o System2000;
2o) Modelo de Redes: utilizado principalmente no final da década de sessenta e durante a década de setenta. Organizava dados em uma estrutura formada por várias listas, que definia uma intrincada rede de ligações (estrutura similar a um grafo direcionado). O IDMS e o Total foram os SGBDs mais conhecidos;
3o) Modelo Relacional: definido na década de setenta, é o modelo de dados dominante no mercado atualmente. Organiza dados em em um conjunto de relações (tabelas). Os SGBDs de grande porte mais famosos são: Oracle, Informix, Sybase e Ingres;
4o) Abordagens Pós-Relacionais: novos modelos que começaram a ser definidos a partir da década de oitenta, visando atender as necessidades de aplicações ditas não convencionais, ou seja, aplicações cujas entidades apresentam uma estrutura que não se adequa bem com a organização relacional de dados. Exemplos deste modelos são: orientado a objetos (suporta a representação de objetos complexos); temporais (suporta a representação de versões de dados no tempo), dedutivos (suporta regras para a dedução de dados a partir de outros dados), etc. Alguns destes SGBDs já se encontram disponíveis comercialmente, especialmente os orientados a objetos.
Comentário sobre os Modelos Hierárquico, Rede e Relacional
Modelo Hierárquico
O modelo hierárquico foi definido com base na observação de que muitas entidades do mundo real são organizadas hierarquicamente. Por exemplo, em uma organização como a Universidade, encontamos uma reitoria que coordena vários centros, que são formados por departamentos, que apresentam vários cursos onde professores, alunos e disciplinas estão vinculados.
Neste modelo, os dados organizados em um conjunto de tipos de registros (entidades), interconectados através de ligações (relacionamentos). Uma ligação representa um relação entre exatamente 2 tipos de registros: pai e filho. Assim, tanto o esquema quanto os dados (ocorrências) são visualizados através de uma estrutura em árvore, onde um ou vários tipos de registro filhos podem estar vinculados a um tipo de registro pai. Um esquema no modelo hierárquico é chamado de um diagrama de estrutura em árvore. O sentido de acesso é sempre unidirecional, ou seja, sempre no sentido do pai para o filho (parte sempre da raiz e percorre os níveis inferiores).
Este modelo apresenta os seguintes problemas:
Não suporta relacionamentos com cardinalidade M:N: decorrência da organização em árvore, que permite apenas cardinalidades 1:1 e 1:N, ou seja, um tipo de registro filho sempre está relacionado a um único tipo de registro pai. Um pai, por sua vez, pode se relacionar com vários filhos. Casos M:N devem ser modelados como uma relação 1:N, através da escolha de um dos dois tipos de registro (aquele que apresentar um maior valor médio de cardinalidade) para ser o tipo de registro pai. A redundência de dados é inevitável, caso uma ocorrência de um tipo de registro filho relacionar-se com mais de uma ocorrência de um tipo de registro pai;
Não há acesso direto a ocorrências de tipos de registro filhos: a performance não é boa quando se deseja o acesso a dados de tipos de registro filhos, uma vez que é necessário percorrer os tipos de registro pai hierarquicamente superiores ao mesmo;
Assimetria de acesso: consultas aparentemente simétricas em termos de tempo de processamento, não apresentam uma performance equivalente. Suponha uma hierarquia onde o tipo de registro pai seja médicos e o tipo de registro filho seja pacientes, e duas consultas simétricas como:
1) buscar os pacientes com consulta marcada para o médico João
2) buscar os médicos que a paciente Maria tem consulta marcada
A segunda consulta apresenta quase sempre uma performance pior, uma vez que devem ser percorridos todos os registros de médicos, para descobrir se a paciente Maria está relacionada (como “filha”) a este médico. No caso da primeira consulta, uma vez localizado o médico João, todos os seus pacientes estão vinculados diretamente a ele como “filhos”.
Inexistência de uma linguagem independente para manipulação de dados: o modelo hierárquico oferece um conjunto de comandos para realizar percorrimento em árvore. Os procedimentos para execução de consultas a dados devem ser programadas pela aplicação, através do embutimento destes comandos no seu código.
Modelo de Rede
Este modelo é muitas vezes denominado de modelo DBTG CODASYL (Data Base Task Group - subgrupo da Conference On DAta SYstems and Languages), uma organização (conferência) existente na década de setenta responsável pela padronização de linguagens de programação de sistemas. O subgrupo DBTG foi o responsável pelo padrão da organização e manipulação de dados neste modelo.
Similar ao modelo hierárquico, os dados no modelo de redes são organizados em tipos de registro e ligações entre 2 tipos de registro. Não existe restrição hierárquica, ou seja, quaisquer dois tipos de registro podem se relacionar. Assim, tanto o esquema quanto as ocorrências de dados são visualizados como um grafo direcionado. Um esquema no modelo de redes é chamado de diagrama de estrutura de dados.
Toda vez que existe um relacionamento com cardinalidade 1:1 ou 1:N, define-se um set, ou seja, o tipo de registro com cardinalidade fixa igual à 1 é chamado de owner e o outro é chamado member. Uma ocorrência de um set equivale a uma lista encadeada que parte do owner e encadeia todos os members relacionados a ele. Assim, se existe um setor do hospital, por exemplo, onde trabalham exclusivamente vários médicos, para cada registro de setor existe uma ligação para um registro de médicos que, por sua vez, encadeia outros registros de médicos, sendo que o último médico tem uma ligação para o setor em questão.
Quando existe um relacionamento com cardinalidade M:N, define-se o que se chama de conector: um tipo de registro adicional que estabelece uma ligação entre os 2 tipos de registro envolvidos no relacionamento. O conector é member destes 2 tipos de registo, ou seja, 2 sets são definidos, transformando um relacionamento M:N em 2 relacionamentos 1:N. Este conector pode ou não ter atributos. Por exemplo, em um relacionamento entre médicos e pacientes, o conector pode funcionar como um registro de consultas marcadas, com dados relativos à data e à hora da consulta.
As vantagens deste modelo em relação ao modelo hierárquico são:
Suporte a todas as cardinalidades de relacionamento: é possível representar diretamente no esquema qualquer cardinalide de relacionamento. Não é mais necessário transformar forçadamente uma cardinalidade M:N em 1:N;
Eliminação da redundância: decorrência do fato de não existir mais uma imposição de hierarquia, ou seja, relacionamentos M:N são permitidos;
Simetria de acesso: consultas equivalentes em termos de processamento realmente apresentam a mesma performance. Para buscar, por exemplo, os pacientes com consulta marcada para um médico ou os médicos que uma paciente tem consulta marcada, percorre-se, a partir do registro indicado em questão (médico ou paciente), a lista encadeada de conectores, sendo que cada conector, por sua vez, leva ao tipo de registro relacionado.
Por outro lado, as desvantagens deste modelo são:
Número excessivo de ligações: cada relacionamento presente na realidade gera listas encadeadas. Consultas que envolvem o percorrimento de muitos relacionamentos têm sua performance comprometida;
Definição de conectores: conectores, quando não mantêm dados sobre um relacionamento, são tipos de registro artificiais, utilizados apenas para o suporte de cardinalidades M:N. Sempre criam um nível de indireção na pesquisa, tornando maior o tempo de processamento;
Inexistência de uma linguagem independente para manipulação de dados: idêntico ao modelo hierárquico.
Modelo Relacional
O modelo relacional foi formalmente definido por E. Codd, no Laboratório da IBM em San Jose - Califórnia, em 1970. O projeto inicial foi denominado de Sistema R e definia a organização dos dados e linguagens formais para a sua manipulação. Com base nestas linguagens formais, a primeira versão da linguagem SQL (Structured Query Language) foi definida. Esta linguagem é, atualmente, um padrão para gerenciamento de dados em SGBDs relacionais.
Entidades e relacionamentos são representados neste modelo por relações, que equivalem ao conceito matemático de conjunto, ou seja, um agrupamento de elementos sem repetição. Uma relação é vista como uma tabela, onde as colunas indicam os campos e as linhas, as ocorrências (valores). Relacionamentos entre relações são estabelecidos por igualdade de valor de campos. Por exemplo, para indicar que um médico trabalha em um setor, uma coluna da relação médicos guarda o número do seu setor, que permite a sua identificação na relação setores. Relacionamentos M:N são modelados como relações que mantêm os campos que identificam as 2 relações envolvidas, mais os dados pertinentes ao relacionamento, caso existam.
Se comparado com os modelos anteriores, o modelo relacional apresenta as seguintes vantagens:
Representação uniforme: tanto entidades quanto relacionamentos são representados através de relações. É um conceito único e simples para organização de dados;
Representação mais abstrata: um esquema no modelo relacional é dito um esquema de mais alto nível, pois abstrai uma estrutura de implementação, como estruturas em árvore ou grafo, onde o usuário deve se preocupar em percorrer apontadores adequadamente;
Linguagens independentes: o modelo relacional é o primeiro modelo de dados que oferece linguagens de manipulação de dados cujos comandos podem ser executados independente de aplicação (não estão obrigatoriamente vinculados ao código da aplicação). São, ainda, linguagens de alto nível, ou seja, um pequeno comando de manipulação equivale (implementa) a um procedimento de acesso a dados, se comparado com os modelos anteriores. Linguagens com esta característica são ditas declarativas, ou seja, o usuário preocupa-se em dizer o quê ele deseja obter do BD e não como ele deseja obter estes dados.
Modelo Relacional
Fundamentação Teórica
O estudo do modelo de dados relacional apresenta 3 aspectos:
Aspectos estruturais: formalizam matematicamente a maneira como os dados estão organizados no modelo. Esta formalização é baseada na teoria dos conjuntos;
Aspectos de integridade: descrevem os procedimentos para garantia de integridade de dados quando da ocorrência de operações de atualização de dados;
Aspectos de manipulação: descrevem as linguagens formais e comerciais definidas para o modelo.
A estrutura do modelo relacional baseia-se em 5 conceitos: domínio, atributo, tupla, relação e chave.
O domínio define o universo de valores permitidos para um certo item de dado, como por exemplo:
Domínio(salário) = R+;
Domínio(idade) = [0,150];
Domínio(sexo) = (masculino, feminino);
Um domínio compreende um tipo de dado predefinido mais um conjunto de restrições de integridade que limitam os valores permitidos para este tipo de dado. Por exemplo, o item de dado idade apresenta um domínio inteiro mais uma RI que delimita o intervalo de valores permitidos para [0,150]. Assim, os valores deste dado ficam coerentes com a realidade em questão. Para tanto, é necessário o uso da DDL e da DCL do SGBD. Ainda, a definição de um domínio acarreta em certas operações e comparações de valor válidas para um item de dado.
Domínios podem ser simples, ou seja, possuem um único valor, como um inteiro, ou compostos, quando possuem vários valores, como uma data, que apresenta dia, mês e ano. Os valores dos itens de dados que apresentam domínios compostos são abstraídos e tratados como um único valor. Uma data poderia ser manipulada como um string, por exemplo.
A noção de domínio de um item de dado assemelha-se à nocão de domínio de um conjunto na matemática.
Um atributo é um nome dado a um domínio, utilizado para representar um item de dado. Matematicamente, um atributo é o nome de um conjunto. Em uma tabela, representa uma coluna. Um atributo pode apresentar um valor condizente com o domínio associado a ele ou null. Null indica ausência de valor ou valor desconhecido.
Um atributo pode conter apenas um valor atômico, ou seja, um valor indivisível. Um contra-exemplo seria definir um atributo estruturado Endereço, que apresentasse 4 valores: rua, número, cidade e CEP. Este tipo de atributo não é suportado pelo modelo relacional.
Uma tupla é um conjunto de pares (atributo-valor), que define uma linha da tabela, ou seja, uma ocorrência de uma entidade ou relacionamento. Se imaginarmos em uma tabela como sendo um conjunto, uma tupla seria um elemento deste conjunto.
Uma relação pode ser definida como um subconjunto do produto cartesiano dos domínios D1, D2, ..., Dn, que correspondem aos atributos A1, A2, ..., An de uma tabela. O produto cartesiano gera D1 X D2 X ... X Dn tuplas (elementos) e a relação mantém apenas aquelas tuplas (elementos) que contêm valores de atributos relacionados que estão presentes na realidade. Por isto, uma relação é um subconjunto.
Uma relação é vista como uma tabela no modelo relacional, composta por um cabeçalho e um corpo. O cabeçalho é formado por um conjunto fixo de atributos que possuem nomes distintos, para evitar ambiguidade na localização de um item de dado. O grau de uma relação significa o número de atributos da mesma. O corpo de uma relação é formado por um número variável de tuplas, onde a ordem das mesmas não é significativa, ou seja, dada uma relação R1 com 3 tuplas, nesta ordem: t1, t2 e t3; e uma relação R2, com 3 tuplas, nesta ordem: t2, t3 e t1; a igualdade R1 = R2 é verdadeira. A cardinalidade de uma relação significa o número de tuplas da mesma.
O conceito de relação é ligeiramente diferente do conceito de tabela. Relação equivale à noção de conjunto, ou seja, um agrupamento de elementos sem repetição. Tabela equivale a noção de coleção, ou seja, um agrupamento de elementos onde é permitida a repetição. SGBDs lidam, na prática, com o conceito de tabela.
O conceito de chave é fundamental no modelo para garantir identificação de tuplas e estabelecer relacionamentos entre relações. O modelo relacional define 2 tipos de chave:
Chave primária (pk): atributo ou grupo de atributos que permite a identificação única de uma tupla em uma relação, ou seja, o valor da pk de uma tupla nunca se repetirá nas demais tuplas da mesma relação. Uma pk é escolhida dentre várias chaves candidatas, que podem estar presentes na relação. As chaves candidatas não selecionadas são ditas chaves alternativas. A cada chave alternativa deve ser associada uma RI que garanta que seus valores sejam únicos (unique);
Chave estrangeira (ek): atributo ou grupo de atributos de uma relação R1 que estabelece um relacionamento de equivalência, por valor, com uma pk de uma relação R2. O domínio da ek de R1 deve ser compatível com o domínio da pk de R2. Nada impede que R1 e R2 sejam a mesma relação.
Restrições de Integridade Básicas
Os aspectos de integridade do modelo relacional estão associados aos conceitos de chave primária e chave estrangeira. Garantir a integridade de um esquema relacional significa garantir o acesso individualizado a todas as tuplas de uma relação, assim como garantir relacionamentos válidos e condizentes com a realidade. O modelo relacional é regido por 2 regras de integridade básicas: a regra de integridade de entidade e a regra de integridade referencial.
A regra de integridade de entidade diz respeito à chave primária de uma relação. Ela diz que nenhum atributo que faz parte da chave primária pode ter null em alguma tupla. A manutenção desta regra garante que toda tupla possa ser identificada unicamente.
A regra de integridade referencial diz respeito às chaves estrangeiras de uma relação. Ela diz que o valor de um atributo que faz parte de uma chave estrangeira pode assumir null desde que o mesmo não faça parte da chave primária. Ainda, este mesmo atributo pode assumir um valor qualquer, condizente com o seu domínio, desde que este mesmo valor exista na chave primária de uma tupla da relação referida por ele. Com isto, nunca existirão relacionamentos incorretos entre dados.
Para que estas regras sejam sempre respeitadas, o SGBD deve implementar rotinas de verificação automáticas. Isto implica em testes e ações a serem realizados pelo SGBD toda vez que uma operação de atualização for submetida ao mesmo. No caso da regra de integridade de entidade, o seguinte algoritmo deve ser executado toda vez que for incluída uma nova tupla em uma relação ou for alterado o valor de um atributo de uma tupla que faz parte da chave primária de uma relação:
SE a chave primária da tupla for null OU existir outra tupla com o mesmo valor de chave primária
ENTÃO Impedir a efetivação da operação
SENÃO Efetivar a operação;
Já para o caso da regra de integridade referencial, 3 alternativas de ações são geralmente tomadas pelo SGBD quando se percebe que uma violação da mesma irá ocorrer:
Impedimento: a operação não é efetivada;
Cascata: para o caso de exclusões de tuplas ou alterações de chave primária na relação referida, realizar a mesma operação em todas as tuplas que se referem à ela;
Anulação: para o caso de exclusões de tuplas ou alterações de chave primária na relação referida, altera-se para null o(s) atributo(s) que compõe(m) a chave estrangeira que estabelece o relacionamento com esta relação (caso 1). Uma variante desta alternativa é anular apenas a chave estrangeira de uma única tupla (caso 2).
A aplicação destas ações depende da operação de atualização submetida e da relação que sofre a operação (a referida ou a que possui uma referência).
Se uma operação de atualização é submetida à relação que possui a referência (possui a chave estrangeira), o seguinte algoritmo deve ser executado toda vez que for incluída uma nova tupla ou for alterado o valor de um atributo que faz parte da chave estrangeira:
SE a chave estrangeira da tupla for null
ENTÃO
SE a chave estrangeira fizer parte da chave primária
ENTÃO Impedir a efetivação da operação
SENÃO Efetivar a operação
SENÃO SE não existir uma tupla na relação referida com valor de chave primária igual ao valor da chave estrangeira desta tupla
ENTÃO SE a chave estrangeira fizer parte da chave primária
ENTÃO Aplicar impedimento
SENÃO Aplicar impedimento OU Aplicar anulação (caso 2)
SENÃO Efetivar a operação;
Se uma operação de atualização é submetida à relação referida (possui a chave primária), o seguinte algoritmo deve ser executado toda vez que for excluída uma tupla ou for alterado o valor de um atributo que faz parte da chave primária:
SE a chave estrangeira fizer parte da chave primária
ENTÃO Aplicar impedimento OU Aplicar cascata
SENÃO Aplicar impedimento OU Aplicar cascata OU Aplicar anulação (caso 1)
Restrições de Integridade em BDs
Subsistema de Integridade Semântica do SGBD
Integridade é um conceito de fundamental em BD, uma vez que diz respeito à correção, consistência, segurança, etc, de dados armazenados. Vários subsistemas de um SGBD têm a incumbência de garantir esta integridade: subsistema de restauração (recovery), subsistema de controle de concorrência (scheduler), subsistema de autorização de acesso e subsistema de integridade semântica. O último deles é o que será tratado neste tópico.
A garantia da integridade semântica é a garantia de que o estado dos dados do BD está sempre coerente com a realidade para o qual o mesmo foi projetado e criado. Não basta ter um esquema com os dados eficientemente bem estruturados, se não existir nenhum controle sobre os valores dos mesmos (falta de confiabilidade). Se não existe gerenciamento de integridade semântica, pode-se ter violações de domínio (valores não condizentes com a semântica de certo atributo - por exemplo, um empregado com idade de 10 ou 100 anos), dados desconhecidos (ausência de valor em atributos significativos, como nome do empregado) e relacionamentos incorretos ou inexistentes (por exemplo, a ocorrência de situações proibidas, como departamentos sem gerente ou alguém sendo gerente de mais de um departamento).
Garantir integridade semântica é garantir estados corretos de um dado (verificado sempre após alguma atualização no BD) e transições de estado também válidas (às vezes, uma atualização no BD acarreta outras ações de atualização sobre outros dados - transparentes para a aplicação - de forma a manter a integridade do esquema).
Um subsistema de integridade semântica de um SGBD controla restrições especificadas sobre um esquema. Estas restrições (ou regras) são chamadas restrições de integridade (RIs). O gerenciamento destas restrições envolve três funções básicas:
Especificação de RIs: deve ser possível especificar testes e ações para garantia de integridade. Para tanto, o SGBD deve suportar uma linguagem de especificação de restrições (DCL), cujos comandos são compilados e mantidos no catálogo do sistema (DD) para posterior consulta e modificação;
Monitoramento de RIs: sempre que ocorrer uma operação de atualização sobre um dado, todas as RIs que dizem respeito ao mesmo devem ser consultadas no DD, para verificar se alguma delas não foi violada ou se algo mais (por exemplo, outra atualização ou a execução de um procedimento qualquer) deve ser realizado;
Ações para garantia de RIs: quando alguma operação de atualização gera alguma inconsistência, devem ser tomadas ações como o impedimento da atualização (rollback da atualização) ou a execução de outros procedimentos para atualizar dados relacionados.
Assim sendo, em toda RI deve ser possível especificar:
para quais dados deve-se verificar a regra (alcançe da regra);
quando a regra deve ser verificada (antes, imediatamente após ou um tempo após a operação de atualização);
que ação deve ser tomada para garantí-la.
A existência de um subsistema de integridade semântica é extremamente vantajosa para as aplicações que utilizam um SGBD, pois existe total independência deste controle, ou seja, o gerenciamento de integridade fica a cargo do SGBD. As aplicações ficam liberadas desta pesada tarefa, sendo que estas apenas submetem operações ao SGBD e recebem indicação de OK ou sinalizações de violações e atitudes tomadas para garantí-las.
Classificação de RIs Semânticas
É possível classificar o universo possível de RIs semânticas em quatro categorias. Esta classificação é interessante, uma vez que todo SGBD deveria suportar a especificação e o controle de todas estas categorias. Considerando BDs relacionais, a classificação é a seguinte:
1) Quanto ao alcançe: classifica RIs de acordo com a quantidade (ou volume) de dados que deve ser consultado para que a regra seja verificada. A medida que os itens desta categoria são mostrados, mais cara fica esta verificação. Os itens são:
1.1) RIs que atingem um atributo de uma relação: são as mais simples, controlando, por exemplo, intervalos de valores possíveis, valores constantes possíveis, preenchimento obrigatório, unicidade de valor, etc;
1.2) RIs que atingem mais de um atributo de uma relação: em geral testes comparativos entre valores de 2 ou mais colunas de uma tabela;
1.3) RIs que atingem mais de uma tupla de uma relação: o caso típico é a garantia de integridade da chave primária (CP), que exige que o valor da CP de uma nova tupla seja diferente de todos os valores das tuplas já existentes;
1.4) RIs que atingem tuplas de relações diferentes: o caso típico é a garantia da integridade da chave estrangeira (CE), que exige que o valor da CE esteja presente como CP na tabela a qual a mesma se refere.
2) Quanto ao momento em que deve ser verificada a regra: duas possibilidades podem ser determinadas: verificação imediata ou postergada. A imediata (default) dispara a verificação de todas as RIs associadas a um dado imediatamente após a sua atualização. A postergada realiza a verificação apenas ao final da transação ou em algum momento antes do final da transação, quando especificado pelo usuário. A verificação postergada em algumas situações é obrigatória (a); em outras é recomendada para otimizar a performance (b). Um exemplo da situação (a) seria uma modificação em códigos de todos os atributos que são CP de uma tabela. Por exemplo, a numeração de todos os códigos foi incrementada em 1 unidade. Uma verificação imediata, após a atualização de cada CP, não é recomendada, pois acarretaria em violação. Já para o caso (b), um exemplo seria uma RIs que diz que a soma dos salários pagos a empregados nunca deve ultrapassar o valor do orçamento do departamento onde os mesmos trabalham. Supondo uma transação que altera os salários de diversos empregados, é recomendado que esta RIs seja verificada apenas uma vez, após a realização de todas as alterações, para não sobrecarregar a carga de trabalho do SGBD, visto que, após cada alteração, este processamento de verificação precisaria ser executado. Para o controle de verificações postergadas, é fundamental que o SGBD mantenha um histórico de atualizações já feitas (Log) para poder desfazê-los (rollback) em caso de violação;
3) Quanto ao estados anteriores e posteriores de um dado: esta categoria de RI restringe transições válidas de estado de um dado. Esta transição pode considerar apenas estados anteriores, como o fato de que uma atualização de salário não pode torná-lo inferior ao seu valor antigo; ou anteriores e posteriores, como no caso de atualizações de estado civil . Neste segundo exemplo, o SGBD deveria manter um grafo de transições válidas de estado para este atributo;
4) Quanto à ocorrência de eventos externos: são RIs que realizam automaticamente ações de atualização, sem esta ação ter sido ocasionada por um evento interno (previsível), que é o caso de operações de atualização. Um exemplo é atualização automática de uma parcela de uma prestação de uma conta, quando chega o dia do vencimento. Este tipo de RI exige que o SGBD constantemente monitore se um evento externo (por exemplo, um determinado valor de data/hora do sistema) ocorreu.
Especificação de RIs em SQL
O SQL padrão 92 oferece três maneiras de especificar RIs sobre um esquema relacional:
1) RIs associadas à definição de relações: diz respeito a todas as consistências que podem ser feitas sobre um ou mais atributos de uma relação ou sobre atributos de relações relacionadas a ela. São RIs especificadas no momento da criação de uma relação (a nível de DDL), estando vinculadas somente a ela e verificadas apenas quando seus atributos são modificados. Nesta situação encontram-se as RIs de CP (primary key) e CE (foreign key), not null, unique e todas as RIs enquadradas na categoria 1 da classificação anterior. Merece destaque a cláusula check, que permite a especificação de diversos tipos de testes comparativos entre atributos, inclusive com a possibilidade de inclusão de comandos de consulta SQL;
2) Afirmações (Asserts): são testes que devem sempre ter um resultado verdadeiro, caso contrário, a atualização deve ser desfeita. É empregado geralmente para testes que envolvem operações lógicas ou de cálculo sobre atributos de mais de uma relação, não podendo ser vinculadas a uma relação em particular. O SQL permite a sua especificação (Create Assertion) e remoção (Drop Assertion) do catálogo;
3) Gatilhos (Triggers): importante mecanismo de garantia de integridade semântica, um gatilho é uma ação que é disparada em função de um evento interno ocorrido no BD (uma operação DML, geralmente), visando manter a integridade do esquema. Todo gatilho tem dois componentes: a condição e a ação. A condição é uma operação de manipulação SQL (inclusão, exclusão, consulta, etc) sobre uma certa relação. Pode-se especificar o disparo do gatilho para antes ou depois da execução da operação. A ação realizada pelo gatilho normalmente é um outro comando SQL, podendo até, dependendo da sofisticação do SGBD, conter chamadas a stored procedures, que realizam outros procedimentos de manipulação de dados, programados em alguma LH ou de quarta geração disponível pelo sistema. Stored Procedures são mantidos no SGBD e não na aplicação.
Considerações
Considerando estritamente o SQL padrão, nem todas as categorias de RIs são suportadas. A categoria 1 é atendida pelas RIs associadas a uma relação e afirmações. A categoria 2 é também atendida, sendo o modo imediato o default, e o modo postergado passível de definição através da cláusula Set Constraint nome_RI: deferred, dentro de uma transação. A categoria 3 é atendida, a princípio, pelos gatilhos, que permitem a referência ao valor antigo ou novo de um dado (antes e depois da atualização, respectivamente). Porém, se a verificação de estados anteriores e posteriores for mais sofisticada (por exemplo, pesquisa em grafos de transição de estados), e possível que um procedimento de validação tenha que ser implementado. Isto foge a sintaxe do SQL padrão, que permite apenas comandos SQL no corpo de um gatilho.O controle de RIs classificadas na categoria 4 deve necessariamente ser implementado através de procedimentos, ou seja, o SQL padrão não oferece suporte.
RIs são um componente fundamental de qualquer esquema de BD, devendo ser cuidadosamente planejadas em tempo de projeto do BD, para evitar situações como:
especificações redundantes: mais de uma RI realizando a mesma validação sobre o mesmo dado. Exemplo: supondo 2 dados: A e B, tem-se como RIs: (a) A > 0; (b) A <= B e (c) B > 0. A RI (c) pode ser dispensada;
especificações conflitantes: mais de uma RI exigindo estados válidos para o mesmo dado que são conflitantes. Exemplo: (a) A > 0; (b) A <= B; (c) B < 0. As RIs (b) e (c) estão em conflito;
especificações inconsistentes: uma RI altera o estado de um dado, sendo este estado não permitido por outra RI. Exemplo: Um gatilho diminui o salário de um empregado, tornando-o negativo, e existe um check que garante apenas valores positivos para salários.
Visões em BDs
Uma visão pode ser encarada como uma janela para um conjunto de dados mantidos em um BD. Considerando um BD relacional, por exemplo, uma visão seria uma relação virtual derivada a partir de dados de uma ou mais relações do esquema. Esta derivação é transparente para a aplicação que a manipula, ou seja, para a aplicação é como se os dados da visão fossem tabelas mantidas fisicamente no BD.
Uma visão é definida a partir de um comando de consulta SQL (chamado Create View) que pode associar e filtrar dados de várias relações. O nome dos atributos originais das relações pode ser redefinido na visão. Uma vez compilada, sua especificação é mantida no catálogo (DD) do SGBD para posterior verificação, toda vez que um acesso a ela for solicitado pela aplicação. Essa verificação é necessária principalmente para que possa ser realizado o mapeamento para as tabelas físicas de uma requisição feita para a visão. Por exemplo, uma consulta a alguns atributos de uma visão pode executar uma busca a atributos de diversas relações, sendo necessário ainda considerar os critérios de seleção definidos na própria especificação da visão.
Visões são dinâmicas por definição, ou seja, sempre refletem o estado atual dos dados das relações das quais derivam. Caso novos dados sejam inseridos, ou alguns deles modificados diretamente nas tabelas, os mesmos serão naturalmente “vistos” por futuras consultas solicitadas às visões que têm acesso a estes dados.
Visões podem ser definidas recursivamente, ou seja, é possível se ter visões de visões, onde novas filtragens e/ou reduções no número de atributos são especificadas. Porém, certos controles devem ser feitos pelo SGBD para garantir que uma visão não se torne inválida. Por exemplo, não pode ser permitida a existência de uma visão sem a existência de uma das relações da qual deriva. O mesmo vale para visões de visões. Ainda, a remoção de uma visão do BD implica apenas na retirada da sua especificação do DD. Isto é possível através de um comando SQL chamado Drop View.
O principal cuidado quando se define uma visão é considerá-la passível de atualização ou não. Por default, toda visão é passível de consulta. Por outro lado, nem toda visão é atualizável. Se nenhum tipo de controle for feito explicitamente pelo projetista do BD ou implicitamente pelo SGBD, dados inconsistentes podem surgir no BD, em decorrência de uma atualização proveniente de uma visão. É necessário que toda visão atualizável atenda as seguintes premissas (supondo um BD relacional):
1) “Toda visão atualizável deve preservar a chave primária (CP) da relação da qual deriva.”
2) “Toda visão atualizável deve conter atributos cujos valores tenham uma correspondência direta com valores de atributos presentes na relação da qual deriva.”
3) “Toda visão atualizável deve ser derivada, preferencialmente, de apenas uma relação.”
A premissa 1 garante que toda tupla modificada por uma visão tenha condições de ser identificada e modificada na relação física, sem problema de ambiguidade, ou seja, deve existir um mapeamento 1 para 1 de uma tupla da visão para uma tupla da relação. Quando isto não é garantido, tem-se vários problemas, como por exemplo, inclusões de tuplas com CP total ou parcialmente nula nas relações ou remoções de tuplas na visão sem saber exatamente quantas tuplas serão efetivamente removidas na relação.
A premissa 2 considera visões estatísticas, ou seja, visões que retornam certos cálculos associados a alguns atributos de uma relação. São visões tipicamente para consulta a informações derivadas do BD, não havendo sentido a realização de atualizações a partir delas. Isto porquê, ocorrendo atributos da visão que são cálculos a partir de atributos da relação, não há uma correspondência direta entre colunas da visão e da relação. Isto pode dificultar e até mesmo inviabilizar a atualização física do BD, ainda mais quando não se consegue determinar precisamente esta correspondência (por exemplo, um cálculo com várias variáveis, cada uma sendo um atributo de uma relação).
A premissa 3 considera problemas de efeitos indesejáveis de atualizações feitas a partir de visões, pelo fato da mesma agregar atributos de diversas relações. Por exemplo, a inclusão de uma nova tupla na visão se reflete na inclusão de tuplas em todas as relações envolvidas, podendo gerar violação de CP, se nem todos os atributos que compõem as chaves das relações envolvidas estiverem presentes. A atualização de uma tupla da visão acarreta atualizações em atributos de relações que podem violar restrições de CP e chave estrangeira (CE). Da mesma forma, por não haver uma correspondência 1 para 1 entre tuplas da visão e da relação, uma exclusão feita na visão pode ter o efeito indesejável de excluir mais dados do que o realmente esperado.
A nível de controle de atualização a partir de visões, a linguagem SQL permite a inclusão da cláusula With Check Option ao comando Create View
