DB2 z/OS - O DB2 do Mainframe

Principios básicos do DB2

2009-10-13T09:09:00.000-03:00

Começado com o último post pretendo colocar aqui alguns outros com os príncipios básicos do DB2. No primeiro post escrivi sobre a relação do DB2 com o z/OS. Os outros posts serão sobre: Arquiterua do DB2, Estrutura de Dados, e Estrutura de Sistema.

Arquitetura DB2 para o z/OS

2009-08-03T13:02:00.003-03:00

Aqui temos um pequeno tópico sobre a arquitetura do DB2 para o Mainframe.

A arquitetura do DB2 para z/OS

z/OS

O z/OS é o sistema operacional para zSeries baseado na arquitetura de 64-bit. Ele é a geração seguinte ao OS/390.

A integração do DB2 com o z/OS está cada vez maior permitindo um melhor uso das funções do z/OS. A arquitetura do DB2 foi redesenhada para poder aproveitar o suporte ao endereçamento virtual em 64-bit (64-bit virtual address support).

O DB2 se beneficia dos seguintes componentes da nova arquitetura para zSeries:
• 64-bit Storage: Aumenta de 2GB para 64GB a capacidade central de memória eliminando a maior parte do limite de armazenamento (storage contraints ???). Com o armazenamento de 64-bit existem 16 exabytes de endereçamento de memória (vamos utilizar address space) virtual. Esse tipo de arquitetura ainda aumenta a disponibilidade e escalabilidade e simplifica o gerenciamento de espaço.
• Comunicação em alta velocidade: Hipersockets possibilita comunicação TCP-IP em alta velocidade entre as partições de um mesmo servidor zSeries, por exemplo, entre o Linux para zSeries e o DB2 z/OS.
• Gerenciamento de workload dinâmico: O gerenciador de espaço (storage) para o z/OS, IRD (Intelligent Resource Director), expande a capacidade do WLM (workload manager) gerenciando dinamicamente de acordo com as prioridades de workload.

Em adição aos benefícios da arquitetura z, o DB2 tem mais outras vantagens das opções do sistema operacional z/OS:
• Maior Segurança: z/Series, z/OS e outros predecessores tem provido uma segurança robusta. As opções de segurança disponibiliza privacidade para usuários, aplicações e dados e protege a integridade e isola os processos que estão rodando. As funções atuais de segurança evoluiriam para incluir uma rede compreensiva e segurança transacional que operam em diversos outros sistemas operacionais. Melhoras no z/OS Security Server e Tivoli aumentam as opções de segurança, bem como multilevel security.
• Tecnologia de software aberto: z/OS usa as mais novas tecnologias para software aberto que incluem Entreprise JavaBeans, XML e UNICODE.
• Tecnologia de cluster: o z/OS Parallel Sysplex disponibiliza uma tecnologia de cluster que possibilita a disponibilidade do sistema 24 horas por dia, 7 dias por semana. Tecnologia de cluster também possibilita a capacidade de crescimento horizontal. Crescimento horizontal resolve os problemas de overhead de performance e problemas de gerenciamento de sistemas encontrados em sistemas com diversas máquinas que acessam o mesmo banco de dados. Com crescimento horizontal, maior escalabilidade é alcançada; o sistema pode crescer além do limite de uma única máquina enquanto seu banco de dados permanece intacto.
• Processadores mais rápidos: Com processadores mais rápidos e poderosos, o DB2 alcança maiores graus de paralelismos de queries e níveis mais altos de movimentos transacionais.
• Melhora da tecnologia de I/O: O IBM Entreprise Storage (ESS) explora o acesso paralelo de volumes e Multiple Allegiance(?) (opções do z/OS) e suporta até 256 me/Os por volume de disco lógico. Um único ambiente z/OS pode ter I/Os em paralelo no mesmo volume lógico e diferentes ambientes podem ter I/Os em um volume compartilhado em paralelo.
• Canais FICON: Esses canais oferecem significantes benefícios de performance para transações de workload. As características FICON, por exemplo uma rápida taxa de transferência de dados (100MB por segundo), resulta também varredura de tabela mais rápida e melhora a performance de utilitários.
• Melhora da compressão de hardware: A melhora na compressão de hardware teve um impacto positivo da performance. Por exemplo, utilitários que rodam em dados compressados rodam mais rápidos.

