Características dos sistemas convencionais de gestão

O modelo relacional adapta-se perfeitamente a sistemas de

processamento de dados de gestão

Áreas como o CAD, CIM, GIS, ferramentas CASE, sistemas

multimédia, etc., têm características muito diferentes das aplicações

tradicionais de gestão

Os sistemas relacionais não são adequados

Características dos sistemas convencionais de gestão

Necessidade de manipulação de grandes volumes de dados Dados simples, homogéneos e com formatos fixos

Modelos de dados relativamente estáveis Transacções de curta duração

O conteúdo da BD, em cada momento, reflecte o estado actual da realidade modelada

As novas áreas de aplicação solicitam ao SGBD outras facilidades

Suporte a tipos de dados complexos

Modelos de dados semanticamente mais ricos

Representação de formas mais elaboradas de conhecimento Transacções com duração relativamente grande

Manutenção da evolução dos objectos modelados

Há a necessidade de aumentar o nível de abstracção sobre a

realidade modelada

O modelo relacional pode ser utilizado para representar mecanismos tais como a agregação, a classificação, a generalização, a especialização e a associação, mas, é uma solução pouco adequada porque estes

Exemplo

Viaturas

(matrícula, marca, cilindrada, combustível)

Automóveis (matrícula, volumes)

Autocarros (matrícula, lugares_sentados, lugares_pé)

Camiões

(matrícula, tara, peso_bruto)

Familiares (matrícula, nºportas)

Há perdas a nível semântico

A estrutura hierárquica desapareceu

Que relações são generalização ou especialização de que relações?

É necessário que a informação sobre a estrutura hierárquica seja representada através de código

Caso não se represente através de código, esse conhecimento tem de estar presente na mente das pessoas que vão manipular o modelo

A consulta da informação é dificultada

Para obter informação sobre uma determinada relação, temos de fazer a junção com todas as relações hierarquicamente superiores

Por exemplo, para saber informação sobre um automóvel familiar, temos de obter dados das relações Familiar, Automóvel e Viatura

Quanto maior for a hierarquia, maior é a carga colocada sobre o utilizador e sobre o sistema de gestão da base de dados

Uma possível alternativa:

Utilização de views

Cada view “importa” toda a informação da relação hierarquicamente superior

v_Viaturas (matrícula, marca, cilindrada, combustível)

v_Automóveis (matrícula, marca, cilindrada, combustível, volumes)

v_Autocarros (matrícula, marca, cilindrada, combustível, lugares_sentados, lugares_pé)

v_Camiões (matrícula, marca, cilindrada, combustível, tara, peso_bruto) v_Familiares (matrícula, marca, cilindrada, combustível, volumes, nºportas) v_Desportivos (matrícula, marca, cilindrada, combustível, volumes, potência, tracção)

Problemas

A estrutura hierárquica continua a não ser representada

Podemos decifrá-la se compararmos os atributos de todas as relações… Mas obriga-nos a conhecer previamente todas as relações…

E não é um processo fácil nem infalível

As views têm limitações na actualização de informação

A actualização de informação de uma view proveniente de junções entre tabelas só é possível se sobre ela tivermos definido “INSTEAD OF

TRIGGERS” que direccionam as actualizações para as tabelas base

Nem todos os SGBDs permitem a definição de “INSTEAD OF TRIGGERS” Nesse caso, a actualização da view pode não ser possível, e as

actualizações têm de ser feitas directamente sobre as tabelas base Isso resulta num processo pouco transparente porque para consultar

informação usamos as views, e para alterar temos de conhecer as tabelas base

Breve exemplo, considerando a view v_Automóveis:

v_Automóveis (matrícula, marca, cilindrada, combustível, volumes)

Se quisermos criar um novo automóvel, podemos inserir o registo

V_Automóveis (’12-AB-34’, ‘BMW’, 2000, ‘Diesel’, 2)

Como a view deriva das tabelas base Viaturas e Automóveis, este novo registo tem de ser distribuído pelas mesmas

Viaturas (’12-AB-34’, ‘BMW’, 2000, ‘Diesel’) Automóveis (’12-AB-34’, 2)

Há ainda outros problemas associados à actualização das views, como por exemplo, views que tenham cláusulas WHERE

Não é fácil garantir a integridade dos dados

Outras soluções poderiam ser (ainda que pobres e limitadas):

A remoção das relações que não são “folha”, nomeadamente Viatura e Automóvel Juntar toda a hierarquia numa única relação

!

"

Extensões ao modelo relacional

Suporte a tipos de dados complexos, assim como funções para a sua manipulação

As relações deixam de estar normalizadas (Nested Realations)

