Inicialmente desenvolvida pela IBM em 1974 para o seu sistema System R. O seu nome era

Transcrição

1 Nuno Melo e Castro

2 SQL :: Structured Query Language Linguagem declarativa usada para definição e manipulação de dados em bases de dados relacionais Sql não é uma linguagem procedimental Numa linguagem procedimental como por exemplo C ou Pascal, desenvolvemos procedimentos que executam tarefas específicas, uns após os outros Sql é uma linguagem declarativa Usando SQL, o programador especifica aquilo que quer, em vez de especificar como se pode obter aquilo que se quer. O SGBD é responsável por decidir qual é a melhor forma para obter o que foi pedido Inicialmente desenvolvida pela IBM em 1974 para o seu sistema System R. O seu nome era inicialmente SEQUEL. Proposta pela IBM para normalização em 1984, e organizações como a ANSI e a ISSO constituem grupos de trabalho para o efeito. A 1ª versão da norma (agora chamada SQL) surge em 1986 com a designação SQL-86 Surgem revisões à norma SQL em 1992 (SQL-92) e em 2003 (SQL-2003) A norma SQL-2003 já inclui suporte a algumas instruções puramente procedimentais, como por exemplo, blocos de instruções, condições, etc. Irá surgir uma nova revisão SQL3 que incorporará suporte a modelos Object-Oriented Os vários fabricantes de SGBDs relacionais, fornecem actualmente (no mínimo) suporte ao SQL-92, no entanto, todos eles incorporam na sua linguagem base extensões específicas ao SGBD. Por exemplo, a Oracle tem o PL/Sql, a Microsoft tem o T/Sql para o SqlServer, etc.

3 SQL - DDL :: Data Definition Language Permite criar e destruir bases de dados e objectos das bases de dados Comandos fundamentais CREATE DROP ALTER Qualquer comando tem uma sintaxe própria. Para poder ser executado temos de especificar o comando na totalidade Exemplos CREATE DATABASE DROP DATABASE ALTER DATABASE CREATE TABLE DROP TABLE ALTER TABLE

4 Schema, Domain, Constraint Uma base de dados é mais do que uma simples colecção de tabelas. Existem estruturas adicionais que nos permitem garantir a integridade da informação. Schema Estrutura de uma base de dados (vista conceptual) O schema descreve a estrutura da base de dados, e, além de outros objectos, contém informação sobre todas as tabelas. O próprio schema está guardado em tabelas (metadados), tal qual aquelas usadas para guardar informação genérica. Metadados são dados.

5 Domain Define o conjunto de valores que uma coluna pode assumir. É o mais básico tipo de integridade que se pode definir para uma coluna. Não apenas define o domínio, mas também indica ao SGBD algo sobre a semântica dos dados. Duas colunas a e b do tipo VARCHAR: a+b é a concatenação de a com b. Duas colunas a e b do tipo INTEGER: a+b é a soma de a com b.

6 Constraint São regras que definem quais os valores que uma coluna pode assumir. Uma constraint é uma restrição sobre os valores do domain. Podemos concluir que as características de uma coluna (domain) em conjunto com as restrições aplicadas sobre essa mesma coluna (constraint) determinam o domínio da mesma.

7 Datatypes A especificação SQL2003 reconhece os 5 tipos genéricos: Numeric String Boolean Datetime Interval Cada tipo pode ter vários subtipos: Numeric Exact Numeric (Integer, Smallint, Bigint, Numeric, Decimal) Integer, Smallint, Bigint são inteiros, variando a precisão Numeric, Decimal são números reais com uma determinada precisão e escala [numeric(p, s)]. A diferença é que a precisão pode ser excedida no caso do Decimal. Approximate Numeric (Real, Double, Float). Usados quando a exactidão não é imperativa (Floating Point Numbers). São números em vírgula flutuante. Real e Double têm uma precisão dependente do hardware. Em máquinas de 64 bits o Real tem uma precisão superior do que em máquinas 32 bits. O Double tem precisão dupla do Real, e também é dependente do hardware. Float difere dos anteriores porque permite definir a precisão. Um número em vírgula flutuante (a) pode ser representado por dois números (m) e (e), tal que: a = m*b^e, sendo b uma base.

8 SQL - DDL :: Data Definition Language Simbologia usada na especificação da sintaxe dos comandos { } [ ] n Engloba itens que são obrigatórios. Engloba itens que são opcionais. Significa OU. Os itens da lista são opcionais, e só pode ocorrer um dos itens. O grupo pode repetir-se n vezes.

