SCC Bancos de Dados e Suas Aplicações

Apresentação em tema: "SCC Bancos de Dados e Suas Aplicações"— Transcrição da apresentação:

1 SCC0141 - Bancos de Dados e Suas Aplicações
Prof. Jose Fernando Rodrigues Junior Material original: Elaine Parros Machado de Sousa Sistemas de Banco de Dados

2 Tópicos da Aula Evolução dos Sistemas de Banco de Dados
arquiteturas cliente/servidor Desenvolvimento de Sistemas de Banco de Dados Three-Schema Architecture Ciclo de Vida Modelagem de Dados

3 Tópicos da Aula Evolução dos Sistemas de Banco de Dados
arquiteturas cliente/servidor Desenvolvimento de Sistemas de Banco de Dados Three-Schema Architecture Ciclo de Vida Modelagem de Dados

4 Evolução dos Sistemas de Bases de Dados
Computadores pessoais mais rápidos e baratos – terminais substituídos por PCs – interface de sistemas centralizados adaptadas para PCs – sistemas centralizados agem como servidores... USP – ICMC - GBDI

5 Evolução dos Sistemas de Bases de Dados
Os programas de aplicação são executados no servidor de dados – os terminais “burros” executam quase nenhum processamento. Computadores pessoais mais rápidos e baratos – terminais substituídos por PCs – interface de sistemas centralizados adaptadas para PCs – sistemas centralizados agem como servidores... USP – ICMC - GBDI

6 Evolução dos Sistemas de Bases de Dados
PC USP – ICMC - GBDI

7 Evolução dos Sistemas de Bases de Dados
PCs mais potentes executam tanto o programa de aplicação quanto o SGBD. O servidor de arquivos provê espaço de armazenamento, escasso à época. PC USP – ICMC - GBDI

8 Evolução dos Sistemas de Bases de Dados
USP – ICMC - GBDI

9 Arquitetura Cliente/Servidor
Aplicações Dados e Regras SGBD Servidor Cliente Servidor – SGBD e funcionalidades básicas Cliente – aplicações executadas em cima do SGBD – Escritas por usuários ou Built-in (ferramentas - fornecidas pelo fabricante ou terceiros- ex: gerador de relatórios) USP – ICMC - GBDI

10 Arquitetura Cliente/Servidor
Duas camadas Dados e Regras Aplicações SGBD Maior parte do código de aplicação fica no cliente, que acessa o servidor de banco de dados (que por sua vez é compartilhado com outros clientes). Problema: Fat Client: muitas requisições e downloads de dados para executar operações de lógica do negócio – ineficiente – rede muito carregada. Cliente pode ficar sobrecarregado e a performance da aplicação depende muito do sistema (hardware/software) onde roda o cliente Servidor Cliente BD + parte (pequena) da lógica de negócio Interface + maior parte da lógica de negócio USP – ICMC - GBDI

11 Arquitetura Cliente/Servidor
Três camadas Aplicações-Cliente Servidor de Aplicação Dados e Regras SGBD Particionar a funcionalidade do sistema de banco de dados em 3 camadas: clientes (front-end) servidor de aplicação (domain servers ) SGBD (persistence servers - storage) Clientes: componentes únicos de cada usuário – componentes de lógica da aplicação específicas para cada tipo de usuário – interfaces específicas Servidor de aplicações: suporte multi-usuário - gerencia as partes comuns da lógica da aplicação e de negócio. Requer gerenciamento de transações, controle de concorrência e política de segurança. Boa parte da requisição de dados é feita via esta camada – desempenho SGBD: gerencia armazenamento e recuperação de informação, executa transações, realiza mapeamentos entre objetos da aplicação e tabelas do SGBD... Vantagens: pre-processamento no servidor de aplicações reduz tráfego na rede – aumento de performance boa parte da lógica e código do negócio fica isolada – alterações não afetam SGBD e clientes interface cliente servidor de aplicação independe da interface fornecida pelo fabricante do SGBD – programador faz como achar melhor integração de sistemas legados no servidor de aplicações Desvantagens: liberdade e flexibilidade – mais responsabilidade dos desenvolvedores – interfaces, consistência, segurança... Para melhorar estes problemas: usar padrões: ex: CORBA and CORBAservices from the Object Management Group Servidor Cliente BD + parte comum da lógica de negócio Interface + parte específica da lógica de negócio USP – ICMC - GBDI

