OTIMIZAÇÃO DE CONSULTAS EM SGBD RELACIONAL ESTUDO DE CASO

Tamanho: px
Começar a partir da página:

Download "OTIMIZAÇÃO DE CONSULTAS EM SGBD RELACIONAL ESTUDO DE CASO"

Transcrição

1 Mariana Gava º semestre OTIMIZAÇÃO DE CONSULTAS EM SGBD RELACIONAL ESTUDO DE CASO Dezembro de 2010 Itatiba / SP

2 ii Mariana Gava º semestre OTIMIZAÇÃO DE CONSULTAS EM SGBD RELACIONAL ESTUDO DE CASO Monografia apresentada à disciplina Trabalho de Conclusão de Curso, do Curso de Engenharia de Computação da Universidade São Francisco, sob a orientação do Profa. Rafaela Girotte Sampaio Maion, como exigência parcial para conclusão do curso de graduação. Dezembro de 2010 Itatiba / SP

3 iii AGRADECIMENTOS Agradeço primeiramente a Deus, por ter me concedido a oportunidade de poder ingressar numa universidade e chegar ao final desse curso, superando os obstáculos e desafios. A realização desta Monografia só foi possível graças a inúmeras pessoas, principalmente aos meus pais, que em todos os momentos souberam compreender e motivar-me durante toda a graduação para que mais essa etapa fosse vencida. Aos meus amigos, que sempre me deram apoio e entusiasmo nos momentos mais difíceis, dirigindome palavras de conforto. Aqui deixo um agradecimento especial a minha amiga Talita que me ajudou muito na leitura, revisão e formatação desse trabalho. Ao meu amigo Decinho que também revisou esse trabalho e me ajudou passando seus conhecimentos durante a sua realização. E a todos manifesto aqui a minha gratidão. E de modo particular me refiro à profª Rafaela G. Sampaio Maion pela sua tão importante orientação, dedicação e disposição constante em todos os momentos da realização deste trabalho, proporcionando-me grande estímulo e motivação para realização do mesmo. Agradeço também, aos professores do curso de Engenharia de Computação, alguns hoje nem mais presentes no corpo docente desta Universidade, porém foram de grande contribuição para o meu crescimento intelectual e pessoal. Enfim, a todas as pessoas que direta ou indiretamente compartilharam informações úteis que colaboraram para a elaboração deste trabalho.

4 iv GAVA, Mariana. Otimização de Consultas em SGBD Relacional Estudo de Caso f. Monografia Curso de Engenharia da Computação da Unidade Acadêmica da Área de Exatas da Universidade São Francisco, Itatiba. RESUMO Bancos de dados tornam-se cada dia mais importantes no cotidiano da sociedade atual. Durante as atividades diárias, pessoas deparam-se interações com algum banco de dados, embora na maioria das vezes sem ao menos perceberem tal feito. Pode-se afirmar que os bancos de dados são amplamente utilizados em diversas aplicações presentes no dia-a-dia, tais como: transações bancárias, transações com cartão de crédito, reservas de linhas aéreas e informações de horários, reservas de hotel, vendas, revendedores on-line, dentre outras aplicações. Devido ao grande volume de dados que estes precisam gerenciar e a complexidade de suas aplicações, é fundamental que as operações sejam realizadas de forma eficiente, pois o desempenho de um Sistema de Gerenciamento de Banco de Dados é medido a partir da sua eficiência na realização de consultas e alterações. Através de uma linguagem de manipulação de dados (DML) os dados são manipulados dentro do SGBD, sendo possível realizar diferentes funções como, consultas, atualizações e fornecer relatórios específicos. SGBDs têm como principal função proteger o banco de dados contra ataques maliciosos ou acessos não autorizados e também precisam garantir que não haja mau funcionamento ou falhas que podem ocorrer no hardware ou software. Outra função importante é quanto à manutenção dos dados. Bancos de dados precisam estar protegidos com relação a danos causados pelos usuários, quer sejam intencionais ou não. Visando a agilidade na consulta desses dados, o objetivo deste trabalho é analisar as técnicas de otimização e tuning de banco de dados, utilizando o banco de dados SQL SERVER 2008, pois a seleção de uma boa estratégia faz toda diferença e, em termos do tempo de avaliação, a diferença de custo pode chegar a várias ordens de grandeza. Palavras-chave: SGBD, TUNING, OTIMIZAÇÃO.

5 v ABSTRACT Databases become increasingly important in the daily lot of society today. During the daily activities, people are faced with some interaction with a database, although most often without even realizing it done. It can be stated that databases are widely used in various applications present on the day to day, such as: banking transactions, credit card transactions, airline reservations and information on schedules, hotel reservations, sales, online retailers, among other applications. Due to the large volume of data they need to manage complexity and its applications, it is essential that operations are carried out efficiently, because the performance of a Management System Database is measured from its efficiency in carrying out consultations and changes. Through a data manipulation language (DML) data are handled within the SGBD, and can perform different functions such as queries, updates, and provide specific reports. SGBDs have the main function to protect the database from malicious attacks or unauthorized access and must also ensure that no malfunctions or failures that may occur in hardware or software. Another important function is for the maintenance of the data. Databases must be protected against damage caused by users, whether intentional or not. Aiming to speed up the consultation of such data, the objective is to analyze the techniques of optimization and tuning database using the database SQL SERVER 2008, because the selection of a good strategy makes all the difference and in terms of time evaluation, the difference in cost can reach several orders of magnitude. Key Words: SGBD, TUNING, OPTIMIZATION

6 vi SUMÁRIO LISTA DE SIGLAS... viii LISTA DE FIGURAS... ix LISTA DE TABELAS... xi 1. INTRODUÇÃO Objetivos CONCEITOS GERAIS SOBRE BANCO DE DADOS STRUCTURED QUERY LANGUAGE SQL Definição de dados e tipos do SQL OTIMIZAÇÃO DE BANCO DE DADOS SQL SERVER Traduzindo consultas SQL para a álgebra relacional Utilização de heurísticas na otimização de consultas Otimização heurística de árvores de consulta Otimização baseada em custo Componentes do custo para execução de uma consulta Otimizando subconsultas aninhadas SINTONIZAÇÃO (TUNING) DE BANCO DE DADOS EM SISTEMAS RELACIONAIS Sintonização do projeto de banco de dados Sintonização de consultas Possíveis causas para o baixo desempenho Aumentando a perfomance da aplicação através da otimização de SQL ÍNDICES NO SQL SERVER Estruturas de índices clusterizados Estruturas de índices não clusterizados De que maneira o otimizador sabe quando utilizar os índices? Páginas e extends Unidade de alocação IN_ROW_DATA Unidade de alocação ROW_OVERFLOW_DATA Unidade de alocação LOB_DATA Sintonização de índices O PLANO DE EXECUÇÃO NO SQL SERVER O Otimizador de consulta Plano de execução estimado e plano de execução real Formato dos planos Interpretando planos de execução gráficos... 47

7 vii Facilitando a captura do plano de execução usando SQL SERVER Profiler Eventos do plano de execução Um pouco mais sobre planos gráficos ESTUDO DE CASO O SGBD Infraestrutura Aplicação da metodologia Base de dados Implementação das consultas Testes Teste 1 (subconsultas aninhadas comandos EXISTS e INNER JOIN) Teste 2 (Transformando expressões NOT em expressões afirmativas) Teste 3 (Usando ou não índices) ANÁLISE DOS RESULTADOS CONSIDERAÇÕES FINAIS REFERÊNCIAS BIBLIOGRÁFICAS... 78

8 viii LISTA DE SIGLAS ANSI American National Standards Institute BD Banco de Dados CLR Common Language Runtime CPU Central Processing Unit DBA Database Administrator DDL Linguagem de Definição de Dados DER Diagrama Entidade Relacionamento DML Linguagem de Manipulação de Dados GB Gigabyte GUI Graphical User Interface IAM Index Allocation Map ID Identifier ISO International Organization for Standardization I/O Input/Output KB Kilobyte MB Megabyte OLAP Online Analytical Processing RAM Random Access Memory SGBD Sistema de Gerenciamento de Banco de Dados SO Sistema Operacional SPID System Process Identifier SQL Structure Query Language XML Extensible Markup Language

9 ix LISTA DE FIGURAS Figura 6.1 Árvore B para um índice clusterizado. Figura 6.2 Árvore B para um índice não clusterizado. Figura 6.3 Árvore B padrão para um índice do SQL SERVER. Figura 7.1 Exemplo de texto estimado usando os comandos SET SHOWPLAN_ALL ON e SET SHOWPLAN_ALL OF. Figura 7.2 Exemplo de um plano de texto estimado usando os comandos SET SHOWPLAN_TEXT ON e SET SHOWPLAN_TEXT OFF. Figura 7.3 Exemplo de um plano de texto real usando os comandos SET STATISTICS_PROFILE ON e SET STATISTICS_PROFILE OFF. Figura 7.4 Exemplo de um plano XML estimado usando os comandos SET SHOWPLAN_XML e SET ON e SHOWPLAN_XML OFF. Figura 7.5 Exemplo de um plano de execução em XML. Figura 7.6 Exemplo de um plano de execução gráfico. Figura 7.7 Dados resultantes do ícone SELECT no plano de execução gráfico. Figura 7.8 Dados resultantes do ícone table scan. Figura 7.9 Exemplo de funcionamento do SQL profiler. Figura 7.10 Operador clustered index scan. Figura 7.11 Exemplo de consulta que retorna um clustered index scan. Figura 7.12 Operador clustered index seek Figura 7.13 Exemplo de consulta que retorna um clustered index seek Figura 7.14 Operador non clustered index seek. Figura 7.15 Exemplo de consulta que retorna um non clustered index seek. Figura 7.16 Operador key lookup. Figura 7.17 Exemplo de consulta que retorna um operador key lookup. Figura 7.18 Dados resultantes do operador non clustered index seek. Figura 7.19 Dados resultantes do operador key lookup. Figura 7.20 Operador nested loops. Figura 7.21 Operador sort. Figura 7.22 Operador table scan. Figura 7.23 Exemplo de consulta que retorna um table scan. Figura 7.24 Operador RID lookup. Figura 7.25 Exemplo de consulta que retorna um operador RID lookup. Figura 7.26 Operador merge join.

10 x Figura 7.27 Operador hash match. Figura 7.28 Exemplo de consulta que retorna os operadores merge join e hash match. Figura 8.1 Plano de execução gerado para o teste 1a. Figura 8.2 Plano de execução gerado para o teste 1b. Figura 8.3 Plano de execução gerado para o teste 2a. Figura 8.4 Plano de execução gerado para o teste 2b.

11 xi LISTA DE TABELAS Tabela 9.1 Resultados obtidos através dos Testes 1 e 2. Tabela 9.2 Resultados obtidos através do Teste 3.

12 12 1. INTRODUÇÃO Atualmente banco de dados tornou-se peça fundamental nas atividades diárias das pessoas. Muitas vezes nos deparamos com banco de dados nas nossas tarefas diárias e nem ao menos sabemos disso. Alguns exemplos são: transações bancárias, transações com cartão de créditos, reservas de passagens áreas, reserva de hotéis, compras on-line, dentro outras aplicações. Com o crescimento e o avanço tecnológico ao longo dos anos surgiram novas aplicações dos sistemas de banco de dados. É possível citar bancos de dados multimídia, que armazenam figuras, videoclipes e mensagens sonoras; bancos de dados geográficos, que armazenam e também são capazes de analisar mapas, dados do tempo e imagens de satélite; data warehouse e Online analytical processing (OLAP), que são utilizados em muitas empresas para auxiliar em tomada de decisões, devido à capacidade de extrair e analisar informações. Segundo uma das definições de Elmasri e Navathe, Um banco de dados é projetado, construído e povoado por dados, atendendo a uma proposta específica. Possui um grupo de usuários definido e algumas aplicações preconcebidas, de acordo com o interesse desse grupo de usuários. (2005, p.4) A complexidade e o tamanho de um banco de dados são variáveis. Eles também podem ser criados e mantidos manualmente ou então computadorizados através de um grupo de aplicações como um sistema gerenciador de banco de dados (SGBD). De acordo com Elmasri e Navathe (2005, p.4), Um SGBD é uma coleção de programas que permite aos usuários criar e manter um banco de dados. Sendo assim, um banco de dados é construído através de dados que são armazenados e assim são controlados por um SGBD. SGBDs têm como principal função proteger o banco de dados contra ataques maliciosos ou acessos não autorizados e também precisam garantir que não haja mau funcionamento ou falhas que podem ocorrer no hardware ou software. Outra função importante é quanto à manutenção dos dados. Bancos de dados precisam estar protegidos com relação aos danos causados pelos usuários, quer sejam intencionais ou não. O principal problema enfrentado com relação a esses sistemas é o grande volume de dados que estes precisam gerenciar e a complexidade de suas aplicações. Sendo assim, é

13 13 fundamental que as operações sejam realizadas de forma eficiente, pois o desempenho de um SGBD é medido a partir da sua eficiência na realização de consultas e alterações. Visando a agilidade na consulta desses dados, a otimização é um processo muito utilizado para a escolha da maneira mais adequada na realização de uma consulta, pois em geral, existem diferentes maneiras de realizá-la. Diante disso, é de extrema importância realizar o processo de otimização e tuning, pois a seleção de uma boa estratégia faz toda diferença e, em termos do tempo de avaliação, a diferença de custo pode chegar a várias ordens de grandeza. 1.1 Objetivos A elaboração deste trabalho tem como objetivo estudar as principais técnicas de otimização e tuning em um banco de dados SQL SERVER, o qual é muito utilizado em diversas aplicações, sendo de grande importância a escolha da solução mais adequada para agilizar no processo de consultas.

14 14 2. CONCEITOS GERAIS SOBRE BANCO DE DADOS Segundo Silberschatz, Um modelo de dados é uma coleção de ferramentas conceituais para descrever dados, relações de dados, semântica de dados e restrições de consistência. (2006, p.5). Existem três maneiras para se descrever um projeto de um banco de dados como no nível físico, lógico e de visão, que são divididos em quatro categorias diferentes de classificação de modelos: Modelo relacional: baseado em tabelas, que representam os dados e as relações entre eles. Cada tabela possui um nome único. É formado por uma estrutura de registros de tamanho fixo de vários tipos. Cada tipo de registro define a quantidade de número dos campos ou atributos. Devido a sua simplicidade conceitual, pois facilita o trabalho do programador, ainda hoje é o modelo mais utilizado. Modelo de entidade/relacionamento: consiste em uma coleção de objetos básicos, chamados de entidades e de relações entre eles. É um modelo muito útil no mapeamento para um esquema conceitual. Modelo de dados baseado em objetos: uma extensão do modelo de dados relacional, incluindo orientação a objetos e tipos de coleção que possuem relações, conjuntos, multiconjuntos e arrays. Modelo de dados semi-estruturado: possui características contrárias aos dos modelos acima citados, pois itens de dados individuais do mesmo tipo podem ter diferentes conjuntos de atributos. Um exemplo desse modelo é a Extensible Markup Language (XML). Como citado anteriormente, um banco de dados relacional é formado por uma coleção de tabelas, sendo que cada tabela possui um nome único. A relação entre um conjunto de valores é representada pela linha de uma tabela.

