Introdução a Teoria de Banco de Dados Prof. Rogério Gonçalves Bittencourt, M.Sc.

Transcrição

1 Introdução a Teoria de Banco de Dados Prof. Rogério Gonçalves Bittencourt, M.Sc.

2 Literatura Recomendada BATINI, C.; CERI, S.; NAVATHE, S. B.: Conceptual database desing. Benjamin/Cummings Publ. Co., Redwood City, ELMASRI, R.; NAVATHE, S.B.: Fundamentals of database systems. Addison- Wesley. 3Ed. Reprinted June ULLMAN, J. D. & WIDON, J.: A first course in database systems. Prentice-Hall, Inc RAMAKRISHNAN, R.: Database management systems. McGraw-Hill HEUSER, C. A.: Projeto de banco de dados. 3Ed. Sagra-Luzzatto, Porto Alegre DATE, C. J.: Introdução a sistemas de bancos de dados. Ed. Campus, Rio de Janeiro, 6ª Edição, KORTH. H. F.; SILBERSCHATZ, A.: Sistemas de bancos de dados. McGraw- Hill, São Paulo, 1994.

3 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.

4 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?

5 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... Produtos... Produtos...

6 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)

7 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

8 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...

9 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)

10 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...

11 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

12 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

13 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)

14 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

15 Sistemas de Gerência de Banco de Dados O 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.

16 Componentes de SBD

17 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).

18 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

19 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

20 Modelos de Dados Modelo de (Banco de) Dados Descrição formal dos tipos de dados que estão armazenados em um Banco de Dados

21 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

22 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

23 Modelos de Dados Níveis de Abstração Modelo Conceitual Abstração Modelo Lógico Modelo Físico

24 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

25 Modelo Conceitual ER Técnica mais difundida de modelagem conceitual Abordagem entidade-relacionamento (ER) Modelo conceitual é representado graficamente através de Diagrama Entidade- Relacionamento (DER)

26 Diagrama Entidade- Relacionamento preço descrição Produto n 1 Tipo de Produto código descrição código

27 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

28 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

29 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

30 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

31 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

32 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

33 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

34 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

35 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

36 Abordagem Hierárquica Esquema Gráfico Peça CodPeça NomePeça CorPeça PesoPeça CidadePeça Fornec definição de tipo de relação pai-filho CodFornec NomeFornec StatusFornec CidadeFornec QtdeEmbarc definição de tipo registro

37 Abordagem Hierárquica Um estado da base de dados IMS Fornec Peça P1 Eixo Cinza 10 PoA F3 Álvares 5 São Paulo 200 F2 Souza 10 Rio 400 F1 Silva 5 São Paulo 300 Fornec Peça P2 Rolamento Preto 16 Rio F4 Tavares 8 Rio 350 F1 Silva 5 São Paulo 300 Peça P3 Mancal Verde 30 São Paulo

38 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

39 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;

40 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; end; get next root Peça; get next child Fornec where CodFornec = 'F1'; if found then print NomePeça;

41 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.

42 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

43 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

44 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

45 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)

46 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

47 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

48 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>

49 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

50 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

51 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

52 Abordagem em Rede Esquema Gráfico Peça CodPeça NomePeça CorPeça PesoPeça CidadePeça Peça-Embarq Embarq QtdeEmbarc definição de tipo de relação pai-filho Fornec Fornec-Embarq CodFornec NomeFornec StatusFornec CidadeFornec definição de tipo registro

53 Abordagem em Rede Conteúdo da base de dados

54 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:

55 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>

56 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;

57 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;

58 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.

59 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

60 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

61 Abordagem Relacional

62 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.

63 Abordagem Relacional TipoDeProduto (CodTipoProd( CodTipoProd,, DescrTipoProd) Produto (CodProd( CodProd,, DescrProd, PrecoProd, CodTipoProd) CodTipoProd referencia TipoDeProduto

64 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

65 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

66 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. Externo (PL/1) Externo (COBOL) DCL 1 EMPP, 01 EMPC. 2 EMP # CHAR (6), 02 EMPNO PIC X (6) 2 SAL FIXED BIN (31) 02 DEPTNO PIC X (4). Conceitual EMPLOYEE EMPLOYEE_NUMBER CHARACTER (6) DEPARTAMENT_NUMBER CHARACTER (4) SALARY 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

67 Arquitetura de SGBD Interpretação do Exemplo Externo (PL/1) Externo (COBOL) DCL 1 EMPP, 01 EMPC. 2 EMP # CHAR (6), 02 EMPNO PIC X (6) 2 SAL FIXED BIN (31) 02 DEPTNO PIC X (4). banco de dados contém, no nível conceitual, informações referentes ao tipo de entidade chamada EMPLOYEE. Cada EMPLOYEE tem um EMPLOYEE- NUMBER (seis caracteres), um DEPARTMENT-NUMBER (quatro caracteres) e um SALARY (cinco dígitos decimais). Conceitual EMPLOYEE EMPLOYEE_NUMBER CHARACTER (6) DEPARTAMENT_NUMBER CHARACTER (4) SALARY 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

68 Arquitetura de SGBD Interpretação do Exemplo Externo (PL/1) Externo (COBOL) DCL 1 EMPP, 01 EMPC. 2 EMP # CHAR (6), 02 EMPNO PIC X (6) 2 SAL FIXED BIN (31) 02 DEPTNO PIC X (4). Conceitual EMPLOYEE EMPLOYEE_NUMBER CHARACTER (6) DEPARTAMENT_NUMBER CHARACTER (4) SALARY 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 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.

69 Arquitetura de SGBD Interpretação do Exemplo Externo (PL/1) Externo (COBOL) DCL 1 EMPP, 01 EMPC. 2 EMP # CHAR (6), 02 EMPNO PIC X (6) 2 SAL FIXED BIN (31) 02 DEPTNO PIC X (4). Conceitual EMPLOYEE EMPLOYEE_NUMBER CHARACTER (6) DEPARTAMENT_NUMBER CHARACTER (4) SALARY 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 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 normais de PL/I.

70 Arquitetura de SGBD Interpretação do Exemplo Externo (PL/1) Externo (COBOL) DCL 1 EMPP, 01 EMPC. 2 EMP # CHAR (6), 02 EMPNO PIC X (6) 2 SAL FIXED BIN (31) 02 DEPTNO PIC X (4). 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. Conceitual EMPLOYEE EMPLOYEE_NUMBER CHARACTER (6) DEPARTAMENT_NUMBER CHARACTER (4) SALARY 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

71 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.

72 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)

73 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

74 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. Prof. Rogério Bittencourt 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.

75 Independência de Dados... visão 1 visão 2 visão n Nível Conceitu al Nível Físico

76 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.

77 Estrutura Geral de um Sistema de Banco de Dados Usuários Ingênuos Programadores de aplicativos Usuários sofisticados Administrador de banco de dados Interfaces do aplicativo Programas aplicativos Consulta Esquema de bancos de dados Pré-compilador da linguagem de manipulação de dados Processador de consultas Compilador de linguagem de definição de dados Código objeto de programas aplicativos Gerenciador de banco de dados SGDB Gerenciador de arquivos DISCO Arquivos de dados Dicionários de dados