Informix Dynamic Server 11.50 Fundamentals Exam 555 certification preparation, Part 1 - 1/2:

Planejamento e instalação do IDS

Este tutorial é o primeiro de uma série de tutoriais projetados para ajuda-lo a se familiarizar com todos os diferentes aspectos do IBM Informix Dynamic Server (IDS) e ajuda-lo a se preparar para o exame de certificação do IDS Fundamentals. Este primeiro tutorial cobre o planejamento e a instalação do IDS, sendo um ótimo lugar para começar a entender e usar o IDS com sucesso.

Antes que você comece

Este tutorial ensina sobre o planejamento de uma instalação IDS. Este planejamento consiste em questões chaves que precisam ser respondidas, bem como obter informações sobre o produto, suas capacidades em sua maquina, e qualquer configuração previa que possa ser necessária.

Depois de planejar a instalação vem a instalação real. Este tutorial fala sobre as diferentes opções  de instalações disponíveis em cada sistema operacional e continua após a instalação na configuração de sua primeira instancia IDS, bem como iniciar e parar essa instancia uma vez que ela esta configurada.

Com este conhecimento você deve ser capaz de planejar, instalar e iniciar uma instancia do Informix Dynamic Server que você pode utilizar com o resto desta serie de tutoriais. Você também deve estar preparado para responder aos tipos de perguntas feitas na seção 1 do exame de certificação.

Sobre esta série

Esta série complementar de nove tutoriais foi desenvolvido para ajuda-lo a se preparar para o exame de certificação IBM Informix Dynamic Server Fundamentals. Este exame de certificação irá testar seu conhecimento de administração de nível de entrada do IDS, incluindo o básico de SQL (Structured Quero Language - Linguagem de consulta estruturada), como instalar o IDS, como criar bancos de dados e objetos de banco de dados, segurança, transação, backup e procedimento de recuperação e tecnologias de replicação de dados e propósitos. Esses tutoriais fornecem uma base sólida para cada seção do exame. No entanto, você não deve confiar nesses tutoriais com sua única fonte de preparação para o exame.

Objetivos

Quando você terminar este tutorial, você deve poder:

• Explicar as diferenças entre as edições IDS;
• Descrever diferentes aplicações de Banco de Dados;
• Descrever a configurações e os controles de usuários, incluindo a separação de funções;
• Compreender os tipos de dados disponíveis no IDS, incluindo o tipo incorporado e extensível;
• Explicar e executar os diferentes métodos de instalação disponíveis na sua plataforma;
• Explicar e executar as etapas para configurar uma instância IDS;
• Explicar os diferentes estados de uma instancia IDS;
• Executar comandos para alterar os estados de uma instancia IDS;

Pré-requisitos

Estes tutoriais são escritos para futuros administradores de banco de dados (DBAs). Embora algum conhecimento básico do conceito de banco de dados possa ajudar, não é necessariamente necessário.

Requisitos de sistemas

Para completar este tutorial, você não precisara de uma copia do IDS. Entretanto, se você tiver uma disponível, você definitivamente obterá mais informações sobre os tutoriais. Se você não tem uma copia, você poderá obter a versão free no site da IBM.

Planejamento

Primeiro foram meus pais, depois meu conselheiro da escola secundaria, meus professores da faculdade, meu treinador de negócios e a lista continua; mas todos eles me disseram essencialmente o mesmo: para ser bem sucedido, você precisa ter um plano. Quando se trata de implantação de banco de dados bem sucedida, o mesmo é verdade - você precisa planejar. Embora você possa não ter tempo para criar um plano, lembre-se de que ele pode salvar você muito mais tarde.

Então, esta primeira parte deste tutorial abrange a idéia de planejamento. Durante o planejamento, algumas das perguntas que você precisa perguntar incluem:

• Quais recursos eu preciso do Banco de Dados? 
• Quais tipos de aplicativos estou esperando conectar ao Banco de Dados?
• Quantos usuários existem, e de onde esses usuários se conectam?
• Que tipo de dados e qual a volumetria desses dados vou armazenar?
• Qual é o tempo de resposta esperado da minha aplicação?
• Vou utilizar o hardware existe ou um novo?
• Uma unica pessoa vai manter esse banco de dados, ou vou dividir papéis com uma equipe?

As perguntas podem continuar, mas vamos parar por agora. A intenção desta seção não é aprofundar nessas questões, mas fazer você pensar sobre elas e discutir alguns pontos de alto nível sobre alguns deles.

Edições IDS

O Informix Dynamic Server vem em quatro edições diferentes:

• Developer
• Express
• Workgroup
• Enterprise

O Developer Edition do IDS é um produto gratuito destinado apenas para desenvolvimento e teste de aplicações. Ele contém a maior parte da funcionalidade do Workgroup Edition, mas não possui capacidades de suporte técnico da IBM. Ele também possui limites de escalabilidade para processadores, memória e armazenamento.

