Módulo 4 - Banco de Dados

Tabela de Conteúdo
1. Introdução ao DB2 UDB: Conhecendo a família de produtos do DB2 UDB
2. Família DB2 UDB
3. Um pouco mais sobre outros produtos.
4. O ambiente DB2 OS/390 e z/OS
5. DB2 UDB no ambiente OS/390 e z/OS
6. Arquitetura DB2 UDB
7. Arquitetura DB2 UDB – Objetos DB2 - 1 de 2
8. Arquitetura DB2 UDB – Objetos DB2 - 2 de 2
9. Arquitetura DB2 UDB – Objetos para Recuperação
10. Segurança: todos pensam nisso
11. Controle de Acesso e o SQL
12. “Conversando” com o DB2: somos os objetos DB2!
13. Modelagem de Dados
14. Diagrama de Relacionamento
15. Normalização
16. 2ª. Forma Normal
17. 3ª. Forma Normal
18. “Conversando” com o DB2 : Fiquem à vontade, utilize-me, sou o SQL!
19. DDL (Data Definition Language) - 1 de 2
20. DDL (Data Definition Language) - 2 de 2
21. DML (Data Manipulation Language)
22. Comando SELECT
23. Comando INSERT
24. Comando INSERT - Tratamento de NULOS:
25. DELETE
26. UPDATE
27. SUBQUERIES
28. Leitura Módulo 4 – finalizada
Introdução ao DB2 UDB:

Conhecendo a família de produtos do DB2 UDB

Inicialmente, você irá conhecer um pouco sobre o DB2 Universal Database (DB2
UDB – vamos sempre utilizar este termo!) e toda sua família de produtos, nas
plataformas S/390, zSeries, Unix e Intel.

Essa ilustração oferece uma clara noção da coexistência de toda a família DB2 UDB nas
diferentes plataformas.

A seguir, veremos um pouco sobre cada participante da família DB2 UDB

Família DB2 UDB

DB2 Every Place

Também chamado de DB2 E ou DB2 EE, traz todo o poder de um gerenciador de banco
de dados relacional para a computação móvel “fingerprint” com tamanho de até 180kb.
Pode ser executado em dispositivos que usam tecnologia PALM®, Microsoft Windows
CE/Pocket PC, qualquer sistema operacional Microsoft Windows 32-bit, Symbian,
QNX Neutrino, Java 2 Platform Micro Edition (J2ME), e Linux (BlueCat Linux).

Você poderá considerar o uso desta plataforma, em situações ocasionais de conexão

com laptops, somente se as aplicações não utilizarem “TRIGGERS”, que não são
implementadas nesta arquitetura.

DB2 Personal Edition

DB2 PE foi desenvolvido para permitir todas as funções do gerenciador DB2 UDB,
para um único usuário. Traz a vantagem de executar em plataformas de baixo custo, tais
como Windows 98, Windows ME, Windows NT (SP6 ou maior), Windows 2000 (SP2
recomendado), Windows XP, e Linux. Windows 2003 será suportado após liberação da
Microsoft.
DB2 PE tem todas as funções do DB2 Workgroup Server Edition, com uma exceção:
Clientes Remotos não podem ser conectar aos Databases executados sob o DB2 PE.
Podemos ter estações de trabalho apenas executando o “Centro de Controle” (veremos
sobre este produto em breve) com funções de administração do Database.

DB2 Workgroup Server Edition

DB2 WSE é um completo Sistema de Gerenciador de Banco de Dados Relacional
(SGBDR vamos utilizar sempre este termo!) provendo recursos de ambiente
Cliente/Servidor. Disponível nas plataformas UNIX (AIX, Solaris, e HP-UX), Linux,
Windows NT (SP6 ou maior), Windows 2000 (SP2 recomendado), e Windows XP.

DB2 WSE tem todas as funções do DB2 Enterprise Server Edition, porém não está
integrado com o Mainframe através de conectividade via DB2 Connect, e também não
suporta ambiente 64-bit.