15 15 3. STRUCTURED QUERY LANGUAGE SQL De acordo com a definição de Silberschatz (2006, p.51), Embora a SQL seja referenciada como linguagem de consulta, ela pode fazer muito mais do que simplesmente consultar um banco de dados, pois ela consegue definir a estrutura dos dados, modificar dados no banco de dados e especificar restrições de segurança. No início da década de 1970, a IBM desenvolveu a versão original da SQL, a qual foi chamada de Sequel. Após anos de evolução, passou a ser chamada de SQL (Structure Query Language), tornando-se a linguagem padrão de banco de dados relacional. Em 1986, foi publicado um padrão SQL chamado de SQL-86 pelo American National Standards Institute (ANSI) e a International Organization for Standardization (ISO). Em 1989, o ANSI publicou o SQL-89 e depois surgiram as versões SQL-92 e SQL Atualmente a versão utilizada é o SQL A linguagem SQL possui várias partes: Linguagem de definição de dados (DDL): através da DDL é possível definir esquemas de relação, excluir relações e modificar esquemas. Inclui comandos para definir visões, especificar direitos de acesso para relações e visões e comandos para especificar restrições de integridade às quais os dados armazenados precisam satisfazer. Não é possível realizar atualizações que violam as restrições de integridade. Linguagem de manipulação de dados interativa (DML): inclui uma linguagem de consulta baseada na álgebra relacional e no cálculo relacional de tabela. Também possui comandos para inserir, excluir e modificar tabelas. Integridade: A DDL SQL inclui comandos para especificar restrições de integridade as quais os dados armazenados no banco de dados precisam satisfazer. As atualizações que violam as restrições de integridade são proibidas. Definição de view: A DDL SQL inclui comandos que definem as views. Controle de transação: SQL inclui comandos que especificam o início e o fim das transações.

16 16 SQL embutida e SQL dinâmica: definem como as instruções SQL podem ser incorporadas dentro das linguagens de programação. Autorização: A DDL inclui comandos que especificam direitos de acesso para relações e views. Devido ao fato de ter se tornado padrão para os bancos de dados relacionais, os usuários não têm tanta preocupação ao migrar suas aplicações para outros tipos de sistemas de banco de dados, como exemplo, em rede e hierárquico para sistema relacional. 3.1 Definição de dados e tipos do SQL A SQL usa os termos tabela, linha e coluna, ao invés de relação, tabela e atributo para o modelo relacional formal. De acordo com Elmasri e Navathe (2005), o principal comando SQL para definição de dados é o CREATE, que pode ser usado para criar esquemas, tabelas (relações) e domínios da mesma forma que outros construtores, como visões (views), asserções (assertions) e gatilhos (triggers). O padrão SQL SERVER 2008 aceita diversos tipos de domínio internos, como: Tipos numéricos: TINYINT: Faz o armazenamento de valores numéricos inteiros, variando de 0 a byte; SMALLINT: Faz o armazenamento de valores numéricos inteiros, variando de (-) à (+) bytes; INT: Faz o armazenamento de valores numéricos inteiros, variando de (-) à (+) bytes; BIGINT: Faz o armazenamento de valores numéricos inteiros, variando de (+) à (-) bytes;

17 17 SMALLMONEY: Armazena valores numéricos decimais variando de (-) à (+) bytes; MONEY: Armazena valores numéricos decimais variando de (-) à (+) bytes; NUMERIC(18,0): Valores numéricos com casas decimais com precisão. O primeiro número representa a quantidade de inteiros a serem armazenados e o segundo, indica a quantidade de casas decimais do número; DECIMAL(18,0): Possui as mesmas funcionalidades do tipo NUMERIC, com a diferença que o DECIMAL faz parte do padrão ANSI e NUMERIC é mantido por compatibilidade; FLOAT: Valores numéricos aproximados com precisão de ponto flutuante, variando de (-) 1.79E à (+) 1.79E ou 8 bytes; REAL: Valores numéricos aproximados com precisão de ponto flutuante, variando de (-) 3.40E + 38 à 3.40E bytes; Tipo BIT: BIT: Armazena bits, podendo conter valores lógicos 0 ou 1 1 bit; Tipo data: SMALLDATETIME: Faz o armazenamento de data e hora, com precisão de minutos 4 bytes; DATETIME: Também armazena data e hora, porém com precisão de centésimos de segundos 8 bytes; TIME: Armazena somente hora, podendo armazenar segundos até a fração de a 5 bytes; DATE: Somente data 3 bytes; DATETIME2: Combinação dos tipos de dados DATE e TIME, com a diferença para o tipo DATETIME é a precisão ao armazenar as horas 6 a 8 bytes;

18 18 DATETIMEOFFSET: Valores de data e hora com a combinação da hora do dia com o fuso horário. O intervalo de deslocamento do fuso horário é de (-)14:00 à (+) 14:00 8 a 10 bytes; Tipos caracteres: CHAR(N): Faz o armazenamento de N caracteres fixos (até 8.000) no formato não Unicode. Independente da quantidade de caracteres utilizados, sempre irá armazenar o tamanho de caracteres do campo, preenchendo o restante com espaços em branco; VARCHAR(N): Faz o armazenamento de N caracteres (até 8.000) no formato não Unicode; VARCHAR(MAX): Faz o armazenamento de caracteres no formato não Unicode. MAX indica que o máximo a ser armazenado pode chegar a 2^31-1 bytes; TEXT: Faz o armazenamento de caracteres no formato não Unicode. Esse tipo de dado suporte até caracteres e possui funções específicas para trabalhar com esse tipo de dado; NCHAR(N): Praticamente similar ao CHAR(N), com a diferença que armazena N caracteres fixos (até 4.000) no formato Unicode; NVARCHAR(N): Faz o armazenamento de (até 4.000) no formato Unicode; NVARCHAR(MAX): Faz o armazenamento de caracteres no formato Unicode. MAX indica que o máximo a ser armazenado pode chegar a 2^31-1 bytes; NTEXT: Faz o armazenamento de caracteres no formato Unicode. Esse tipo de dado suporte até caracteres e possui funções específicas para trabalhar com esse tipo de dado; Por padrão todo caracter ocupa um byte. Se considerarmos que um byte representa um octeto de oito bits e que cada bit tem duas possibilidades (ligado ou desligado), então um byte pode representar 256 possibilidades (2^8). No passado, 256 possibilidades eram suficientes para cobrir todo o conjunto de caracteres americano.

19 19 Outros tipos de dados: BINARY(N): Faz o armazenamento de dados no formato binário, podendo chegar até bytes. Independente da quantidade de dados armazenados, o restante do campo será preenchido com espaços em branco; VARBINARY(N): Faz o armazenamento de dados no formato binário, podendo chegar até bytes. É diferente do tipo BINARY porque não faz o preenchimento com espaços em branco. VARBINARY(MAX): Faz o armazenamento de dados no formato binário, podendo chegar até 2^31-1 bytes; IMAGE: Faz o armazenamento de dados no formato binário, podendo chegar até 2,147,483,647 bytes; SQL_VARIANT: Faz o armazenamento de todos os tipos de dados em um mesmo campo de uma tabela, com exceção dos tipos TEXT, NTEXT, TIMESTAMP e SQL_VARIANT até 8 K; TIMESTAMP: Permite a geração automática de um valor binário para um campo de uma tabela; UNIQUEIDENTIFIER: Utilizado para a criação de um identificador global e único para uma tabela do SQL SERVER armazena 16 bytes; GEOMETRY: Faz o armazenamento de dados espaciais utilizando representação plana da Terra (Flat Earth); GEOGRAPHY: Faz o armazenamento de dados espaciais utilizando representação redonda da Terra (Round Earth); HIERARCHYID: Usado para representar uma posição em uma hierarquia. Uma coluna não necessariamente irá representar automaticamente uma árvore. É até a aplicação para gerar e atribuir valores hierarchyid de tal forma que a relação desejada entre as linhas é refletida nos valores; XML: Faz o armazenamento de dados no formato XML, não podendo exceder a 2Gb;

20 20 4. OTIMIZAÇÃO DE BANCO DE DADOS SQL SERVER Segundo a definição de Silberschatz, otimização da consulta É o processo de selecionar o plano de avaliação de consulta mais eficiente dentre as muitas estratégias normalmente possíveis para o processamento de determinada consulta, especialmente se esta for complexa. (2006, p.383). Os usuários não têm obrigação de saber escrever a consulta para que a mesma seja processada de forma eficiente, mas o sistema deve construir um plano de avaliação para que o custo da avaliação da consulta seja reduzido. Além da busca ser realizada pelo sistema de uma maneira mais eficiente para executar uma consulta, através de uma expressão similar na álgebra relacional, outros aspectos também são observados tais como: algoritmos para execução de operações e também índices específicos que serão utilizados. O otimizador de consulta tem como tarefa gerar um plano de avaliação de consulta que terá como base uma expressão em álgebra relacional e a transformará numa expressão com menor custo. A geração de planos de avaliação envolve três etapas: 1. Definir expressões que sejam logicamente equivalentes a expressão dada; 2. Fazer uma estimativa do custo do plano de avaliação; 3. Realizar de forma alternativa anotações das expressões resultantes para gerar planos de avaliação de consulta alternativos; Primeiramente, as etapas 1 e 3 são realizadas, sendo as expressões geradas e anotadas aos poucos. E em segundo plano a etapa 2 é feita com a coleta de informações estatísticas sobre as relações para garantir uma boa estimativa do custo de um plano. De acordo com Silberschatz (2006, p.384), o otimizador de consulta gera expressões equivalentes a uma determinada expressão através de regras de equivalência que especificam como transformar uma expressão em outra logicamente equivalente. Existem diversas maneiras de uma consulta ser expressa, com diferentes custos de avaliação. É bom ressaltar que, a ordem das tabelas é irrelevante, desde que seja equivalente o conjunto de tabelas.

21 Traduzindo consultas SQL para a álgebra relacional Em primeiro lugar, uma consulta SQL é traduzida para uma expressão equivalente na álgebra relacional, sendo representada por uma estrutura de dados de árvore de consulta, que após é otimizada. Uma regra de equivalência diz que expressões de duas formas são equivalentes. É através delas que o otimizador transforma expressões em outras logicamente equivalentes. De acordo com Elmasri e Navathe (2005, p.356), As consultas SQL são decompostas em blocos de consultas, que formam as unidades básicas que podem ser traduzidas em operadores algébricos e otimizadas. Um bloco de consulta contém uma única expressão SELECT- FROM-WHERE, bem como cláusulas GROUP BY e HAVING, se elas forem partes do bloco. Sendo assim, consultas aninhadas dentro de uma consulta são identificadas como blocos separados Utilização de heurísticas na otimização de consultas As regras heurísticas são utilizadas para melhorar o desempenho das consultas, através da modificação da representação interna de uma consulta, que na maioria das vezes está na forma de dados de árvore de consulta ou de um grafo de consulta. Segundo Elmasri e Navathe, O analisador sintático de uma consulta de alto nível primeiro gera uma representação interna inicial, que depois é otimizada de acordo com as regras de heurística. (2005, p.368). Após, um plano de execução de consulta é gerado, e o mesmo tem como responsabilidade executar grupos de operações com base nos caminhos de acesso disponíveis para os arquivos envolvidos na consulta. Devido ao tamanho do arquivo resultante de uma operação binária, como JOIN, utilizam-se as operações SELECT e PROJECT antes do JOIN de operações binárias, pois essas operações reduzem o tamanho de um arquivo.

22 22 As regras de otimização heurísticas são aplicadas para converter uma árvore de consulta numa árvore de consulta equivalente, que representa uma expressão diferente da álgebra relacional e que é executada de forma mais eficiente, porém que produz o mesmo resultado. Elmasri e Navathe (2005, p. 368), definem que: Uma árvore de consulta é uma estrutura de dados de árvore que corresponde a uma expressão da álgebra relacional. Ela representa as relações de entrada de uma consulta como nós folhas da árvore e representa as operações da álgebra relacional como nós internos. Realiza-se a execução de uma operação de nó interno, se seus operandos estiverem disponíveis, e em seguida a substituição do nó interno pela relação que resulta da execução da operação, que é chamada de execução da árvore de consulta. Na árvore de consulta existe a necessidade de preservar uma ordem específica de operações para execução de uma consulta. Já uma representação mais neutra de uma consulta é notada de grafo de consulta, na qual não indica uma ordem na qual as operações devem ser realizadas e apenas um grafo corresponde a cada consulta. De acordo com Elmasri e Navathe (2005), embora algumas técnicas de otimização sejam baseadas em grafos de consulta, as árvores de consulta são preferíveis porque, na prática, o otimizador de consulta precisa mostrar a ordem das operações para a execução da consulta, o que não é possível em grafos de consulta Otimização heurística de árvores de consulta Devido ao fato de existirem muitas expressões diferentes na álgebra relacional, muitas árvores de consulta diferentes podem corresponder à mesma consulta. É criada uma árvore de consulta inicial, correspondente à consulta SQL, sem nenhuma otimização através do analisador sintático. É tarefa do otimizador heurístico de consulta transformar a árvore de consulta inicial em uma árvore de consulta final que seja eficiente. Incluem-se regras de equivalência entre as expressões da álgebra relacional, que são utilizadas para transformar a árvore inicial na árvore de consulta otimizada final. Operações Cartesian Product seguidas de uma condição de junção podem ser substituídas por uma operação Join para melhorar ainda mais a árvore de consulta.

23 23 Também é importante o mais cedo possível manter apenas os atributos necessários para as operações subseqüentes nas relações intermediárias, por meio da inclusão de operações Project (π). Enfim, as heurísticas básicas para otimização algébrica são: Aplicar o quanto antes operações que reduzem o tamanho dos resultados intermediários, como operações de SELECT que reduzem o número de tabelas e Operações Project que diminuem o número de atributos Otimização baseada em custo Um otimizador de consultas não deve basear-se apenas em regras heurísticas, mas também deve estimar e comparar diferentes estratégias de execução, considerando a melhor estratégia aquela com menor estimativa de custo. Uma otimização mais elaborada é indicada em consultas compiladas, que são consultas na qual a otimização é feita em tempo de compilação, sendo consultas interpretadas indicadas para otimização parcial, que ocorrem em tempo de execução. A otimização baseada no custo, busca soluções para um problema e também uma solução que minimize uma função de custo, porém essas funções são apenas estimativas, pois o otimizador pode escolher uma estratégia de solução que não seja a estratégia ótima Componentes do custo para execução de uma consulta Alguns componentes são necessários para o custo da execução de uma consulta, como: Custo de acesso ao armazenamento secundário: refere-se ao custo da busca, leitura e escrita de blocos de dados que residem em armazenamento secundário, principalmente em discos. Fatores como blocos de arquivos alocados de maneira adjacente no mesmo cilindro ou disco afetam o custo de acesso.

24 24 Custo de armazenamento: custo de arquivos temporários que são gerados por uma estratégia de execução de consulta. Custo de computação: compõe o custo de realização, na memória, referente às operações de buffers de dados durante a execução da consulta. Custo do uso de memória: custo referente ao número de buffers de memória que são solicitados durante a execução da consulta. Custo de comunicação: custo que se refere ao transporte da consulta e de seus resultados de um site de banco de dados para o site ou terminal onde a consulta originou-se. Em grandes bancos de dados, o foco é minimizar o custo de acesso ao armazenamento secundário. Já em bancos menores, o ideal é minimizar o custo de computação. Nos bancos de dados distribuídos, o custo de comunicação deve ser o foco de minimização. De acordo com Elmasri e Navathe (2005, p.377), Para estimar custos de várias estratégias de execução, devemos manter atualizadas quaisquer informações que sejam necessárias para as funções de custo. Essas informações podem ser armazenadas no catálogo do SGBD, onde são acessadas pelo otimizador de consulta. Para o otimizador de consulta realizar a estimativa de custo das várias estratégias de execução, é preciso valores razoavelmente próximos de atualizados, mas não necessariamente valores atualizados até o último minuto. As diferenças estratégias são enumeradas e os custos das diferentes estratégias são estimados. A programação dinâmica é uma técnica de otimização que pode ser utilizada para encontrar eficientemente a estimativa de custo ótima, sem precisar considerar todas as possíveis estratégias de execução. Segundo Elmasri e Navathe, Para desenvolver funções de custo razoavelmente precisas para operações JOIN, é preciso ter uma estimativa do tamanho (número de tabelas) do arquivo que resulta após a operação JOIN. (2005, p.378). Dá-se o nome de seletividade da junção (js), a proporção entre o tamanho do arquivo de junção resultante e o tamanho do arquivo do produto cartesiano.