O DB2 em um ambiente z/OS

O DB2 opera como um subsistema formal do z/OS.

Os processos do z/OS são separados em regiões que são chamados address spaces. Os processos do DB2 z/OS são executados em diversos address spaces diferentes. Alguns processos de aplicações do DB2 rodam em um address space que solicitam serviços ao DB2 como WebSphere, IMS, e CICS.

Subsystem
O Subsistema é um sistema secundário ou subordinado que é usualmente capaz de operar independentemente de, ou não sincronizado com, um controlador de sistema. O subsistema DB2 é uma instancia distinta de um DBMS relacional. O software controla tanto a criação, organização e alteração de um banco de dados e o acesso aos dados que o banco de dados armazena.

O DB2 trabalha eficientemente com outros subsistemas do z/OS e componentes. Nesse mesmo capítulo serão explicados alguns componentes chaves – o z/OS Security Server e o zSeries Parallel Sysplex.

Os utilitários do DB2 rodam no ambiente batch do z/OS. Aplicações que acessam recursos do DB2 podem rodar em um mesmo sistema z/OS no CICS, IMS, TSO ou em ambiente batch ou em outro sistema operacional. Essas aplicações podem acessar recursos do DB2 usando serviços cliente/servidor do DB2 distribued data facility (DDF). A IBM disponibiliza ‘attachment facilities’ para conectar o DB2 em cada um desses ambientes.

DB2 lock manager

O IRLM do DB2 (internal resource lock manager) é tanto um subsistema separado com um componente integral do DB2. Cada subsistema DB2 deve ter seu próprio IRLM.

O IRLM trabalha com o DB2 para controlar o acesso aos dados. O DB2 pede o lock do IRLM para garantir a integridade dos dados quando aplicações, utilitários e comandos que tentam acessar os mesmos dados.

DB2 e o z/OS Security Server

Para controlar o acesso para o seu sistema z/OS, pode ser usado o RACF (resource access control facility) que é um componente do z/OS Security Server ou um produto equivalente. Quando usuários começam alguma sessão. O z/OS Security Server checa suas identidades para prevenir acessos não autorizados ao sistema. O z/OS Security Server pode também ser usado para proteger recursos do DB2, como as tabelas.

Integridade de Dados

2007-12-31T11:46:00.000-03:00

Introdução

Nessa era da informação sob demanda não podemos nos contentar em que os dados são apenas registros armazenados em um banco de dados. Sem a devida garantia de sua integridade não podemos transformá-los em informação.

De nada adianta termos imensos bancos de dados armazenando incontáveis bytes de dados, que são constantemente inseridos, modificados, eliminados, se não podemos transformá-los em informação. E, de preferência, informação útil. E sem garantir que nossos dados armazenados estão íntegros, dificilmente conseguimos transformar esses bytes em informação real. Não importa quão avançada sejam suas ferramentas ou técnicas de aplicação em seu ambiente, nada irá adiantar se não houver um investimento na qualidade de seus dados.

Ao falarmos de integridade de dados, podemos citar alguns exemplos que podem e ajudam a garanti-la:

· Firewalls

· Sistema Gerenciador de Banco de Dados (SGDB)

· Revisão regular de privilegio aos dados

· Encriptação

· Controle na prevenção de corrupção de dados

· Compliance

· Fácil recuperação de dados e performance

· Integração com os sistemas de armazenamento (discos, fitas)

· Trafego dos dados pela rede

· E mais...

Usando os exemplos citados acima, podemos dividir a integridade dos dados em 2 grupos:

· Sob a ótica do sistema: Integração com o hardware como discos, fitas; conexão de rede; firewalls; integração entre o SGDB e o sistema.

· Sob a ótica da aplicação: Integridade referencial; triggers; lockings; controle de acesso aos dados.

Nesse artigo será abordado a ótica da aplicação, mais precisamente da parte que depende do Sistema Gerenciador de Banco de Dados (SGDB) de integridade referencial, integridade semântica, integridade de domínio. Cada um desses itens será explicado no decorrer do texto.

