ibm i: administração de banco de dados · criando objetos de banco de dados .... . 4 assegurando...

IBM iVersão 7.3

Banco de DadosAdministração

IBM

AvisoAntes de utilizar estas informações e o produto suportado por elas, leia as informações em “Avisos” na página 47.

Esta edição se aplica ao IBM i 7.3 (número do produto 5770-SS1) e a todas as liberações e modificaçõessubsequentes, até que seja indicado de outra forma em novas edições. Esta versão não é executada em todos osmodelos RISC (Reduced Instruction Set Computer), nem nos modelos CISC.

Este documento pode conter referências ao Código Interno Licenciado. O Código Interno Licenciado é um Códigode Máquina e é licenciado a você sob os termos do IBM License Agreement for Machine Code.

© Copyright IBM Corporation 1998, 2015.

Índice

Administração de Banco de Dados . . . 1O que há de novo para o IBM i 7.3 . . . . . . . 1Arquivo PDF para Administração de Banco de Dados 1Administração de Banco de Dados . . . . . . . 2

Acessando Dados Através de Interfaces do Cliente 2Acessando Dados com Java . . . . . . . 2Acessando Dados com o Domino . . . . . 2Acessando Dados com o ODBC . . . . . . 2Acessando Dados com o IBM i PASE . . . . 2Acessando Dados com o Provedor IBM i Accesspara Windows OLE DB . . . . . . . . . 2Acessando Dados com o IBM i Access paraWindows .Net Provider. . . . . . . . . 3Acessando Dados com o Net.Data . . . . . 3Acessando Dados Através de uma Partição doLinux . . . . . . . . . . . . . . . 3Acessando Dados Utilizando o DRDA(Distributed Relational Database Architecture) . 3

Alterando e Gerenciando Objetos de Banco deDados . . . . . . . . . . . . . . . 3Criando Objetos de Banco de Dados . . . . . 4Assegurando a Integridade dos Dados. . . . . 4Importando e Exportando Dados entre Sistemas . 4Trabalhando com Vários Bancos de Dados . . . 4Trabalhando com tabelas temporais de período dosistema . . . . . . . . . . . . . . . 5

Tabelas Temporais de Período do Sistema. . . 5Coluna de tempo inicial . . . . . . . 5Coluna de tempo final . . . . . . . . 5ID de início de transação . . . . . . . 6Período SYSTEM_TIME. . . . . . . . 6

Tabelas de históricos . . . . . . . . . . 6Criando uma tabela temporal de período dosistema . . . . . . . . . . . . . . 7

Exemplos adicionais de CREATE TABLE databela temporal de período do sistema. . . 8

Inserindo dados em uma tabela temporal deperíodo do sistema . . . . . . . . . . 9Atualizando dados em uma tabela temporalde período do sistema . . . . . . . . . 10Excluindo dados em uma tabela temporal deperíodo do sistema . . . . . . . . . . 11Usando uma tabela temporal de período dosistema para controlar informações deauditoria . . . . . . . . . . . . . 12Conflitos de valor de registro de data e horada tabela temporal de período do sistema . . 14Consultando os dados temporais do períododo sistema. . . . . . . . . . . . . 15

Especificando os critérios de tempo emuma consulta . . . . . . . . . . . 15Especificando os critérios de tempo usandoo registro especial CURRENT TEMPORALSYSTEM_TIME . . . . . . . . . . 17Especifique os critérios de tempo para umavisualização . . . . . . . . . . . 19

Restrições ao inserir, atualizar ou excluirdados em uma tabela temporal de período dosistema . . . . . . . . . . . . . . 21Considerações de E/S nativa com uma tabelatemporal de período do sistema . . . . . 22Mantendo a tabela de históricos . . . . . 22Particionando uma tabela temporal de períododo sistema. . . . . . . . . . . . . 23Controle de acesso de linha e coluna com umatabela temporal de período do sistema . . . 23Salvando e restaurando as tabelas temporaisde período do sistema . . . . . . . . . 24Usando catálogos para localizar informaçõessobre a tabela temporal de período do sistema. 24Restrições da tabela temporal . . . . . . 25

Trabalhando com Acionadores e Restrições . . . 25Gravando Programas do DB2 . . . . . . . 25

Backup e Recuperação do Banco de Dados . . . . 26Administração de Banco de Dados Distribuída . . 26Consultas e Relatórios . . . . . . . . . . . 26Segurança . . . . . . . . . . . . . . . 27

Opções de Autoridade para Análise e Ajuste deSQL . . . . . . . . . . . . . . . . 27

Row and Column Access Control (RCAC) . . . . 32Visão Geral . . . . . . . . . . . . . 33Permissões e Máscaras. . . . . . . . . . 34Instruções SQL . . . . . . . . . . . . 35Funções Protegidas . . . . . . . . . . . 36Proteger Acionadores . . . . . . . . . . 36Autoridade administrativa . . . . . . . . 36Melhores Práticas ao Usar Permissões e Máscaras 36

Criando Permissões e Máscaras. . . . . . 36Única Permissão com Todos os Usuários . 36Única Permissão com um Perfil de Grupo 37Única Permissão com uma TabelaDependente . . . . . . . . . . . 37Única Permissão com um UDF . . . . . 37Permissões para Cada Usuário . . . . . 38Atributos de Diversas Permissões . . . . 38Nomes de Objetos Não Qualificados . . . 39

Objetos Dependentes . . . . . . . . . 39Propriedade . . . . . . . . . . . 39Esquema . . . . . . . . . . . . 39Autoridade de Esquema . . . . . . . 40UDFs Protegidos . . . . . . . . . 40ALWCPYDTA e Nível de Isolamento . . . 40Restaurando Objetos . . . . . . . . 40

Operações Adicionais . . . . . . . . . 41Incluindo o Perfil do Aplicativo emPermissões e Máscaras. . . . . . . . 41Recuperar o Armazenamento . . . . . 41Relatórios de Consulta. . . . . . . . 41MQTs . . . . . . . . . . . . . 41Tabelas temporais . . . . . . . . . 42Perfis de Grupo e QIBM_DB_SECADM . . 42Parâmetros Copy File (CPYF) . . . . . 42

© Copyright IBM Corp. 1998, 2015 iii

||

||||||||||||||||||||||||||||||||||||||||||||||||||

|||||||||||||||||||||||

||

OmniFind Text Search Server for DB2 for i 43Usando o RCAC em Arquivos LógicosMultiformatados. . . . . . . . . . . 43Propagação de Dados Mascarados . . . . . 44

Classic Query Engine (CQE) e SQL Query Engine(SQE) . . . . . . . . . . . . . . . . 46

Diferenças entre nativo aberto e consulta SQLenvolvendo RCAC . . . . . . . . . . . 46

Ordenação de Conjunto de Resultados . . . . 46

Avisos . . . . . . . . . . . . . . . 47Informações sobre a Interface de Programação. . . 49Marcas Registradas . . . . . . . . . . . . 49Terms and conditions . . . . . . . . . . . 49

iv IBM i: Administração de Banco de Dados

Administração de Banco de Dados

O DB2 para IBM® i fornece funções de administração de banco de dados, de backup e recuperação, deconsulta e de segurança.

Você também pode explorar outras informações do banco de dados utilizando a árvore de navegaçãoprincipal ou o Localizador de Informações do Banco de Dados.

O que há de novo para o IBM i 7.3Leia sobre informações novas ou significativamente alteradas para a coleta de tópicos de administraçãode Banco de Dados.

Tabela Temporal de Período do Sistema

Uma tabela temporal de período do sistema é uma tabela que mantém versões históricas de suas linhas.

Como Saber o Que É Novo ou Que Foi Alterado

Para ajudar a ver onde as alterações técnicas foram feitas, o centro de informações utiliza:v A imagem

marca onde começam as informações novas ou alteradas.

v A imagem

marca onde terminam as informações novas ou alteradas.

Nos arquivos PDF, você poderá ver barras de revisão (|) na margem esquerda das informações novas oualteradas.

Para localizar outras informações sobre as novidades ou alterações neste release, consulte Memorandopara Usuários.

Arquivo PDF para Administração de Banco de DadosVocê pode visualizar e imprimir um arquivo PDF dessas informações.

Para visualizar ou fazer o download da versão em PDF deste documento, selecione Administração dobanco de dados.

Salvando Arquivos PDF

Para salvar um PDF em sua estação de trabalho para exibição ou impressão:1. Clique com o botão direito do mouse no link do PDF no seu navegador.2. Clique na opção que salva o PDF localmente.3. Navegue para o diretório no qual deseja salvar o PDF.4. Clique em Salvar.

Fazendo Download do Adobe Reader

É necessário ter o Adobe Reader instalado em seu sistema para visualizar ou imprimir esses PDFs. Épossível fazer download de uma cópia gratuita a partir do website da Adobe

