Bases de Dados - Dei-Isep
Propaganda
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