Acesso não procedimental aos dados através de linguagens tipo SQL

A norma SQL3 irá incrementar funcionalidades relacionais e incluir características marcadamente object/oriented

!

"

O modelo relacional exige a normalização dando origem a modelos onde os objectos modelados se encontram desagregados, e apesar de relacionados, se encontram dispersos por várias relações

Seria desejável que no nível aplicacional os dados surgissem reorganizados, reconstruindo os objectos do mundo real que representam

Uma possível abordagem pode ser a adição de uma camada de software capaz de reorganizar sob a forma de objectos, os dados provenientes de várias relações (Gestor de Objectos)

Este tipo de soluções, dadas as necessárias transformações entre objectos manipulados no nível aplicacional e o sistema relacional, apresenta alguns problemas de desempenho

!

"

Outra abordagem pode ser a reformulação do próprio modelo relacional, permitindo a existência de relações não normalizadas

Nested-Relations

São relações onde os atributos podem não ser atómicos

Aumenta o grau de abstracção e permite a capacidade de abstracção do modelo relacional clássico

Outra linha de desenvolvimento é a adição da dimensão temporal ao modelo relacional

Modelo Relacional Temporal

Em cada instante, a base de dados tem a situação actual As transições de estados são perdidas

O modelo relacional clássico pode permiti-lo, no entanto será à custa de maior redundância e de uma modelação de dados menos natural

!

"

Nested-Relations

O valor de um atributo pode ser

Atómico

Um conjunto de valores Um conjunto de tuplos

Um objecto pode ser representado por um único tuplo de uma nested-relation

Pode agora ser possível ver a base de dados, não como um conjunto de relações ou tabelas, mas como um conjunto de objectos

O esquema relacional nested é definido como um conjunto de nested-relations

Exemplo: Sistema de informação de uma biblioteca

Cada livro tem

Um título

Um grupo de autores Um editor

!

"

Exemplo: Sistema de informação de uma biblioteca

Cada livro tem

Um título

Um grupo de autores Um editor

Um glossário (lista de palavras chave)

A visão normalizada iria conduzir a uma desagregação do objecto livro,

distribuindo os seus dados por várias tabelas, obrigando à utilização de

junções para recuperar o objecto original

… Property Hill 3 Sudarshan Join McGraw 2 Korth Object 1 Silberschatz Database Database System Concepts

Glossário Editor

Autor Título

!

"

A dimensão temporal

Normalmente, na manutenção de um sistema de bases de dados apenas fica reflectido o estado actual, perdendo-se os estados anteriores

As actualizações são do tipo overwriting

O modelo clássico de Codd não prevê a dimensão temporal dos dados Seria conveniente o seu tratamento, e que isso fosse tarefa do SGBD A base de dados seria constituída por duas partes lógicas

Parte histórica

Parte activa (actual)

A parte activa é o modelo relacional actual A parte histórica vai crescendo rapidamente

Haverá condições para a implementar?

!

"

O universo modelado e a sua representação na BD podem estar dessincronizados

Os eventos ocorridos no mundo real podem ser registados na base de dados, mais tarde (ou até mais cedo) que a altura em que realmente aconteceram

Medidas temporais

Tempo real (valid-time)

Tempo de sistema (transaction-time)

Ao contrário dos sistemas temporais, nos sistema não temporais, uma

actualização não distingue uma actualização de uma correcção

Correcção Evolução 2000-09-15 2000-01-01 1200 2000-01-05 2000-01-01 1000 Tempo de sistema Tempo real Salário

!

"

Tipos de bases de dados

Snapshot (não suportam dimensão temporal) Rollback (suportam apenas tempo de sistema) Históricas (suportam apenas tempo real)

Temporais (suportam ambos os tempos real e de sistema)

Tipos de questões que se podem colocar a uma base de dados temporal

Não têm qualquer referência temporal. Actuam apenas sobre o segmento corrente Questões normais

Para além dos dados do segmento corrente, também actuam sobre eventuais correcções, até ao momento actual

Questões rollback

São questões que, posicionando-se num determinado momento passado, actuam sobre os dados anteriores a esse momento

!

"

Implementação de modelos temporais

É adicionada uma terceira dimensão: o tempo

Pode assumir duas formas Intervalos de tempo

Adequada para caracterizar situações em que os dados se mantêm estáveis durante um dado espaço de tempo

Instantes de tempo

Adequada para caracterizar situações em que os dados apenas são válidos num determinado instante de tempo, mais concretamente, na altura em que são recolhidos

Formas de implementação

Etiquetagem temporal de tuplos Etiquetagem temporal de atributos

#

$"%