Trabalho de SBD Estudo do sistema POSTGRESQL

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

Download "Trabalho de SBD Estudo do sistema POSTGRESQL"

Transcrição

1 Trabalho de SBD Estudo do sistema POSTGRESQL João Miguel Vaz, Ricardo Vaz Alves, Vasco Jorge Pessanha, 31235

2 Índice 1. Introdução: História dos SGBDs História do PostgreSQL Aplicabilidade e Actualidade do PostgreSQL Cobertura do SQL Cobertura DDL Cobertura DML Armazenamento e file structure File System Paginação Partições Clustering Buffer Management Indexação e Hashing Introdução Tipos de Índices Índices para organização de ficheiros Outras Informações Processamento e Optimização de Perguntas Percurso de Uma Interrogação Ligação ao Servidor Etapa de Parsing Planificador / Optimizador Executor Algoritmos para operações básicas Mecanismos de Avaliação de Expressões Complexas Tabelas e Views Estatísticas Mais estimativas Como é que o Planificador Utiliza as Estatísticas (Estimativas de Linhas) Mecanismos de Visualização de Planos de Perguntas Gestão de transacções e controlo de concorrência Definição de transacção Propriedades ACID das transacções

3 6.3. Estado de uma transacção Controlo de Concorrência Transacções e Gestão de Concorrência no PostgreSQL Consistência de Dados no PostgreSQL Atomicidade e Durabilidade no PostgreSQL Mecanismos de Rollback e recuperação no PostgreSQL Diferir a verificação para o final das transacções Suporte para bases de dados distribuídas Outras características do sistema estudado XML Procedimentos / Triggers Segurança Tipos de Dados Ferramentas Adicionais Conclusão Bibliografia

4 1. Introdução: O sistema de gestão de bases de dados (SGBD) que iremos abordar será o PostgreSQL (muitas vezes referido apenas como Postgres). Como tal, faremos primeiro uma pequena abordagem à história dos SGBD, seguida duma introdução ao sistema acima referido, nomeadamente à sua criação e desenvolvimento, aplicabilidade e capacidades. Note-se que não será referido qualquer tipo de instalação do sistema, já que a mesma é trivial, bastando-se fazer o download do site oficial (gratuito), e seguir as instruções da instalação (semelhante à instalação de qualquer outra aplicação) História dos SGBDs Os SGBDs (Sistemas de Gestão de Bases de dados) apareceram nos anos 60, à medida que a capacidade e velocidade dos computadores aumentavam. São constituídos por software que é responsável pela manutenção, gestão de acessos, e organização de dados, oferecendo uma agradável abstracção ao cliente, tal como mostra a Figura 1. Figura 1 Esquema de um SGBD, fazendo a ponte entre as aplicações e a base de dados Ao longo do tempo, os SGBD foram-se tornando cada vez mais eficientes, fornecendo inúmeras particularidades que melhoram a utilização das bases de dados, aumentando a velocidade, consistência, e segurança dos acessos. Os SGBDs actuais oferecem segurança, backups e replicações para recuperação de falhas do equipamento como discos, implementação de restrições (como primary e foreign keys), optimização de perguntas, modelos para definir esquemas de dados armazenados no sistema, estruturas de dados preparadas para suportar grandes quantidades de dados, etc. Para além de implementarem isto tudo, fazem-no quase sempre de forma automática, simples e transparente para o utilizador (mesmo que o utilizador não refira como quer aceder aos 4

5 dados, os SGBD usam optimizações baseadas em estatísticas no acesso dos mesmos, que aumentam a eficiência e rapidez das queries) História do PostgreSQL O PostgreSQL é hoje constituído por uma comunidade de pessoas que são responsáveis pela manutenção do sistema (incluindo manutenção do site, da documentação, e das FAQs), tradução, correcção de bugs, testes de performance, etc. A primeira referência que há do PostgreSQL é o INGRES (INteractive Graphics REtrieval System), um projecto de investigação da Universidade de Berkeley (Califórnia) do final dos anos 70, que desenvolvia um SGBD Relacional Open Source desenhado para suportar grandes aplicações comerciais e governamentais. Em 1986, o professor Michael Stonebraker liderou o projecto POSTGRES que não era mais do que o sucessor do primeiro ( POST Ingres ). Este projecto conseguiu grandes patrocinadores fazendo com que o sistema aumentasse a sua robustez e crescesse bastante, passando a implementar um grande número de funcionalidades novas. Desse conjunto de patrocinadores destacam-se: Defense Advanced Research Projects Agency (DARPA), Army Research Office (ARO), National Science Foundation (NSF). Nos dez anos seguintes (até 1995), o Postgres foi crescendo exponencialmente sendo constantemente alterado em sucessivas versões que tentaram focar-se na portabilidade, versatilidade e fiabilidade do sistema. Só em 1993, a comunidade de utilizadores externos do Postgres duplicou. Em 1994 Andrew Yu e Jolly Chen adicionaram um interpretador da linguagem SQL ao sistema. Este feito foi de tal maneira importante que viria a mudar o nome do SGBD para POSTGRES95 (lançado, como o nome indica, no ano de 1995). Esta nova versão incluiu importantes mudanças no que diz respeito a correcção de erros, melhoramentos da performance e da facilidade de manutenção, e ainda foram adicionados vários recursos (exemplo disso foi a introdução da cláusula vulgar groupby). Esta versão foi disponibilizada na Web como opensource juntamente com um tutorial que agrupava funcionalidades regulares do SQL e do Postgres95. Esta decisão viria a impulsionar drasticamente o crescimento deste sistema. No ano seguinte, o nome Postgres95 tornou-se obsoleto, pelo que passou a ser intitulado PostgreSQL, para realçar a interacção do antigo sistema com a linguagem SQL. A primeira versão com este nome correspondeu à versão 6.0 do antigo sistema e, ao contrário das primeiras versões que se baseavam na correcção de falhas e optimização de código, nesta versão os esforços foram canalizados para a expansão do sistema melhorado com a implementação de novos recursos. Desde esta última versão, o Postgres (nome pelo qual também é reconhecido ainda hoje) foi crescendo tornando-se um dos grandes nomes no que toca a sistemas de gestão de bases de dados, servindo desde pequenos programadores, até grandes empresas. A última versão deste sistema (versão 8.4.1) data de 09/09/2009, oferecendo uma panóplia de funcionalidades novas, mantendo porém compatibilidade com versões mais antigas. 5

6 1.3. Aplicabilidade e Actualidade do PostgreSQL Como foi visto anteriormente, o PostgreSQL é hoje em dia um sistema muito poderoso, sofisticado, estável, com alta performance, implementando praticamente todas as funcionalidades requeridas pelos clientes. Por outro lado é um sistema Open Source gratuito, acessível e de fácil utilização e instalação. Este sistema suporta bases de dados bastante extensas, adequadas ao uso de uma grande empresa. No quadro seguinte podemos observar as capacidades do PostgreSQL, percebendo assim que não existe qualquer tipo de limitação para grandes bases de dados: Tamanho máximo da Base de Dados Ilimitado * Tamanho máximo de uma tabela 64 TB Tamanho máximo de uma linha de uma tabela 1.6 TB Número máximo de indexes por tabela Ilimitado * * - Note-se que ilimitado significa que não há qualquer restrição por parte do PostgreSQL ou seja, tendo apenas as limitações do espaço livre em disco. Actualmente, a solução PostgreSQL+Linux é muito utilizada pelas mais variadas empresas. Esta constitui um exemplo de como os produtos Open Source podem oferecer um grande serviço a pequenas e grandes empresas evitando custos de licenças, ajudando-as assim a racionalizar os custos das tecnologias de informação. O PostgreSQL é ainda um sistema bastante versátil, suportando praticamente todos os sistemas operacionais tais como Linux, Mac OS, Solaris, Windows, etc. É usado ainda por grandes empresas no mundo da informática tais como Apple ou Cisco, e noutros ramos como é o caso da OMS (Organização Mundial de Saúde). Na figura seguinte podemos observar alguns dos maiores patrocinadores do projecto PostgreSQL: Figura 2 Logótipos de alguns dos maiores patrocinadores do PostgreSQL Concluímos assim, que a nível da aplicabilidade do sistema, o PostgreSQL é potente o suficiente para ser usado por grandes empresas que precisam de grande estabilidade por parte do SGBD, mas por outro lado é fácil de usar, leve e prático para uma gestão de uma base de dados 6

7 caseira. O sistema é por isso muito completo, podendo ser usado para praticamente qualquer situação. 7

8 2. Cobertura do SQL Como já foi referido e o próprio nome indica, o PostgreSQL utiliza um interpretador de SQL, pelo que para além da linguagem de perguntas usada pelo utilizador ser o SQL, praticamente todas as operações do SQL são suportadas pelo PostgreSQL Cobertura DDL Por definição, o DDL (Data Definition Language) é uma linguagem que disponibiliza comandos que permitem ao utilizador criar estruturas de dados. Em base de dados é usado portanto para criar as estruturas que irão suportar os dados guardados pela mesma, disponibilizando para isso uma panóplia de comandos tais como a criação, remoção e alteração de tabelas, triggers ou regras Criação de Tabelas A sintaxe do comando que permite a criação de uma tabela é bastante complexa já que suporta diversas opções para o utilizador, tais como definição directa de restrições sobre um ou mais atributos, chaves primárias e estrangeiras, se as operações sobre a tabela têm de ser verificadas ou não aquando de uma operação, etc. A sintaxe completa é mostrada de seguida (tal como na documentação do PostgreSQL, a sintaxe foi repartida em diversas partes para tornar a sua leitura mais perceptível): CREATE [ [ GLOBAL LOCAL ] { TEMPORARY TEMP } ] TABLE table_name ([ { column_name data_type [ DEFAULT default_expr ] [ column_constraint [... ] ] table_constraint LIKE parent_table [ { INCLUDING EXCLUDING } { DEFAULTS CONSTRAINTS INDEXES } ]... } [,... ] ] ) [ INHERITS ( parent_table [,... ] ) ] [ WITH( storage_parameter [= value][,... ]) WITH OIDS WITHOUT OIDS] [ ON COMMIT { PRESERVE ROWS DELETE ROWS DROP } ] [ TABLESPACE tablespace ] Sendo que column_constraint corresponde a: [ CONSTRAINT constraint_name ] { NOT NULL NULL UNIQUE index_parameters PRIMARY KEY index_parameters CHECK ( expression ) REFERENCES reftable [ ( refcolumn ) ] [ MATCH FULL MATCH PARTIAL MATCH SIMPLE ] [ ON DELETE action ] [ ON UPDATE action ] } [DEFERRABLE NOT DEFERRABLE] [INITIALLY DEFERRED INITIALLY IMMEDIATE] Sendo que table_constraint corresponde também a: [ CONSTRAINT constraint_name ] { UNIQUE ( column_name [,... ] ) index_parameters PRIMARY KEY ( column_name [,... ] ) index_parameters 8

9 CHECK ( expression ) FOREIGN KEY ( column_name [,... ] ) REFERENCES reftable [ ( refcolumn [,... ] ) ] [ MATCH FULL MATCH PARTIAL MATCH SIMPLE ] [ ON DELETE action ] [ ON UPDATE action ] } [ DEFERRABLE NOT DEFERRABLE ] [ INITIALLY DEFERRED INITIALLY IMMEDIATE ] Nas cláusulas UNIQUE e PRIMARY KEY, índex_parameters corresponde ainda a: [ WITH ( storage_parameter [= value] [,... ] ) ] [ USING INDEX TABLESPACE tablespace ] Em seguida abordaremos algumas das cláusulas que nos parecem mais úteis e importantes. Uma delas é a cláusula UNIQUE que permite criar uma restrição que obriga a que uma determinada coluna ou um conjunto de colunas só suportem valores únicos (pelo que a inserção de um valor repetido é detectada, e rejeitada). Outra propriedade interessante é a possibilidade de herança de colunas de outras tabelas sendo que são suportadas duas abordagens distintas: cópia, e apontador. A primeira é feita através da cláusula LIKE onde as colunas de determinada tabela são simplesmente copiadas (juntamente com as restrições, tipos e propriedades associadas). A segunda é conseguida com o uso da cláusula INHERITS que, não só copia as colunas das outras tabelas tal como a primeira, como garante que alterações na definição dessas colunas são propagadas para as colunas da tabela a ser criada. Por outro lado, todas as colunas das tabelas, por defeito, tomam o valor null se este for permitido. No entanto, pode ser utilizada a cláusula DEFAULT que atribui por defeito um valor definido aquando da declaração da tabela ou ainda, de forma mais sofisticada, um valor retirado de uma determinada sequência previamente declarada. O exemplo seguinte mostra os vários tipos de aplicações desta cláusula: CREATE TABLE countries ( name varchar(40) DEFAULT 'Portugal', id integer DEFAULT nextval('people_id_sequence'), time timestamp DEFAULT current_timestamp ); O PostgreSQL suporta ainda outro tipo de criação de tabela, através de subqueries. Para isso é usado o comando CREATE TABLE AS que, tal como o nome indica, cria uma tabela que é construída através do resultado de uma determinada pesquisa (que pode ser feita numa ou mais tabelas): CREATE [ [ GLOBAL LOCAL ] { TEMPORARY TEMP } ] TABLE table_name [ (column_name [,...] ) ] [WITH(storage_parameter[=value][,...]) WITH OIDS WITHOUT OIDS] [ ON COMMIT { PRESERVE ROWS DELETE ROWS DROP } ] [ TABLESPACE tablespace ] AS query [ WITH [ NO ] DATA ] 9

10 Alterações de Tabelas O PostgreSQL permite inúmeros tipos de alterações de tabelas, desde renomeações da própria tabela ou de colunas, alterações nos tipos e restrições de cada coluna, até mesmo à criação ou remoção de uma coluna. Observando as seguintes sintaxes, percebemos que a alteração de dados é conseguida de forma perceptível e trivial: ALTER TABLE [ ONLY ] name [ * ] action [,... ] ALTER TABLE [ ONLY ] name [ * ] RENAME [ COLUMN ] column TO new_column ALTER TABLE name RENAME TO new_name ALTER TABLE name SET SCHEMA new_schema Sendo que o parâmetro action corresponde a: ADD [ COLUMN ] column type [ column_constraint [... ] ] DROP [ COLUMN ] column [ RESTRICT CASCADE ] ALTER [ COLUMN ] column [ SET DATA ] TYPE type [ USING expression] ALTER [ COLUMN ] column SET DEFAULT expression ALTER [ COLUMN ] column DROP DEFAULT ALTER [ COLUMN ] column { SET DROP } NOT NULL ALTER [ COLUMN ] column SET STATISTICS integer ALTER [ COLUMN ] column SET STORAGE {PLAIN EXTERNAL EXTENDED MAIN} ADD table_constraint DROP CONSTRAINT constraint_name [ RESTRICT CASCADE ] DISABLE TRIGGER [ trigger_name ALL USER ] ENABLE TRIGGER [ trigger_name ALL USER ] ENABLE REPLICA TRIGGER trigger_name ENABLE ALWAYS TRIGGER trigger_name DISABLE RULE rewrite_rule_name ENABLE RULE rewrite_rule_name ENABLE REPLICA RULE rewrite_rule_name ENABLE ALWAYS RULE rewrite_rule_name CLUSTER ON index_name SET WITHOUT CLUSTER SET WITH OIDS SET WITHOUT OIDS SET ( storage_parameter = value [,... ] ) RESET ( storage_parameter [,... ] ) INHERIT parent_table NO INHERIT parent_table OWNER TO new_owner SET TABLESPACE new_tablespace Remoção de Tabelas A remoção de uma tabela é bastante simples, permitindo apenas propagar ou não essa remoção para objectos dependentes da mesma, recusar a operação caso existam 10

