Bases de Dados Permitem que os dados da organização estejam disponíveis, de forma partilhada, a todas as aplicações ou utilizadores Formas mais elaboradas de conhecimento, por exemplo conceitos, deveriam poder ser mantidos sob gestão do SGBD, caso contrário… Cada entidade pode interpretar o mesmo conceito de forma diferente Pode originar incoerências de comportamento Para contornar esse problema, uma abordagem poderá ser a recolha e armazenamento desse conhecimento no SGBD Estaremos a guardar e a partilhar por vários utilizadores Conhecimento factual (dados) Conhecimento procedimental (tradução dos conceitos para formas possíveis de serem armazenadas nos SGBDs, normalmente sob a forma de código de programação) Conhecimento descrito de forma procedimental Uma das formas de conhecimento procedimental são as regras de integridade implícitas, que podem ser impostas: No nível aplicacional, com grandes desvantagens… Não há partilha do código por várias aplicações Cada aplicação deve implementar as mesmas regras, caso contrário poderá ser gerada inconsistência Não se pode garantir que os dados serão actualizados de forma coerente em todas as ocasiões Na base de dados Se o SGBA permite a definição de triggers, stored procedures, assertions, etc., é possível traduzir esse conhecimento Será uma tradução do conhecimento sob forma de código de programação Poderá não ser possível traduzir todas as formas de conhecimento Conhecimento descrito de forma procedimental Usando uma abordagem procedimental, o conhecimento é definido como sendo um conjunto de instruções sobre como fazer as coisas Uma abordagem científica deve procurar produzir conhecimento que é incrementalmente compreensivo, sistemático e preciso, no entanto, quanto mais precisa tornamos a representação procedimental, mais perspectiva ela se torna Como existem várias formas de representação procedimental (várias formas de resolução) não temos uma boa base para a definição do conhecimento O conhecimento, quando expresso de uma forma procedimental, não providencia uma linha de orientação precisa, nem pode ser formalizado para o providenciar sem minar o próprio espírito da abordagem procedimental Conhecimento descrito de forma declarativa Porquê a importância da representação declarativa do conhecimento? Uma abordagem declarativa não especifica como algo se faz, mas sim o que pode ser feito Por exemplo, a gramática descreve a estrutura abstracta subjacente ao que pode ser produzido com uma linguagem, não descreve exaustivamente todas as possibilidades… O uso criativo deste conhecimento está ao dispor do utilizador (pessoa) já que este terá inteligência para interpretar o conceito e produzir algo (fala, escrita, etc.) Proporciona não só uma descrição formal e sistemática, mas também permite a obtenção de novo conhecimento A declaração de conhecimento é sistemática e integrada Conhecimento descrito de forma declarativa Níveis mais elevados na precisão deste conhecimento permitem incrementar a criatividade dos utilizadores, ao contrário da abordagem procedimental Na abordagem procedimental, quanto mais precisa for a representação do conhecimento, menor liberdade e menor criatividade os utilizadores terão, já que ao incrementar a precisão estamos a acrescentar novas restrições A abordagem declarativa pode permitir diferentes alternativas ou opções para uma determinada acção Não rejeita o conhecimento simplesmente porque este provém de uma forma de resolução rival… As formas de resolução são simplesmente analisadas e verificada a sua validade para a resolução de uma determinada acção Um dos critérios fundamentais para uma boa teoria é que deve ser capaz de assimilar ao invés de impor barreiras aos seus predecessores ou rivais, e assim, a abordagem declarativa não nega a abordagem procedimental Uma solução informática passa pelo desenvolvimento de um algoritmo ALGORITMO = Exemplo: 0! = 1, LÓGICA + CONTROLO (conhecimento para (especifica a forma como esse resolver o problema) conhecimento pode ser utilizado) n! = n*(n-1)! FACT = 1 FACT = 1 Se (n = 0) então { SKIP senão enquanto (n > 0) FACT = FACT * n n=n–1 RETURN (FACT) CONT = 0 Se ( n = CONT) então { SKIP senão repetir CONT=CONT+1 FACT=FACT*CONT até (CONT = n) RETURN (FACT) Seria preferível poder representar o conhecimento (conceitos) de uma forma declarativa Modelo lógico/dedutivo Surge da junção de duas tecnologias Bases de dados Programação em lógica Permite armazenar Conhecimento factual (dados) Regras de dedução Permitem traduzir os conceitos de uma forma declarativa Permitem inferir factos adicionais, a partir do conhecimento factual Programação em lógica Conjunto de predicados lógicos de dois tipos Factos (expressões que representam a realidade) Regras (parte dedutiva) A lógica proporciona uma forma de provar se uma determinada questão é verdadeira ou falsa O processo de construção da prova tem de ser conhecido Os sistemas de programação em lógica simplesmente automatizam o processo de prova das questões Exemplo de uma formulação Factos ou conclusões intermédias: F1, F2, …, Fn Regras: C :- F1, F2, …, Fn C1 :- F1, F2, F3 A regra pode ser lida como uma implicação lógica (leitura declarativa) da seguinte forma: F1 e F2 e F3 implicam C1 Se todas as variáveis da regra foram quantificadas, para provar C1, é suficiente provar F1, F2 e F3 Basicamente, podemos formular qualquer questão usando como operandos (C, H, F), onde: C H F é uma conclusão é uma hipótese, ou conclusão intermédia é um facto Exemplo de uma formulação Consideremos os factos: Homem(x) Mulher(x) Como podemos traduzir o conceito de Avô? Uma abordagem (manifestamente inadequada) poderia ser a definição do facto: Avô(x, y) …que nos obrigaria a instanciar todos os pares x, y com os nomes dos avós (homens) e respectivos netos ou netas… …e seria sempre uma modelação incompleta da realidade porque teríamos informação sobre os avós mas não teríamos sobre os pais, nem sequer sobre as avós (mulheres)… Uma solução muito mais inteligente seria; Factos: Homem(x) Mulher(x) Progenitor(x, y) Regras: Pai(x, y) Mãe(x, y) Avô(x, y) Avó(x, y) :- Homem(x), Progenitor(x, y) :- Mulher(x), Progenitor(x, y) :- Pai(x, z), Progenitor(z, y) :- Mãe(x, z), progenitor(z, y) Nesta solução, a nossa base de dados (base de factos) só tem 3 tabelas (factos), e todas as outras relações são inferidas das regras que definimos Uma base de dados lógico/dedutiva é constituída por: Um conjunto de factos (conhecimento puramente factual), traduzido por predicados lógicos do tipo facto Um conjunto de regras O conhecimento derivado pelas regras, é visto como sendo o conhecimento para além do conhecimento factual da base de dados Apesar de o conjunto de dados que o nível aplicacional tem acesso poder ser muito vasto, apenas parte desses dados estão explicitamente armazenados. A outra parte é informação deduzida a partir das regras. A recolha do conhecimento procedimental sob a forma de regras tem vantagens no desenvolvimento e manutenção de aplicações, já que é bem mais simples adicionar ou modificar uma regra do que alterar código fonte Assim, uma Base de Dados Dedutiva pode ser dividida em duas partes: a Base de Dados Extensional (BDE): que é formada pelo conjunto de factos básicos contidos nas relações base, que foram explicitamente inseridos. a Base de Dados Intensional (BDI): que é formada pelas informações contidas nas relações derivadas, deduzidas pela aplicação de regras dedutivas sobre o BDE Num sistema de Base de Dados Dedutiva, o conteúdo das relações derivadas depende do conteúdo das relações básicas da Base de Dados. Assim, o efeito de uma actualização sobre uma relação básica deve ser visível nas relações derivadas. Da mesma forma, se é solicitada uma actualização sobre uma relação derivada, as relações básicas devem ser modificadas de forma que a actualização solicitada se torne visível. Há duas políticas básicas para tratar relações derivadas: manter as relações derivadas virtuais, ou seja, não são armazenadas e são computadas quando necessário; armazenar as relações derivadas, ou seja, manter as relações derivadas materializadas. A vantagem das relações derivadas materializadas é que se pode diminuir o tempo de acesso, através da criação de estruturas de índice. No entanto, se uma alteração nas relações básicas causa uma alteração nas relações derivadas materializadas, estas devem ser modificadas de forma a reflectir a alteração realizada nas relações básicas. Este processo é chamado de propagação de actualizações. Na maioria das vezes, não é a melhor solução computar toda a relação derivada materializada a cada alteração da Base de Dados. Esta alternativa seria interessante nos casos em que ocorre uma grande quantidade de alterações na BD, como a exclusão de uma relação inteira, por exemplo. Como esta situação não é a mais comum, a melhor solução é a utilização de algoritmos incrementais que realizam nas relações derivadas apenas as alterações correspondentes às alterações nas relações básicas. Desenvolvimento de Bases de Dados dedutivas Duas abordagens no desenvolvimento de SGBDD: Homogénea – a parte intensional e a parte extensional são feitas do mesmo elemento há uniformidade de representações e transparência da linguagem utilizada (por exemplo, a utilização de Prolog para desenvolver uma BDD) Heterogénea – a parte intensional e a parte extensional são construídas de componentes distintos que coexistem. A coexistência pode ser: Fraca (as duas componentes cooperam quando necessário, mas mantêm autonomia); Forte (as duas componentes, apesar de diferentes encontram-se fortemente integradas). A unidade de gestão da interface decide se a questão é submetida directamente à parte extensional ou se a parte intensional também deve colaborar Entre os Sistemas de Bases de Dados Dedutivas existentes, pode-se citar CORAL, LDL, LogiQuel, Aditi, LQL, RDL1, Glue-Nail, Rock & Roll, ConceptBase e Chronolog, desenvolvidos em ambientes universitários,e o Sistema DECLARE, desenvolvido como um Sistema de Base de Dados Dedutiva comercial. Os Sistemas de Base de Dados dedutivas não são muito utilizados no desenvolvimento de aplicações do mundo real. A área é considerada mais teórica do que prática, porque: 1. A linguagem de consulta utilizada, geralmente baseada no Datalog, que é uma evolução do Prolog, não possui características que a tornem uma linguagem adequada para utilização em aplicações práticas. Particularmente, a ausência no Datalog base da negação, operações aritméticas, operações de comparação e funções agregadas, que são características desejáveis numa linguagem de consulta. A forma com que os atributos de uma relação são referenciados, pela sua posição e não pelo seu nome, também é uma característica incomoda destas linguagens. Além disso, elas geralmente só atendem a consultas e não são capazes de expressar actualizações, característica essencial em aplicações reais; 2. A implementação de muitos dos Sistemas de BDD, utiliza um Sistema de Gestão de Bases de Dados específico, ao qual é adicionada capacidade de tratar regras de dedução. Este tipo de implementação não permite que se mantenha a base de dados já instalada, tendose que convertê-la para o SGBD sobre o qual o Sistema de BDD foi criado. As actualizações num Sistema de BDD necessitam de tratamento adicional àquele provido por um Sistema de Base de Dados tradicional. Em particular, o problema das actualizações sobre relações derivadas, que está fortemente relacionado ao problema das actualizações sobre visões em Sistemas de Bases de Dados relacionais, e o problema da propagação de actualizações para relações derivadas materializadas, merecem atenção especial. Sistemas de BDD têm, pois, a sua origem ligada aos estudos sobre a integração de lógica com Bases de Dados. Estes estudos procuravam utilizar linguagens de programação em lógica como linguagens de consulta em Sistemas de Base de Dados. A primeira linguagem de programação utilizada foi o Prolog, o qual se mostrou ineficiente em tratar grandes volumes de dados e não dando importância à ordem das regras, o que não a fazia uma linguagem totalmente declarativa como se desejava. Isto levou à criação da linguagem de consulta Datalog. Exemplo de um Protótipo de SGBD Dedutiva O Sistema de Gestão de Bases de Dados Dedutivo DEDALO é um protótipo que implementa uma nova linguagem que é uma extensão do Datalog, os métodos de propagação de actualizações para relações derivadas materializadas, as técnicas de tradução de actualizações sobre relações derivadas, os métodos de detecção de violação de restrições de integridade e as técnicas de recuperação das transacções que as violam. O Sistema DEDALO é composto de quatro ferramentas: o Gestor de Regras, onde as regras de derivação e as restrições de integridade são definidas; a Interface Interactiva, utilizada para submeter consultas ad hoc e solicitações de actualização sobre o sistema; dois novos Componentes Delphi, que são duas novas classes criadas para o ambiente de desenvolvimento de aplicações Delphi, que foi utilizado na implementação do protótipo, e são utilizadas para a criação das aplicações sobre o Sistema DEDALO; o Tradutor de Sentenças DEDALO/SQL-ANSI, que traduz as sentenças da linguagem proposta para sentenças SQL-ANSI que serão submetidas ao Sistema Gestor de Base de Dados.