Temos um outro similar, o DB2 Workgroup Server Unlimited Edition (DB2 WSUE),
que difere do DB2 WSE apenas no aspecto de “Licença de Uso”.

DB2 Enterprise Server Edition

DB2 ESE, estamos falando do SGBDR, que contempla todas as funções do DB2 WSE,
com a vantagem de possuir o componente DB2 Connect no qual habilita a conexão com
os Databases pertencentes aos ambientes iSeries e zSeries, bem como utilização de
recursos do Host, tais como CICS, VSAM e IMS.

Um pouco mais sobre outros produtos.

DB2 Clients:
DB2 Run Time : Tem apenas a função de conectar estações de trabalhos aos servidores;
DB2 Administration Client : Tem a função de acessar e administrar os Databases através
das estações de trabalhos, utilizando o “Centro de Controle” ou “Assistente de
Configuração”. Caso a estação possua o DB2 Connect, pode-se ainda gerenciar os
sistemas z/OS e IMS;
DB2 Application Development Client : Prove ferramentas e ambiente necessários ao
desenvolvimento de aplicativos, que acessam servidores DB2, podendo construir e
executar tais aplicativos.
DB2 Extenders:
XML : Provê novos de tipos de dados que podem ser armazenados em documentos
XML, em Databases DB2;
Net Searcher : Para auxiliar na construção de aplicativos Internet, que necessitam alta
performance em grandes índices e escalabilidade de pesquisas concorrentes;
Spatial : Permite armazenar, gerenciar e analisar dados espaciais, do tipo localização
geográfica;
TAIV (Text, Audio, Image, Video) : Próprio para administrar em seu DB2 formatos não
tradicionais do tipo Músicas, Filmes, Fotografias.
DB2 Connect:
Em grandes organizações os dados estão armazenados em databases DB2 em diversos
ambientes, tais como, AS/400, MVS, OS/390, z/OS, VSE e VM. Podemos administrar
os diversos ambientes em uma única estação de trabalho, utilizando o DB2 Connect,
que possui um grande conjunto de ferramentas que permitem tais conectividades.

Muito temos que falar sobre os produtos relacionados com o DB2 UDB. O importante
no momento é ter uma real noção das inúmeras possibilidades de implementação e de
escalabilidade oferecidas por este SGBDR. Com certeza teremos outras oportunidades
para conhecer maiores detalhes sobre os produtos aqui mencionados, bem como sermos
apresentados a outros produtos.

O ambiente DB2 OS/390 e z/OS

A seguir, você irá se familiarizar com alguns objetos relacionados com o Sistema
Operacional, e conhecer como o DB2 está organizado dentro deste sistema operacional.
Viajaremos também pelos componentes do SGBDR DB2 UDB.

OS/390 e z/OS
A família IBM de servidores “enterprises” utiliza OS/390 e z/OS, que são os softwares
de sistema operacional, que oferecem escalabilidade, segurança no processamento para
diferentes cargas de trabalho, em um ambiente de alta performance.

Neste ambiente de sistema operacional temos a convivência de múltiplos tipos de

aplicações, sendo as principais BATCH e OLTP (Online Transaction Processing),
destacando como principais características: Gerenciamento, Escalabilidade,
Flexibilidade, Disponibilidade e Segurança.

DB2 UDB no ambiente OS/390 e z/OS

O DB2 UDB, visto pelo sistema operacional, é um sub-sistema que gerencia os banco
de dados. Os processos do DB2 UDB são executados em diversos “ADDRESS
SPACES”: podemos definir esses “ADDRESS SPACES” como serviços ou gerentes,
existindo um “ADDRESS SPACE” para cada serviço. Nesta ilustração, temos os nomes
de cada “ADDRESS SPACE”:
DSN1MSTR – Responsável pelos serviços de Sistema DB2 UDB, executando as
seguintes tarefas:

- Processadores de comandos
- Suporte ao sub-sistema (não esqueçam o DB2 é um sub-sistema para o S/390 e z/OS)
- Gerenciador de Serviços
- Gerenciador de Armazenamento
- Gerenciador de Recuperação
- Gerador de Mensagens
- Gerenciador de transações distribuídas