25 25 Para uma consulta complexa o número de planos de consulta diferentes que são equivalentes pode ser muito grande. Várias técnicas são utilizadas para reduzir ainda mais o custo da pesquisa por uma grande quantidade de planos. Para Silberschatz (2006, p.395), Ao examinarmos os planos para uma expressão, podemos terminar depois que examinarmos apenas uma parte da expressão, isso se determinarmos que o plano mais barato para essa parte já é mais dispendioso do que o plano de avaliação mais barato para uma expressão completa examinada anteriormente. A redução ainda maior do número de planos de execução pode ser conseguida através de uma escolha heurística de um bom plano e estimando seu custo. Essas otimizações podem diminuir significativamente a sobrecarga da otimização de consulta. O SQL SERVER introduz grande complexidade nos otimizadores de consulta. Existem diferentes técnicas de otimização, sendo que alguns sistemas como Microsoft SQL SERVER são baseados em regras de equivalência, que possui como benefício à facilidade de estender o otimizador com novas regras. De acordo com Silberschatz (2006), para que a técnica funcione de modo eficiente, é preciso que haja técnicas eficientes para detectar derivações duplicadas e uma forma de programação dinâmica para evitar a reotimização das mesmas subexpressões Otimizando subconsultas aninhadas No SQL SERVER, subconsultas são consultas aninhadas, que pode ser utilizada em SELECT, INSERT, UPDATE ou DELETE, ou mesmo em subconsulta. Existem dois tipos de subsconsultas aninhadas: Correlacionada e não correlacionada. Subconsultas correlacionadas são consultas, onde a consulta aninhada depende de campos da query externa. Quando se utiliza uma subquery correlativa com o comando EXISTS, a perfomance é igual ao do INNER JOIN. SELECT p.productid, p.name, p.listprice FROM Production.Product AS p WHERE EXISTS (SELECT * FROM Sales.SalesOrderDetail AS sod WHERE p.productid = sod.productid )

26 26 No exemplo abaixo, fazendo a mesma query com o INNER JOIN SELECT DISTINCT p.productid, p.name, p.listprice FROM Production.Product AS p INNER JOIN Sales.SalesOrderDetail sod ON p.productid = sod.productid Subquery não-correlacionada A subquery não depende de campos da query externa. SELECT p.productid, p.name, p.listprice FROM Production.Product AS p WHERE p.listprice > (SELECT AVG(p2.ListPrice) FROM Production.Product AS p2) As tabelas derivadas Quando a SELECT é embutido na clausula FROM. SELECT B.BusinessEntityID, b.jobtitle, a.numtitle FROM (SELECT e.jobtitle, COUNT(*) numtitle FROM HumanResources.Employee e GROUP BY e.jobtitle) AS a INNER JOIN HumanResources.Employee b ON b.jobtitle = a.jobtitle. Demais exemplos: Comando IN SELECT Name, p.productsubcategoryid FROM Production.Product p WHERE ProductSubcategoryID IN ( SELECT ProductSubcategoryID FROM Production.ProductSubcategory WHERE Name = 'Wheels' ); O mesmo exemplo que o acima, mas usando o JOIN ao invés do IN. A diferença é que com o JOIN, consegue-se pegar os campos das duas tabelas e usar no SELECT, já com o IN isso não é possível. SELECT p.name, s.name, p.productsubcategoryid FROM Production.Product p INNER JOIN Production.ProductSubcategory s ON p.productsubcategoryid = s.productsubcategoryid AND s.name = 'Wheels';

27 27 Utilizando Valores no IN. SELECT Name, ProductSubcategoryID FROM Production.Product WHERE ProductSubcategoryID IN (12, 17); Utilizando o comando NOT IN SELECT Name FROM Production.Product WHERE ProductSubcategoryID NOT IN ( SELECT ProductSubcategoryID FROM Production.ProductSubcategory WHERE Name = 'Mountain Bikes' )

28 28 5. SINTONIZAÇÃO (TUNING) DE BANCO DE DADOS EM SISTEMAS RELACIONAIS É de extrema importância que no projeto físico inicial de desenvolvimento de um banco de dados sejam tomados certos cuidados, para que, quando o banco de dados esteja em operação, fazendo uso das aplicações, transações, consultas e visões, não ocorram problemas. É preciso realizar estimativas seguras de volumes de atividades e os tamanhos dos dados e constantemente monitorar e revisar o projeto. Para Elmasri e Navathe, A utilização dos recursos, bem como o processamento interno do SGBD, tais como otimização de consultas, podem ser monitorados para revelar gargalos, como a disputa pelos mesmos dados ou dispositivos. (2005, p.389). Os objetivos da sintonização são: Permitir que as aplicações sejam executadas mais rapidamente; Fazer com que as consultas/transações possam ter um tempo de resposta menor; Melhorar o desempenho geral das transações; A sintonização pode ser considerada como um ajuste continuado do projeto, pois as mesmas decisões do projeto precisam ser revistas. Os SGBDs podem coletar as seguintes estatísticas: Tamanhos de tabelas individuais; Número de valores distintos em uma coluna; Número de vezes que uma consulta ou transação em particular é submetida ou executada num determinado intervalo de tempo; Os tempos necessários para as diferentes fases do processamento de consultas e transações (para um dado conjunto de consultas e transações). A sintonização de um banco de dados envolve tratar os seguintes tipos de problemas: Como evitar excessivas disputas por bloqueios, para que não ocorra a concorrência entre as transações;

29 29 Como diminuir a sobrecarga dos registros de logs e o armazenamento desnecessário de dados; Como realizar a otimização do tamanho do buffer e o escalonamento de processos; De que maneira alocar recursos, como discos, RAM e também processos para que haja uma utilização mais eficiente; Os DBAs passam por treinamentos para tratar de problemas de sintonização em SGBDs específicos. Alguns problemas podem ser resolvidos através de ajustes de parâmetros físicos do SGBD, como alteração da configuração de dispositivos, de parâmetros do sistema operacional e de outras atividades similares. É preciso levar em consideração vários aspectos para que se consiga um desempenho adequado de um banco de dados. Para isso é necessário tomar algumas decisões durante o projeto. De acordo com Carneiro (2009), uma das principais considerações a se levar em conta na fase de projeto é quanto ao volume esperado de dados em cada relação do sistema e quais consultas serão realizadas com mais freqüência. Porém, em alguns sistemas percebe-se o real desempenho, somente após algum tempo de uso, e também muitas vezes, as considerações feitas pelos projetistas podem estar equivocadas. Por isso que se tornam necessários o monitoramento e a revisão do projeto físico de banco de dados, para descobrir a existência de gargalos ou mesmo a disputa dos mesmos dados ou dispositivos. Através desse monitoramento, algumas outras informações são obtidas, tais como: Estatísticas de armazenamento: dados a respeito da alocação de armazenamento para espaço de tabelas, espaço de índices e portas de buffer. Estatísticas de desempenho de I/O: atividade total de leitura/escrita (paginação) do disco. Estatísticas de processamento de consultas: Quantidade de tempo utilizado para execução de cada consulta e também do tempo de otimização das mesmas. Estatísticas relacionadas a bloqueios/registros de log: taxas de definição de diferentes bloqueios, de desempenho de transações e registros de log de atividades. Apesar das estatísticas acima referirem-se a transações, controle de concorrência e recuperação de dados, o tuning de banco de dados trata diretamente de problemas relacionados a excessivas disputas, que podem ser amenizados por meio de bloqueios, aumentando a concorrência entre as transações, minimizando a sobrecarga de registros,

30 30 logs e o armazenamento desnecessário dos dados. Também é de extrema importância que seja feita a otimização do tamanho do buffer e o escalonamento de processos, bem como, alocar recursos de memória, discos e processos para uma utilização mais eficiente. 5.1 Sintonização do projeto de banco de dados De acordo com Elmasri e Navathe, Se um dado projeto físico de banco de dados não atinge os objetivos esperados, podemos voltar ao projeto lógico do banco de dados, fazer ajustes no esquema lógico e remapeá-lo num novo conjunto de tabelas e índices físicos. (2005, p. 390). Todo projeto de banco de dados deve ser direcionado por requisitos de processamento e requisitos de dados, nos quais o primeiro altera-se dinamicamente, sendo necessário o projeto responder por meio de alterações no esquema conceitual, refletindo tais mudanças no esquema lógico e físico do projeto. Elmasri e Navathe, citam algumas dessas alterações, (2005, p.390, 391): Tabelas existentes podem ser desnormalizadas, porque certos atributos de duas ou mais são freqüentemente necessários em conjunto; Pode haver outras escolhas alternativas no projeto, para um dado conjunto de tabelas; Uma relação da forma R(K, A, B, C, D,...), onde K é um conjunto de atributos-chave (que está na FNBC), pode ser armazenada em múltiplas tabelas que também estão na FNBC, replicando-se a chave K em cada tabela, como exemplo, R1 (K, A, B), R2(K, C, D) e R3(K,...). Dá-se o nome de partição vertical; Atributo(s) de uma tabela pode(m) ser repetido(s) em outra mesmo que isso crie redundância e uma anomalia potencial; Da mesma forma que a partição vertical divide uma tabela verticalmente em múltiplas tabelas, a partição horizontal toma fatias horizontais de uma tabela e as armazena como tabelas distintas. Por exemplo, os dados de vendas de produtos podem ser separados em dez tabelas baseadas em dez linhas de produtos. Cada

31 31 tabela possui o mesmo conjunto de colunas (atributos), porém, contém um conjunto distinto de tabelas Sintonização de consultas Há principalmente duas indicações pela qual a sintonização da consulta pode ser indicada, segundo Elmasri e Navathe (2005, p. 391): 1. Quando existem muitos acessos a disco resultantes de uma consulta; 2. Um plano de consulta mostra que os índices relevantes não estão sendo utilizados; Situações típicas que indicam a necessidade de sintonização de consultas: Muitos otimizadores de consulta não utilizam índices na presença de expressões aritméticas, de comparações numéricas de atributos de diferentes tamanhos e níveis de precisão, comparações com NULL e comparações com substrings; Freqüentemente os índices não são utilizados em consultas aninhadas usando IN; Algumas cláusulas DISTINCT podem ser redundantes e podem ser evitadas sem a modificação do resultado, pois ele causa uma operação de ordenação e deve ser evitado sempre que possível. O uso desnecessário de tabelas de resultado temporário pode ser evitado por meio da aglutinação de múltiplas consultas em uma única consulta, a menos que a relação temporária seja necessária para algum processamento intermediário. Em algumas situações que envolvem o uso de consultas correlacionadas, os temporários são úteis; Se for possível utilizar várias opções de condições de junção, a melhor opção é a escolha que use um índice clustered, e evite as que contenham comparações de cadeias de caracteres; Uma particularidade dos otimizadores de consulta é que a ordem das tabelas na cláusula FROM pode afetar o processamento de junções. Às vezes, é necessário

32 32 alterar a ordem de forma que a menor das relações seja varrida e a maior relação usada como um índice adequado; 5.2 Possíveis causas para o baixo desempenho A causa do baixo desempenho pode estar relacionada ao hardware, que inclui a rede disponível, processador, memória RAM, entre outros, ou também nos softwares. Esses problemas geram gargalos que interferem no bom desempenho do banco de dados. Quando se trata de banco de dados relacional as causas de baixo desempenho também podem estar relacionadas a(o): a) Sistema operacional (SO), por razões de má parametrização; b) SGBD relacional, relacionada às inadequadas configurações nas áreas de buffers, organização do logging, alocação de arquivos, entre outros; c) Rede, devido a impactos no tráfego em razão de processamento de dados efetuados no servidor ou na rede; d) Modelo físico de dados, por razão de inadequação na definição da estrutura das tabelas e índices; e) Aplicação, com relação a problemas na estrutura lógica efetuada pelo programador, o que compreende a linguagem hospedeira e os comandos em SQL SERVER. Entretanto, segundo Picini e Schimiguel, os problemas estão relacionados pela seguinte proporção: 60% correspondem ao mau uso de expressões SQL; 20% estão relacionados à má modelagem do BD; 10% referem-se à má configuração do SGDB; 10% referem-se à má configuração do SO; Além disso, é importante citar que o conhecimento sobre a aplicação influencia bastante, pois a baixa performance pode não estar ligada diretamente ao banco. Outro fator importante é que as alterações devem ser realizadas aos poucos, divididas e analisadas verificando os resultados um a um, pois se vários procedimentos forem modificados ao mesmo tempo, corre-se o risco de não perceber algum erro e não conseguir repará-lo com facilidade.

33 33 De acordo com Mullins (2005), Quase 80% dos problemas de performance em banco de dados são causados por códigos SQL mal elaborados. Reduzir o tempo dos SQL e o custo é importantíssimo para que uma grande parte dos problemas seja reduzida. 5.3 Aumentando a performance da aplicação através da otimização do SQL SERVER De acordo com Couto (2006), existem algumas observações a serem feitas para aumentar a performance do banco de dados, como: Definir corretamente o buffer do banco de dados (shared_pool, buffer chache, log buffer, etc.), colocando os objetos grandes e muito acessados em memória para prevenir freqüentes reloads; É necessário que os arquivos de banco de dados estejam com o tamanho correto e um local que prove um mínimo de I/O; Observar os eventos que acontecem no banco relativo à locks, latches e wait e se possível eliminá-los. Monitorar e definir os parâmetros de CPU, I/O e memória de forma a melhorar o desempenho do banco; Como já explicado anteriormente, a otimização consiste em mostrar ao usuário a informação com tempo e custo menores, através do caminho mais eficiente. Couto (2006), ainda explica em seu artigo que a metodologia de tuning de SQL envolve identificar as queries que consomem mais recursos para então otimizá-las. Geralmente, um número pequeno de queries é responsável pela maior parte das atividades que ocorrem no banco de dados. É essencial que se tente entender por completo a aplicação, focando a atenção nos SQL ou tabelas onde os benefícios do tuning excederão os custos. Devem-se observar alguns passos: É preciso ter certeza de que o código esteja correto antes de otimizá-lo; Garantir a escrita igual dos comandos para facilitar a reutilização; Trazer apenas as informações necessárias do banco de dados;

34 34 Sempre manter atualizado as estatísticas das tabelas; Identificar problemas potenciais antes de mandá-los para produção; Otimizar primeiro os SQL mais críticos, não perdendo tempo otimizando códigos que raramente são utilizados; Utilizar índices, porém não criá-los em demasia. Alguns índices podem trazer um resultado com efeito adverso no desempenho. O critério básico da escolha de índices é a seletividade. Quando um banco de dados resolve uma consulta, geralmente, ele precisa percorrer mais registros do que aqueles realmente retomados pela consulta. Os registros percorridos que forem rejeitados representam o trabalho perdido. Quanto menor for o trabalho perdido, mais perto estará da performance ótima para resolver a consulta; Construir índices a partir das restrições dos SELECTs (cláusula WHERE); As comparações usando <>, NOT, NULL, LIKE podem invalidar o índice; Evitar full table scans se o resultado pode ser recuperado via índice, a menos que a tabela seja pequena e o custo diminua. Quando a tabela é pequena, o trabalho envolvido em acessar o índice, pegar o endereço e acessar a tabela é maior que o esforço de ler a tabela inteira; Queries muito grandes devem ser divididas em queries menores. Lógicas complexas de negócio no SQL devem ser evitadas; Evitar usar os comandos que produzem sort como: GROUP BY, ORDER BY, DISTINCT, etc. No sort, o banco recupera todas as informações necessárias primeiramente, para após realizar a ordenação; Os comandos EXIST e NOT EXIST geralmente possuem menor custo do que comandos como IN e NOT IN. A condição NOT deve ser transformada em uma expressão afirmativa; Substituir por junções os blocos SELECT embutidos utilizando IN, =ALL, =ANY e =SOME; Se uma junção de igualdade for definida entre duas tabelas, o predicado de faixa (condição de seleção) para o atributo de junção definido em uma tabela pode ser repetido para a outra tabela;