12 Arquitetura Cliente/Servidor
Quatro camadas Servidor de Interface Aplicações-Cliente Servidor de Aplicação Dados e Regras SGBD Apresentação e interface: Servidor Web - páginas HTML, ASP, com APPLETS em JAVA, JAVA SCRIPTS, FLASH e códigos PHP, ou ainda outras ferramentas que possuam a capacidade de criar material para o Navegador. Vantagem: modificação da camada de apresentação não interfere nos clientes Desvantagens: dimensionamento Servidor Cliente USP – ICMC - GBDI

13 Tópicos da Aula Evolução dos Sistemas de Banco de Dados
arquiteturas cliente/servidor Desenvolvimento de Sistemas de Banco de Dados Three-Schema Architecture Ciclo de Vida Modelagem de Dados

14 SGBD Aplicação INSTÂNCIA ESQUEMA Definição da base de dados armazenada

15 Esquema e Instância Esquema Instância Banco de dados: Esquema
Definição Estático (ou quase!) Instância Manipulação Dinâmica Esquema Instância

16 Esquema pode ser definido em 3 níveis
Esquema e Instância Esquema pode ser definido em 3 níveis Three-Schema Architecture

17 Arquitetura Esquema de Três
Three-Schema Architecture (ou arquitetura ANSI/SPARC) múltiplas visões para os usuários armazenamento da descrição da base de dados (esquema) em diferentes níveis de abstração independência de dados Incorporação de características importantes da filosofia de bases de dados

18 Three-Schema Architecture
Nível Externo ou de Visão ... Visão 1 Visão 2 Visão N Sub-Esquemas (views) Esquema Conceitual e/ou Esquema Lógico Nível Conceitual ou Lógico Esquema Físico Nível Interno ou Físico

19 Three-Schema Architecture
Nível Interno – esquema físico descreve estrutura física de armazenamento da base de dados como os dados estão armazenados

20 Three-Schema Architecture
Nível Conceitual – esquema conceitual e/ou lógico descreve a estrutura da base de dados sem detalhes de estrutura de armazenamento físico quais dados estão armazenados e como estão relacionados descrição do esquema conceitual/lógico: modelo conceitual (ex: MER) modelo de implementação (ex: Modelo Relacional)

21 Three-Schema Architecture
Nível Externo – sub-esquemas define as visões dos usuários descreve a parte da base de dados em que cada grupo de usuários tem interesse descrição de sub-esquemas: modelo conceitual (ex: MER) modelo de implementação (ex: Modelo Relacional)

22 Three-Schema Architecture
... Nível Externo ou de Visão Visão 1 Visão 2 Visão N mapeamento externo/conceitual Nível Conceitual ou Lógico mapeamento conceitual/interno Nível Interno ou Físico

23 Three-Schema Architecture
Visualização de níveis de esquema em sistemas de banco de dados  ABSTRAÇÃO escondendo detalhes e complexidade nos diferentes níveis visão mais geral ou mais específica

24 Recordando.... Three-Schema Architecture (ou arquitetura ANSI/SPARC)
independência de dados múltiplas visões para os usuários armazenamento da descrição da base de dados (esquema) em diferentes níveis de abstração OK!!!! OK!!!!

25 Independência de Dados
Independência de dados na arquitetura de três esquemas  capacidade de modificar o esquema em determinado nível sem afetar o esquema do nível superior SGBD pode suportar: independência física independência lógica

26 Independência de Dados
... Nível Externo ou de Visão Visão 1 Visão 2 Visão N Nível Conceitual ou Lógico Independência Física??? Nível Interno ou Físico

27 Independência de Dados
Independência física de dados modificações no esquema interno não provocam alterações nos esquemas lógico e externo por que modificar esquema interno? quando os esquemas em níveis superiores teriam que ser alterados?

28 Independência de Dados
Independência física de dados modificações no esquema interno não provocam alterações nos esquemas lógico e externo por que modificar esquema interno? quando os esquemas em níveis superiores teriam que ser alterados? Modificações no nível interno – reorganização dos dados – ex: inserção de novos mecanismos de acesso, novos índices, mais espaço de armazenamento.

29 Independência de Dados
... Nível Externo ou de Visão Visão 1 Visão 2 Visão N Nível Conceitual ou Lógico Independência Lógica??? Nível Interno ou Físico

30 Independência de Dados
Independência lógica de dados modificações no esquema lógico não provocam alterações nos esquemas externos aplicativos não precisam ser reescritos por que modificar esquema lógico? quando os esquemas em níveis superiores teriam que ser alterados? alterações no esquema lógico: reorganização lógica - expandir ou reduzir a base de dados níveis superiores têm que ser alterados em caso de redução da base

