Bases de Dados - Dei-Isep

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
mecanismos não têm representação directa no modelo relacional
Exemplo
Viaturas
Automóveis
Autocarros
Camiões
Familiares
Desportivos
(matrícula, marca, cilindrada, combustível)
(matrícula, volumes)
(matrícula, lugares_sentados, lugares_pé)
(matrícula, tara, peso_bruto)
(matrícula, nºportas)
(matrícula, potência, tracção)
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
Este mecanismo de abstracção não é inerente ao modelo relacional
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
Automóveis
(’12-AB-34’, ‘BMW’, 2000, ‘Diesel’)
(’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
Um glossário (lista de palavras chave)
!
"
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)
Título
Autor
Editor
Glossário
Database
Database System Concepts
Silberschatz
1
Object
Korth
2
McGraw
Sudarshan
3
Hill
Join
Property
…
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
!
"
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?
WORM devices (Dispositivos ópticos, CD, etc)
!
"
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
Salário
Tempo real
Tempo de sistema
1000
2000-01-01
2000-01-05
1200
2000-01-01
2000-09-15
Salário
Tempo real
Tempo de sistema
1000
2000-01-01
2000-01-05
1200
2000-09-01
2000-09-15
!
"
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
Questões correntes
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
#
$"%
Tecnologia de bases de dados – FCA – José Luís Pereira