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
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
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 = LÓGICA + CONTROLO
(conhecimento para (especifica a forma como esse resolver o problema) conhecimento pode ser utilizado)
Exemplo: 0! = 1, n! = n*(n-1)!
FACT = 1 FACT = 1
Se (n = 0) então { SKIP CONT = 0
senão enquanto (n > 0) Se ( n = CONT) então { SKIP
FACT = FACT * n senão repetir
n = n – 1 CONT=CONT+1
RETURN (FACT) 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
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 é uma conclusão
H é uma hipótese, ou conclusão intermédia
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)
:- Homem(x), Progenitor(x, y)
Mãe(x, y)
:- Mulher(x), Progenitor(x, y)
Avô(x, y)
:- Pai(x, z), Progenitor(z, y)
Avó(x, 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, tendo-se 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.
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.