9 CREATE TABLE [ schema_name. ] table_name ( { <column_definition> } [ <table_constraint> ] [,...n ] ) [ ; ] <column_definition> ::= column_name <data_type> [ NULL NOT NULL ] [ DEFAULT constant_expression ] [ <column_constraint> [...n ] ] <column_constraint> ::= [ CONSTRAINT constraint_name ] { { PRIMARY KEY UNIQUE } [ FOREIGN KEY ] REFERENCES [ schema_name. ] referenced_table_name [ ( ref_column ) ] CHECK ( logical_expression ) } < table_constraint > ::= { { PRIMARY KEY UNIQUE } (column [ ASC DESC ] [,...n ] ) FOREIGN KEY (column [,...n ] ) REFERENCES [ schema_name. ] referenced_table_name [ ( ref_column ) ] CHECK ( logical_expression ) }

10 Cada coluna de uma tabela tem um domínio associado. O domínio define-se especificando o datatype e constraints. CREATE TABLE Aluno( id_aluno integer, nome varchar(50)) Neste exemplo, a tabela Aluno tem duas colunas de nome id_aluno e nome. Ambas as colunas admitem valores NULL. O valor NULL faz sempre parte do domínio de qualquer coluna, excepto quando se define uma restrição que o impeça. O domínio da coluna id_aluno é o conjunto dos números inteiros. Como é óbvio, o id_aluno pode tomar valores positivos ou negativos. Se quisermos, por exemplo, que a coluna id_aluno só tenha valores positivos, como o podemos garantir? Definindo uma constraint Essa constraint será de um tipo específico: CHECK

11 Garantindo que o id_aluno será sempre positivo... Tipo de constraint a usar: CHECK Hipótese 1 (usando uma column_constraint) <column_constraint> ::= [ CONSTRAINT constraint_name ] { { PRIMARY KEY UNIQUE } [ FOREIGN KEY ] REFERENCES [ schema_name. ] referenced_table_name [ ( ref_column ) ] CHECK ( logical_expression ) } CREATE TABLE Aluno( id_aluno integer CHECK (id_aluno > 0), nome varchar(50)) Este comando originou a criação de dois objectos na base de dados: Uma tabela com o nome Aluno Uma constraint, da qual não sabemos o nome

12 Hipótese 2 (usando uma column_constraint) <column_constraint> ::= [ CONSTRAINT constraint_name ] { { PRIMARY KEY UNIQUE } [ FOREIGN KEY ] REFERENCES [ schema_name. ] referenced_table_name [ ( ref_column ) ] CHECK ( logical_expression ) } CREATE TABLE Aluno( id_aluno integer CONSTRAINT CK_Aluno_id_aluno CHECK (id_aluno > 0), nome varchar(50)) Este comando originou a criação de dois objectos na base de dados: Uma tabela com o nome Aluno Uma constraint com o nome CK_Aluno_id_aluno

13 Porque se deve dar sempre um nome a uma constraint? Em termos práticos é indiferente definir ou não definir o nome da constraint, mas Uma constraint é um objecto da BD e pode ser criado, eliminado ou modificado independentemente da tabela a que está associada. Se não sabemos o seu nome não poderemos efectuar comandos sobre a constraint Temos de consultar o dicionário de dados para obter o nome quando quisermos manipular a constraint. Convenção para o nome das constraints Não existe uma convenção mais correcta do que outra. O administrador da BD usa a que achar por bem usar, no entanto deve incluir sempre no nome da constraint, como prefixo ou como sufixo, algo que indique o tipo de constraint. Por exemplo: PRIMARY KEY PK_nome_tabela UNIQUE UK_nome_tabela_nome_coluna CHECK CK_nome_tabela_nome_coluna FOREIGN KEY FK_nome_tabela_nome_coluna_nome_tabela_ref

14 Hipótese 3 (usando uma table_constraint) < table_constraint > ::= { { PRIMARY KEY UNIQUE } (column [ ASC DESC ] [,...n ] ) FOREIGN KEY (column [,...n ] ) REFERENCES [ schema_name. ] referenced_table_name [ ( ref_column ) ] CHECK ( logical_expression ) } CREATE TABLE Aluno( id_aluno integer, nome varchar(50), CONSTRAINT CK_Aluno_id_aluno CHECK (id_aluno > 0)) Este comando originou a criação de dois objectos na base de dados: Uma tabela com o nome Aluno Uma constraint com o nome CK_Aluno_id_aluno Podemos verificar que a sintaxe do CHECK é idêntica quer seja escrita como uma column_constraint ou table_constraint. Esta é a única constraint em que isso se verifica.