(http://get.adobe.com/reader/) .

© Copyright IBM Corp. 1998, 2015 1

|

||

|

|

|

|

|

|

||

||

http://get.adobe.com/reader/

Administração de Banco de DadosO DB2 for i fornece vários métodos para configurar e gerenciar bancos de dados.Conceitos relacionados:Gerenciamento de Diário

Acessando Dados Através de Interfaces do ClienteÉ possível acessar os dados do DB2 for i através de interfaces do cliente no servidor, tais como driverJava Database Connectivity (JDBC), o driver Open Database Connectivity (ODBC), o IBM i PortableApplication Solutions Environment (IBM i PASE), o OLE DB Provider, o .Net Provider, o Net.Data, ou aDistributed Relational Database Architecture (DRDA).

Acessando Dados com JavaVocê pode acessar dados do DB2 for i em seus programas Java™ utilizando o driver JDBC (Java DatabaseConnectivity) que está incluído com o programa licenciado IBM Developer Kit para Java.

O driver permite executar as seguintes tarefas:v Acessar arquivos do banco de dados.v Acessar funções do banco de dados JDBC com SQL (Linguagem de Consulta Estruturada) incorporada

para Java.v Executar instruções SQL e processar resultados.Conceitos relacionados:Acessando o Banco de Dados do System i5 com o IBM Developer Kit para Driver JDBC do Java

Acessando Dados com o DominoVocê pode utilizar o IBM Lotus Domino para i5/OS para integrar dados dos bancos de dados do DB2 fori e bancos de dados do Domino em ambas as direções.

Para obter vantagem dessa integração, você precisa entender e gerenciar como as autorizações funcionamentre os dois tipos de bancos de dados.Conceitos relacionados:Lotus Domino para i5/OS

Acessando Dados com o ODBCVocê utiliza o driver ODBC (IBM i Access para Windows Open Database Connectivity) para permitir queaplicativos clientes ODBC compartilhem efetivamente dados entre si e com o servidor.Conceitos relacionados:Administração do ODBC

Acessando Dados com o IBM i PASEO IBM i Portable Application Solutions Environment (IBM i PASE) é um ambiente de tempo de execuçãointegrado para AIX, UNIX ou outros aplicativos que estão em execução no sistema operacional do IBM i.O IBM i PASE suporta a CLI (Interface de Nível de Chamada) do DB2 for i.Conceitos relacionados:Banco de Dados

Acessando Dados com o Provedor IBM i Access para Windows OLE DBO Provedor IBM i Access para Windows OLE DB, junto com o Kit de Ferramentas do Programador,facilita o desenvolvimento de aplicativos cliente/servidor do IBM i a partir do PC do cliente MicrosoftWindows.

2 IBM i: Administração de Banco de Dados

http://www-03.ibm.com/systems/i/software/domino/

O Provedor IBM i Access para Windows OLE DB fornece interfaces de acesso no nível de registro dosprogramadores para arquivos de banco de dados do DB2 for i. Além disso, ele fornece suporte para SQL,filas de dados, programas e comandos.Referências relacionadas:Provedor OLE DB do System i Access para Windows

Acessando Dados com o IBM i Access para Windows .Net ProviderO acesso ao IBM i Access para Windows .Net Provider.

O IBM i Access para Windows .Net Provider permite o acesso ao DB2 para IBM i através da interfaceMicrosoft ADO.NET.

Acessando Dados com o Net.DataO Net.Data é um aplicativo executado em um servidor. Você pode utilizar o Net.Data para criarfacilmente documentos da Web dinâmicos que são chamados de macros da Web. As macros da Webcriadas para o Net.Data têm a simplicidade de HTML com a funcionalidade de aplicativos CGI-BIN.

O Net.Data facilita a inclusão de dados ativos em páginas da Web estáticas. Dados ativos inclueminformações que estão armazenadas em bancos de dados, arquivos, aplicativos e serviços do sistema.Conceitos relacionados:Aplicativos Net.Data para o Servidor HTTP

Acessando Dados Através de uma Partição do LinuxA IBM e vários distribuidores Linux cooperaram para integrar o sistema operacional Linux com aconfiabilidade da arquitetura IBM i.

O Linux traz uma nova geração de aplicativos baseados na Web para o produto IBM i. A IBM modificouo kernel Linux PowerPC para executar em uma partição lógica secundária e contribuiu para a volta dokernel à comunidade Linux.

Acessando Dados Utilizando o DRDA (Distributed Relational DatabaseArchitecture)Um banco de dados relacional distribuído consiste em um conjunto de objetos SQL que são espalhados entresistemas de computador interconectados. Cada banco de dados relacional tem um gerenciador de bancode dados relacional para gerenciar as tabelas em seu ambiente.

Os gerenciadores de banco de dados comunicam-se e cooperam entre si de forma que um determinadogerenciador de banco de dados acesse as instruções SQL em execução em um banco de dados relacionalem outro sistema.Referências relacionadas:Função do Banco de Dados Relacional Distribuído e SQL

Alterando e Gerenciando Objetos de Banco de DadosO DB2 for i fornece métodos SQL (Linguagem de Consulta Estruturada) e de sistema para alterar egerenciar os objetos de bancos de dados.

Há vários métodos disponíveis para trabalhar com objetos de banco de dados. É possível usar a interfaceIBM Navigator for i, instruções SQL ou comandos do IBM i.Conceitos relacionados:Tarefas de Banco de Dados do Navegador do System iReferências relacionadas:Terminologia: Acesso de Arquivo SQL versus Tradicional

Administração 3

Criando Objetos de Banco de DadosA primeira etapa no desenvolvimento do banco de dados é criar objetos que conterão os dados. Vocêpode criar tabelas, visualizações e índices com SQL. Também pode criar arquivos físicos e lógicosutilizando a interface de sistema tradicional.

Você pode criar objetos de banco de dados utilizando o IBM Navigator for i, o SQL ou a interface desistema tradicional.Conceitos relacionados:Tarefas de Banco de Dados do Navegador do System iReferências relacionadas:Terminologia: Acesso de Arquivo SQL versus Tradicional

Assegurando a Integridade dos DadosO DB2 for i fornece diversas medidas de integridade, incluindo limitações, programas do acionador econtrole de comprometimento.

Restrições, acionadores e controle de comprometimento podem proteger seu banco de dados contrainserções, exclusões e atualizações inadvertidas. As restrições dizem basicamente como os valores dedados podem ser alterados, enquanto os acionadores são ações automáticas que iniciam ou acionam umevento, como uma atualização de uma tabela específica.Conceitos relacionados:Controle de Consolidação“Trabalhando com Acionadores e Restrições” na página 25Você pode utilizar acionadores ou restrições para gerenciar dados nas tabelas de bancos de dados.

Importando e Exportando Dados entre SistemasImportar dados é o processo de recuperação de dados de origens externas, enquanto exportar dados é oprocesso de extrair dados de DB2 for i e copiá-los para outro sistema.

Importar dados para o DB2 for i pode ser um evento único ou pode ser uma tarefa contínua, comoatualizações semanais com o objetivo de fazer relatórios comerciais. Esses tipos de operações demovimentação de dados são normalmente realizados por meio das funções importar, exportar oucarregar.Conceitos relacionados:Copiando um ArquivoCopiando ArquivosCopiando Dados do Arquivo de OrigemMovendo um ArquivoTarefas relacionadas:Importando e Exportando DadosCarregando e Descarregando Dados de Sistemas Diferentes do System i

Trabalhando com Vários Bancos de DadosO sistema fornece um banco de dados do sistema (identificado como SYSBAS) e a habilidade paratrabalhar com um ou mais bancos de dados de usuários.

Os bancos de dados do usuário são implementados através do uso de conjuntos de discos independentes,que são configurados na função de gerenciamento de disco doSystem i Navigator. Depois que umconjunto de discos independente é configurado, ele é exibido como outro banco de dados na pasta Bancode dados do System i Navigator.


Quando você expande um sistema no System i Navigator e, em seguida, expande os Bancos de Dados, éexibida uma lista de bancos de dados com os quais você pode trabalhar. Para estabelecer uma conexãocom um banco de dados, expanda o banco de dados com o qual deseja trabalhar.Conceitos relacionados:Gerenciamento de Disco

Trabalhando com tabelas temporais de período do sistemaDefinir uma tabela temporal de período do sistema permite manter versões históricas de linhas da tabela.Uma tabela temporal de período do sistema armazena as versões atuais de seus dados e utiliza sua suatabela de históricos associada para armazenar versões anteriores de linhas que foram atualizadas ouexcluídas.

Uma tabela temporal de período do sistema é uma tabela SQL que pode ser criada utilizando asinstruções SQL CREATE TABLE ou ALTER TABLE. O gerenciamento de histórico para a tabela funcionapara as duas instruções SQL de Data Manipulation Language (DML) e também para operações de E/S doDB nativo. O gerenciador do banco de dados utiliza o período SYSTEM_TIME para preservar as versõeshistóricas de cada linha que é afetada por uma operação de atualização ou de exclusão. O gerenciador dobanco de dados armazena as versões históricas das linhas em uma tabela de históricos, que está associadaà tabela temporal de período do sistema. Uma tabela de alteração para incluir a versão estabelece o linkentre a tabela temporal de período do sistema e sua tabela de históricos. Ao fazer referência a apenasuma tabela temporal de período do sistema, suas consultas têm acesso a seus dados no momento atual enos momentos passados.

Tabelas Temporais de Período do SistemaUma tabela temporal de período do sistema deve ter uma coluna de tempo inicial, uma coluna de tempofinal, uma coluna de ID de início da transação e um período SYSTEM_TIME.

As colunas de tempo inicial, tempo final e ID de início da transação devem ser criadas usando a cláusulaGENERATED ALWAYS AS. Quando esta cláusula é usada, o DB2 for i mantém os valores de registro dedata e hora nessas colunas.

Coluna de tempo inicial:

A coluna de tempo inicial representa a hora em que os dados na linha se tornaram atuais. Ela é definidacomo um TIMESTAMP(12).

O gerenciador de banco de dados gera um valor para esta coluna utilizando uma leitura do relógio dosistema. Se várias linhas forem inseridas ou atualizadas em uma única transação SQL, o valor para acoluna de tempo inicial é gerado apenas uma vez, no momento da primeira instrução de mudança dedados, e é utilizado como o valor de tempo inicial para todas as operações de mudança de dados nessatransação.

Quando uma tabela existente é alterada para incluir uma coluna de tempo inicial, a coluna de tempoinicial é preenchida com o valor padrão 0001-01-01-00.00.00.000000000000 para todas as linhasexistentes.

Coluna de tempo final:

A coluna de tempo final representa a hora em que os dados na linha não eram mais atuais.

As linhas na tabela temporal de período do sistema são, por definição, atuais, portanto, a coluna detempo final é preenchida com um valor padrão, o 9999-12-30-00.00.00.000000000000. Para linhas emuma tabela de históricos, o valor na coluna de tempo final representa quando a linha foi incluída na

Administração 5

|

||||

||||||||||

|||

|||

|

||

|||||

|||

|

|

|||

tabela de históricos. Para obter mais informações sobre como este valor é definido para as linhas dotempo, consulte Atualizando os dados em uma tabela temporal de período do sistema e Excluindo dadosem uma tabela temporal de período do sistema.

Quando uma tabela existente é alterada para incluir uma coluna de tempo final, a coluna de tempo finalé preenchida com o valor padrão 9999-12-30-00.00.00.000000000000 para todas as linhas existentes.

ID de início de transação:

A coluna de ID de início de transação captura o horário da primeira operação de mudança de dados natransação.

Se várias linhas forem inseridas ou atualizadas em uma única transação SQL, então, os valores para acoluna de ID de início de transação serão os mesmos para todas as linhas e serão exclusivos dos valoresgerados para esta coluna por outras transações. Quando a coluna de ID de início da transação não fornula, é possível usá-la para identificar todas as linhas nas tabelas que foram gravadas pela mesmatransação. Se o ID de início da transação for definido para permitir o valor NULL, ele é definido para umvalor apenas quando o ID de início da transação não corresponder ao valor da coluna de tempo inicial. Adiferença entre a o ID de início da transação e a coluna de tempo inicial tem mais explicações no tópicoConflitos de valores de registro de data e hora da tabela temporal de período do sistema.

Período SYSTEM_TIME:

O período SYSTEM_TIME indica o período de tempo quando a versão de uma linha é atual.

O período SYSTEM_TIME é definido por uma coluna de tempo inicial e uma coluna de tempo final.

Tabelas de históricosCada tabela temporal de período do sistema está ligada a uma tabela de históricos. Quando uma linha éatualizada ou excluída de uma tabela temporal de período do sistema, o gerenciador de banco do dadosinsere uma cópia da linha antiga em sua tabela de históricos associada, com um registro de data e horado tempo final atualizado. Este armazenamento de dados anteriores da tabela temporal de período dosistema fornece a capacidade de recuperar dados de momentos passados.

As colunas na tabela de históricos e tabela temporal de período do sistema devem ter os mesmos exatosnomes, ordem e tipos de dados. É possível criar uma tabela de históricos com os mesmos nomes edefinições como as colunas da tabela temporal de período do sistema, usando a cláusula LIKE dainstrução CREATE TABLE. Exemplo:CREATE TABLE hist_policy_info LIKE policy_info;

Uma tabela de históricos será sujeita às seguintes regras e restrições quando o versionamento estiverativado:v Uma tabela de históricos não pode ser explicitamente eliminada. Ela só pode ser implicitamente

eliminada quando a tabela temporal do período do sistema associada for eliminada.v As colunas da tabela de históricos não podem ser explicitamente incluídas, eliminadas ou mudadas.v Uma tabela de históricos não pode ser definida como pai, filho ou de autorreferência em uma restrição

de referência.

Quando o versionamento é estabelecido, uma mudança para uma tabela temporal de período do sistemacausa uma mudança correspondente implícita na tabela de históricos. Por exemplo, se uma tabelatemporal de período do sistema é alterada para incluir uma coluna, a mesma coluna é incluída na tabelade históricos.


|||

||

|

||

||||||||

|

|

|

||||||

|||||

||

||

|

||

||||

Como excluir dados em uma tabela de históricos pode prejudicar sua habilidade de auditar o histórico dedados da tabela temporal de período do sistema, deve-se restringir o acesso a uma tabela de históricospara proteger seus dados.Referências relacionadas:CREATE TABLEALTER TABLE

Criando uma tabela temporal de período do sistemaCriar uma tabela temporal de período do sistema e uma tabela de históricos correspondente que estejamem um relacionamento de versionamento resulta em duas tabelas que controlam quando as mudanças dedados ocorrerão e preserva versões históricas desses dados.

Ao criar uma tabela temporal de período do sistema, deve-se:v Definir sua tabela nova ou existente para que ela possa ser usada como uma tabela temporal de

período do sistema:– Definindo as colunas de tempo inicial, tempo final e ID de início da transação para o gerenciador do

banco de dados usar para manter os horários histórios para cada linha.– Definindo um período SYSTEM_TIME para controlar quando uma linha é atual.

v Criar uma tabela de históricos para receber linhas antigas da tabela temporal de período do sistema.v Incluir o versionamento para estabelecer o link entre a tabela temporal de período do sistema e a

tabela de históricos.

O exemplo na seção a seguir mostra a criação de uma tabela que armazena informações de política paraos clientes de uma empresa de seguros

Para criar uma tabela temporal de período do sistema1. Crie uma tabela com as colunas de tempo inicial, tempo final e ID de início da transação e um

período SYSTEM_TIME.No exemplo a seguir, a tabela POLICY_INFO armazena informações sobre a cobertura de seguro de umcliente. As colunas do período SYSTEM_TIME, SYS_START e SYS_END, mostram quando uma linha éatual. A coluna TS_ID mostra o horário da primeira operação de mudança de dados na transação queafetou a linha.CREATE TABLE policy_info( policy_id CHAR(4) NOT NULL,coverage INT NOT NULL,sys_start TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW BEGIN,sys_end TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW END,ts_id TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS TRANSACTION START ID,PERIOD SYSTEM_TIME (sys_start, sys_end) );

2. Crie uma tabela de históricos correspondente. É possível criar uma tabela de históricos com osmesmos nomes de coluna e descrições que as colunas da tabela temporal de período do sistema,usando a cláusula LIKE da instrução CREATE TABLE. Exemplo:CREATE TABLE hist_policy_info LIKE policy_info;

3. Inclua o versionamento na tabela temporal de período do sistema para estabelecer um link com atabela de históricos. Exemplo:ALTER TABLE policy_info ADD VERSIONING USE HISTORY TABLE hist_policy_info;

Quando todas as três etapas estiverem concluídas, a tabela de históricos HIST_POLICY_INFO recebe aslinhas antigas da tabela POLICY_INFO.

A cláusula ON DELETE ADD EXTRA ROW pode ser opcionalmente especificada na instrução ALTERTABLE ADD VERSIONING. Se a cláusula for especificada, uma linha extra será inserida na tabela dehistóricos quando uma linha é excluída da tabela temporal de período do sistema. Quando a linhaadicional é gravada na tabela de históricos, os valores das colunas de expressão geradas, incluindo acoluna de tempo inicial e de tempo final, são gerados. Para obter mais informações sobre como ON

Administração 7

|||

|

|

|

||||

|

||

||

|

|

||

||

|

||

|||||||||||

||||

|||

||

|||||

DELETE ADD EXTRA ROW pode ser usado para controlar informações de auditoria, consulte Usandouma tabela temporal de período do sistema para controlar informações de auditoria.Referências relacionadas:CREATE TABLEALTER TABLE

Exemplos adicionais de CREATE TABLE da tabela temporal de período do sistema:

Exemplos adicionais incluem ocultar colunas e mudar uma tabela existente para uma tabela temporal deperíodo do sistema.

Ocultando colunas

As colunas tempo inicial, tempo final e ID de início da transação podem ser definidas como IMPLICITLYHIDDEN. As colunas definidas como IMPLICITLY HIDDEN não aparecem na lista de seleção, a menosque explicitamente referenciadas. Como os valores das colunas tempo inicial, tempo final e ID de inícioda transação são gerados pelo gerenciador do banco de dados, ocultá-las pode minimizar qualquerimpacto em seus aplicativos existentes.

Exemplo:v Uma consulta SELECT * executada com relação a uma tabela não retorna quaisquer colunas

implicitamente ocultas na tabela de resultados.v Uma instrução INSERT sem uma lista de coluna não espera que o valor padrão seja especificado para

quaisquer colunas ocultas implicitamente.

O exemplo a seguir cria a tabela POLICY_INFO com as colunas TIMESTAMP(12) SYS_START, SYS_END eTS_ID definidas como ocultas implicitamente.CREATE TABLE policy_info( policy_id CHAR(4) NOT NULL,coverage INT NOT NULL,sys_start TIMESTAMP(12) NOT NULL

GENERATED ALWAYS AS ROW BEGINIMPLICITLY HIDDEN,

sys_end TIMESTAMP(12) NOT NULLGENERATED ALWAYS AS ROW ENDIMPLICITLY HIDDEN,

ts_id TIMESTAMP(12) NOT NULLGENERATED ALWAYS AS TRANSACTION START IDIMPLICITLY HIDDEN,

PERIOD SYSTEM_TIME (sys_start, sys_end) );

Criar a tabela de históricos HIST_POLICY_INFO usando a cláusula LIKE da instrução CREATE TABLEresulta na tabela de históricos herdando o atributo oculto implicitamente da tabela POLICY_INFO. Se vocênão usar a cláusula LIKE ao criar a tabela de históricos, então, quaisquer colunas definidas como ocultasna tabela temporal de período do sistema também deverá ser definida como oculta na tabela de históricosassociada. Se as definições de coluna não corresponderem, você não será capaz de incluir oversionamento.

Mudando uma tabela existente para uma tabela temporal de período do sistema

No exemplo a seguir, as três colunas de registro de data e hora e um período SYSTEM_TIME sãoincluídas na tabela existente, EMPLOYEES, preparando-a para ser usada como uma tabela temporal deperíodo do sistema.ALTER TABLE employeesADD COLUMN sys_start TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW BEGINADD COLUMN sys_end TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW ENDADD COLUMN ts_id TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS TRANSACTION START IDADD PERIOD SYSTEM_TIME(sys_start, sys_end);


||

|

|

|

|

||

|

|||||

|

||

||

|||||||||||||||

||||||

|

||||||||

Uma tabela de históricos deve ser criada e o versionamento incluído para terminar de ativar o rastreio delinhas do tempo.

Inserindo dados em uma tabela temporal de período do sistemaInserir dados em uma tabela temporal de período do sistema é semelhante a inserir dados em uma tabelacomum.

O gerenciador do banco de dados gera automaticamente os valores das colunas de registro de data e horade tempo inicial e tempo final quandos os dados são inseridos em uma tabela temporal de período dosistema. O gerenciador do banco de dados também gera o valor de ID de início da transação queidentifica exclusivamente a transação que está inserindo a linha.

Neste exemplo, os seguintes dados foram inseridos em 31 de janeiro de 2015 (31-01-2015) na tabela criadano exemplo em Criando uma tabela temporal de período do sistema.

Insira três linhas na tabela POLICY_INFO.INSERT INTO policy_info (policy_id, coverage)VALUES(’A123’,12000);

INSERT INTO policy_info (policy_id, coverage)VALUES(’B345’,18000);

INSERT INTO policy_info (policy_id, coverage)VALUES(’C567’,20000);

A tabela POLICY_INFO agora contém os dados de cobertura de seguro na tabela a seguir. As entradas decolunas SYS_START, SYS_END e TS_ID foram geradas pelo gerenciador do banco de dados.

Tabela 1. Dados na tabela temporal de período do sistema, POLICY_INFO, depois das instruções INSERT

POLICY_ID COVERAGE SYS_START SYS_END TS_ID

A123 12000 2015-01-31-22.31.33.495925000000

9999-12-30-00.00.00.000000000000

2015-01-31-22.31.33.495925000000

B345 18000 2015-01-31-22.31.33.495925000000

9999-12-30-00.00.00.000000000000

2015-01-31-22.31.33.495925000000

C567 20000 2015-01-31-22.31.33.495925000000

9999-12-30-00.00.00.000000000000

2015-01-31-22.31.33.495925000000

Os valores de registro de data e hora SYS_START são os mesmos para todas as três linhas inseridasrecentemente porque, neste exemplo, as linhas foram inseridas como parte da mesma transação.

A tabela de históricos HIST_POLICY_INFO permanecerá vazia porque nenhuma linha do tempo é geradapor uma inserção.

A coluna de tempo inicial, SYS_START, representa o horário em que a linha se tornou atual. O gerenciadordo banco de dados gera esse valor usando uma leitura do relógio do sistema no momento em que eleexecuta a primeira instrução de mudança de dados na transação que gera a linha. O gerenciador dobanco de dados também gera a coluna de ID de início da transação TS_ID, que captura o horário quandoa execução iniciou para uma transação que afeta a linha. Na maioria dos casos, os valores de registro dedata e hora para essas duas colunas são os mesmos, porque eles são resultados da execução da mesmatransação. Se a coluna de ID de início da transação for definida para permitir o valor NULL, ele seráNULL quando o valor da coluna de ID de início da transação for idêntico à coluna de tempo inicial.

Quando várias transações estão atualizando a mesma linha, podem ocorrer conflitos de registro de data ehora. O gerenciador do banco de dados pode resolver esses conflitos, ajustando os valores de registro dedata e hora da coluna de tempo inicial. Em tais casos, os valores na coluna de tempo inicial e na colunade ID de início da transação diferem. O tópico Conflitos de valor de registro de data e hora da tabelatemporal de período do sistema fornece mais detalhes sobre ajustes de registro de data e hora.

Administração 9

||

|||

||||

||

|||||||||

||

||

|||||

||||||||

||||||||

|||||||||

||

||

||||||||

|||||

Referências relacionadas:INSERT

Atualizando dados em uma tabela temporal de período do sistemaA atualização de dados em uma tabela temporal de período do sistema resulta em linhas incluídas natabela de históricos associada da tabela temporal de período do sistema.

Além disso, para atualizar os valores em linhas da tabela temporal de período do sistema, a instruçãoUPDATE faz com que o gerenciador do banco de dados insira uma cópia da linha existente na tabela dehistóricos associada. A linha do tempo é gerada como parte da mesma transação que atualiza a linha. Seuma única transação atualiza a mesma linha várias vezes, apenas uma linha do tempo será gerada, e essalinha reflete o estado do registro antes de quaisquer mudanças feitas pela transação.

No exemplo a seguir, a cobertura de seguro de um cliente é aumentada em 28 de fevereiro de 2016(28-02-2016). Este exemplo usa a tabela criada em Criando uma tabela temporal de período do sistemacom linhas que foram incluídas em Inserindo dados em uma tabela temporal de período do sistema.

A tabela a seguir contém os dados da tabela POLICY_INFO antes da atualização.

Tabela 2. Dados na tabela temporal de período do sistema POLICY_INFO, antes da instrução UPDATE


A123 12000 2015-01-31-22.31.33.495925000000

9999-12-30-00.00.00.000000000000

2015-01-31-22.31.33.495925000000

B345 18000 2015-01-31-22.31.33.495925000000

9999-12-30-00.00.00.000000000000

2015-01-31-22.31.33.495925000000

C567 20000 2015-01-31-22.31.33.495925000000

9999-12-30-00.00.00.000000000000

2015-01-31-22.31.33.495925000000

Atualize a cobertura para a política C567 para 25000.UPDATE policy_infoSET coverage = 25000WHERE policy_id = ’C567’;

A atualização para a política C567 afeta a tabela temporal de período do sistema e sua tabela dehistóricos, fazendo com que o seguinte ocorra:1. O valor de cobertura para a linha com a política C567 é atualizado para 25000.2. Na tabela temporal de período do sistema, o gerenciador do banco de dados atualiza os valores

SYS_START e TS_ID para o registro de data e hora da atualização, e o valor SYS_END fica inalterado.3. A linha original é inserida na tabela de históricos. O gerenciador do banco de dados atualiza o valor

SYS_END para o registro de data e hora da atualização. Esta linha pode ser interpretada como acobertura válida para a política C567 de 2015-01-31-22.31.33.495925000000 para 2016-02-28-09.10.12.649592000000.

Tabela 3. Dados na tabela temporal de período do sistema, POLICY_INFO, após a instrução UPDATE


A123 12000 2015-01-31-22.31.33.495925000000

9999-12-30-00.00.00.000000000000

2015-01-31-22.31.33.495925000000

B345 18000 2015-01-31-22.31.33.495925000000

9999-12-30-00.00.00.000000000000

2015-01-31-22.31.33.495925000000

C567 25000 2016-02-28-09.10.12.649592000000

9999-12-30-00.00.00.000000000000

2016-02-28-09.10.12.649592000000


|

|

|||

|||||

|||

|

||

|||||

||||||||

||||||||

|||||||||

||||

||

|

||

||||

||

|||||

||||||||

||||||||

|||||||||

Tabela 4. Dados na tabela de históricos, HIST_POLICY_INFO, após a instrução UPDATE


C567 20000 2015-01-31-22.31.33.495925000000

2016-02-28-09.10.12.649592000000

2015-01-31-22.31.33.495925000000

Se uma ou mais atualizações ocorrerem durante a execução sob o controle de compromisso, e o usuáriorecuperar a transação, então, as atualizações para a tabela temporal de período do sistema e as inserçõesna tabela de históricos são recuperadas.

Quando várias transações estão atualizando a mesma linha, podem ocorrer conflitos de registro de data ehora. Quando esses conflitos ocorrerem, a configuração para a opção SYSTIME_PERIOD_ADJ QAQQINIdetermina se os ajustes registro de data e hora são feitos ou se a transação falha. O tópico Conflitos devalor de registro de data e hora da tabela temporal de período do sistema fornece mais detalhes sobreajustes de registro de data e hora. Os programadores de aplicativos podem considerar o uso dos valoresSQLCODE ou SQLSTATE para manipular os códigos de retorno relacionados ao ajuste do valor deregistro de data e hora a partir das instruções de atualização SQL.Referências relacionadas:ATUALIZAR

Excluindo dados em uma tabela temporal de período do sistemaA exclusão de uma linha de uma tabela temporal de período do sistema remove a linha da tabela e incluiuma ou duas linhas na tabela de históricos associada. A instrução DELETE copia a linha existente natabela de históricos associada antes que a linha seja excluída da tabela temporal de período do sistema.As linhas na tabela de históricos são incluídas com os registros de data e hora do sistema apropriados.

No exemplo a seguir, o proprietário da política B345 decide cancelar a cobertura de seguro. Os dadospara o cliente foram excluídos no dia 1 de setembro de 2016 (01-09-2016) da tabela de exemplo criada notópico Criando uma tabela temporal de período do sistema e atualizados no tópicoAtualizando os dadosem uma tabela temporal de período do sistema.

A tabela a seguir contém os dados da tabela POLICY_INFO antes da exclusão.

Tabela 5. Dados na tabela temporal de período do sistema, POLICY_INFO, antes da instrução DELETE


A123 12000 2015-01-31-22.31.33.495925000000

9999-12-30-00.00.00.000000000000

2015-01-31-22.31.33.495925000000

B345 18000 2015-01-31-22.31.33.495925000000

9999-12-30-00.00.00.000000000000

2015-01-31-22.31.33.495925000000

C567 25000 2016-02-28-09.10.12.649592000000

9999-12-30-00.00.00.000000000000

2016-02-28-09.10.12.649592000000

A instrução a seguir exclui as informações de política para o ID de política B345.DELETE FROM policy_info WHERE policy_id = ’B345’;

A exclusão da política B345 afeta a tabela temporal de período do sistema e sua tabela de históricos,fazendo com que o seguinte ocorra:1. A linha original é copiada para a tabela de históricos. O gerenciador do banco de dados atualiza o

valor da coluna SYS_END para o registro de data e hora da primeira operação de mudança de dados natransação.

2. A linha na qual o valor da coluna policy_id é B345 é excluída da tabela temporal de período dosistema.

Administração 11

||

|||||

|||||||||

|||

|||||||

|

|

|||||

||||

|

||

|||||

||||||||

||||||||

|||||||||

||

||

|||

||

Tabela 6. Dados na tabela temporal de período do sistema, POLICY_INFO, após a instrução DELETE


A123 12000 2015-01-31-22.31.33.495925000000

9999-12-30-00.00.00.000000000000

2015-01-31-22.31.33.495925000000

C567 25000 2016-02-28-09.10.12.649592000000

9999-12-30-00.00.00.000000000000

2016-02-28-09.10.12.649592000000

Tabela 7. Dados na tabela de históricos HIST_POLICY_INFO após a instrução DELETE


C567 20000 2015-01-31-22.31.33.495925000000

2016-02-28-09.10.12.649592000000

2015-01-31-22.31.33.495925000000

B345 18000 2015-01-31-22.31.33.495925000000

2016-09-01-12.18.22.959254000000

2015-01-31-22.31.33.495925000000

Referências relacionadas:EXCLUIR

Usando uma tabela temporal de período do sistema para controlar informações deauditoriaUma trilha de auditoria das mudanças que foram feitas para a tabela temporal de período do sistemapode se tornar mais informativa com a adição de um ou mais colunas de expressão geradas.

Alguns exemplos de informações de auditoria que podem ser controladas sãov quando os dados foram modificadosv quem modificou os dadosv qual operação SQL modificou os dados.

Para controlar quando os dados foram modificados, defina a tabela como uma tabela temporal deperíodo do sistema. Para controlar quem e qual instrução SQL modificou os dados, use uma coluna deexpressão gerada. Para obter mais informações sobre colunas de expressão geradas disponíveis, consulteCREATE TABLE.

No exemplo a seguir, a tabela POLICY_INFO contém duas colunas extras. AUDIT_USER controla quemmodificou os dados usando o registro especial SESSION USER. AUDIT_OP controla a operação SQL quemodificou os dados usando a DATA CHANGE OPERATION.

CREATE TABLE policy_info(policy_id CHAR(4) NOT NULL,coverage INT NOT NULL,audit_user VARCHAR(128) GENERATED ALWAYS AS (SESSION USER),audit_op CHAR(1) GENERATED ALWAYS AS (DATA CHANGE OPERATION),sys_start TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW BEGIN,sys_end TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW END,ts_id TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS TRANSACTION START ID,PERIOD SYSTEM_TIME (sys_start, sys_end) );

CREATE TABLE hist_policy_info LIKE policy_info;

ALTER TABLE policy_info ADD VERSIONING USE HISTORY TABLE hist_policy_infoON DELETE ADD EXTRA ROW;

Cada linha na tabela temporal do sistema e sua tabela de históricos correspondente rastreia se a linha foimudada por uma operação de inserção, atualização ou exclusão, e o nome do usuário que modificou alinha pela última vez.


||

|||||

||||||||

|||||||||

||

|||||

||||||||

|||||||||

|

|

||||

|

|

|

|

||||

|||||||||||||||||

|||

ON DELETE ADD EXTRA ROW

Se a clásula ON DELETE ADD EXTRA ROW for especificada na instrução ALTER TABLE ADDVERSIONING, uma linha extra será inserida na tabela de históricos quando uma linha é excluída de umatabela temporal de período do sistema. Esta linha adicional contém informações sobre a própria operaçãode exclusão.

O exemplo a seguir ilustra o valor de ON DELETE ADD EXTRA ROW. Este exemplo mostra uma série de trêstransações. Em junho de 2014, USER1 insere uma linha na tabela do POLICY_INFO. Então, em janeiro de2015, USER2 atualiza a linha. Finalmente, em agosto de 2015, USER3 exclui a linha:INSERT INTO policy_info (policy_id, coverage)VALUES (’A123’,12000);

UPDATE policy_infoSET coverage = 25000WHERE policy_id = ’A123’

DELETE FROM policy_infoWHERE policy_id = 'A123'

Sem a cláusula ON DELETE ADD EXTRA ROW, essa série de transações gravaria somente as seguintesduas entradas na tabela de históricos. A primeira entrada registra a linha como era antes de o USER2 terfeito sua atualização, e a segunda entrada registra a linha como ela era antes de o USER3 ter feito aexclusão. A operação de exclusão de registra a linha como existia na tabela temporal na última vez. Sem acláusula ON DELETE ADD EXTRA ROW, não há registro de auditoria da própria operação de exclusão.

Tabela 8. Dados na tabela de históricos, HIST_POLICY_INFO, após a instrução DELETE quando ON DELETE ADD EXTRAROW não for especificado

POLICY_ID COVERAGE AUDIT_USER AUDIT_OP SYS_START SYS_END TS_ID

A123 12000 USER1 T 2014-06-31-22.31.33.495925

2015-01-31-22.31.33.857632

2014-06-31-22.31.33.495925

A123 25000 USER2 i 2015-01-31-22.31.33.857632

2015-08-31-22.31.33.634521

2015-01-31-22.31.33.857632

Com a cláusula DELETE ADD EXTRA ROW incluída na instrução ADD VERSIONING, uma linha extragravada na tabela de históricos. Como os valores de tempo inicial e tempo final são gerados para a linhaextra, eles são o mesmo valor de registro de data e hora. Este registro de data e hora tambémcorresponde ao valor de tempo final da primeira linha inserida para a exclusão. Na tabela a seguir, essalinha adicional é mostrada:

Tabela 9. Os dados na tabela de históricos, HIST_POLICY_INFO, após a instrução DELETE, quando ON DELETE ADDEXTRA ROW é especificado

POLICY_ID COVERAGE AUDIT_USER AUDIT_OP SYS_START SYS_END TS_ID

A123 12000 USER1 T 2014-06-31-22.31.33.495925

2015-01-31-22.31.33.857632

2014-06-31-22.31.33.495925

A123 25000 USER2 i 2015-01-31-22.31.33.857632

2015-08-31-22.31.33.634521

2015-01-31-22.31.33.857632

A123 25000 USER3 d 2015-08-31-22.31.33.634521

2015-08-31-22.31.33.634521

2015-08-31-22.31.33.634521

Referências relacionadas:Criando colunas de auditoria

Administração 13

|

||||

||||||||||||

|||||

|||

|||||||

||||||||||

|||||||||||

|||||

|||

|||||||

||||||||||

||||||||||

|||||||||||

|

|

Conflitos de valor de registro de data e hora da tabela temporal de período dosistemaO gerenciador do banco de dados irá impedir que uma linha do tempo de uma tabela temporal deperíodo do sistema seja gerada com um registro de data e hora de tempo final menor do que o registrode data e hora de tempo inicial. Esse tipo de conflito pode ocorrer quando várias transações atualizarama mesma linha de uma tabela temporal de período do sistema.

Um cenário de exemplo é mostrado na tabela abaixo. Os registros de data e hora para este exemploforam simplificados como um item temporário, em vez de uma leitura do relógio do sistema de amostra.

Tabela 10. Transações simultâneas em uma tabela temporal de período do sistema

Data e HoraAtuais Transação A

TransaçãoA, valorSYS_START Transação B

TransaçãoB, valorSYS_START

T1 INSERT INTOpolicy_info (policy_id,

coverage)VALUES (’S777’,7000)

T1

T2 INSERT INTOpolicy_info (policy_id,

coverage)VALUES (’T888’,8000)

T2

T3 COMMIT T2

T4 UPDATE policy_infoSET policy_id = ’X999’WHERE policy_id = ’T888’

T1

T5 COMMIT T1

Quando várias linhas são inseridas ou atualizadas na mesma transação, a coluna de tempo inicial é amesma para todas as linhas afetadas. O valor para o início da linha vem de uma leitura do relógio dosistema no momento da primeira mudança de dados na transação. Na tabela acima, todas as linhasinseridas ou atualizadas pela transação A possuem um registro de data e hora de tempo inicial de T1, e alinha inserida pela transação B possui um registro de data e hora de tempo inicial de T2. No tempo T3, ainserção da linha dois é confirmada com um registro de data e hora de tempo inicial de T2.

Quando a transação A atualiza a linha em que o POLICY_ID é igual a 'T888' no tempo T4, o registroatualizado de data e hora de tempo inicial da linha é mudado para T1 porque a atualização ocorreu natransação A. A linha original é inserida na tabela de históricos e o valor do registro de data e hora detempo final para a linha do tempo é atualizado para corresponder ao valor de registro de data e hora detempo inicial da linha atualizada, T1. O valor de tempo inicial da linha do tempo é T2. Isso resultaria emuma linha do tempo com um valor de registro de data e hora de tempo final, T1, que é anterior ao seuvalor de registro de data e hora de tempo inicial, T2. Isso não é permitido.

A opção SYSTIME_PERIOD_ADJ QAQQINI determina qual ação o sistema executa quando uma linha dotempo possui um registro de data e hora de tempo final que é menor que o registro de data e hora detempo inicial. O valor QAQQINI pode ser configurado para *ERROR ou *ADJUST, com *ERROR sendo ovalor padrão. Quando *ERROR é utilizado, um erro com SQLCODE -20528 e SQLSTATE 57062 seráretornado quando o valor de registro de data e hora de tempo final for menor que o valor de registro dedata e hora de tempo inicial. Quando *ADJUST é utilizado, um ajuste é feito para o valor de registro dedata e hora de tempo inicial e o registro de data e hora de tempo final, em vez de retornar um erro. Emtais casos, os valores na coluna inicial da linha e a coluna de ID de início da transação serão diferentes.Para obter mais informações sobre a opção SYSTIME_PERIOD_ADJ QAQQINI, consulte Desempenho eotimização de consulta.


||||||

||

||

|||

||||

|||

|||||

|||

|||||||

|

|||||

||||

|||

||||||

||||||

|||||||

||||||||||

Outro exemplo de quando esta situação pode ocorrer é quando o relógio do sistema é ajustado. Isso podeacontecer ao mudar o horário da conta para o horário de verão. Como no caso anterior, o valor da opçãoQAQQINI deve determinar se um erro é retornado ou se os valores de registro de data e hora sãoajustados.

Consultando os dados temporais do período do sistemaConsultar uma tabela temporal de período do sistema pode retornar resultados para um determinadoponto ou período no tempo. Os resultados podem incluir valores atuais e valores históricos anteriores.

Para consultar uma tabela temporal, é possível especificar os critérios de tempo de várias maneiras:v em uma consulta usando explicitamente uma especificação de período SYSTEM_TIME,v em uma consulta usando implicitamente o registro do sistema CURRENT TEMPORAL SYSTEM_TIME,

ouv em uma definição de visualização.

Especificando os critérios de tempo em uma consulta:

Ao consultar uma tabela temporal de período do sistema, é possível incluir FOR SYSTEM_TIME nacláusula FROM para consultar o estado atual e passado de seus dados.

Os períodos de tempo podem ser especificados de três maneiras:v valorAS OF

Inclui cada linha para a qual o valor de tempo inicial é menor ou igual ao valor e o valor de tempofinal é maior que valor. Zero linhas são retornadas se o valor for o valor nulo.

v FROM value1 TO value2

Inclui linhas que existem completamente dentro do período que é especificado de value1 a value2. Umalinha é incluída se o valor de tempo inicial for menor que value2 e o valor de tempo final for maiorque value1. Zero linhas são retornadas se value1 for maior ou igual a value2, ou se value1 ou value2forem o valor nulo.

v BETWEEN value1 AND value2

Inclui linhas que se sobrepõem em qualquer momento entre value1 e value2. Uma linha é incluída seseu valor de tempo inicial for menor ou igual a value2 e se o valor de tempo final for maior que value1.Zero linhas são retornadas se value1 for maior que value2, ou se value1 ou value2 forem o valor nulo. Sevalue1 = value2, a expressão será equivalente a AS OF value1.

Para obter informações detalhadas sobre períodos de tempo, consulte referência de tabela e Consultas.Referências relacionadas:SELECT

Exemplo: critérios de tempo na consulta:

Essas consultas de amostra solicitam informações de política a partir de uma tabela temporal de períododo sistema. Cada consulta usa uma variação da especificação FOR SYSTEM_TIME.

A tabela temporal POLICY_INFO e sua tabela de históricos associada que é usada nos exemplos contêmestas linhas:

Tabela 11. Tabela temporal de período do sistema POLICY_INFO


A123 12000 2015-01-31-22.31.33.495925000000

9999-12-30-00.00.00.000000000000

2015-01-31-22.31.33.495925000000

C567 25000 2016-02-28-09.10.12.649592000000

9999-12-30-00.00.00.000000000000

2016-02-28-09.10.12.649592000000

Administração 15

||||

|||

|

|

||

|

|

||

|

|

||

|

||||

|

||||

|

|

|

|

||

||

||

|||||

||||||||

||||||||

Tabela 12. Tabela de históricos HIST_POLICY_INFO


C567 20000 2015-01-31-22.31.33.495925000000

2016-02-28-09.10.12.649592000000

2015-01-31-22.31.33.495925000000

B345 18000 2015-01-31-22.31.33.495925000000

2016-09-01-12.18.22.959254000000

2015-01-31-22.31.33.495925000000

vConsulta sem período especificadoSELECT policy_id, coverage, sys_start, sys_endFROM policy_infoWHERE policy_id = ’C567’

Esta consulta retorna uma linha. A instrução SELECT consulta apenas a tabela POLICY_INFO. A tabela dehistóricos não é consultada porque FOR SYSTEM_TIME não foi especificado.

Tabela 13. Resultado da consulta sem período especificado

POLICY_ID COVERAGE SYS_START SYS_END

C567 25000 2016-02-28-09.10.12.649592000000

9999-12-30-00.00.00.000000000000

vConsulta com a cláusula FOR SYSTEM_TIME AS OF especificadaSELECT policy_id, coverage, sys_start, sys_endFROM policy_infoFOR SYSTEM_TIME AS OF ’2016-02-28-09.10.12.649592000000’

Essa consulta retorna três linhas. A instrução SELECT consulta as tabelas POLICY_INFO eHIST_POLICY_INFO. A coluna de tempo inicial do período é inclusiva, enquanto a coluna de tempo finalé exclusiva. A linha da tabela de históricos com um valor de coluna SYS_END de 2016-02-28-09.10.12.649592000000 é igual ao valor AS OF, mas deve ser menor do que o valor a ser retornado

Tabela 14. Resultado da consulta com um período FOR SYSTEM_TIME AS OF especificado


A123 12000 2015-01-31-22.31.334959250000

9999-12-30-00.00.00.000000000000

C567 25000 2016-02-28-09.10.12.649592000000

9999-12-30-00.00.00.000000000000

B345 18000 2015-01-31-22.31.33.495925000000

2016-09-01-12.18.22.959254000000

vConsulta com FOR SYSTEM_TIME FROM...TO especificado.SELECT policy_id, coverage, sys_start, sys_endFROM policy_infoFOR SYSTEM_TIME FROM ’0001-01-01-00.00.00.000000000000’

TO ’9999-12-30-00.00.00.000000000000’WHERE policy_id = ’C567’

Essa consulta retorna duas linhas. A instrução SELECT consulta as tabelas POLICY_INFO eHIST_POLICY_INFO.

Tabela 15. Resultado da consulta com FOR SYSTEM_TIME FROM...TO especificado.


C567 25000 2016-02-28-09.10.12.649592000000

9999-12-30-00.00.00.000000000000


|

||

|||||

||||||||

|||||||||

|

||||

||

||

||||

|||||||

|

||||

||||

||

||||

||||||

||||||

|||||||

|

||||||

||

||

||||

||||||

Tabela 15. Resultado da consulta com FOR SYSTEM_TIME FROM...TO especificado. (continuação)


C567 20000 2015-01-31-22.31.33.495925000000

2016-02-28-09.10.12.649592000000

vConsulta com FOR SYSTEM_TIME BETWEEN...AND especificado.SELECT policy_id, coverageFROM policy_infoFOR SYSTEM_TIME BETWEEN ’2016-02-28-09.10.12.649592000000’

AND ’9999-12-30-00.00.00.000000000000’

Essa consulta retorna três linhas. A instrução SELECT consulta as tabelas POLICY_INFO eHIST_POLICY_INFO. As linhas com um valor de coluna SYS_START de 2016-02-28-09.10.12.649592000000são iguais ao value1 e são retornadas porque o horário de início de um período é incluído. As linhascom um valor de coluna SYS_END de 2016-02-28-09.10.12.649592000000 são iguais a value1 e não sãoretornadas porque o horário de encerramento de um período não é incluído.

Tabela 16. Resultado da consulta com FOR SYSTEM_TIME BETWEEN...AND especificado.

POLICY_ID COVERAGE

A123 12000

C567 25000

B345 18000

Especificando os critérios de tempo usando o registro especial CURRENT TEMPORALSYSTEM_TIME:

Usar o registro especial CURRENT TEMPORAL SYSTEM_TIME para especificar o tempo AS OF parauma consulta pode reduzir ou eliminar as mudanças que são necessárias para executar um aplicativo emmomentos diferentes.

Quando você tem um aplicativo que deseja executar em uma tabela temporal de período do sistema paraconsultar o estado de seus dados para várias datas diferentes, é possível configurar a data em um registroespecial. Se você precisar consultar os dados a partir de hoje, desde o final do último trimestre ou a partirda mesma data do ano passado, poderá não ser possível mudar o aplicativo para incluir especificaçõesAS OF para cada instrução SQL. Esta restrição é provavelmente o caso em que você está usandoaplicativos empacotados. Para abordar tais cenários, é possível usar o registro especial SYSTEM_TIMETEMPORALCURRENT para configurar o registro de data e hora no nível da tarefa.

Configurar o registro especial SYSTEM_TIME TEMPORAL CURRENT não afeta as tabelas não temporais.Apenas consultas em tabelas temporais com versionamento ativado usam o tempo definido no registroespecial. Não há impacto também nas instruções DDL.

Quando o registro especial CURRENT TEMPORAL SYSTEM_TIME é configurado como um valor nãonulo, os aplicativos que emitem uma consulta em qualquer tabela temporal de período do sistema retornadados a partir dessa data ou registro de data e hora.

Quando o registro especial CURRENT TEMPORAL SYSTEM_TIME é configurado como um valor nãonulo, as instruções de modificação de dados, como INSERT, UPDATE e DELETE na tabela temporal deperíodo do sistema são bloqueadas, porque, se o registro especial for configurado para algum momentono passado, por exemplo, há cinco anos, então, permitir as operações de modificação de dados poderesultar em mudanças em seus registros de dados históricos. Modificar a tabela de históricos não épermitido.

Administração 17

|

||||

|||||||

|

|||||

|||||

||

||

||

||

|||

||

|||

|||||||

|||

|||

||||||

Os comandos do pré-compilador CRTSQLxxx possuem uma opção sensível à hora do sistema, que indicase as referências às tabelas temporais de período do sistema em instruções SQL estáticas e dinâmicas sãoafetadas pelo valor do registro especial CURRENT TEMPORAL SYSTEM_TIME. Esse comportamentopode também ser especificado para os programas SQL, procedimentos ou funções pela opção SYSTIMEna instrução SET OPTION. O padrão é *SYSTIME. Todos os programas SQL e programas de serviço queforam criados antes do 7.3 são considerados *NOSYSTIME. Quando o valor for *SYSTIME, o registroespecial será aplicado às instruções que fazem referência às tabelas temporais de período do sistema.Quando o valor for *NOSYSTIME, o registro especial será ignorado.Referências relacionadas:CURRENT TEMPORAL SYSTEM_TIME

Exemplo: critérios de tempo especificados usando o registro especial CURRENT TEMPORAL SYSTEM_TIME:

Essas consultas de amostra solicitam informações de política de uma tabela temporal de período dosistema para um momento específico, usando o registro especial CURRENT TEMPORAL SYSTEM_TIME.

A tabela temporal POLICY_INFO e sua tabela de históricos associada que é usada nos exemplos são:



A123 12000 2015-01-31-22.31.33.495925000000

9999-12-30-00.00.00.000000000000

2015-01-31-22.31.33.495925000000

C567 25000 2016-02-28-09.10.12.649592000000

9999-12-30-00.00.00.000000000000

2016-02-28-09.10.12.649592000000



C567 20000 2015-01-31-22.31.33.495925000000

2016-02-28-09.10.12.649592000000

2015-01-31-22.31.33.495925000000

B345 18000 2015-01-31-22.31.33.495925000000

2016-09-01-12.18.22.959254000000

2015-01-31-22.31.33.495925000000

vExemplo 1: Configure o registro especial CURRENT, TEMPORAL SYSTEM_TIME para um ano anteriorao registro de data e hora. Suponha um registro de data e hora atual de 2016-05-17-14.45.31.434235000000.SET CURRENT TEMPORAL SYSTEM_TIME = CURRENT TIMESTAMP – 1 YEAR;

A consulta a seguir da tabela temporal de período do sistema retorna resultados a partir de um anoatrás.SELECT policy_id, coverage FROM policy_info;

Como POLICY_INFO é uma tabela temporal de período do sistema e o registro especial CURRENTTEMPORAL SYSTEM_TIME não é nulo, a consulta é executada como:SELECT policy_id, coverage FROM policy_infoFOR SYSTEM_TIME AS OF CURRENT TEMPORAL SYSTEM_TIME;

A instrução SELECT consulta as tabelas POLICY_INFO e HIST_POLICY_INFO, e retorna:

Tabela 19. Resultado de consulta com um registro especial configurado.

POLICY_ID COVERAGE

A123 12000

C567 20000

B345 18000


||||||||

|

|

|

||

|

||

|||||

||||||||

|||||||||

||

|||||

||||||||

|||||||||

|

||||

|||

||||

|

||

||

||

||

|||

vExemplo 2: Configure o registro especial CURRENT, TEMPORAL SYSTEM_TIME para um registro dedata e hora, e referencie uma tabela temporal de período do sistema nas definições de visualização.CREATE VIEW coverage AS SELECT policy_id, coverage FROM policy_info;

SET CURRENT TEMPORAL SYSTEM_TIME = TIMESTAMP(’2016-02-28-09.10.12.649592000000’);

SELECT * FROM coverage;

Como a visualização faz referência a POLICY_INFO, que é uma tabela temporal de período do sistema, eo CURRENT TEMPORAL SYSTEM_TIME está configurado, a referência de tabela na visualizaçãopossui FOR SYSTEM_TIME AS OF CURRENT TEMPORAL SYSTEM_TIME implicitamente incluído nele. Ainstrução SELECT consulta as tabelas POLICY_INFO e HIST_POLICY_INFO, e retorna:

Tabela 20. Resultado de consulta com um registro especial configurado.

POLICY_ID COVERAGE

A123 12000

C567 25000

B345 18000

v Exemplo 3: Configure o registro especial CURRENT TEMPORAL SYSTEM_TIME e faça referência auma tabela temporal de período do sistema em uma subseleção.CREATE VIEW customer_policy AS SELECT * FROM customer_infoWHERE cust_policy_id IN (SELECT policy_id FROM policy_info);

SET CURRENT TEMPORAL SYSTEM_TIME = TIMESTAMP(’2016-02-28-09.10.12.649592000000’);

SELECT * FROM customer_policy;

A consulta neste exemplo envolve uma visualização em uma tabela não temporal de período dosistema que faz referência a uma tabela temporal de período do sistema.O registro especial CURRENT TEMPORAL SYSTEM TIME é aplicado a todas as tabelas temporais deperíodo do sistema em uma visualização. Ele é ignorado para qualquer outra referência de tabela. Paraesta consulta de uma visualização, FOR SYSTEM_TIME AS OF CURRENT TEMPORAL SYSTEM TIME éimplicitamente incluído na referência de tabela POLICY_INFO.

v Exemplo 4: Configure o registro especial e execute uma consulta que contém uma especificação deperíodo. Esta é uma consulta inválida.SET CURRENT TEMPORAL SYSTEM_TIME = CURRENT TIMESTAMP - 1 YEAR;

SELECT * FROM policy_info FOR SYSTEM_TIME AS OF TIMESTAMP(’2016-02-28-09.10.12.649592000000’);

Um erro é retornado porque há várias especificações de período. O registro especial foi definido paraum valor não nulo e a consulta também especificou um horário. Quando a consulta usa uma cláusulaFOR SYSTEM_TIME, o registro especial CURRENT TEMPORAL SYSTEM_TIME deve ser o valorNULL.

Especifique os critérios de tempo para uma visualização:

Uma especificação de período A FOR SYSTEM_TIME que segue o nome de uma visualização em umareferência de tabela se aplica a todas as referências de tabela temporal de período do sistema na definiçãodessa visualização. Se a visualização não acessa nenhuma tabela temporal, a especificação do período nãoentra em vigor na tabela de resultados da visualização.

Uma referência de visualização seguida por uma especificação de período não deve incluir uma funçãoexterna que não seja NO SQL, ou uma função SQL que não seja capaz sequencialmente.

Para consultar uma visualização que faz referência a uma tabela temporal, use um dos seguintesmétodos:v Especifique uma especificação de período SYSTEM_TIME seguindo o nome de uma visualização na

cláusula FROM de uma consulta.

Administração 19

|

|||||||

||||

||

||

||

||

|||

||||||||

||

||||

|||||

||||

|

||||

||

||

||

v Use o registro especial CURRENT TEMPORAL SYSTEM_TIME. Neste caso, não se deve incluir umaespecificação de período na consulta.

Exemple: critérios de tempo na visualização:

Essas consultas de amostra solicitam informações de política a partir de uma visualização criada em umatabela temporal de período do sistema.

A tabela temporal POLICY_INFO e sua tabela de históricos associada que é usada nos exemplos são:



A123 12000 2015-01-31-22.31.33.495925000000

9999-12-30-00.00.00.000000000000

2015-01-31-22.31.33.495925000000

C567 25000 2016-02-28-09.10.12.649592000000

9999-12-30-00.00.00.000000000000

2016-02-28-09.10.12.649592000000



C567 20000 2015-01-31-22.31.33.495925000000

2016-02-28-09.10.12.649592000000

2015-01-31-22.31.33.495925000000

B345 18000 2015-01-31-22.31.33.495925000000

2016-09-01-12.18.22.959254000000

2015-01-31-22.31.33.495925000000

Exemplo 1: crie uma visualização COVERAGE que faz referência à tabela temporal de período do sistemaPOLICY_INFO. Em seguida, consulte a visualização e identifique uma especificação de período FORSYSTEM_TIME para retornar linhas que eram atuais a partir de um ano atrás. Suponha um registro dedata e hora atual de 2016-05-17-14.45.31.434235000000.CREATE VIEW coverage ASSELECT policy_id, coverageFROM policy_info;

SELECT * FROM coverageFOR SYSTEM_TIME AS OF CURRENT TIMESTAMP - 1 YEAR;

A instrução SELECT consulta as tabelas POLICY_INFO e HIST_POLICY_INFO, e retorna:

Tabela 23. Resultado da consulta de uma visualização que tem uma especificação de período.

POLICY_ID COVERAGE

A123 12000

C567 20000

B345 18000

Exemplo 2: crie uma visualização COVERAGE que faz referência a uma tabela temporal de período dosistema POLICY_INFO e retorna linhas que eram atuais a partir de um ano atrás.CREATE VIEW coverage ASSELECT policy_id, coverageFROM policy_infoFOR SYSTEM_TIME AS CURRENT TIMESTAMP - 1 YEAR;

SELECT * FROM coverage;

A consulta dessa visualização sempre retorna linhas que eram atuais A PARTIR DE um ano atrás.Assumindo um registro de data e hora atual de 2016-05-17-14.45.31.434235000000, a consulta retorna osmesmos resultados que os resultados que foram retornados no exemplo um.


||

|

||

|

||

|||||

||||||||

|||||||||

||

|||||

||||||||

|||||||||

||||||||||

|

||

||

||

||

|||

||||||||

|||

Restrições ao inserir, atualizar ou excluir dados em uma tabela temporal deperíodo do sistemaUma inserção, atualização ou exclusão não pode ser feita quando a inserção, atualização ou exclusãotentar mudar implicitamente as linhas do tempo.

Restrições para cursores e UPDATE/DELETE WHERE CURRENT OF

Um cursor FOR UPDATE não pode ser definido se inclui uma especificação de período na tabelaidentificada na cláusula FROM. O exemplo a seguir retorna um erro:DECLARE updateCursor CURSOR FORSELECT coverageFROM policy_info FOR SYSTEM_TIME AS OF ’2015-01-31-22.31.33.495925000000’FOR UPDATE;

Se a cláusula FOR UPDATE for removida da instrução DECLARE CURSOR e uma especificação deperíodo for definida, o cursor se tornará somente leitura. Se uma instrução UPDATE WHERE CURRENTOF ou DELETE WHERE CURRENT OF for usada para tentar atualizar ou excluir linhas na tabelatemporal de período do sistema e sua tabela de históricos associada, um erro será retornado. O exemplo aseguir retorna um erro:CREATE OR REPLACE PROCEDURE updateProcLANGUAGE SQLBEGINDECLARE val1 INTEGER;DECLARE updateCursor CURSOR FOR

SELECT coverageFROM policy_info FOR SYSTEM_TIME AS OF ’2015-01-31-22.31.33.495925000000’;

OPEN updateCursor;FETCH updateCursor INTO val1;UPDATE policy_info SET coverage = coverage + 1000

WHERE CURRENT OF updateCursor;CLOSE updateCursor;

END;

A atualização retorna um erro porque ela implicitamente tenta atualizar linhas do tempo. A instruçãoSELECT consulta explicitamente a tabela POLICY_INFO e consulta implicitamente sua tabela de históricosassociada, HIST_POLICY_INFO. As linhas em uma tabela de históricos que são acessadas implicitamente nãopodem ser atualizadas.

Restrições para inserir, atualizar e excluir dados em uma visualização

Inserções, atualizações e exclusões não são permitidas em relação a uma visualização que tem umaespecificação de período definida. Por exemplo, a instrução UPDATE a seguir retornaria um erro:CREATE VIEW coverage ASSELECT policy_id, coverage

FROM policy_info FOR SYSTEM_TIME AS OF TIMESTAMP(’2016-02-28-09.10.12.649592000000’);

UPDATE coverage SET coverage = coverage + 1000 WHERE policy_id = ’C567’;

A atualização retorna um erro porque ela implicitamente tenta atualizar linhas do tempo. No entanto, épossível criar, em vez disso, um acionador de atualização para atualizar a tabela temporal de período dosistema. Exemplo:CREATE TRIGGER coverage_update_iot INSTEAD OF UPDATE ON coverageREFERENCING NEW AS N OLD AS OFOR EACH ROW MODE DB2SQLBEGIN

UPDATE policy_infoSET policy_id = n.policy_id, coverage = n.coverageWHERE policy_id = o.policy_id AND coverage = o.coverage;

END;

UPDATE coverage SET coverage = coverage + 1000 WHERE policy_id = ’C567’;

Um erro não será retornado porque o acionador direciona a atualização para a tabela temporal deperíodo do sistema, em vez de direcionar para a visualização.

Administração 21

||||

|

||||||

||||||||||||||||||

||||

|

|||||||

|||||||||||||

||

Considerações de E/S nativa com uma tabela temporal de período do sistemaO processamento de E/S nativo de operações de leitura, gravação e atualização é, em geral, semelhanteàs operações SQL correspondentes. No entanto, há algumas considerações para se ter em mente.

As operações de atualização e exclusão nativas e de SQL relacionadas a uma tabela temporal de períododo sistema fazem com que as linhas do tempo sejam incluídas em uma tabela de históricos. Além disso,se a cláusula ON DELETE ADD EXTRA ROW for especificada no comando ALTER TABLE, as operaçõesde exclusão de SQL e nativa incluirão uma linha extra quando um registro for excluído da tabela. Damesma forma, o valor QAQQINI para SYSTIME_PERIOD_ADJ tem o mesmo efeito sobre atualizaçõessimultâneas nativas, pois ele tem operações SQL de atualização simultâneas. Para nativo e SQL, o valorQAQQINI faz com que o banco de dados crie um erro ou ajuste aos registros de data e hora de tempoinicial e tempo final. Um aplicativo do DB nativo recebe uma exceção CPF503B, código de razão 3,quando o valor SYSTIME_PERIOD_ADJ está definido como *DEFAULT ou *ERROR, e um UPDATEnativo fará com que o valor do horário de encerramento da linha do tempo seja definido para um valorque é menor que o horário inicial da linha do tempo.

Dito isso, várias diferenças entre o processamento nativo e de SQL merecem atenção.

Enquanto as solicitações de leitura nativas trabalham em relação à tabela temporal e de históricos, elasnão mesclam os resultados. Apenas os registros do arquivo lido são retornados. Por exemplo, quando oregistro especial CURRENT TEMPORAL SYSTEM_TIME é configurado como um valor não nulo, umaleitura de SQL da tabela temporal pode retornar as linhas que são desenhadas a partir da tabela temporale sua tabela de históricos correspondente. No entanto, para uma leitura nativa da tabela temporal, obanco de dados ignora o registro especial e retorna valores apenas da tabela temporal.

Quando o registro especial CURRENT TEMPORAL SYSTEM_TIME é configurado como um valor nãonulo, a instruções SQL Data Manipulation (DML) falham com SQLCODE/SQLSTATE configurado como-20535/51046. Um usuário SQL é incapaz de modificar os dados da tabela temporal. No entanto,nenhuma restrição semelhante existe para um usuário nativo. As operações de gravação, atualização eexclusão nativas modificam a tabela temporal se o registro especial estiver configurado ou não.

Finalmente, uma gravação ou atualização nativa pode especificar valores no buffer de E/S das colunasgeradas do período SYSTEM_TIME e outras colunas geradas, se existirem. No entanto,independentemente de quais valores são fornecidos no buffer de E/S, o DB2 for i substitui os valorescorretos para quaisquer colunas geradas.

Mantendo a tabela de históricosComo as tabelas de históricos passam por mais inserções que exclusões, suas tabelas de históricosspodem se tornar grandes. Decidir como remover suas tabelas de históricos para livrar-se das linhas quenão são mais necessárias pode ser uma tarefa complexa.

É necessário compreender o valor de suas linhas individuais. Algum conteúdo, como contratos do cliente,pode ser intocável, nunca podendo ser excluído. Outros registros, como informações do visitante dowebsite, podem ser removidos sem preocupação. Muitas vezes não é a idade de uma linha que determinaquando ela pode ser removida e arquivada, em vez disso, uma lógica de negócios que é o fator decisivo.A lista a seguir contém algumas regras possíveis para remoção:v Remover linhas que são selecionadas por uma consulta fornecida pelo usuário, que reflete as regras de

negócios.v Remover linhas mais antigas do que uma certa idade.v Remover linhas do tempo quando mais de N versões existirem para esse registro (reter apenas as N

versões mais recentes).v Remover linhas do tempo quando o registro é excluído da tabela temporal do período de sistema

associada (quando versões atuais não existirem).


|||

|||||||||||

|

||||||

|||||

||||

||||

|||||

||

|

||

||

Existem várias maneiras de remover dados antigos periodicamente a partir de uma tabela de históricos.Uma maneira de remover dados é o particionamento de intervalo na tabela de históricos. Partiçõesantigas podem, então, ser removidas da tabela de históricos e arquivadas ou excluídas. Para obter maisinformações, consulte Particionando uma tabela temporal de período do sistema.

Particionando uma tabela temporal de período do sistemaUma tabela temporal de período do sistema pode ter seus dados da tabela divididos em várias partições.Uma tabela de históricos que está associada a uma tabela temporal de período do sistema também podeser particionada.

Quando o versionamento está ativado, os seguintes comportamentos são aplicados ao conectar oudesconectar uma partição a uma tabela temporal de período do sistema:

Conectando partições

v Em uma partição única, a tabela particionada pode ser conectada a uma tabela temporal de período dosistema como uma partição enquanto o versionamento está ativado.

v A tabela conectada deve ter as mesmas definições de coluna que a tabela temporal de período dosistema, incluindo as três colunas de registro de data e hora definidas como ROW BEGIN, ROW ENDe START TRANSACTION ID.

v A tabela conectada não requer uma definição de período SYSTEM_TIME.

Desconectando partições

v Uma partição não pode ser desconectada de uma tabela temporal de período do sistema enquanto oversionamento estiver ativado. É possível eliminar o versionamento e, em seguida, desconectar umapartição da tabela base. A partição desconectada se torna uma partição única independente, tabelaparticionada. Desconectar uma partição de uma tabela de históricos não requer que você elimine oversionamento.

v Uma partição desconectada retém todas as três colunas de registro de data e hora (ROW BEGIN, ROWEND e START TRANSACTION ID), mas não a definição do período SYSTEM_TIME.

Referências relacionadas:tabelas particionadas

Controle de acesso de linha e coluna com uma tabela temporal de período dosistemaO controle de acesso de linha e coluna pode ser definido em uma tabela temporal de período do sistemae sua tabela de históricos associada.

O controle de acesso de linha e coluna (RCAC) é uma camada de segurança de dados que controla oacesso a uma tabela no nível de linha, nível de coluna, ou ambos. O RCAC pode ser aplicado às tabelastemporais de período do sistema e às tabelas de históricos. Quando o RCAC é ativado para uma tabelatemporal de período do sistema, o gerenciador do banco de dados ativa automaticamente o controle deacesso de linha na tabela de históricos e cria uma permissão de linha padrão para a tabela de históricos.Esta permissão de linha padrão impede qualquer acesso direto à tabela de históricos. Quando a tabela dehistóricos é protegida pela permissão de linha padrão, as atualizações e exclusões ainda geram linhas dotempo na tabela de históricos.

Quando uma consulta temporal é executada com relação a uma tabela temporal de período do sistema, aspermissões de linha e as máscaras de coluna da tabela temporal de período do sistema também sãoaplicadas às linhas retornadas da tabela de históricos. Por exemplo, se uma permissão de linha é definidapara uma tabela temporal de período do sistema e uma consulta com uma cláusula FOR SYSTEM_TIME ASOF é executada, ambas as linhas atuais e do tempo são retornadas quando a linha atual ou do temposatisfaz a regra RCAC da tabela temporal e era atual desde o horário especificado.

Administração 23

||||

||||

||

|

||

|||

|

|

|||||

||

|

|

||||

||||||||

||||||

Se a tabela de históricos possui apenas uma permissão padrão, não será possível consultá-la diretamente.No entanto, se uma regra de linha ou coluna diferente da permissão padrão também estiver definida natabela de históricos, essa regra será aplicada quando a tabela de históricos for acessada diretamente.Portanto, se você precisar consultar a tabela de históricos diretamente, será possível criar uma permissãode linha ou máscara de coluna na tabela de históricos que corresponde à permissão de linha ou máscaraque foi criada na tabela temporal de período do sistema. Quando a permissão de linha ou máscara decoluna é criada, é possível consultar a tabela de históricos diretamente enquanto também controla oacesso aos dados.

Para obter mais informações sobre o RCAC, consulte Controle de acesso de linha e coluna (RCAC).

Salvando e restaurando as tabelas temporais de período do sistema

A tabela temporal de período do sistema e sua tabela de históricos devem ser explicitamente salvas. Ogerenciador do banco de dados não salva os dois arquivos quando apenas um dos arquivos está salvo.

Quando uma tabela temporal de período do sistema é restaurada sem a sua tabela de históricoscorrespondente, ou uma tabela de históricos é restaurada sem sua tabela temporal de período do sistemacorrespondente, o relacionamento de versionamento da tabela restaurada permanece definido, mas nãoestá estabelecido. Quando isso acontece, o status do versionamento da tabela é mudado para o estadodefinido. Uma mensagem informativa CPI3231 é emitida quando um status do versionamento da tabelatemporal de período do sistema é mudado para o estado definido. Há restrições para as ações que podemser executadas em uma tabela temporal de período do sistema ou uma tabela de históricos quando atabela está no estado definido. Inserções, atualizações e exclusões são evitadas. A maioria das mudançasde DDL também são evitadas. As únicas operações que são permitidas são:v ALTER TABLE ADD VERSIONINGv ALTER TABLE DROP VERSIONINGv DROP TABLE

Para determinar se uma tabela temporal de período do sistema está no estado definido, é possívelconsultar a visualização de catálogo QSYS2/SYSPERIODS. Para determinar se uma tabela de históricosestá no estado definido, é possível consultar a visualização de catálogo QSYS2/SYSHISTORYTABLES.Ambas as visualizações possuem a coluna VERSIONING_STATUS, que contém um 'E' se umrelacionamento de versionamento entre a tabela temporal de período do sistema e a tabela de históricosfoi estabelecido, ou um 'D' se um relacionamento de versionamento entre a tabela temporal de períododo sistema e a tabela de históricos foi definido, mas não estabelecido.

Para obter mais informações, consulte Salvando arquivos físicos que são temporais e Restaurandoarquivos físicos que são temporais.

Usando catálogos para localizar informações sobre a tabela temporal de períododo sistemaHá várias visualizações de catálogo que contêm informações sobre a tabela temporal de período dosistema.v QSYS2/SYSTABLES

Contém uma coluna denominada TEMPORAL_TYPE. Quando o valor é configurado como “S”, a tabela éuma tabela temporal de período do sistema. Quando ele for configurado como “H”, a tabela é umatabela de históricos. O valor “N” é usado para todas as outras tabelas.

v QSYS2/SYSCOLUMNS

Contém uma coluna chamada HAS_DEFAULT. Esta coluna indica o tipo de coluna gerada.v QSYS2/SYSPERIODS

Contém uma linha para cada tabela com um período do sistema e identifica as informaçõestemporárias e de versão.

v QSYS2/SYSHISTORYTABLES


||||||||

|

|

||

|||||||||

|

|

|

|||||||

||

||||

|

|||

|

|

|

||

|

Contém uma linha para cada tabela de históricos.

Restrições da tabela temporalAs tabelas temporais de período do sistema estão sujeitas a várias restrições.

A seguir estão as restrições para tabelas temporais de período do sistema:v A tabela temporal de período do sistema e sua tabela de históricos devem estar no mesmo esquema.v Para atualizar ou excluir dados de uma tabela temporal de período do sistema com versionamento,

tanto a tabela temporal como seu arquivo histórico devem ser registrados.v As instruções SQL ALTER ou CREATE OR REPLACE TABLE que causam uma perda potencial de

dados não são suportadas em tabelas temporais de período do sistema.v As operações a seguir não são permitidas para tabelas temporais de período do sistema:

– ALTER TABLE DROP COLUMN– ALTER TABLE ADD GENERATED COLUMN

v A instrução TRUNCATE não é suportada em relação a uma tabela temporal de período do sistema.v Uma tabela distribuída também não pode ser uma tabela temporal de período do sistema.v As seguintes operações de consulta não são permitidas em relação a uma tabela temporal de período

do sistema:– Uma especificação de período não pode ser feita dentro de uma consulta que faz referência a uma

tabela distribuída, uma tabela com um acionador de leitura, que usa a sequência de classificação doICU 2.6.1, ou se tiver mais de 1000 referências de tabela.

– Uma especificação de período não pode ser feita para um arquivo lógico nativo.– Uma especificação de período não pode ser feita para uma tabela ou visualização que faz referência

a uma coluna em uma função CONTAINS ou SCORE.– Uma especificação de período não pode ser feita para uma visualização em que a definição da

visualização inclui uma função externa que não seja NO SQL ou uma função SQL que não sejacapaz sequencialmente.

Trabalhando com Acionadores e RestriçõesVocê pode utilizar acionadores ou restrições para gerenciar dados nas tabelas de bancos de dados.

Um acionador é um tipo de programa que é chamado automaticamente sempre que uma ação especificadaé executada em uma tabela específica. Os acionadores são úteis para manter as trilhas de auditoria,detectar condições excepcionais, manter relacionamentos no banco de dados e executar aplicativos eoperações que coincidem com a operação de alteração.

Como alternativa, as colunas geradas podem ser utilizadas em vez de um acionador manter informaçõesde auditoria. Para obter mais informações sobre como utilizar as colunas geradas para auditoria, consulte“Usando uma tabela temporal de período do sistema para controlar informações de auditoria” na página12.

Uma restrição é uma restrição ou limitação colocada no banco de dados. As restrições são implementadasno nível da tabela. Você pode utilizar as restrições para criar integridade de referência no banco de dados.

Você pode trabalhar com acionadores e restrições utilizando o IBM Navigator for i, o SQL ou a interfacede sistema tradicional.Conceitos relacionados:Tarefas de Banco de Dados do Navegador do System i

Gravando Programas do DB2O DB2 for i fornece vários métodos para gravação de aplicativos que acessam ou atualizam dados.

Administração 25

|

||

|

|

||

||

|

|

|

|

|

||

|||

|

||

|||

||||

Você pode gravar programas de SQL incorporados, funções externas, procedimentos externos, aplicativosCLI do DB2 for i e programas do acionador.Conceitos relacionados:Programação de SQL IntegradaGravando um DB2 para Aplicativo CLI do i5/OSTarefas relacionadas:Criando Programas do AcionadorReferências relacionadas:Definindo um Procedimento ExternoGravando UDFs como Funções Externas

Backup e Recuperação do Banco de DadosSalvar os dados podem exigir tempo e requer disciplina. Entretanto, é crucial fazer o backup dos dados,pois nunca se sabe quando será necessário fazer uma recuperação deles.Conceitos relacionados:Backup e RecuperaçãoGerenciamento de DiárioRecuperando e Restaurando seu Banco de Dados

Administração de Banco de Dados DistribuídaCom o DB2 for i, você pode trabalhar com bancos de dados que são distribuídos entre vários sistemas.Conceitos relacionados:Programação do Banco de Dados Distribuído

Consultas e RelatóriosVocê pode utilizar o SQL, o comando Abrir Arquivo de Consulta (OPNQRYF), a API de Consulta(QQQQRY), o Open Database Connectivity (ODBC) ou o programa licenciado IBM Query for i para criare executar consultas.

Uma das tarefas mais comuns executadas com o banco de dados é a recuperação de informações. Osistema fornece vários métodos para criar e executar consultas e relatórios.

Você pode utilizar uma instrução SQL para recuperar informações. Essa instrução SQL é chamada query.A consulta faz procuras nas tabelas armazenadas no banco de dados para localizar a resposta à perguntaenviada com a instrução SQL. A resposta é expressa como um conjunto de linhas, conhecido comoconjunto de resultados. Após a execução de uma consulta, você também pode criar um relatório paraexibir os dados fornecidos no conjunto de resultados.

Além disso, para utilizar o SQL, você pode utilizar outras funções e produtos para criar e executarconsultas e relatórios. Consulte as seguintes informações para obter detalhes.v Visão Geral do IBM DB2 Web Query para IBM i

v Consulta para IBM i

v Query Management Programming

v Query Manager Use


http://publib.boulder.ibm.com/infocenter/iseries/v6r1m0/topic/rzatc/sc415210.pdf



Além disso, você pode construir as instruções SQL SELECT, INSERT, UPDATE e DELETE na janelaAssistente de SQL do System i Navigator.Conceitos relacionados:Programação de SQLTarefas relacionadas:Construindo Instruções SQL com o Assistente de SQLReferências relacionadas:comando Abrir Arquivo de Consulta (OPNQRYF)API de Consulta (QQQQRY)

SegurançaAutorizar os usuários a dados no sistema e a níveis de dados permite controlar o acesso ao banco dedados.

A proteção de banco de dados requer que você estabeleça o direito à propriedade e a autoridade públicaaos objetos e à autoridade específica para os aplicativos.Conceitos relacionados:Programas de Saída do Controle de Acesso do Servidor DRDAConcedendo Autoridade de Arquivo e dos DadosLimitando Acesso a Campos Específicos em um Arquivo de Banco de DadosSegurançaEspecificando Autoridade PúblicaUtilizando Recursos de Arquivo de Banco de Dados para Controlar as Operações de E/SUtilizando Arquivos Lógicos para Proteger os Dados

Opções de Autoridade para Análise e Ajuste de SQLEste tópico descreve as opções de autoridade para análise e ajuste de SQL.

O DB2 for i possui um rico conjunto de comandos, procedimentos armazenados, APIs e ferramentas paraanálise e ajuste dos aspectos de desempenho dos aplicativos de banco de dados. Anteriormente, umresponsável pela segurança do sistema precisaria conceder autoridade especial de usuário *JOBCTL parapossibilitar que analistas e administradores de banco de dados utilizassem as ferramentas de banco dedados. Como a autoridade *JOBCTL permite que um usuário altere muitas configurações críticas dosistema que não estão relacionadas à atividade do banco de dados, não era uma decisão fácil para osresponsáveis pela segurança conceder esta autoridade. Em alguns casos, esta era uma decisão fácil e*JOBCTL não era concedido aos analistas de banco de dados, proibindo assim o uso do conjunto integraldas ferramentas de banco de dados.

Nota: Para obter mais informações sobre substituições de configuração para o arquivo QAQQINI,consulte o link a seguir: Suporte para Substituição do Arquivo QAQQINI.

Agora, o responsável pela segurança possui a capacidade adicional de autorizar o acesso às ferramentasde análise de banco de dados e ao Cache de Planos SQL. O DB2 for i que aproveita a vantagem dacapacidade de uso da função disponível no sistema operacional. Um novo grupo de uso da funçãochamado QIBM_DB foi criado com os IDs de função no grupo QIBM_DB:1. QIBM_DB_SQLADM (tarefas do Administrador de Banco de Dados)2. QIBM_DB_SYSMON (tarefas de Informações do Banco de Dados)3. QIBM_DB_DDMDRDA (Acesso de Servidor de Aplicativos DDM & DRDA)4. QIBM_DB_ZDA (Acesso de Servidor de Aplicativos da Caixa de Ferramentas)

Administração 27

5. QIBM_DB_SECADM (Administrador de Segurança de Banco de Dados)

O responsável pela segurança agora tem a flexibilidade para conceder autoridades: conceder a autoridadeespecial *JOBCTL ou autorizar um usuário ou grupo para a Função de Administrador de Banco de Dadosdo IBM i através de Administração de Aplicativos no System i Navigator do IBM Navigator for i. Ocomando Change Function Usage (CHGFCNUSG), com um ID de função de QIBM_DB_SQLADM,também pode ser utilizado para alterar a lista de usuários que têm permissão para executar operações deAdministração de Banco de Dados. Os controles de uso de função permitem que grupos ou usuáriosespecíficos tenham a autoridade permitida ou negada. O comando CHGFCNUSG também fornece umparâmetro que pode ser utilizado para conceder autoridade de uso de função para qualquer usuário quepossua a autoridade especial de usuário *ALLOBJ. (por exemplo, ALLOBJAUT(*USED))

A função Administrador de Banco de Dados é necessária sempre que um usuário está analisando evisualizando dados de desempenho de SQL. Algumas das funções mais comuns são a exibição deinstruções do Cache de Planos SQL, a análise dos Monitores de Desempenho de SQL e de CapturasInstantâneas do Cache de Planos SQL e a exibição dos detalhes de SQL de uma tarefa que não a suaprópria.

O uso da função de administrador de banco de dados é uma alternativa para a concessão de *JOBCTL,mas ela não substitui o requisito de possuir a autoridade de objeto correta. Para ativar tarefas doadministrador de banco de dados que não estão relacionadas à análise de desempenho, consulte a tarefaespecífica para obter detalhes sobre os requisitos de autorização. Por exemplo, para permitir que umadministrador reorganize uma tabela, é necessário que ele tenha autoridades de objeto concedidas, quenão são cobertas pelo QIBM_DB_SQLADM.

Além do QIBM_DB_SQLADM, o comando Change Function Usage (CHGFCNUSG), com um ID defunção de QIBM_DB_SYSMON, também pode ser utilizado para alterar a lista de usuários que têmpermissão para executar operações de Informações do Banco de Dados.

A função Informações do Banco de Dados fornece muito menos autoridade do que a de Administradorde Banco de Dados. O uso principal é permitir que um usuário examine propriedades de banco de dadosde alto nível. Por exemplo, um usuário que não possui *JOBCTL ou QIBM_DB_SQLADM, poderia terpermissão para visualizar as propriedades do Cache de Planos SQL se recebesse a concessão deautoridade para QIBM_DB_SYSMON.

Para trabalhar com o uso da função de grupo de bancos de dados QIBM_DB do System i Navigator, sigaestas etapas:1. Ative Application Administration, conforme mostrado na figura 1.2. Expanda as pastas ‘IBM i' e ‘Database' sob a guia Host Applications, conforme mostrado na figura 2.3. Customize o uso da função Database Administrator (QIBM_DB_SQLADM), conforme mostrado na

figura 3.

Neste exemplo, o responsável pela segurança determinou que desejava configurar um grupo denominadoDbagroup que conteria todos os usuários para os quais desejava fornecer este nível de autoridade. E eledesejou explicitamente negar o acesso para Slfuser. Agora, o responsável pela segurança possui um localconveniente e facilmente monitorado para visualizar e autorizar usuários a estas funções.

Figura 1. Ative Application Administration.


Figura 2. Expanda o grupo Database

Administração 29

Figura 3. Altere as configurações de uso da função QIBM_DB_SQLADM


A Tabela 1 descreve algumas das mudanças de autorização relacionadas aos comandos, ProcedimentosArmazenados e APIs do DB2.

Tabela 24. Requisitos de Autorização para Desempenho e Análise do Banco de Dados

Ação do Usuário *JOBCTL QIBM_DB_SQLADM QIBM_DB_SYSMONSemAutoridade

SET CURRENT DEGREE (instruçãoSQL)

Permitido Permitido Não Permitido Não Permitido

Comando CHGQRYA objetivando umatarefa de um usuário diferente


Comandos STRDBMON ouENDDBMON objetivando uma tarefade um usuário diferente


Comandos STRDBMON ouENDDBMON objetivando uma tarefaque corresponde ao usuário atual

Permitido Permitido Permitido Permitido

API QUSRJOBI() formato 900 ouDetalhes SQL do System i Navigatorpara a Tarefa

Permitido Permitido Permitido Não Permitido

Administração 31

Tabela 24. Requisitos de Autorização para Desempenho e Análise do Banco de Dados (continuação)

Ação do Usuário *JOBCTL QIBM_DB_SQLADM QIBM_DB_SYSMONSemAutoridade

Procedimento DUMP PLAN CACHEPROPERTIES

Permitido Permitido Permitido Não Permitido

Visual Explain dentro de ExecutarScripts SQL

Permitido Permitido Permitido Permitido

Visual Explain fora de Executar ScriptsSQL


Procedimento ANALYZE PLANCACHE


Procedimento DUMP PLAN CACHE Permitido Permitido Não Permitido Não Permitido

Procedimento MODIFY PLAN CACHE Permitido Permitido Não Permitido Não Permitido

Procedimento MODIFY PLAN CACHEPROPERTIES (atualmente não verificaa autoridade)


Procedimento CHANGE PLANCACHE SIZE (atualmente não verificaa autoridade)


Procedimento START PLAN CACHEEVENT MONITOR


Procedimento END PLAN CACHEEVENT MONITOR


Procedimento END ALL PLANCACHE EVENT MONITORS


Row and Column Access Control (RCAC)O Row and column access control (RCAC) fornece uma alternativa centralizada em dados para atingir asegurança de dados.

O RCAC coloca o controle de acesso no nível da tabela em torno de si mesmo. As regras SQL criadas emlinhas e colunas são a base da implementação deste recurso.

Termos do RCAC

v Tabela base - A tabela (arquivo físico), a permissão ou máscara é incluída.v Objeto dependente - Qualquer referência a objeto (arquivo, esquema, função ou outro objeto),

permissão ou máscara.v QIBM_DB_SECADM – O uso da função identifica o usuário que deve estar autorizado para manipular

todas as ações relacionadas a permissões e máscaras.v Row and Column Access Control (RCAC) – O controle de acesso é o recurso para controlar o acesso

aos dados usando permissões e máscaras.v Permissão - Uma permissão de linha define uma regra de controle de acesso de linha para linhas de

uma tabela.v Máscara - Uma máscara de coluna define uma regra de controle de acesso da coluna para uma coluna

específica em uma tabela.v RULETEXT – A expressão a ser usada pela permissão ou máscara.v 5770-SS1 IBM Advanced Data Security for i (Opção 47) – O produto que precisa ser solicitado e

instalado para poder:– criar permissões de linha.


– criar máscaras de coluna.– executar acesso ao banco de dados por meio de objetos que têm RCAC ativo.

Visão GeralIBM Advanced Data Security for i apresenta RCAC como uma camada extra de segurança de dados.

O RCAC fornece controle de acesso a uma tabela no nível baixo, nível da coluna ou ambos. O RCACpode ser usado para complementar o modelo de privilégios da tabela. Para estar em conformidade comvários regulamentos do governo, é possível implementar procedimentos e métodos para assegurar que asinformações estejam protegidas adequadamente. Os indivíduos em sua organização têm acesso permitidoa somente o subconjunto de dados que é necessário para executar suas atividades de trabalho. Porexemplo, os regulamentos do governo em sua área podem declarar que um médico está autorizado avisualizar os registros médicos de seus próprios pacientes, mas não de outros pacientes. Os mesmosregulamentos também podem declarar que, a menos que um paciente dê seu consentimento, umprovedor de assistência médica não terá acesso permitido a informações pessoais do paciente, como onúmero do telefone residencial dos pacientes. É possível usar o RCAC para assegurar que seus usuáriossó tenham acesso aos dados necessários para seu trabalho. Por exemplo, o RCAC pode filtrar informaçõese dados do paciente para incluir somente esses dados, que um determinado médico está autorizado avisualizar.

Outros pacientes não existem até onde sabe o médico. Da mesma forma, quando um representante deserviço do paciente consulta a tabela do paciente no mesmo hospital, ele pode visualizar as colunas nomedo paciente e número de telefone, mas a coluna histórico médico é mascarada para eles. Se os dadosforem mascarados, um valor NULL ou alternativo será exibido em vez de o histórico médico real. ORCAC possui as vantagens a seguir:1. Nenhum usuário do banco de dados está isento inerentemente das regras do RCAC. Mesmo

autoridades de alto nível, como usuários com toda a autoridade de objeto (autoridade especial (como*ALLOBJ)) não estão isentos dessas regras. Somente usuários com a autoridade QIBM_DB_SECADMpodem gerenciar o RCAC em um banco de dados. Portanto, é possível usar o RCAC para impedirque os usuários com autoridade de objeto total acessem todos os dados em um banco de dados.

2. Os dados da tabela são protegidos independentemente de como uma tabela é acessada. Aplicativos,ferramentas de consulta e de geração de relatórios improvisadas estão todas sujeitas às regras decontrole de acesso. A execução é centralizada nos dados.

3. Nenhuma mudança de aplicativo é necessária para aproveitar esta camada adicional de segurança dedados. O RCAC é estabelecido e definido de modo que não fica aparente aos aplicativos existentes.Entretanto, o RCAC representa uma mudança importante no paradigma no sentido de que não é maiso que está sendo perguntado, mas sim quem perguntou. Mesmo que dois usuários possam executar oque parece serem consultas idênticas, quando predicados de permissão de linha são incluídos naconsulta, esses dois usuários podem observar um conjunto de resultados diferente. Estecomportamento é o intento exato da solução. Significa que os editores de telas e DBAs devem estarcientes de que as consultas não veem toda a imagem em termos de dados na tabela a menos que aautorização ao RCAC seja concedida.

4. Antes dos controles do RCAC para a proteção de dados centralizada em dados, os usuários do DB2for i protegeriam os dados por meio da criação de várias visualizações SQL ou arquivos lógicosSelect-omit. Embora esta técnica de confiar em uma visualização/arquivo lógico para limitar dadosatinja o objetivo, ela cria vários problemas:a. Os aplicativos tinham de ser copiados para funcionar com visualizações especializadas, em vez de

um objeto comum.b. Em grandes instalações, o número de visualizações que existem para este propósito cresce

rapidamente para um número grande, resultando em considerações de gerenciamento de objetosadicional como Salvar/Restaurar.

c. O responsável pela segurança tem de passar um tempo ajustando autorizações para muitosobjetos.

Administração 33

d. Para arquivos lógicos select-omit, o DB2 for i tem de gastar ciclos de processamento para mantercada arquivo lógico select-omit atualizado conforme o(s) objeto(s) subjacente(s) muda(m).

Além de atingir os benefícios dos dados naturalmente protegidos ao implementar o RCAC, os clientes doDB2 for i podem aposentar as muitas visualizações que existem unicamente para proteger dados.

IBM Advanced Data Security for i

IBM Advanced Data Security for i é uma opção instalável que é usada para gerenciar políticas desegurança reforçando o RCAC com permissões e máscaras.

Se o IBM Advanced Data Security for i não estiver instalado, consulte Instalando, Fazendo Upgrade ouExcluindo o IBM i/OS® e Software Relacionado para obter informações sobre instalar programaslicenciados extra. Para instalar o IBM Advanced Data Security for i, use a opção 47 na lista de opçõesinstaláveis para o sistema operacional.

Tabelas que contêm permissões ou máscaras ativadas do RCAC podem ser restauradasindependentemente se o IBM Advanced Data Security for i está instalado ou não. Entretanto, se a opçãonão estiver instalada, as permissões e máscaras não poderão ser criadas e as tabelas, visualizações ouíndices que contêm permissões ou máscaras ativas não poderão ser acessados.

Separação de Obrigações

A separação de obrigações ajuda as empresas a estarem em conformidade com os regulamentos domercado ou requisitos organizacionais e simplifica o gerenciamento de autoridades. A separação deobrigações geralmente é usada para impedir atividades fraudulentas ou erros por uma única pessoa. Elafornece a capacidade para que funções administrativas sejam divididas entre indivíduos sem sobrepor asresponsabilidades, para que um usuário não possua autoridade ilimitada, como com a autoridade*ALLOBJ.

Por exemplo, suponha que um negócio tenha designado a responsabilidade de gerenciar a segurança noIBM i para Theresa. Antes da liberação do IBM i 7.2, para conceder privilégios, Theresa tinha de ter osmesmos privilégios que estava concedendo. Assim, para conceder privilégios *USE à tabela PAYROLL,Theresa tinha de ter as autoridades *OBJMGT e *USE (ou um nível superior de autoridade, como*ALLOBJ). Este requisito permitiu que Theresa acessasse os dados na tabela PAYROLL mesmo que adescrição do cargo dela fosse somente gerenciar a segurança.

No IBM i 7.2, o uso da função, QIBM_DB_SECADM, fornece a um usuário a capacidade de conceder aautoridade, revogar a autoridade, alterar a propriedade ou alterar o grupo primário. Isso é feito sem daracesso ao objeto ou, no caso de uma tabela de banco de dados, aos dados que estão na tabela oupermitindo outras operações na tabela. O uso da função QIBM_DB_SECADM só pode ser concedido porum usuário com autoridade especial *SECADM e pode ser atribuído a um usuário ou grupo.

QIBM_DB_SECADM também é responsável por administrar o RCAC. O RCAC restringe quais linhas umusuário tem permissão de acesso em uma tabela e se um usuário tem permissão de ver informações emcertas colunas de uma tabela.

A melhor prática é que o administrador do RCAC tenha o uso da função QIBM_DB_SECADM eabsolutamente nenhum privilégio de dados. O administrador do RCAC pode implementar e manter osconstrutos do RCAC e seria incapaz de conceder a si mesmo o acesso não autorizado aos dados.

Permissões e MáscarasO RCAC é um modelo no qual um administrador de segurança gerencia políticas de privacidade esegurança.


O RCAC permite que todos os usuários acessem a mesma tabela, ao contrário de visualizaçõesalternativas de uma tabela. RCAC, no entanto, restringe o acesso aos dados na tabela, baseada naspermissões de usuário individual ou regras, conforme especificado por uma política que está associada àtabela. Há dois conjuntos de regras. Um conjunto de regras opera em linhas (permissões) e o outro emcolunas (máscaras). Para criar permissões e máscaras, o IBM Advanced Data Security for i deve serinstalado.

Permissão de linhav Uma permissão de linha define uma regra de controle de acesso de linha para uma tabela específica.v Uma regra de controle de acesso de acesso de linha é uma condição de procura SQL que descreve qual

conjunto de linhas um usuário pode acessar.v A definição de cada permissão de linha pode referenciar o usuário ou grupo na condição de procura.

Se diversas permissões de linha forem definidas para uma tabela e o controle de acesso de linha estiverativado, a condição de procura em cada permissão de linha será conectada pelo operador OR lógicopara formar a condição de procura do controle de acesso de linha. Essa condição de procura decontrole de acesso de linha é aplicada sempre que a tabela é acessada. Ela atua como um filtro natabela antes de quaisquer outras operações especificadas pelo usuário, como predicados e ordenaçãosão processados. Ela atua como a cláusula WITH CHECK OPTION de uma visualização para assegurarque uma linha seja inserida ou atualizada conforme as definições das permissões de linha em umainstrução INSERT, UPDATE ou MERGE.

Máscara de colunav Uma máscara de coluna define uma regra de controle de acesso da coluna para uma coluna específica

em uma tabela.v Uma regra de controle de acesso de coluna é uma expressão CASE SQL que descreve quais valores de

coluna um usuário tem permissão de ver e sob quais condições.v A definição de cada máscara de coluna pode referenciar o usuário ou grupo nas condições de procura

na cláusula CASE WHEN. Embora diversas colunas em uma tabela possam ter máscaras de coluna,somente uma máscara de coluna pode ser criada para uma única coluna. Quando o controle de acessode coluna é ativado para a tabela, a expressão CASE na definição de máscara de coluna é aplicada nacoluna de saída para determinar os valores mascarados retornados para um aplicativo. O aplicativo demáscaras de coluna afeta o resultado final somente. Isso não impacta as operações, como predicados eordenação em uma instrução SQL.

O RCAC pode ser ativado para uma tabela antes ou após as permissões de linha ou máscaras de colunaserem criadas para a tabela. Se as permissões de linha ou máscaras de coluna existirem, ativar o controlede acesso de linha e coluna simplesmente torna as permissões ou máscaras efetivas. Se as permissões delinha ainda não existirem, ativar o controle de acesso de linha para uma tabela significa que o DB2 for igera uma permissão de linha padrão que impede qualquer acesso aos dados na tabela.

Instruções SQLAs instruções criar, alterar e eliminar SQL suportam a implementação de RCAC com permissões emáscaras.v Criar Permissãov Alterar Permissãov Eliminar Permissãov Criar Máscarav Alterar Máscarav Eliminar Máscarav Alterar Funçãov Alterar Acionadorv Alterar Tabela

Administração 35

Autorização

O ID de autorização da instrução SQL deve estar autorizado à função de Administrador de Segurança doBanco de Dados do IBM i. Consulte Autoridade administrativa.

Funções ProtegidasAs funções devem ser definidas como protegidas antes de poderem ser chamadas nas definições doRCAC.

O atributo SECURED é necessário se o UDF for referenciado na definição de uma permissão de linha oumáscara de coluna, porque o UDF terá acesso aos dados antes do aplicativo do RCAC. O atributoSECURED também é necessário para um UDF que é chamado em uma instrução SQL quando osargumentos da função referenciam colunas que estão ativadas com o controle de acesso da coluna.

Proteger AcionadoresOs acionadores definidos em uma tabela com o RCAC ativado devem estar protegidos.

O atributo SECURED é necessário para um acionador quando a tabela associada possui o RCAC ativadoou a visualização associada cuja tabela subjacente está ativada com o RCAC. Se um acionador existir, masnão estiver protegido, o RCAC não poderá ser ativado para a tabela associada.

Autoridade administrativaA autorização para a função de Administrador de Segurança de Banco de Dados do IBM i pode serdesignado por meio de um Administração do Aplicativo em IBM Navigator for i.

O comando Change Function Usage Information (CHGFCNUSG), com um ID da função deQIBM_DB_SECADM, pode ser usado para alterar a lista de usuários autorizados.

Melhores Práticas ao Usar Permissões e MáscarasAs permissões e máscaras podem ser criadas para uma tabela em um número de implementaçõesdiferentes. Esta seção explicará algumas das implementações que podem ser usadas para criar permissõese máscaras.

Criando Permissões e MáscarasUm número de considerações precisa ser determinado para decidir a melhor forma de criar permissõesou máscaras.

Criar permissões ou máscaras quando o row or column access control está ativo

A tarefa que está criando a permissão ou máscara obtém um bloqueio restrito na tabela base. Se o row orcolumn access control estiver ativo, a tabela base não terá permissão de leitura até a criação da permissãoou máscara estar concluída. Os aplicativos que leem a tabela base precisam ser encerrados até que aspermissões ou máscaras sejam incluídas.

Criando permissões ou máscaras quando o row or column access control não está ativo

A tarefa que está criando a permissão ou máscara obtém um bloqueio restrito na tabela base. Entretanto,a tabela base tem permissão de ser lida até que o row or column access control seja ativado. Osaplicativos que leem a tabela base não têm de ser encerrados.

Única Permissão com Todos os Usuários:

Exemplo 1: Usando uma única permissão com todos os usuários definidos na permissão.


CREATE SCHEMA MY_LIBCREATE TABLE MY_LIB.PERMISSION_TABLE (COLUMN1 INT)CREATE PERMISSION MY_LIB.PERM1 ON MY_LIB.PERMISSION_TABLE FOR ROWS WHERE

VERIFY_GROUP_FOR_USER(CURRENT_USER,’USER1’,’USER2’,’USER3’) = 1ENFORCED FOR ALL ACCESS ENABLE

ALTER TABLE MY_LIB.PERMISSION_TABLE ACTIVATE ROW ACCESS CONTROL/***************************************************************//* Conecte-se como USER1 *//***************************************************************/INSERT INTO MY_LIB.PERMISSION_TABLE VALUES(1) /* Permitido. */

A vantagem de uma única permissão é o melhor desempenho da consulta para aplicativos. Adesvantagem é incluir outro usuário, a permissão tem de ser eliminada e criada para incluir o novousuário.

Única Permissão com um Perfil de Grupo:

Exemplo 2: usando uma única permissão com todos os usuários definidos em um perfil de grupo napermissão.

CREATE SCHEMA MY_LIBCREATE TABLE MY_LIB.PERMISSION_TABLE (COLUMN1 INT)CREATE PERMISSION MY_LIB.PERM1 ON MY_LIB.PERMISSION_TABLE

AS P_GROUP FOR ROWS WHEREVERIFY_GROUP_FOR_USER(SESSION_USER,’PERM_GROUP’) = 1

ENFORCED FOR ALL ACCESS ENABLEALTER TABLE MY_LIB.PERMISSION_TABLE ACTIVATE ROW ACCESS CONTROL/********************************************************************//* Conecte-se como USER1 que é um membro do grupo de usuários PERM_GROUP *//********************************************************************/INSERT INTO MY_LIB.PERMISSION_TABLE VALUES(1) /* Permitido. */

A vantagem de uma única permissão verificando um perfil do grupo significa que a permissão não temde alterar a inclusão de outro usuário. A desvantagem de cada consulta da tabela base, a funçãoVERIFY_GROUP_FOR_USER é verificada.

Única Permissão com uma Tabela Dependente:

Exemplo 3: Usando uma única permissão que os usuários definiram em uma tabela dependente.CREATE SCHEMA MY_LIBCREATE SCHEMA RCAC_DEPENDENTCREATE TABLE MY_LIB.PERMISSION_TABLE (COLUMN1 INT)CREATE TABLE RCAC_DEPENDENT.USERS (USERNAME CHAR (10))INSERT INTO RCAC_DEPENDENT.USERS

VALUES(’USER1 ’),(’USER2 ’),(’USER3 ’)CREATE TABLE MY_LIB.PERMISSION_TABLE (FIELD1 INT)CREATE PERMISSION MY_LIB.PERM1 ON MY_LIB.PERMISSION_TABLE

FOR ROWS WHERECURRENT_USER IN (SELECT USERNAME FROM RCAC_DEPENDENT.USERS)ENFORCED FOR ALL ACCESS ENABLE

ALTER TABLE MY_LIB.PERMISSION_TABLE ACTIVATE ROW ACCESS CONTROL/***********************************************************************//* Conecte-se como USER1 *//***********************************************************************/INSERT INTO MY_LIB.PERMISSION_TABLE VALUES(1) /* Permitido. */

A vantagem de uma única permissão verificar uma tabela dependente é que, ao incluir outro usuário, apermissão não precisa ser mudada. A desvantagem é a consideração de desempenho de consultar a tabeladependente.

Única Permissão com um UDF:

Exemplo 4: Usando uma única permissão com um User Defined Function (UDF).CREATE SCHEMA RCAC_DEPENDENT

CREATE SCHEMA MY_LIBCREATE TABLE MY_LIB.PERMISSION_TABLE (COLUMN1 INT)CREATE OR REPLACE FUNCTION RCAC_DEPENDENT.UDF_PERMISSION

()RETURNS CHAR(10)LANGUAGE SQL

Administração 37

MODIFIES SQL DATANO EXTERNAL ACTIONDETERMINISTICNOT FENCEDSECUREDBEGIN

DECLARE ALLOWS CHAR(10);IF (CURRENT_USER = ’USER1’) THEN

SET ALLOWS = ’ALLOWED ’;ELSE

SET ALLOWS = ’DISALLOWED’; END IF;RETURN ALLOWS;

END

CREATE PERMISSION MY_LIB.PERMISSION_USERON MY_LIB.PERMISSION_TABLE

FOR ROWS WHERERCAC_DEPENDENT.UDF_PERMISSION() = ’ALLOWED ’ENFORCED FOR ALL ACCESS ENABLE

ALTER TABLE MY_LIB.PERMISSION_TABLE ACTIVATE ROW ACCESS CONTROL

A vantagem de uma única permissão que verifica um UDF é incluir outro usuário, a permissão não temde se alterar. A desvantagem aparece quando o UDF é alterado. Durante a próxima abertura da tabelacom a permissão, a verificação deve ser feita para permitir que o novo UDF seja usado com a permissão.A verificação faz com que a permissão ou máscara seja gerada novamente uma vez para a tabela.

Permissões para Cada Usuário:

Exemplo 5: Usando diversas permissões, uma permissão para cada usuário.CREATE SCHEMA MY_LIBCREATE TABLE MY_LIB.PERMISSION_TABLE (COLUMN1 INT)

CREATE PERMISSION MY_LIB.P1 ON MYLIB.PERMISSION_TABLEFOR ROWS WHERECURRENT_USER = ’USER1 ’ENFORCED FOR ALL ACCESS ENABLE

CREATE PERMISSION MY_LIB.P2 ON MY_LIB.PERMISSION_TABLEFOR ROWS WHERECURRENT_USER = ’USER2 ’ENFORCED FOR ALL ACCESS ENABLE

CREATE PERMISSION MY_LIB.P3 ON MY_LIB.PERMISSION_TABLEFOR ROWS WHERECURRENT_USER = ’USER3 ’ENFORCED FOR ALL ACCESS ENABLE

ALTER TABLE MY_LIB.PERMISSION_TABLE ACTIVATE ROW ACCESS CONTROL

A vantagem de diversas permissões é a facilidade de uso de ter permissões individuais. A desvantagem éter de incluir outro usuário, uma nova permissão tem de ser incluída. A nova permissão causa umaregeneração da permissão composta usada para a tabela.

Atributos de Diversas Permissões:

Os atributos para cada permissão da tabela base precisam ser os mesmos.

Os atributos precisam ser os mesmos, porque quando a permissão é executada, os dados (linhas da tabelabase) são verificados para cada permissão. Por exemplo, o caso em que uma permissão está usando um*PERIOD como o ponto decimal e outra permissão está usando uma*COMMA. As permissões sãodiferentes, porque o tipo de ponto decimal esperado por cada permissão não é o mesmo. Os atributos aseguir podem alterar a execução da permissão:v DATFMT, TIMFMT, DATSEP, TIMSEP DECMPTv SRTSEQ e LANGIDv DECFLTRNDv Ponto decimal e DECRESULT


Se os atributos listados não forem os mesmos para cada permissão, um resultado inesperado poderá serretornado.

Nomes de Objetos Não Qualificados:

Os nomes de objetos não qualificados no RULETEXT se tornam qualificados para esquema durante acriação das permissões ou máscaras.

Por exemplo, criar permissões ou máscaras em um ambiente de teste faz com que os nomes de objetos setornem qualificados com o nome do esquema de teste. Portanto, é melhor qualificar o nome do esquemapara evitar confusão do nome do esquema.

CREATE SCHEMA MY_LIBCREATE SCHEMA RCAC_LIBCREATE TABLE MY_LIB.PERMISSION_TABLE (COLUMN1 INT)CREATE TABLE RCAC_LIB.DEPENDENT_TABLE (COLUMN1 INT)SET SCHEMA RCAC_LIBCREATE PERMISSION MY_LIB.PERMISSION_USE

ON MY_LIB.PERMISSION_TABLE FOR ROWSWHERE

COLUMN1 IN (SELECT COLUMN1 FROM DEPENDENT_TABLE)ENFORCED FOR ALL ACCESS ENABLE

/*******************************************************************//* A instrução selecionar mostrará RULETEXT como sendo qualificado. *//*******************************************************************/SELECT CHAR(RULETEXT,200) FROM QSYS2.SYSCONTROL

WHERE SCHEMA = ’MY_LIB’

/*******************************************************************//* O RULETEXT agora está qualificado. *//*******************************************************************/PERMISSION_TABLE.COLUMN1 IN(SELECT RCAC_LIB.DEPENDENT_TABLE.COLUMN1 FROM RCAC_LIB.DEPENDENT_TABLE)

Objetos DependentesUm número de considerações deve ser determinado para decidir como manipular objetos dependentesdas permissões e máscaras.

Propriedade:

Objetos dependentes de uma permissão ou máscara devem ser possuídos pelo perfil do usuário com aautoridade funcional QIBM_DB_SECADM e nenhuma autoridade de gerenciamento de objetos deve serconcedida a outros usuários.

Isso restringe a possibilidade de o objeto dependente ser manipulado por um usuário autorizado paraalterar uma permissão ou máscara para permitir acesso indesejado a dados.

Esquema:

Todas as tabelas dependentes ou visualizações de uma permissão ou máscara devem ser criadas em umesquema diferente do esquema da tabela base.

Se o usuário executar um Create Duplicate Object (CRTDUPOBJ) ou Restore (RSTOBJ) da tabela base paraum novo esquema, os nomes do esquema dos objetos dependentes não são alterados. Ao manter astabelas dependentes e visualizações em um esquema diferente após CRTDUPOBJ ou RSTOBJ da tabelabase, a tabela base recém-criada referencia os mesmos objetos dependentes que a tabela base original.

Se os objetos dependentes das permissões e máscaras estiverem no mesmo esquema, se o usuárioduplicar o esquema, as permissões e máscaras duplicadas referenciarão os objetos do esquema original.Portanto, ao clonar um esquema e os objetos nele, a melhor prática é usar o recurso Gerar SQL em umIBM i Navigator. Ao cancelar a seleção da opção "Objetos de Qualificação de Esquema", o script SQL

Administração 39

resultante não conterá mais referências qualificadas do esquema nas permissões e máscaras. O usuáriopode preceder a execução do script SQL com uma instrução SET SCHEMA especificando o esquema dedestino.

Autoridade de Esquema:

O esquema que contém os objetos dependentes não deve permitir a autoridade de gerenciamento deobjetos para usuários.

Ao não conceder a autoridade de gerenciamento de objetos aos usuários, os objetos dependentes nãoterão permissão de serem manipulados por usuários.

UDFs Protegidos:

Uma função definida pelo usuário (UDF) SQL usada no RULETEXT de uma permissão ou máscara deveser marcada como SECURE.

Esta mesma regra se aplica a qualquer função que possa ser chamada com uma coluna mascaradaespecificada como um argumento. O atributo SECURE está armazenado no executável *PGM ou*SRVPGM que é chamado quando o UDF é chamado. Quando o *PGM/*SRVPGM para uma função SQLSECURED é restaurado, o atributo SECURE associado à função pode ser perdido a menos que um dosseguintes seja true:v O usuário que está fazendo a restauração está autorizado à função QIBM_DB_SECADM.v O usuário que está fazendo a restauração possui a autoridade especial *SAVSYS.v O usuário chamado QSECOFR está fazendo a restauração.

Os programas Old Program Model (OPM) não podem ser usados para funções (UDFs) definidas empermissões ou máscaras. Isso ocorre porque o sistema não pode verificar o programa durante outrasoperações do banco de dados, como a restauração ou renomeação.

Ao criar um UDTF ou UDF, o padrão é FENCED, significando que UDTF ou UDF é executado em umencadeamento secundário. Certos registros especiais SQL como CURRENT USER não podem secomportar conforme o esperado quando referenciados em um UDF FENCED. Portanto, quando UDTFsou UDFs forem usados no texto do RCAC, use NOT FENCED.

ALWCPYDTA e Nível de Isolamento:

As expressões no RULETEXT da permissão ou máscara são executadas com o mesmo ALWCPYDTA eatributos de nível de isolamento ao abrir uma tabela base, índice ou visualização com uma permissão oumáscara ativa.

Para aberturas nativas o atributo ALWCPYDTA é *NO. Isso impede que as cópias temporárias dos dadossejam usadas para executar as expressões de permissão ou máscara. Se a permissão ou máscara requereruma cópia temporária dos dados, é recomendável que as expressões correspondentes sejam movidas paraum UDF seguro que é executado com um atributo ALWCPYDTA de *YES ou *OPTIMIZE. O RULETEXTda permissão ou máscara poderia ser alterado para referenciar o UDF em vez da expressão que precisavade uma cópia temporária dos dados.

Restaurando Objetos:

Restaurar uma versão diferente de um objeto dependente da tabela base pode impactar as permissões emáscaras existentes.

O processo de verificar os objetos dependentes para permissões e máscaras é feito pela primeira vez quea tabela base é aberta e não durante o processo de restauração.


Portanto, após restaurar os objetos dependentes para as permissões ou máscaras,o administrador dosistema deve incluir no processo uma operação aberta simples da tabela base. Isso permite que averificação seja concluída e evita a verificação no tempo de execução do aplicativo.

É importante se assegurar de que os objetos dependentes adequados das permissões e máscaras sãorestaurados ao restaurar as tabelas base com as permissões e máscaras.

Operações AdicionaisUm número de considerações deve ser revisto criando permissões ou máscaras para uma tabela.

Incluindo o Perfil do Aplicativo em Permissões e Máscaras:

Alguns aplicativos existentes podem precisar incluir o perfil da tarefa que executa o aplicativo naspermissões e máscaras da tabela base.

Alguns exemplos desses aplicativos seriam Data Propagator, software High Availability (HA) e aplicativossemelhantes. Se o perfil do aplicativo não for incluído nas permissões e máscaras, as permissões emáscaras serão reforçadas e o aplicativo poderá usar linhas parciais e dados mascarados.

Recuperar o Armazenamento:

Após concluir um Reclaim Storage (RCLSTG), quaisquer espaços de dados que sejam órfãos e localizadospela operação de recuperação de armazenamento serão incluídos na biblioteca QRCL como uma tabela.

Como esses espaços para dados poderiam ser o resultado de uma tabela base que tinha o RCAC, osespaços para dados que agora são tabelas no QRCL não têm nenhum RCAC. Após o RCLSTG serconcluído, o administrador do sistema precisará consultar as tabelas em QRCL e manipular (copiar osdados e excluir a tabela) as tabelas que precisam ser protegidas com o RCAC.

Relatórios de Consulta:

Esta recomendação se aplica a funções de relator de consulta, como Query for i ou DB2 for i QueryManager.

Ao usar uma função de relator de consulta da web, é recomendado, para resultados consistentes, queuma classificação também seja aplicada a qualquer coluna usada para processamento de quebra derelatório. Com o aplicativo de máscaras de coluna, a classificação é feita em uma coluna antes de asmáscaras serem aplicadas, mas o processamento da quebra que é feito pela função de relator pode serfeito usando valores mascarados. Como resultado, os agrupamentos de quebra inconsistente e valores deresumo diferentes podem ser vistos ao executar um relatório de consulta após as máscaras seremdefinidas na tabela baseada.

MQTs:

Ao preencher ou atualizar um MQT, ele não considera predicados ou expressões de máscaras oupermissões em tabelas dependentes.

Quando o MQT é usado para otimização em uma consulta, as permissões de linha subjacentes e máscarasde coluna são construídas na consulta que usa o MQT. Para que o MQT seja usado para otimização, oMQT deve incluir quaisquer colunas que sejam usadas pelas máscaras ou permissões.

No exemplo a seguir, o MQT TOTALSALES não pode ser usado por nenhuma consulta que incluaCreditCardNum porque CustID é usado pela máscara para CreditCardNum, mas não está na lista deseleção do MQT.

CREATE SCHEMA MY_LIBCREATE TABLE MY_LIB.SALES(CustID INT,

CreditCardNum VARCHAR(12),

Administração 41

Amount DEC(6,2))

CREATE MASK MY_LIB.CCN_MASK ON SALES FOR COLUMN CreditCardNumRETURNCASE

WHEN (CustID < 10) THEN CreditCardNumELSE 'b*******' || SUBSTR(CreditCardNum, 9, 4)

ENDENABLE;

CREATE TABLE MY_LIB.TOTALSALESAS (SELECT CreditCardNum AS SCCN, SUM(Amount) AS SSUMFROM SALESGROUP BY CreditCardNum)DATA INITIALLY DEFERREDREFRESH DEFERREDMAINTAINED BY USER

SELECT CreditCardNum, Sum(Amount)FROM MY_LIB.SALESGROUP BY CreditCardNum

Tabelas temporais:

Uma tabela temporal de período do sistema pode ter uma permissão de linha ou uma máscara de coluna.

Para obter mais informações sobre tabelas temporaise RCAC, consulte “Controle de acesso de linha ecoluna com uma tabela temporal de período do sistema” na página 23.

Perfis de Grupo e QIBM_DB_SECADM:

IDs de autorização que estão autorizados à função QIBM_DB_SECADM não devem ser incluídos em umperfil do grupo.

Esse ID de autorização pode transferir a propriedade ou conceder privilégios para um objeto a qualquerID de autorização que não ele mesmo. Entretanto, o ID autorizado ainda pode transferir ou conceder aogrupo do qual o ID autorizado é um membro.

Os usuários que têm autoridades necessárias para excluir, mover, copiar, renomear ou substituir osobjetos *PGM/*SRVPGM não podem fazer essas operações quando o objeto *PGM/*SRVPGMcorresponde a um SECURE FUNCTION e o usuário está autorizado à função QIBM_DB_SECADM. Umusuário que tem permissão de usar a função QIBM_DB_SECADM pode usar os comandos Create SQLILE CL (CRTSQLCBLI, CRTSQLCI, CRTSQLCCPPI ou CRTSQLRPGI) ou qualquer um dos comandosCreate Bound Program CL (CRTBNDC, CRTBNDCBL, CRTBNDCL, CRTBNDCPP, CRTBNDRPG) parasubstituir um *PGM/*SRVPGM associado à SECURE FUNCTION.

Após o objeto ser criado, ele pode ser copiado para a biblioteca QRPLOBJ. A cópia QRPLOBJ da SECUREFUNCTION pode ser copiada ou movida para outra biblioteca, mas não terá permissão para ser usadacomo uma SECURE FUNCTION, a menos que o programa seja renomeado, movido, copiado ousalvo/restaurado por um usuário com a autoridade QIBM_DB_SECADM. Lembre-se, um usuário sem aautoridade QIBM_DB_SECADM tem permissão de excluir, mover ou copiar o objeto em QRPLOBJ, masnão tem permissão de excluí-lo da biblioteca à qual foi movida ou copiada.

Parâmetros Copy File (CPYF):

O comando Copy File (CPYF) pode comparar valores retornados dos parâmetros FROMFILE TOKEY,INCCHAR e INCREL.

Se uma máscara for definida para a coluna que é usada por qualquer um desses parâmetros, o valor damáscara será retornado de FROMFILE e usado pelo parâmetro que pode resultar em resultadosinesperados.


|

|

||

OmniFind Text Search Server for DB2 for i:

O OmniFind Text Search Server for DB2 for i (5733-OMF) versão 1.3 ou superior permite que os clientescriem um índice de procura de texto por meio de uma coluna de uma tabela que está protegida peloRCAC.

Após um índice de procura de texto ser criado, as funções SQL integradas CONTAINS e SCORE podemser usadas para executar procuras de texto completo por meio da coluna indexada. Os clientes devemestar cientes das considerações a seguir ao criar um índice de procura de texto por meio de uma colunaque está protegida por um RCAC.v Um servidor de procura de texto executa a tarefa de indexação e procura de documentos; os dados

indexados são armazenados fora do DB2 como arquivos de fluxos no sistema de arquivo integrado.Como os dados indexados são armazenados fora do DB2, os usuários que têm acesso ao servidor deprocura de texto poderia possivelmente reconstruir documentos confidenciais a partir do índice.

v Os dados são trocados com o servidor de procura de texto usando protocolos de rede que não sãocriptografados, os certificados digitais não serão verificados.

v Um índice de procura de texto requer que a tabela base contenha uma ou mais colunas de identificaçãoque são uma chave primária, índice exclusivo ou ROWID. A coluna de identificação é usada paraidentificar uma linha específica ao interagir com o servidor de procura de texto ou um administrador;os valores serão armazenados na tabela de migração de dados e poderão ser retornados dosprocedimentos administrativos. Quando um índice de procura de texto for criado por meio de umatabela que é protegida por RCAC, a coluna de identificação deve conter um valor gerado, como umROWID ou uma coluna de identidade. Isso permite que linhas individuais sejam identificadas usandoinformações não confidenciais. Para obter mais informações, consulte o OmniFind Text Search Serverfor DB2 for i .

Usando o RCAC em Arquivos Lógicos MultiformatadosUm arquivo lógico de multiformato contém mais um formato de registro ou mais de um arquivoespecificado na palavra-chave PFILE (DDS) de um arquivo lógico.

Para abrir um arquivo lógico que tem mais de um arquivo especificado na palavra-chave PFILE, oscritérios a seguir devem ser atendidos:1. Cada permissão ou máscara no mesmo arquivo físico baseado deve ter um nome de correlação

exclusivo.2. Como os nomes de permissões e máscaras na mesma biblioteca devem ser exclusivos e não podem

usar o nome da máscara ou permissão para determinar uma correspondência entre duas tabelas. Emvez disso, a correspondência está usando o nome de correlação. O nome de correlação que é usadopara a "mesma" permissão ou máscara que é aplicado a diversos arquivos físicos baseados deve ser omesmo para cada arquivo.

3. O RULETEXT para uma permissão ou máscara correspondente deve ser o mesmo. Em casos em quenenhum nome de correlação está especificado na permissão ou máscara, o RULETEXT é normalizadopara usar o nome da tabela como o nome de correlação. Portanto, a única forma de forçar RULETEXTa ser o mesmo entre duas permissões e máscaras é usar o mesmo nome de correlação explícito.

4. Cada máscara ou permissão correspondente entre as tabelas deve ser definida com as mesmas opçõesde analisador:v Formato de data/hora e separadorv SRTSEQ e LANGIDv DECFLTRNDv Ponto decimal e DECRESULTv CCSID de RULETEXT

5. O RCAC para cada arquivo físico baseado deve estar no mesmo estado ativo ou inativo.6. Cada máscara ou permissão deve estar no mesmo estado ENABLED/DISABLED como sua

correspondência nos outros arquivos físicos baseados.

Administração 43

Neste exemplo, LF1 está baseado em PF1, PF2 e PF3 e cada definição usa o nome de correlação PERM1para que o código de verificação SQL possa identificá-los como sendo equivalente.

CREATE SCHEMA MY_LIBSET SCHEMA MY_LIBCREATE TABLE MY_LIB.PF1 (COLUMN1 INT)CREATE TABLE MY_LIB.PF2 (COLUMN1 INT)CREATE TABLE MY_LIB.PF3 (COLUMN1 INT)

DDS for LF1FMT LF .....A..........T.Name++++++.Len++TDp......Functions++++++++++++++

R RECORD1 PFILE(PF1 PF2 PF3)COLUMN1

K COLUMN1

ADDLIBLE MY_LIBCRTLF FILE(MY_LIB/LF1) SRCFILE(MY_LIB/QDDSSRC)

CREATE PERMISSION PF1_P1 ON MY_LIB.PF1 AS PERM1 FOR ROWS WHERECURRENT_USER = ’USER3’ ENFORCED FOR ALL ACCESS



CREATE MASK PF1_M1 ON MY_LIB.PF1 AS MASK1FOR COLUMN COLUMN1 RETURNCASE WHEN COLUMN1 > 55000 THEN 0 END



ALTER TABLE PF1 ACTIVATE ROW ACCESS CONTROLALTER TABLE PF2 ACTIVATE ROW ACCESS CONTROLALTER TABLE PF3 ACTIVATE ROW ACCESS CONTROL

ALTER TABLE PF1 ACTIVATE COLUMN ACCESS CONTROLALTER TABLE PF2 ACTIVATE COLUMN ACCESS CONTROLALTER TABLE PF3 ACTIVATE COLUMN ACCESS CONTROL

Propagação de Dados MascaradosExecutar uma operação de inserção ou atualização em uma tabela base com o controle de acesso decoluna ativo, a operação pode falhar, porque os dados são os dados mascarados.

Isso pode acontecer quando os dados a serem inseridos ou atualizados contêm o valor mascarado e osdados mascarados foram selecionados em uma tabela com o controle de acesso da coluna ativa e aseleção foi feita na mesma instrução SQL. Como um exemplo, presuma que TABLE1 e TABLE2 tenham ocontrole de acesso da coluna ativa e para a inserção, selecionar na TABLE2 retornaria os dadosmascarados. A instrução a seguir retornaria um erro:INSERT INTO TABLE1 SELECT * FROM TABLE2

A instrução falharia com SQ20478 – O controle de acesso de linha ou coluna não é válido.

Entretanto, suponha que para este exemplo, TABLE1 e TABLE2 contenham duas colunas, NAME e SSN.Para o usuário que está fazendo o INSERT, a máscara é definida para retornar a sequência‘XXX-XX-nnnn’ ao consultar TABLE2.SELECT NAME, SSN INTO :name, :ssn FROM TABLE2;INSERT INTO TABLE1 VALUES(:name, :ssn);

Este mesmo tipo de problema também pode ocorrer se o usuário estiver executando um aplicativo debanco de dados nativo. Um READ da TABLE2 seguido de um WRITE na TABLE1 poderia resultar nosdados mascarados gravados no arquivo. Ou no caso de uma atualização, mesmo se a coluna SSN não sedestinar a alterar na UPDATE, o registro que está sendo atualizado contém o valor mascarado para acoluna SSN e ela é alterada.


Duas soluções para evitar que os dados mascarados sejam fornecidos:1. Acionador BEFORE.2. Restrição CHECK.

Solução de Acionador Before

A solução do acionador verifica os novos dados gravados em uma coluna e configura condicionalmente acoluna para o valor atual ou o configura como DEFAULT.

Este é um exemplo de um acionador before de inserção/atualização para evitar dados mascarados:CREATE SCHEMA MY_LIBCREATE TABLE MY_LIB.EMP_INFO

(COL1_name CHAR(10) WITH DEFAULT ’DEFAULT’,COL2_ssn CHAR(11) WITH DEFAULT ’DEFAULT’)

/********************************************************************//* Crie uma máscara para dar COL2_ssn para DBMGR, mas para qualquer outro usuário *//* mascare a coluna. Esta tabela conterá um acionador para assegurar que *//* a coluna possa nunca conter um valor mascarado. *//********************************************************************/

CREATE MASK MASK_SSN ON MY_LIB.EMP_INFOFOR COLUMN COL2_ssnRETURNCASEWHEN VERIFY_GROUP_FOR_USER(SESSION_USER, ’DBMGR’) = 1

THEN COL2_ssnELSE ’XXX-XX-’||SUBSTR(COL2_ssn,8,4)

ENDENABLE

ALTER TABLE MY_LIB.EMP_INFO ACTIVATE COLUMN ACCESS CONTROL

CREATE TRIGGER PREVENT_MASK_SSN BEFORE INSERT OR UPDATE ON MY_LIB.EMP_INFOREFERENCING NEW ROW AS N OLD ROW AS OFOR EACH ROW MODE DB2ROWSECUREDWHEN(SUBSTR(N.COL2_ssn,1,7) = ’XXX-XX-’)BEGINIF INSERTING THEN SET N.COL2_ssn = DEFAULT;ELSEIF UPDATING THEN SET N.COL2_ssn = O.COL2_ssn;END IF;

END

Tentar uma operação de inserção ou atualização faz com que o acionador BEFORE seja executado eassegure-se dos dados corretos na coluna COL2_ssn.

Solução de Restrição de Verificação

A solução baseada na restrição de verificação fornece uma nova sintaxe SQL para permitir que aespecificação de uma ação seja executada quando uma violação da condição de verificação de restrição deverificação ocorrer em vez de retornar um erro irrecuperável. Entretanto, se a condição de verificaçãocontinuar falhando após a ação ser tomada, um erro irrecuperável será retornado e a instrução SQLfalhará com a falha de restrição existente, (SQLSTATE=23513, SQLCODE=-545).

Uma restrição de verificação com a cláusula sobre violação está permitida em ambas as instruçõesCREATE TABLE e ALTER TABLE.

No exemplo a seguir, a máscara está definida para retornar um valor de ‘XXX-XX-nnnn’ para qualquerconsulta que não seja feita por um perfil do usuário no grupo ‘DBMGR’. A restrição verifica que a colunaSSN não tem o valor mascarado.

CREATE SCHEMA MY_LIBSET SCHEMA MY_LIBCREATE TABLE MY_LIB.EMP_INFO

(COL1_name CHAR(10) WITH DEFAULT ’DEFAULT’,COL2_ssn CHAR(11) WITH DEFAULT ’DEFAULT’)

Administração 45

CREATE MASK MASK_ssn ON MY_LIB.EMP_INFOFOR COLUMN COL2_ssn RETURN

CASEWHEN VERIFY_GROUP_FOR_USER ( SESSION_USER , ’DBMGR’ ) = 1THEN COL2_ssnELSE ’XXX-XX-’||SUBSTR(COL2_ssn,8,4)

ENDENABLE

/* Restrição de verificação para a atualização e inserção.*/ALTER TABLE MY_LIB.EMP_INFO

ADD CONSTRAINT MASK_ssn_preserveCHECK(SUBSTR(COL2_ssn,1,7)<>'XXX-XX-')ON UPDATE VIOLATION PRESERVE COL2_ssnON INSERT VIOLATION SET COL2_ssn = DEFAULT

Classic Query Engine (CQE) e SQL Query Engine (SQE)A seção explica as diferenças de processamento de consulta nativas e abertas entre CQE e SQE.

Para obter mais informações sobre as diferenças gerais entre CQE e SQE, consulte o artigo do IBMdeveloperWorks Diferenças entre o Mecanismo de Consulta Clássico (CQE) e o Mecanismo de Consulta

SQL (SQE) .

Diferenças entre nativo aberto e consulta SQL envolvendo RCACAlguns arquivos com RCAC não têm permissão de serem acessados.

Uma tentativa de usar o ambiente nativo para abrir um arquivo com RCAC ativo que envolve qualquerum dos seguintes não é permitida:v Um arquivo lógico com diversos formatos se a tentativa de abrir for para mais de um formato.v Um arquivo distribuído.v Um arquivo com acionadores de leitura.v Um arquivo descrito no programa.v Um arquivo ou consulta que especifica uma sequência de classificação ICU 2.6.1.

Uma tentativa de usar o SQL para consultar uma tabela com o RCAC ativo que envolve qualquer um dosseguintes não está permitida:v Um arquivo distribuído.v Um arquivo com acionadores de leitura.v Um arquivo ou consulta que especifica uma sequência de classificação ICU 2.6.1.

Ordenação de Conjunto de ResultadosA implementação de SQE pode resultar em uma ordenação do conjunto de resultados diferente paraWRKQRY, RUNQRY ou OPNQRYF.

Quando uma consulta é executada sem especificar explicitamente que os resultados sejam retornados emuma ordem específica, ambos os otimizadores SQE e CQE escolherão qualquer plano que melhor seexecutar. Isso significa que ambos SQE e CQE podem ou não retornar os resultados em uma ordem dearquivo-chave. Como o CQE tem muito menos recurso avançado que o SQE, é mais provável que retorneresultados em uma ordem em chave e que o SQE tem menos probabilidade de retornar os resultados emuma ordem em chave. Assim, se uma consulta for especificada com WRKQRY, RUNQRY ou OPNQRYF ea ordenação da linha for importante, especifique explicitamente o(s) campo(s) chave e a ordenação docampo de chave.


||

|

http://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/IBM%20i%20Technology%20Updates/page/Classic%20Query%20Engine%20%28CQE%29%20and%20SQL%20Query%20Engine%20%28SQE%29%20Differences

http://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/IBM%20i%20Technology%20Updates/page/Classic%20Query%20Engine%20%28CQE%29%20and%20SQL%20Query%20Engine%20%28SQE%29%20Differences

Avisos

Estas informações foram desenvolvidas para produtos e serviços oferecidos nos Estados Unidos.

É possível que a IBM não ofereça os produtos, serviços ou recursos discutidos nesta publicação em outrospaíses. Consulte um representante IBM local para obter informações sobre produtos e serviços disponíveisatualmente em sua área. Qualquer referência a produtos, programas ou serviços IBM não significa queapenas produtos, programas ou serviços IBM possam ser utilizados. Qualquer produto, programa ouserviço funcionalmente equivalente, que não infrinja nenhum direito de propriedade intelectual da IBM(ou quaisquer outros direitos da IBM) poderá ser utilizado em substituição a este produto, programa ouserviço. Entretanto, a avaliação e verificação da operação de qualquer produto, programa ou serviço nãoIBM são de responsabilidade do Cliente.

A IBM pode ter patentes ou solicitações de patentes pendentes relativas a assuntos tratados nestapublicação. O fornecimento desta publicação não lhe garante direito algum sobre tais patentes. Pedidosde licença devem ser enviados, por escrito, para:

Gerência de Relações Comerciais e Industriais da IBM BrasilAv. Pasteur, 138-146BotafogoRio de Janeiro, RJCEP 22290-240

Para pedidos de licença relacionados a informações de DBCS (Conjunto de Caracteres de Byte Duplo),entre em contato com o Departamento de Propriedade Intelectual da IBM em seu país ou envie pedidosde licença, por escrito, para:

IBM World Trade Asia Corporation2-31 Roppongi 3-chome,Minato-kuTokyo 106,Japan

O parágrafo a seguir não se aplica a nenhum país em que tais disposições não estejam de acordo com alegislação local: A INTERNATIONAL BUSINESS MACHINES CORPORATION FORNECE ESTAPUBLICAÇÃO “NO ESTADO EM QUE SE ENCONTRA”, SEM GARANTIA DE NENHUM TIPO, SEJAEXPRESSA OU IMPLÍCITA, INCLUINDO, MAS A ELAS NÃO SE LIMITANDO, AS GARANTIASIMPLÍCITAS (OU CONDIÇÕES) DE NÃO INFRAÇÃO, COMERCIALIZAÇÃO OU ADEQUAÇÃO A UMDETERMINADO PROPÓSITO. Alguns países não permitem a exclusão de garantias expressas ouimplícitas em certas transações, portanto, esta disposição pode não se aplicar ao Cliente.

Estas informações podem incluir imprecisões técnicas ou erros tipográficos. Periodicamente, são feitasalterações nas informações aqui contidas; tais alterações serão incorporadas em futuras edições destapublicação. A IBMpode, a qualquer momento, aperfeiçoar e/ou alterar os produtos e/ou programasdescritos nesta publicação, sem aviso prévio.

Referências nestas informações a Web sites não IBM são fornecidas apenas por conveniência e nãorepresentam de forma alguma um endosso a esses Web sites. Os materiais contidos nesses Web sites nãofazem parte dos materiais desse produto IBM e a utilização desses Web sites é de inteira responsabilidadedo Cliente.

A IBM pode utilizar ou distribuir as informações fornecidas da forma que julgar apropriada sem incorrerem qualquer obrigação para com o Cliente.

© Copyright IBM Corp. 1998, 2015 47

Licenciados deste programa que desejam obter informações sobre este assunto com objetivo de permitir:(i) a troca de informações entre programas criados independentemente e outros programas (incluindoeste) e (ii) a utilização mútua das informações trocadas, devem entrar em contato com:

IBM CorporationAv. Pasteur, 138-146Botafogo,Rio de Janeiro, RJCEP 22290-240

Tais informações podem estar disponíveis, sujeitas a termos e condições apropriadas, incluindo em algunscasos o pagamento de uma taxa.

O programa licenciado descrito nesta publicação e todo o material licenciado disponível são fornecidospela IBM sob os termos do Contrato com o Cliente IBM, do Contrato Internacional de Licença doPrograma IBM ou de qualquer outro contrato equivalente.

Todos os dados de desempenho aqui contidos foram determinados em um ambiente controlado. Portanto,os resultados obtidos em outros ambientes operacionais poderão variar significativamente. Algumasmedidas podem ter sido tomadas em sistemas de nível de desenvolvimento e não há garantia de queestas medidas serão iguais em sistemas geralmente disponíveis. Além disso, algumas medidas podem tersido estimadas por extrapolação. Os resultados reais podem variar. Os usuários deste documento devemverificar os dados aplicáveis para o ambiente específico.

As informações relativas a produtos não IBM foram obtidas junto aos fornecedores dos respectivosprodutos, de seus anúncios publicados ou de outras fontes disponíveis publicamente. A IBM não testouestes produtos e não pode confirmar a precisão de seu desempenho, compatibilidade nem qualquer outrareivindicação relacionada a produtos não IBM. Dúvidas sobre os recursos de produtos não IBM devemser encaminhadas diretamente a seus fornecedores.

Todas as declarações relacionadas aos objetivos e intenções futuras da IBM estão sujeitas a alterações oucancelamento sem aviso prévio e representam apenas metas e objetivos.

Estas informações foram projetadas apenas com o propósito de planejamento. As informações aquicontidas estão sujeitas a alterações antes que os produtos descritos estejam disponíveis.

Estas informações contêm exemplos de dados e relatórios utilizados em operações comerciais diárias.Para ilustrá-los da forma mais completa possível, os exemplos incluem nomes de pessoas, empresas,marcas e produtos. Todos esses nomes são fictícios e qualquer semelhança com os nomes e endereçosutilizados por uma empresa real é mera coincidência.

LICENÇA DE COPYRIGHT:

Estas informações contêm programas de aplicativos de amostra na linguagem fonte, ilustrando as técnicasde programação em diversas plataformas operacionais. O Cliente pode copiar, modificar e distribuir estesprogramas de amostra sem a necessidade de pagar à IBM, com objetivos de desenvolvimento, utilização,marketing ou distribuição de programas aplicativos em conformidade com a interface de programação deaplicativo para a plataforma operacional para a qual os programas de amostra são criados. Essesexemplos não foram testados completamente em todas as condições. Portanto, a IBM, não pode garantirou implicar a confiabilidade, manutenção ou função destes programas. Os programas de amostra sãofornecidos "NO ESTADO EM QUE SE ENCONTRAM", sem garantia de nenhum tipo. A IBM não deveser responsabilizada por nenhum dano causado pelo uso dos programas de amostra.

Cada cópia ou parte destes programas de amostra ou qualquer trabalho derivado deve incluir um avisode copyright com os dizeres:


© (nome da empresa) (ano). Partes deste código são derivadas dos IBM Corp. Sample Programs.

© Copyright IBM Corp. _insira o ano ou anos_.

Informações sobre a Interface de ProgramaçãoEsta publicação de Administração do banco de dados documenta Interfaces de Programação desejadasque permitem que o cliente grave programas para obter os serviços do IBM i.

Marcas RegistradasIBM, o logotipo IBM e ibm.com são marcas ou marcas registradas da International Business MachinesCorp., registradas em vários países no mundo todo. Outros nomes de produto e serviço podem sermarcas registradas da IBM ou de outras empresas. Uma lista atual de marcas registradas da IBM estádisponível na Web em “Copyright and trademark information” at www.ibm.com/legal/copytrade.shtml.

Adobe, o logotipo Adobe, PostScript e o logotipo PostScript são marcas ou marcas registradas da AdobeSystems Incorporated nos Estados Unidos e/ou outros países.

Linux é uma marca registrada da Linus Torvalds nos Estados Unidos e/ou em outros países.

Microsoft, Windows, Windows NT e o logotipo Windows são marcas registradas da MicrosoftCorporation nos Estados Unidos e/ou em outros países.

UNIX é uma marca registrada da The Open Group nos Estados Unidos e em outros países.

Java e todas as marcas registradas e logotipos baseados em Java são marcas registradas da Oracle, Inc.nos Estados Unidos e/ou em outros países.

Outros nomes de produtos e serviços podem ser marcas registradas da IBM ou de outras empresas.

Terms and conditionsPermissions for the use of these publications is granted subject to the following terms and conditions.

Personal Use: You may reproduce these publications for your personal, noncommercial use provided thatall proprietary notices are preserved. You may not distribute, display or make derivative works of thesepublications, or any portion thereof, without the express consent of IBM.

Commercial Use: You may reproduce, distribute and display these publications solely within yourenterprise provided that all proprietary notices are preserved. You may not make derivative works ofthese publications, or reproduce, distribute or display these publications or any portion thereof outsideyour enterprise, without the express consent of IBM.

Except as expressly granted in this permission, no other permissions, licenses or rights are granted, eitherexpress or implied, to the publications or any information, data, software or other intellectual propertycontained therein.

IBM reserves the right to withdraw the permissions granted herein whenever, in its discretion, the use ofthe publications is detrimental to its interest or, as determined by IBM, the above instructions are notbeing properly followed.

You may not download, export or re-export this information except in full compliance with all applicablelaws and regulations, including all United States export laws and regulations.

Avisos 49

http://www.ibm.com/legal/copytrade.shtml

IBM MAKES NO GUARANTEE ABOUT THE CONTENT OF THESE PUBLICATIONS. THEPUBLICATIONS ARE PROVIDED "AS-IS" AND WITHOUT WARRANTY OF ANY KIND, EITHEREXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO IMPLIED WARRANTIES OFMERCHANTABILITY, NON-INFRINGEMENT, AND FITNESS FOR A PARTICULAR PURPOSE.


Avisos 51

IBM®

Número do Programa: 5770-SS1

Impresso no Brasil

ibm i: administração de banco de dados · criando objetos de banco de dados .... . 4 assegurando...

Documents