A edição do Express destina-se a pequenas e médias empresas e está limitada a funcionar em sistemas operacionais Linux e Windows. Ele também contém a maior parte da funcionalidade da versão do Workgroup Edition com limitações de escalabilidade.

A versão Workgroup Edition é destinada as empresas de medio porte ou servidores departamentais de uma empresa. Está disponível para varias versões do UNIX/Linux, bem como para Windows e MAC OS X. Workgroup Edition adiciona funcionalidades adicionais, como o Enterprise Replication (ER) com algumas limitações e High-Availability Data Replication (HDR). Workgroup Edition também tem limites na escalabilidade.

A versão Enterprise Edition contém todas as funcionalidades do Workgroup Edition com escalabilidade ilimitada. Enterprise inclui todas as funcionalidades do HDR e ER, bem como funcionalidades adicionais para os recursos de disponibilidade continuo, otimização de armazenamento, LBAC entre outros.

Um das primeiras partes de um planejamento de banco de dados é decidir qual edição do IDS é necessária para suportar os requisitos de seu negócio.

Tipos de aplicação

As aplicações que se conectam a um Banco de Dados geralmente são dividas em duas categorias:

• Online Transaction Processing (Processamento de transações Online), melhor conhecida como OLTP
• Decision Support System (Sistema de Apoio à Decisão), melhor conhecido como DSS, mas as vezes chamado de Data Warehousing

"Então qual a diferença?" você se pergunta. vamos ver alguns exemplos.

OLTP

OLTP - O processamento é como um aplicativo de Call Center. Quando você liga para sua operadora de cartão de crédito ( ou um Help Desk de qualquer tipo), o atendente na linha geralmente pede-lhe algo que é exclusivo da sua conta, como o numero da conta. Esse número de conta é utilizado para pesquisar no banco de dados para obter alguns registros associados apenas a você. Poderia ser apenas um registro - talvez a informação da sua conta; ou pode ser uma dúzia, como as informações de sua conta mais as últimas 15 transações de sua conta. De qualquer forma, ele é projetado para ser uma busca rápida que traz de volta os dados em questão de alguns segundos ou menos. Embora possa trazer de volta uma dúzia de linhas com dados de várias tabelas, as linhas que retornam são apenas uma fração de uma fração do numero de linhas que são mantidas no banco de dados.  As 20 linhas que o aplicativo pode ter retornado não são, portando, nada comparadas aos 200 milhões de registros na tabela. Isso não é para fazer se sentir pequeno no grande esquema de coisas; estou apenas tentando apontar um par de elementos chaves para um sistema do tipo OLTP. Isto:

• Retorno de algumas linhas de uma consulta
• Ter um tempo de resposta muito rápido - geralmente alguns segundos ou menos
• Utilização de indices únicos para obter um conjunto de registros
• Um ambiente de tipo leitura e escrita
• permitir conexões de muitos usuários

Systema OLTP foi projetado para serem sistemas de leitura e gravação. Aplicativos de usuários, como  o help desk do cartão de credito, não selecionara somente dados do banco de dados, mas também frequentemente atualizara (update) e inserirá (insert) novos dados.

DSS ou data warehousing

Consultas tipo DSS, por falta de um melhor termo, são consultas de tipo de relatórios. São consultas mais pesadas, mais longas. Tomando o exemplo da empresa de cartão de crédito acima, o CEO da empresa quer:

• Descobrir a quantidade de  transações de cartão de crédito ocorreram no último mês
• Ter um relatório de todos os clientes que estão inadimplentes em suas contas

Observe que essas consultas não estão associadas a um determinado cliente. A primeira consulta pode usar apenas uma tabela para obter seus dados (ou pode usar varias), mas é necessário fazer uma pesquisa muito maior ao longo de um período de dados para obter seus resultados durante o mês, e depois agrega os dados para obter o resultado final. A segunda consulta é semelhante a primeira, porem traz muito mais dados.

Muitas pessoas pensam em consultas de tipo DSS como consultas que retornam um livro de dados. No entanto, isso não é verdade. Dos exemplos, a primeira consulta é uma consulta DSS, mas retorna somente uma linha, um valor, de fato da conta. A segunda consulta pode retornar muitos dados, dependendo da quantidade de pessoas inadimplentes daquela conta.

Os elementos chaves associados com uma consulta DSS são:

• Consultas longas; pode ser minutos ou horas
• Utilização de mais recursos
• Quantidade maiores de linhas retornadas que correspondem aos critérios da consulta
• Maior agregação dos dados (sum, min, max, count, e assim por diante)
• Utilização de seqüencial scan nas tabelas, uma vez que grandes conjuntos de dados estão envolvidos.

