CEFET-PI Pós-graduação Lato Sensu Especialização em Banco de Dados Bancos de Dados Objeto-Relacionais Prof. Ricardo Ramos BDOR Abril 2008 1
Evolução dos SGBDs Sistemas de Arquivos SGBD Hierárquico (1ª Geração) A SGBD Orientado a Objetos (3ª Geração) C SGBD Objeto-relacionais (3ª Geração) D SGBD em Rede (1ª Geração) A SGBD Relacionais (2ª Geração) B 2
Evolução dos SGBDs A - Final da década de 1960 (SGBDs de legado) SGBD Hierárquico: IMS da IBM SGBD de Rede: IDSII, IDMS, IMAGE, VAX-DBMS, etc B - Final da década de 1970 e início da década de 1980 C - Final da década de 1980 e início da década de 1990 D - Final da década de 1990 3
Classificação dos SGBDs Banco de Dados Convencionais - Dados bem estruturados; - Tipos de dados simples (inteiros, reais, caracteres...); - Transações simples e curtas; - Acesso através de chaves; - Exemplo de aplicações: folha de pagamento e controle de estoque; - 1ª e 2ª Gerações. 4
Classificação dos SGBDs Banco de Dados Não Convencionais - Grande volume de dados estruturados; - Tipos de dados complexos (textos, gráficos, imagens, vídeos e sons); - Transações longas; - Acesso não trivial; - Exemplo de aplicações: projeto assistido por computador (CAD), CASE e SIG; - 3ª Geração. 5
Matriz de Stonebraker Com consulta II IV Sem consulta I III Dados simples Dados complexos 6
Matriz de Stonebraker I Dados simples sem consulta - Este quadrante representa aplicações que lidam apenas com dados bastantes simples e não têm qualquer exigência para consultas ad-hoc; - Exemplo: um editor de texto; - Na realidade, essas aplicações não são de modo algum aplicações de banco de dados no sentido comum desse termo; 7
Matriz de Stonebraker I Dados simples sem consulta (cont) - O SGBD que melhor serve as suas necessidades é apenas o gerenciador de arquivos interno, fornecido como parte do sistema operacional. 8
Matriz de Stonebraker Com consulta Sem consulta II I Gerenciadores de Arquivos Dados simples IV III Dados complexos 9
Matriz de Stonebraker II Dados simples com consulta - Este quadrante representa aplicações que têm uma exigência de consulta ad-hoc, mais ainda lidam apenas com dados bastantes simples; - A maioria das aplicações comerciais de hoje se encaixa nesse quadrante, e elas são razoavelmente bem aceitas por SGBDs relacionais tradicionais (ou, pelo menos, SQL); 10
Matriz de Stonebraker II Dados simples com consulta (cont) - Linguagem de consulta; - Ferramentas de interfaces; -Performance (gerenciamento de transações consistentes); - Segurança. 11
Matriz de Stonebraker Com consulta II (SGBDR) IV Sem consulta I Gerenciadores de Arquivos Dados simples III Dados complexos 12
Matriz de Stonebraker III Dados complexos sem consulta - Este quadrante representa aplicações com exigências complexas de dados e processamento, mas nem uma exigência de consultas ad-hoc; - Exemplo: aplicações CAD; - Os SGBDOOs atuais se destinam principalmente a esse segmento de mercado (os produtos de SQL tradicionais tendem a não realizar um trabalho muito bom sobre aplicações deste quadrante); 13
Matriz de Stonebraker III Dados complexos sem consulta (cont) - Necessidade de rotinas específicas para manipulação dos dados complexos; - Grande integração com uma linguagem de programação; - Performance na atualização de variáveis persistentes. 14
Matriz de Stonebraker Com consulta II (SGBDR) IV Sem consulta I Gerenciadores de Arquivos Dados simples III (SGBDOO) Dados complexos 15
Matriz de Stonebraker IV Dados complexos com consulta - Este quadrante representa aplicações com necessidade de dados complexos e consultas ocasionais sobre seus dados; - Exemplo: um banco de dados contendo slides digitalizados de 35mm, com uma consulta típica sendo obter imagens do pôr do sol tiradas em Teresina ; 16
Matriz de Stonebraker IV Dados complexos com consulta (cont) - Um SGBDOR é necessário para aplicações onde se encaixam neste quadrante; - Os SGBDORs surgiram como uma maneira de se estenderem as capacidades de SGBDRs com algumas das características que apareceram em SGBDOOs. - Nos próximos anos, a maioria das aplicações de recursos humanos poderá se expandir para incluir fotografias de empregados, gravações sonoras (mensagens faladas) e coisas desse tipo. 17
Matriz de Stonebraker IV Dados complexos com consulta (cont) -Linguagem de consulta estendida à objetos complexos (SQL3); - Ferramentas de visualização não convencionais; - Otimizador de consultas. 18
Matriz de Stonebraker Com consulta II (SGBDR) IV (SGBDOR) Sem consulta I Gerenciadores de Arquivos Dados simples III (SGBDOO) Dados complexos 19
Características Fundamentais de um SGBDOR As principais motivações que há por trás do desenvolvimento de SGBDORs têm origem na incapacidade dos SGBDs de legado e dos SGBDRs, de fazer face aos desafios de novas aplicações. As novas aplicações se encontram basicamente em áreas que envolvem vários tipos de dados, necessitando uma extensão dos tipos de dados básicos. 20
Características Fundamentais de um SGBDOR Exemplos de novas aplicações: - imagens obtidas por satélite ou na previsão do tempo; - dados complexos não-convencionais em projetos de engenharia; - informações sobre o genoma biológico; - dados sobre a poluição da água e do ar. 21
Características Fundamentais de um SGBDOR Portanto, existe uma clara necessidade de se projetarem bancos de dados que possam desenvolver, manipular e manter os objetos complexos que surgem de tais aplicações. Além disso, torna-se necessário lidar com informações digitalizadas que representam streams (correntes) de dados de áudio e vídeo que requerem o armazenamento de BLOBs (grandes objetos binários) nos SGBDs. 22
Características Fundamentais de um SGBDOR O suporte a herança para a criação de novos tipos de dados. Por conseguinte, surgiu uma tendência de combinar as melhores características do modelo e da linguagem de dados de objetos com o modelo relacional, de modo que o mesmo possa ser estendido para lidar com as desafiadoras aplicações dos dias de hoje. 23
Projeto de BD para SGBDOR Um projeto mal feito é responsável pelo fracasso de muitas aplicações. Um bom projeto é um desafio mesmo para BD relacionais. A maioria dos produtos são baseados no modelo E-R. 24
Projeto de BD para SGBDOR Projeto E-R: - identificar entidades; - identificar atributos de cada entidade; - dar a cada entidade um identificador único (chave primária); - identificar os relacionamentos entre entidades (1:1, 1:N, M:N); 25
Projeto de BD para SGBDOR Projeto E-R: (cont) - identificar os eventuais atributos dos relacionamentos; - mapear o esquema E-R gerando tabelas normalizadas. 26
Projeto de BD para SGBDOR Por que tantos problemas com projetos de BD? 1) Dificuldade em ajustar o esquema Normalizar ou desnormalizar tabelas em função de melhoria da performance analisando as consequências para o resto do esquema. Intuição e prática 27
Projeto de BD para SGBDOR Por que tantos problemas com projetos de BD? (cont) 2) Desinteresse em seguir todos os passos do projeto O projeto é um processo evolutivo e tem que ser revisto em diversas circunstâncias. É uma tarefa que demanda um grande esforço e é necessário uma pessoa responsável unicamente por esta atividade. 28
Projeto de BD para SGBDOR Por que tantos problemas com projetos de BD? (cont) 3) Projeto irreal da aplicação Um implementador pode usar uma dada funcionalidade do SGBD para resolver vários problemas sem analisar se é um bom mecanismo ou não. Ex: triggers (gatilhos) Sérios problemas de performance 29
Projeto de BD para SGBDOR Por que tantos problemas com projetos de BD? (cont) 4) Fracasso em atingir os objetivos de performance em grandes BD Carregar e testar grandes BD previamente para que qualquer problema de performance seja identificado a tempo de uma ação corretiva. Este passo não pode ser menosprezado 30
Projeto de BD para SGBDOR Por que tantos problemas com projetos de BD? (cont) 5) Dificuldade em capturar todo o esquema Capturar todas as restrições do esquema, regras do tipo: todo empregado deve trabalhar em um departamento e todas as ações a serem tomadas em caso de falha. Difícil de conseguir este tipo de informação do usuário 31
Projeto de BD para SGBDOR Por que tantos problemas com projetos de BD? (cont) 6) Excesso de foco na modelagem formal da aplicação Busca por uma ferramenta apropriada e decisão de construir uma própria depois de uma longa procura. Atividades que não ajudam na construção da aplicação 32
Projeto de BD para SGBDOR Desafios em projetos de BDOR: OR é um super-conjunto do relacional, os problemas são os mesmos porém mais complexos. 1) Escolher entre as várias opções: - como implementar as tabelas empregado e departamento? (Ver pág 28 BDOO) a) O atributo departamento na tabela Empregado como ref(departamento). 33
Projeto de BD para SGBDOR 1) Escolher entre as várias opções: (cont) b) O relacionamento empregados da tabela Departamento como setof(ref(empregado)). c) Ou qualquer um dos casos anteriores de outra forma. 34
Projeto de BD para SGBDOR Realmente se requer arte e uma boa intuição para escolher a melhor maneira de implementar um esquema OR. Pela riqueza do modelo, o projeto de um banco de dados OR é proporcionalmente mais difícil. 35
Projeto de BD para SGBDOR Representação de dados versus procedimentos Consideremos o exemplo de datadenascimento e idade de um empregado (Ver pág 33 BDOO). No modelo relacional seriam implementados dois atributos com controle de consistência entre eles. 36
Projeto de BD para SGBDOR Representação de dados versus procedimentos (cont) No OR, existe a possibilidade de implementação de procedimentos. Logo, um pode ser implementado como um atributo e o outro calculado por um procedimento e identificado quando o procedimento será executado (se na entrada do dado ou em uma consulta). 37
Projeto de BD para SGBDOR Em resumo: - projeto OR é mais difícil do que o relacional; - são necessárias pessoas qualificadas para definir qual a melhor opção e não existem muitas no mercado; - SGBDOR devem ser mais fáceis de usar no futuro; 38
Projeto de BD para SGBDOR Em resumo: (cont) - o esquema deve ser ajustado automaticamente pelo sistema para melhorar performance; - o sistema deveria prevenir o usuário das conseqüências de suas escolhas em termo de performance. 39
Visão Geral da SQL3 (SQL3 - http://en.wikipedia.org/wiki/sql); A SQL é a linguagem de consulta padrão para SGBDRs. A SQL foi especificada pela primeira vez nos anos 70, e em 1986 foi adotada como padrão ANSI e em 1987 como ISO. Em 1992 a SQL-92 (SQL2) teve sua maior revisão. Em 1999 a SQL3 acrescenta características orientadas a objetos, além de outras características. 40
Visão Geral da SQL3 Em SGBDORs a SQL pode ser estendida para lidar ao mesmo tempo com tabelas do modelo relacional e classes e objetos do modelo orientado a objetos. 41
Visão Geral da SQL3 Novos tipos de operações foram adicionados à SQL3: - A operação SIMILAR, que permite o uso de expressões regulares para combinar com strings de caracteres; - Valores booleanos foram estendidos com UNKNOWN(DESCONHECIDO) quando uma comparação não resulta nem verdadeiro nem falso, porque alguns valores podem ser nulos; 42
Visão Geral da SQL3 Novos tipos de operações foram adicionados à SQL3: (cont) - Uma nova operação importante é a recursão linear para especificar consultas recursivas; Tabela_Peças(Peça 1, Peça 2) tupla<p1, p2> sempre que a peça p1 contenha a peça p2 como componente. Uma consulta para produzir a lista de materiais para alguma peça p1 (ou seja, todas as peças componentes necessárias para produzir p1) está descrita a seguir: 43
Visão Geral da SQL3 Novos tipos de operações foram adicionados à SQL3: (cont) WITH RECURSIVE Lista_Materiais(Peça 1, Peça 2) As (Select Peça 1, Peça 2, from Tabela_Peças where Peça 1 = p1 UNION ALL Select Tabela_Peças (Peça 1), Tabela_Peças (Peça 2) from Lista_Materiais, Tabela_Peças where Tabela_Peças.Peça1 = Lista_Materiais(Peça2)) Select * from Lista_Materiais order by Peça 1, Peça 2; 44
Visão Geral da SQL3 Novos tipos de operações foram adicionados à SQL3: (cont) - role(papel), é semelhante a uma descrição de serviço e está sujeito à autorização de privilégios gios. As verdadeiras pessoas (contas de usuários) que são designadas para um papel podem ser alteradas, mas a autorização de papéis propriamente dita não precisa ser alterada; 45
Visão Geral da SQL3 Novos tipos de operações foram adicionados à SQL3: (cont) - inclui sintaxe para especificação e uso de triggers como regras ativas. Eventos de triggers incluem as operações INSERT, DELETE e UPDATE em uma tabela. O disparo pode ser especificado como sendo antes (BEFORE) ou após (AFTER) o evento de disparo. 46
Visão Geral da SQL3 Novos tipos de operações foram adicionados à SQL3: (cont) - A SQL3 está sendo estendida com facilidades de linguagem de programação. - Rotinas escritas em SQL computacionalmente completa, com a plena combinação de tipos de dados e um ambiente integrado, denominam-se rotinas da SQL. 47
Visão Geral da SQL3 Novos tipos de operações foram adicionados à SQL3: (cont) - Para tornar computacionalmente completa a linguagem, estão incluídas na sintaxe da SQL3 as seguintes estruturas de controle de programação: CALL/RETURN, BEGIN/END, FOR/END_FOR, IF/ THEN/ELSE/END_IF, CASE/END_CASE, LOOP/ END_LOOP, WHILE/END_WHILE, REPEAT/UNTIL/END_REPEAT e LEAVE. 48
Visão Geral da SQL3 Novos tipos de operações foram adicionados à SQL3: (cont) - Variáveis são declaradas utilizando-se DECLARE e atribuições são especificadas utilizando-se SET. 49
Visão Geral da SQL3 A SQL3 estende a (SQL2/SQL-92) para incluir funcionalidades orientadas a objetos. Novos tipos de dados incluem objetos booleanos, objetos de caracteres e objetos binários grandes (LOBs). Em função da SQL/Fundamentos, a SQL3 admite tipos de dados definidos pelo usuário, construtores de tipo, tipos de coleção, funções e procedimentos definidos pelo usuário, suporte pra grandes objetos e triggers. 50
Visão Geral da SQL3 Os objetos na SQL3 são de dois tipos: - tipos linhas, cujas instâncias são tuplas tabelas; em - tipos abstratos de dados (TAD), que significam quaisquer tipos gerais. 51
Visão Geral da SQL3 Um tipo linha pode ser definido utilizando-se a sintaxe: CREATE ROW TYPE nome (< componentes >); Exemplo 1: CREATE ROW TYPE emp (nome VARCHAR (35), idade INTERGER ); CREATE ROW TYPE comp (nomecomp VARCHAR (20), localização VARCHAR (20)); 52
Visão Geral da SQL3 Tabelas podem ser criadas com base nas declarações dos tipos linhas emp e comp. Exemplo 2: CREATE TABLE Empregado OF TYPE emp; CREATE TABLE Companhia OF TYPE comp; Um atributo componente de uma tupla pode ser uma referência (REF) para uma tupla de uma outra(ou talvez da mesma) relação. 53
Visão Geral da SQL3 Exemplo 3: CREATE ROW TYPE emprego (Empregado REF (emp emp), Companhia REF (comp comp)); CREATE TABLE Emprego OF TYPE emprego; A SQL3 utiliza notação de dois pontos para construir expressões de caminho que se referem aos componentes de tuplas. Exemplo 4: SELECT Emprego..empregado..nome FROM Emprego WHERE Emprego..companhia..localização = teresina ; 54
Visão Geral da SQL3 Identificadores de objeto (OIDs OIDs) podem ser explicitamente declarados e acessados. Exemplo 5: CREATE ROW TYPE emp (nome CHAR (35), idade INTENGER, Id REF (emp emp)); Valores de identificador de objeto podem ser gerados pelo sistema. Exemplo 6: CREATE TABLE Empregado OF TYPE emp VALUES FOR Id ARE SYSTEM GENERATED; 55
Visão Geral da SQL3 Tipos Abstratos de Dados (TADs TADs) Na SQL3, é fornecido um componente semelhante à definição de classe através do qual o usuário pode criar um tipo definido pelo usuário com sua própria especificação de comportamento e estrutura interna. Exemplo 7: CREATE TYPE <nome> ( Lista de atributos com tipos Declaração de funções EQUAL e LESS THAN Declaração de outras funções ou métodos ); 56
Visão Geral da SQL3 Exemplo 8: CREATE TYPE Pessoa (nome VARCHAR (40), identidade INTEGER); Um TAD tem inúmeras funções definidas pelo usuário a ele associadas. A sintaxe é: Exemplo 9: FUNCTION <nome> (<lista_argumentos >) RETURNS <tipos>; 57
Visão Geral da SQL3 Herança - Todos o atributos são herdados; - A ordem dos subtipos na clausula UNDER determina a hierarquia de herança; - Uma instância de um subtipo pode ser utilizada em todos os contextos em que uma instância de supertipo seja utilizada. Exemplo 10: CREATE TYPE Professor (salário INTENGER, departamento VARCHAR, UNDER Pessoa); 58
Visão Geral da SQL3 Sobrecarga - Um subtipo pode redefinir qualquer função que esteja definida em seu supertipo, com a restrição de que a assinatura seja a mesma. Resolução de Funções - Quando uma função é chamada, a melhor combinação é selecionada com base nos tipos de todos os argumentos. 59
Visão Geral da SQL3 Tipos Coleções - A SQL3 suporta construtores para tipos de coleção, que podem ser utilizadas para se criarem estruturas aninhadas para objetos complexos. Exemplo 11: List, Set e Mutiset 60