O Sistema Gerenciador de Banco de Dados e a integridade dos dados

Os SQL statements INSERT, DELETE e UPDATE modificam os dados em um banco de dados existentes. Toda vez que os dados são alterados existe a possibilidade que integridade lógica ser afetada. Por exemplo, a inserção de um produto inexistente em um pedido um cliente, ou um cliente pode ser eliminado mesmo tenho ainda pedidos pendentes em seu nome. Em ambos os casos houve perda da integridade dos dados.

A integridade de dados em SGDBs é uma combinação de:

· Integridade semântica: o dado de uma coluna sempre será do tipo de dado definido na criação da coluna

· Integridade de entidade: cada linha de uma tabela possui um indicador que garanta a unicidade da mesma.

· Integridade referencial: os relacionamentos lógicos entre as entidades serão forçados pelos SGDB

· Integridade de domínio: Domínio é um conjunto de valores previamente definido no qual uma coluna só poderá conter valores pertencentes a esse domínio.

Quando bem definido um banco de dados, provavelmente esse quatro conceitos de integridade serão aplicados.

Integridade Semântica

A integridade semântica garante que o dado inserido em uma linha da tabela seja um valor válido. Esse valor para ser válido deve ser do mesmo tipo de dados definido na especificação da coluna na tabela. Por exemplo, um atributo de uma determinada entidade definido como DATA só conterá dados relativos a DATA. É a certeza que no campo DATA_CONTRATACAO só conterá datas válidas. Caso um SGDB permita a inserção de um outro tipo de dado diferente do definido, a integridade semântica estará sendo violada.

A integridade semântica em um SGDB é aplicada com a utilização de constraints. Usarei o termo em inglês nesse caso por dois motivos: 1) não encontrei termo apropriado para a tradução de constraint; 2) sendo os SGDBs na sua maioria escritos em inglês, esse é o termo mais conhecido por todos.

Constraints

Constraint pode ser definido resumidamente como uma regra que limita o valor que pode ser inserido, modificado, ou eliminado em uma tabela. Na linguagem SQL temos os seguintes tipos de constraints:

· Constraint de dados

· Constraint NOT NULL (não nulo)

· Constraint única

· Constraint de validação (check constraint)

Segue abaixo um resumo sobre esses tipos de constraints.

Constraint de dados

Esse tipo de constraint pode ser considerado o mais simples e por muitas vezes ignorado como um constraint. Ele é o que delimita o tipo de dado de cada coluna em uma tabela. Os tipos de dados disponíveis na maioria dos SGDBs existentes pode ser dividia em:

· Numérico

· Alfa numérico ou caracteres

· Data e tempo

· Grandes objetos

Tipos de dados numéricos mais comuns:

Tipo de Dados	Descrição
SMALLINT	Números inteiros pequenos
INTEGER	Números inteiros
DECIMAL	Números decimais. Contem a parte inteira e a decimal (13,2 por exemplo)
REAL	O número floating-point de precisão simples é um floating-point de 32 bit
FLOAT	O número floating-point de precisão dupla é um floating-point de 64 bit

Tipos de dados alfa-numérico ou caracteres:

Tipo de Dados	Descrição
CHAR	Para cadeias fixas de caracteres alfa numéricos
VARCHAR	Para cadeias variáveis de caracteres alfa numéricos

Tipos de dados data e tempo:

Tipo de Dados	Descrição
DATE	Data com valores representando dia, mês e ano
TIME	Tempo com valores representando hora, minuto e segundo
TIMESTAMP	Data e Tempo juntos com valores que representam ano, mês, dia, hora, minuto, segundo e milisegundo

Observação: na perspectiva do usuário, os tipos de dados data e tempo parecem ser do tipo alfa-numérico, porém fisicamente são armazenados como do tipo binário compactado.

Tipos de dados grandes objetos, tais como LOB (large object), armazenam grande quantidade de bytes podem ser utilizados para armazenar objetos do tipo imagem ou som.

Constraint NOT NULL (não nulo)

