Banco de Dados

SQL - DDL
 SQL

• SQL (“Structured Query Language") é uma

linguagem comercial de criação e manipulação de
bancos de dados relacionais
• SQL é padrão de fato (mesmo SGBDs que
possuem linguagem própria oferecem uma
interface SQL)
• Tem como base a álgebra relacional e cálculo
relacional.

2
 SQL Versões

• SQL é padrão de direito (ISO):

– SQL1 aprovado em 1986, com modificações
em 1989
– SQL2 aprovado em 1992
– SQL3 aprovado em 1999
– SQL ANSI 2003 aprovado em 2003
– SQL 2006 aprovado em 2006 (XML)

3
 SQL Componentes

• SQL é uma linguagem completa de manipulação

de BD
• Oferece as seguintes funcionalidades:
– Uma DDL para definição do esquema da base
de dados.
– Uma DML para programação de consultas e
transações que inserem, removem e alteram
linhas de tabelas.

4
 SQL Componentes
• Existem outras linguagens dentro de SQL:
– DCL - Data Control Language (Linguagem de Controle
de Dados): Controla os aspectos de autorização de
dados e a utilização de licenças por usuários. Os
principais comandos são GRANT e REVOKE.
– DTL - Data Transaction Language (Linguagem de
Transação de Dados): Utilizado pelos desenvolvedores
em transações. Os principais comandos são COMMIT e
ROLLBACK.
– DQL - Data Query Language (Linguagem de Consulta de
Dados): O mais importante dentre estes, pois consultas
são realizadas a todo instante. O comando que é
utilizado pelo DQL é o SELECT. O SELECT também é
considerado DML por algumas literaturas.

5
 SQL Componentes

• Conexão com sistemas:

– Uma versão de SQL embutida em linguagens
de 3ª geração (COBOL, C, ...), estendendo-as
para manipulação de banco de dados
– Um padrão de comunicação
cliente/servidor (ODBC (Open Database
Connectivity)), a partir de SQL3
– Instruções para definições de visões (tabelas
virtuais vistas por um usuário ou uma classe
de usuários)

6
 SQL Componentes

• Funcionalidades:
– Instruções para controle de autorização de
acesso
– Instruções para controle de transações e
concorrência
– Instruções para especificação de restrições de
integridade

7
 Aderência ao Padrão

• A aderência a padrões de SQL é importante para

aqueles que:
– escrevem comandos de SQL em suas
aplicações (SQL não fica oculto por algum
gerador de telas, ...)
– desejam portar aplicações a vários SGBD
• O padrão é irrelevante para aqueles que usam
ferramentas como geradores de telas, relatórios,
etc.
• Praticamente todo fornecedor de SGBD
afirma que o seu produto é compatível com
o padrão.

8
 DDL – Criação de BD

• Normalmente trabalha-se com as seguintes

instruções de DDL:
– Create Database: cria uma base de dados
vazia
– Drop Database: elimina uma base de dados
• Alguns SGBD’s têm abordagens variadas

9
 DDL

• A SQL DDL permite não só a especificação de um

conjunto de relações, como também informações
acerca de cada uma das relações, incluindo:
– O esquema de cada relação
– O domínio dos valores associados a cada
atributo
– As regras de integridade
– O conjunto de índices para manutenção de
cada relação
– Informações sobre segurança e autoridade
sobre cada relação
– A estrutura de armazenamento físico de cada
relação no disco 10
 DDL – Tipos de Domínios

• AQL aceita uma variedade de tipos de domínios,

incluindo os seguintes:
– char(n) é uma cadeia de caracteres de
tamanho fixo, com o tamanho n definido pelo
DBA. A forma completa, character, também
pode ser usada.
– varchar(n) é uma cadeia de caracteres de
tamanho variável, com o tamanho n máximo
definido pelo DBA. A forma completa,
character varying, é equivalente.

11
 DDL – Tipos de Domínios

– int é um inteiro, a forma completa, integer,

também pode ser usada.
– smallint é um inteiro pequeno (um
subconjunto do domínio dos inteiros
dependente do ambiente e equipamento)
– numeric(p, d) é um numero de ponto fixo
cuja precisão é definida pelo usuário. O
número consiste de p dígitos (mais o sinal),
sendo que d dos p dígitos estão à direita do
ponto decimal.

12
 DDL – Tipos de Domínios

– real, double precision são números de ponto

flutuante e ponto flutuante de precisão.
– date é um calendário contendo um ano (com 4
dígitos) mês e dia do mês.
– time representa horário, em horas, minutos e
segundos.

13
 DDL – Tipos de Domínios

• Obs.:
– Strings de caracteres de tamanho variável
(varchar), data e horário não faziam parte do
SQL-89;
– Normalmente utiliza-se a comparação entre
valores compatíveis;
– O valor nulo é um membro de todos os
domínios;
– A SQL permite que a declaração de domínio de
um atributo inclua a especificação de not null,
proibindo, assim, a inserção de um valor nulo
para esse tipo de atributo.

14
 DDL – Tipos de Domínios

• Domínios são tipos de dados personalizados

definidos a partir de um tipo de dado existente.
• Definir um domínio significa criar uma abstração
de dados, uma vez que as colunas definidas
sobre um domínio refletem quaisquer alterações
realizadas sobre ele, sem que precisem ser
redefinidas.

15
 DDL – Tipos de Domínios

• Podemos caracterizar:
– Domínios simples: aqueles simplesmente
baseados em um tipo de dado qualquer.
– Domínios complexos: podem especificar
valores padrões e estabelecer regras e
restrições acerca dos valores que as colunas
podem receber.

16
 DDL – Tipos de Domínios

• SQL permite-nos definir domínios usando a

clausula create domain, como mostra o
seguinte exemplo:
– Create domain nome_pessoa varchar(40)

• Podemos, então, usar o domínio de nome em

nome_pessoa para definir o tipo de um atributo
com um domínio exato embutido.

17
 DDL – Instruções

• SQL oferece três instruções para definição do

esquema da base de dados:
• Create Table
– define a estrutura de uma tabela, suas
restrições de integridade e cria a tabela vazia
• Drop Table
– elimina a tabela da base de dados
– não remove tabelas referenciadas por outras
tabelas

18
 DDL – Instruções

• Alter Table
– permite modificar a definição de uma tabela
• Inserir, Alterar e Excluir  Atributos e RI´s
– RIs básicas:
• atributos chave não podem ser removidos
• atributos NOT NULL não podem ser inseridos

19
 Sintaxe do Create Table

Create table nome_tabela (

nome_atributo_1 tipo_1
[[NOT]NULL][UNIQUE]
[{, nome_atributo_n tipo_n}]
[, primary key (nome(s)_atributo(s))]
[{, foreign key (nome_atributo)
references nome_tabela}]
)

20
 Criação da Tabela Peças

CREATE TABLE PECA (

CodPeca CHAR(4) NOT NULL,
NomePeca VARCHAR(50) NOT NULL,
CorPeca CHAR(10),
PesoPeca INTEGER,
CidadePeca VARCHAR(40),
PRIMARY KEY (CodPeca));

21
 Criação da Tabela Fornec

CREATE TABLE FORNEC (

CodFornec CHAR(4) NOT NULL,
NomeFornec VARCHAR(50) NOT NULL,
StatusFornec INTEGER,
CidadeFornec VARCHAR(40),
CGC CHAR(14) NOT NULL,
PRIMARY KEY (CodFornec),
UNIQUE KEY (CGC))

22
 Criação da Tabela Embarque

CREATE TABLE EMBARQUE (

CodPeca CHAR(4) NOT NULL,
CodFornec CHAR (4) NOT NULL,
QtdeEmbarq INTEGER NOT NULL,
PRIMARY KEY (CodPeca,CodFornec),
FOREIGN KEY (CodPeca) REFERENCES
Peca (CodPeca),
FOREIGN KEY (CodFornec)
REFERENCES Fornec(CodFornec);

23
 Criação das Tabelas

• Em SQL/2 o conjunto de domínios de valores é

fixo
• Desejável (SQL/3)
– domínio definível pelo usuário
• Nos SGBD comerciais são oferecidos
domínios adicionais aos do padrão (CHAR,
VARCHAR, INTEGER, REAL, ...) destinados a
aplicações especiais como DATA, CURRENCY e
domínios para armazenar campos longos (BLOBS,
até 2GB) destinados a conter imagens, sons,
vídeos, etc. (maioria aparece no SQL/2)

24
 Criação das Tabelas

• A cláusula NOT NULL especifica que uma coluna

não admite o valor vazio (requerido para colunas
que sejam chave primária)
• Default é NULL permitido (exceto Sybase e
SQL/Server antigos)

25
 Restrições de Chaves

• No SQL original (System R) e no SQL padrão

original (1986) não havia cláusulas para
especificar chaves
• A única maneira de definir chave primária era
através da criação de um índice sem duplicatas
sobre a coluna
• Não havia forma declarativa de definir chaves
estrangeiras
• SGBD não dava suporte a integridade referencial
• Agora é possível definir no momento da criação
da tabela

26
 Restrições de chave estrangeira

• Padrão (1986/1989) foi estendido para

especificar chaves:
– primária
– estrangeira
– alternativa (unique key)
• Praticamente todos os produtos comerciais
incluem a definição de chaves.

27
 Chave estrangeira cláusula ON DELETE

• Cascade
– Pode ser definida a propagação da exclusão da
linha para as linhas que a referenciam
– Sintaxe:
• ... FOREIGN KEY ... REFERENCES ...
ON DELETE {CASCADE}

28
 Chave estrangeira cláusula ON DELETE

• SET NULL
– Especifica que as chaves estrangeiras que
referenciam a linha excluídas devem ser
tornadas vazias
– Válido somente para chaves estrangeiras
opcionais
– Sintaxe:
• ... FOREIGN KEY ... REFERENCES ...
ON DELETE {SET NULL}

29
 Chave estrangeira cláusula ON DELETE

• RESTRICT (default)
– Especifica que uma linha não pode ser excluída
caso existam chaves estrangeiras que a
referenciem.
– Caso nada seja especificado na definição de
chave estrangeira, uma linha que contenha
uma chave primária referenciada na chave
estrangeira não pode ser excluída (regra
RESTRICT)
– Sintaxe:
• ... FOREIGN KEY ... REFERENCES ...
ON DELETE {RESTRICT}
30
 Chave estrangeira cláusula ON UPDATE

• CASCADE
– Alteração da chave primária é propagada para
as chaves estrangeiras que a referenciam
– Sintaxe:
• FOREIGN KEY ... REFERENCES ...
ON UPDATE {CASCADE}

31
 Chave estrangeira cláusula ON UPDATE

• SET NULL
– Chaves estrangeiras que referenciam a linha
alterada devem ser tornadas vazias
– Válido somente para chaves estrangeiras
opcionais
• FOREIGN KEY ... REFERENCES ...
ON UPDATE {SET NULL}

32
 Chave estrangeira cláusula ON UPDATE

• RESTRICT
– Uma chave primária não pode ser alterada,
caso existam chaves estrangeiras que a
referenciem
• FOREIGN KEY ... REFERENCES ...
ON UPDATE {RESTRICT}

33
 Eliminação de Tabelas

• Para eliminar completamente uma tabela (vazia

ou não) do BD é usada a instrução:
– DROP TABLE Embarq

• SQL inclui cláusulas RESTRICT e CASCADE

(obrigatória) que informam se a exclusão deve
ser propagada ou não para objetos definidos com
base na tabela (visões)

34
 Eliminação de Tabelas

• Exemplo:
– DROP TABLE Embarq RESTRICT

• Exclui a tabela somente se não existirem visões

definidas com base na tabela

35
 Alteração Definição da Tabela

• A instrução ALTER TABLE serve para modificar a

definição original da tabela
• Nem todas as modificações são permitidas
• Primeiros SGBD e SQL/1 somente permitiam
adicionar colunas

36
 Alteração Definição da Tabela

• Para modificar a estrutura de tabelas já

existentes no BD, há uma instrução que permite
adicionar colunas a tabelas:
– ALTER TABLE Embarq ADD DataEmbarq
date;

37
 Alteração Definição da Tabela

• Observe-se que:
– A instrução adiciona uma nova coluna com o
valor vazio para todas as linhas
– Os valores para as diversas linhas devem ser
adicionadas através de instruções da DML
– Não pode ser especificada a cláusula NOT
NULL, já que a coluna é criada com o valor
vazio (a menos que seja especificado um valor
DEFAULT)

38
 Alteração Definição da Tabela

• Se o SGBD não permite a alteração desejada:

– 1. Armazenar o conteúdo da tabela em uma
tabela temporária ou arquivo do sistema
operacional
– 2. Eliminar todas as referências na tabela
antiga
– 3. Eliminar a tabela antiga (DROP TABLE)
– 4. Definir a nova tabela (CREATE TABLE)
– 5. Carregar a nova tabela a partir da tabela
intermediária ou arquivo do sistema
operacional criado no passo 1
– 6. Reincluir as referências na tabela

39
 Alter Table Mudando Chaves

• ALTER TABLE permite incluir ou excluir restrições

de chave
– ALTER TABLE Representantes DROP PRIMARY
KEY
• Para excluir uma chave estrangeira é necessário
que ela tenha recebido um nome quando de sua
definição

40
 Alter Table Mudando Chaves

• Exemplos:
– ALTER TABLE Representantes
ADD FOREIGN KEY
(CodFilial) REFERENCES Filial

– ALTER TABLE Representantes

DROP FOREIGN KEY
(CodFilial) REFERENCES Filial

41
Alter Table Definição de Chaves

• ALTER TABLE com definição de chaves permite

separar a DDL em duas seções
• A primeira seção contém apenas os CREATE
TABLE com a estrutura do BD
• A segunda seção contém as restrições de chave
através de instruções ALTER TABLE

42
 CONSTRAINTS

• CONSTRAINT é a tendência em SQL de tratar de

maneira uniforme todas as restrições de
integridade (chave primária, chave única, chave
estrangeira, ...)

43
 CONSTRAINTS

CREATE TABLE Embarq (

CodFornec CHAR(4) NOT NULL,
CodPeca CHAR(4) NOT NULL,
Quant INTEGER NOT NULL,
CONSTRAINT PK_EMBARQ
PRIMARY KEY
(CodFornec, CodPeca));

44
 CONSTRAINTS

ALTER TABLE Embarq (

ADD CONSTRAINT
FK_EMBARQ_RELATION_PECAS
FOREIGN KEY (CodPeca)
REFERENCES Pecas (CodPeca));

45
 CONSTRAINTS

ALTER TABLE Embarq (

ADD CONSTRAINT
FK_EMBARQ_RELATION_FORNEC
FOREIGN KEY (CodFornec)
REFERENCES Fornec (CodFornec));

46
 Dicas

• Podem ser usados os caracteres A ... Z, a ... z, 0

... 9, cifrão ($) e sublinhado (_);
• Os nomes devem começar com um caractere
alfabético;
• Os nomes em geral limitam-se a 31 caracteres.
Nomes de restrições limitam-se a 27 caracteres.
Nomes de eventos devem ter no máximo 15
caracteres.

47
 Dicas
• Ordem coerente na criação dos objetos:
1. Domínios;
2. Tabelas;
3. Índices;
4. Restrições FOREIGN KEY (chave estrangeira);
5. Visões;
6. Restrições CHECK (valores permitidos);
7. Exceções;
8. Procedimentos armazenados;
9. Geradores;
10.Gatilhos;
11.Papeis;
12.Atribuições de privilégios.

48
 Dicas
1. Informação é representada logicamente em tabelas.
2. Dados devem ser logicamente acessíveis por tabelas, chaves primárias e colunas.
3. Valores NULLs devem ser tratados uniformemente como “informação perdida”, não
como strings vazias, espaços ou zeros.
4. Metadados (dados sobre o banco de dados) devem ser armazenados no banco de
dados assim como são os dados regulares.
5. Uma única linguagem deve ser capaz de definir dados, exibições ou visualizações
(em inglês: view), restrições de integridade, autorização, transações e manipulação
de dados.
6. Exibições ou visualizações (em inglês: view) devem mostrar as atualizações de suas
tabelas de base e vice versa.
7. Uma única operação deve ser disponível para fazer cada uma das
operaçõesseguintes: recuperar, inserir, atualizar ou remover dados.
8. Lotes (em inglês: Batch) e operações do usuário final são logicamente separados do
armazenamento físico e métodos de acesso.
9. Lotes (em inglês: Batch) e operações do usuário final podem mudar o esquema do
banco de dados sem ter que recriá-lo ou as aplicações construídas por meio dele.
10. Restrições de integridade devem ser disponíveis e armazenados em metadados, não
em um programa de aplicação.
11. A linguagem de manipulação de dados do sistema relacional não deveria se importar
onde ou como dados físicos são distribuídos e não deveria requerer alteração se
dados físicos são centralizados ou distribuídos.
12. Qualquer processamento de linha feito no sistema deve obedecer às mesmas regras
de integridade e restrições que os grupos de operações de processamento obedecem. 49
 Atividades
1. Analise a conta de energia elétrica abaixo (parte 1):

50
 Atividades
1. Analise a conta de energia elétrica abaixo (parte 2):

51
 Atividades
1. Vamos construir um banco de dados no MySQL Workbench para
armazenar os dados da conta de Energia Elétrica.

a. Vamos modelar (na mão) o Modelo Relacional com pelo menos

2 tabelas.

b. Crie a base de dados “companhiaeletrica”.

c. Construa as tabelas modeladas (na mão) utilizando SQL

52