Os ambientes DSS são ambientes de somente leitura. Embora que os dados tenham que ser inseridos no sistema de alguma forma, geralmente são cargas com grandes quantidade de INSERT, uma vez, se o sistema não for atualizado ou atualizado com pouca frequência.

Portanto, não categorize uma consulta pela quantidade de dados retornado, mas sim pelos elementos chaves da própria consulta.

O modelo de dados que é utilizado durante o projeto do banco de dados também é muito importante. O IDS pode tirar proveito de três modelos de dados:

• Modelo de dados relacionais - Modelo típico OLTP
• Modelo de dados objeto relacional - Adiciona ao modelo de dados relacionais as opções de extensibilidade do IDS (tipo de dados estendido, rotinas definidas pelo usuário, tipos definidos pelo usuário, agregados definidos pelo usuário e assim por diante)
• Modelo de dados dimensional - Modelo típico DSS, suporte ao processamento analítico online (OLAP)

Embora nos ambientes de hoje, um único banco de dados não é necessariamente um ambiente OLTP ou DSS, é sempre uma boa ideia tentar descobrir qual será o tipo de aplicação principal para o seu banco de dados, e siga um caminho de design que corresponda a esse tipo.

Para acomodar o fato de que muitos bancos de dados tem ambos os tipos de aplicativos conectados a eles ao mesmo tempo, o IDS possui parâmetros configuráveis para ajudar o desempenho das consultas OLTP e DSS em execução no mesmo banco de dados.

Users

Outra parte do planejamento é cuidar dos requisitos do usuário.

As questões básicas a serem feitas são:

• Preciso de usuários ou grupos especiais para o software?
• De onde conectara os usuarios?
• Quantos usuários espero se conectar simultaneamente?

A importância de responder a estas três perguntas não é apenas boa para o planejamento do banco de dados, mas também para o planejamento dos requisitos de hardware.

O IDS no Unix/Linux requer uma conta de usuário "informix", bem como um grupo "informix" criado na máquina de instalação. O Windows reduz esse requisito e permite um usuário "informix"ou o usuário de um sistema local e um "Informix-Admin". Durante a instalação no Windows, você pode escolher qual conta de usuário você deseja usar.

Por padrão, o usuário "informix" é considerado o "superusuário" do IDS. Tem acesso a tudo e pode fazer tudo o que precisa ser feito no IDS.

O IDS utiliza autenticação externa de usuário, o que significa que ele não possui usuários configurados internamente no software, mas depende de outros recursos para ajuda-lo a autenticar um usuário. Estes recursos externos podem ser o mecanismo de autenticação do Sistema Operacional (SO) da maquina onde o IDS esta sendo executado, LDAP, MS Active Directory ou o Pluggable Authentication Module (PAM).

Nota: Independentemente a forma que você escolheu para a autenticação, a coisa importante é lembrar que TODOS os usuários que precisam acessar o banco de dados precisam ter uma conta e senha com um mecanismo de autenticação externo para que o banco de dados possa autenticação-los e permitir-lhes acessar os dados. Isso pode levar há um planejamento importante, independente se você tiver duas contas de usuários conectando ou 2000 contas de usuários conectados.

Como mencionado anteriormente, por padrão, o usuário "informix" é o "superusuário" da instalação do IDS. No entanto, certas especificações exigem que o poder administrativo seja dividido em vários usuários, com cada usuário tendo um subconjunto da administração total. Isso é conhecido como role separation (separação de função) e esta dividido em duas categorias:

• Tarefas administrativas para pessoas que executam a instancia
• Tarefas de auditoria para pessoas que auditam o que está acontecendo na instancia

Role separation deve ser ativada durante a instalação do software, definindo a variável de ambiente INF_ROLE_SEP antes de iniciar o processo de instalação, ou ativar durante o processo de instalação interativa. Role separation só pode ser desativado desinstalando ou reinstalando o IDS. Role separation utiliza contas de usuários do Windows e contas de grupos no Unix/Linux. Se o Role separation foi ativada, o processo de instalação pedirá as informações necessárias para essas contas de usuários e grupos.

Os três usuários que participam da Role separation são:

• Database System Administrator (DBSA) - Controla as operações gerais da instancia
• Database System Security Office (DBSSO) - determina o que será auditado
• Audit Analysis Officer (AAO) - monitora a auditoria

Outros usuários que não fazem parte da separação de funções, mas podem precisar de algum planejamento:

• Database Administrator (DBA) - gerencia os banco de dados da instancia
• Operating-System Administrator (OSA) - satisfaz os requisitos do Sistema Operacional
• System Users - qualquer usuário que precise acessar os dados

Tipos de dados

