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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)

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)

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

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

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

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

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

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?

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.

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

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

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

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

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

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

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

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

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

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

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)

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

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

Idéias Modelo E/R Modelo Relacional SGBD Relacional

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

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

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

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)

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

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

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

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

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

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

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

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)

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.

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

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