15 Se quiser garantir que ambas as colunas da tabela não admitem o valor NULL É importante notar que NULL é um valor especial e que Se as constraints não o impedirem explicitamente, NULL será sempre possível! Por exemplo: CREATE TABLE Aluno( id_aluno integer, nome varchar(50), CONSTRAINT CK_Aluno_id_aluno CHECK (id_aluno > 0)) Nesta tabela temos uma constraint que obriga a que os valores de id_aluno sejam sempre superiores a 0 O valor NULL é considerado como sendo maior ou menor do que 0? NULL significa que não tem valor, portanto não é menor nem maior do que 0! NULL será possível para id_aluno, a não ser que implementemos uma restrição, por exemplo: CREATE TABLE Aluno( id_aluno integer NOT NULL, nome varchar(50), CONSTRAINT CK_Aluno_id_aluno CHECK (id_aluno > 0))

16 Se quiser garantir que os valores de id_aluno serão sempre diferentes Temos de criar uma constraint que garanta a unicidade Por exemplo: CREATE TABLE Aluno( id_aluno integer UNIQUE NOT NULL, nome varchar(50), CONSTRAINT CK_Aluno_id_aluno CHECK (id_aluno > 0)) Definição da chave primária A chave primária é uma constraint Ao definir uma chave primária estamos implicitamente a: A definir um UNIQUE INDEX A garantir a unicidade da chave A garantir que as colunas que fazem parte da chave não admitem NULL

17 Exemplos: CREATE TABLE Aluno( id_aluno integer PRIMARY KEY, nome varchar(50), CONSTRAINT CK_Aluno_id_aluno CHECK (id_aluno > 0)) CREATE TABLE Aluno( id_aluno integer CONSTRAINT PK_Aluno PRIMARY KEY, nome varchar(50), CONSTRAINT CK_Aluno_id_aluno CHECK (id_aluno > 0)) CREATE TABLE Aluno( id_aluno integer NOT NULL, nome varchar(50), CONSTRAINT CK_Aluno_id_aluno CHECK (id_aluno > 0), CONSTRAINT PK_Aluno PRIMARY KEY(id_aluno)) Repare-se que a sintaxe é diferente quando a PRIMARY KEY é especificada numa column_constraint ou numa table_constraint Quando usamos uma column_constraint, estamos a definir uma constraint especificamente para essa coluna Quando usamos uma table_constraint, estamos a definir uma constraint a nível da tabela, logo temos de especificar qual é a coluna (ou lista de colunas)

18 Quando as constraints se referem a mais do que uma coluna, por exemplo, se a chave primária for composta Consideremos a seguinte tabela: Nota (id_aluno, id_disciplina, nota) onde a chave primária são os 2 campos id_aluno e id_disciplina CREATE TABLE Nota( id_aluno integer, id_disciplina integer, nota numeric(3, 1)) O seguinte exemplo é ERRADO! CREATE TABLE Nota( id_aluno integer PRIMARY KEY, id_disciplina integer PRIMARY KEY, nota numeric(3, 1)) É errado porque cada tabela só pode ter UMA chave primária! Com este exemplo estaríamos a tentar criar DUAS chaves primárias, porque estávamos a definir duas constraints! Quando uma constraint refere mais do que uma coluna, não é possível defini-la através de uma column_constraint, mas obrigatoriamente através de uma table_constraint!

19 A chave primária devia então ser definida da forma seguinte. Foi ainda acrescentada uma constraint para garantir que a nota é um valor entre 0 e 20. CREATE TABLE Nota( id_aluno integer, id_disciplina integer, nota numeric(3, 1) NOT NULL, CONSTRAINT PK_Nota PRIMARY KEY (id_aluno, id_disciplina), CONSTRAINT CK_Nota_nota CHECK (nota between 0 and 20)) Não há a necessidade de especificar que id_aluno não admite NULL Não há a necessidade de especificar que id_disciplina não admite NULL Porque a PRIMARY KEY garante-o implicitamente No nosso modelo de dados, até agora temos 2 tabelas Aluno e Nota A tabela nota pretende representar as notas que os alunos tiveram às disciplinas Faz sentido ter outra tabela (Disciplina) E também faz sentido relacionar as 3 tabelas, ou seja, temos de definir as chaves estrangeiras