Parte do planejamento do banco de dados esta relacionado com os tipos de dados disponíveis. A maneira mais fácil de descrever como os dados são armazenados em um banco de dados é usando uma analogia de planilha eletrônica. Até agora, você esperava ter usado ou visto algum tipo de planilha ( como por exemplo, Microsoft Excel ). Quando você olha a planilha, ela é organizada em linhas e colunas de células. Quando você olha para uma coluna da célula (dados verticais), geralmente todos os dados da mesma coluna são semelhantes - uma coluna de datas ou uma coluna de valores de dinheiro - com um cabeçalho de coluna que descreve o que os dados significam.

Quando você olha para uma linha da célula (dados horizontais), todos os dados nas células em conjunto descrevem uma instancia especifica do que a planilha esta representando. No exemplo abaixo, esta planilha descreve os clientes da XYZ Shoe Store. Cada linha descreve informações sobre um cliente especifico, onde cada coluna descreve um conceito que esta sendo mantido sobre todos os clientes. Então, para cada cliente, você esta armazenando seu nome, idade, tamanho do sapato, a última compra de sapatos e quando ele comprou.

Exemplos de dados

Os bancos de dados não mantem dados em planilha, mas em tabelas. Tabelas, como planilhas, são construídas por linhas e colunas. Durante a definição da tabela, você especifica quais colunas de dados estão sendo mantidas e que tipo de dados cada coluna usa. Um tipo de dados definido restringe o tipo de dados que a coluna pode armazenar. Se você define uma coluna como INTEGER, então essa coluna não poderá conter letras; é obrigado a apenas conter números inteiros. As linhas da tabela são adicionadas à medida que os aplicativos começam a armazenar dados nas colunas da tabela. Os dados são armazenados uma linha por vez. No exemplo acima tem cinco colunas - a primeira coluna, Name,   definido como caracter/string; a coluna Age definido como integre; a coluna Shoesize definido como decimal; a coluna LastTransDate definido como date; e a coluna LastTransAmt definido como money.

Agora que você ja possui uma ideia de como os tipos de dados são utilizados, vamos dar uma olhada nos tipos de dados que estão disponíveis no IDS.

Tipo de dados disponíveis 

• Tipos de dados incorporados
• BIGINT - Números inteiros de -(2⁶³ -1) até 2⁶³ -1
• BIGSERIAL - Números inteiros de -(2⁶³ -1) até 2⁶³ -1, automaticamente incrementado pelo server; as vezes utilizado como uma chave primaria de substituição 
• BLOB - Binary Large Object de até 4 TB de tamanho, armazenando objetos em seu formato nativo
• BOOLEAN - valores 'T' ou 'F'; pode ser testado em expressões
• BYTE - versão antiga do BLOB com 2³¹ byte, teoricamente limitado porem na pratica o limit é determinado pela capacidade de seu disco
• CHAR(n) - armazena 'n' caracteres de dados; se o valor é maior que n, preenche em branco até o tamanho 'n'
• CHARACTERVARYING(m,r) - compatível com ANSI VARCHAR
• CLOB - Character Large Object de até 4TB de tamanho; armazena dados de caracter
• DATE - data do calendario; o formato padrão é MM/DD/YYYY; pode ser modificado com a variável de ambiente DBDATE; especifica um ponto no tempo.
• DATETIME - data do calendario e tempo; formato padrão YYYY-MM-DD HH:MM:SS.FFF; pode ser modificado com a variável de ambiente DBTIME; especifica um ponto no tempo.
• DECIMAL(p,s) - valores decimais, onde 'p' é um numero total de dígitos e 's' é o numero de dígitos à direita do ponto decimal
• NUMERIC(p,s) - como o DECIMAL
• DOUBLE PRECISION - como o FLOAT
• FLOAT - números de ponto flutuante de dupla precisão com até 17 dígitos significativos
• IDSSECURITYLABEL - um VARCHAR(128) utilizado somente com Label Based Access Control (LBAC)
• INTEGER - números inteiros de -(2³¹ -1) até 2³¹ -1
• INT8 - números inteiros de -(2⁶³ -1) até 2⁶³ -1
• INTERVAL - mesmo formato do DATETIME, porem especifica um período de tempo
• LVARCHAR(m) - comprimento de caracter longo com 'm' sendo o tamanho máximo; use apenas o espaço necessário para armazenar dados até o tamanho 'm', tamanho máximo de 2GB quando usado com UDT, senão o máximo de 32K
• MONEY(p,s) - assim como o valor DECIMAL, exceto formatado com caracteres de dinheiro, o padrão é $ e . , mas pode ser alterado com a variável de ambiente DBMONEY
• NCHAR(n) - armazena dados de caracteres de comprimento fixo, mas inclui o uso do Global Language Support (GLS) para armazenar conjuntos de caracteres de um único byte e de vários bytes suportados pelo LOCALE do banco de dados; também permite o uso de sequencias de agrupamento local.
• NVARCHAR(m,r) - como o VARCHAR, porem com características especiais como o NCHAR
• REAL - como o SMALLFLOAT
• SMALLFLOAT - números de ponto flutuante de precisão única com aproximadamente nove dígitos significativos
• SERIAL - números inteiros -(2³¹ -1) até 2³¹ -1, incrementado automaticamente pelo server
• SERIAL8 - como o SERIAL com um range de -(2⁶³ -1) até 2⁶³ -1
• SMALLINT - números inteiros de -32767 até 32767
• TEXT - versão antiga do CLOB com um numero máximo de 2GB
• VARCHAR(m,r) - campo de comprimento de caracter variável com 'm' como o tamanho máximo (até 255) e 'r' como o menor espaço reservado; se o valor que esta sendo armazenado for menor que 'r', o valor será preenchido com espaço até o tamanho 'r'; se o valor for maior que 'r' e menor que 'm, então ele usara apenas o espaço necessário para armazenar o valor
• Tipo de dados estendido
• Tipo de dados complexo
• Linhas
• Coleção
• Tipos de dados definido pelo usuário
• Tipos distintos 
• Tipos opacos

