Introdução a Teoria de Banco de Dados Prof. Rogério Gonçalves Bittencourt, M.Sc. Prof. Rogério Bittencourt Literatura Recomendada BATINI, C.; CERI, S.; NAVATHE, S. B.: Conceptual database desing. Benjamin/Cummings Publ. Co., Redwood City, 1992. ELMASRI, R.; NAVATHE, S.B.: Fundamentals of database systems. AddisonWesley. 3Ed. Reprinted June 2000. ULLMAN, J. D. & WIDON, J.: A first course in database systems. Prentice-Hall, Inc. 1997. RAMAKRISHNAN, R.: Database management systems. McGraw-Hill. 1998. HEUSER, C. A.: Projeto de banco de dados. 3Ed. Sagra-Luzzatto, Porto Alegre. 1999. DATE, C. J.: Introdução a sistemas de bancos de dados. Ed. Campus, Rio de Janeiro, 6ª Edição, 2000. KORTH. H. F.; SILBERSCHATZ, A.: Sistemas de bancos de dados. McGrawHill, São Paulo, 1994. Prof. Rogério Bittencourt Terminologia Básica Dados representação de fatos, conceitos ou instruções de maneira formalizada. Informação significado que pessoas associam aos dados através de convenções usadas em sua interpretação. Conhecimento discernimento, critério, apreciação prática de vida, experiência. Prof. Rogério Bittencourt Como a Informática é Adotada nas Organizações Informática é implementada gradativamente Exemplo – Empresa hipotética Implementa gradativamente sistemas para: Vendas Produção Compras Onde ficam os dados de PRODUTO? Prof. Rogério Bittencourt Sistemas Isolados Dados não Compartilhados Dados de diferentes aplicações não estão integrados Dados estão projetados para atender uma aplicação específica Produção Vendas Compras Arquivos produção Arquivos vendas Arquivos compras Produtos Prof. Rogério Bittencourt .... Produtos .... Produtos .... Sistemas Isolados Dados não Compartilhados Problema: redundância de dados Tipos de redundância de dados: Redundância controlada de dados Software gerencia redundância Redundância não controlada de dados Usuário gerencia redundância (não há gerência automática) Prof. Rogério Bittencourt Redundância Não Controlada Conseqüências Entrada repetida da mesma informação Inconsistências de dados Dificuldade de extração de informações Dados projetados para atender aplicações específicas geram dificuldades para o cruzamento de informações Dados pouco confiáveis e de baixa disponibilidade Prof. Rogério Bittencourt Como Evitar Redundância Não Controlada Compartilhamento de dados Cada informação é armazenada uma única vez Usar o conceito de Banco de Dados Produção Vendas Compras Banco de Dados Produtos Prof. Rogério Bittencourt .... Definições de Banco de Dados Literatura “Um banco de dados é um conjunto de arquivos relacionados entre si” (Chu, 1983) “Um banco de dados é uma coleção de dados operacionais armazenados, sendo usados pelos sistemas de aplicação de uma determinada organização” (C. J. Date, 1985) “Um banco de dados é uma coleção de dados relacionais” (Elmasri & Navathe, 1989) “Um banco de dados é um conjunto de dados armazenados, cujo conteúdo informativo representa, a cada instante, o estado atual de uma determinada aplicação” (Laender, 1990) Prof. Rogério Bittencourt Banco de Dados Conjunto de arquivos integrados que atendem a um conjunto de sistemas Cada informação armazenada uma única vez Eventualmente redundância controlada pelo sistema em computador e invisível ao usuário Produção Vendas Compras Banco de Dados Produtos Prof. Rogério Bittencourt .... Banco de Dados Compartilhamento de dados tem reflexos na estrutura do software Estrutura interna dos arquivos passa a ser mais complexa Devem atender à necessidades dos diferentes sistemas Solução Usar Sistema de Gerência de Banco de Dados Prof. Rogério Bittencourt Evolução da Programação de Sistemas Início da programação de aplicações Programa continha todas operações Interface de usuários Transformações de dados e cálculos Operações de armazenamento de dados Tarefas de comunicação com outros sistemas e programas Prof. Rogério Bittencourt Evolução da Programação de Sistemas Foram identificadas funcionalidades comuns Exibição dos dados na interface Gerenciadores de interface de usuários Comunicação com processos remotos Gerenciadores de comunicação Manutenção de grandes repositórios compartilhados de dados • Sistemas de Gerência de Banco de Dados (SGBD) Prof. Rogério Bittencourt Sistema de Gerência de Banco de Dados Software que incorpora as funções de definição, recuperação e alteração de dados em um banco de dados Facilita desenvolvimento de aplicações de Banco de Dados (BD) Manutenção de programas torna-se mais simples Produtividade de programadores aumenta Prof. Rogério Bittencourt Sistemas de Gerência de Banco de Dados “O SGBD permite a definição, construção e manipulação do banco de dados para diversas aplicações.” DEFINIÇÃO do BD: Envolve a especificação dos tipos de dados a serem armazenados no BD, mais a descrição de cada tipo de dado. CONSTRUÇÃO do BD: Processo de armazenar os dados em um meio controlado pelo SGBD. MANIPULAÇÃO do BD: Execução de operações de consulta e recuperação de dados específicos, além de atualização de dados para refletir, no BD, mudanças no mini-mundo sendo modelado. A manipulação inclui, também, a geração de relatórios a partir dos dados do BD. Prof. Rogério Bittencourt Componentes de SBD Prof. Rogério Bittencourt Objetivos SBD Isolar os usuários dos detalhes mais internos do banco de dados (abstração de dados). Prover independência de dados às aplicações (estrutura física de armazenamento e à estratégia de acesso). Prof. Rogério Bittencourt Porque Usar Banco de Dados Sistema de Banco de Dados proporciona à empresa o controle centralizado de seus dados operacionais. Tal situação contrasta nitidamente com o que podemos encontrar em uma empresa que não utiliza um SGBD, onde cada aplicação dispõe de seus próprios arquivos de tal forma que os dados operacionais são muito dispersos, dificultando o controle sistemático. • Isto implica que exista um DBA Prof. Rogério Bittencourt Vantagens do Controle Centralizado Reduzir Redundância Compartilhamento dos Dados Evitar Inconsistência Padronização (redução do esforço humano (desenvolvimento e utilização)) Manter a Integridade Integridade Referencial Integridade Transacional Rapidez na manipulação e no acesso à informação Controle integrado de informações distribuídas fisicamente, Aplicação automática de restrições de segurança Prof. Rogério Bittencourt Modelos de Dados Modelo de (Banco de) Dados Descrição formal dos tipos de dados que estão armazenados em um Banco de Dados Prof. Rogério Bittencourt Modelos de Dados Conteúdo Exemplo de Indústria Modelo de dados informa São armazenadas informações sobre PRODUTOS Para cada PRODUTO são armazenadas seu código, preço e descrição Modelo de dados não informa Quais os produtos que estão armazenados no Banco de Dados Prof. Rogério Bittencourt Esquema de Banco de Dados Para construir um BD usa-se Linguagem de modelagem de dados Textual Gráfica Um modelo de dados pode ser apresentado de várias formas (texto, figura, ...) Cada apresentação do modelo recebe a denominação Esquema de Banco de Dados Prof. Rogério Bittencourt Modelos de Dados Níveis de Abstração Modelo Conceitual Abstração Modelo Lógico Modelo Físico Prof. Rogério Bittencourt Modelo Conceitual Independente do tipo de SGBD Registra Estrutura dos dados podem aparecer no BD Não registra Como estes dados estão armazenados a nível de SGBD Prof. Rogério Bittencourt Modelo Conceitual ER Técnica mais difundida de modelagem conceitual Abordagem entidade-relacionamento (ER) Modelo conceitual é representado graficamente através de Diagrama EntidadeRelacionamento (DER) Prof. Rogério Bittencourt Diagrama EntidadeRelacionamento preço Produto descrição código Prof. Rogério Bittencourt descrição n 1 Tipo de Produto código Modelo Lógico Nível de abstração visto pelo usuário do SGBD Depende do tipo particular de SGBD que está sendo usado Descrição dos dados nos níveis conceitual e de visões de usuários O banco de dados é estruturado em registros de formatos fixos, de diversos tipos Cada tipo de registro tem sua coleção de atributos Há linguagens para expressar consultas e atualizações no banco de dados Prof. Rogério Bittencourt Modelo Lógico Abordagens Tipos de abordagem: Navegacional: caminhos de acesso explícitos Modelo de dados em árvore 1. Abordagem hierárquica (histórica) 2. Abordagem XML Modelo de dados em grafo 1. Abordagem em rede (histórica) 2. Abordagem orientada a objetos Associativa: sem caminhos de acesso explícitos Abordagem relacional Prof. Rogério Bittencourt Histórico das Abordagens Desde o fim da década de 1960, diversos SGBD comerciais foram construídos. Algumas abordagens estabeleceram-se na prática. Abordagem Hierárquica Origem: SGBD da IBM (IMS) Largamente utilizado durante as décadas de 1970 e início da década de 1980 Abordagem em Rede Grande família de SGBD baseados em um padrão ANSI Originário do IDMS (BF Goodrich, depois Culinane) Exemplos: IDMS, IDS/2 Década de 1970 Prof. Rogério Bittencourt Histórico das Abordagens Abordagem Relacional Embasamento teórico: trabalhos de Codd (IBM) procurando um modelo lógico independente de detalhes de implementação Década de 1970: pesquisa e construção de diversos protótipos. Os mais importantes são: System R (IBM), precursor do DB2 INGRES (Stonebraker, Universidade da Califórnia), precursor do produto comercial de mesmo nome e do PostgreSQL Década de 1980: surgimento de produtos comerciais DB2, Oracle, Informix, Sybase (SQL/Server) Domínio do mercado Padrão ISO Prof. Rogério Bittencourt Histórico das Abordagens Abordagem Orientada a Objetos Abordagem relacional não é completamente adequada para programação orientada a objetos Década de 1990: surgimento de SGBD orientados a objetos O2, Gemstone, ObjectStore, Jasmine, ... Padrão ODMG Modelo de dados semelhante ao modelo em rede Abordagem XML Abordagem voltada para o intercâmbio de dados e representação de documentos Não foi concebida para armazenamento (exceção: SGBD Tamino) Final da década de 1990: Padrão W3C Modelo de dados semelhante ao modelo hierárquico Prof. Rogério Bittencourt Comparação entre Abordagens Aspectos Comparação da estrutura de dados Construções que compõe uma base de dados na abordagem Comparação das instruções de acesso a dados DML fictícia mínima destinada apenas a comparar as abordagens DML opera registro-a-registro (não há operações que tratam conjuntos de dados) Comparação das instruções de alteração Será verificado como alterações são implementadas em cada modelo lógico Comparação da independência de dados Prof. Rogério Bittencourt Exemplo Utilizado Informações armazenadas: Para cada peça: código, nome, cor, peso e cidade em que se encontra Para cada fornecedor: código, nome, status e cidade Para cada embarque: fornecedor que fez o embarque, peça embarcada, quantidade embarcada Operações consideradas: Buscar os nomes dos produtos embarcados por um fornecedor de código dado. Buscar os nomes dos fornecedores que embarcaram um produto de código dado. Incluir um produto e um fornecedor Excluir um produto e um fornecedor Alterar os nome de um produto e o nome de um fornecedor Prof. Rogério Bittencourt Abordagem Hierárquica Importância: IBM teve IMS (DL/1), largamente utilizado durante a década de 70 e início da década de 80 Própria IBM adaptou o IMS para modelo semelhante a rede Poucos produtos além de IMS Ainda aparece em sistemas legados Prof. Rogério Bittencourt Abordagem Hierárquica Estrutura de Dados Um BD hierárquico é uma floresta composta de árvores de registros Há dois tipos básicos de construção registro (chamado segmento em IMS) ligação pai-filho entre os registros Restrição: um determinado registro somente pode possuir um registro pai Prof. Rogério Bittencourt Abordagem Hierárquica Esquema Gráfico Peça CodPeça NomePeça CorPeça PesoPeça CidadePeça definição de tipo de relação “pai-filho” Fornec CodFornec NomeFornec StatusFornec CidadeFornec QtdeEmbarc definição de tipo registro Prof. Rogério Bittencourt Abordagem Hierárquica Um estado da base de dados IMS Peça P1 Eixo Cinza 10 PoA Fornec F3 Álvares F2 Souza F1 Silva 5 10 5 São Paulo 200 Rio 400 São Paulo 300 Peça P2 Rolamento Preto 16 Rio Fornec F4 Tavares F1 Silva 8 5 Rio 350 São Paulo 300 Peça P3 Prof. Rogério Bittencourt Mancal Verde 30 São Paulo Abordagem Hierárquica Instruções de Acesso a Dados get next root <record name> [where <select criteria>] Esta instrução busca um registro raiz que obedece a determinado critério com base em valores de seus campos get next child <record name> [where <select criteria>] Esta instrução busca um registro que: 1. é filho do registro corrente 2. obedece a determinado critério Prof. Rogério Bittencourt Abordagem Hierárquica Exemplo de Acesso a Dados Consulta 1 Buscar os nomes dos fornecedores que embarcaram o produto de código P2 get next root Peça where CodPeça='P2'; do until no more Fornec under this; get next child Fornec; print NomeFornec; end; Prof. Rogério Bittencourt Abordagem Hierárquica Exemplo de Acesso a Dados Consulta 2 Buscar os nomes das peças embarcadas pelo fornecedor F1 do until no more Peça; get next get next where if found end; Prof. Rogério Bittencourt root Peça; child Fornec CodFornec = 'F1'; then print NomePeça; Abordagem Hierárquica Assimetria na abordagem IMS O problema das peças e fornecedores é simétrico. A abordagem IMS força uma assimetria inexistente na realidade modelada. O modelador tem que escolher um tipo de registro pai com base em considerações de performance. Consultas simétricas são resolvidas de forma diferente. Somente problemas hierárquicos são modelados adequadamente na abordagem hierárquica. Prof. Rogério Bittencourt Abordagem Hierárquica Operações de modificação da base de dados - Inclusão Incluir um novo fornecedor (sem embarques) criar um registro “fantasma” de peça Anomalia de inclusão Uma operação que do ponto de vista da realidade modelada inclui um único objeto é implementada na base de dados pela inclusão de múltiplos objetos É conseqüência da redundância de dados Prof. Rogério Bittencourt Abordagem Hierárquica Operações de modificação da base de dados - Exclusão Anomalia de exclusão A exclusão do último embarque de um fornecedor implica na exclusão de seus dados A exclusão da única peça fornecida por um fornecedor implica na exclusão de seus dados Para resolver o problema, fornecedores sem embarques teriam que ser movidos para baixo de um registro fantasma Prof. Rogério Bittencourt Abordagem Hierárquica Operações de modificação da base de dados - Alteração Anomalia de alteração A alteração de um campo de um fornecedor implica em busca em toda base de dados Prof. Rogério Bittencourt Abordagem Hierárquica Análise da Abordagem Adequada somente para problemas hierárquicos Em caso de problemas não hierárquicos cria: Redundância de dados Resulta em anomalias de atualização ("update anomalies") nas instruções de modificação da base de dados Assimetrias indesejáveis na representação de dados e na programação Porque abordagem hierárquica foi usada? Performance Modelava a idéia de armazenar contiguamente um registro pai e seus vários filhos IBM fez cedo uma reforma introduzindo o conceito de pai-filho lógico Permitia estabelecer relações entre diferentes árvores e de fato implementar o modelo em rede (ver adiante) Prof. Rogério Bittencourt Abordagem XML Padrão W3C: Intercâmbio de documentos Representação de conteúdo de documentos (separar apresentação de conteúdo) Em evolução Modelo de dados em árvore, semelhante hierárquico Como modelo de dados de SGBD, mesmos problemas Prof. Rogério Bittencourt Abordagem XML Estrutura de Dados Banco de dados é um documento XML Documento XML é composto de um elemento raiz Elemento raiz pode ser composto por outros elementos e assim recursivamente Estrutura em árvores Prof. Rogério Bittencourt Abordagem XML Exemplo de Documento <pecas> <peca> <codpeca>P1</codpeca> <nomepeca>Eixo</nomepeca> <corpeca>Cinza</corpeca> <pesopeca>10</pesopeca> <cidadepeca>PoA</cidadepeca> <embarques> <fornec> <codfornec>F1</codfornec> ... </fornec> <fornec> <codfornec>F2</codfornec> ... </fornec> </embarques> </peca> ... </pecas> Prof. Rogério Bittencourt Abordagem XML Assimetria das Consultas Modelo em rede implica em assimetria de consultas Exemplos em Xpath (linguagem para referenciar partes de um documento - faz parte do padrão XML) Consulta 1 Buscar os nomes dos fornecedores que embarcaram o produto de código P2 /pecas/peca[codpeca="P2"]/embarques/fornec/nomefornec Consulta 2 Buscar os nomes das peças embarcadas pelo fornecedor F1: /pecas/peca[embarques/fornec[codfornec="F1"]]/nomepeca Prof. Rogério Bittencourt Abordagem em Rede Grande família de SGBDs baseada em um padrão estabelecido na década de 70 Padrão CODASYL/DBTG Tentativa de padronizar modelos de dados de SGBD Precursores foram sistemas de gerência de arquivos em listas encadeadas como TOTAL Originário do IDMS (BF Goodrich, depois Culinane) Depois adotado por muitos fornecedores de Hardware Prof. Rogério Bittencourt Abordagem em Rede Estrutura de Dados BD em rede é um grafo nós = registros arcos = ligações entre registros Há dois tipos básicos de construção registro (“record type”) ligação pai-filho entre os registros (“set type”) Não há a restrição da abordagem hierárquica: um determinado registro pode possuir diversos registros pai. A única restrição é que, em um tipo de ligação, um registro somente pode participar uma vez Prof. Rogério Bittencourt Abordagem em Rede Esquema Gráfico Peça CodPeça NomePeça CorPeça PesoPeça CidadePeça Peça-Embarq Embarq Fornec QtdeEmbarc definição de tipo de relação “pai-filho” Fornec-Embarq CodFornec NomeFornec StatusFornec CidadeFornec definição de tipo registro Prof. Rogério Bittencourt Abordagem em Rede Conteúdo da base de dados Prof. Rogério Bittencourt Abordagem em Rede Instruções de Acesso a Dados Na abordagem de rede são necessárias duas instruções de acesso a dados semelhantes às da abordagem hierárquica: get next <record name> where <select criteria> Esta instrução busca um registro de um tipo (<record name>) que obedece a determinado critério (<select criteria>) com base em valores de seus campos Não está restrita a registros raiz get next child <record name> via <set name> where <select criteria> Esta instrução busca um registro de um tipo (<record name>) que obedece a determinado critério (<select criteria>) e que é filho do registro corrente dentro da ligação (<set name>) indicada. Na abordagem de rede são necessárias duas instruções de acesso a dados semelhantes às da abordagem hierárquica: Prof. Rogério Bittencourt Abordagem em Rede Instruções de Acesso a Dados Adicionalmente, aparece uma instrução própria da abordagem em rede para buscar um registro pai (<record name>1) de um filho em uma cadeia dada (<set name>) get parent <record name>1 via <set name> Prof. Rogério Bittencourt Abordagem em Rede Exemplo de Acesso a Dados Consulta 1 Buscar os nomes dos fornecedores que embarcaram o produto de código P2 get next Peça where CodPeça='P2'; do until no more Embarq under this in Peça-Embarq; get next child Embarq via Peça-Embarq; get parent Fornec via Fornec-Embarq; print NomeFornec; end; Prof. Rogério Bittencourt Abordagem em Rede Exemplo de Acesso a Dados Consulta 2 Buscar os nomes das peças embarcadas pelo fornecedor F1 get next Fornec where CodFornec='F1'; do until no more Embarq under this in Fornec-Embarq; get next child Embarq via Fornec-Embarq; get parent Peça via Peça-Embarq; print NomePeça; end; Prof. Rogério Bittencourt Abordagem em Rede Assimetria na abordagem O problema das peças e fornecedores que é simétrico do ponto de vista da realidade implementada ➔ tratado de forma simétrica na abordagem em rede A abordagem em rede modela o problema e as consultas simetricamente. Prof. Rogério Bittencourt Abordagem em Rede Operações de modificação da base de dados Na abordagem em rede, não aparecem as anomalias de alteração que podem aparecer na abordagem hierárquica Para incluir um novo fornecedor (sem embarques) é necessário criar apenas um registro de fornecedor A exclusão do último embarque de um fornecedor não implica na exclusão de seu registro A exclusão de uma peça não implica na exclusão de seus fornecedores (apenas de seus embarques) A alteração de um campo de um fornecedor implica em alteração de um registro somente Na abordagem em rede, não aparecem as anomalias de alteração que podem aparecer na abordagem hierárquica Prof. Rogério Bittencourt Análise das Abordagens com Caminhos de Acesso Explícitos Todas abordagens mostradas tem caminhos de acesso explícitos Significa: programador inclui referências explícitas a caminhos de acesso dentro do código das consultas São chamadas de abordagens navegacionais Independência de dados fica prejudicada: criação/eliminação de ligações implica em alteração do código das consultas Solução proposta: Não permitir que o programador faça referência a caminhos de acesso Abordagem associativa Base do desenvolvimento da abordagem relacional Prof. Rogério Bittencourt Abordagem Relacional Prof. Rogério Bittencourt Abordagem Relacional Tanto os dados quanto os relacionamentos são representados por tabelas. Possui fundamento matemático sólido. Prescinde de estruturas de índice eficientes e hardware adequado para alcançar desempenho viável em situações práticas. Prof. Rogério Bittencourt Abordagem Relacional TipoDeProduto (CodTipoProd, DescrTipoProd) Produto (CodProd, DescrProd, PrecoProd, CodTipoProd) CodTipoProd referencia TipoDeProduto Prof. Rogério Bittencourt Modelo Físico Contém detalhes de armazenamento interno de informações Detalhes que Não têm influência sobre a programação de aplicações no SGBD Influenciam a performance das aplicações Usado por profissionais que fazem a sintonia (tunning) de performance de BD Prof. Rogério Bittencourt Arquitetura de SGBD Nível Interno Mais próximo do armazenamento físico, isto é, relaciona-se com a forma como os dados são armazenados. Emprega-se o Modelo de Dados Físico para descrever detalhes de armazenamento. Nível Conceitual Descreve a estrutura completa de um BD para uma comunidade de usuários. É uma descrição global do BD, que esconde detalhes da estrutura física de armazenamento. Pode-se empregar um modelo de alto nível (modelo conceitual) ou de implementação. Nível Externo Mais próximo dos usuários. É formado por um conjunto de visões de usuários ou esquemas externos. Cada visão descreve a parte do BD que um grupo de usuários está interessado. Pode ser empregado um modelo de alto nível (modelo conceitual) ou de implementação Prof. Rogério Bittencourt Arquitetura de SGBD Exemplo O exemplo mostra a visão conceitual de um simples banco de dados sobre funcionários. A visão interna correspondente e as duas visões externas correspondentes, uma para um usuário de PL/1 e outra para o usuário de COBOL. O exemplo é totalmente hipotético - não pretende simular qualquer sistema real - e muitos detalhes irrelevantes foram deliberadamente omitidos. Prof. Rogério Bittencourt Externo (PL/1) DCL 1 EMPP, 2 EMP # CHAR (6), 2 SAL FIXED BIN (31) Conceitual EMPLOYEE EMPLOYEE_NUMBER DEPARTAMENT_NUMBER SALARY Externo (COBOL) 01 EMPC. 02 EMPNO PIC X (6) 02 DEPTNO PIC X (4). CHARACTER (6) CHARACTER (4) NUMERIC (5) Interno STORED_EMP LENGTH = 118 PREFIX TYPE = BITE(6), OFFSET = O EMP# TYPE = BYTE(6), OFFSET = 6, INDEX = EMPX DEPT# TYPE = BYTE(4), OFFSET = 12 SAL TYPE = FULLWORD, OFFSET = 16 Arquitetura de SGBD Interpretação do Exemplo Externo (PL/1) DCL 1 EMPP, 2 EMP # CHAR (6), 2 SAL FIXED BIN (31) Conceitual EMPLOYEE EMPLOYEE_NUMBER DEPARTAMENT_NUMBER SALARY Externo (COBOL) 01 EMPC. 02 EMPNO PIC X (6) 02 DEPTNO PIC X (4). CHARACTER (6) CHARACTER (4) NUMERIC (5) Interno STORED_EMP LENGTH = 118 PREFIX TYPE = BITE(6), OFFSET = O EMP# TYPE = BYTE(6), OFFSET = 6, INDEX = EMPX DEPT# TYPE = BYTE(4), OFFSET = 12 SAL TYPE = FULLWORD, OFFSET = 16 Prof. Rogério Bittencourt banco de dados contém, no nível conceitual, informações referentes ao tipo de entidade chamada EMPLOYEE. Cada EMPLOYEE tem um EMPLOYEENUMBER (seis caracteres), um DEPARTMENT-NUMBER (quatro caracteres) e um SALARY (cinco dígitos decimais). Arquitetura de SGBD Interpretação do Exemplo Externo (PL/1) DCL 1 EMPP, 2 EMP # CHAR (6), 2 SAL FIXED BIN (31) Conceitual EMPLOYEE EMPLOYEE_NUMBER DEPARTAMENT_NUMBER SALARY Externo (COBOL) 01 EMPC. 02 EMPNO PIC X (6) 02 DEPTNO PIC X (4). CHARACTER (6) CHARACTER (4) NUMERIC (5) Interno STORED_EMP LENGTH = 118 PREFIX TYPE = BITE(6), OFFSET = O EMP# TYPE = BYTE(6), OFFSET = 6, INDEX = EMPX DEPT# TYPE = BYTE(4), OFFSET = 12 SAL TYPE = FULLWORD, OFFSET = 16 Prof. Rogério Bittencourt Os funcionários estão representados, no nível interno, por um tipo de registro armazenado chamado STORED-EMP, com dezoito bytes de comprimento. O STORED-EMP contém quatro tipos de campos armazenados: um prefixo de seis bytes (contendo, provavelmente, informações de controle como sinalizadores ou ponteiros), e três campos de dados correspondendo às três propriedades dos funcionários' Os registros STORED_FMP são, adicionalmente, indexados no CAMPO EMP por um índice chamado EMPX. Arquitetura de SGBD Interpretação do Exemplo Externo (PL/1) DCL 1 EMPP, 2 EMP # CHAR (6), 2 SAL FIXED BIN (31) Conceitual EMPLOYEE EMPLOYEE_NUMBER DEPARTAMENT_NUMBER SALARY O usuário de PL/1 tem uma visão externa do banco de dados, na qual cada funcionário é representado por um registro PL/I, contendo dois campos (os números de departamento não são do interesse deste usuário, e por isto foram omitidos da visão). O tipo de registro é definido por uma declaração comum de estrutura PL/I, de acordo com as regras Externo (COBOL) normais de PL/I. 01 EMPC. 02 EMPNO PIC X (6) 02 DEPTNO PIC X (4). CHARACTER (6) CHARACTER (4) NUMERIC (5) Interno STORED_EMP LENGTH = 118 PREFIX TYPE = BITE(6), OFFSET = O EMP# TYPE = BYTE(6), OFFSET = 6, INDEX = EMPX DEPT# TYPE = BYTE(4), OFFSET = 12 SAL TYPE = FULLWORD, OFFSET = 16 Prof. Rogério Bittencourt Arquitetura de SGBD Interpretação do Exemplo Externo (PL/1) DCL 1 EMPP, 2 EMP # CHAR (6), 2 SAL FIXED BIN (31) Conceitual EMPLOYEE EMPLOYEE_NUMBER DEPARTAMENT_NUMBER SALARY Externo (COBOL) 01 EMPC. 02 EMPNO PIC X (6) 02 DEPTNO PIC X (4). CHARACTER (6) CHARACTER (4) NUMERIC (5) Interno STORED_EMP LENGTH = 118 PREFIX TYPE = BITE(6), OFFSET = O EMP# TYPE = BYTE(6), OFFSET = 6, INDEX = EMPX DEPT# TYPE = BYTE(4), OFFSET = 12 SAL TYPE = FULLWORD, OFFSET = 16 Prof. Rogério Bittencourt Do mesmo modo, o usuário de COBOL tem uma visão externa, na qual cada funcionário é representado por um registro COBOL, contendo, novamente, dois campos (desta vez foi omitido o de salário). O tipo de registro é definido por um registro comum COBOL, de acordo com as regras normais do COBOL. Linguagens de SGBD's DDL = Data Definition Language - Linguagem de definição de dados, possibilita a definição ou descrição dos objetos do BD. DML = Data Manipulation Language - Linguagem de manipulação de dados, que suporta manipulação (acesso e alteração. DCL = Data Control Language – Linguagem de controle de segurança e acesso, que possibilita a definição de usuários. Prof. Rogério Bittencourt Tipos de DML's DML’s podem ser: procedurais - o usuário tem que especificar o que deseja e como pretende obter isso. Recuperam registros individuais do BD e processam cada registro separadamente. (devem ser embutidas em LPG’s) não procedurais - são capazes de expressar operações complexas de maneira concisa. O usuário especifica apenas o que deseja, e permite que o sistema decida como obter isso. (pode ser embutida em uma LPG de propósito geral) Prof. Rogério Bittencourt Níveis de Abstração O sistema de bancos de dados deve prover uma visão abstrata de dados para os usuários. A abstração se dá em três níveis: Nível de visão dos usuários Nível do conjunto de usuários Nível de armazenamento Prof. Rogério Bittencourt Independência de Dados Níveis de Abstração Nível Físico nível mais baixo de abstração, descreve como os dados estão realmente armazenados. Complexas estruturas de dados de baixo nível são descritas em detalhes. Nível Conceitual descreve quais dados estão armazenados de fato no BD e as relações que existem entre eles. Aqui o BD inteiro é descrito em termos de um pequeno número de estruturas relativamente simples. Nível Visual o mais alto nível de abstração descreve apenas parte do BD, de acordo com a necessidade de cada usuário. Apesar do uso de estruturas mais simples do que no nível conceitual, alguma complexidade perdura devido ao grande tamanho do BD. Prof. Rogério Bittencourt Independência de Dados visão 1 ... visão 2 Nível Conceitu al Nível Físico Prof. Rogério Bittencourt visão n Independência de Dados A habilidade de modificar a definição de um esquema em um nível sem afetar a definição de esquema num nível mais alto é chamada de independência de dados. Independência física de dados é a habilidade de modificar o esquema físico sem a necessidade de rescrever os programas aplicativos. As modificações no nível físico são ocasionalmente necessárias para aprimorar o desempenho. Independência lógica de dados é a habilidade de modificar o esquema conceitual sem a necessidade de rescrever os programas aplicativos. As modificações no nível conceitual são necessárias quando a estrutura lógica do BD é alterada. Prof. Rogério Bittencourt Estrutura Geral de um Sistema de Banco de Dados Usuários Ingênuos Interfaces do aplicativo Programadores de aplicativos Usuários sofisticados Programas aplicativos Consulta Pré-compilador da linguagem de manipulação de dados Processador de consultas Código objeto de programas aplicativos Esquema de bancos de dados Compilador de linguagem de definição de dados Gerenciador de banco de dados SGDB Gerenciador de arquivos DISCO Prof. Rogério Bittencourt Administrador de banco de dados Arquivos de dados Dicionários de dados