20 O nosso modelo de dados: Aluno (id_aluno, nome) Disciplina (id_disciplina, nome) Nota (id_aluno, id_disciplina, nota) As relações entre as tabelas: Aluno.id_aluno é relacionado com Nota.id_aluno Disciplina.id_disciplina é relacionado com Nota.id_disciplina Uma relação entre duas tabelas define-se através de uma chave estrangeira Uma chave estrangeira existe, quando uma coluna (ou conjunto de colunas) numa tabela se relaciona(m) com outra coluna (ou conjunto de colunas) noutra tabela, mas nessa outra tabela a(s) coluna(s) é(são) chave primária. Neste caso específico, existem 2 chaves estrangeiras Nota.id_aluno é chave estrangeira de Aluno.id_aluno Nota.id_disciplina é chave estrangeira de Disciplina.id_disciplina

21 Criação das chaves estrangeiras Hipótese 1 CREATE TABLE Nota( id_aluno integer CONSTRAINT FK_Nota_id_aluno_Aluno REFERENCES Aluno(id_aluno), id_disciplina integer CONSTRAINT FK_Nota_id_disciplina_Disciplina REFERENCES Disciplina(id_disciplina), nota numeric(3, 1) NOT NULL, CONSTRAINT PK_Nota PRIMARY KEY (id_aluno, id_disciplina), CONSTRAINT CK_Nota_nota CHECK (nota between 0 and 20)) Hipótese 2 CREATE TABLE Nota( id_aluno integer, id_disciplina integer, nota numeric(3, 1) NOT NULL, CONSTRAINT PK_Nota PRIMARY KEY (id_aluno, id_disciplina), CONSTRAINT CK_Nota_nota CHECK (nota between 0 and 20), CONSTRAINT FK_Nota_id_aluno_Aluno FOREIGN KEY (id_aluno) REFERENCES Aluno(id_aluno), CONSTRAINT FK_Nota_id_disciplina_Disciplina FOREIGN KEY (id_disciplina) REFERENCES Disciplina(id_disciplina))

22 É possível alterar tabelas Acrescentar novas colunas, alterar o tipo de dados, eliminar colunas Acrescentar ou retirar constraints Acrescentar uma coluna ALTER TABLE Aluno ADD ( varchar(100)) Eliminar uma coluna ALTER TABLE Aluno DROP Alterar o tipo de dados de uma coluna ALTER TABLE Aluno MODIFY ( varchar(75)) Eliminar uma constraint ALTER TABLE Aluno DROP CONSTRAINT FK_Nota_id_aluno_Aluno Acrescentar uma constraint ALTER TABLE Aluno ADD CONSTRAINT FK_Nota_id_aluno_Aluno FOREIGN KEY (id_aluno) REFERENCES Aluno(id_aluno) Considerações: A sintaxe dos comandos pode variar de SGBD para SGBD Nem todos os SGBD permitem todas as versões do comando ALTER TABLE Quando se adiciona uma constraint, terá sempre de ser no formato de uma table_constraint A alteração de tipo de dados de uma coluna não pode violar regras de integridade

23 A instrução que permite obter dados contidos em tabelas é SELECT SINTAXE SELECT [ ALL DISTINCT ] <select_list> FROM <table_list> [WHERE <where_expression>] [GROUP BY <groupby_list>] [HAVING <having_expression>] [ORDER BY <orderby_list> [DESC ASC]] <select_list> ::= { * { table_name view_name table_alias }.* { column_name expression }, [, n]} <table_list> ::= { table_name view_name table_alias } [, n]} <where_expression> ::= Qualquer expressão booleana envolvendo expressões, colunas ou constantes <groupby_list> ::= { table_name view_name table_alias }.* { column_name expression }, [, n] <having_expression> ::= Qualquer expressão booleana envolvendo expressões, colunas ou constantes, mas que estejam envolvidas na <groupby_list> < orderby_list> ::= { table_name view_name table_alias }.* { column_name <index> }, [, n] <index> ::= Pode tomar valores de 1 até ao nº de colunas na select_list

24 O SELECT corresponde a uma expressão de álgebra relacional, envolvendo selecções, projecções e produtos cartesianos Faz o produto cartesiano de todas as tabelas que estão no FROM A expressão da cláusula WHERE tem de ser verdadeira para uma determinada linha (obtida do produto cartesiano) ser devolvida no resultado A cláusula GROUP BY define o número máximo de linhas do resultado final. Esse número é igual ao número de todos os valores distintos para as colunas da groupby_list As colunas da select_list que não estão contidas na groupby_list, têm obrigatoriamente de estar associadas a funções de agregação A expressão da cláusula HAVING tem de ser verdadeira para uma determinada linha (obtida após GROUP BY) ser devolvida no resultado Qualquer resultado de um SELECT pode ser ordenado.