Os tipos de dados de compilação são considerados atômicos, o que significa que eles não podem ser divididos em pedaços pequenos. Cada tipo de dados incorporado tem suas próprias características que o tornam único.

A listagem 1 fornece um exemplo de como utilizar a compilação de  tipo interno ao criar a tabela de cliente (dados da tabela 1):

Listagem 1. Utilizando o tipo de compilação

CREATE TABLE customer 

(

   Name CHAR(55),

   Age INTEGER,

   Shoesize DECIMAL(3,1)

   LastTransDate DATE,

   LastTransAmt MONEY(5,2)

);

Tipos de dados extendidos

Uma vez que os tipos de dados incorporados não podem abranger todos os tipos possíveis que os usuários desejam armazenar, IDS tem a capacidade de ampliá-los combinando os conjuntos integrados ou adicionando novos tipos de dados definidos pelo usuário. A categoria de tipo de dados complexo é composta por dois tipos de dados conhecidos como row e collection.

A melhor maneira de descrever um tipo de dados ROW é que ela imita uma linha em uma tabela, mas você coloca toda essa linha em uma única coluna. Portanto, é um tipo de dados de várias partes composto pelos tipos de dados incorporados. Não é mais atômico. Os tipos de dados ROW podem ser nomeados ou renomeados.

Exemplo:

Usando a XYZ Shoe Store do exemplo acima, talvez você queira armazenar o nome completo do cliente - primeiro, meio e último. Em vez de criar três colunas diferentes - uma para cada parte - você pode criar uma única coluna que tenha três partes.

O tipo de dados COLLECTION é, na verdade, uma categoria de três tipos de dados subjacentes chamados de set, multiset e list. O tipo de dados COLLECTION permite que grupos de dados, todos do mesmo tipo de dados, sejam armazenados juntos em uma única coluna.

Exemplo:

Usando a XYZ Shoe Store do exemplo acima, talvez você queira armazenar as marcas favoritas de sapatos dos clientes. Você não quer criar várias colunas porque você não sabe qual é a quantidade de colunas que você precisa. Algumas pessoas têm apenas uma marca favorita; outras pessoas tem cinco marcas favoritas quando se trata de sapatos. Um vez que todos as marcas são apenas cadeias de caracteres, eles são todos os mesmo tipo de dados. Então, você pode criar uma coluna chamada FavBrands de tipo SET que armazena dados de sequencia de caracteres. Agora uma única coluna pode armazenar tantas marcas favoritas dos clientes. Com SQL, você pode entrar e selecionar todos os clientes cujos FavBrands incluem a Nike, independentemente da quantidade de marcas favoritas listadas. Você selecionaria um tipo SET, já que o SET não permite COLLECTION duplicados. Não faz sentido ter um valor 'Nike', 'Keds', 'Nike'. Ambas as listas MULTI-SET permitem duplicadas. COLLECTIONS não permitem elementos nulos, então, ao definir uma COLLECTION, a restrição NOT NULL de deve ser especificada.

A listagem 2 fornece um exemplo para criar a tabela CUSTOMER usando as idéias de ROW e COLLECTION acima:

CREATE TABLE customer

(

   Name ROW( fname CHAR(15),  mi CHAR(1),  lname CHAR(35)),

   Age INTEGER,

   Shoesize DECIMAL(3,1),

   LastTransDate DATE,

   LastTransAmt MONEY(5,2)

   FavBrands SET(CHAR(10) NOT NULL)

);

Depois de fazer as mudanças, meus dados da tabela pareceriam algo como:

Tipo User-Defined

Embora os tipos incorporados e os tipos complexos possam cobrir muitos dos dados que um usuário deseja armazenar, é possível que novos tipos de dados sejam necessários. Novas aplicações e tecnologias trazem novas coisas que podem precisar de novos tipos de dados. Então, ao invés do IDS decidir quando é bom adicionar um novo tipo de dados, o IDS permite você adicionar novos tipos de dados sempre que necessário. Esses tipos de dados são conhecidos como tipos User-Defined ou UDTs. Você projeta isso, você diz ao IDS como interagir com ele, e você possui ótimas funcionalidades novas.