35 35 6. ÍNDICES NO SQL SERVER Um índice torna rápida a recuperação de linhas de uma tabela, pois contém chaves de uma ou mais colunas da tabela que são criadas e armazenadas em uma estrutura de árvore. Desta maneira o SQL SERVER faz a associação dos valores de chave com as linhas de pesquisa. Os índices podem ser: Clustered: Através dos valores de chave é que esse tipo de índice classifica e armazena suas linhas de dados. Por existir apenas um índice desse tipo em uma tabela, a classificação das linhas de dados é feita em ordem única. Quando a tabela não possui um índice clusterizado, seus dados ficam armazenados numa estrutura denominada heap. Denomina-se heap porque os dados não têm uma ordem lógica e são gravados nas páginas que tem espaço disponível. As páginas de dados não são ligadas a uma lista vinculada. O espaço alocado para o heap é gerenciado pela coluna de páginas Index Allocation Map (IAM). A movimentação pelo heap é feita pelo SQL SERVER através das páginas IAM. Não existe vínculo entre as páginas de dados e as linhas dentro delas. Não Custerizado: Nesse tipo de índice a estrutura é diferente das linhas de dados, pois possui um ponteiro que armazena o valor de chave do índice. O ponteiro de uma linha de índice é denominado localizador de linhas. Os dois tipos de índices podem ser exclusivos, garantindo que duas linhas não tenham o mesmo valor que a chave do referido índice. No momento da criação de uma tabela, quando se define restrições de Primary Key e Unique os índices são automaticamente criados na coluna. 6.1 Estruturas de índices clusterizados No SQL SERVER, os índices são organizados como árvores B. Pelo fato de ser balanceada, a árvore B localiza qualquer registro, propiciando o rápido acesso aos dados através da pesquisa de um valor-chave do índice.

36 36 Cada página em uma árvore B de índice é chamada de nó do índice. Os nós inferiores são conhecidos por folha, os superiores por raiz e qualquer um que esteja entre os dois são conhecidos como níveis intermediários. Os nós folha possuem as páginas de dados da tabela subjacente. Já os nós raiz e intermediário, possuem páginas de índices com linhas de índice. Cada índice clusterizado, tem um particionamento único. Caso algum índice possua particionamentos múltiplos, cada um terá uma estrutura de árvore B com os dados específicos dele. Para cada particionamento usado pelo índice, os índices clusterizados tem uma linha em sys.partions com índex_id = 1. Os tipos de dados é que definem a estrutura de alocação para armazenar e gerenciar o índice. Cada índice possui no mínimo uma unidade de alocação IN_ROW_DATA (linhas de dados ou índices que contenham todos os dados, exceto dados de LOB), LOB_DATA (dados de objeto grande armazenados em um ou mais tipos de dados) e ROW_OVERFLOW_DATA (excesso do tamanho de linha). O SQL SERVER possui métodos específicos para localizar a linha correspondente a uma chave de índice clusterizado. Figura Árvore B para um índice clusterizado. Fonte:

37 Estruturas de índices não clusterizados Os índices não clusterizados possuem a mesma estrutura de árvore B que os índices clusterizados, com algumas diferenças importantes: Não existe uma ordem na classificação e no armazenamento das linhas de dados; A camada de folha de um índice possui páginas de índice, diferente do índice clusterizado que possui página de dados; Cada linha desse índice possui o valor de chave e um ponteiro que aponta para a linha de dados no índice clusterizado ou no heap. É chamado de RID, o ponteiro que é criado através de um identificador do número de página e o número da linha do arquivo. Figura Árvore B para um índice não clusterizado. Fonte:

38 De que maneira o Otimizador sabe quando utilizar os índices? Visando sempre o melhor desempenho no momento de realizar operações, os índices são grandes aliados em muitas instruções como SELECT, UPDATE, DELETE ou MERGE. Um exemplo é quando uma consulta é realizada, o otimizador lê as linhas da tabela, estuda as possibilidades de recuperação de dados e escolhe qual é o método mais eficaz, filtrando assim as que atendem a pesquisa solicitada. Porém, todo esse trabalho do otimizador gera várias operações de I/O e muitos recursos são exigidos. Quando o otimizador não encontra um índice disponível, ele realiza a verificação de tabela para que assim possa criar e projetar índices que serão apropriados. Essa é outra importante função do Otimizador de consulta. No SQL SERVER existe uma ferramenta que auxilia na análise e seleção de índices mais apropriados que é chamada de Orientador de otimização do mecanismo de banco de dados. Geralmente os índices contêm poucas colunas por linha e ficam classificadas em ordem, tornando assim, bem mais rápida a busca do que se fosse feita na tabela. Quando a pesquisa é feita através do índice, o otimizador busca as colunas de chave e encontra o local pelo qual estão armazenadas as linhas para aquela consulta específica. 6.2 Páginas e extends Um arquivo de dados (.mdf ou.ndf) no SQL SERVER é armazenado em páginas contíguas, que possuem o tamanho de 8 Kilobytes (KB). A leitura ou a gravação são feitas em páginas de dados inteiras. A quantidade de páginas por megabytes (MB) é de 128, sendo que a página inicia-se com um cabeçalho de 96 bytes, onde ficam armazenadas as informações de sistema, como número, tipo, quantidade de espaço livre e o ID de alocação do objeto da página. Em seguida, iniciam-se as linhas de dados.

39 39 O máximo de dados que uma linha suporta é bytes (8KB), não incluindo os dados armazenados em tabelas que possuem colunas varchar, nvarchar, varbinary ou SQL_variant. Caso ocorra excesso de dados, o SQL SERVER move uma ou mais colunas de comprimento variável para páginas na unidade chamada de ROW_OVERFLOW_DATA. Se houver diminuição do tamanho da linha, através de uma operação subseqüente, o SQL SERVER transportará novamente a coluna para a página de dados original. Já as extensões, são um conjunto de oito páginas contíguas ou 64 KB e tem como função o gerenciamento eficaz das mesmas. Sendo assim, o SQL SERVER têm 16 extensões por MB. O SQL SERVER possui dois tipos de extensões: Uniformes: Possui um objeto proprietário; Mistas: Podem ser compartilhadas por até oito objetos, podendo cada página pertencer a um objeto diferente; Geralmente, quando a tabela ou índice é novo, utiliza-se a alocação de páginas de extensões mistas. Porém quando há um crescimento, passa-se a utilizar a alocação por extensões uniformes. Figura Árvore B padrão para um índice do SQL SERVER. Fonte: Unidade de alocação IN_ROW_DATA É composta por coleções de páginas de dados que são baseados em ponteiros de página na exibição de sistema. Cada partição de tabela, índice e exibição indexada é identificada por um ID de contêiner (container_id).

40 Unidade de alocação ROW_OVERFLOW_DATA Existe uma unidade de alocação ROW_OVERFLOW_DATA para toda partição usada por uma tabela, índice ou exibição indexada. Possui zero página até que uma linha de dados exceda o limite. Caso isso aconteça, o SQL SERVER move uma coluna com a largura maior daquela linha para uma página na unidade de alocação Unidade de alocação LOB_DATA Gerencia o armazenamento de diferentes tipos de dados, tais como text, ntext, image, xml, varchar(max), nvarchar(max), varbinary(max) e tipos de dados Common Language Runtime (CLR) definidos pelo usuário. 6.3 Sintonização de índices De acordo com Pilecki, O índice é, em essência, uma cópia menor da tabela, contendo um subconjunto de colunas da tabela. Apenas as colunas necessárias para responder as consultas são incluídas no índice. Utiliza-se a criação de índices abrangentes para ajustes nas consultas executadas com maior freqüência. É essencial em casos em que a tabela possui várias colunas, porém apenas algumas delas são freqüentemente referenciadas por consultas. Dessa maneira, criando um ou mais índices abrangentes, é possível melhorar muito o desempenho das consultas afetadas, pois elas estarão acessando um volume de dados bem menor e, assim, incorrendo em menor I/O. Todavia, há um custo oculto de manutenção de índices adicionais durante as operações de modificação de dados (INSERT, UPDATE e DELETE). Às vezes torna-se necessária uma revisão para a escolha inicial de índices, pelas seguintes razões, segundo Elmasri e Navathe, (2005, p.389, 390): Devido à ausência de um índice, certas consultas podem demorar demais para serem executadas;

41 41 Alguns índices podem não ser utilizados; Certos índices podem estar causando sobrecarga excessiva, porque são baseados em um atributo que sofre freqüentes alterações; A maioria dos SGBDs possui um comando ou um meio de rastreamento (trace facility) que pode ser usado para solicitar ao sistema quais operações foram realizadas e em que ordem e quais estruturas de acesso secundário foram utilizadas, pois assim, através dessas análises de planos de execução, é possível diagnosticar as causas dos problemas citados acima. Segundo Elmasri e Navathe, O objetivo da sintonização é avaliar dinamicamente os requisitos, os quais às vezes variam sazonalmente ou durante diferentes períodos do mês ou da semana e reorganizar os índices para proporcionar melhor desempenho geral. (2005, p. 390).

42 42 7. O PLANO DE EXECUÇÃO NO SQL SERVER É através dos dados armazenados nas estatísticas das tabelas, referentes aos registros das tabelas, que o SQL SERVER decide qual será o melhor plano de execução a escolher. Desta maneira, é de suma importância manter as estatísticas sempre atualizadas, pois do contrário, o otimizador não terá informações necessárias para aperfeiçoar determinada consulta, gerando assim, um plano de execução com estimativas erradas. Quando uma solicitação é feita e enviada ao servidor, a mesma é guiada por um plano de execução, que se bem executado, trará o mais eficiente caminho da solicitação. O plano de execução também auxilia na identificação qual parte do código SQL que está causando o problema. O plano de execução é composto por operadores que na maioria das vezes são aplicados em certa ordem. É através do plano de execução, que se determina a ordem e acesso das tabelas que estão envolvidas na query, quais índices que serão utilizados e métodos para aplicá-los. 7.1 O otimizador de consulta O otimizador do SQL gera diversos planos, mas escolhe o que apresenta melhor performance, ou seja, o que apresenta o menor tempo para responder a consulta. Ele é quem decide como os dados serão acessados, por meio de índices, os tipos de JOINs a utilizar. É através de cálculos de custo, como processamento de CPU e operações de I/O, gerados pelo plano de execução que determinará qual será o caminho mais rápido de execução. É importante ressaltar que o custo estimado é apenas uma estimativa. Em casos, onde é realizada uma consulta simples, o otimizador não perde tempo tentando calcular o plano ideal, ele simplesmente aplica um plano trivial único a estes tipos de procedimentos. Porém, se a consulta não é trivial, o otimizador realiza um custo base de cálculo para selecionar um plano, baseado em estatísticas que são mantidas pelo SQL SERVER. Porém, nem todas as possibilidades são avaliadas, pois o custo é muito alto e desta forma compromete-se o ganho do desempenho. O plano de execução é determinado através de testes com diferentes associações, reorganizando a ordem de junções, tentando

43 43 diferentes índices e assim sucessivamente até chegar ao que ele pensa ser o plano mais rápido. 7.2 Plano de execução estimado e plano de execução real Existem dois tipos de planos de execução. O primeiro, conhecido como plano de execução estimado é o que representa a saída do otimizador. Os operadores, ou etapas, são representativos dos otimizadores de vista do plano. O próximo, mais conhecido como plano de execução real representa a saída da execução da consulta atual, o qual mostra o que realmente aconteceu quando a consulta foi executada. Geralmente, não existe diferença entre os dois planos, todavia algumas circunstâncias causam diferenças, como: Estatísticas desatualizadas, que ocorrem ao longo do tempo, quando dados são adicionados e excluídos, fazem com que ocorram diferenças entre elas e os dados reais; Em alguns casos, como os que utilizam tabela temporária, uma vez que a consulta não tenha sido executado, a tabela temporária também não existirá e desta maneira o plano de estimativa não irá funcionar; Em casos de requisições de consultas paralelas, quando o plano encontra paralelismo, no qual dois planos de execução são criados Formato dos planos O SQL SERVER oferece apenas um tipo de plano de execução, sendo três diferentes formatos: Planos gráficos (Graphical plans); Planos de texto (Text plans); Planos XML (XML plans);

44 44 Planos gráficos: Oferecem uma maneira rápida e fácil de leitura, porém os dados nesse tipo de plano ficam mascarados. Tanto o plano atual, como o estimado podem ser vistos da mesma maneira. Planos de Texto: Considerado um pouco mais difícil de ler, contudo, a informação é encontrada imediatamente. Existem três formatos: SHOWPLAN_ALL: conjunto completo de dados, que mostra o plano de execução estimado para o plano de consulta. SHOWPLAN_TEXT: Mostra apenas o plano de execução estimado. Fornece um conjunto muito limitado de dados, que são usados com ferramentas como osql.exe. STATISTICS_PROFILE: é praticamente similar ao SHOWPLAN_ALL, com exceção que representa os dados para o plano de execução real. Planos XML: Esses planos apresentam o mais completo conjunto de dados disponíveis num plano, com a estrutura no formato de XML. Existem duas formas: SHOWPLAN_XML: É utilizado pelo plano de estimativa, pois é gerado pelo otimizador antes da execução. STATISTICS_XML: Utilizado pelo plano de execução real. A seguir, exemplos de Planos de Texto (TEXT plans) e Planos XML (XML plans):

45 45 Figura 7.1 Exemplo de um plano de texto estimado usando os comandos SET SHOWPLAN_ALL ON e SET SHOWPLAN_ALL OFF. Figura 7.2 Exemplo de um plano de texto estimado usando os comandos SHOWPLAN_TEXT ON e SHOWPLAN_TEXT OFF.

46 46 Figura 7.3 Exemplo de um plano de texto real usando os comandos SET STATISTICS_PROFILE ON e SET STATISTICS_PROFILE OFF. Figura 7.4 Exemplo de um plano XML estimado usando os comandos SET SHOWPLAN_XML e SET ON e SHOWPLAN_XML OFF.

47 47 Clicando no link gerado, o SQL direcionará para outra janela, na qual abrirá o plano de execução no formato XML, conforme demonstra a figura abaixo: Figura 7.5 Exemplo de um plano de execução em XML. Através da exibição desses planos é claramente possível observar que o SHOWPLAN_ALL é mais completo, pois exibe maiores informações de maneira imediata Interpretando planos de execução gráficos Um plano de execução deve ser lido da direita para a esquerda e de cima para baixo. Na figura abaixo, observa-se apenas que houve uma varredura de tabelas (table scan), no qual se produziu um conjunto de resultados, representados através do comando SELECT. A quantidade de dados que são passados na consulta, é o fator que representa a espessura da seta, pois quanto mais grossa a linha, maior será a quantidade de dados. É possível saber o número de linhas representado, passando o ponteiro do mouse sobre as flechas, confirmando assim se o número apresentado está correto. Na figura 7.6 é possível visualizar:

48 48 Figura 7.6 Exemplo de um plano de execução gráfico. Abaixo de cada ícone exibi-se um número com uma porcentagem, que representa o custo relativo à consulta para esse operador. Esse custo que é retornado pelo otimizador, é o custo do tempo de execução para aquela determinada operação. No caso da consulta do exemplo acima, o custo maior refere-se à operação table scan, que ocorre quando o mecanismo de armazenamento é obrigado a ler linha por linha, retornando todas as informações, pois nenhuma outra cláusula foi especificada, como a cláusula WHERE. Entretanto, é importante ressaltar que como as porcentagens referem-se a razões e não números reais, então mesmo um operador que tenha 0 % terá um pequeno custo associado. Acima dos ícones é possível visualizar o custo de 100% que representa grande parte da seqüência de consulta. Desta maneira, como cada consulta pode ter várias etapas, e cada uma dessas etapas tem um custo em relação à consulta, é possível executar também diversas consultas dentro de um lote e obter planos de execução para eles. Passando o ponteiro do mouse sobre o ícone SELECT, observa-se os dados que são apresentados na figura 7.7:

49 49 Figura 7.7 Dados resultantes do ícone SELECT no plano de execução gráfico Cached plan size ou tamanho do plano em cachê: Quantidade de memória em cachê, que a consulta terá, demonstrado através do plano de execução. Através desse número, é possível diagnosticar problemas de desempenho, selecionando os planos que estão ocupando mais memória; Degree of parallelism ou grau de paralelismo: Quantidade de planos de execução gerados; Estimated operator cost ou custo estimado do Operador: Custo estimado referente ao operador, neste caso SELECT ; Estimated subtree cost ou custo estimado da Subárvore: Custo do otimizador acumulado atribuído a esta etapa e todas as etapas anteriores. É importante ressaltar novamente, que o plano de execução deve ser lido da direita para a esquerda e de cima para baixo. Apesar de esse número ser insignificante no mundo real, é uma avaliação matemática utilizado pelo otimizador. Estimated numbers of rows ou número estimado de linhas: Estimativa referente ao número de linhas da consulta. Da mesma maneira, observam-se na figura 7.8, os dados demonstrados no ícone Table Scan.

50 50 Figura 7.8 Dados resultantes do ícone table scan. Cada um dos diferentes operadores mostrados na figura acima terá um conjunto distinto de dados. Os operadores lógicos compõem o resultado dos cálculos de otimização que são feitos quando uma consulta é executada. Os operadores físicos representam o que de fato ocorreu. Na maioria das vezes esses operadores sempre são parecidos. Em seguida, é possível observar as estimativas dos custos de operações de I/O, CPU, e subárvore. A subárvore representa uma simples seção da execução, sempre analisando da direita para a esquerda e de cima pra baixo. Todas as estimativas baseadas em estatísticas referem-se a colunas e índices disponíveis nas tabelas. Os custos das operações de I/O e de CPU representam o custo atribuído pelo otimizador através de cálculos. Esses números são úteis para determinar se a maior parte do custo é de I/O, ou se é necessário colocar uma carga na CPU. O Custo do Operador e da subárvore são parecidos, desde que haja apenas um operador. Para árvores mais complexas, com mais

51 51 operadores, o custo é acumulado individualmente para cada operador e depois adicionado no total. Em seguida, novamente pode-se observar a estimativa do número de Linhas. Outra importante análise de informação, que também auxilia na solução de problemas de desempenho, é a variável Ordered ou Ordenada que exibe o valor em booleano. Em uma instrução SELECT, podem ser necessários que os dados sejam colocados em uma determinada ordem, classificados por um determinado valor ou conjunto de valores. Finalmente, Node ID é o número ordinal, que significa simplesmente numerado em ordem, do próprio nó, da esquerda para a direita Facilitando a captura do plano de execução usando SQL SERVER Profiler Uma ferramenta poderosa existente no SQL SERVER, é o SQL Profiler, que realiza a captura de dados sobre eventos, tais como a execução de T-SQL ou então procedimentos armazenados, que ocorrem dentro do SQL SERVER. Essa ferramenta mostra como o SQL SERVER resolve consultas internas fornecendo uma interface gráfica para a funcionalidade oferecida pelo Rastreamento SQL. Com o SQL SERVER Profiler, é possível capturar atividades geradas por uma carga de trabalho em uma instância do SQL SERVER. Através de modelos pré-definidos, os eventos que são capturados e exibidos podem ser definidos, e assim podendo realizar a modificação de modelos fornecidos pelo sistema para criar os seus próprios. A carga de trabalho, que servirá para uma futura avaliação, também pode ser capturada em uma tabela ou um arquivo. Rastreamentos podem ser iniciados a qualquer momento a partir do SQL SERVER Management Studio, baseado em seu contexto de conexão. O comando Rastrear Consulta no SQL SERVER Profiler, auxilia no rastreamento da execução de instruções em uma determinada sessão do Editor de Consulta, usando o SPID da janela de consulta como um filtro. Os eventos Profiler podem ser rastreados manualmente, ou através de uma interface gráfica ou vestígios podem ser definidos através da T-SQL (ou o GUI) e automatizado para

52 52 executar em certos momentos e em certos períodos. Tais vestígios podem ser visualizados na tela ou enviados para um arquivo ou uma tabela em um banco de dados. Figura Exemplo de funcionamento do SQL profiler Eventos do plano de execução Diversos eventos, como os listados abaixo, geram o rastreamento do plano de execução: Showplan Text: Parecido com o plano de estimativa que o evento SHOWPLAN_TEXT gera, esse evento dispara a cada execução de uma consulta. Showplan Text (unencoded): A mesma definição do anterior, porém com a diferença que os dados são trazidos em forma de string e não como binário. Showplan All: Possui o mesmo tipo de plano de execução que os anteriores, apresentando também as mesmas dificuldades. Showplan All para compilação de consulta: Esse evento possui os mesmos dados que o Showplan All event, mas apenas dispara quando ocorre a compilação da consulta.

53 53 Showplan Statistics Profile: Esse evento refere-se ao plano de execução real e utiliza o comando STATISTICS PROFILE. Showplan XML: É disparado a cada execução de consulta e usado para gerar o plano de execução estimado, através do comando SHOWPLAN_XML. Showplan XML para compilação de consulta: Igual ao Showplan XML acima, porém só dispara quando alguma consulta está sendo compilada. Performance Statistics: É similar ao Showplan XML para compilação de um evento da consulta, com exceção que este evento captura métricas de desempenho e também o plano. Este evento capta apenas a saída XML para subclasses em determinados eventos. Ele é disparado toda vez que um plano está em cachê, é compilado, recompilado ou é removido do cachê. Showplan XML Statistics Profile: Esse evento gera o plano atual para cada consulta executada. 7.3 Um pouco mais sobre planos gráficos No plano de execução gráfico, são exibidos quatro tipos de operadores: Operadores lógicos e físicos: Representam a execução da consulta ou a linguagem de manipulação de dados (DML). São conhecidos como ícones azuis. Operadores de paralelismo físico: Representam operações de paralelismo e também são ícones azuis. De certa maneira, são subconjuntos dos operadores lógicos e físicos, porém são considerados a parte, pois indicam um nível totalmente diferente de análise do plano de execução. Cursor de Operações: Possui ícones amarelos e representam transações de cursor SQL. Elementos de Linguagem: São representados por ícones verdes e representam transações SQL de elementos de linguagem, como atribuição, declaração, If, SELECT, While dentre outras.

54 54 Alguns operadores, como os de ordenação (sort), hash, match e junção de join exigem uma quantidade variável de memória para executar e por causa disso, consultas com esses operadores podem ter que aguardar por memória disponível antes da execução, podendo assim afetar o desempenho. A maioria dos operadores comporta-se de duas maneiras distintas: bloqueio e sem bloqueio. Um operador de bloqueio precisa para produzir sua saída, obter todos os dados. Esse tipo de operador pode contribuir significativamente para problemas de concorrência, prejudicando assim o desempenho. Já o operador sem bloqueio recebe a entrada e ao mesmo tempo cria a saída. Segue abaixo exemplos de simples consultas em Tabelas da Base de dados do Adventure Works, no qual é possível observar alguns operadores que aparecem com mais freqüência nos planos de execução: Figura 7.10 Operador Clustered index scan. Os índices no SQL SERVER são armazenados em uma estrutura de árvore-b (uma série de nós que aponta para um dos pais). Um índice clustered armazena não apenas a estrutura essencial que é um índice regular, mas também armazena e classifica os dados, sendo que existe apenas um índice clustered por tabela. Um clustered index scan possui praticamente o mesmo conceito de um uma table scan. O índice percorre linha por linha para identificar dados necessários para a consulta. Às vezes, quando ocorre um index scan, é preciso saber se o plano de execução está retornando mais linhas do que realmente é necessário. Desta maneira, há necessidade de um fino ajuste na consulta utilizando a cláusula WHERE, para que assim o plano retorne apenas as linhas que realmente são necessárias, pois caso contrário, ocorrerá o desperdício de recursos do SQL SERVER, prejudicando o desempenho geral.

55 55 Figura 7.11 Exemplo de consulta que retorna um clustered index scan Figura 7.12 Operador clustered index seek Índices seek são totalmente diferentes dos índices scan, que percorrem linha a linha para encontrar os dados que a consulta solicita. Um índice seek, clustered ou não, ocorre quando o otimizador é capaz de localizar um índice que pode ser usado para recuperar os dados feitos na solicitação da consulta. Sendo assim, o mecanismo de armazenamento recebe a ordem para procurar os valores com base nas chaves do índice determinado. É possível verificar nesse exemplo do índice seek, que a propriedade ORDERED agora é verdadeira, indicando que os dados foram ordenados pelo otimizador.

56 56 Figura 7.13 Exemplo de consulta que retorna um clustered index seek Figura 7.14 Operador nonclustered index seek Como nos índices clustered, um índice nonclustered utiliza um índice para realizar a busca de linhas a serem devolvidas. Esse tipo de índice acontece quando todos os dados se encontram nele.

57 57 Figura 7.15 Exemplo de consulta que retorna um nonclustered index seek Figura 7.16 Operador key lookup

58 58 O operador key lookup pode ser observado na figura abaixo: Figura 7.17 Exemplo de consulta que retorna um operador key lookup. Conforme se observa esse plano envolve mais que uma única operação. Como dito anteriormente, o plano deve ser lido da direita para a esquerda e de cima para baixo. A primeira operação é relacionada a um índice seek, que não é um índice non-unique, nonclustered e non-covering. Um índice non-covering é um índice que não retorna todos os dados necessários para uma consulta, pois não contém todas as colunas. Sendo assim, ele força o otimizador a ler o índice cluster também, para que assim possa reunir todos os dados solicitados e devolver a consulta.

59 59 Figura 7.18 Dados resultantes do operador nonclustered index seek. Nessa figura é possível observar as descrições de saída do índice seek como as colunas como Address e ContactId.

60 60 Figura 7.19 Dados resultantes do operador key lookup. Observa-se na figura acima, que os valores-chave são utilizados na key lookup na PK_Contact_ContactID índice clustered para encontrar as linhas correspondentes com a lista de colunas de saída LastName e Phone. A Key Lookup ou Bookmark Lookup como era chamado no SQL SERVER 2000 é visto em tabelas com índices clustered. Esse operador demonstra que o otimizador não consegue recuperar as linhas com uma única operação e por isso necessita de uma clustered Key (ou linha ID) para que assim retorne as linhas correspondentes usando um índice clustered (ou da própria tabela). O operador Key Lookup é quando temos uma tabela com um índice clustered, e o índice non clustered busca a chave da pesquisa no outro índice. A clustered Key indica que o desempenho da consulta pode beneficiar-se da presença de um índice covering ou índices inclusos. A Key Lookup é sempre acompanhada da operação de junção Nested Loop que combina os resultados das duas operações. Figura 7.20 Operador nested loops

61 61 A Nested Loop join é uma operação padrão de associação, e não indica por si só problema de desempenho. Para que esse tipo de operação seja requisitado é preciso combinar as linhas do Index Seek e Key Lookup. Caso um índice de cobertura esteja disponível, a Key lookup não será necessária e o operador Nested Loops não aparecerá no plano de execução gráfico. Figura 7.21 Operador sort Quando outras cláusulas básicas são adicionadas a consulta, diferentes operadores podem surgir. O operador Sort é muito simples. Geralmente usado para indicar quando o otimizador de consulta classifica os dados dentro do plano de execução. Se uma cláusula ORDER BY não especificar a ordem, a ordem padrão é ascendente. Se esse operador não for realmente necessário, sugere-se que ele seja retirado, para que assim diminua a sobrecarga. Figura 7.22 Operador table scan Esse operador é bastante auto-explicativo. É possível verificar através de uma varredura da tabela, as linhas que foram devolvidas, linha a linha.

62 62 Figura 7.23 Exemplo de consulta que retorna um table scan. A table scan pode ocorrer por diversos motivos, porém geralmente é porque não existem índices úteis na tabela, sendo assim necessário o otimizador de consulta pesquisar todas as linhas em ordem para identificar as linhas que devem ser retornadas. Outro motivo comum pelo qual ocorre uma table scan é quando todas as linhas de uma tabela são retornadas. Quando a maioria das linhas trazidas pelo otimizador retorna cada uma um índice. Em algumas vezes, na maioria em tabelas com poucos registros, o otimizador de consulta determina que seja mais rápido realizar a varredura de cada linha do que utilizar um índice para retornar as linhas. Em casos onde a pesquisa é realizada em tabelas grandes e muitas linhas são devolvidas, sendo necessário analisar e reescrever a consulta para que a mesma retorne um número menor de linhas ou então adicionar um índice que seja apropriado para acelerar o desempenho.

63 63 Figura 7.24 Operador RID lookup No exemplo da consulta abaixo é possível verificar a combinação entre o Index Seek e a RID Lookup. Figura 7.25 Exemplo de consulta que retorna um operador RID lookup. No resultado dessa consulta, o otimizador de consulta primeiramente executa um Index Seek na chave primária. Enquanto o índice é útil na identificação de linhas que são encontradas com a cláusula WHERE, todas as colunas de dados necessários não estão presentes no índice.

64 64 Operadores Merge Join e Hash Match Figura 7.26 Operador merge join Figura 7.27 Operador hash match Na consulta abaixo é possível verificar os operadores acima: Figura 7.28 Exemplo de consulta que retorna os operadores merge join e hash match Merge Join: O otimizador de consulta também pode executar uma junção MERGE, que correspondem a linhas de tabelas de entrada devidamente ordenadas explorando a sua ordem de classificação.

65 65 Hash Match: Operações Hash são a segunda operação mais cara do plano de execução. Hashing é uma técnica de programação onde os dados são convertidos em uma forma simbólica que torna mais fácil e rápida a procura. Por outro lado, é uma estrutura de dados que divide todos os elementos em categorias regularizadas, permitindo o acesso rápido aos elementos. A junção Hash Match ocorre quando o SQL SERVER une duas tabelas, juntando linhas da menor com a maior, verificando as linhas que precisam ser unidas e inserindo-as em uma outra tabela hash. Portanto, se ambas as tabelas são muito grandes, um junção Hash Match pode ser muito ineficiente em comparação com outros tipos de associações.

66 66 8. ESTUDO DE CASO 8.1 O SGBD O SGBD escolhido para realização deste estudo foi o SQL SERVER Infraestrutura Hardware: Um servidor com processador Intel Core 2 duo T GHz; 4 GB de memória RAM; Software: Abaixo segue relacionado respectivamente, o sistema operacional e a versão correspondente ao SGBD SQL SERVER utilizados durante os testes: Windows 7 Home Basic; SQL SERVER 2008 R2; 8.2 Aplicação da metodologia Os testes foram realizados a partir de consultas que sofrem alterações de acordo com a utilização de métodos de junção diferentes, utilização ou não de índices, chaves primárias e chaves de junção.