11 dependências entre esta tabela e outros objectos, ou ainda evitar o lançamento de um erro no caso de não haver qualquer tabela com o nome referido: DROP TABLE [ IF EXISTS ] name [,...] [ CASCADE RESTRICT ] Note-se que este comando não se limita a remover apenas os dados de uma tabela, destruindo a sua estrutura também. Se o utilizador pretender esvaziar uma tabela poderá usar o comando TRUNCATE que automaticamente eliminará todos os tuplos pertencentes àquela tabela mantendo, no entanto, a sua estrutura Criação de triggers Um trigger corresponde à definição de uma acção cuja iniciação é desencadeada por um determinado evento definido na criação do próprio trigger. Entre as várias utilidades dos triggers podem-se destacar a criação de mecanismos de validação que envolvem pesquisa em mais que uma tabela, inserção de dados de uma coluna através da combinação de outras, actualização de tabelas aquando da alteração de outra, criação de logs e registos de criações ou alterações de utilizadores, etc. A criação de um trigger é feita da seguinte forma: CREATE TRIGGER name { BEFORE AFTER } { event [ OR... ] } ON table [ FOR [ EACH ] { ROW STATEMENT } ] EXECUTE PROCEDURE funcname ( arguments ) Com este comando, é criado um trigger de nome name, que vai executar a função funcname quando for detectado o evento event na tabela table. De frisar que o nome do trigger tem de ser único já que este nome representa um identificador do mesmo, permitindo posteriormente que este possa ser removido através do seu nome. As cláusulas BEFORE e AFTER permitem executar a função referida antes ou depois do evento. Isto permite, por exemplo, fazer validações antes de uma inserção e inserir dados em tabelas depois de uma ter sido actualizada. A opção FOR EACH ROW permite executar a função para cada linha alterada/inserida/removida enquanto, por contraste, FOR EACH STATEMENT executa a função para cada operação efectuada (mesmo que essa operação não chegue de facto a modificar nenhuma linha da tabela. Note-se que neste capítulo temos uma funcionalidade bastante útil do SQL que não é implementada pelo PostgreSQL: INSTEAD OF. Esta é usada em vez das cláusulas AFTER e BEFORE, e permite efectuar uma operação em vez de uma outra que constitui o evento. Isto permite, por exemplo, depois da criação de uma view que é obtida através da fusão de duas tabelas, dizer que quando o utilizador tenta inserir na view, o sistema de bases de dados, em vez disso, insere directamente nas duas tabelas. Apesar de não fazer parte da criação de triggers, esta operação pode ser feita através da criação de uma regra (referido mais à frente) Remoção de triggers Tal como aconteceu com a remoção de tabelas, a sintaxe da remoção de triggers também é bastante simples: 11

12 DROP TRIGGER [ IF EXISTS ] name ON table [ CASCADE RESTRICT ] Este comando permite remover o trigger de nome name aplicado à tabela table. Mais uma vez, é usada a cláusula IF EXISTS que evita que um erro seja lançado caso estejamos a tentar remover um trigger não existe (recebendo assim apenas um aviso). Para além disso, as cláusulas CASCADE e RESTRICT permitem, respectivamente, remover todos os objectos que dependerem deste trigger, e anular esta operação caso isso aconteça Criação de Regras Embora muitas vezes se considere que regras e triggers são exactamente a mesma coisa, isso não é verdade. Por exemplo, um trigger, ao contrário de uma regra, não funciona se for criado numa table view já que a informação que aparenta estar nessa, está de facto espalhada em tabelas, pelo que o trigger não consegue aceder a esses dados. Por outro lado, não é possível criar algum tipo de restrições tais como foreign keys com regras, sendo que o mesmo já possível com triggers. Percebido isto, a sintaxe da criação de regras é a seguinte: CREATE [OR REPLACE] RULE name AS ON event TO table[ WHERE condition ] DO[ ALSO INSTEAD ] {NOTHING command (command ; command... )} Este comando cria uma regra de nome name na tabela table que, executa um determinado comando em vez de (INSTEAD), ou para além de (ALSO) executar um determinado evento event, caso a condição condition se verifique. Note-se que, combinando as cláusulas NOTHING e INSTEAD, pode-se implementar uma regra que, por exemplo, anula a inserção de certos dados se estes não satisfizerem uma determinada condição. Note-se também que esta definição de regra permite que, quando detectado o evento referido, pode não ser executado nada (NOTHING), pode ser executado um comando command, ou pode ainda ser executada uma lista de comandos separados por ; Remoção de Regras A sintaxe da remoção de regras é idêntica à remoção de triggers ou mesmo de tabelas: DROP RULE [ IF EXISTS ] name ON relation [ CASCADE RESTRICT ] As cláusulas IF EXISTS, CASCADE e RESTRICT, já foram apresentadas anteriormente pelo que não haverá necessidade de tornar a fazê-lo, sob pena de ter redundância de informação Informação Adicional Não foi encontrada qualquer informação sobre implementação de assertions em PostgreSQL pelo que se assume que este Sistema de Gestão de Base de Dados não implementa esse tipo de operações. O único tipo de assertions permitido é usado para efeitos de debugging, nas seguintes situações: 12

13 Execução do comando postgres (utilizado para correr o servidor) Configuração do servidor Note-se também que não foram abordados os comandos DDL respectivos à criação de estruturas de dados em índices, já que isto irá ser abordado na secção 4 (Indexação e Hashing) Cobertura DML O DML (Data Manipulation Language) define, por oposição ao DDL, os comandos responsáveis pela modificação, remoção, inserção, recuperação e inclusão de informações em bases de dados, ou seja, em tudo o que é relativo aos dados em si. Os quatro comandos que serão abordados nesta secção, e que correspondem aos quatro comandos DML mais importantes, são: Select utilizado para seleccionar dados Insert utilizado para introduzir novos dados Update utilizado para alterar dados Delete utilizado para remover dados Selecções de dados A selecção de dados tem-se tornado cada vez mais complexa, sendo que o utilizador pode optar por inúmeras opções, que permitem agrupar os dados, filtrando-os através de restrições, combinar várias tabelas e views, etc. A sintaxe do comando SELECT é a seguinte: [ WITH [ RECURSIVE ] with_query [,...] ] SELECT [ ALL DISTINCT [ON(expression [,...]) ]] * expression [ [ AS ] output_name ] [,...] [ FROM from_item [,...] ] [ WHERE condition ] [ GROUP BY expression [,...] ] [ HAVING condition [,...] ] [ WINDOW window_name AS ( window_definition ) [,...] ] [ { UNION INTERSECT EXCEPT } [ ALL ] select ] [ ORDER BY expression [ASC DESC USING operator ] [ NULLS { FIRST LAST } ] [,...] ] [ LIMIT { count ALL } ] [ OFFSET start [ ROW ROWS ] ] [ FETCH { FIRST NEXT } [ count ] { ROW ROWS } ONLY ] [ FOR {UPDATE SHARE}[OF table_name[,...] ][NOWAIT][...]] Sendo que from_item corresponde a: 13

14 [ ONLY ] table_name [ * ] [ [ AS ] alias [ ( column_alias [,...] ) ] ] ( select ) [ AS ] alias [ ( column_alias [,...] ) ] with_query_name [ [ AS ] alias [ ( column_alias [,...] )]] function_name ( [ argument [,...] ] ) [ AS ] alias [ ( column_alias [,...] column_definition [,...] ) ] function_name ( [ argument [,...] ] ) AS ( column_definition [,...] ) from_item [ NATURAL ]join_type from_item[ ON join_condition USING ( join_column [,...] )] Como muitas vezes temos selecções de colunas com o mesmo nome de tabelas diferentes, podemos fazer renomeação com o parâmetro with_query que corresponde a: with_query_name [ ( column_name [,...] ) ] AS ( select ) TABLE { [ ONLY ] table_name [ * ] with_query_name } Uma das cláusulas interessantes é a cláusula WITH que permite definir subperguntas que poderão ser posteriormente usadas na selecção principal. Isto permite simplificar a leitura deste comando, e permite que uma subpergunta seja usada mais que uma vez sem que para isso seja preciso repetir código. Outra cláusula bastante útil é a DISTINCT que permite filtrar duplicados de forma a obter tuplos únicos duma selecção. Para além de possibilitar limitar, ordenar e agrupar os dados, a selecção de dados ainda permite fazer uniões, intercepções e filtragens através das cláusulas UNION, INTERSECT e EXCEPT respectivamente. Estas cláusulas aumentam, por essa razão, a expressividade das perguntas, podendo-se relacionar inúmeras tabelas Inserção de dados O método mais conhecido de inserção de dados no SQL é o método INSERT. A sua sintaxe é a seguinte: INSERT INTO table [ ( column [,...] ) ] { DEFAULT VALUES VALUES ({ expression DEFAULT } [,...]) [,...] query } [ RETURNING * output_expression[[ AS ]output_name][,...]] Basicamente, este método insere na tabela table a sequência de valores definida em VALUES (cujos valores estão separados por virgulas). Se por defeito VALUES tem de definir e instanciar todos os atributos de uma tabela, o mesmo não se passa se definirmos em column um conjunto de atributos que serão afectados (os outros serão introduzidos a null ou com o valor default definido). 14

15 Note-se ainda que podem ser introduzidos dados através de uma pergunta a outras tabelas com o parâmetro query, ou com o seu valor default com a cláusula DEFAULT. Pode ainda ser retornado um output que pode ser um valor fixo, ou uma expressão envolvendo as colunas usadas, através da cláusula RETURNING. O resultado da utilização desta é idêntico, por isso, ao resultado de uma selecção. A inserção de dados pode ser feita no entanto, com outro método: COPY. Este método permite a utilização de dados de um determinado ficheiro, para serem introduzidos numa tabela tornando a inserção mais rápida e simples para o utilizador. A sintaxe deste método é: COPY tablename [ ( column [,...] ) ] FROM { 'filename' STDIN } [ [ WITH ] [ BINARY ] [ OIDS ] [ DELIMITER [ AS ] 'delimiter' ] [ NULL [ AS ] 'null string' ] [ CSV [ HEADER ] [ QUOTE [ AS ] 'quote' ] [ ESCAPE [ AS ] 'escape' ] [ FORCE NOT NULL column [,...] ] Note-se que este método permite fazer a operação inversa, ou seja, seleccionar dados de uma tabela para um ficheiro, com uma sintaxe muito parecida, alterando a cláusula FROM para TO Remoção de dados A remoção de dados é feita através do comando DELETE FROM, de forma bastante simples, sendo que a sua sintaxe é a seguinte: DELETE FROM [ ONLY ] table [ [ AS ] alias ] [ USING usinglist ] [ WHERE condition WHERE CURRENT OF cursor_name ] [ RETURNING * output_expression[[ AS ] output_name ][,...]] Este método elimina todos os tuplos da tabela table que satisfaçam a condição condition. Note-se que se não for usada a cláusula WHERE, então serão eliminados todos os tuplos da tabela, sendo que o resultado seria igual ao produzido pela execução do comando TRUNCATE anteriormente referido. De notar ainda que a cláusula RETURNING é idêntica à mesma no método de inserção de dados, e que a cláusula USING permite usar múltiplas tabelas na cláusula WHERE ou seja, a condição de eliminação de tuplos pode ser mais complexa, envolvendo outras tabelas. 15

16 Actualização de dados Finalmente, para actualizar os dados de uma tabela, o postgresql utiliza o comando UPDATE cuja sintaxe é a seguinte: UPDATE [ ONLY ] table [ [ AS ] alias ] SET { column = { expression DEFAULT } (column [,...]) = ({expression DEFAULT}[,...])} [,...] [ FROM fromlist ] [ WHERE condition WHERE CURRENT OF cursor_name ] [ RETURNING * output_expression[[ AS ] output_name][,...]] Este comando permite alterar todos os dados que satisfaçam uma condição condition duma tabela table, alterando os atributos indicados na cláusula SET. Naturalmente, todos os valores dos atributos não mencionados nessa cláusula serão mantidos. Mais uma vez, DEFAULT permite instanciar um atributo com o seu valor por defeito, enquanto o parâmetro fromlist permite definir nomes de outras tabelas que poderão ser usados na cláusula WHERE tal como na remoção de dados. Note-se ainda que quer esta operação, quer a operação de remoção de dados, permitem o uso de cursores, permitindo operações mais complexas. 16

17 3. Armazenamento e file structure 3.1. File System O PostgreSQL utiliza, para guardar os dados, o sistema de ficheiros do sistema operativo. Todas as bases de dados criadas encontram-se guardada na directoria /data/base divididas por pastas, ou seja, cada base de dados está contida numa pasta cujo nome é um identificador único. A lista de Bases de Dados / Identificadores pode ser consultada no ficheiro pg_database. As tabelas podem ter vários GB de tamanho, sendo que a partir de 1GB são divididas em segmentos de 1GB (este é o valor default e pode ser alterado) e que são identificados pelo identificador do seu filenode. Se uma tabela estiver dividida em vários segmentos os nomes serão filenode1, filenode2, etc. Caso uma tabela tenha campos muito grandes ser-lhe-á associada ainda uma tabela TOAST. O PostgreSQL usa páginas de tamanho fixo, geralmente 8kb, e não permite que um tuplo se divida por mais que uma página. O TOAST (The Oversized-Attribute Storage Technique) ajuda a resolver este problema comprimindo ou dividindo um tuplo em várias linhas. Isto é totalmente transparente para o utilizador e não causa grandes transtornos a nível de código. Obviamente o TOAST só pode ser utilizado em tipos que possam atingir valores grandes, em termos de espaço. Os ficheiros temporários encontram-se guardados numa pasta aparte, /data/base/pgsql_tmp Paginação Como já foi referido acima, o PostgreSQL utiliza tipicamente páginas de 8KB. Tanto as tabelas como os índices estão guardados em arrays de páginas, isto é, cada tabela corresponderá a uma posição do array. Os tuplos estão guardados num Heap (HeapTupleHeaderData) Partições É possível particionar tabelas no PostgreSQL, isto é, dividir as tabelas em várias 'partes' a um nível físico, de modo a melhorar o desenho da base de dados. Particionar os dados pode trazer vários benefícios, por exemplo, se uma grande percentagem das pesquisas forem efectuadas sobre um conjunto de dados, e esses dados estiverem separados numa partição, as pesquisas serão bem mais eficientes. Outra vantagem importante é a de podermos guardar informação pouco acedida em dispositivos de armazenamento mais lento e mais barato. O particionamento é implementado por herança, isto é, todas as partições são 'filhos' de uma 'tabela-pai', que geralmente se encontra vazia. O PostgreSQL permite a uso de Range Partitioning (por gamas de valores) e List Partitioning (indicando explicitamente que valores entram em que partições). Para criar partições é necessário criar a tabela principal e de seguida as 'tabelasfilho', que serão as partições. Em seguida podemos definir os valores que poderão existir em qualquer partição. Por exemplo para definir que uma partição conterá os valores do atributo x que tenham o valor 1, fazemos CHECK (x = 1). É possível ainda criar índices para cada tabela, o que é bastante aconselhável, e também triggers de 17

18 inserção, para quando um valor é inserido na tabela principal ser direccionado para a sua partição. Por fim, convém verificar se o parâmetro constraint_exclusion no ficheiro postgresql.conf, de modo a optimizar as pesquisas Clustering O conceito de cluster em bases de dados consiste na aglomeração de dados em determinados pontos contíguos dos dispositivos de armazenamento. A grande vantagem desta técnica é poupar acessos e leituras de disco. Supondo que queremos encontrar todos os tuplos de uma tabela cujo atributo x é maior que 100, ao encontrar o primeiro tuplo, caso estes se encontrem ordenados, basta continuar a ler os seguintes blocos. O PostgreSQL implementa esta técnica através do comando CLUSTER. Exemplo: CLUSTER country USING code; 3.5. Buffer Management O PostgreSQL está, em grande parte, dependente do sistema operativo. Apenas usa buffers para fazer a transição dos dados entre o disco rígido e o backend do sistema, isto é, servindo como cache. Assim, quando um processo precisa de um bloco de disco, este será guardado num buffer. Se ao ser efectuado um pedido, o bloco se encontrar na cache, é marcado como pinned, isto é, mais nenhum processo o poderá usar, caso contrário será preciso encontrar um buffer para guardar o bloco. Esta selecção é feita através de clock sweep que, basicamente, trata a cache como uma lista circular, percorrendo-a à procura de blocos disponíveis. Um bloco não está disponível quando está a ser referenciado por algum processo. 18

19 4. Indexação e Hashing 4.1. Introdução Os índices são usados em bases de dados para facilitar o acesso às tabelas, aumentando a rapidez das queries, tal como o objectivo de um índice num livro. Consoante o Sistema de Gestão de Base de Dados, os índices podem ser criados em função de um ou mais atributos ou mesmo em função de uma determinada expressão, e podem ser guardados em diferentes estruturas de dados. Sendo o PostgreSQL um SGBD bastante completo, implementa inúmeras opções de tipos de índices nomeadamente variadas estruturas de dados, índices multi-coluna ou mesmo indexação múltipla. Depois de criado um índice, o administrador não tem de ter mais intervenções, sendo que o próprio sistema irá manter o índex actualizado (sempre que a tabela é alterada), e irá usar o índice sempre que achar que a sua utilização irá melhorar o desempenho da query. Devido a esta autonomia do sistema, o uso de índices deve ser bastante cuidadoso para que não sejam criados índices que tragam computações desnecessárias relativas à manutenção dos mesmos que acabam por não ser aproveitados. Note-se que o uso inapropriado de um índice pode baixar a performance de um sistema. O sistema utiliza ou não os índices consoante a análise de estatísticas de acesso guardadas pelo próprio, pelo que esporadicamente deve-se correr o comando ANALYSE que permite a actualização dessas mesmas estatísticas. A sintaxe deste comando é: ANALYZE [ VERBOSE ] [ table [ ( column [,...] ) ] ] Enquanto o parâmetro verbose permite a observação deste comando através de mensagens de progresso, os parâmetros table e column permitem restringir as estatísticas produzidas à análise da tabela e colunas correspondentes. Visto isto, passaremos então à sintaxe da criação e remoção de um índice. O comando de criação de um índice veio-se a alterar ao longo das versões tendo cada vez mais parâmetros, oferecendo também cada vez mais opções e possibilidades. A sintaxe deste comando da versão do PostgreSQL é a seguinte: CREATE[ UNIQUE ] INDEX [ CONCURRENTLY ] name ON table [ USING method ] ({ column ( expression ) } [ opclass ] [ ASC DESC ] [ NULLS { FIRST LAST } ] [,...] ) [ WITH ( storage_parameter = value [,... ] ) ] [ TABLESPACE tablespace ] [ WHERE predicate ] Este comando irá criar um índice de nome name na tabela especificada pelo parâmetro table, implementado na estrutura de dados method (árvore B+ por defeito). A chave do índice (atributo pelo qual um tuplo é identificado), corresponde ao conjunto de colunas da tabela identificadas em column ou ainda através duma expressão identificada entre parênteses, expression, que corresponde a uma função de um ou mais atributos da 19

20 tabela. O PostgreSQL suporta índices múlti-coluna (com chaves compostas por vários atributos) desde que a estrutura de dados o permita, sendo que para isso basta identificar as várias colunas separadas por vírgulas, tal como mostra o seguinte exemplo: CREATE INDEX index_name ON table (col1, col2); Se na criação do índice for usada a cláusula UNIQUE então o sistema vai garantir que todos os tuplos da tabela têm uma key única, sendo que isto também é verificado aquando da inserção e alteração de um tuplo. Por outro lado, a cláusula CONCURRENTLY permite criar um índice sem que o sistema bloqueie quaisquer alterações ou inserções que aconteçam durante a sua criação (como aconteceria por defeito). Os parâmetros asc, desc, nulls first, nulls last, entre outros, limitam-se a especificar a ordem pela qual os nós serão apresentados no índice. A cláusula WITH permite definir opções de armazenamento (storage_parameter) do índice, sendo que cada estrutura de dados (method) pode ter o seu conjunto de opções permitidas. As estruturas de dados B-tree, Gist e hash aceitam um único parâmetro, FILLFACTOR, que corresponde ao grau de ocupação das páginas de indexação, enquanto os índices Gin utilizam o parâmetro booleano FASTUPDATE cujo valor por defeito é a true. Por fim, a cláusula WHERE permite criar um índice parcial. Um índice parcial é um índice que, em vez de indexar todas os tuplos de uma tabela, indexa apenas os tuplos que satisfaçam uma determinada condição (predicate). Note-se portanto que a introdução desta cláusula nunca poderá aumentar o tamanho do índice tendo tendência a diminui-lo. Actualmente não são permitidas subqueries e agregações nem na cláusula WHERE nem mesmo nos atributos que são expressões (expression). A sintaxe da remoção de um índice é bastante mais simples e intuitiva: DROP INDEX [ IF EXISTS ] name [,...] [ CASCADE RESTRICT ] A cláusula IF EXISTS evita que o sistema lance uma excepção no caso de não existir nenhum índice com o nome indicado, enquanto as cláusulas CASCADE e RESTRICT especificam diferentes tipos de abordagens no caso de existirem dependências em relação ao índice em questão. Enquanto a primeira elimina para além do índice, todos os objectos que dependiam deste, a segunda recusa-se a remover o índice se existir um ou mais objectos dependentes do mesmo Tipos de Índices O PostgreSQL suporta quatro tipos de estruturas de dados, para guardar os índices: BTree, HASH, GIST e GIN. Cada uma optimiza um determinado tipo de pesquisas, pelo que a estrutura de dados usada por defeito é a Btree, já que é a mais promissora na maioria dos tipos de pesquisa mais frequentes. 20

21 Btree Em primeiro deve-se focar que, apesar do nome geralmente utilizado ser Btree, quando se fala neste tipo de árvores neste contexto refere-se, na verdade, a outro tipo de árvores ligeiramente mais complexas de nome B+ Tree ou BplusTree. Uma árvore B+, ao contrário de um Btree normal, guarda a totalidade dos dados no último nível, ou seja, nas folhas. Estas folhas estão ligadas entre si, estabelecendo uma lista ligada. Uma das propriedades que faz com que esta estrutura de dados seja bastante útil para guardar índices, é o facto de cada nó que não é folha ter entre n+1 e n filhos (excepto a raiz da árvore). Isto faz com que a árvore B+ não tenha muitos níveis fazendo com que a consulta de dados atinja rapidamente o nível das folhas (dados) fazendo o mínimo de seek s no disco possíveis. O PostgreSQL usa o algoritmo de Lehman e Yao para criar e gerir este tipo de árvore que, devido à sua implementação, fazem com que a indexação com este tipo de estrutura de dados seja mais eficaz em pesquisas que usam igualdades. A figura seguinte representa uma possível instância exemplificativa deste tipo de estrutura de dados: 2 Figura 3 Exemplo de uma instância de uma árvore B Hash Os índices baseados em estruturas de dados e funções de Hash acabam por ser limitativos já que só suportam comparações simples de igualdades. O algoritmo de Hashing usado pelo PostgreSQL foi desenvolvido por W. Litwin para sistemas baseados em discos com um processador. Este hashing é dinâmico, e não tem qualquer tipo de rehashing que permita a eliminação dos buckets de overflow, diminuindo também o número de seeks do disco. O algoritmo de W.Litwin efectua a divisão de buckets por ordem (primeiro o bucket 0, depois o bucket 1, etc.) em vez de dividir o bucket que excedeu a capacidade, se bem que essa divisão é efectuada quando um bucket qualquer excede a capacidade. Como possivelmente este último bucket não é o bucket que foi dividido, então podem-se aplicar técnicas de overflow. Como a indexação não é melhor que a indexação com árvores B+ (que também suportam as comparações de igualdade), utilizando mais recursos do sistema que a segunda, o uso deste tipo de indexação é actualmente desencorajado. Para além disto, o Hash é o único method do PostgreSQL que não suporta índices de múltiplas colunas. De qualquer forma, para criar um índice com esta estrutura de dados utiliza-se o seguinte comando: CREATE INDEX nome_index ON nome_tabela USING hash (nome_coluna); 21

22 Note-se finalmente que o PostgreSQL só implementa hashing a nível da indexação, não implementando hashing de dados Gist Os índices Gist (Generalized Search Tree) não são um tipo específico de estruturas de dados, constituindo uma abstracção ou interface que pode ser utilizada para a implementação de vários tipos de árvores tais como B+ trees, R-trees, hb-trees, RD-trees. Os operadores particulares de cada índice GIST podem variar bastante consoante a estratégia de indexação (opclass no método CREATE INDEX). O PostgreSQL tem, por defeito, inúmeras classes de operadores GIST específicas para tipos de dados geométricos bidimensionais. Para a criação de um índice GIST têm de ser definidas as classes de operadores, incluindo operadores de comparação e estratégias de pesquisa. Depois de criados, os nomes destes operadores têm de ser incluídos na função CREATE INDEX. Devido à complexidade e pouca relevância deste procedimento, não será apresentada a sintaxe da criação deste índice Gin Os índices GIN suportam uma indexação invertida que permite o uso de chaves múltiplas, identificadas através de um array. Tal como o Gist, suporta que o utilizador utilize várias estratégias de indexação, com os seus operadores específicos. Porém, ao contrário do primeiro, o GIN por defeito inclui classes de operadores para arrays de apenas uma dimensão. A sintaxe da criação deste tipo de índices não será apresentada pela mesma razão que a dos índices GIST Índices para organização de ficheiros A organização de ficheiros em PostgreSQL é feita em Heap, sem que haja nenhum sistema de clustering automático. Em vez disso, o sistema fornece um comando que permite reorganizar os dados de uma determinada tabela de acordo com um índice previamente criado. A sintaxe deste comando é a seguinte: CLUSTER [VERBOSE] tablename [ USING indexname ] Este comando reestrutura os dados da tabela tabelaname podendo, para isso, usar o índice indexname através da cláusula USING. A cláusula VERBOSE permite obter informação sobre o clustering de cada tabela. Como este comando cria uma cópia temporária dos dados (quer da tabela quer do índice) para fazer a operação, é necessário ter espaço de disco livre equivalente ou superior ao espaço ocupado por ambos. Importante realçar que este comando é uma operação que se limita a reorganizar o ficheiro num determinado instante, não sendo responsável pela manutenção desta estrutura (se houver alterações ou inserções de dados, estes serão colocados em qualquer espaço livre do ficheiro mantendo a organização em Heap). Para além deste comando, o parâmetro de armazenamento FILLFACTOR, já abordado anteriormente, pode também ser usado para reajustar os dados periodicamente de forma automática, aquando da alteração dos dados (se o seu valor for inferior a 100%). 22

23 Como foi referido anteriormente, o sistema vai tomando opções (por exemplo na optimização de perguntas) baseado em estatísticas produzidas ao longo do tempo. Assim, é aconselhado que, depois de executar o comando CLUSTER, se execute o comando ANALYSE forçando a actualização das estatísticas, ou o sistema poderá tomar decisões erradas com base em informação desactualizada. Para terminar, a documentação do PostgreSQL refere ainda um possível atalho na organização de ficheiros com índices de ordenação, podendo obter o mesmo resultado de forma mais rápida. Em vez de usarmos um índice para ordenar uma tabela, este procedimento rudimentar passa por criar uma tabela idêntica usando a cláusula ORDERBY da selecção: CREATE TABLE newtable AS SELECT * FROM table ORDER BY columnlist; De seguida seria apenas remover a tabela antiga e alterar o nome da nova. No entanto, esta solução não é prática, ou mesmo viável apesar de poder ser mais eficiente. 23

24 4.4. Outras Informações Múltiplos ficheiros de índices para os mesmos atributos Uma das questões abordadas no enunciado é a possibilidade de serem criados vários ficheiros de índices para o mesmo conjunto de atributos, implementados ou não nas mesmas estruturas de dados. O PostgreSQL não tem qualquer tipo de restrição no número de índices por tabela, ou por conjunto de atributos. Para demonstrar o referido anteriormente, o exemplo seguinte mostra a criação de dois índices semelhantes sobre o mesmo atributo: Figura 4 Criação de dois ficheiros de índex idênticos, para o mesmo conjunto de atributos Bitmap (Combinação de múltiplos índices) Como pôde ser observado na sessão 4.2 (tipos de índices), o PostgreSQL não implementa qualquer tipo de índice em Bitmaps. Em vez disso, o PostgreSQL só utiliza bitmaps em duas situações: valores nulls, e combinação de múltiplos índices. A primeira consiste na criação automática de um bitmap para cada atributo de cada tabela, desde que estes não tenham já uma imposição not null (especificada directamente, pelo facto de serem chaves primárias, etc). Cada bitmap consiste assim, numa lista de bits que tomam o valor 0 se o atributo for nulo nesse tuplo, e o valor 1 caso contrário. O PostgreSQL utiliza ainda bitmaps para combinar múltiplos índices numa determinada pesquisa. Se por um lado um índice sobre os atributos (at1, at2) pode ser usado numa pergunta do estilo WHERE at1 = V1 AND at2 = V2, por outro lado se em vez de uma conjunção, tivermos uma disjunção, o uso deste índice será desnecessário e contraproducente. Para tratar destas e de outras situações, o PostgreSQL suporta utilização de múltiplos índices, sendo que para cada um é criado um bitmap cujos bits representam o resultado de uma sub-condição. No exemplo anterior da disjunção, seria criado um bitmap com o resultado de at1 = V1 e outro para at2 = V2. Depois, a operação lógica é aplicada aos bitmaps independentemente de ser uma conjunção, disjunção, negação, XOR, etc. Só no final é que as tabelas são de facto visitadas e retornadas pelo que este processo se torna bastante eficiente. No caso da disjunção referida anteriormente, seriam seleccionados os tuplos que tivessem pelo menos uma célula do bitmap de valor 1. 24

25 Estruturas temporariamente inconsistentes para lidar com verificação diferida de restrições de integridade O PostgreSQL permite que os tipos de índices abordados anteriormente fiquem inconsistentes temporariamente através da cláusula DEFERRED aplicada a restrições) nos comandos CREATE e ALTER TABLE. Constituindo este facto uma necessidade para algumas operações no âmbito das transaccoes, este tópico será abordado mais à frente na secção 6.9 ( Diferir a verificação para o final das transacções ). 25

26 5. Processamento e Optimização de Perguntas Esta secção de processamento e optimização de perguntas pode ser uma ferramenta muito forte num sistema de gestão de bases de dados. Através desta ferramenta, podem-se determinar os modos mais eficazes de executar determinada pergunta ao sistema. O optimizador do sistema verifica os planos de execução possíveis dada uma pergunta, e tenta descobrir qual o plano mais eficaz para a pergunta dada. Estes custos são utilizados para estimar o custo de avaliação de uma pergunta, em termos de operações I/O pretendidas, requisitos de CPU e outros factores. Em geral não é possível aceder-se directamente a este optimizador, sendo que em alguns sistemas de gestão de bases de dados o permitem, através da utilização de hints. No PostgreSQL, não é possível utilizar explicitamente estes hints. O que é possível fazer é, alterando certos parâmetros no ficheiro de configuração do PostgreSQL, (posgresql.conf), autorizar ou impedir a utilização de certos algoritmos. Porém, podem existir situações em que, mesmo estando o algoritmo desactivado, este é utilizado na mesma. Para esta questão, é importante compreender um pouco melhor o caminho percorrido por uma interrogação ao sistema. Na imagem seguinte apresenta-se um esquema da questão referida, numa situação geral: Figura 5 - Percurso de uma interrogação ao sistema Como se pode observar, uma pergunta passa por vários passos antes de ser efectivamente executada Percurso de Uma Interrogação Na imagem anterior, explicava-se no caso geral o percurso de uma pergunta no sistema. Nesta secção vamos ver de forma mais aprofundada esta questão. No PostgreSQL, uma pergunta passa pelos seguintes passos: 1 Estabelece-se uma ligação da aplicação para um servidor do PostgreSQL. A aplicação transmite a pergunta e espera por uma resposta por parte deste. 26

27 2 O parser verifica que a pergunta está correcta (a nível de sintaxe) e cria uma query tree. 3 - O rewrite system pega nesta árvore criada e verifica se existe alguma regra a aplicar nesta árvore. 4 O planificador/optimizador do sistema pega na árvore reescrita e cria um plano de execução que servirá de input para o executador. 5 O executor pega nestes dados e executa-os retornando os tuplos na forma representada na árvore. O executor usa o storage system enquanto percorre relações, executando sorts e joins, avaliando qualifications e retornando os resultados pretendidos. PARSER Optimizador Transformações Procura o Plano de Execução Compila o Plano de Execução Execução Retorno dos Dados Figura 6 - Figura Representativa do Esquema de Vida de um Pergunta 5.2. Ligação ao Servidor As ligações ao servidor são estabelecidas utilizando um mecanismo de processo por utilizador, através de um modelo cliente/servidor. Neste modelo, um processo de um cliente está ligado a um, e só um, servidor. É necessário ter um servidor mestre que cria um novo processo de servidor. Este servidor é chamado postgres e recebe pedidos numa porta específica de TCP/IP Etapa de Parsing Parser O parser numa primeira fase, recebe a pergunta, uma String (em texto ASCII), e verifica a sua validade a nível de sintaxe. Se esta for correcta, gera-se uma parse tree. Caso contrário, é retornada uma mensagem de erro. 27

28 O lexer esta definido no ficheiro scan.l e é responsável por reconhecer identificadores, SQL key words. etc... Para cada key word ou identificador encontrados, um token é gerado e passado para o parser. Este está definido no ficheiro grammar.y e consiste um conjunto de regras de gramática e acções que são executadas quando uma regra é "disparada". O código das acções (escrito em C) é utilizado para construir a árvore. O ficheiro scan.l é transformado para o ficheiro fonte scan.c utilizando o programa lex e o gram.y é transformado em gram.c. Após estas transformações, um compilador normal de C pode ser utilizado para criar o parser Processo de Transformação No processo anterior cria-se uma parse tree usando regras sobre estruturas sintáticas do SQL. Após se utilizar o parser, utiliza-se a árvore gerada e faz uma interpretação semântica necessária para saber que tabelas, funções e operadores estão referenciados na pesquisa. A estrutura de dados criada neste passo é a chamada query tree. Há dois processos de parsing que são necessários. O primeiro só faz sentido em caso de transacções, em que simplesmente identifica palavras como BEGIN, ROLLBACK, etc, podendo estas ser imediatamente executadas sem qualquer análise adicional. Após se saber que se está a lidar com uma interrogação propriamente dita (SELECT ou UPDATE) podemos iniciar a transacção (se não se estiver já dentro de uma). Aqui sim é invocado o processo de transformação. De acordo com a interrogação: select customer_name, balance, from customers where balance > 0 ORDER BY balance a a árvore gerada pode ser a seguinte: Figura 7 Parse Tree gerada para uma determinada query 5.4. Planificador / Optimizador A tarefa do planificador/optimizador é a de criar um plano de execução óptimo. Um interrogação SQL pode ser executada de várias formas diferentes, sendo que cada forma tem custos associados, sendo umas melhores que outras, produzindo-se os mesmos resultados em qualquer um dos casos. Se for possível a nível computacional, o 28

29 planificador/optimizador olha para todas as possibilidades, elegendo a mais vantajosa. Podem haver situações em que verificar todas as possibilidades é muito dispendioso tanto a nível de tempo como de recursos e, por isso, quando o número de joins de uma interrogação ultrapassa um determinado limite, PostgreSQL utiliza uma ferramenta chamada Genetic Query Optimizer por forma a conseguir criar um plano em tempo útil. Em seguida mostra-se um possível plano de execução, no formato de árvore: Figura 8 Exemplo de um plano de execução Geração de Possíveis Planos Os planos criados estão directamente relacionados com os índices disponíveis. Se uma interrogação tiver uma restrição de atributo (cláusula WHERE, pesquisa por um determinado atributo, etc ), e este atributo coincidir com o atributo chave de um índice, é criado um plano de execução para esse índice. Se houve mais índices e/ou mais restrições de atributos, são criados vários planos de execução para cada índice. Criam-se também planos para índices quando as interrogações têm também cláusulas de ordenação (ORDER BY). Um exemplo disto é o caso dos índices B-Tree. Se houver uma pesquisa de ordenação, basta chegar às folhas da árvore e percorre-las. Neste caso, a utilização do índice é útil. Independentemente dos índices utilizados, é sempre criado um índice para pesquisa sequencial, o Seq Scan. Este é sempre criado em qualquer situação. Se a interrogação requer junção de duas ou mais tabelas, planos para a junção de tabelas também são utilizados. Há três planos de junção possíveis (hash join, merge join, nested loop join), como veremos na secção seguinte, relativa à implementação das operações básicas. Quando uma interrogação envolve mais do que duas tabelas, o resultado tem de ser construído a partir de uma árvore de junção de vários passos. O planificador examina as diferentes possibilidades de junção e escolhe a mais barata. Caso a interrogação use menos que um determinado número de tabelas (por defeito é 12), uma pesquisa quase exaustiva é levada a cabo para tentar seleccionar a melhor opção possível. O planificador costuma considerar junções entre tabelas entre as quais existe uma relação de junção com a cláusula WHERE, por exemplo, rel1.attr1=rel2.attr2 como prioritárias. Juntar pares, sem que exista a cláusula 29

30 WHERE sobre os mesmos, só é considerado em último caso. Se o número de tabelas intervenientes numa junção for pequeno, então é possível assumir-se que todas as combinações de junção são analisadas. Mais à frente falaremos dos diferentes tipos de junção que o PostgreSQL tem e como se fazem as junções nestes. Caso a interrogação implique a utilização de mais tabela que o limite considerado, as sequências de junção são determinadas por heurística, utilizando o Genetic Query Optimizer Genetic Query Optimizer De entre as várias operações de uma base de dados, a mais complicada de tratar é sem dúvida a operação de junção. O número de possíveis planos aumenta exponencialmente com o número de tabelas intervenientes no processo. É preciso ainda mais esforço devido aos vários tipos de junção que o PostgreSQL permite (nested loop, hash join, merge join) e pela diversidade de índices. O optimizador realizar uma pesquisa quase exaustiva de todas a combinações possíveis, sendo que quanto maior fosse a pesquisa, mais tempo e mais recursos seriam gastos para fazer esta pesquisa exaustiva. Desta forma, decidiu-se que o ideal para estes casos grandes, era utilizar algoritmos genéticos para ajudar a resolver a situação, sendo que, nem sempre estes retornam a melhor solução possível, mas retornam-na num espaço de tempo muito mais reduzido Executor O executor pega no plano dado pelo planeador e recursivamente processa-o para extrair os tuplos pretendidos. Aqui tem-se essencialmente um mecanismo de demandpull pipelining. Sempre que um nó do plano é chamado, este tem de devolver um ou mais tuplos, ou reportar que já terminou Algoritmos para operações básicas Como se viu anteriormente, a função do planificador é escolher as operações que menos custos têm. Se apenas existisse um algoritmo para cada operação básica, não haveria necessidade da existência do optimizador. Porém, como existem vários algoritmos distintos, cada um deles bom numas situações e maus noutras, é necessário então a intervenção deste optimizador. Em seguida, demonstrar-se-ão os vários tipos de algoritmos possíveis para cada tipo de operação Algoritmos Utilizados a Nível de Selecção Seq Scan este é o algoritmo de pesquisa mais básico. Um query plan para este algoritmo é sempre gerado. Pode não ser o melhor muitas das vezes, mas este é sempre gerado. Tal como o nome indica, o modo de funcionamento do Sequencial Scan passa por percorrer todas as linhas de uma tabela, e, por cada linha, verifica se a condição é respeitada. Repare-se que se a pesquisa for efectuada numa chave primária, quando o algoritmo encontra o tuplo desejado, este pode parar imediatamente. 30

31 Bitmap Scan é um tipo de pesquisa diferente da sequencial. Enquanto este último percorre todas as entradas de uma tabela, o bitmap scan utiliza os diferentes índices criados numa dada tabela para optimizar e aumentar a velocidade de pesquisas mais complexas. Dá uso da indexação múltipla (ver secção Bitmap Combinação de Múltiplos Índices). É de notar que se poder-se-ão realizar bastantes mais seeks, por isso, este apenas deve ser utilizado com um pequeno conjunto de valores. Index Scan o index scan baseia-se numa pesquisa sobre um índice. Se for dado um valor inicial de pesquisa, o index scan apenas começará nesse valor, e se for dado um valor final, o index scan parará nesse valor. Relativamente ao seq scan, apresenta algumas vantagens e desvantagens. A pesquisa sequencial percorre todas as entradas de uma tabela, enquanto uma pesquisa por índice apenas percorre alguns valores (não os percorre todos). Porém, a pesquisa sequencial retorna os valores por ordem de entrada na tabela, e a pesquisa por índice retorna os valores de acordo com a ordem no índice (o que poderá querer dizer que se terão de realizar mais seeks). De seguida apresentaremos um exemplo em que os três diferentes tipos de scan são utilizados, variando apenas a pesquisa introduzida. create table test (a int primary key, b int unique, c int); insert into test values (1,1,1),(2,2,2),(3,3,3),(4,4,4),(5,5,5); explain select * from test where a!= 4 explain select * from test where a = 4 explain select * from test where a = 4 or a=3 31

32 É importante realçar que estes resultados não são os correctos. Em casos de experimentação, é muito importante primeiro utilizar a instrução ANALYZE, actualizando os dados estatísticos. Se executássemos os mesmos comandos após tal, todas as pesquisas utilizariam uma pesquisa sequencial, visto que o número de entradas na tabela é bastante reduzido. TID scan o operador TID Scan é raramente utilizado. Cada tuplo tem um identificador que é único na tabela, que é chamado Tuple ID. É possível fazer-se uma pesquisa pelo ID do tuplo. Existe um atributo especial para cada tabela, que corresponde ao id do tuplo, identificador este denominado por ctid Algoritmos Utilizados a Nível de Ordenação Sort após uma interrogação ter gerado um conjunto de resposta (output table), esta pode opcionalmente ser ordenada. Se tal não for pedido, a tabela será retornada tal como está, sendo que pode não ser o resultado pretendido. Para se ter algo ordenado, é preciso explicitar o comando ORDER BY na interrogação. A sua especificação é a seguinte: SELECT select_list FROM table_expression ORDER BY column1 [ASC DESC] [, column2 [ASC DESC]...] Em cada especificação de coluna, podemos ainda escolher a ordem pela qual queremos ver os resultados, se crescente ou decrescente (ASC, DESC). A ordem crescente está escolhida por defeito. Há duas formas de ordenação possíveis, ordenação em memória e ordenação em disco. Estas opções são escolhidas de acordo com um parâmetro denominado: work_mem(integer), chamado previamente de sort_mem. Isto determina o espaço de memória gasto para se realizar um algoritmo de ordenação. Se o conjunto de resultados tiver um tamanho inferior a work_mem, ordenação em memória será feita através do algoritmo quicksort. Caso contrário, o conjunto de entrada será dividido, ordenando cada parte, procedendo-se depois a uma junção dos vários componentes, utilizando o external merge sort. Em seguida mostramos dois exemplos: no primeiro ordenação em memória é realizado, no segundo, memória em disco. explain analyze select * from country order by name; explain analyze select * from uscensus order by occupation; 32

33 Apesar de em grande parte os algoritmos de ordenação serem chamados através da cláusula ORDER BY, há outras cláusulas de também necessitam destes tipos de algoritmos, tais como: UNIQUE, INTERSECT, UNION ou mesmo EXCEPT. A ordenação pode também ser efectuada utilizando as propriedades dos índices. O índice B-Tree é bastante utilizado para este caso também (basta apenas percorrer as folhas da árvore) Algoritmos Utilizados a Nível de Junção Nested-Loop Join a relação da direita é vista uma vez por cada tuplo encontrado na relação da esquerda. Esta estratégia é muito simples de implementar, sendo que é também muito dispendiosa. É importante salientar que esta operação é sempre executada entre duas tabelas. Para tal, uma terá que a tabela exterior e outra a interior. Regra geral, escolhe-se a que tem menos tuplos para ser a tabela exterior. Porém, se a tabela mais pequena couber toda em memória, é preferível tê-la como tabela interior. Merge-Sort Join tal como o algoritmo anterior, este é suposto ser um algoritmo utilizado para juntar duas tabelas. Antes da junção começar, é necessário ordenar cada uma das tabelas, de acordo com os atributos de junção. Então, procede-se à junção das tabelas, tendo em conta que as tabelas estão ordenadas de acordo com os mesmos atributos. Esta ordenação é mais interessante, visto que cada tabela só tem de ser percorrida uma vez. Em seguida mostra-se um passo intermédio deste algoritmo, em que as duas tabelas estão ordenadas de acordo com o atributo de junção, a1. Figura 9 Esquema gráfico de um merge-sort join Hash-Join este algoritmo é substancialmente diferente dos outros. Em primeiro lugar, é feito um hash dos atributos de junção da tabela da direita. De seguida, 33

34 a tabela do lado esquerdo é percorrida e os valores apropriados de cada tuplo encontrados são utilizados como hash keys para localizar os tuplos do lado direito. Este algoritmo é um candidato muito forte para a utilização de paralelização, porém, em nenhuma versão do PostgreSQL, este mecanismo de paralelização não foi implementado. Figura 10 Esquema gráfico de um hash join Mostraremos agora um exemplo deste algoritmo em funcionamento: explain select * from country co, city ci where co.area< and co.name = ci.name; Outros algoritmos Aggregate as funções de agregação computam um único valor de um conjunto de valores de input. Estas funções são chamadas quando inseridas instruções do estilo: AVG(), COUNT(), MAN(), MIN(), etc O operador hashaggregate também é utilizado em expressões com Group By. 34

35 explain select count(*) from country; Unique este operador é utilizado para remover duplicados, que necessita de estar ordenado por coluna, sendo estas únicas. É esta a forma como o operador DISTINCT está definido. De seguida mostra-se um exemplo: explain select distinct age from uscensus; Append este operador é utilizado sempre que é detectada uma cláusula de união. É necessária a intervenção de duas tabelas. São ambas ordenadas, e depois ao juntar vão-se eliminando os duplicados. Repare-se no exemplo em seguida: explain select name from country where name='portugal' intersect select name from city; Note-se na figura anterior que é perfeitamente visível a remoção de duplicados. Setop(Intersect, IntersectAll, Except, Except All) há quarto operadores do setop: intersect, intersect all, except e except all. Estes operadores são produzidos somente quando o optimizador/planificador encontra qualquer dessas operações. O modo de funcionamento é semelhante. São sempre necessários dois conjuntos de entrada, combinando os inputs em listas ordenadas e depois em grupos de linhas idênticas. explain select name from country intersect select name from city; 35

36 Scan. Como se pode observar, também é utilizado mais um operador, o subquery 5.7. Mecanismos de Avaliação de Expressões Complexas De acordo com a secção anterior, apenas vimos algoritmos para operações individuais. Estes têm depois de ser combinados para avaliar expressões complexas, com algumas operações. Algumas alternativas para tal são: Materialização consiste em analisar as expressões (de baixo para cima) guardando o seu resultado em relações temporárias guardadas na base de dados. Os resultados de cada operação intermédia são armazenados e utilizados em avaliações de operações nos níveis superiores. Pipelining consiste na passagem de tuplos para as operações pai, mesmo enquanto uma operação esteja a ser executada. Paralelização tal como o nome indica, consiste em executar várias tarefas paralelamente. Relativamente ao sistema de gestão de bases de dados PostgreSQL, podemos ver que nem todas estas propriedades são utilizadas. A materialização é utilizada para algumas operações de subselecção. O planificador/optimizador por vezes decide que é menos caro materializar uma subselecção do que repetir o trabalho em níveis superiores da árvore. É também utilizado em algumas operações de merge-join. O pipelining também é utilizado, mais concretamente, demand-pull pipelining. A paralelização é óptima para o algoritmo hash join, mas, o PostgreSQL não a implementa Tabelas e Views Estatísticas Como seria de esperar, o planificador tem de estimar o número de linhas devolvidas por uma pergunta de forma a conseguir fazer boas estimativas e aproximações. Assim, surge a necessidade de termos dados estatísticos sobre dados do sistema, de maneira a que esta questão seja resolvida. Um dos componentes das estatísticas é o número de entradas em cada tabela e em cada índice, bem como o número de blocos de disco ocupados por cada tabela (com dimensão BLOCKSIZE, que, em geral, é 8K por tabela) e índices. Esta informação é guardada na tabela pg_class, nas colunas reltuples e relpages. A definição da tabela é a seguinte: 36

37 CREATE TABLE pg_class ( relname name NOT NULL, relnamespace oid NOT NULL, reltype oid NOT NULL, relowner oid NOT NULL, relam oid NOT NULL, relfilenode oid NOT NULL, reltablespace oid NOT NULL, relpages integer NOT NULL, reltuples real NOT NULL, reltoastrelid oid NOT NULL, reltoastidxid oid NOT NULL, relhasindex boolean NOT NULL, relisshared boolean NOT NULL, relistemp boolean NOT NULL, relkind "char" NOT NULL, relnatts smallint NOT NULL, relchecks smallint NOT NULL, relhasoids boolean NOT NULL, relhaspkey boolean NOT NULL, relhasrules boolean NOT NULL, relhastriggers boolean NOT NULL, relhassubclass boolean NOT NULL, relfrozenxid xid NOT NULL, relacl aclitem[], reloptions text[] ) Por cada linha da tabela apresenta-se informação relativa a uma tabela do sistema. A tabela inclui informação sobre índices, sequências, views, tipos compostos, e tabelas TOAST. Em seguida apresenta-se um exemplo de uma pesquisa com estas informações: select reltuples, relpages from pg_class where relname =country; Como podemos observar, a tabela tem 195 tuplos também: select count(*) from country; Por defeito, os valores são inicializados a 0 aquando da construção de uma nova tabela. 37

38 É importante dizer que estes valores não são afectados instantaneamente, ou seja, é possível existir alturas em que estes estejam ligeiramente desactualizados. Para tal, é possível, através de certos comandos, actualizar estes dados estatísticos, tais como VACUUM, ANALYZE e CREATE INDEX. O VACUUM serve para limpar tuplos que foram apagados mas que efectivamente ainda continuam a ocupar espaço em memória. Muitas das pesquisas a uma base de dados retornam apenas um conjunto de resultados, muito em parte devido à cláusula WHERE. Assim, o planificador necessita de fazer uma estimativa aos dados selectivos da cláusula WHERE. A informação usada para esta tarefa guarda-se na tabela pg_statistics. Esta guarda informação detalhada sobre os dados das tabelas. Os dados nesta são actualizados também com ANALYSE e VACUUM ANALYZE, e são sempre aproximados, mesmo com updates recentes. Para além dos dados relativos ao conteúdo de tabelas, guardam-se também dados estatísticos sobre os valores de expressões de índices. A tabela pg_statistics tem o seguinte formato: CREATE TABLE pg_statistic ( starelid oid NOT NULL, staattnum smallint NOT NULL, stanullfrac real NOT NULL, stawidth integer NOT NULL, stadistinct real NOT NULL, stakind1 smallint NOT NULL, stakind2 smallint NOT NULL, stakind3 smallint NOT NULL, stakind4 smallint NOT NULL, staop1 oid NOT NULL, staop2 oid NOT NULL, staop3 oid NOT NULL, staop4 oid NOT NULL, stanumbers1 real[], stanumbers2 real[], stanumbers3 real[], stanumbers4 real[], stavalues1 anyarray, stavalues2 anyarray, stavalues3 anyarray, stavalues4 anyarray ) Apesar da tabela pg_statistics guardar informação preciosa para consultar estes dados de uma forma mais legível, consulta-se a tabela pg_stats. Esta última é lida por todos, enquanto a primeira apenas é lida pelo supervisor do sistema. Uma consulta a esta tabela pode apresentar os seguintes resultados: SELECT attname, n_distinct, most_common_vals FROM pg_stats WHERE tablename = 'country'; 38

39 Most_common_vals representam, tal como o nome indica, os valores mais comuns que se encontram em determinada tabela. Este valor, com a instrução ANALYZE é por defeito 10. Porém, é possível alterar este número manualmente, com a instrução ALTER TABLE SET STATISTICS. O limite por defeito é 100. Aumentando este valor, temos resultados mais correctos, mas temos também mais entradas na tabela, aumentando a memória consumida. Se por outro lado tivermos poucas entradas, não temos os dados tão correctos. Um outro atributo que entra para esta problemática é o chamado histogram_bounds. Esta coluna contém um vector com os valores para cada coluna da tabela, servindo depois para particionar os dados. Eis um exemplo: SELECT histogram_bounds FROM pg_stats WHERE tablename = 'country' and attname = 'name'; Pg_stats também possui informação sobre correlações, fornecendo correlações estatísticas entre a ordenação física dos tuplos e a ordenação lógica das colunas de valores. Isto cobre as áreas das tabelas estatísticas, mas, o PostgreSQL ainda implementa mais. Implementa também estatísticas sobre o uso de tabelas, como veremos a seguir Mais estimativas Como seria de esperar, para executar perguntas o mais rápido possível, o planificador do PostgreSQL tem de ter informação precisa sobre as tabelas na base de dados em questão, visto que cada operação pode utilizar diferentes algoritmos, sendo necessários dados estatísticos para que se possam fazer aproximações mais precisas. Para que tal seja possível, o PostgreSQL dispõe de um Statistics Collector. Este é um sub-sistema que suporta a recolha de informação sobre a actividade no servidor. O Collector pode contar acessos a tabelas e índices em blocos de disco ou em tuplos individuais. Configuração dado que a recolha de dados estatísticos pode trazer um overhead muito elevado, o sistema pode ser configurável para permitir a recolha ou não destes dados. Isto é controlável através de parâmetros editados no ficheiro postgresql.conf. O parâmetro stats_start_collector tem de estar a true para que tal seja 39

40 possível (o que já está por defeito). Os parâmetros stats_block_level e stats_row_level controlam o fluxo de informação que é enviado para o servidor. O parâmetro stats_command_string permite a monitorização do comando corrente, sem haver necessidade do collector esta a funcionar. É de salientar que os parâmetros stats_block_level e stats_row_level inicialmente estão a false de forma a que o overhead não seja demasiado elevado. É importante saber onde o sistema guarda estas informações. Para tal, existem views próprias que guardam a informação destas estatísticas. É possível também criarem-se views para guardar essas estatísticas. De seguida apresentam-se as várias views onde são guardados os dados: pg_stat_activity, pg_stat_database, pg_stat_all_tables, pg_stat_sys_tables, pg_stat_user_tables, pg_stat_all_indexes, pg_stat_sys_indexes, pg_stat_user_indexes, pg_statio_all_tables, pg_statio_sys_tables, pg_statio_user_tables, pg_statio_all_indexes, pg_statio_sys_indexes, pg_statio_user_indexes, pg_statio_all_sequences, pg_statio_sys_sequences, pg_statio_user_sequences. Estas tabelas podem fornecer variadas informações, desde quais as tabelas mais utilizadas, quais os índices mais utilizados e quão efectivos eles são, quais as estimativas do I/O, entre outras estimativas bastante relevantes para o sistema. Uma outra forma de olhar para as estatísticas é realizando interrogações específicas à base de dados, que seguem o mesmo raciocínio estatístico da secção anterior. Algumas dessas perguntas consistem no seguinte: pg_stat_get_db_numbackends(oid), pg_stat_get_db_xact_commit(oid), pg_stat_get_db_xact_rollback(oid), pg_stat_get_db_blocks_fetched(oid), pg_stat_get_db_blocks_hit(oid), pg_stat_get_numscans(oid), pg_stat_get_tuples_returned(oid), pg_stat_get_tuples_fetched(oid), pg_stat_get_tuples_inserted(oid), pg_stat_get_tuples_updated(oid), pg_stat_get_tuples_deleted(oid), pg_stat_get_blocks_fetched(oid), pg_stat_get_blocks_hit(oid), pg_stat_get_backend_idset(),pg_backend_pid(),pg_stat_get_backend_pid(integer), pg_stat_get_backend_dbid(integer), pg_stat_get_backend_userid(integer), pg_stat_get_backend_activity(integer), pg_stat_get_backend_activity_start(integer), pg_stat_get_backend_start(integer), pg_stat_get_backend_client_addr(integer), pg_stat_get_backend_client_port(integer), pg_stat_reset() Através destas interrogações, podemos obter informação específica sobre, por exemplo, o número de processos de servidores activos, o número de transacções committed na base de dados, o número de transacções rolled back na base de dados, entre outras Estas questões das transacções serão abordadas no capítulo seguinte. Assim sendo, conclui-se a secção das estimativas e estatísticas de uma base de dados. É importante dizer que são guardadas estatísticas sobre custos para determinadas 40

41 operações. Estes custos podem ser manualmente alterados, porém tal não se aconselha, parametrizando-se assim as estatísticas utilizadas Como é que o Planificador Utiliza as Estatísticas (Estimativas de Linhas) Nesta secção vamos ver alguns exemplos de como o Planificador utiliza as estatísticas para determinar a cardinalidade dos valores devolvidos. Para tal, utilizaremos alguns as tabelas das tabelas de regressão da base de dados do PostgreSQL. EXPLAIN SELECT * FROM tenk1; QUERY PLAN Seq Scan on tenk1 (cost= rows=10000 width=244) O número de páginas e de linhas é verificado na tabela pg_class falada anteriormente. Estes números são correntes desde o último ANALYZE ou VACUUM à tabela (comandos de limpeza de estatísticas). Passemos para um exemplo com a condição WHERE. EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 1000; QUERY PLAN Bitmap Heap Scan on tenk1 (cost= rows=1007 width=244) Recheck Cond: (unique1 < 1000) -> Bitmap Index Scan on tenk1_unique1 (cost= rows=1007 width=0) Index Cond: (unique1 < 1000) O planificador examina a cláusula WHERE e vê a função de selecção para o operador < na tabela pg_operator. Isto é guardado na coluna oprrest e na entrada scalarltsel. Esta última devolve um histograma para unique1 de pg_statistics. De acordo com este histograma, e assumindo uma distribuição linear dos valores em cada bloco, é possível calcular a selecção através da seguinte expressão matemática: selectivity = (1 + ( bucket[2].min)/(bucket[2].max - bucket[2].min))/num_buckets O número estimado de linhas pode depois ser calculado como o produto da selecção com a cardinalidade de tenk1: rows = rel_cardinality * selectivity 41

42 Vejamos agora um exemplo em que existe uma cláusula WHERE com uma restrição de igualdade: EXPLAIN SELECT * FROM tenk1 WHERE stringu1 = 'CRAAAA'; QUERY PLAN Seq Scan on tenk1 (cost= rows=30 width=244) Filter: (stringu1 = 'CRAAAA'::name) Novamente, o planificador examina a condição WHERE e verifica a função de selecção para o operador =. Para questões de igualdade, o histograma não é utilizado. Ao invés utiliza-se a lista de most common values (MCV). Vejamos um exemplo de MCV s. SELECT null_frac, n_distinct, most_common_vals, most_common_freqs FROM pg_stats WHERE tablename='tenk1' AND attname='stringu1'; null_frac 0 n_distinct 676 most_common_vals {EJAAAA,BBAAAA,CRAAAA,FCAAAA,FEAAAA,GSAAAA,JOAAAA,MCAAAA,NAAAAA,WGAAAA } most_common_freqs { ,0.003,0.003,0.003,0.003,0.003,0.003,0.003,0.003,0.003} Visto que CRAAAA aparece na lista de MCV s, a selecção corresponde meramente à entrada correspondente à lista de most commons frequencies (MCF): selectivity = mcf[3] = Tal como anteriormente, o número estimado de linhas é calculado pela multiplicação disto com a cardinalidade de tenk1. Para um caso em que o valor não esteja na lista de valores mais comuns, é aplicada uma diferente estratégia. Tira-se proveito de se saber que o valor não é muito comum, e aplica-se a seguinte fórmula: selectivity = (1 - sum(mvf))/(num_distinct - num_mcv) Depois, multiplica-se pela cardinalidade e obtemos o número de linhas pretendido. Para valores únicos (como é o exemplo das chaves primárias), não são guardadas entradas em MCV (obviamente, nenhum valor é mais comum que outro), nem histogramas. Para um valor não único, é guardado um histograma e uma lista de MVC. Observemos agora um exemplo com mais do que uma condição na cláusula WHERE. 42

43 EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 1000 AND stringu1 = 'xxx'; QUERY PLAN Bitmap Heap Scan on tenk1 (cost= rows=1 width=244) Recheck Cond: (unique1 < 1000) Filter: (stringu1 = 'xxx'::name) -> Bitmap Index Scan on tenk1_unique1 (cost= rows=1007 width=0) Index Cond: (unique1 < 1000) O planificador assume que as duas condições são independentes, de forma a que as selecções individuais das cláusulas possam ser multiplicadas juntas. selectivity = selectivity(unique1 < 1000) * selectivity(stringu1 = 'xxx') Por último, vejamos um exemplo de uma interrogação que envolva uma operação de junção. EXPLAIN SELECT * FROM tenk1 t1, tenk2 t2 WHERE t1.unique1 < 50 AND t1.unique2 = t2.unique2; QUERY PLAN Nested Loop (cost= rows=50 width=488) -> Bitmap Heap Scan on tenk1 t1 (cost= rows=50 width=244) Recheck Cond: (unique1 < 50) -> Bitmap Index Scan on tenk1_unique1 (cost= rows=50 width=0) Index Cond: (unique1 < 50) -> Index Scan using tenk2_unique2 on tenk2 t2 (cost= rows=1 width=244) Index Cond: (t2.unique2 = t1.unique2) A restrição tenk.unique1 < 50 é avaliada antes do Nested-Loop-Join. Isto é feito analogamente às análises anteriores. A restrição para a junção é t1.unique1=t2.unique2. A operação = já é conhecida, porém, a função de selecção é obtida na coluna oprjoin em pg_operator. Visto que são ambos valores únicos, utiliza-se um algoritmo que se baseia no número de valores distitintos para ambas as relações juntamente com as suas fracções nulas. selectivity = (1 - null_frac1) * (1 - null_frac2) * min(1/num_distinct1, 1/num_distinct2) O número de linhas é então calculado pela cardinalidade do produto cartesiano dos dois inputs, multiplicados pela selecção: rows = (outer_cardinality * inner_cardinality) * selectivity Note-se que os atributos de junção eram ambos atributos únicos. Caso não fosse, um algoritmo diferente seria utilizado (sendo na mesma muito semelhante a este). 43

44 5.11. Mecanismos de Visualização de Planos de Perguntas No sistema do PostgreSQL, o mecanismo utilizado para ver os planos de perguntas é o comando EXPLAIN. EXPLAIN [ ANALYZE ] [ VERBOSE ] statement Este comando mostra o plano que o PostgreSQL gera para determinada pergunta. Mostra como a tabela vai ser pesquisada, se por pesquisa sequencial, se por pesquisa por índex e, se múltiplas tabelas forem referenciadas, que algoritmos de junção vão ser utilizados. A parte mais crítica é o custo estimado de execução da pergunta (medido em unidades de disk page fetches). São mostrados dos números, o tempo de começo e o tempo total de devolução dos dados, sendo que estes tempos são medidos em milissegundos. Na maior parte dos casos o mais importante é o tempo total de duração, mas existem situações particulares em que o tempo inicial também entra em conta. Parâmetros: Analyze a opção analyze causa a execução da query, não somente a sua planificação. Verbose mostra a representação interna da árvore de planificação, ao invés de apenas um sumário. Esta opção é mais utilizada para propósitos de debugging. Statement qualquer SELECT, INSERT, UPDATE, DELETE, EXECUTE, DECLARE, cujo plano de execução deseje ser visto. De seguida é mostrado um exemplo de um plano de execução para a instrução: explain analyze select * from country; Passamos agora a explicar um pouco melhor os resultados obtidos na imagem anterior. Tipo de operação requisitada, neste caso, Seq Scan. Custo estimado de execução, apresentando-se na forma de intervalo, em que o primeiro valor mostra a rapidez com que a primeira linha no conjunto de resultados é devolvida e o segundo o tempo total da operação. Número de linhas (rows) esperado. Tamanho em bytes médio dos tuplos no conjunto de resultados (bytes). Custo real de execução caso o comando ANALYZE tenha sido introduzido. 44

45 Apresenta-se de seguida um exemplo um pouco mais complexo, por forma a que uma melhor percepção deste mecanismo seja compreendido: explain analyze select * from country order by name ASC; Como se pode observar através da imagem anterior, é simples reparar que há dois processos distintos em causa. Primeiramente é efectuada uma ordenação e depois é efectuada uma selecção de dados, tal como se pode constatar na imagem anterior. 45

46 6. Gestão de transacções e controlo de concorrência 6.1. Definição de transacção Num sistema de bases de dados, existem muitas operações que podem ser executadas (select, insert, update ). Podemos assumir também que as bases de dados não estão, na maior parte dos casos, projectadas para serem utilizadas por uma pessoa em particular, mas sim por várias pessoas. Consideremos o exemplo de um banco: várias pessoas podem fazer depósitos, levantamentos, consultas, etc, e podem-no fazer concorrentemente. É então importante ter um sistema que proteja a base de dados de erros que possam ocorrer devido a esta concorrência. É no âmbito desta protecção que surgem as transacções, que permitem que haja um controlo grande nestas questões de concorrência, fornecendo ferramentas fiáveis de recuperação de dados em casos de falhas, mantendo a base de dados consistente, fornecendo também isolamento entre programas a aceder a uma base de dados. De seguida apresentaremos as propriedades chave que uma transacção deverá ter. Uma má gestão destas pode levar uma base de dados a guardar dados inconsistentes ou simplesmente errados. Retomando o exemplo do banco, uma má gestão da base de dados aqui pode comprometer seriamente as economias das pessoas, o que não é de todo desejado Propriedades ACID das transacções Todas as transacções de um sistema de base de dados devem respeitar as propriedades ACID (atomicidade, consistência, isolamento e durabilidade). Atomicidade (A) a atomicidade corresponde a uma política de all or nothing. Atomicidade diz que uma operação não pode ser partida em várias sub-operações, sendo que se esta falha, nada é executado. Ou a operação é executada toda com sucesso ou não é sequer executada. Pegando novamente no exemplo do banco, imaginemos que o cliente A está a fazer uma transferência para o cliente B. Não se quer que a operação termine a meio, sendo que já foi debitado dinheiro da conta de A, apesar de não ter sido aumentado o saldo de B. Assim, ou se faz a transferência por completo ou não se faz de todo. Consistência (C) a consistência garante que a base de dados se apresenta consistente antes e depois da transacção (independentemente do sucesso desta). Para tal, na base de dados só podem ser introduzidos valores válidos. Caso tentem ser inseridos valores não válidos, a operação voltará atrás, deixando a base de dados no estado consistente original. Porém, em estado intermédio, é possível que a transacção esteja num estado inconsistente. Isolamento (I) o isolamento refere-se ao requisito de que certas operações não podem aceder nem ver dados num estado intermédia de uma transacção. Esta propriedade por ser assegurada correndo transacções serialmente, ou seja, uma depois da outra, por vezes perdendo a capacidade de concorrência que pode ser muito útil em certas ocasiões. Durabilidade (D) a durabilidade é algo que garante ao utilizador que, assim que este for notificado do sucesso da transacção, as alterações feitas na base de dados têm de persistir mesmo havendo falhas a nível de software ou hardware. 46

47 Geralmente, os sistemas de bases de dados implementam transacções que obedecem a este conjunto de regras, porém, existem aplicações em que tais propriedades não são sempre desejadas. Tomemos como exemplo uma transacção significativamente grande (long duration transactions). Neste caso, pode-se não querer, ou conseguir, que o isolamento seja garantido, devido ao longo tempo de execução da transacção. Sem este isolamento, a atomicidade por ser comprometida. Uma solução para este problema é definir acções de compensação, ou seja, definir um conjunto de regras do que fazer no caso de, mais tarde, a transacção falhar. O PostgreSQL não tem suporte para long-duration transactions. A implementação das transacções não é trivial, sendo que mais à frente serão abordados alguns métodos aplicados a estas Estado de uma transacção Na ausência de falhas, todas as transacções são concluídas com êxito. Contudo, uma transacção pode nem sempre ser concluída com sucesso. Quando tal acontece, dizse que a transacção foi abortada (aborted). De acordo com as propriedades ACID, a atomicidade implica que se a transacção não foi concluída, então nada dela foi concluída, sendo necessário cancelar tudo o que foi feito. Tal processo chama-se rollback. Se uma transacção foi executada com sucesso, diz-se que foi committed. De acordo com isto, é possível estabelecer variados estados para as transacções: Active corresponde ao estado inicial. A transacção fica neste estado enquanto está a ser executada. Partially Committed após a última instrução ter sido executada Failed depois de se descobrir que a execução normal não pode continuar Aborted quando a transacção foi rolled back e a base de dados voltou ao estado antes da transacção Committed como dito antes, após uma conclusão da transacção com êxito. 47

48 partially commited committed active failed aborted Figura 11 Esquema dos vários estados das transacções 6.4. Controlo de Concorrência Após uma abordagem inicial sobre transacções, é fácil verificar que estas fazem sentido num âmbito concorrente. O controlo de concorrência é uma das coisas mais importantes em bases de dados grandes. Tomemos novamente como exemplo o caso de um banco, em que várias pessoas podem aceder aos mesmos dados em simultâneo, fazendo várias operações iguais ou diferentes. Caso não haja um controlo de concorrência forte, poderiam existir problemas sérios. Para lidar com este problema, foram desenvolvidas técnicas específicas, de acordo a conseguir lidar com esta concorrência. Antes de passarmos para o PostgreSQL, em seguida falamos de algumas técnicas mais comuns, sendo elas as seguintes: Protocolos Baseados em Locks estes protocolos baseiam-se, tal como o nome indica, na utilização de locks. Através destas propriedades, podemos garantir que o acesso a determinados dados são feitos de acordo com estes locks, mas basicamente a ideia é que se uma transacção está a aceder a determinados dados, mais nenhuma transacção pode aceder a estes (modo exclusivo). Através de propriedades de locks e unlocks conseguimos estabelecer estas regras. Note-se que estes locks podem ser do tipo exclusivo, em que se uma transacção obtém um exclusive-mode lock mais nenhuma transacção poderá ler ou escrever sobre esses dados, ou também podem ser do tipo shared, em que se uma transacção obtém o shared-mode lock qualquer outra transacção poderá ler os mesmos dados, mas nunca escrever neles. Um protocolo deste género muito conhecido é o Two-Phase Locking Protocol, que consiste em duas fases distintas, Growing phase, onde são obtidos os locks sem nunca os libertar, e a shrinking phase, onde uma transacção liberta os locks, não os podendo obter mais. 48

49 Protocolos Baseados em Time-Stamps para cada transacção no sistema, é atribuído um time-stamp, antes de esta começar a execução. Há então duas formas de funcionamento: a atribuição do time-stamp pode ser com a utilização do clock do sistema ou utilizando um contador lógico, que é incrementado sempre que uma nova transacção entra no sistema. Através destes time-stamps consegue-se fazer um controlo de concorrência. Protocolos Multi-Versões De forma a maximizar ainda mais a concorrência, este tipo de protocolo cria várias cópias do mesmo item. Assim, cada write (Q) cria uma nova versão de Q e quando Q é chamado para leitura, o sistema elege a versão do Q mais apropriada, garantida a serialização. É neste âmbito que surgem então os protocolos Multiversion Timestamp Ordering e o conhecido Two-Phase Locking. É de notar que existem outros protocolos, mas estes são dos mais conhecidos e dos mais utilizados, razão pela qual não são apresentados os restantes Transacções e Gestão de Concorrência no PostgreSQL Definição de Transacção - para começar este tema, é importante primeiro dizer que o PostgreSQL, por defeito, implementa uma política de auto-commit. Desta forma, cada instrução é tratada como uma transacção. Um read é uma transacção, um write é outra, etc Há então duas formas de contornar esta situação: uma é simplesmente desligar o auto-commit, através da instrução \SET AUTOCOMMIT OFF. Assim, é tudo considerado uma transacção até que a instrução commit seja executada. A outra solução passa por indicar explicitamente o início e o fim de uma transacção usando o comando BEGIN no início da transacção e o comando COMMI; no final desta. Caso se pretenda anular a transacção, ao invés do comando COMMIT é possível introduzir o comando ROLLBACK. Poderia existir a possibilidade de o PostgreSQL permitir a ocorrência de nested transactions. Tal não é possível neste sistema. A sua gestão não é trivial, e pode não ser aconselhada em muitas situações. Postgres =# begin; Postgtes =# begin; WARNING: there is already a transaction in progress. Como se pode observar, não é possível a ocorrência de nested transactions. Garantia de Isolamento O PostgreSQL, ao invés de muitos outros SGBD s, mantém os dados coerentes através da utilização de modelos multi-versão (Multiversion Concurrency Control, MVCC). Assim, cada transacção vê uma versão da base de dados (snapshot) tal como era em algum tempo atrás, independentemente do estado actual dos dados, evitando assim o problema de uma transacção poder ver os dados incoerentes. Protocolos a nível de locks de tabela e tuplo também são possíveis no PostgreSQL, para aplicações que não se adaptem bem ao funcionamento do modelo MVCC, sendo que é necessário estabelecer manualmente o nível de granularidade desejado. Contudo, um uso cuidado no MVCC é melhor que a utilização de locks. 49

50 Isolamento nas Transacções o SQL standard define quatro níveis de isolamento de transacções de acordo com três fenómenos que não devem acontecer entre transacções concorrentes, sendo os fenómenos os seguintes: dirty reading, nonrepeatable read e phantom read. Dirty reading uma transacção lê dados que foram entretanto modificados por uma outra transacção concorrente que ainda não realizou o comando commit; Nonrepeatable read uma transacção re-lê dados e descobre que os estes foram modificados por uma outra transacção; Phantom read uma transacção executa novamente uma pergunta e descobre que os valores que satisfazem a pergunta são diferentes da anterior, devido a um commit de uma outra transacção. Os quatro níveis de isolamento das transacções SQL são as seguintes: Figura 12 Vários níveis de isolamento das transacções SQL O PostgreSQL suporta o Read Commited e o Serializable. Para então se determinar qual o nível de isolamento pretendido, devem-se utilizar uma das seguintes operações: SET TRANSACTION transaction_mode [,...] SET SESSION CHARACTERISTICS AS TRANSACTION transaction_mode [,...] Sendo que transaction_mode pode ser um dos seguintes: ISOLATION LEVEL { SERIALIZABLE REPEATABLE READ READ COMMITTED READ UNCOMMITTED } READ WRITE READ ONLY Nota: para se utilizar o comando SET TRANSACTION sem que seja inicializada uma transacção especificamente com o comando START TRANSACTION ou BEGIN (no caso de estarmos perante um sistema em auto-commit), então não haverá qualquer efeito sobre esta, visto que a transacção acabará imediatamente. Se o comando SET TRANSACTION for utilizado correctamente, este também só afectará a actual transacção, enquanto o comando SET SESSION CHARACTERISTICS AS TRANSACTION afectará todas as transacções da sessão, sendo que SET TRANSACTION pode subscrever as transacções da sessão para uma transacção em particular. Como já foi dito, o PostgreSQL implementa o Serializable e o Read Commited. Como o standard SQL tem mais dois elementos, o Read Uncommitted é tratado como um Repetable Read é tratado como Serializable. É de nota que o Read Commited é o grau de isolamento standard do sistema em questão. Níveis de Granularidade (Locks) o PostgreSQL permite a utilização de locks com vários níveis de granularidade (explicit locking), a nível de tabela, a nível de 50

51 tuplos e, em versões mais recentes, os chamados advisory locks. Para criar locks a nível de tabela, a instrução utilizada é a seguinte: LOCK [ TABLE ] [ ONLY ] name [,...] [ IN lockmode MODE ] [ NOWAIT ] Sendo que lock mode é um dos seguintes: ACCESS SHARE ROW SHARE ROW EXCLUSIVE SHARE UPDATE EXCLUSIVE SHARE SHARE ROW EXCLUSIVE EXCLUSIVE ACCESS EXCLUSIVE Cada um destes lock modes corresponde a um tipo de lock diferente. Se o no wait for introduzido, se a tabela não consegue obter o lock desejado, o comando é abortado e uma mensagem de erro é emitida. Quando obtido, o lock dura até ao final da transacção. Note-se que não há nenhum comando do tipo unlock table, já que o lock dura somente até ao final de transacção em questão. É de notar também que duas transacções não podem conter locks em modo conflituoso. Caso se tente ter lock de uma tabela num modo conflituoso, o último processo fica bloqueado até que um dos modos seja libertado. Em seguida apresentaremos um quadro onde estão indicados os vários tipos de conflito que podem existir no sistema: Figura 13 Níveis de granularidade e tipos de conflito possíveis entre eles Relativamente aos locks por tuplo, estes podem ser shared ou exclusive. Um exclusive lock é obtido automaticamente aquando de um update ou de um delete. Um lock a nível de tuplo não afecta as perguntas. Para se obter um lock sem que haja alteração dos dados, é possível faze-lo explicitamente, através dos seguintes comandos: SELECT FOR SHARE SELECT FOR UPDATE A primeira cria locks exclusivos enquanto que a segunda cria locks partilhados. Como seria de esperar, ao utilizarmos um sistema de locks podemos introduzir deadlocks no sistema. Todavia, o PostgreSQL contém mecanismos que conseguem detectar um deadlock, abortando uma das transacções intervenientes, permitindo a outra transacção avançar. Quando acontece o deadlock, a transacção mais recente é desbloqueada, sendo a última a terminada, surgindo uma mensagem de erro semelhante à seguinte: Process 5136 waits for ShareLock on transaction 756; blocked by process 1424 waits for ShareLock on transaction 755; blocked by process

Estudo do Sistema de Gestão de Bases de Dados PostgreSQL. André Ricardo Carlos Nobre Cristiano Lopes Nº 31208 Nº 31211 Nº 17662

Estudo do Sistema de Gestão de Bases de Dados PostgreSQL. André Ricardo Carlos Nobre Cristiano Lopes Nº 31208 Nº 31211 Nº 17662 Estudo do Sistema de Gestão de Bases de Dados PostgreSQL André Ricardo Carlos Nobre Cristiano Lopes Nº 31208 Nº 31211 Nº 17662 Índice 1 Introdução 5 1.1 Introdução histórica e aplicabilidade do sistema

Leia mais

Sistemas de Base de Dados 2010/11 GRUPO 10 ANDRÉ MOURÃO Nº 35008 EDUARDO COSTA Nº 355049 RICARDO MARQUES Nº 35048

Sistemas de Base de Dados 2010/11 GRUPO 10 ANDRÉ MOURÃO Nº 35008 EDUARDO COSTA Nº 355049 RICARDO MARQUES Nº 35048 DEPARTAMENTO DE INFORMÁTICA TRABALHO FINAL POSTGRESQL Sistemas de Base de Dados 2010/11 Mestrado em Engenharia Informática GRUPO 10 ANDRÉ MOURÃO Nº 35008 EDUARDO COSTA Nº 355049 RICARDO MARQUES Nº 35048

Leia mais

Regras de Integridade. Profa. Késsia Marchi

Regras de Integridade. Profa. Késsia Marchi Regras de Integridade Restrições de Integridade Integridade refere-se a precisão ou correção de dados em um banco de dados; Restrição refere-se a impor uma condição para qualquer atualização. Antes de

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

SQL (Structured Query Language)

SQL (Structured Query Language) (Structured Query Language) I DDL (Definição de Esquemas Relacionais)... 2 I.2 Domínios... 2 I.3 Criação de Tabelas... 2 I.4 Triggers... 4 II DML Linguagem para manipulação de dados... 5 II.2 Comando SELECT...

Leia mais

Consistem num conjunto de apontadores para instâncias especificas de cada relação.

Consistem num conjunto de apontadores para instâncias especificas de cada relação. Mecanismo usado para mais fácil e rapidamente aceder à informação existente numa base de dados. Bases de Dados de elevadas dimensões. Consistem num conjunto de apontadores para instâncias especificas de

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

Structured Query Language (SQL)

Structured Query Language (SQL) Structured Query Language (SQL) SQL-Breve Histórico : # CREATE, ALTER e DROP; # BEGIN TRANSACTION, ROLLBACK e COMMIT; # GRANT, REVOKE e DENY; 1 Structured Query Language (SQL) Desenvolvida pelo departamento

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

SQL TGD/JMB 1. Projecto de Bases de Dados. Linguagem SQL

SQL TGD/JMB 1. Projecto de Bases de Dados. Linguagem SQL SQL TGD/JMB 1 Projecto de Bases de Dados Linguagem SQL SQL TGD/JMB 2 O que é o SQL? SQL ("ess-que-el") significa Structured Query Language. É uma linguagem standard (universal) para comunicação com sistemas

Leia mais

SQL92 DDL( RIS, ACTUALIZAÇÕES E VISTAS) DML (QUERIES, SUBQUERIES,JUNÇÕES, E OPERAÇÕES SOBRE CONJUNTOS)

SQL92 DDL( RIS, ACTUALIZAÇÕES E VISTAS) DML (QUERIES, SUBQUERIES,JUNÇÕES, E OPERAÇÕES SOBRE CONJUNTOS) SQL92 DDL( RIS, ACTUALIZAÇÕES E VISTAS) DML (QUERIES, SUBQUERIES,JUNÇÕES, E OPERAÇÕES SOBRE CONJUNTOS) SQL SQL, é uma linguagem de programação que foi desenvolvida para questionar bases de dados relacionais

Leia mais

Tarefa Orientada 19 Triggers

Tarefa Orientada 19 Triggers Tarefa Orientada 19 Triggers Objectivos: Criar triggers AFTER Criar triggers INSTEAD OF Exemplos de utilização Os triggers são um tipo especial de procedimento que são invocados, ou activados, de forma

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

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

SQL Linguagem de Definição de Dados. Laboratório de Bases de Dados Profa. Dra. Cristina Dutra de Aguiar Ciferri

SQL Linguagem de Definição de Dados. Laboratório de Bases de Dados Profa. Dra. Cristina Dutra de Aguiar Ciferri SQL Linguagem de Definição 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 Ingress SQL

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

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

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

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

Administração e Optimização de BDs

Administração e Optimização de BDs Departamento de Engenharia Informática 2010/2011 Administração e Optimização de BDs Mini-Projecto 1 2º semestre A resolução deve ser claramente identificada com o número de grupo e entregue sob a forma

Leia mais

Banco de Dados. PostgreSQL

Banco de Dados. PostgreSQL Banco de Dados PostgreSQL 2010 Banco de Dados PostgreSQL Banco de Dados II Equipe: Equipe Postgre Líder: Alexandre Strauss... 01 Aline Cássia Lima dos Santos... 02 Erik Machado... 09 Fernando Gomes Brandã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

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

DBMS%Performance% Carlos%Soares% (baseado%em%materiais%gen8lmente%cedidos% por%andré%res8vo,%joão%correia%lopes%e%do% livro%ramakrishnan%&%gehrke)% %

DBMS%Performance% Carlos%Soares% (baseado%em%materiais%gen8lmente%cedidos% por%andré%res8vo,%joão%correia%lopes%e%do% livro%ramakrishnan%&%gehrke)% % DBMS%Performance% Carlos%Soares% (baseado%em%materiais%gen8lmente%cedidos% por%andré%res8vo,%joão%correia%lopes%e%do% livro%ramakrishnan%&%gehrke)% % Plano% Contexto% Índices% Carga%da%base%de%dados%%

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

0 1 5 5 _ B A S E D E D A D O S P A R A I N T E R N E T ( S E R V E R S I D E )

0 1 5 5 _ B A S E D E D A D O S P A R A I N T E R N E T ( S E R V E R S I D E ) 0 1 5 5 _ B A S E D E D A D O S P A R A I N T E R N E T ( S E R V E R S I D E ) EFA NÍVEL SECUNDÁRIO TECNOLOGIAS DE INFORMAÇÃO E COMUNICAÇÃO MULTIMÉDIA (TICM) 04-05-2011 0155_Base de dados para Internet

Leia mais

Bases de Dados 2012/2013 Restrições de Integridade em SQL. Helena Galhardas 2012 IST. Bibliografia

Bases de Dados 2012/2013 Restrições de Integridade em SQL. Helena Galhardas 2012 IST. Bibliografia Bases de Dados 2012/2013 Restrições de Integridade em SQL Helena Galhardas Bibliografia Raghu Ramakrishnan, Database Management Systems, Cap. 3 e 5 1 1 Sumário Restrições de Integridade (RIs) em SQL Chave

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

Bases de Dados 2005/2006. Aula 5

Bases de Dados 2005/2006. Aula 5 Bases de Dados 2005/2006 Aula 5 Sumário -1. (T.P.C.) Indique diferenças entre uma tabela e uma relação. 0. A base de dados Projecto 1. SQL Join (variantes) a. Cross Join b. Equi-Join c. Natural Join d.

Leia mais

BANCO DE DADOS II Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com

BANCO DE DADOS II Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com - Aula 11-1. INTRODUÇÃO TRIGGERS (GATILHOS OU AUTOMATISMOS) Desenvolver uma aplicação para gerenciar os dados significa criar uma aplicação que faça o controle sobre todo ambiente desde a interface, passando

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

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

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

Programação SQL. Introdução

Programação SQL. Introdução Introdução Principais estruturas duma Base de Dados: Uma BD relacional é constituída por diversas estruturas (ou objectos ) de informação. Podemos destacar: Database: designa a própria BD; Table/Tabela:

Leia mais

SQL - Criação de Tabelas

SQL - Criação de Tabelas SQL - Criação de Tabelas André Restivo Faculdade de Engenharia da Universidade do Porto February 24, 2012 André Restivo (FEUP) SQL - Criação de Tabelas February 24, 2012 1 / 25 Sumário 1 Introdução 2 Tabelas

Leia mais

BD Oracle. Licenciatura em Engenharia Informática e Computação. Bases de Dados 2003/04

BD Oracle. Licenciatura em Engenharia Informática e Computação. Bases de Dados 2003/04 BD Oracle SGBD Oracle Licenciatura em Engenharia Informática e Computação Bases de Dados 2003/04 BD Oracle Introdução aos SGBD Base de Dados Colecção de dados que descrevem alguma realidade Sistema de

Leia mais

Bases de Dados Distribuídas

Bases de Dados Distribuídas Introdução Devido ao ambiente de grande competitividade em que as organizações de hoje têm que actuar, estas são forçadas a distribuir-se geograficamente, procurando as condições locais mais favoráveis

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

Banco de Dados I 2007. Módulo V: Indexação em Banco de Dados. (Aulas 4) Clodis Boscarioli

Banco de Dados I 2007. Módulo V: Indexação em Banco de Dados. (Aulas 4) Clodis Boscarioli Banco de Dados I 2007 Módulo V: Indexação em Banco de Dados (Aulas 4) Clodis Boscarioli Agenda: Indexação em SQL; Vantagens e Custo dos Índices; Indexação no PostgreSQL; Dicas Práticas. Índice em SQL Sintaxe:

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

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

BANCO DE DADOS. info 3º ano. Prof. Diemesleno Souza Carvalho diemesleno@iftm.edu.br www.diemesleno.com.br

BANCO DE DADOS. info 3º ano. Prof. Diemesleno Souza Carvalho diemesleno@iftm.edu.br www.diemesleno.com.br BANCO DE DADOS info 3º ano Prof. Diemesleno Souza Carvalho diemesleno@iftm.edu.br www.diemesleno.com.br Na última aula estudamos Unidade 4 - Projeto Lógico Normalização; Dicionário de Dados. Arquitetura

Leia mais

Tarefa Orientada 15 Manipulação de dados

Tarefa Orientada 15 Manipulação de dados Tarefa Orientada 15 Manipulação de dados Objectivos: Criação de tabelas teste Comando INSERT INTO Inserção de dados Comando INSERT Actualização de dados Comando UPDATE Eliminação de dados Comando DELETE

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

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

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

Tarefa Orientada 16 Vistas

Tarefa Orientada 16 Vistas Tarefa Orientada 16 Vistas Objectivos: Vistas só de leitura Vistas de manipulação de dados Uma vista consiste numa instrução de SELECT que é armazenada como um objecto na base de dados. Deste modo, um

Leia mais

Linguagem SQL Sub-linguagem DDL

Linguagem SQL Sub-linguagem DDL Linguagem SQL Sub-linguagem DDL A SQL - Structured Query Language, foi desenvolvido pela IBM em meados dos anos 70 como uma linguagem de manipulação de dados (DML - Data Manipulation Language para suas

Leia mais

Programação SQL. INTRODUÇÃO II parte

Programação SQL. INTRODUÇÃO II parte Programação SQL INTRODUÇÃO II parte Programação SQL SELECT; INSERT; UPDATE; DELETE. Este conjunto de comandos faz parte da sublinguagem denominada por DML Data Manipulation Language (Linguagem de manipulação

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

Administração de Banco de Dados

Administração de Banco de Dados Administração de Banco de Dados Adriano J. Holanda http://holanda.xyz 28/8/2015 Índices Para os testes com os índices criaremos uma tabela chamada tteste com o comando teste=> CREATE TABLE tteste (id int4);

Leia mais

A compreensão do mecanismo de transações é essencial, sempre que a

A compreensão do mecanismo de transações é essencial, sempre que a Transações A compreensão do mecanismo de transações é essencial, sempre que a base de dados d servir várias clientes simultaneamente. Em SQL é possível definir explicitamente os limites de uma transação.

Leia mais

COMPETÊNCIAS ESPECÍFICAS Compreender e utilizar a linguagem SQL, na construção e manutenção de uma base de dados.

COMPETÊNCIAS ESPECÍFICAS Compreender e utilizar a linguagem SQL, na construção e manutenção de uma base de dados. PLANIFICAÇÃO DA DISCIPLINA DE SISTEMAS DE INFORMAÇÃO 12.ºH CURSO PROFISSIONAL DE TÉCNICO MULTIMÉDIA ANO LECTIVO 2013/2014 6. LINGUAGENS DE PROGRAMAÇÃO IV Pré-requisitos: - Planificar e estruturar bases

Leia mais

Triggers em PostgreSQL. Linguagem de Programação de Banco de Dados. Triggers em PostgreSQL. Triggers em PostgreSQL

Triggers em PostgreSQL. Linguagem de Programação de Banco de Dados. Triggers em PostgreSQL. Triggers em PostgreSQL Prof. Ms. Luiz Alberto Contato: lasf.bel@gmail.com Linguagem de Programação de Banco de Dados Triggers em PostgreSQL Todos os bancos de dados comerciais possuem uma linguagem procedural auxiliar para a

Leia mais

SQL Server Triggers Aprenda a utilizar triggers em views e auditar as colunas atualizadas em uma tabela

SQL Server Triggers Aprenda a utilizar triggers em views e auditar as colunas atualizadas em uma tabela SQL Server Triggers Aprenda a utilizar triggers em views e auditar as colunas atualizadas em uma tabela Certamente você já ouviu falar muito sobre triggers. Mas o quê são triggers? Quando e como utilizá-las?

Leia mais

Comandos DDL. id_modulo = id_m odulo

Comandos DDL. id_modulo = id_m odulo Comandos DDL Estudo de Caso Controle Acadêmico Simplificado Uma escola contém vários cursos, onde cada aluno possui uma matricula num determinado curso. Estes cursos, por sua vez, possuem módulos, aos

Leia mais

Linguagem de Consulta Estruturada SQL- DML

Linguagem de Consulta Estruturada SQL- DML Linguagem de Consulta Estruturada SQL- DML INTRODUÇÃO A SQL - Structured Query Language, foi desenvolvido pela IBM em meados dos anos 70 como uma linguagem de manipulação de dados (DML - Data Manipulation

Leia mais

Banco de dados 1. Linguagem SQL DDL e DML. Professor: Victor Hugo L. Lopes

Banco de dados 1. Linguagem SQL DDL e DML. Professor: Victor Hugo L. Lopes Banco de dados 1 Linguagem SQL DDL e DML Professor: Victor Hugo L. Lopes Agenda: Introdução à linguagem de dados; DDL; DML; CRUD; Introdução à linguagem SQL. 2 Por que precisamos da linguagem SQL? A algebra

Leia mais

Triggers. um trigger permite que uma determinada sequência de comandos SQL seja accionada quando um determinado evento ocorre.

Triggers. um trigger permite que uma determinada sequência de comandos SQL seja accionada quando um determinado evento ocorre. Triggers um trigger permite que uma determinada sequência de comandos SQL seja accionada quando um determinado evento ocorre. o evento pode ser INSERT, UPDATE, ou DELETE. o trigger pode ser accionado imediatamente

Leia mais

Auditoria de sistemas Deixe que seu banco de dados faça o trabalho por você

Auditoria de sistemas Deixe que seu banco de dados faça o trabalho por você Auditoria de sistemas Deixe que seu banco de dados faça o trabalho por você por Cristóferson Guimarães Magalhães Bueno e Odilon Corrêa da Silva 1 O objetivo deste artigo é demonstrar como criar um sistema

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

Sistemas de Base de Dados

Sistemas de Base de Dados Sistemas de Base de Dados Análise do SGBD PostgreSQL Bruno Barão nº28061 Fábio Afonso nº30218 Hugo Fernandes nº28062 Índice de Conteúdos Índice de Conteúdos...ii Introdução... 1 Introdução Histórica...

Leia mais

Exemplos de Vistas SQL. Tipos em SQL. Linguagem de Definição de Dados (DDL) CREATE VIEW todososclientes As

Exemplos de Vistas SQL. Tipos em SQL. Linguagem de Definição de Dados (DDL) CREATE VIEW todososclientes As Exemplos de Vistas SQL Considere-se a vista (com o nome todososconsumidores) contento os nomes das agências e seus clientes CREATE VIEW todososclientes As Π nomebalcao,nomecliente (temconta conta) Π nomebalcao,nomecliente

Leia mais

BASES DE DADOS I LTSI/2. Universidade da Beira Interior, Departamento de Informática Hugo Pedro Proença, 2010/2011

BASES DE DADOS I LTSI/2. Universidade da Beira Interior, Departamento de Informática Hugo Pedro Proença, 2010/2011 BASES DE DADOS I LTSI/2 Universidade da Beira Interior, Departamento de Informática Hugo Pedro Proença, 2010/2011 A Linguagem SQL As raízes da linguagem SQL remontam a 1974, altura em que a IBM desenvolvia

Leia mais

Programação SQL. Manipulação de Dados. DML Data Manipulation Language

Programação SQL. Manipulação de Dados. DML Data Manipulation Language Programação SQL Manipulação de Dados DML Data Manipulation Language Manipulação de Dados (DML) Os comandos INSERT, UPDATE, DELETE, são normalmente classificados como pertencendo a uma sublinguagem da linguagem

Leia mais

Banco de Dados - Senado

Banco de Dados - Senado Banco de Dados - Senado Structured Query Language (SQL) Material preparado :Prof. Marcio Vitorino Ambiente Simplificado de um SGBD 2 Características dos SGBDs Natureza auto-contida de um sistema de banco

Leia mais

Sistemas de Informação

Sistemas de Informação Sistemas de Informação Rules and Triggers André Restivo Sistemas de Informação 2006/07 Rules e Triggers Nem todas as restrições podem ser definidas usando os mecanismos que estudamos anteriormente: - CHECK

Leia mais

Bases de Dados 2007/2008. Aula 9

Bases de Dados 2007/2008. Aula 9 Bases de Dados 2007/2008 Aula 9 1. T-SQL TRY CATCH 2. TRATAMENTO ERROS RAISERROR 3. TRIGGERS 4. EXERCÍCIOS Sumário Referências http://msdn2.microsoft.com/en-us/library/ms189826.aspx (linguagem t-sql) http://www.di.ubi.pt/~pprata/bd/bd0405-proc.sql

Leia mais

Uma Base de Dados é uma colecção de dados partilhados, interrelacionados e usados para múltiplos objectivos.

Uma Base de Dados é uma colecção de dados partilhados, interrelacionados e usados para múltiplos objectivos. 1. Introdução aos Sistemas de Bases de Dados Uma Base de Dados é uma colecção de dados partilhados, interrelacionados e usados para múltiplos objectivos. O conceito de base de dados faz hoje parte do nosso

Leia mais

Fundamentos do Sistema Gerenciador de Banco de Dados

Fundamentos do Sistema Gerenciador de Banco de Dados Fundamentos do Sistema Gerenciador de Banco de Dados Cláudio Luís V. Oliveira Janeiro de 2010 Definição "Um sistema cujo objetivo principal é gerenciar o acesso, a correta manutenção e a integridade dos

Leia mais

PostgreSQL 8.0. Diogo Biazus

PostgreSQL 8.0. Diogo Biazus PostgreSQL 8.0 Diogo Biazus PostgreSQL 7.X Totalmente ACID MVCC Tipos e operadores customizáveis Diversas linguagens procedurais Hot backup Código aberto (BSD) Facilidade de extensão PL/pgSQL, PL/Python,

Leia mais

Tarefa Orientada 20 Cursores

Tarefa Orientada 20 Cursores Tarefa Orientada 20 Cursores Objectivos: Declarar cursores Utilizar cursores Utilizar funções do sistema para trabalhar com cursores Actualizar dados através de cursores Um cursor é um objecto da base

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

SQL Gatilhos (Triggers)

SQL Gatilhos (Triggers) SQL Gatilhos (Triggers) Laboratório de Bases de Dados Gatilho (trigger) Bloco PL/SQL que é disparado de forma automática e implícita sempre que ocorrer um evento associado a uma tabela INSERT UPDATE DELETE

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

Triggers e Regras. Fernando Lobo. Base de Dados, Universidade do Algarve

Triggers e Regras. Fernando Lobo. Base de Dados, Universidade do Algarve Triggers e Regras Fernando Lobo Base de Dados, Universidade do Algarve 1 / 14 Triggers Um trigger permite que uma determinada sequência de comandos SQL seja accionada quando um determinado evento ocorre.

Leia mais

SQL. Hélder Antero Amaral Nunes

SQL. Hélder Antero Amaral Nunes SQL Hélder Antero Amaral Nunes 2 Introdução Desenvolvida pelo departamento 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

trigger insert, delete, update

trigger insert, delete, update 1 Um trigger é um conjunto de instruções SQL armazenadas no catalogo da BD Pertence a um grupo de stored programs do MySQL Executado quando um evento associado com uma tabela acontece: insert, delete,

Leia mais

Princípio dos anos 70 IBM desenvolve a linguagem Sequel para o System R. Standards ISO e ANSI SQL-86, SQL-89, SQL-92, SQL:1999, SQL:2003

Princípio dos anos 70 IBM desenvolve a linguagem Sequel para o System R. Standards ISO e ANSI SQL-86, SQL-89, SQL-92, SQL:1999, SQL:2003 Bases de Dados Introdução à linguagem SQL História Princípio dos anos 70 IBM desenvolve a linguagem Sequel para o System R Renomeada para SQL (Structured Query Language) Standards ISO e ANSI SQL-86, SQL-89,

Leia mais

APOSTILA BANCO DE DADOS INTRODUÇÃO A LINGUAGEM SQL

APOSTILA BANCO DE DADOS INTRODUÇÃO A LINGUAGEM SQL 1. O que é Linguagem SQL 2. Instrução CREATE 3. CONSTRAINT 4. ALTER TABLE 5. RENAME TABLE 6. TRUCANTE TABLE 7. DROP TABLE 8. DROP DATABASE 1 1. O que é Linguagem SQL 2. O SQL (Structured Query Language)

Leia mais

INSTITUTO SUPERIOR TÉCNICO Administração e Optimização de Bases de Dados

INSTITUTO SUPERIOR TÉCNICO Administração e Optimização de Bases de Dados Número: Nome: 1 -------------------------------------------------------------------------------------------------------------- INSTITUTO SUPERIOR TÉCNICO Administração e Optimização de Bases de Dados Exame

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

Bases de Dados. Parte IX: Organização Física dos Dados

Bases de Dados. Parte IX: Organização Física dos Dados Bases de Dados Parte IX Organização Física dos Dados Unidades de Medida da Informação A unidade fundamental é o byte. byte corresponde a 8 bits e cada bit permite representar ou um 0 ou um. Kilobyte (Kbyte

Leia mais

Roteiro 9 - SQL Básico: chave estrangeira, operadores de comparação e operadores booleanos

Roteiro 9 - SQL Básico: chave estrangeira, operadores de comparação e operadores booleanos Roteiro 9 - SQL Básico: chave estrangeira, operadores de comparação e operadores booleanos Objetivos: Criar restrições para atributos, chaves primárias e estrangeiras; Explorar consultas SQL com uso de

Leia mais

SQL (Structured Querie Language) Escola Secundária de Emídio Navarro 2001/2002 Estruturas, Tratamento e Organização de Dados

SQL (Structured Querie Language) Escola Secundária de Emídio Navarro 2001/2002 Estruturas, Tratamento e Organização de Dados SQL (Structured Querie Language) SQL é mais que uma linguagem de interrogação estruturada. Inclui características para a definição da estrutura de dados, para alterar os dados de uma base de dados, e para

Leia mais

PostgreSQL. www.postgresql.org. André Luiz Fortunato da Silva Analista de Sistemas CIRP / USP alf@cirp.usp.br

PostgreSQL. www.postgresql.org. André Luiz Fortunato da Silva Analista de Sistemas CIRP / USP alf@cirp.usp.br PostgreSQL www.postgresql.org André Luiz Fortunato da Silva Analista de Sistemas CIRP / USP alf@cirp.usp.br Características Licença BSD (aberto, permite uso comercial) Multi-plataforma (Unix, GNU/Linux,

Leia mais

Integridade dos Dados

Integridade dos Dados 1 Integridade dos Dados Integridade dos Dados Melissa Lemos melissa@inf.puc-rio.br A integridade dos dados é feita através de restrições, que são condições obrigatórias impostas pelo modelo. Restrições

Leia mais

Histórico de revisões

Histórico de revisões Apostila 3 Histórico de revisões Data Versão Descrição Autor 30/09/2011 1.0 Criação da primeira versão HEngholmJr CONTEÚDO Exclusão de registros Consultas por Dados de Resumo Group by / Having Funções

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

Linguagem SQL. Comandos Básicos

Linguagem SQL. Comandos Básicos Linguagem SQL Comandos Básicos Caetano Traina Júnior Grupo de Bases de Dados e Imagens Instituto de Ciências Matemáticas e de Computação Universidade de São Paulo - São Carlos caetano@icmc.sc.usp.br Comando

Leia mais

BANCO DE DADOS: SQL. Edson Anibal de Macedo Reis Batista. 27 de janeiro de 2010

BANCO DE DADOS: SQL. Edson Anibal de Macedo Reis Batista. 27 de janeiro de 2010 BANCO DE DADOS: SQL UERN - Universidade do Estado do Rio Grande do Norte. Departamento de Ciências da Computação. 27 de janeiro de 2010 índice 1 Introdução 2 3 Introdução SQL - Structured Query Language

Leia mais

SQL. Structured Query Language

SQL. Structured Query Language SQL Structured Query Language Construções básicas Junção de Tabelas Join O uso da operação JOIN numa cláusula FROM especifica como se deseja que as tabelas sejam vinculadas. Use INNER JOIN para associar

Leia mais

Estatística, monitoramento e diagnóstico através do catálogo do PostgreSQL

Estatística, monitoramento e diagnóstico através do catálogo do PostgreSQL Estatística, monitoramento e diagnóstico através do catálogo do PostgreSQL O trabalho Estatística, monitoramento e diagnóstico através do catálogo do PostgreSQL de Fabiano Machado Dias e Eduardo Wolak

Leia mais

SQL - Structured Query Language, ou Linguagem de Consulta Estruturada ou SQL

SQL - Structured Query Language, ou Linguagem de Consulta Estruturada ou SQL SQL - Structured Query Language, ou Linguagem de Consulta Estruturada ou SQL Criar uma base de dados (criar um banco de dados) No mysql: create database locadora; No postgresql: createdb locadora Criar

Leia mais

Bases de Dados. Lab 1: Introdução ao ambiente. Figura 1. Base de dados de exemplo

Bases de Dados. Lab 1: Introdução ao ambiente. Figura 1. Base de dados de exemplo Departamento de Engenharia Informática 2014/2015 Bases de Dados Lab 1: Introdução ao ambiente 1º semestre O ficheiro bank.sql contém um conjunto de instruções SQL para criar a base de dados de exemplo

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

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