Se tudo na vida fosse tão fácil, incluindo isso, então todos poderiam estar fazendo isso. Na verdade, não é necessariamente difícil; Há várias coisas que você precisa fazer para que tudo funcione. Mais disso surgirá, pois este tutorial continuara a discutir UDTs e funções de suporte para UDTs. Então vamos voltar para UDTs....

Como visto na lista de tipos de dados disponíveis acima, o primeiro tipo de UDTs que você possui é chamado de um tipo DISTINCT. Simplificando, um tipo DISTINCT é apenas a renomeação do tipo de dados incorporado. Isso herda as características básicas do tipo incorporado, mas não as funções de suporte.

Exemplo: CREATE distinct type Shoesize AS DECIMAL(3,1):

Como Shoesize está sendo definido como um decimal, assumirá as características de armazenamento do tipo decimal. No entanto, nem tudo que você pode fazer com um valor decimal faz sentido fazer com um valor de Shoesize. Um exemplo seria a adição. Não faz sentido adicionar dois tamanhos de sapatos para outro tamanho de sapato. A função de adição (+) é considerada uma função de suporte em IDS. Como o IDS não sabe se as funções de suporte terão sentido para o tipo DISTINCT recém-definido, ele simplesmente desabilita automaticamente todas as funções de suporte no tipo DISTINCT.  Por isso, você também não pode comparar um valor de tamanho de sapato com um valor decimal. Comparar o valor também é considerado parte da funcionalidade de suporte. Embora o tamanho do shoesize seja definido como um decimal, eles são considerados dois tipos diferentes (DISTINCT) que não podem ser comparados. Se você quiser comparar um valor decimal com um valor de shoesize, você deve primeiro fazer um Cast em um deles para se tornar o mesmo tipo do outro, e então a comparação pode ser feita.

Então, você se pergunta: "Se nenhuma função de suporte é suportada neste novo tipo de dados 'DISTINCT', qual a vantagem que isso me traz?". Bem, você pode ter algo especial que você pode fazer com Shoesizes, como dizer se um é maior do que outro. Este é um mal exemplo, uma vez que o tamanho do sapato segue um valor incremental normal, tal como valores decimais. No entanto, diga como você fez para incorporar os valores XS, S, M, L, XL e XXL também. Você teria que mudar SHOESIZE de um decimal para um tipo caracter. Mas agora, se você quisesse ver se o tamanho do sapato de um cliente aumentou ou diminuiu desde a sua ultima compra, você poderia confiar mais no pedido normal (alfabeticamente neste caso). Se você tentou confiar nos pedidos em ordem alfabética, então o gráfico de tamanho de sapatos seria L, M, S, XL, XS, XXL. Mas esse não é o caso porque você sabe que XS é o menor da lista de tamanho de sapatos. Uma vez que você não pode confiar nas funções incorporadas do IDS para ajudar com isso, você precisa de uma alternativa. A alternativa do IDS é permitir a escrita de rotinas externas que podem ser chamadas em SQL normal.
Assim, você poderia escrever uma rotina para fazer a comparação de tamanho de sapatos para você. Essas novas rotinas são conhecidas como User-Defined Routines (UDRs). Este tutorial abrange UDRs um pouco mais tarde.

O outro tipo de UDT é conhecimento como um tipo de dados OPAQUE. Assim como o nome descreve, um tipo OPAQUE é um novo tipo que o IDS não entende nada. Não só o tipo de dados deve ser descrito como IDS, algo como uma estrutura em C, mas você também precisa dizer ao IDS como estrutura deve ficar no disco, como converte-lo entre o formato do disco e o formato de exibição, como indexa-lo, e todas as funções de suporte que você deseja usar para isso. As pessoas sempre perguntam, "Se eu tiver que fazer tanto trabalho, porque eu deveria usar o IDS enquanto que eu posso escrever minha própria aplicação?" Embora os tipos de dados OPAQUE possam ter muito trabalho para configurar, eles tem uma recompensa, você automaticamente tem acesso a todas as demais funcionalidades do banco de dados. Depois de definir as funções de suporte, IDS pode utilizar  esse tipo em qualquer lugar em instruções SQL normal, Fazendo com que pareça como qualquer  tipo de função interna. Então agora você tem integridade de transação, backup e restore, armazenamento, funcionalidade de usuários, integração com outros tipos de dados, e tudo mais que já é incorporado no Sistema de Gerenciamento de Banco de Dados (SGBD).