DSN1DBM1 – Responsável pelo gerenciamento das principais funções do Database;

destacamos suas principais funções:
- Controlador de Serviços
- Gerenciador de Dados
- Gerenciador de Espaço de Dados (arquivos físicos)
- Gerenciador de “STORED PROCEDURE”
- Gerenciador de “BUFFER”
- Utilitários
IRLMPROC – Responsável pelo controle da integridade de dados.

DSN1SPAS – Provê um ambiente isolado no qual serão executados as “STORED

PROCEDURE”.

DSN1DIST – Responsável pelo controle de acesso a dados entre dois sub-sistemas

DB2.

Existem outros “ADDRESS SPACES” que comunicam-se com o DB2 que não iremos
detalhar nesta publicação: CICS, TSO, IMS e outros

Arquitetura DB2 UDB

Catálogo DB2
O Catálogo DB2 consiste de tabelas e dados sobre todos os objetos definidos em um
DB2 Subsystem, incluindo tablespaces, índices, tabelas, storage groups, e tudo o mais.
O Catálogo DB2 reside no database DSNDB06. Quando se cria, altera ou deleta
qualquer estrutura DB2, inserts, updates, ou deletes são executados nas linhas/colunas
da estrutura do catálogo.
Existe todo um relacionamento entre as tabelas do Catálogo DB2, que é implementado a
partir de uma estrutura de links, similar à integridade referencial.

No manual IBM DB2 UDB for OS/390 SQL Reference Manual há uma lista detalhando
todas as tabelas e colunas pertencentes ao Catálogo DB2.

Diretório DB2
O Diretório DB2 contém informações usadas pelo DB2 durante a operação normal.
Você não pode acessar o Diretório DB2 usando SQL. Embora tenha o mesmo tipo de
informações que o Catálogo DB2, as estruturas do Diretório DB2 não estão descritas no
Catálogo DB2.

O Diretório consiste em um conjunto de Tabelas DB2, armazenadas em 5 tablespaces no

database DSNDB01:
SCT02
SPT01
SYSLGRNX
SYSUTILX
DBD01

Arquitetura DB2 UDB – Objetos DB2 - 1 de 2

Database
No DB2, um database é onde todas as estruturas DB2 serão associadas. Um Database
poderá conter todos os dados associados com uma aplicação ou com um grupo de
aplicações.

Com isto temos a condição de start ou stop para todos os dados contidos no Database,
ou permitir acesso aos mesmos.

DB2 Storage group

Um DB2 storage group é um conjunto de volumes em um direct access storage devices
(DASD).

Os data sets residem nos volumes, nos quais as tabelas e índices estão armazenados. Um
storage group é composto de um volume e de um catálogo VSAM (Armazenamento
utilizado no ambiente OS/390 e z/OS). O Storage group SYSDEFLT, é o storage group
default, e é criado quando você instala o DB2.

Todos volumes de um storage group tem que ser do mesmo device type.

Arquitetura DB2 UDB – Objetos DB2 - 2 de 2

TableSpace
Um tablespace é composto por um ou mais data sets, nos quais uma ou mais tabelas são
armazenadas. Um tablespace pode ser um ou mais arquivos VSAM. Estes arquivos
VSAM são do tipo linear data sets (LDSs). Esses tablespaces são formatados em
páginas geralmente de 4kb de tamanho. Este é um componente físico das estruturas do
DB2.

Tabela
Todos os dados de um database DB2 são apresentados em forma de Tabelas. Quando se
cria uma Tabela, define-se a ordem das colunas.

IndexSpace
Um Indexspace é o mesmo que um Tablespace. O chamamos desta forma por ter
correlação apenas com os índices. Este é um componente físico das estruturas do DB2.

Arquitetura DB2 UDB – Objetos para Recuperação