31 Independência de Dados
Independência lógica de dados modificações no esquema lógico não provocam alterações nos esquemas externos aplicativos não precisam ser reescritos por que modificar esquema lógico? quando os esquemas em níveis superiores teriam que ser alterados? Modificações no nível conceitual – reestruturação lógica – ex.: novas tabelas, novos atributos, novas restrições de integridade  expansão. No cado de redução, níveis superiores talvez tenham que ser alterados. Ex.: exclusão de atributos, relacionamentos, ou restrições de integridade. alterações no esquema lógico: reorganização lógica - expandir ou reduzir a base de dados níveis superiores têm que ser alterados em caso de redução da base

32 Coleta/Especificação
Sistemas de Banco de Dados Ciclo de Vida Mundo Real Requisitos de Dados Coleta/Especificação de Requisitos Requisitos Funcionais Projeto Conceitual Análise Funcional Protótipo Projeto Lógico Projeto Projeto Físico Implementação SGBD Aplicação Dados e Metadados

33 Coleta/Especificação
Sistemas de Banco de Dados Desenvolvimento de Software Mundo Real Requisitos de Dados Coleta/Especificação de Requisitos Requisitos Funcionais Projeto Conceitual Análise Funcional Projetistas de Interface Protótipo Projeto Lógico Projeto DBA Pessoal de Suporte e Operação Projeto Físico Implementação Analistas de Sistemas Programadores Aplicação SGBD Dados e Metadados Usuários Operadores de Aplicação

34 Coleta/Especificação
Sistemas de Banco de Dados Desenvolvimento de Sistemas de Banco de Dados Ciclo de Vida Mundo Real Projetistas de BD Requisitos de Dados Coleta/Especificação de Requisitos Requisitos Funcionais Projeto Conceitual Análise Funcional Projetistas de Interface Protótipo Projeto Lógico Projeto DBA Pessoal de Suporte e Operação Projeto Físico Implementação SGBD Aplicação Dados e Metadados Usuários Operadores de Aplicação

35 Desenvolvimento de Sistemas de Banco de Dados [Elmasri]
Projeto conceitual esquema conceitual para a base de dados níveis conceitual/lógico e externo baseado nos requisitos de dados objetivos: estrutura da base de dados semântica relacionamentos restrições Entrada: requisitos Saída: modelo conceitual alto nível – descrição sucinta, clara, não ambígua, padronizada

36 Desenvolvimento de Sistemas de Banco de Dados [Elmasri]
Projeto conceitual (cont.) independente do SGBD pode incluir especificação em alto nível de: aplicações características funcionais das transações modelo conceitual – ex: MER Entrada: requisitos Saída: modelo conceitual alto nível – descrição sucinta, clara, não ambígua, padronizada

37 Desenvolvimento de Sistemas de Banco de Dados [Elmasri]
Projeto lógico esquema lógico níveis conceitual/lógico e externo mapeamento do modelo conceitual para o modelo do SGBD ex: Modelo Relacional

38 Desenvolvimento de Sistemas de Banco de Dados [Elmasri]
Projeto lógico (cont.) Passo1 – mapeamento independente de um SGBD específico mas... dependente do “paradigma” (relacional, OO, relacional-objeto) Passo 2 – ajustes de acordo com as características e restrições do modelo implementado por um SGBD específico

39 Desenvolvimento de Sistemas de Banco de Dados [Elmasri]
Projeto físico esquema físico nível interno estruturas físicas de armazenamento organização de registros físicos índices número de discos …. critérios: tempo de resposta espaço utilizado número de transações organização de registros: ex: clustering de registros relacionados em blocos do disco, hashing, ponteiros entre registros relacionados Critério: Tempo de resposta: tempo entre submeter uma transação e receber resposta. Fator controlado pelo SGBD: tempo de acesso ao item de dados. Fatores não controlados pelo SGBD: scheduling do sistema operacional, delays de comunicação... Espaço utilizado: dados, índices.... Número de transações por minuto: crítico para sistemas como banco ou reserva de passagens (muitas transações simultâneas)

40 Tópicos da Aula Evolução dos Sistemas de Banco de Dados
arquiteturas cliente/servidor Desenvolvimento de Sistemas de Banco de Dados Three-Schema Architecture Ciclo de Vida Modelagem de Dados

41 Modelagem de dados Os Três Reinos - Abstração
Real Imaginário Percepção Produto Sigla Nome-P Peso Verifica Padrão Empregado Código Idade Trabalha Peça Máquina Usina Composta por Nome-E Material Tempo Total de horas 1 N M Implementação Modelagem Representação

42 Idéias Modelo E/R Modelo Relacional SGBD Relacional