Um excelente exemplo de usar os tipos OPAQUE é o GeoSpatial Datablade que define um tipo de dados Geopoint, que armazena coordenadas geográficas em quatro dimensões. A função de suporte em torno dessa solução é analisar a distância, proximidade, interseção, e outras funções baseadas em pontos geográficos. Essas funções podem ser incluídas dentro de instruções SQL normais para que os dados de caracteres, dados de pontos geográficos, e qualquer outro tipos de dados por sair no mesmo conjunto de resultados.

Rotinas definidas pelo usuário

As funções de suporte para qualquer UDT podem ser escritas em C, Java, ou Store Procedure Language (SPL). De fato, ele não para com UDTs. Um DBA pode criar uma UDR pra suportar tipos de dados internos.

Exemplo:

A função de agregação (rotina) média (AVG) para tipos de dados numéricos incorporados, ignora completamente os valores NULL quando ele faz cálculos.  Então, talvez você analise que precise de uma rotina AVG que possa ler valores NULL e converte-los em zeros e inclui-los no cálculo. Você pode escrever uma UDR que sobreponha a função AVG interna e utilizar sua nova rotina para tipos de dados internos, UDTs ou ambos.

Observer no exemplo, que os termos funções e rotinas são sinônimos. Isso ocorre porque o termo rotina é apenas uma categoria que engloba dois elementos reais: FUNCTIONS e PROCEDURES. Então, quando você cria uma rotina, você realmente usa as instruções CREATE FUNCTION ou CREATE PROCEDURE.

Por que os dois, você se pergunta. Por definições de padrões ANSI, uma função pode levar e retornar valores, onde uma PROCEDURE pode levar valores, mas não deve retornar nada. Um exemplo de uma FUNCTION seria a FUNCTION SUM - você passa 2 mais 2, e isso retorna 4. Um exemplo de uma PROCEDURE seria um UPDATE no salário de uma pessoa - você passa o novo salário, mas não precisa devolver nada ao usuário. A partir da versão 11.50, O IDS não é completamente compatível com ANSI, pois ainda exibe valores de retorno das PROCEDURES. Isso é feito para compatibilidade com versões anteriores. Certifique-se de manter os padrões ANSI em mente ao escrever quaisquer rotinas futuras.

Datablades

Antes de encerrar o tópico de extensibilidade de UDTs e UDRs, Vejamos um conceito mais conhecido como datablade. Como discutimos o que são UDTs e UDRs, O conceito Datablade deve ser fácil. Um Datablade é o empacotamento de UDTs e UDRs por uma razão específica. A razão é geralmente porque eles têm algo comum, como uma dada funcionalidade. Um exemplo seria o Geodetic Datablade. Dentro do Geodetic Datablade são todos os UDTs e UDRs necessários para fazer armazenamento geoespacial, recuperação, indexação e todos os tipos de análise. 

Notas

Vamos fingir por um segundo que você precisa de uma nova impressora para seu computador. Você se dirige para a loja de periféricos de computador, escolhe uma impressora que quiser e leva-o para casa com você. Quando chegar em casa, você sobre a caixa, e a primeira coisa que você faz é retirar o Manual do Usuário, lê a capa do manual e, em seguida, desembala o resto. Certo? Se você é como os outros 99% de nós, você pode retirar o manual, mas você o deixa de lado porque está muito animado com a sua impressora conectada. Bem, os fabricantes de periféricos descobriram isso e, para ajudar, eles colocaram algo mais no topo da caixa - uma coisa que eles chamam de "Leia-me primeiro" papel com 10 ou 20 passos fáceis para deixar a impressora funcionando.

IDS incorporou a mesma idéia em duas partes. O primeiro é um arquivo README.html que está no diretório principal quando você extrai o software da mídia de instalação. O arquivo README possui instruções de instalações básicas, bem como links para vários outros arquivos de documentação conhecidos como "release notes". (Este tutorial discute mais sobre a instalação na seção "instalação".). O release notes descreve novos recursos, lançamentos suportados, valores de parâmetros do kernel, recursos obsoletos e informações sobre problemas de conhecimento e suas soluções alternativas. Se você está atualizando de uma versão de IDS para outra, os releases notes são um ótimo lugar para aprender sobre mudanças feitas entre lançamentos. Se você está instalando novo, eles ainda são um ótimo lugar para encontrar informações sobre esta versão e outros locais para obter informações. Se você está herdando um produto já instalado, as notas de versão ainda podem ser encontradas em um subdiretório do diretório onde o IDS está instalado. Vamos chamar o diretório onde IDS está instalado de INFORMIXDIR. Então, os release notes de versão seriam encontradas em /INFORMIXDIR/release no Unix / Linux ou C: \INFORMIXDIR\release no Windows. Na verdade, eles seriam encontrados em um conjunto de diretórios localizados sob isso. Esses diretórios localizados seguem uma convenção do Global Language Support  (GLS). Se você estiver instalando a versão em inglês dos EUA do produto no Unix/Linux, a estrutura de diretório será semelhante a: /INFORMIXDIR/release/en_us/0333.