LOGS
Todas as alterações de dados nas tabelas DB2 UDB são eventos significantes, e são
gravados nas Logs do DB2 UDB. Em caso de falha de uma aplicação ou do próprio
Subsistema DB2 UDB, estes dados são utilizados para Recuperação.
O processo de LOG DB2 nada mais é do que gravar, em um arquivo VSAM Seqüencial,
o registro antes e depois da atualização, mais o TIMESTAMP do momento da alteração.
O arquivo de LOG ATIVA, por ser um arquivo VSAM, tem um tamanho máximo
permitido definido na Instalação do DB2 UDB. Assim sendo, quando este arquivo está
próximo da sua capacidade máxima, é executado um processo pelo Sub-sistema DB2
chamado ARCHIVE LOG. Este procedimento descarrega todos os registros da LOG
ATIVA em uma unidade de cartucho, e é registrado no catálogo DB2, chamado
SYSCOPY.

Todas as LOGs são definidas de forma DUAL, ou seja, gravados em duas unidades,
para garantir sua recuperação mesmo em situação de falha na leitura das LOGS.

BSDS
O BootStrat DataSet é um arquivo do tipo VSAM-KSDS, que contém informações
críticas para o funcionamento de um Subsistema DB2. O DB2 utiliza este arquivo
durante o procedimento de START, com a finalidade de garantir um ambiente seguro de
recuperação. Fazem parte deste arquivo as seguintes informações:

- Inventário das Logs Ativas e Archives Logs;

- Lista de Checkpoint efetuados em um Subsistema DB2;
- Informações para a conexões remotas (DDF);
- Informações sobre Buffers.

Segurança: todos pensam nisso

Segurança é uma tarefa vital dentro de um ambiente de banco de dados relacional.
Veremos agora os principais tópicos envolvidos nesta tarefa. Na figura abaixo temos
uma visão geral de como se integram os ambientes e a segurança dentro do DB2 UDB:

Um procedimento comum é garantir o acesso de um determinado usuário somente

através do RACF (sub-sistema de segurança da IBM), ou outro software similar.

Perfis de acessos ao DB2 UDB de diversos ambientes e “ADDRESS SPACES” são

definidos como recurso para o RACF. Cada requisição para acesso ao DB2 UDB é
associado com um usuário

(USERID): o RACF verifica se o USERID está autorizado pelo DB2 a utilizar os

recursos, permitindo ou não o acesso.
Do lado do DB2, o controle de acesso aos objetos é feito pelo assinalamento de
privilégios e autorizações para os recursos passados pelo RACF. Podemos ainda
especificar um conjunto de privilégios administrativos, que são específicos e definidos
pelo próprio DB2.

Controle de Acesso e o SQL

O controle de acesso aos objetos é feito utilizando a linguagem SQL. Para permitir o
acesso usamos o SQL GRANT, e para revogar este acesso, o SQL REVOKE. Abaixo
vamos ilustrar através de um modelo genérico:

GRANT privilégio ON TABLE objeto TO recurso

Para garantir ao usuário BARTH o acesso SELECT para a tabela RAMAIS, temos que
codificar o seguinte SQL :

GRANT SELECT ON TABLE RAMAIS TO BARTH.

Se precisamos garantir todos os acessos para a tabela RAMAIS a todos usuários
teremos:

GRANT ALL ON TABLE RAMAIS TO PUBLIC.

Vamos ilustrar um exemplo de revogação de acesso:

REVOKE SELECT ON TABLE RAMAIS FROM BARTH.

Acabamos de ver alguns aspectos gerais de segurança no ambiente DB2, suficientes
para os objetivos deste momento. Maiores detalhes poderão ser obtidos nos cursos
presenciais, ou então nos seguintes manuais do fabricante:

IBM DB2 UDB for OS/390 SQL Reference Manual

IBM DB2 UDB for OS/390 SQL Administration Guide

“Conversando” com o DB2: somos os objetos DB2!

Como podemos observar, um subsistema DB2 é composto de vários objetos
organizados hierarquicamente – cuidado, não estamos falando de Banco de Dados
hierárquico. Hierarquia, nesse contexto, corresponde à idéia de dependência entre os
objetos dentro do ambiente DB2 UDB.
Cada um desses objetos deve ter um nome que o identifique univocamente, com
exceção de nomes de tabelas, índices e views, que podem ter nomes iguais, mas com
owners (proprietários) distintos.