43 MER SQL - DDL DADOS SGBD Relacional Idéias Modelo E/R
Modelo Relacional SQL - DDL SGBD Relacional DADOS

44 Modelagem de Dados - Motivação
Por que modelar?? se projetistas se apóiam pouco em metodologias sistemáticas para conduzir o projeto da base de dados... então tempo e recursos são subestimados resultado não atende às necessidades das aplicações documentação é limitada manutenção custosa

45 Modelagem de Dados - Motivação
Por que modelar??? Se projeto é feito direto em termos de estruturas de armazenamento... Então considera limitações da estrutura escolhida; inclui “macetes” para bom desempenho e representação da informação; convívio com a inadequação da estrutura escolhida dificulta o diálogo com o usuário esquece-se o que é percepção da realidade e o que é necessidade de implementação

46 Modelos de Dados Modelo de dados – “definição abstrata, autônoma e lógica dos objetos, operadores e outros elementos que, juntos, constituem a máquina abstrata com a qual os usuários interagem”. (Date) objetos estrutura dos dados operadores comportamento dos dados Modelos conceitual e de implementação (ou lógico)

47 Modelos de Dados Modelos de dados (Elmasri) Conceituais
Modelo Entidade Relacionamento (MER) Modelo de Objetos da ODMG (Object Database and Open Source Vendors) …. de Implementação : Ex: Rede, Hierárquico, NO-SQL, Relacional

48 Modelos Conceituais Objetivo: Enfoque: Projeto Conceitual
descrição do conteúdo da base de dados NÃO considera estruturas de armazenamento Enfoque: compreensão e descrição da realidade (informação) compreensão e seleção das propriedades relevantes da informação compreensão e descrição das restrições sobre os dados diálogo com o usuário Projeto Conceitual

49 Coleta/Especificação
Sistemas de Banco de Dados Desenvolvimento de Sistemas de Banco de Dados Ciclo de Vida Mundo Real Requisitos de Dados Coleta/Especificação de Requisitos Requisitos Funcionais Projeto Conceitual Análise Funcional Projetistas de Interface Protótipo Projeto Lógico Projeto DBA Pessoal de Suporte e Operação Projeto Físico Implementação Projetistas de BD SGBD Aplicação Dados e Metadados Usuários Operadores de Aplicação

50 Modelagem Conceitual Entrada: Requisitos de Dados Processo:
modelagem – representação conceitual modelo conceitual (Ex: MER) Resultado: Esquema Conceitual descrição sucinta (diagramas e texto) clara, concisa, sem ambigüidades, sem contradições padronizada

51 Modelagem Conceitual – Exemplo usando MER:
Nome Cidade Idade N#USP nota N Disciplina É pré-requisito de Aluno N Matricula N 1 Sigla M Idade Nome Turma Composta por Grau N N#Cred Nome N#Funcional Código N N#Alunos Professor Ministra M livro

52 Modelagem Conceitual Ex: ….. SDM (Semantic Data Model) [McLeod-81]
SAM (Semantic Association Model) [Su-86] IFO [Abiteboul-87] ME-R (Modelo Entidade-Relacionamento) [Chen-76] Modelos Orientados a Objetos Object Model (ODMG), UML, OMT, OOAD, BOOCH …..

53 Modelos de Implementação
Modelo em Rede: dados representados por um conjunto de registros relações entre registros representadas por links registros organizados no BD por um conjunto de grafos

54 Modelos de Implementação
Modelo Hierárquico similar ao Modelo em Rede dados e relações representados por registros e links diferença: no Modelo Hierárquico os registros estão organizados em árvores Sistema IMS (Information Management System - IBM)

55 Modelos de Implementação
Modelo Relacional difere por não usar links relaciona os registros por meio de valores possibilidade do desenvolvimento de fundamentos matemáticos para sua definição Cálculo Relacional e Álgebra Relacional Precursor, Sistema R (IBM) 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.

56 Coleta/Especificação
Sistemas de Banco de Dados Desenvolvimento de Sistemas de Banco de Dados Ciclo de Vida Mundo Real Requisitos de Dados Coleta/Especificação de Requisitos Requisitos Funcionais Projeto Conceitual Análise Funcional Projetistas de Interface Protótipo Projeto Lógico Projeto DBA Pessoal de Suporte e Operação Projeto Físico Implementação Projetistas de BD SGBD Aplicação Dados e Metadados Usuários Operadores de Aplicação

57 Sugestão de leitura Capítulos introdutórios dos livros citados na bibliografia principal da disciplina USP – ICMC - GBDI