O conceito de nulo é utilizado quando uma determinada coluna ou atributo de uma linha na tabela não possui valor ou o valor é desconhecido. Pelo outro lado existem colunas / atributo que obrigatoriamente precisam de valor informado. Por exemplo, em uma tabela chamada FUNCIONARIO que dados de funcionários a atributo NUMERO_FUNCIONARIO é obrigatório. Nesse caso é possível utilizar a constraint NOT NULL para garantir que haverá informação nessa coluna.

Importante frisar aqui que NULO é diferente de brancos e zeros. Temos que lembrar que tanto branco quanto zero são valores validos e que são levados em conta em funções de coluna tais como média, somatório, máximo, mínimo. Sendo que o NULO é desconsiderado nessas funções.

Constraint única

No SQL a constraint única é uma regra que garante que não haverá valores duplicados da mesma coluna ou em um conjunto de colunas na mesma tabela. Usando o mesmo exemplo da tabela FUNCIONARIO, podemos utilizar uma constraint única na coluna NUMERO_FUNCIONARIO para garantir que dois ou mais funcionários possuam o mesmo número de identificação.

Podemos considerar que a chave primaria (primary key), que será explicada mais adiante, é um tipo de constraint única. Lembrando que uma tabela pode ter apenas uma chave primária, porém diversas constraint únicas.

Constraint de validação (check constraint)

A constraint de validação determina um conjunto de valores permitidos para uma determinada coluna na tabela. Essas constraints são definidas explicitamente no DDL (data definition language) de uma tabela com expressões Booleanas similares a clausula WHERE do SQL. Constraint de validação é forçada em qualquer inserção ou atualização da coluna. Caso a inserção ou atualização da coluna não esteja de acordo com a definição da constraint, a mesma não será executada.

Por exemplo, vamos supor que a tabela FUNCIONARIO possua uma coluna SALARIO e que o valor do salário de cada funcionário não possa ser maior que 50.000,00, é possível criar uma constraint para essa regra:

CREATE TABLE FUNCIONARIO (
      NUMERO_FUNCIONARIO SMALLINT NOT NULL,
      SALARIO DECIMAL (9,2) NOT NULL CHECK SALARIO >= 50.000);

Constraint de validação pode ser muito útil para garantir regras de negócio, pois ela não pode ser sobreposta. Uma vez definida é dada a garantia que a regra será respeitada.

Utilizando esse tipo de integridade torna as suas aplicações mais robustas, consistentes e simples, pois não é necessário controlar as regras dentro do próprio código de programação ou utilizando uma subrotina. Dessa maneira é isolada em apenas um lugar a regra de negócio. Havendo a necessidade de mudar alguma regra de negócio, basta apenas mudar a constraint de validação na tabela ao invés de sair alterando códigos e mais códigos de programação uma vez que a mesma regra pode estar replicada em diversos pontos da sua aplicação.

Integridade Referencial

Em resumo, integridade referencial é um conceito de banco de dados que garante que todos os relacionamentos propostos entre tabelas no modelo de entidade-relacionamento (ER) serão respeitados dando a certeza que os dados de um banco de dados estarão íntegros. Esses relacionamentos são baseados nas definições de uma chave primária e uma chave estrangeira e regras pré-definidas para a manipulação dessas chaves.

Vale lembrar que existem diversos livros, manuais, tratados que falam sobre integridade referencial, sendo assim esse artigo apenas deseja explicar de uma maneira simples e com exemplos esse conceitos.

Conceitos de IR (Integridade Referencial)

A figura abaixo mostra alguns conceitos de IR e o uso de sua terminologia:

Chave Candidata

Chave candidata é um atributo ou um conjunto de atributos de uma tabela que identifica uma única linha da tabela. A chave primária é extraída a partir do conjunto de chaves candidatas de uma tabela.

Na Figura 1 as chaves candidatas da tabela FUNCIONARIO o NR_FUNC (número do funcionário) e NR_CPF (número do CPF) por que eles garantem a unicidade de uma linha na tabela.

Chave Única

Uma chave única que definida pela constraint única que garante que um atributo ou um conjunto de atributos não pode ser duplicado na mesma tabela.

Chave Primária