Para que seja possível gerenciar tal ambiente, é importante que algumas regras de
padronização sejam seguidas, de modo que seja possível estabelecer nomes que não
entrem em conflitos e que permitam uma identificação do tipo de objeto em questão.

Em algumas instalações, um mesmo subsistema pode conter mais de um ambiente (por

exemplo, desenvolvimento e homologação), tornando ainda mais importante um sistema
de padronização de nomes.

O pré-requisito básico para a construção e padronização de nomes dos objetos DB2 é a

modelagem de dados, associada à construção de um Dicionário de Dados Lógico.
Podemos utilizar algumas técnicas para essa construção, tais como Modelo Entidade
Relacionamento (MER) ou Diagrama Entidade Relacionamento (DER). Além destas
técnicas, temos ferramentas que melhoram a produtividade e qualidade: uma ferramenta
muito conhecida pela comunidade de informática é o ERWin.

Embora nosso foco seja o DB2 UDB e a implementação física do Modelo de Dados,
vamos ver a seguir alguns tópicos sobre a Modelagem de Dados Lógica.

Modelagem de Dados
Um passo importante em qualquer projeto de banco de dados é o levantamento de
informações, de modo a retratar o mais fielmente possível as regras envolvidas no
negócio e seus relacionamentos. Uma boa modelagem dos negócios da empresa é
fundamental para que um projeto de banco de dados possa ser realizado de modo
gradual, sem que surjam problemas de integração no futuro.

O projeto físico de um banco de dados relacional mapeia, em tabelas, as entidades

derivadas do modelo lógico, levando também em conta fatores como quantidade de
acessos, atualizações, inserções, convivência entre processos BATCH e ONLINE, etc.

A modelagem lógica é um processo que procura determinar o mais fielmente possível as

entidades representativas de um negócio, bem como seus relacionamentos e regras. Ao
se definir entidades (como, por exemplo, funcionários, departamentos e projetos)
podemos ter regras e relacionamentos diferentes em empresas distintas, tais como:

Na empresa A um funcionário pertence a um departamento e pode estar alocado a

apenas um projeto.
Na empresa B um funcionário pertence a um departamento e pode estar alocado
simultaneamente a mais de um projeto.
Essas diferenças têm implicações no modelo físico: no primeiro caso, o projeto poderia
ser considerado como um atributo da entidade funcionário, pois normalmente, nas
relações 1:1, uma das entidades é na realidade atributo da outra. Isto, no caso da
empresa B, não é verdade.

O relacionamento entre as entidades poderá ser:

(1:1) um para um
(1:M) um para muitos
(M:M) muitos para muitos

Diagrama de Relacionamento:

O processo de modelagem lógica e o mapeamento dessas informações, por si só, é

matéria suficiente para um curso à parte, e está sendo apresentado aqui de uma forma
bastante resumida.

O relacionamento entre as entidades pode ser mapeado graficamente através do

diagrama de Entidades–Relacionamentos, onde cada entidade é representada por
retângulos, e os relacionamentos por setas, no qual o número de pontas identifica o tipo
de relacionamento.

No processo da modelagem física, cada entidade do negócio terá uma entidade

equivalente no modelo de dados físico mapeados numa tabela. Os atributos de cada
entidade serão representados por colunas dessa tabela.

Antes de começar esse processo é importante que se identifique as chaves primárias de

cada entidade do modelo, e que este seja normalizado para evitar anomalias na
implantação do modelo físico.

Normalização
1ª. Forma Normal:

Pelas próprias características do modelo relacional, qualquer tabela satisfaz a primeira

regra, pois não é possível, para uma dada ocorrência de uma entidade, haver mais de um
valor para uma dada coluna, conforme ilustrado pela figura.
2ª. Forma Normal:

No nosso exemplo, para identificar cada ocorrência na tabela, é necessário definir como
chave o código do componente, e o local onde o mesmo está armazenado. Mas essa
tabela não está de acordo com a segunda forma normal, pois o endereço, que é um
atributo, depende apenas de parte da chave, que é o local.