67 67 O desempenho é avaliado através do estudo dos planos de execução gerados para cada consulta Base de dados Para realização deste estudo de caso foi utilizada a base de dados AdventureWorks, base esta, própria da Microsoft, contendo o tamanho de MB Implementação das consultas As consultas foram desenvolvidas utilizando tabelas do banco de dados AdventureWorks, as quais já possuem índices criados. Contudo, para complementar a demonstração desse estudo de caso, foi criada uma nova tabela, e também seus índices clustered e non clustered. Nessa nova tabela foram inseridos registros. O objetivo desse estudo de caso é demonstrar, dentre as consultas realizadas quais apresentam diferenças com relação ao desempenho. 8.3 Testes Teste 1 (subconsultas aninhadas comandos EXISTS e INNER JOIN) No exemplo abaixo, uma subconsulta aninhada é executada, usando a cláusula WHERE com o comando EXISTS.

68 68 a) SELECT p.productid, p.name, p.listprice FROM Production.Product AS p WHERE EXISTS (SELECT * FROM Sales.SalesOrderDetail AS sod WHERE p.productid = sod.productid ) Resultados obtidos: Linhas afetadas: 266; Tempos de Execução do SQL SERVER: CPU = 46 ms; tempo decorrido = 148 ms. Tempo de análise e compilação do SQL SERVER: CPU = 0 ms; tempo decorrido = 0 ms. TotalSubtreeCost: 0, Plano de execução: Figura 8.1 Plano de execução gerado para o teste 1a A consulta abaixo traz as mesmas informações que a anterior, porém ao invés de utilizar o comando EXISTS, foi utilizado o comando INNER JOIN. b) SELECT DISTINCT p.productid, p.name, p.listprice FROM Production.Product AS p INNER JOIN Sales.SalesOrderDetail sod ON p.productid = sod.productid

69 69 Resultados obtidos: Linhas afetadas: 266; Tempos de Execução do SQL SERVER: CPU = 47 ms; tempo decorrido = 115 ms. Tempo de análise e compilação do SQL SERVER: CPU = 0 ms; tempo decorrido = 0 ms. TotalSubtreeCost: 0, Plano de execução: Figura 8.2 Plano de execução gerado para o teste 1b Observa-se nos casos acima, que não houve diferença relevante entre as duas consultas. Portanto, nesses casos os comandos EXISTS e INNER JOIN possuem a mesma funcionalidade Teste 2 (Transformando expressões NOT em expressões afirmativas) a) SELECT Name,ProductSubcategoryID FROM Production.Product WHERE ProductSubcategoryID NOT IN ( SELECT ProductSubcategoryID FROM Production.ProductSubcategory WHERE Name = 'Mountain Bikes' ) ORDER BY ProductSubcategoryID

70 70 Resultados Obtidos: Linhas afetadas: 263; Tempos de Execução do SQL SERVER: CPU = 0 ms; tempo decorrido = 0 ms. Tempo de análise e compilação do SQL SERVER: CPU = 7 ms; tempo decorrido = 7 s. TotalSubtreeCost: 0, Plano de execução: Figura 8.3 Plano de execução gerado para o teste 2a b) SELECT Name,ProductSubcategoryID FROM Production.Product WHERE ProductSubcategoryID IN ( SELECT ProductSubcategoryID FROM Production.ProductSubcategory WHERE Name <> 'Mountain Bikes' ) ORDER BY ProductSubcategoryID Resultados obtidos: Linhas afetadas: 263; Tempos de Execução do SQL SERVER: CPU = 0 ms; tempo decorrido = 0 ms. Tempo de análise e compilação do SQL SERVER: CPU = 0 ms; tempo decorrido = 11 ms. TotalSubtreeCost: 0,

71 71 Plano de execução: Figura 8.4 Plano de execução gerado para o teste 2b Nos testes acima, foi possível constatar que no item a, o qual se utilizou o comando NOT IN, gerou um plano de execução com um número maior de operadores com relação ao item b, apesar de fazer uso de índices para realização da consulta. Devido a isso, a consulta possui um desempenho menor com relação ao item b, que possui um número menor de operadores, sendo assim utilizando menos recursos do SQL SERVER Teste 3 (Usando ou não índices) Para realização deste teste, foi criado uma nova tabela na base de dados AdventureWorks chamada de Curso.Pessoa. Abaixo seguem os passos: Criação da tabela Curso.Pessoa. Por padrão a PRIMAY KEY é um índice cluster. CREATE TABLE Curso.Pessoa ( Codigo BIGINT IDENTITY(1,1) NOT NULL PRIMARY KEY, Nome CHAR(100) NOT NULL, Idade TINYINT NULL ) GO

Structured Query Language (SQL)

Structured Query Language (SQL) SQL Histórico Structured Query Language (SQL) Foi desenvolvido pela IBM em meados dos anos 70 como uma linguagem de manipulação de dados (DML - Data Manipulation Language) para suas primeiras tentativas

Leia mais

Banco de Dados Profa. Dra. Cristina Dutra de Aguiar Ciferri. Banco de Dados Processamento e Otimização de Consultas

Banco de Dados Profa. Dra. Cristina Dutra de Aguiar Ciferri. Banco de Dados Processamento e Otimização de Consultas Processamento e Otimização de Consultas Banco de Dados Motivação Consulta pode ter sua resposta computada por uma variedade de métodos (geralmente) Usuário (programador) sugere uma estratégia para achar

Leia mais

SQL é uma linguagem de consulta que implementa as operações da álgebra relacional de forma bem amigável.

SQL é uma linguagem de consulta que implementa as operações da álgebra relacional de forma bem amigável. SQL (Structured Query Language) SQL é uma linguagem de consulta que implementa as operações da álgebra relacional de forma bem amigável. Além de permitir a realização de consultas, SQL possibilita: definição

Leia mais

SQL. SQL (Structured Query Language) Comando CREATE TABLE. SQL é uma linguagem de consulta que possibilita:

SQL. SQL (Structured Query Language) Comando CREATE TABLE. SQL é uma linguagem de consulta que possibilita: SQL Tópicos Especiais Modelagem de Dados Prof. Guilherme Tavares de Assis Universidade Federal de Ouro Preto UFOP Instituto de Ciências Exatas e Biológicas ICEB Mestrado Profissional em Ensino de Ciências

Leia mais

Comandos de Manipulação

Comandos de Manipulação SQL - Avançado Inserção de dados; Atualização de dados; Remoção de dados; Projeção; Seleção; Junções; Operadores: aritméticos, de comparação,de agregação e lógicos; Outros comandos relacionados. SQL SQL

Leia mais

Administração de Banco de Dados

Administração de Banco de Dados Administração de Banco de Dados Professora conteudista: Cida Atum Sumário Administração de Banco de Dados Unidade I 1 INTRODUÇÃO A BANCO DE DADOS...1 1.1 Histórico...1 1.2 Definições...2 1.3 Importância

Leia mais

SQL - Banco de Dados. Disciplina: Banco de Dados. Professor: José Antônio. José Antônio - CEFET-RN 23/09/2015

SQL - Banco de Dados. Disciplina: Banco de Dados. Professor: José Antônio. José Antônio - CEFET-RN 23/09/2015 SQL - Banco de Dados 1 Disciplina: Banco de Dados Professor: José Antônio 2 Tópicos de discussão Criando um banco de dados Incluindo, atualizando e excluindo linhas nas tabelas Pesquisa básica em tabelas

Leia mais

Faculdade Pitágoras 16/08/2011. Curso Superior de Tecnologia: Banco de Dados Sistemas para Internet

Faculdade Pitágoras 16/08/2011. Curso Superior de Tecnologia: Banco de Dados Sistemas para Internet Faculdade Pitágoras Curso Superior de Tecnologia: Banco de Dados Sistemas para Internet Disciplina: Banco de Dados Prof.: Fernando Hadad Zaidan SQL A linguagem SQL é responsável por garantir um bom nível

Leia mais

Faculdade Pitágoras. Curso Superior de Tecnologia: Banco de Dados. Disciplina: Banco de Dados Prof.: Fernando Hadad Zaidan SQL

Faculdade Pitágoras. Curso Superior de Tecnologia: Banco de Dados. Disciplina: Banco de Dados Prof.: Fernando Hadad Zaidan SQL Faculdade Pitágoras Curso Superior de Tecnologia: Banco de Dados Disciplina: Banco de Dados Prof.: Fernando Hadad Zaidan SQL A linguagem SQL é responsável por garantir um bom nível de independência do

Leia mais

Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br

Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br Programação com acesso a BD Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br 1 Modelos de Dados, Esquemas e Instâncias 2 Modelos de Dados, Esquemas e Instâncias Modelo de dados: Conjunto de conceitos

Leia mais

Linguagem SQL (Parte I)

Linguagem SQL (Parte I) Universidade Federal de Sergipe Departamento de Sistemas de Informação Itatech Group Jr Softwares Itabaiana Site: www.itatechjr.com.br E-mail: contato@itatechjr.com.br Linguagem SQL (Parte I) Introdução

Leia mais

Introdução ao SQL. O que é SQL?

Introdução ao SQL. O que é SQL? Introdução ao SQL 1 O que é SQL? Inicialmente chamada de Sequel, SQL (Structured Query Language), é a linguagem padrão utilizada para comunicar-se com um banco de dados relacional. A versão original foi

Leia mais

INTRODUÇÃO À LINGUAGEM SQL CRIAÇÃO DE BANCO DE DADOS E OTIMIZAÇÃO DE CONSULTAS

INTRODUÇÃO À LINGUAGEM SQL CRIAÇÃO DE BANCO DE DADOS E OTIMIZAÇÃO DE CONSULTAS Esclarecimento Licenciamento de Uso Este documento é propriedade intelectual 2012 da NRSYSTEM COMÉRCIO E SERVIÇOS DE INFORMÁTICA LTDA-ME, consiste de uma compilação de diversos materiais entre livros,

Leia mais

SQL. Prof. Márcio Bueno. {bd2tarde,bd2noite}@marciobueno.com

SQL. Prof. Márcio Bueno. {bd2tarde,bd2noite}@marciobueno.com SQL Prof. Márcio Bueno {bd2tarde,bd2noite}@marciobueno.com Material dos professores Ana Carolina Salgado, Fernando Foncesa e Valéria Times (CIn/UFPE) SQL SQL - Structured Query Language Linguagem de Consulta

Leia mais

Núcleo de Pós Graduação Pitágoras

Núcleo de Pós Graduação Pitágoras Núcleo de Pós Graduação Pitágoras Professor: Fernando Zaidan Disciplina: Modelagem e Projeto de Banco de Dados Especialização em Tecnologia da Informação - Ênfases Março- 2009 1 Modelo Físico Introdução

Leia mais

Banco de Dados 1 Prof. MSc Wagner Siqueira Cavalcante

Banco de Dados 1 Prof. MSc Wagner Siqueira Cavalcante Banco de Dados 1 Programação sucinta do curso:. Conceitos fundamentais de Banco de Dados.. Arquitetura dos Sistemas Gerenciadores de Banco de Dados (SGBD ou DBMS).. Características típicas de um SGBD..

Leia mais

O que são Bancos de Dados?

O que são Bancos de Dados? SQL Básico Liojes de Oliveira Carneiro professor.liojes@gmail.com www.professor-liojes.blogspot.com O que são Bancos de Dados? É o software que armazena, organiza, controla, trata e distribui os dados

Leia mais

Linguagem SQL Parte I

Linguagem SQL Parte I FIB - Centro Universitário da Bahia Banco de Dados Linguagem SQL Parte I Francisco Rodrigues Santos chicowebmail@yahoo.com.br Slides gentilmente cedidos por André Vinicius R. P. Nascimento Conteúdo A Linguagem

Leia mais

Capitulo 2. Prof.º Espc. Fábio Margarito Martins de Barros - Tecnologia de banco de dados

Capitulo 2. Prof.º Espc. Fábio Margarito Martins de Barros - Tecnologia de banco de dados Capitulo 2 1. MODELO LÓGICO DE BANCO DE DADOS... 2 1.1 Definição... 2 1.2 Mapeando o modelo conceitual para o modelo lógico... 2 1.2 Dicionário de dados... 3 2. MODELO FÍSICO DO BANCO DE DADOS... 4 2.1

Leia mais

Banco de Dados. Aula 1 - Prof. Bruno Moreno 16/08/2011

Banco de Dados. Aula 1 - Prof. Bruno Moreno 16/08/2011 Banco de Dados Aula 1 - Prof. Bruno Moreno 16/08/2011 Roteiro Apresentação do professor e disciplina Definição de Banco de Dados Sistema de BD vs Tradicional Principais características de BD Natureza autodescritiva

Leia mais

Banco de dados. Linguagens de Banco de Dados II. Wedson Quintanilha da Silva - www.assembla.com/spaces/objetivobd/documents

Banco de dados. Linguagens de Banco de Dados II. Wedson Quintanilha da Silva - www.assembla.com/spaces/objetivobd/documents Banco de dados Linguagens de Banco de Dados II 1 Linguagem de Definição de Dados - DDL Comandos utilizados para criação do esquema de dados; Um DDL permite ao utilizador definir tabelas novas e elementos

Leia mais

Introdução à Banco de Dados. Nathalia Sautchuk Patrício

Introdução à Banco de Dados. Nathalia Sautchuk Patrício Introdução à Banco de Dados Nathalia Sautchuk Patrício Histórico Início da computação: dados guardados em arquivos de texto Problemas nesse modelo: redundância não-controlada de dados aplicações devem

Leia mais

ADMINISTRAÇÃO DE BANCO DE DADOS

ADMINISTRAÇÃO DE BANCO DE DADOS ADMINISTRAÇÃO DE BANCO DE DADOS ARTEFATO 02 AT02 Diversos I 1 Indice ESQUEMAS NO BANCO DE DADOS... 3 CRIANDO SCHEMA... 3 CRIANDO TABELA EM DETERMINADO ESQUEMA... 4 NOÇÕES BÁSICAS SOBRE CRIAÇÃO E MODIFICAÇÃO

Leia mais

Álgebra Relacional. Conjunto de operações que usa uma ou duas relações como entrada e gera uma relação de saída. Operações básicas:

Álgebra Relacional. Conjunto de operações que usa uma ou duas relações como entrada e gera uma relação de saída. Operações básicas: Álgebra Relacional Conjunto de operações que usa uma ou duas relações como entrada e gera uma relação de saída operação (REL 1 ) REL 2 operação (REL 1,REL 2 ) REL 3 Operações básicas: seleção projeção

Leia mais

Dado: Fatos conhecidos que podem ser registrados e têm um significado implícito. Banco de Dados:

Dado: Fatos conhecidos que podem ser registrados e têm um significado implícito. Banco de Dados: MC536 Introdução Sumário Conceitos preliminares Funcionalidades Características principais Usuários Vantagens do uso de BDs Tendências mais recentes em SGBDs Algumas desvantagens Modelos de dados Classificação

Leia mais

Gerenciamento de um Sistema de

Gerenciamento de um Sistema de SBD Gerenciamento de um Sistema de Banco de Dados Prof. Michel Nobre Muza ua michel.muza@ifsc.edu.br Prof. Marcos Antonio Viana Nascimento Por que é importante: Motivação Participar na organização e no

Leia mais

Structured Query Language (SQL) Ambiente Simplificado de um SGBD

Structured Query Language (SQL) Ambiente Simplificado de um SGBD Structured Query Language (SQL) Ambiente Simplificado de um SGBD 2 1 Características dos SGBDs Natureza auto-contida de um sistema de banco de dados: metadados armazenados num catálogo ou dicionário de

Leia mais

BANCO DE DADOS E BUSINESS INTELIGENCE. C/H: 20 horas (20/02, 25/02, 27/02, 04/03, 06/03)

BANCO DE DADOS E BUSINESS INTELIGENCE. C/H: 20 horas (20/02, 25/02, 27/02, 04/03, 06/03) MBA em Gestão de TI MÓDULO: BANCO DE DADOS E BUSINESS INTELIGENCE C/H: 20 horas (20/02, 25/02, 27/02, 04/03, 06/03) PROFESSOR: Edison Andrade Martins Morais prof@edison.eti.br http://www.edison.eti.br