A chave primária de uma tabela é uma das chaves candidatas que melhor identifica uma tabela. Os critérios para escolher a chave primária são:

· O conteúdo da coluna ou do conjunto de colunas deve sempre existir, em outras palavras deve possuir a constraint semântica NOT NULL.

· O valor da chave não deve poder ser alterado.

A chave primária tem as seguintes características:

· Apenas uma chave primária por tabela

· Pode ser composta por mais de uma coluna

· Obrigatoriamente ser NOT NULL (não nulo)

No exemplo mostrado na Figura 1 a coluna NR_FUNC da tabela foi escolhida como chave primária uma vez o NR_CPF, apesar de não usual, pode conter valor nulo já que no momento da contratação o funcionário pode não ter o CPF.

Na mesma figura, a chave primaria da tabela DEPARTAMENTO é NR_DEPT (número do departamento).

Chave Estrangeira

A chave estrangeira se refere ou é relacionada com alguma chave primaria de uma tabela, podendo ser inclusive da mesma tabela. É a concretização do relacionamento proposto no modelo entidade-relacionamento (MER).

A chave estrangeira tem as seguintes características:

· Uma tabela pode possuir zera, uma ou diversas chaves primárias

· Pode ser composta de uma ou mais colunas contando que ela seja exatamente igual à chave primaria que ela é relacionada (tipo de dado e tamanho)

· Pode conter a clausula NULL

Na figura 1, a coluna NR_DEPT da tabela FUNCIONARIO é uma chave estrangeira que referencia a tabela DEPARTAMENTO cuja chave primária é NR_DEPT.

Chave Parente

A chave parente é uma chave única que é referenciada pela chave estrangeira. Pode ser tanto a chave primaria como uma outra chave única existente na tabela. Os valores da chave parente determinam os valores validos da respectiva chave estrangeira.

Tabela parente

Uma tabela parente é uma tabela que possui chaves parentes que é referenciada por uma ou mais chaves estrangeiras.

A tabela DEPARTAMENTO da Figura 1 é uma tabela parente pois possui uma chave primária, NR_DEPT, que é referenciado por uma chave estrangeira na tabela FUNCIONARIO.

Normalmente as chaves estrangeiras são referenciadas por chaves primárias, mas nada impede que seja referenciada por uma chave única.

Tabela Dependente

Toda tabela que possui uma ou mais chaves estrangeiras é uma tabela dependente. Uma tabela dependente pode não possuir uma chave primária mas mesmo assim também pode ser uma tabela parente.

A tabela FUNCIONARIO é uma tabela dependente da tabela DEPARTAMENTO por possuir uma chave estrangeira que referencia essa tabela.

Tabela Independente

Uma tabela que não possui chave estrangeira é chamada de tabela independente.

Linha Dependente

Uma linha dependente é uma linha de uma tabela dependente no qual o valor da chave estrangeira não é nulo.

Integridade de entidade

A obrigatoriedade que uma chave primária não possa conter valores NULOS e que ela é única na tabela define a regra integridade de entidade.

Constraint Referencial

É a constraint que define a Integridade Referencial (IR) de relacionamentos entre tabelas em um banco de dados. O conceito de IR garante que todos os valores não nulos existentes em uma chave estrangeira são iguais aos da chave primária que ela referencia.

Regras e opções de IR

O modelo relacional possui um conjunto de regras para controle da inserção, atualização e eliminação dos dados nas tabelas. As regras são:

· Regra de Inserção (INSERT)

· Regra de Atualização (UPDATE)

· Regra de Eliminação (DELETE)

Regra de Inserção

A regra de inserção é uma regra implícita, diferentemente das regras de atualização e eliminação que precisam ser declaradas no momento de criação das chaves estrangeiras.

Essa regra define que qualquer linha inserida na tabela dependente deve conter o valor na chave estrangeira no qual será:

· Nulo, se for permitido nulo na chave estrangeira

· Exatamente o mesmo valor da chave parente da respectiva tabela parente.

Independente se a tabela dependente possui uma ou mais chave parente, a regra de inserção garante que o valor inserido estará integro em relação aos seus relacionamentos.

Regra de Atualização