Como solução do exemplo anterior temos que separar os dados que dependem de
apenas parte da chave e criar uma nova tabela, abaixo temo o exemplo:

3ª. Forma Normal:

Nesse exemplo, Depto e NomeDepto são atributos que estão relacionados entre si, mas
nenhum deles pertence à chave primária dessa tabela. Como solução, teremos que
separar os dados que dependem de uma coluna não-chave:

“Conversando” com o DB2 :

Fiquem à vontade, utilize-me, sou o SQL!
 Agora que revimos a modelagem de dados, vejamos a linguagem SQL, adequada à
conversa com o DB2.

Muitos dos objetos DB2 já descritos até o momento podem ser referenciados
diretamente pela linguagem SQL, que é dividida em três categorias, a saber:

DDL (Data Definition Language)

Usada para Criar, Modificar ou Excluir objetos DB2.
DML (Data Manipulation Language)
Usada para Pesquisar, Inserir, Atualizar ou Deletar dados de tabelas (registros).
DCL (Data Control Language)
Usada para prover controle de acesso aos dados.
Iremos conhecer todas as categorias SQL, mas não iremos nos aprofundar em todos os
elementos e comandos que compõem cada uma das categorias, e sua sintaxe. Este
assunto é muito rico em detalhes e informações, e não é objetivo deste curso abrangê-
los em toda sua extensão e profundidade.

DDL (Data Definition Language) - 1 de 2

Na DDL temos os seguintes comandos SQL:
- CREATE (Criação de Objetos DB2)
- ALTER (Alteração de Objetos DB2)
- DROP (Eliminação de Objetos DB2)
- DECLARE (Criação temporária de Objetos DB2)
Abaixo temos a sintaxe completa de um comando DDL, mais precisamente CREATE
TABLE, para podermos ter uma noção dos elementos que envolvem uma criação de
uma tabela DB2:

Podemos destacar algumas informações, para melhor conhecer esta DDL:

Column-definition: Podemos definir as características das colunas, tamanho, tipo de
dado.
Unique-constraint: Definimos a chave primária ou não.
Referential-constraint: Regras de integridade referencial.
Check-constraint: Regras de negócio.

DDL (Data Definition Language) - 2 de 2

Sobre definição de colunas temos alguns detalhes a saber:

Podemos obter mais detalhes sobre a DDL no manual do fabricante de cada gerenciador
de banco de dados. No caso do DB2 UDB, temos o IBM DB2 UDB for OS/390 SQL
Reference Manual.

Exemplo de DDL:
DML (Data Manipulation Language)
Na DML temos os seguintes comandos SQL:
- SELECT (Pesquisando dados)
- INSERT (Inserindo dados)
- DELETE (Deletando dados)
- UPDATE (Atualizando dados)
Para detalharmos cada um dos comandos, utilizaremos como base uma tabela de nome
RAMAIS, ilustrada a seguir :

Comando SELECT
Sintaxe básica:

Clause – quais colunas, funções escalares, colunas derivadas.

Where – condições de restrições de pesquisa (linhas).
Group by – Agrupamento de linhas.
Having – Condições sobre os agrupamento de linhas.

Exemplo prático:

Neste exemplo, estamos selecionando apenas as colunas NOME e SOBRENOME da

tabela RAMAIS, somente para as linhas que tenham como conteúdo o RAMAL 7447.
Evidentemente há inúmeras outras possibilidades de SELECT, que não serão aqui
tratadas.

Um outro exemplo:
Neste caso temos o ORDER BY, que tem como função a classificação do resultado da
pesquisa.

Comando INSERT
Sintaxe básica:

Exemplo prático:

Considerações :

Todas as regras de integridade serão verificadas pelo DB2 antes de efetivar o comando
INSERT. Essas regras são:

- Chave Primária e chave Única

- Chave Estrangeira
Neste exemplo, considerando que a coluna RAMAL é uma chave primária, e que já
existe na tabela uma linha com RAMAL = 7777, um SQL ERRO ocorrerá, indicando a
violação da chave primária.