Dependendo do seu país e idioma, os dois últimos subdiretórios podem ser nomeados de forma diferente, mas ainda terão uma estrutura similar. Dentro desse diretório final, você encontrará o releve notes de versão, tanto em formato html quanto em texto, para todos os produtos IBM Informix instalados nesta máquina.

Locales

A última parte da seção do release notes começou a trazer uma idéia de suporte de linguagem global - Global Language Support (GLS). Nem todos os países do mundo falam a mesma língua, tem o mesmo alfabeto, ou utiliza o mesmo dinheiro. Portanto, você não deve esperar que o software seja apenas em um idioma. É ai que entra o Locales. A "localização" é o processo de transformação de um produto para atender a um ambiente cultural específico. Como parte da localização, você cria arquivos de recursos específicos da cultura, arquivos de tradução para mensagens e erros, arquivos de tradução para a interface do usuário do produto e definir os formatos de data, hora e dinheiro.

Definir um local leva um passo adiante; mas também especifica um conjunto de códigos (mapeamento de caracteres) e seqüência de agrupamento (ordem de classificação do dicionário). Essa separação permite que várias localidades existam para a mesma localização, semelhante a um país que tenha várias regiões. Todas as regiões falam a mesma língua, mas cada região tem sua própria variação de dialetos. O tipo de produto e hardware determinará a localidade padrão que é usada ao criar um banco de dados. Isso é conhecido como DB_LOCALE. Para o produto IDS nos Estados Unidos e instalado no Unix/Linux, o DB_LOCALE padrão é en_us.8859-1 (também conhecido como en_us.819). Se instalado no Windows, o DB_LOCALE padrão é en_us.1252. Se você deseja alterar o DB_LOCALE padrão, ele deve ser especificado no tempo de criação do banco de dados definindo a variável de ambiente DB_LOCALE na sessão que executa a instrução SQL CREATE DATABASE.

A codificação de caracteres ISO8859-1 é para o alfabeto Latino, que muitos países compartilham.

Embora o DB_LOCALE especifique a localização padrão para o banco de dados, os clientes que se conectam ao banco de dados têm a capacidade de usar uma localização diferente. Os clientes têm a variável de ambiente CLIENT_LOCALE que especifica a localidade do cliente. Para que o banco de dados e o cliente troquem informações, suas localidades devem ser iguais ou compatíveis (conversíveis).

Ao armazenar dados de caracteres para GLS, é importante usar o tipo de dados NCHAR e NVARCHAR, em vez do tipo de dados CHAR e VARCHAR. Os tipos de dados "N" permitem o agrupamento (ordem de classificação) dos dados com base no CLIENT_LOCALE, em vez de apenas no DB_LOCALE. A instrução SQL SET COLLATION permite que um cliente mude isso dinamicamente dentro de sua sessão atual.

A listagem abaixo mostra os conceitos de formatação dos locais GLS. Como muitos países utilizam o alfabeto latino, muitos dos conjuntos de códigos para esses países são compatíveis. Depois de criar a tabela Shoe Store acima e popula-la com uma linha, executei a seguinte instrução SELECT SQL várias vezes, mas alterei a variável de ambiente CLIENT_LOCALE para algo diferente, mas ainda compatível com o DB_LOCALE para cada execução.

Observe como, ao mudar o CLIENT_LOCALE, o formato de dados é diferente. (o formato, não os dados). Você precisa ter cuidado ao usar isso porque uma data é uma data em qualquer país, mas $85 dólares americanos não são iguais a 85 reais brasileiros. Além disso, o motivo pelo qual todas as datas surgiram no formato Month Day Year é devido à chamada para a função TO_CHAR com a formatação definida como% B% d% Y.

Abaixo mostra a saída se você remover a chamada para a função TO_CHAR e redor novamente  a instrução SQL com o CLIENT_LOCALE determinado:

Para recapitular, as bibliotecas GLS permitem que um aplicativo atenda às expectativas culturais dos dados sem ter que mudar o aplicativo. GLS locais, através do uso de tipos especiais de dados, variáveis de ambiente e instruções SQL, permitem a formatação dinâmica e a triagem de dados para atender aos padrões dos clientes. Tudo isso pode ser feito sem ter que escrever o aplicativo cliente de forma diferente para cada país/região do mundo em que ele possa ser usado.

Sumario

Nessa primeira parte desse tutorial, você estudou sobre:

• Os dois tipos diferentes de aplicativos usados em comparação ao sistema RDBMS
• Como a autenticação do usuário é tratada no IDS
• Todos os diferentes tipos de dados que o IDS está disponível para usar
• Extensibilidade de IDS através de UDTs e UDRs
• Arquivos "Read-me first" e release notes no IDS
• Localização GLS