A regra de atualização deve ser explicitamente definida no momento de criação da chave estrangeira. Essa regra é acionada quando:

· A chave estrangeira da tabela dependente é atualizada. Nesse caso, assim como a regra de inserção, o valor só pode ser alterado para nulo, caso seja permitido, ou para um valor existente na chave parente da tabela parente.

· A chave primária da tabela parente é atualizada

Existem três opções para a regra de atualização:

· RESTRITO:

o A chave parente não pode ser atualizada caso exista alguma chave estrangeira em qualquer tabela dependente que o possua o mesmo valor.

· CASCATA:

o Caso a chave parente seja atualizada, todas as chaves estrangeiras respectivas de cada tabela dependente que contenha o valor da chave parente serão também atualizadas para o novo valor.

· NULO:

o Caso a chave parente seja atualizada, todas as chaves estrangeiras respectivas de cada tabela dependente que contenha o valor da chave parente serão atualizadas com o NULO.

Cada chave estrangeira é associada a sua regra de atualização respectiva. A regra de atualização determina se a atualização pode ser feita ou não. Sendo assim, uma chave parente não poderá ser atualizada caso qualquer chave estrangeira respectiva for definida com a regra RESTRITO.

Regra de Eliminação (delete)

Do mesmo modo que a regra de atualização, a regra de eliminação deve ser definida no momento da criação da chave estrangeira. Essa regra é imposta toda vez que houver tentativa de eliminar uma linha da tabela parente.

Essa regra também possui as mesmas três opções da regra de atualização:

· RESTRITO:

o A linha da tabela parente não pode ser eliminada caso exista na tabela dependente o mesmo valor na chave parente e de sua respectiva chave estrangeira.

· CASCATA:

o Todas as linhas de qualquer tabela dependente que possua o valor na chave estrangeira igual ao valor da chave parente também serão eliminadas.

o A eliminação é propagada para os dependentes das tabelas dependentes

o Se uma das eliminações falharem o processo inteiro falha também

· NULO

o Todas as linhas de qualquer tabela dependente que possua o valor na chave estrangeira igual ao valor da chave parente serão atualizadas para o valor NULO

Cada chave estrangeira possui sua própria regra de eliminação. A regra de eliminação determina se uma linha pode ser ou não eliminada. Portanto uma linha pode não ser eliminada caso:

· Uma ou mais chave estrangeira possua a regra RESTRITO, ou

· Quando possua a regra CASCATA e no momento da propagação da eliminação encontre alguma chave estrangeira que esteja definida como RESTRITO nas tabelas dependentes da tabela dependente.

A figura 2 mostra exemplo de um modelo de entidade-relacionamento com suas respectivas regras de eliminação:

Conclusão

No mundo atual, aonde a informação vem se tornando cada vez valiosa, de nada adianta termos imensos bancos de dados contendo milhares de dados sem garantimos a integridade desses dados. A Integridade Referencial é um conceito que existe desde os primórdios do banco de dados e hoje entra como um papel fundamental para a garantia da veracidade das informações armazenadas.

Praticamente todos os Sistemas Gerenciadores de Banco de Dados (SGDB) possuem mecanismos para a implementação da IR facilitando o trabalho de programadores e analistas, pois, uma vez implementada existe a garantia que o SGDB irá gerenciá-la com todas essas regras em um único lugar encapsuladas.

Melhorias no SQL do DB2 V8 z/OS

2007-12-20T16:00:00.000-03:00

E para começar, o primeiro assunto postado aqui é sobre algumas melhorias no SQL do DB2 z/OS V8.

Melhorias no SQL do DB2 V8 z/OS

A versão 8 do DB2 trouxe novos statements SQL para facilitar e melhorar a vida de todos que usam o DB2. Aqui segue uma lista de todas as novas funcionalidades do SQL.