Leia mais

Evolução. Tópicos. Bancos de Dados - Introdução. Melissa Lemos. Evolução dos Sistemas de Informação Esquemas Modelos. Características de SGBDs

Evolução. Tópicos. Bancos de Dados - Introdução. Melissa Lemos. Evolução dos Sistemas de Informação Esquemas Modelos. Características de SGBDs 1 Bancos de Dados - Introdução Melissa Lemos melissa@inf.puc-rio.br Tópicos Evolução dos Sistemas de Informação Esquemas Modelos Conceitual Lógico Características de SGBDs 2 Evolução tempo Programas e

Leia mais

Banco de Dados. Maurício Edgar Stivanello

Banco de Dados. Maurício Edgar Stivanello Banco de Dados Maurício Edgar Stivanello Agenda Conceitos Básicos SGBD Projeto de Banco de Dados SQL Ferramentas Exemplo Dado e Informação Dado Fato do mundo real que está registrado e possui um significado

Leia mais

14/08/2008. Curso Superior de Tecnologia em Banco de Dados Disciplina: Projeto de Banco de Dados Relacional 1 Prof.: Fernando Hadad Zaidan

14/08/2008. Curso Superior de Tecnologia em Banco de Dados Disciplina: Projeto de Banco de Dados Relacional 1 Prof.: Fernando Hadad Zaidan Faculdade INED Curso Superior de Tecnologia em Banco de Dados Disciplina: Projeto de Banco de Dados Relacional 1 Prof.: Fernando Hadad Zaidan 1 Unidade 2 Introdução a SQL 2 Leitura Obrigatória ELMASRI,

Leia mais

UNIVERSIDADE VEIGA DE ALMEIDA CURSO DE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO CURSO SUPERIOR DE TECNOLOGIA EM PROCESSAMENTO DE DADOS BANCO DE DADOS

UNIVERSIDADE VEIGA DE ALMEIDA CURSO DE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO CURSO SUPERIOR DE TECNOLOGIA EM PROCESSAMENTO DE DADOS BANCO DE DADOS CURSO DE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO CURSO SUPERIOR DE TECNOLOGIA EM PROCESSAMENTO DE DADOS CLAUDIO RIBEIRO DA SILVA MARÇO 1997 2 1 - CONCEITOS GERAIS DE 1.1 - Conceitos Banco de Dados - Representa

Leia mais

Banco de Dados I. Aula 12 - Prof. Bruno Moreno 04/10/2011

Banco de Dados I. Aula 12 - Prof. Bruno Moreno 04/10/2011 Banco de Dados I Aula 12 - Prof. Bruno Moreno 04/10/2011 Plano de Aula SQL Definição Histórico SQL e sublinguagens Definição de dados (DDL) CREATE Restrições básicas em SQL ALTER DROP 08:20 Definição de

Leia mais

BANCO DE DADOS CONCEITOS BÁSICOS

BANCO DE DADOS CONCEITOS BÁSICOS Universidade Federal da Paraíba UFPB Centro de Energias Alternativas e Renováveis - CEAR Departamento de Eng. Elétrica DEE BANCO DE DADOS CONCEITOS BÁSICOS Isaac Maia Pessoa Introdução O que é um BD? Operações

Leia mais

SISTEMAS DE BANCO DE DADOS. Prof. Adriano Pereira Maranhão

SISTEMAS DE BANCO DE DADOS. Prof. Adriano Pereira Maranhão SISTEMAS DE BANCO DE DADOS Prof. Adriano Pereira Maranhão 1 REVISÃO BANCO DE DADOS I O que é banco de dados? Ou seja afinal o que é um SGBD? REVISÃO BD I REVISÃO DE BD I Um Sistema de Gerenciamento de

Leia mais

ORACLE 11 G INTRODUÇÃO AO ORACLE, SQL,PL/SQL. Carga horária: 32 Horas

ORACLE 11 G INTRODUÇÃO AO ORACLE, SQL,PL/SQL. Carga horária: 32 Horas ORACLE 11 G INTRODUÇÃO AO ORACLE, SQL,PL/SQL Carga horária: 32 Horas Pré-requisito: Para que os alunos possam aproveitar este treinamento ao máximo, é importante que eles tenham participado dos treinamentos

Leia mais

Bases de Dados II 6638: BSc in Information Systems and Technologies. Cap. 1 Arquitectura de Sistemas de Bases de Dados. Module Introduction

Bases de Dados II 6638: BSc in Information Systems and Technologies. Cap. 1 Arquitectura de Sistemas de Bases de Dados. Module Introduction Bases de Dados II 6638: BSc in Information Systems and Technologies Cap. 1 Module Introduction Objectivos O propósito e a origem da arquitectura de base de dados a três níveis. O conteúdo dos níveis externo,

Leia mais

Introdução. Motivação. Sistema Gerenciador de Banco de Dados (SGBD) Banco de Dados (BD) Sistema de Banco de Dados (SBD)

Introdução. Motivação. Sistema Gerenciador de Banco de Dados (SGBD) Banco de Dados (BD) Sistema de Banco de Dados (SBD) Pós-graduação em Ciência da Computação CCM-202 Sistemas de Banco de Dados Introdução Profa. Maria Camila Nardini Barioni camila.barioni@ufabc.edu.br Bloco B - sala 937 2 quadrimestre de 2011 Motivação

Leia mais

Banco de Dados. StructuredQuery Language- SQL. Prof. Walteno Martins Parreira Jr www.waltenomartins.com.br waltenomartins@yahoo.

Banco de Dados. StructuredQuery Language- SQL. Prof. Walteno Martins Parreira Jr www.waltenomartins.com.br waltenomartins@yahoo. Banco de Dados StructuredQuery Language- SQL Prof. Walteno Martins Parreira Jr www.waltenomartins.com.br waltenomartins@yahoo.com 2015 A Origem Em 1970, Ted Codd (pesquisador da IBM) publicou o primeiro

Leia mais

Banco de Dados. Prof. Antonio