Comando INSERT - Tratamento de NULOS:

Se algum atributo (coluna) permitir o NULO (NULLS), podemos inserir uma linha
nova na tabela utilizando três formas:
1a. Forma: Informando a coluna e colocando explicitamente o comando NULL no
INSERT
INSERT INTO RAMAIS (RAMAL, NOME, SOBRENOME, DEPTO)
VALUES (‘7777’, ‘Alfredo’, ‘Camargo’, NULL)
2a. Forma: Informando a coluna e não colocando o dado
INSERT INTO RAMAIS (RAMAL, NOME, SOBRENOME, DEPTO)
VALUES (‘7777’, ‘Alfredo’, ‘Camargo’, ‘’)
3a. Forma: Não informando a coluna.
INSERT INTO RAMAIS (RAMAL, NOME, SOBRENOME) VALUES (‘7777’,
‘Alfredo’, ‘Camargo’)

DELETE
Sintaxe básica:

Exemplo prático:

Considerações:

A regra de integridade referencial será verificada pelo DB2 antes de efetivar o comando
DELETE: se existir alguma tabela que dependa da tabela RAMAIS, um SQL ERRO
ocorrerá, indicando a violação da chave estrangeira.

MUITO CUIDADO com o DELETE sem a cláusula WHERE, pois o DB2 irá deletar
todas as linhas da Tabela. Evidentemente, somente caso nenhuma regra de integridade
referencial seja violada.
UPDATE
Sintaxe básica:

Exemplo prático:

Considerações :

Todas as regras de integridade serão verificadas pelo DB2 antes de efetivar o comando
UPDATE. Essas regras são:

- Chave Primária e chave Única

- Chave Estrangeira
No exemplo acima, considerando que a coluna RAMAL é chave primária, e existe na
tabela uma linha com RAMAL = 7717, um SQL ERRO ocorrerá, indicando a violação
da chave primária.

SUBQUERIES
Utilizamos subqueries para resolvermos determinadas pesquisas, nas quais
necessitamos executar uma query interna para obtermos valores que serão comparados
com a query externa. Tipicamente, pesquisas do tipo ranqueamento são resolvidas com
subqueries.
Por exemplo, queremos obter quais Funcionários existem na tabela EMPREGADOS
que tenham SALÁRIO maior que a MÉDIA salarial do DEPARTAMENTO.

Algumas considerações:

1º. – Precisamos saber qual a média salarial do DEPARTAMENTO (query interna);

2º. – Precisamos comparar o salário dos Funcionários com esta média
(query externa).
Para resolver este problema temos o seguinte SELECT:

SELECT DEPTO, NOME, SALARIO FROM EMPREGADOS T1

WHERE SALARIO > (SELECT AVG(SALARIO) FROM EMPREGADOS
WHERE DEPARTAMENTO = T1.DEPARTAMENTO)

JOINS
Utilizamos o JOIN para resolver problemas de normalização. Quando necessitamos
pesquisar informações que estão distribuídas em tabelas diferentes, por questões de
normalização o JOIN é a solução.

Queremos obter informações sobre os Ramais e o nome dos Departamentos da empresa,

mas esta última informação não se encontra na tabela Ramais e sim na tabela
Departamentos: o exemplo abaixo resolve nosso problema:

SELECT RAMAL, A.NOME, SOBRENOME, B.NOME FROM RAMAIS A,

DEPARTAMENTOS B WHERE A.DEPTO = B.DEPTO

Uma consideração importante para o JOIN é clausula WHERE, que indica a condição
de JOIN.

Existem ainda outras situações de JOIN, que não serão abordadas neste momento:

- INNER JOIN
- OUTER JOIN
- FULL OUTER JOIN.

Leitura Módulo 4 - finalizada

Você acabou de ter contato com o DB2, um potente Banco de Dados para Mainframes,
pouco conhecido no universo da microinformática: sua arquitetura, modelação de
dados, comandos para a interação com o sistema.

Realize agora a avaliação do Módulo 4, para prosseguir para o Módulo 5 – Redes.”