SELECT from INSERT
Objeto Sequence
Melhorias para colunas do tipo Identity
Predicado DISTINCT
Scalar fullselect
Multiple-row INSERT e FETCH
Expressões de tabelas
GET DIAGNOSTICS
Dynamic scrollable cursors
Melhorias na linguagem SQL procedural
Uso mais freqüente de indicies
SQL statements maiores e mais complexos
Multiple DISTINCT keywords
Expressões na cláusula GROUP BY
Menos restrições para funções de colunas
Nomes das colunas qualificados no statement de INSERT
Clausula ORDER BY para o statement SELECT INTO
Formatos de input adicionais para timestamp
Colunas ROWID explicitamente definidas não são mais necessárias para LOBs
Comentários para planos e packages
Drop implícito para tabelas temporárias globais no commit
Mudanças no SQL para multilevel security com granularidade de coluna
Comentários nos statements SQL
Encriptação e desencriptação de dados
Melhor controle sobre os locks em queires

Vamos começar esse post com a explicação do SELECT from INSERT statement. Os demais itens listados serão contemplados também com o passar dos dias

SELECT from INSERT

Esse novo statement SQL permite a seleção de colunas de uma tabela no momento da inserção dos dados. Imagine uma tabela que tenha definição de uma coluna do tipo IDENTITY como o exemplo abaixo:

CREATE TABLE EMPLOYEE

(EMPNO INTEGER GENERATED ALWAYS AS IDENTITY,

NAME CHAR(30),

SALARY DECIMAL(10,2),

DEPTNO SMALLINT,

LEVEL CHAR(30),

HIRETYPE VARCHAR(30) NOT NULL WITH DEFAULT 'New Hire',

HIREDATE DATE NOT NULL WITH DEFAULT);

A coluna EMPNO é definida como IDENTITY. Nesse caso, quando há inserção de dados nessa tabela, a coluna EMPNO não é referenciada, pois o próprio DB2 irá gerar o valor para lá. Antes do DB2 V8 só era possível saber o valor da coluna EMPNO fazendo um SELECT após o INSERT.

Com o novo statement “SELECT from INSERT” é possível já saber o valor que vai ser atribuído a coluna no momento do INSERT. Portanto no DB2 V8 ao invés de fazer um SELECT após o INSERT, é possível fazer o SELECT no momento do INSERT como mostra o exemplo abaixo.

SELECT EMPNO, HIRETYPE, HIREDATE

FROM FINAL TABLE (INSERT INTO EMPLOYEE (NAME, SALARY, DEPTNO, LEVEL)

VALUES('Mary Smith', 35000.00, 11, 'Associate'));

Nesse exemplo é recuperado o conteúdo das três colunas que têm valores atribuídos pelo DB2 no momento da inserção: EMPNO (IDENTIDY), HIREDATE e HIRETYPE (que tem cláusula DEFALUT)

Os valores que podem ser recuperados nesse novo tipo de statement SQL são:

Valores de colunas que são resultados de uma expressão
Colunas definidas como DEFAULT
Todos os valores de uma linha inserida, sem especificar o nome da coluna
os valores inseridos pela operação MULTI-ROW INSERT
Valores que são alterados por um BEFORE TRIGGER
Valores que são gerados automaticamente, como ROWID ou INDETITY

Maiores Informações
Manual DB2 UDB for z/OS V8 SQL reference: http://publib.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/dsnsqj14/CCONTENTS

Bem vindo ao Blog DB2 z/OS - O DB2 do Mainframe

2007-12-20T15:48:00.000-03:00

Antes de qualquer coisa quero dar boas vindas a todos.

A idéia desse blog é trazer novidades, soluções, dicas e tudo mais que for relacionado ao DB2 z/OS – o DB2 do Mainframe. E em português!

Todos nós sabemos que grande parte (e olha que tem bastante) do material relacionado ao DB2 e ao mainframe são escritos em inglês: Fóruns, comunidades, manuais, Redbooks. E, infelizmente, isso pode ser fator limitante para algumas pessoas em busca de conhecimento. Por isso começo esse blog hoje, para trazer as novidades, soluções e dicas que encontramos mundo a fora para a nossa língua.

Aqui vocês irão encontrar traduções de alguns bons blogs estrangeiros, mais contribuições minhas e de quem desejar trocar informações.

Por isso são bem vindos comentários, sugestões e toda forma pró-ativa de contribuição.

Mais uma vez, sejam bem vindos e espero que aproveitem.