Banco de Dados. Prof. Antonio Banco de Dados Prof. Antonio SQL - Structured Query Language O que é SQL? A linguagem SQL (Structure query Language - Linguagem de Consulta Estruturada) é a linguagem padrão ANSI (American National Standards

Leia mais

Modelo de Dados Relacional Restrições de um Banco de Dados Relacional

Modelo de Dados Relacional Restrições de um Banco de Dados Relacional Modelo de Dados Relacional e as Restrições de um Banco de Dados Relacional Modelo de Dados Relacional Conceitos do Modelo Relacional Representa o banco de dados como uma coleção de relações. Comparação

Leia mais

Universidade Federal de Santa Maria Curso de Arquivologia. Disciplina de Banco de Dados Aplicados à Arquivística. Versao 1.

Universidade Federal de Santa Maria Curso de Arquivologia. Disciplina de Banco de Dados Aplicados à Arquivística. Versao 1. Universidade Federal de Santa Maria Curso de Arquivologia Disciplina de Banco de Dados Aplicados à Arquivística Prof. Andre Zanki Cordenonsi Versao 1.0 Março de 2008 Tópicos Abordados Conceitos sobre Banco

Leia mais

Processamento e Otimização de Consultas

Processamento e Otimização de Consultas Introdução Processamento e Banco de Dados II Prof. Guilherme Tavares de Assis Universidade Federal de Ouro Preto UFOP Instituto de Ciências Exatas e Biológicas ICEB Departamento de Computação DECOM 1 Processamento

Leia mais

Introdução. Unidade 1. Engenharia de Computação / Engenharia de Produção Banco de Dados Prof. Maria das Graças da Silva Teixeira

Introdução. Unidade 1. Engenharia de Computação / Engenharia de Produção Banco de Dados Prof. Maria das Graças da Silva Teixeira Unidade 1 Introdução Engenharia de Computação / Engenharia de Produção Banco de Dados Prof. Maria das Graças da Silva Teixeira Material base: Banco de Dados, 2009.2, prof. Otacílio José Pereira Contexto

Leia mais

Algoritmos para Processamento e Otimização de Consultas. Adriano Douglas Girardello Ana Paula Fredrich Tiago Alexandre Schulz Sippert

Algoritmos para Processamento e Otimização de Consultas. Adriano Douglas Girardello Ana Paula Fredrich Tiago Alexandre Schulz Sippert UNIOESTE Universidade Estadual do Oeste do Paraná CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS Colegiado de Informática Curso de Bacharelado em Informática Algoritmos para Processamento e Otimização de Consultas

Leia mais

Aula 02 Modelagem de Dados. Banco de Dados. Aula 02 Modelagem de Dados. Superior /2011 Redes Computadores - Disciplina: Banco de Dados -

Aula 02 Modelagem de Dados. Banco de Dados. Aula 02 Modelagem de Dados. Superior /2011 Redes Computadores - Disciplina: Banco de Dados - Banco de Dados Aula 02 Modelagem de Dados Roteiro Definição Evolução Projeto de BD Abstração Esquema e Instância Definição É uma representação, normalmente gráfica, de estruturas de dados reais. Auxilia

Leia mais

SQL Structured Query Language

SQL Structured Query Language Janai Maciel SQL Structured Query Language (Banco de Dados) Conceitos de Linguagens de Programação 2013.2 Structured Query Language ( Linguagem de Consulta Estruturada ) Conceito: É a linguagem de pesquisa

Leia mais

PROVA ESPECÍFICA Cargo 04

PROVA ESPECÍFICA Cargo 04 10 PROVA ESPECÍFICA Cargo 04 QUESTÃO 21 Analise as seguintes afirmativas: I. Uma das funções de um DBA é gerenciar os mecanismos de segurança de acesso aos dados armazenados em um SGBD (Sistema Gerenciador

Leia mais

Curso Superior de Tecnologia em BD Curso Superior de Tecnologia em DAI

Curso Superior de Tecnologia em BD Curso Superior de Tecnologia em DAI Curso Superior de Tecnologia em BD Curso Superior de Tecnologia em DAI Fundamentos de Banco de Dados Aula 01 Introdução aos Sistemas de Bancos de Dados Introdução aos Sistemas de BD Objetivo Apresentar

Leia mais

BANCO DE DADOS. Introdução a Banco de Dados. Conceitos BásicosB. Engenharia da Computação UNIVASF. Aula 1. Breve Histórico

BANCO DE DADOS. Introdução a Banco de Dados. Conceitos BásicosB. Engenharia da Computação UNIVASF. Aula 1. Breve Histórico Banco de Dados // 1 Banco de Dados // 2 Conceitos BásicosB Engenharia da Computação UNIVASF BANCO DE DADOS Aula 1 Introdução a Banco de Dados Campo representação informatizada de um dado real / menor unidade

Leia mais

Banco de Dados Aula 1 Introdução a Banco de Dados Introdução Sistema Gerenciador de Banco de Dados

Banco de Dados Aula 1 Introdução a Banco de Dados Introdução Sistema Gerenciador de Banco de Dados Banco de Dados Aula 1 Introdução a Banco de Dados Introdução Um Sistema Gerenciador de Banco de Dados (SGBD) é constituído por um conjunto de dados associados a um conjunto de programas para acesso a esses

Leia mais

SQL Linguagem de Definição de Dados. Banco de Dados Profa. Dra. Cristina Dutra de Aguiar Ciferri

SQL Linguagem de Definição de Dados. Banco de Dados Profa. Dra. Cristina Dutra de Aguiar Ciferri SQL Linguagem de Definição de Dados Banco de Dados SQL Structured Query Language Uma das mais importantes linguagens relacionais (se não a mais importante) Exemplos de SGBD que utilizam SQL Oracle Informix

Leia mais

Banco de Dados II. Introdução Revisão - normalização -modelagem - sql básico

Banco de Dados II. Introdução Revisão - normalização -modelagem - sql básico Banco de Dados II Introdução Revisão - normalização -modelagem - sql básico Prof. Rodrigo Rocha prof.rodrigorocha@yahoo.com http://www.bolinhabolinha.com Apresentação Prof. Rodrigo Rocha prof.rodrigorocha@yahoo.com

Leia mais

António Rocha Nuno Melo e Castro

António Rocha Nuno Melo e Castro António Rocha Nuno Melo e Castro SQL- Strutured Query Language é a linguagem mais usada nas bases dados relacionais. Originalmente desenvolvida pela IBM Actualmente é um standard, o mais recente é o SQL:2003

Leia mais

Básico da Linguagem SQL. Definição de Esquemas em SQL. SQL(Structured Query Language)

Básico da Linguagem SQL. Definição de Esquemas em SQL. SQL(Structured Query Language) Básico da Linguagem SQL Definição de Esquemas em SQL SQL(Structured Query Language) Desenvolvida como a linguagem de consulta do protótipo de SGBD Sistema R (IBM, 1976). Adotada como linguagem padrão de

Leia mais

Faculdade Lourenço Filho - ENADE 2011-1

Faculdade Lourenço Filho - ENADE 2011-1 1. Quando se constrói um banco de dados, define-se o modelo de entidade e relacionamento (MER), que é a representação abstrata das estruturas de dados do banco e seus relacionamentos. Cada entidade pode

Leia mais

SQL. Histórico BANCO DE DADOS. Conceito. Padrões de SQL (1) Componentes do SQL (1) Padrões de SQL (2) (DDL: CREATE TABLE, CONSTRAINTS)

SQL. Histórico BANCO DE DADOS. Conceito. Padrões de SQL (1) Componentes do SQL (1) Padrões de SQL (2) (DDL: CREATE TABLE, CONSTRAINTS) BANCO DE DADOS SQL (DDL: CREATE TABLE, CONSTRAINTS) Prof. Edson Thizon Histórico Entre 1974 e 1979, o San José Research Laboratory da IBM desenvolveu um SGDB relacional que ficou conhecido como Sistema

Leia mais

PostgreSQL Performance

PostgreSQL Performance PostgreSQL Performance André Restivo Faculdade de Engenharia da Universidade do Porto February 24, 2012 André Restivo (FEUP) PostgreSQL Performance February 24, 2012 1 / 45 Sumário 1 Armazenamento 2 Índices

Leia mais

UNIVERSIDADE FEDERAL DE SANTA MARIA - UFSM COLÉGIO AGRÍCOLA DE FREDERICO WESTPHALEN BANCO DE DADOS II

UNIVERSIDADE FEDERAL DE SANTA MARIA - UFSM COLÉGIO AGRÍCOLA DE FREDERICO WESTPHALEN BANCO DE DADOS II UNIVERSIDADE FEDERAL DE SANTA MARIA - UFSM COLÉGIO AGRÍCOLA DE FREDERICO WESTPHALEN BANCO DE DADOS II BANCO DE DADOS II AULA 1 Linguagem SQL Linguagem de definição de dados (DDL) DISCIPLINA: Banco de Dados

Leia mais

Banco de Dados. Otimização de consultas. Prof. Joao Eduardo Ferreira Prof. Osvaldo Kotaro Takai. Última atualização: 15 de maio de 2006

Banco de Dados. Otimização de consultas. Prof. Joao Eduardo Ferreira Prof. Osvaldo Kotaro Takai. Última atualização: 15 de maio de 2006 Banco de Dados Otimização de consultas Última atualização: 15 de maio de 2006 Prof. Joao Eduardo Ferreira Prof. Osvaldo Kotaro Takai Introdução Consulta em linguagem de alto nível Análise e validação Forma

Leia mais

SQL SQL BANCO DE DADOS 2. Componentes do SQL (1) Componentes do SQL (2) DDL Criação de banco de dados. Padrões de SQL

SQL SQL BANCO DE DADOS 2. Componentes do SQL (1) Componentes do SQL (2) DDL Criação de banco de dados. Padrões de SQL BANCO DE DADOS 2 SQL (CREATE TABLE, CONSTRAINTS, DELETE, UPDATE e INSERT) Prof. Edson Thizon SQL SQL ( structured query language ) é uma linguagem comercial de definição e manipulação de banco de dados

Leia mais

SQL BANCO DE DADOS. Linguagem de consulta SQL. Linguagem de consulta SQL. Linguagem de Consulta Estruturada

SQL BANCO DE DADOS. Linguagem de consulta SQL. Linguagem de consulta SQL. Linguagem de Consulta Estruturada Revisão de tpicos anteriores BANCO DE DADOS Linguagem de consulta SQL Roberto Duarte Fontes Brasília - DF roberto@fontes.pro.br Projeto de banco de dados Modelagem Conceitual (independe da implementação)

Leia mais

Banco de Dados. Introdução. João Eduardo Ferreira Osvaldo Kotaro Takai. jef@ime.usp.br DCC-IME-USP

Banco de Dados. Introdução. João Eduardo Ferreira Osvaldo Kotaro Takai. jef@ime.usp.br DCC-IME-USP Banco de Dados Introdução João Eduardo Ferreira Osvaldo Kotaro Takai jef@ime.usp.br DCC-IME-USP Importância dos Bancos de Dados A competitividade das empresas depende de dados precisos e atualizados. Conforme

Leia mais

Linguagem de Consulta Estruturada (SQL)

Linguagem de Consulta Estruturada (SQL) Linguagem de Consulta Estruturada (SQL) Conceitos sobre a versão ANSI da SQL, a sublinguagem de definição de dados (DDL) e a sublinguagem de manipulação de dados (DML) Prof. Flavio Augusto C. Correia 1

Leia mais

Banco de Dados. Marcio de Carvalho Victorino www.dominandoti.eng.br. Exercícios SQL

Banco de Dados. Marcio de Carvalho Victorino www.dominandoti.eng.br. Exercícios SQL Banco de Dados Exercícios SQL 1 TRF (ESAF 2006) 32. Analise as seguintes afirmações relacionadas a Bancos de Dados e à linguagem SQL: I. A cláusula GROUP BY do comando SELECT é utilizada para dividir colunas

Leia mais

FEAP - Faculdade de Estudos Avançados do Pará PROFª LENA VEIGA PROJETOS DE BANCO DE DADOS UNIDADE V- SQL

FEAP - Faculdade de Estudos Avançados do Pará PROFª LENA VEIGA PROJETOS DE BANCO DE DADOS UNIDADE V- SQL Quando os Bancos de Dados Relacionais estavam sendo desenvolvidos, foram criadas linguagens destinadas à sua manipulação. O Departamento de Pesquisas da IBM desenvolveu a SQL como forma de interface para

Leia mais

2008.1 SQL. Autor: Renata Viegas

2008.1 SQL. Autor: Renata Viegas SQL Autor: Renata Viegas A linguagem SQL SQL - Structured Query Language. Foi definida nos laboratórios de pesquisa da IBM em San Jose, California, em 1974. Teve seus fundamentos no modelo relacional Sua

Leia mais

Roteiro 2 Conceitos Gerais

Roteiro 2 Conceitos Gerais Roteiro 2 Conceitos Gerais Objetivos: UC Projeto de Banco de Dados Explorar conceitos gerais de bancos de dados; o Arquitetura de bancos de dados: esquemas, categorias de modelos de dados, linguagens e

Leia mais

BANCO DE DADOS Parte 4

BANCO DE DADOS Parte 4 BANCO DE DADOS Parte 4 A Linguagem SQL Introdução Desenvolvida pelo depto de pesquisa da IBM na década de 1970 (System R) Linguagem padrão de BD Relacionais; Apresenta várias padrões evolutivos: SQL86,

Leia mais

2008.1. A linguagem SQL

2008.1. A linguagem SQL SQL 2008.1 A linguagem SQL SQL - Structured Query Language. Foi definida nos laboratórios de pesquisa da IBM em San Jose, California, em 1974. Teve seus fundamentos no modelo relacional Sua primeira versão

Leia mais

Banco de Dados Oracle 10g: Introdução à Linguagem SQL

Banco de Dados Oracle 10g: Introdução à Linguagem SQL Oracle University Entre em contato: 0800 891 6502 Banco de Dados Oracle 10g: Introdução à Linguagem SQL Duração: 5 Dias Objetivos do Curso Esta classe se aplica aos usuários do Banco de Dados Oracle8i,

Leia mais

Introdução a Computação

Introdução a Computação Introdução a Computação Aula 04 SGBD Sistemas Gerenciadores de Bancos de Dados Prof. MSc. Edilberto Silva edilms@yahoo.com Conceitos Básicos DADOS: são fatos em sua forma primária. Ex: nome do funcionário,

Leia mais

SQL DDL. Frederico D. Bortoloti freddb@ltc.ufes.br

SQL DDL. Frederico D. Bortoloti freddb@ltc.ufes.br Banco de Dados I SQL DDL Frederico D. Bortoloti freddb@ltc.ufes.br Introdução Modelo relacional encontra-se padronizado pela indústria de informática. Ele é chamado de padrão SQL (Structured Query Language)

Leia mais

Operação de União JOIN

Operação de União JOIN Operação de União JOIN Professor Victor Sotero SGD 1 JOIN O join é uma operação de multi-tabelas Select: o nome da coluna deve ser precedido pelo nome da tabela, se mais de uma coluna na tabela especificada

Leia mais

S Q L 31/03/2010. SQL - Structured Query Language Linguagem de Consulta Estruturada

S Q L 31/03/2010. SQL - Structured Query Language Linguagem de Consulta Estruturada Gerenciamento de Dados e Informação Fernando Fonseca Ana Carolina Robson Fidalgo SQL SQL - Structured Query Language Linguagem de Consulta Estruturada Apesar do QUERY no nome, não é apenas de consulta,

Leia mais

Unidade 5 Armazenamento e Indexação

Unidade 5 Armazenamento e Indexação Unidade 5 Armazenamento e Indexação Engenharia de Computação / Engenharia de Produção Banco de Dados Prof. Maria das Graças da Silva Teixeira Material base: Banco de Dados, 2009.2, prof. Otacílio José

Leia mais

Banco de Dados I. Introdução. Fabricio Breve

Banco de Dados I. Introdução. Fabricio Breve Banco de Dados I Introdução Fabricio Breve Introdução SGBD (Sistema Gerenciador de Banco de Dados): coleção de dados interrelacionados e um conjunto de programas para acessar esses dados Coleção de dados

Leia mais

Structured Query Language (SQL) Aula Prática

Structured Query Language (SQL) Aula Prática Structured Query Language (SQL) Aula Prática Linguagens de SGBD Durante o desenvolvimento do sistema R, pesquisadores da IBM desenvolveram a linguagem SEQUEL, primeira linguagem de acesso para Sistemas

Leia mais

Introdução à Engenharia da Computação. Banco de Dados Professor Machado

Introdução à Engenharia da Computação. Banco de Dados Professor Machado Introdução à Engenharia da Computação Banco de Dados Professor Machado 1 Sistemas isolados Produção Vendas Compras Banco de Dados Produtos... Banco de Dados Produtos... Banco de Dados Produtos... Desvantagens:

Leia mais

UFCD 787. Administração de base de dados. Elsa Marisa S. Almeida

UFCD 787. Administração de base de dados. Elsa Marisa S. Almeida UFCD 787 Administração de base de dados Elsa Marisa S. Almeida 1 Objectivos Replicação de base de dados Gestão de transacções Cópias de segurança Importação e exportação de dados Elsa Marisa S. Almeida

Leia mais

Gabarito - Banco de Dados SQL - 30/07/2013 AULA 01

Gabarito - Banco de Dados SQL - 30/07/2013 AULA 01 Gabarito - Banco de Dados SQL - 30/07/2013 AULA 01 1 1- Bancos de dados compreendem desde agendas telefônicas até sistemas computadorizados. (Sim) 2- Só podemos instalar o SQL Server Express se tivermos

Leia mais

Tuning em queries em Banco de Dados

Tuning em queries em Banco de Dados Tuning em queries em Banco de Dados Alison K. L. Leite 1, Izabella C. A. M. S. Bosco 1, Juliana M. Massoni 1, Patrícia B. Ribeiro 1 1 Curso de Tecnologia em Banco de Dados - Faculdade de Tecnologia de

Leia mais

FACULDADE INTEGRADAS DE PARANAÍBA ADMINISTRAÇÃO DE EMPRESAS. Bancos de Dados Conceitos Fundamentais

FACULDADE INTEGRADAS DE PARANAÍBA ADMINISTRAÇÃO DE EMPRESAS. Bancos de Dados Conceitos Fundamentais FACULDADE INTEGRADAS DE PARANAÍBA ADMINISTRAÇÃO DE EMPRESAS Bancos de Dados Conceitos Fundamentais Tópicos Conceitos Básicos Bancos de Dados Sistemas de Bancos de Dados Sistemas de Gerenciamento de Bancos

Leia mais

Introdução a Sistemas de Bancos de Dados

Introdução a Sistemas de Bancos de Dados Introdução a Sistemas de Bancos de Dados Prof. UFES - Universidade Federal do Espírito Santo rapchan@inf.ufes.br http://www.inf.ufes.br/~rapchan Roteiro da Apresentação Introdução Características de um

Leia mais

Sistema de Processamento de Arquivos

Sistema de Processamento de Arquivos Banco de Dados Banco de Dados; Sistema de Gerenciamento de Banco de Dados; Modelo Entidade-Relacionamento; Banco de Dados Relacional; Banco de Dados Distribuído; Banco de Dados Federado; Projeto de Banco

Leia mais

Banco de Dados. Uma coleção de dados relacionados [ELMASRI/NAVATHE]

Banco de Dados. Uma coleção de dados relacionados [ELMASRI/NAVATHE] 1/6 Banco de Dados O que é um Banco de Dados? Uma coleção de dados relacionados [ELMASRI/NAVATHE] Conjunto de dados integrados que tem por objetivo atender a uma comunidade específica [HEUSER] Um conjunto

Leia mais

Exercícios de Lógica Exercícios de Fixação 08

Exercícios de Lógica Exercícios de Fixação 08 Exercícios Exercícios de Lógica Exercícios de Fixação 08 1. A linguagem SQL apresenta uma série de comandos que permitem a definição dos dados, chamada de DDL (Data Definition Language). Assinale a alternativa

Leia mais

S Q L 15/01/2013. Enfoques de SQL. Enfoques de SQL SQL. Usos de SQL. SQL - Origem/Histórico. Gerenciamento de Dados e Informação

S Q L 15/01/2013. Enfoques de SQL. Enfoques de SQL SQL. Usos de SQL. SQL - Origem/Histórico. Gerenciamento de Dados e Informação Enfoques de SQL Gerenciamento de Dados e Informação Fernando Fonseca Ana Carolina Valeria Times Bernadette Loscio Linguagem interativa de consulta (ad-hoc): usuários podem definir consultas independente

Leia mais

Ex.: INSERT INTO tmpautor (CDAUTOR, NMAUTOR) VALUES (1, Renato Araújo )

Ex.: INSERT INTO tmpautor (CDAUTOR, NMAUTOR) VALUES (1, Renato Araújo ) PRONATEC - Programador de Sistemas Banco de Dados 1) Incluindo linhas nas tabelas a. Para incluir linhas em tabelas utilize o comando INSERT INTO INSERT INTO tabela [ ( coluna [, coluna,...] ) ] VALUES

Leia mais

Introdução Banco de Dados

Introdução Banco de Dados Introdução Banco de Dados Vitor Valerio de Souza Campos Adaptado de Vania Bogorny Por que estudar BD? Os Bancos de Dados fazem parte do nosso dia-a-dia: operação bancária reserva de hotel matrícula em

Leia mais

Banco de Dados. Módulo 7 - Modelo Relacional. Definição do Esquema Relacional em SQL. modulo07.prz 1 10/09/01

Banco de Dados. Módulo 7 - Modelo Relacional. Definição do Esquema Relacional em SQL. modulo07.prz 1 10/09/01 Banco de Dados Módulo 7 - Modelo Relacional Definição do Esquema Relacional em SQL modulo07.prz 1 10/09/01 Introdução SQL linguagem padrão para SGBDs relacionais derivada do SEQUEL (Structured English

Leia mais

Sistema de Bancos de Dados. Conceitos Gerais Sistema Gerenciador de Bancos de Dados

Sistema de Bancos de Dados. Conceitos Gerais Sistema Gerenciador de Bancos de Dados Sistema de Bancos de Dados Conceitos Gerais Sistema Gerenciador de Bancos de Dados # Definições # Motivação # Arquitetura Típica # Vantagens # Desvantagens # Evolução # Classes de Usuários 1 Nível 1 Dados

Leia mais

LINGUAGEM SQL. DML - Linguagem de Manipulação de Dados

LINGUAGEM SQL. DML - Linguagem de Manipulação de Dados LINGUAGEM SQL Structured Query Language, ou Linguagem de Consulta Estruturada ou SQL, é uma linguagem de pesquisa declarativa para banco de dados relacional (base de dados relacional). Muitas das características

Leia mais

DDL, Lidando com as diferenças das instruções SQL nos diferentes SGBD s

DDL, Lidando com as diferenças das instruções SQL nos diferentes SGBD s DDL, Lidando com as diferenças das instruções SQL nos diferentes SGBD s Dio Rafael Jacobs 1, Juliano Varella de Carvalho 1 1 Centro Universitário Feevale Instituto de Ciência Exatas e Tecnológicas Novo

Leia mais

Revisão de Banco de Dados

Revisão de Banco de Dados Revisão de Banco de Dados Fabiano Baldo 1 Sistema de Processamento de Arquivos Antes da concepção dos BDs o registro das informações eram feitos através de arquivos. Desvantagens: Redundância e Inconsistência

Leia mais

LINGUAGEM SQL. SQL Server 2008 Comandos iniciais

LINGUAGEM SQL. SQL Server 2008 Comandos iniciais 1 LINGUAGEM SQL SQL Server 2008 Comandos iniciais SQL - STRUCTURED QUERY LANGUAGE Quando os Bancos de Dados Relacionais estavam sendo desenvolvidos, foram criadas linguagens destinadas à sua manipulação.

Leia mais

Introdução a Banco de Dados

Introdução a Banco de Dados Introdução a Banco de Dados O modelo relacional Marta Mattoso Sumário Introdução Motivação Serviços de um SGBD O Modelo Relacional As aplicações não convencionais O Modelo Orientado a Objetos Considerações

Leia mais

Esta aula tem o objetivo de nos orientar durante este período em nossas aulas de Banco de Dados, não tem a pretensão de ser a única fonte de

Esta aula tem o objetivo de nos orientar durante este período em nossas aulas de Banco de Dados, não tem a pretensão de ser a única fonte de BD Esta aula tem o objetivo de nos orientar durante este período em nossas aulas de Banco de Dados, não tem a pretensão de ser a única fonte de informação para nosso êxito no curso. A intenção de elaborar

Leia mais

SQL Linguagem de Manipulação de Dados. Banco de Dados Profa. Dra. Cristina Dutra de Aguiar Ciferri

SQL Linguagem de Manipulação de Dados. Banco de Dados Profa. Dra. Cristina Dutra de Aguiar Ciferri SQL Linguagem de Manipulação de Dados Banco de Dados SQL DML SELECT... FROM... WHERE... lista atributos de uma ou mais tabelas de acordo com alguma condição INSERT INTO... insere dados em uma tabela DELETE

Leia mais

Dicas de Projeto Lógico Relacional

Dicas de Projeto Lógico Relacional Dicas de Projeto Lógico Relacional O que deve ser especificado? mapeamento do esquema conceitual definição das tabelas e chaves justificativas de mapeamento (se necessário) restrições de integridade (RIs)

Leia mais