PT90209B - Bases de dados relacionais - Google Patents

Description

A presente invenção refere-se a bases de dados computadorizadas e, mais particularmente, a bases de dados relacionais.

Uma base de dados é usada para armazenar grandes quantidades de dados para leitura futura da informação registada a pedido de um utilizador. Um utilizador pode ser um programa de aplicação ou um utilizador final que interage com o sistema da base de dados através de um dispositivo de entrada. Os grupos de dados relacionados são coraummente designados por ficheiros de dados, ou tabelas, como de usa comummente nas bases de dados relacionais. As linhas de dados numa tabela são designadad por registos lógicos e as colunas de dados designam-se por campos. Num sistema de base de dados relacional, o utilizador distingue os dados apenas como tabelas e nao em qualquer outra forma organizacional, por exemplo uma estrutura de dados hierárquica.

Estes sistemas de bases de dados tipicamente in- 1 -

cluem um programa de computador, comummente desigiado por gestor da base de dados, para armazenar, editar, actualizar, inserir, eliminar e ler dados, em resposta a vários comandos introduzidos através da interface de utilizador. Um gestor de base de dados trata todos os pedidos provenientes dos utilizadores da base de dados para executar as várias funções atrás enumeradas.

Especificamente, relativamente à leitura ulterior dos dados registados, inventaram-se numerosas linguagens de com putador para a formulação de comandos de busca ou interrogações” às quais o gestor da base de dados é susceptivel de dar resposta fornecendo os dados pedidos. Estas interrogações eram basicamente instruções de busca codificadas de forma a fazer com que um computador e o gestor da base de dados associado ex£ cutem a busca desejada.

Vários problemas têm estado ligados com estas Iíji guagens para a formulação de interrogações de bases de dados.

Em primeiro lugar, naiitas das linguagens de interrogação dife. riam das linguagens de programação convencionais. 0 utilizador de bases de dados com experiência de programação era assim obri. gado a aprender um conjunto de comandos inteiramente novo preci samente para retirar da base de dados com significado. Os utilizadores sem experiência, tais como muitos operadores de terminais que também não têm qualquer espécie de experiência com computadores, eram assim forçados a aprender uma forma de programação de computadores precisamente para a sua interacção com as bases de dados. Além disso, tais linguagens de interrogação exigiam o conhecimento de regras de sintaxe e de semântica altamente complexas, limitando desse modo ainda mais o número de pessoas capazes de ler com êxito dados registados das bases de dado, o que sé podia ser feito por pouco pessoal altamente trei nado e caro. Isso por sua vez afectava da maneira adversa a utilidade de tais sistemas de computador e inibia seriamente o seu uso por uma vasta gama de pessoas.

- 2 A linguagem estruturada de interrogação (SQL - Structured Query Language) é uma linguagem de interrogação estruturada para utulizadores finais para ser utilizada para estabelecer a interface com o gestor da base de dados para leitura da informação na mesma, e uma linguagem de programação de bases de dados que pode ser encaixada num programa de aplicação para aceder aos dados na base de dados através do gestor da base de dados. A SQL é uma via fácil para especificar o tipo de informação de que se necessita.

Uma linguagem representativa dessas linguagens de interrogação é a SQL^W (Standard Query Language-Linguagem de interrogação normalizada), pormenorizada na Draft Proposal, ANA Database Language SQL, Standard X3. 135-1986, American National Standard Institute, Inc. 1430 Broadway, New York, New York 10018. Apresenta-se uma descrição pormenorizada da SQL em IBM Database 2 SQL Reference Document Number SC26-4346-3, IBM Corporation, sendo aqui as duas incorporadas por referência.

Por exemplo, para um utilizador criar uma tabela (16) com linhas e colunas de dados contendo nomes e endereços, como se mostra na fig. 1, o utilizador gera a declaração CREATE TABLE para definir a base de dados como:

CRETE TABLE DIRECTORY (NAME CHAR(20)

ADDRESS CHAR(50)

A declaração GREATE TABLE é um exemplo de uma declaração de definição de dados SQL. Cada declaração CREATE TABLE indica o nome da tabela que se pretende criar, os nomes das suas colunas e os tipos de dados dessas colunas. A declaração CREATE TABLE é uma declaração executável, isto é, se a declaração CREATE TABLE for introduzida num terminal por um utilizador, o sistema construirá a tabela nesse instante. Ini cialmente, a tabela está vazia, isto é, não haverá quaisquer

- 3 linhas de dados. Porém, utilizando a declaração SQL INSERT, o utilizador pode criar a tabela como está representada na fig. 1.

Tendo criado a tabela e introduzido registos na mesma, o utilizador pode ler ulteriormente dados a partir da tabela através de declarações de manipulação de dados SQL.

Não sé pode criar*· se em qualquer instante uma tabela por um utilizador por meio da declaração CREATE TAHLE atrás representada, como a tabela existente pode também ser alterada em qualquer altura pelo utilizador por adição de coluna^ por meio da declaração ALTER TAHLE. Por exemplo, se se pretender alterar a tabela (16) da fig. 1 por adição de uma coluna City and state (cidade e estado), a declaração ALTER STATE pode aparecer como segue:

ALTER TAHLE DIRECTORY

ADD CITY_STATE CHAR(20)

A declaração anterior adiciona a coluna CITY_ STATE à tabela DIRECTORY. Depois de ser especificado o nome da coluna, especifica-se o tipo de dados dessa coluna. Alguns tipos de dados são como se segue. As três últimas categorias, CHAR, VARCHAR e LOMG VARCHAR serão aqui desigoadas como tipos de dados da carateres:

INTEGER números inteiros de palavras completas em binário com sinal (precisão 31 bits)

SMALLIN números inteiros de meias palavras em binário com sinal (precisão 15 bits)

DECIMAL número decimal em representação compacta com sinal, com a precisão de p dígitos, admitindo-se p casas decimais à direita da vírgula

FLOAT número em vírgula flutuante, com sinal, com precisão dupla

- 4 CHAR(n) sequencia de caracteres de comprimento fixo com o comprimento de n caracteres

VARCHAR(n) sequencia de caracteres de comprimento variável com o comprimento máxí mo de n caracteres que nao excede 4 000 octetos

LONG VARCHAR sequência de caracteres de comprimento variável nao excedendo 32 700 octetos.

Para informação adicional nesta área, sugere-se a seguinte referencia, que aqui se incorpora por referência, C.J. Date, An Introduction do Database Systems , Volume 1, Four th Edition, Addison-Wesley Puhlishing Company, Inc., 1986.

Quando um utilizador inserir os dados como se mo_s tra na fig. 1, o sistema de processamento nao vê os dados como estão de facto representados, mas sim sob a forma de uma sequên cia de bits de ”1” e 0^B que são interpretados de várias maneiras, conforme o tipo de dados, pelo sistema de processamento.

Se os dados forem texto ou carácter, o sistema de processamento interpreta da sequência em unidades fixas, onde cada unidade representa um carácter, um número ou qualquer outro sinal gráfico de texto. Estas unidades são comummente chamadas pontos de código e têm sempre uma largura com um número de bits específico, por exemplo 8 bits (1 byte” ou octeto). Uma estratégia de pontos de código com um só octeto, isto é um esquema de codificação com pontos de código de um só octeto, permite 256 pontos de código diferentes possíveis, cada um com uma das 256 combinações possíveis de 8 bits 1 e ”0”. Com 256 pontos de código diferentes, podem representar-se até 256 caracteres, algarismos, símbolos, etc. diferentes.

Cada grupo de 256 pontos de código é designado por página de código. Uma página de código é suficiente para representar a maior parte dos caracteres e algarismos da língua in&Lesa, mais alguns símbolos adicionais de uso comum. Na fig. 2 está representada uma página de código (21).

A página de código de octetos simples atrás descrita é muito suficiente para representar a lingua inglesa· Porém, visto que a língua japonesa contém mais de 6000 símbolos, o sistema de codificação anterior nao pode ser usado para repre sentar todos os símbolos diferentes.

í portanto necessário um sistema de codificação mais rico, por exenplo o proporcionado numa versão da Japanese Industrial Standard, dennominada Shifted-Jis

As normas Shifted-Jis descrevem o conjunto dos caracteres japoneses e as páginas de código para os mais de 6 000 símbolos gráficos usados na língua japonesa escrita· As normas Shifted-Jis estão ainda descritas nas publicações intituladas IBM Registry Graphics Gharacters Sets and Code Pages”, documento Ne C-H 3-3220-050, e IBM Japanese Graphic Character Set, KANJI numero C-H 3-3220-024. Na fig. 3 está representado um exemplo de página de código (22) para a língua japonesa.

Com referência à fig. 3, os códigos hexadecimais 0x00 a 0x7E representam símbolos de um octeto simples, tais como algarismos e o alfabeto inglês dos grupos de símbolos superiores (upper case) e de símbolos inferiores (lower case). Os códigos hexadecimais OxAl a OxDP representam símbolos japoneses de octeto simples do chamado alfabeto Katakana de meia-dimensão. Os códigos hexadecimais 0x81 a 0x9? e OxEO a OxFC podem considerar-se como octetos de introdução que dão acesso a cerca de 11 000 a 12 000 símbolos japoneses. Os octetos de introdução são os primeiros octetos de sequências de octetos duplos. Por conseguinte para estes cerca de 11 000 símbolos japoneses são necessários dois octetos para representar um símbolo. Isso define o esquema de codificação de octetos duplos.

significado da página de código representada na fig. 3 para os diferentes simbolos japoneses pode avaliar-se com mais alguma informação básica da língua japonesa.

- 6 Ha tres tipos de caracteres japoneses asados na língua japonesa. Sao o Kanji, o Hiragana e o Katakana. Os carac teres Kanji são caracteres ideográficos. Um carácter Kanji único ou uma lista de caracteres Kanji podem representar uma palavra. Há cerca de 7 000 caracteres Kanji definidos para utilização nos computadores.

Os caracteres Hiragana e Katakana são caracteres fonéticos. Cada um deles representa um som. Há aproximadamente 50 caracteres Hiragana e aproximadamente 50 caracteres Katakana. Os caracteres Hiragana são usados para ligar caracteres Kan ji, por exemplo, como sufixos tais como -ing. Os caracteres Katakana sao usados para palavras que não têm um equivalente Kanji» ΡθΓ exemplo palavras estranhas à língua japonesa, tais como algumas palavras inglesas. Estas palavras seriam então representadas foneticamente pelos caracteres Katakana, isto é, com base na maneira como se pronunciaria a palavra estrangeira. Como regra geral, o Hiragana é usado para exprimir sufixos ou terminações de palavras gramaticais e o Katakana é usado para significados especiais tais como dar ênfase a uma palavra ou exprimir um termo estrangeiro. Uma frase escrita típica em japonês é uma mistura de caracteres Kanji, Hiragana e Katakana.

Como atrás se descreveu com referência à fig. 5, os caracteres Katakana eram caracteres de octeto simples OxAl a OxDP, enquanto que os caracteres Hiragana e Kanji são carac teres de octeto duplo. É evidente que seria comum que os japoneses misturassem numa mesma expressão caracteres de octeto simples e caracteres de octeto duplo.

Por exemplo, um carácter Kanji pode ter mais de uma pronúncia, conforme o seu contexto dentro da expressão. No entanto, há apenas uma pronúncia para cada carácter Hiragana ou para cada carácter Katakana. Assim, uma palavra japonesa pode ser representada como um carácter Kanji (carácter de octeto duplo), se existir, ou pela sua pronúncia escrita em Hiragana (carácter de octeto duplo) ou em Katakana (carácter de octeto simples)

Além disso, no Japão é também usado o alfabeto latino, como se representa pelos códigos hexadecimais 0x41 a 0x?4 na fig. 3· 0 Romaji, que consiste em 26 símbolos fonéticos e usado para escrever palavras inglesas e para escrever a pronuncia de palavras japonesas· 0 Romaji é usado primariamente nos domínios técnicos e profissional para construir sons para os quais não se dispõe de caracteres japoneses. Uma lista de caracteres Romaji (octetos simples) representa unicamente uma pronúncia japonesa de uma palavra japonesa, de outro modo representada por um caracter de octeto duplo. A frase japonesa escrita é uma mistura de Kanji, Hiragana, Katakana, Romaji, números e outros caracteres. Isso inclui uma mistura de caracteres de octeto duplo e de caracteres de octeto simples.

Analogamente, as colunas numa base de dados relacional incluiriam também uma mistura de caracteres de octeto simples e de octeto duplo, se a base de dados aceitar também a língua japonesa.

Os produtos de bases de dados relacionais com base na SQL têm uma opção de instalação que especifica se é neces sário processar dados mistos (com octeto sinrçjles e com octeto duplo). Se se especificar essa opção, o caracter é tratado como misto. Como tal, se se especificar a opção mista, todos os dados em todos os campos são tratados como dados mistos, embora alguns campos possam conter dados de octeto simples. Em ambientes, tais como na língua japonesa que exigem dados com conjuntos de caracteres de octeto duplo, todos os caracteres têm de ser considerados como sendo dados de conjuntos de caracteres de octeto duplo e dados de conjunto de caracteres de octeto simples mistos. São necessários algoritmos mais complexos para processar dados mistos do que dados de osteto simples. Como consequên cia disso, o processamento de todas as colunas de dados numa base de dados relacional tem diminuído a sua eficácia se se especificarem dados mistos.

Um objecto da presente invenção consiste em aumentar a eficácia no processa mento de dados numa base de dados relacional quando houver dados da octeto simples e de octeto duplo misturados.

De acordo com um primeiro aspecto da presente invenção, proporciona-se um sistema de base de dados relacional que tem dados mistos, com dados de conjuntos de caracteres de octeto simples e com conjuntos de dados com octetos duplos, compreendendo o referido sistema um certo numero de colunas em pelo menos uma tabela do referido sistema de bases de dados relacional; e meios para designar selectivamente uma coluna na referida tabela como tendo apenas dqdos de um conjunto de caracteres de octeto simples.

De acordo com um segundo aspecto da presente invenção, proporciona-se um sistema de base de dados relacional que compreende um certo número de colunas numa tabela de dados, meios para especificar um certo número de tipos de dados de caracteres para cada uma das referidas colunas e meios para especificar um certo número de subtipos dos referidos tipos de dados de caracteres.

De acordo com um tereceiro aspecto da presente invenção, proporciona-se um processo para o processamento de uma tabela de dados mistos num sistema de base de dados relacional compreendendo o referido processo a etiquetagem com um marcador de uma coluna de dados como sendo apenas para dados de conjuntos de caracteres de octeto simples.

A presente invenção baseia-se no reconhecimento de que, anteriormente, nao havia um meio para especificar que certas colunas numa tabela seriam usadas apenas para dados de conjuntos de caracteres de octeto simples e que especificando assim tais colunas poderiam aplicar-se a essas colunas algfcritmos mais simples.

- 9 Numa forma de realização específica da presente invenção descrita mais adiante, proporcionam-se extensões pare a linguagem SQL existente, por adiçao de parâmetros optativos para a declaração CREATE TABLE e para a declaração ALTER TABLE para especificar um subtipo dos dados dos tipos de caracteres na base de um por coluna· 0 subtipo indica se os dados conterão dados mistos ou dados de octeto simples puros· Na forma de realização preferida, se o utilizador especificar a coluna para dados de octeto simples, o utilizador pode ainda especificar a página de código para os dados do conjunto de caracteres de octeto simples.. Se o utilizador especificar que a coluna é para dados mistos, o utilizador pode ainda especificar a página de código a usar para dados de conjuntos de caracteres de octeto simples e a página de código a usar para os dados de conjunto de caracteres de octeto duplo.

Assim, o esquema de codificação usado na forma de realização específica descrita mais adiante serve uma finalidade dupla. Verificando simplesmente se os atributos de página de código de octeto simples e da página de código de octeto duplo são zero ou não-zero numa coluna de caracteres nos catálogos do sistema de base de dados, o sistema ou uma aplicação podem deter mi nar se a coluna de caracteres está concebida para dados mistas ou para dados de octeto simples puros e, ao mesmo tempo, determinar a ou as páginas de código a usar para essa coluna. A etiqueta ou indicador que indica qual o subtipo de caracteres que está contido na coluna é a própria página de código e pode ser usada para fazer a tradução especial, etc. para a coluna.

Por exemplo, se o atributo de página de código de octeto simples tiver o valor nao-zero e o atributo da pagina de código de octeto duplo for um zero, a coluna foi especificada para apenas dados de conjunto de caracteres de octeto simples. Além disso, o valor não-zero do atributo da página de código de octeto simples seria o valor que especificava uma pa gina de código específica. Se ambos os atributos da página de código de octeto simples e da página de codigo de octeto duplo forem nao-zero, a coluna conteria dados mistos, quer dados de conjunto de caracteres de octeto simples, quer dados de conjunto de caracteres de octeto duplo. Além disso, os valores não-zero especificariam a página de código a usar para os dados de octeto simples e a página de código a usar para dados de octeto duplo· produto da base de dados e as aplicações de uti lizador estão assim em condiçoes de saber como tratar os dados numa coluna de caracteres, relativamente aos algoritmos de tratamento dos dados, tais como truncamento, sub-sequência, etc·

Se a coluna for apenas para dados de conjunto de caracteres de octeto simples, o tratamento dos dados pode ser bastante simplificado· Sem a presente invenção, a especificação de páginas de código separadas para as colunas permitiria que se aplicassen sequências de colação a uma coluna·

Descreve-se a seguir uma forma de realização específica da presente invenção, com referência aos desenhos anexos, cujas figuras representam:

A fig· 1, uma amostra de tabela de dados numa base de dados relacional;

A fig. 2, uma amostra de página de código usada para dados de octeto simples, por exemplo na língua ingLesa;

A fig· 3, uma amostra de página de código para a lín gua japonesa;

A fig. 4A e 4B, vistas gerais do sistema de base de da dos relacional segundo a presente invenção;

A fig. 5A, a declaração CREATE TABLE para especificar um subtipo do tipo de dados de caracteres para desigiar uma coluna como tendo dados mistos ou dados de octeto simples;

A fig. 5B, a declaração ALTER TABLE para especificar um subtipo do tipo de dados de caracteres

Δ fig.

A fig.

A fig.

A fig.

A fig.

A fig.

A fig.

A fig.

A fig.

A fig.

A fig.

A fig.

para desigaar uma coluna que tem dados mis tos ou dados de octeto simples;

6, um esquema de blocos dos componentes de um gestor da base de dados relacional segundo a presente invenção;

7, um fluxo grama para explicar o funcionamento da forma de realização;

8, um esquema de blocos que representa os com ponentes dos serviços de dados relacionais da forma de realização;

9» um diagrama das STSTABLES nos catálogos do sistema de base de dados da forma de realização;

10A, 10B, e 10G, um diagrama das STSCGLUMNS nos catálogos do sistema da base de dados;

11, um fluxograma da fase de análise lógica do funcionamento do compilador SQL· da forma de realização;

12, um fluxograma da fase de geração do funcio namento do compilador SQL·.

13A a 13E, fluxogramas pormenorizados que ilustram aspectos do funcionamento da forma de realização;

14, um fluxograma da execução do código gerado e a descrição compacta na forma de realização;

15, um fluxograma da actualização da SQ1DA com a página de código na forma de realização;

16A, um fluxograma de um algbritmo de truncamento para dados mistos;

16B, um fluxograma de um algoritmo de truncamento para dados de octeto simples;

A fig. 17, um fluxo grama de um algoritmo de sub-sequência para dados mistos; e

A fig. 18, o esquema de codificação em SQLQATA e SQLIND usado na forma de realização.

Começando com referência ao diagrama de blocos das fig. 4A e 4B, nelas está representado um esquema geral do aparelho de processamento que pode ser usado para a realização da presente invenção.

A fig. 4A representa uma arquitectura típica de um computador pessoal, tal como a configuração usada nos sistemas de computadores IBM Personal Systeny^· 0 ponto focal desta arquitectura compreende um microprocessador (l) que pode, por exemplo, ser um Intel 80286 ou 80386 ou um microprocessador semelhante. 0 microprocessador (l) está ligado a uma linha oranibus (2) que compreende um conjunto de linhas de dados, um conjunto de linhas de endereços e o conjunto de linhas de controlo Um certo número de dispositivos de entrada/saida (l/θ) ou dispositivo de memória ou armazenamento (3 a 8) está ligado à linha omnibus (2) através de adaptadores separados (9 ^a 14), respectivamente. Por exemplo, o vizualizador (4) pode ser o vizualizador a cores 8514 do IBM Personal System, no qual o adaptador (10) está integrado um painel plano. Os outros dispositivos (3) e (5 a 8) e os adaptadores (9) e (11 a. 14) são ou incluidos como partes de um IBM Personal Systei^/2 ou existem disponíveis sob a forma de opções da IBM Corporation para ligar por fichas. Por exemplo, a memória de acesso aleatório (6) e a memória fixa (7) e os seus adaptadores correspondentes (12) e (13) são incluídos como equipamento normal no sistema IBM Personal System/ /2, embora possam adicionar-se memórias de acesso aleatório para suplemento da memória (6), através de opçoes de ampliação de memória ligadas por fichas.

No interior da memória fixa (7) são armazenadas as várias instruções, conhecidas como sistema operativo básico de entrada/saida, ou BIOS, para execução pelo microprocessador (l). 0 BIOS controla as operações fundamentais do computador.

Um sistema operativo (15), tal como OS/2 é carregado na memória (6) e passa em conjunto com o BIOS armazenado na ROM (7). Os en tendidos na matéria compreenderão que o sistema de computador pessoal poderia ser configurado de modo que partes ou todo o BIOS fossem armazenados na memória (6) em vez de na ROM (7), de modo a permitir modificações do sistema básico por alterações introduzidas no programa BIOS, que seriam então facilmente carregáveis na memória de acesso aleatório (6).

Para mais informação sobre os produtos do sistema Personal Systen/2 e sobre o sistema operativo OS/2, sugerem-se os manuais de referência seguintes, que aqui se incorporam por referência. Technical Reference Manual. Personal Svstem/2 (Mortei 46.60 systems). IBM Corporation, part number 68X2224, order num ber S68X-2224. Technical Reference Manual. Personal Svstem/2 (Model 80) . IBM Corporation, part number 68X2256, order number S68X-2256. IBM Qperating System/2 version 1.0 Standard Edition Technical Reference. IBM Corporation, part number 6280201, ordei number 5871-AAA. Iacobucci, Ed, OS/2 Prograromer*s Cuide. McGraw Hill, 1988.

No aparelho, um programa de aplicação (20), tal como um gestor de base de dados relacional, pode também ser car regado na memória (6) ou ser residente nos meios (5). Cs meios (5) podem ser constituídos, mas nao se limitando a isso, por uma disquete ou um ficheiro em discos rígidos. 0 gestor da base de dados relacional (20) pode também ser considerado como uma extensão do sistema operativo (15)· 0 gestor da base de dados relacional (20) compreende um conjunto compreensivo de tarefas de gestor de base de dados relacional que proporciona instruções para o microprocessador (1) para permitir que o sistema representado nas fig. 4A e 4B execute as funções da base de dados relacional. Diz-se que um programa de aplicação (18) carregado da memória (6) passa em conjunção com o sistema operativo previamente carregado na memória (6).

ST

No sistema de processamento das fig. 4A e 4B, o operador acede ao gestor (20) da base de dados relacional através de teclas de controlo pelo operador, no teclado (5). 0 tecla do comanda o processador (1) que está ligado operativamente ao visualizador (4), bem como às memórias (5) e à memória (6), através da linha omnibus (2). Quando um utilizador interage atra vós do teclado (5) com um programa de aplicação que interage com o gestor (2) da base de dados relacional, o gestor (20) da base de dados relacional e os seus dados são afixados para o utilizador através do visualizador (4). Além da interacção de um utilizador com o gestor (20) da base de dados relacional, uma aplicação (18) poderá interagir com o gestor (20) da base de dados relacional através de comandos SQL na aplicação (18).

No sistema de base de dados relacional como atras se descreveu, o processamento dos dados de caracteres mistos e mais dispendioso que o processamento de dados de.caracteres com octeto simples porque os limites dos caracteres nao ocorrem necessariamente após cada octeto dos dados. Isso sigaifica que certas operações, as que envolvem o movimento de dados de caracteres, podem ser realizadas rapidamente para dados com octetos simples pelo simples movimento de um certo número de octetos de dados (caracteres) de um endereço para outro. Como os caracteres mistos podem sair dos limites de um octeto, os algo* ritmos para deslocar dados de um endereço para outro têm de ser obtidos por meio de algoritmos para determinar os limites dos caracteres e efectuar um processamento especial para manter a integridade dos dados dos caracteres.

Nesta forma de realização da presente invenção proporcionam-se meios para o utilizador especificar um subtipo do tipo de caracteres, na base de um por cada coluna, como dados de octetos simples ou dados mistos. 0 utilizador pode especificar o subtipo do tipo de caracteres da coluna quando a coluna está a ser criada, quer na instrução CREATE TABLE quer na instrução ALTER TABLE.

Como se mostra nas fig. 5A e 53, nelas estão representadas as instruções CREATE TAELE e ALTER TABLE (2) e (34) que um utilizador deverá usar para criar um subtipo (37,39) de tipo de dados de caracteres do nome da coluna (33,35) especificado. 0 subtipo EOR SBCS DATA (37) para o nome da coluna 1 (33,35) especifica o nome da coluna 1 para dados de conjuntos de caracteres com octetos simples. 0 subtipo EOR MIXED DATA (39) para o nome da coluna 2 (33,35) especifica o nome da coluna 2 para dados mistos de conjuntos de caracteres de octetos simples e de octetos duplos.

Estas instruções SQL (32,34) e os subtipos especificados nessas instruções sao processados na forma de realização da presente invenção da seguinte maneira. Eaz-se referencia S estrutura do núcleo (42) do gestor (20) da base de dados relacional representada na fig. 6, á estrutura dos serviços da base de dados relacional representada na fig. 8 e ao fluxo grama representada na fig. 7· pré-compilador (43) extrai as instruções SQL en caixadas do programa da fonte (18) e passa as mesmas para os dispositivos do sistema básico (41) do gestor (20) da base de dados relacional, fase (71), fig. 7. Os dispositivos (41) do sis tema básico do gestor (20) da base de dados relacional passam as declarações SQL através dos serviços de dados relacionais (25). Os serviços de dados relacionais (25) são a interface para o compilador SQL (24), que compila as instruções SQL, fase (73). 0 compilador SQL (24) gera um código susceptivel de ser interpretado, fase (74), que é executado pelo interpretador de tempo de funcionamento (52) dos serviços de dados relacionais (25), fase (75). Este código chama as rotinas de serviços de ca tálogos (54) dos serviços de dados relacionais (25) que actualizam os catálogos da base de dados (23), fase (16)·

As fases atrás referidas serão descritas mais adiante com referência ao pseudo-código e aos fluxogramas depois da discussão que vai seguir-se das componentes e funções estruturais do núcleo (42) do gestor (20) da base de dados relacional, fig. 6, e os componentes e funções estruturais dos serviços de dados estruturais (25), fig. 6 e fig. 8.

Os serviços de dados relacionais (25) providenciam a criação e a manipulação de tabelas a partir das instruções SQL CREATE TABLE e ALTER TABLE. Os serviços de dados relacionais (25) também gerem os catálogos da base de dados (23).

Os catálogos das bases de dados são eles próprios tabelas dentro da base de dados relacional e residem no interior da sistema de ficheiros onde reside a base de dados relacional, por exemplo nos meios de registos (5) da fig. 4A.

Um catálogo (23) da base de dados é um objecto secundário de base de dados que é estabelecido e mantido pelo gestor da base de dados. Todas as tabelas do catálogo são criadas quando se cria a base de dados e são realizadas praticamente como tabelas de dados de base relacionais. As tabelas dos catálogos nao são diferentes das tabelas criadas pelo utilizador a nao ser que são usadas e mantidas exclusivamente pelo núcleo, embora possam ser interrogadas pelo utilizador. Varias tabelas de catálogos sao mantidas pelo sistema e contêm informação acer ca das tabelas e dos programas do utilizador.

Os serviços de dados relacionais (25), fig. 6, são uma interface para o núcleo (42) do gestor (20) da fase de dados para o pré-compilador (43) e para as aplicações (18). 0 pré-compilador chama o compilador SQL (24) para compilar as instruções SQL. As aplicações executam (interpretam) as instruções SQL na sua forma compilada.

núcleo (42) do gestor da base de dados relacional compreende serviços de dados relacionais (25), o compilador SQL (24), serviços de divisão classificada/listagem (44), serviços de gestão de dados, gestor do índice (46), serviços de dados (47), serviços de protecção de dados (48), serviços do grupo de memórias tampão (48) e serviços do sistema operati30*

vo (50) compilador SQL compila as instruções SQL. 0 compilador SQL tem três funções principais no sistema e no processo segundo a presente invenção.

compilador SQL proporciona a análise lógica, a semântica e a geração de códigos. 0 analisador lógico efectua a verificação lexical e sintática e constroi a árvore de análise lógica. A função semântica inclui a consulta dos catálogos e a verificação semântica das instruções. Na fase de geração de códigos, gera-se um código contínuo juntamente com o re_s to da secção de acesso.

Os serviços de divisão classificada/listagem (44) proporcionam funções de gestão da divisão classificada e de relações temporárias (listagens). Os serviços de gestão de dados (45) proporcinam um modelo físico da base de dados e proporcionam a manipulação física das tabelas. 0 gestor do índice (46) proporciona a manipulação física do índice. Os serviços de dados (47) proporcionam a comparação de valores dos dados, a conversão de dados e a fusão de dados. Os serviços de protecção dos dados (48)proporcionam a gestão das transacçÕes, controlam a concorrência e a recuperação de dados. Os serviços do grupo de memórias tampão (49) proporcionam a gestão das memórias e ficheiros e as funções de entrada/saída. Os serviços de sistema operativo (50) proporcionam a gestão das memórias.

Os componentes dos serviços de dados relacionais (25) estão representados na fig. 8. A interface da aplicação (51) manipula e encaminha os pedidos provenientes do pré-compilador (45), fig. 6, das aplicações (18) e dos equipamentos.

interpretador (52) executa (interpreta) as instruções SQL na sua forma compilada usando o código contínuo para código obje£ to das instruções. 0 interpretador (52) chama a rotina apropriada para cada operador no código contínuo, tais como os ope radores da base de dados (acesso às tabelas, fusão de conjuntos de dados, união, etc.) e os operadores de expressões (adi18 -

cionar, comparar, etc.). 0 gestor do plano de acessos (53) gere os planos de acessos nos catálogos e na memória, e gere as secções de acessos nos catálogos e na memória. Os serviços de catálogos (54) são a interface para os serviços de gestão de dados (45) (fig. 6) para a manipulação dos catálogos. A execução de estatísticas (55) é a interface para os serviços de gestão de dados (45) (fig· 6) que recolhe dados estatísticos nas tabelas e índices.

Quando uma instrução CREATE TABLE (32) ou A1TER TABLE (34) contiver o parâmetro FOR MIXED DATA (39) ou o FOR SBCS DATA (37) numa coluna de caracteres (33,35), fazem-se as seguintes alterações nos catálogos da base de dados (23) representadas nas fig. 9 e 10A. A SYSTABLES (27) (fig.9) e a SYSCGLUMNS (28), fig. 10A, são duas tabelas da tabela (23) de catálogos da base de dados. Na SYSTABLES (27)_t Insere-se uma linha para cada tabela ou vista que é criada. Todas as tabelas de catálogos têm entradas nesta tabela, incluindo ela própria. Na SYSCOLUMNS (28), insere-se uma linha por cada coluna de cada tabela ou vista. Todas as tabelas dos catálogos têm entradas nesta tabela, também.

Com referência às SYSTABLES (27), fig. 9, na coluna PACKED_DESC (descrição compacta) (91), codifica-se um tipo de dados internos de CEAR MIXED, VARCHAR MIXED, ou LONG VARCHAR MIXED para a coluna como FOR MIXED DATA. Este tipo de dados internos é usado pelo gestor da base de dados para determinar se se deve aplicar o processamento de dados mistos a coluna de caracteres. Se nao se especificar nem FOR MIXED DATA nem FOR SBCS DATA, e se não especificar FOR BIT DATA, admite-se FOR MIXED DATED na versão de octetos duplos do produto.

FOR BITS DATA é usada na forma de realização da presente invenção para reter dados binários. Quaisquer dados binários numa coluna de caracteres que nao devam ser processados con» dados de caracteres sao especificados como FOR BIT DATA.Porém, noutras formas de realização da presente invenção, esta classificação adicional nao é necessária

Com referência a SYSCOLUMNS (28), fig. 10 A, na coluna COLTYFE (tipo de dados de colunas) (93), fig. 10A, codifica- se o tipo de dados SQL actual de CHAR, VARCHAR, LONG VARCHAR. Nas colunas CODEPAGE (94) e DBSCODEPG (95), fig. 10A, 10B, 10C, codifica-se a informação seguinte.

Se houver uma interrogação para o tipo de coluna (93) na tabela SYSCOLUMN (28) dos catálogos (23) do sistema da base de dados, verifica-se o seguinte. Se o tipo de coluna (93) nas colunas do sistema (28) indicar um tipo de dados de caracteres tais como CHAR, VARCHAR, LONG VARCHAR, então a coluna da página de código CODEPAGE (94) e a coluna da página de código do conjunto de caracteres de octetos duplos DBCSCODEFC (95), podem ser interrogadas para determinar o subtipo do tipo de caracteres.

esquema de codificação usado nesta forma de realização permite um processo rápido e eficiente de determinação do subtipo, como se mostra na fig. 10C. Se cada uma das colunas CODEPAGE e DBCSCODEPG (94) e (95) tiver o valor zero, en-’ tão o subtipo especifica FOR BIT DATA, que são dados que não se. rao processados como dados de caracteres. Se a coluna CODEPAGE (94) tiver um valor que não seja zero e a coluna DBCSCODEPG (95) tiver um valor zero, a coluna foi especificada para dados com um só octeto. Se a coluna CODEPAGE (94) tiver um valor que não seja zero e a coluna DBCSDATEPG (95) tiver um valor que não seja zero, a coluna á de dados mistos, que é o valor de omissão se o subtipo da coluna não foi especificado especificamente. Além disso, se o valor na coluna CODEPAGE (94) ou na coluna DBCSCODEPG (95) for um valor que não seja zero, esse valor diferente de zero será um valor que especifica uma página de código particular que deve ser usada para essa coluna da base de dados. No caso de FOR BIT DATA, não será especificada nenhuma página de código visto que esses dados não devem ser processados como dados de caracteres.

funcionamento da forma de realização especifica do sistema atras descrito está ilustrado no pseudocódigo seguin te e descreve-se com referência às fig. 11 a 15.

Abreviaturas:

CD - Column Description - descrição da coluna (em de_s crição compacta)

DDL - Data definition Lartguage - Linguagem de definição de dados

DMS - Data Management Services - Serviços de gestão de dados

I) Adicionar suporte para subtipos de caracteres MIXED e SBCS à instrução CREATE TAELE e ALTER TABT.E

II) Adicionar suporte para o atributo CODE PAGE na coluna

NOTA: As fases A) e B) são executadas uma vez, ”off-line” (separadamente), para criar um novo analisador lógico SQL.

A) Modificar a Tabela da Gramática do analizador lógico SQL para adicionar as produções seguintess

ColumnType = CharacterType CharacterOption CharacterOption =Empty =PorMixrd (gerar o nodo EOR OPTION) =PorSBCS (gerar o nodo POR OPTION)

PorMixed =POR MIXED DATA MixedOption

PorSBCS =POR SBCS DATA SBSCOPTION

MixedOption

SBCSOption

CodePage =Empty =(CodePage, CodePage/ =Empty = ( CodePage) =Integer

- 21 B) Gerar nova tabela de analisadores lógicos (utilizando o gerador separado de analisadores lógicos e a nova tabela da gramática).

C) Chamar o compilador SQL para compilar a instru ção CREATE TABLE ou ALTER TABLE (Fase do analisador lógico do compilador SQL)

Nota: A entrada é a instrução SQL

A saída ó a árvore de análise lógica.

/ * IP (instrução CREATE TABLE) * / / ^X Gerar árvore de análise lógica para instrução CREATE TABLE. * / / ^X ELSE (instrução ALTER TABLE) * / / * Gerar árvore de análise lógica para instrução

ALTER TABLE. * / / * ENDIF * / / * IP (presente parâmetro para FOR I-BXED ou POR SBCS) * / / * Gerar nodo POR OPTION na árvore de aná lise ifcógica * /

Com referência à fig. 11 e ao pseudocódigo como atrás se representa, vai descrever-se o funcionamento da fase do analisador lógico SQL do compilador SQL. Chama-se o compilador SQL para compilar as instruções SQL. Na fase do analisador lógico SQL, o compilador SQL gera um nodo da árvore de análise lógica para a instrução CREATE TABLE ou a instrução ALTER TABLE fase (101). Se tiver sido indicado POR MIXED ou POR SBCS ou POR BIT na instrução SQL, então gera-se (fases (103,105) ) uma árvore de análise lógica para POR OPTION. Se tiver sido definida um parâmetro da página de código na instrução SQL, fase (107), então gera-se (fase (109) ) um nodo da árvore de análise lógica da página de código.

(Fase da geração do código do compilador SQL)

Nota: A entrada e a árvore de análise lógica

- 22 A saída e a descrição em bloco actualizada e o código interpretável.

/ * IP (instrução CREATE TABLE) * / / * Armazenar EDI» CREATE TABLE Opcode em código contínuo * / / * ELSE (instrução ALTER TABLE) * / / * Armazenar DEL ALTER TABLE Opcode em código contínuo * / / * ENDIP * / / * Inicializar o endereço indicador transversal da árvore de análise lógica para o nodo da raiz da árvore de análise lógica * /

Com referência ã fig. 12 e ao pseudocódigo atrás indicado, descreve-se a fase de geração do código do compilador SQL. A árvore de análise lógica com todos os seus nodos tal como se gerou anteriormente na fig. 11 ó a entrada para a fase de geração do código, fase (111). Se a instrução SQL não for nem CREATE TABLE nem ALTER TABLE, fase (113), então processam-se as instruções SQL como usualmente, fase (115). Se a instrução SQL for a instrução CREATE TABLE ou a instrução ALTER TABLE, então cria-se o código operacional para essa instrução, fase (117). Durante a fase de geração do código, é endereçado o nodo da raiz da árvore de análise lógica, fase (119).

/ * TRA VERSE PARSE TREE * / / * DO WHILE ( nao se detectou nenhum erro e a árvore de análise lógica ainda necessita de ser atravessada) / / * SWITCH (tipo de nodo da árvore de análise lógica) ^x / / * agrupar o tipo de nodo de Header Column List (arranque de CDs) */ / * Chamar rotina para inicializar os campos de descrição compacta para inicializar CD * / / * END CASE ^x / / & agrupar coluna de tipos de nodos de identificadores de nomes * / / * Atribuir armazenamento para estrutura CD e nome da coluna * / / * IP (armazenamento atribuído com êxito) THEN * / / * estabelecer informação de colunas diversas * / / * Inicializar página de código CD Νδ. l para página de código SBCS da base de dados * / / * Inicializar a página de código CD N° 2 para página de código DBCS da base de dados * / / Actualizar o comprimento da descriçao em bloco / / * ENDIP * / / * END CASE * / / * agrupar tipo de nodo POR OPTION * / / * SWITCH (subtipo de POR OPTION) * / / * agrupar tipo de nodo FOR BIT DATA / / * SWITCH (tipo de coluna em CD (ajustar durante o processamento do nó anterior) ) * / / * agrupar tipo de coluna = CHAR MIXED */ / * Armazenar tipo de coluna CHAR no campo tipo CD / / * END CASE * / / * agrupar tipo de coluna VARCHAR

MIXED * / / * Armazenar tipo de coluna

VARCHAR no campo tipo CD */ / * END CASE * / / agrupar tipo de coluna = IONG VARCHAR MIXED ^X /

/ Armazenar tipo de coluna LONG VARCHAR em campo tipo CD * / / * END CASE * / /* Tipo de coluna ENDSWITCH * / /* Ajustar páginas de código CD Ní 1 e Nfi 2 para 0 ^X / / ^X END CASE EOR BIT * / / * agrupar tipo de nodo SINGLE BYTE CHARACTER SET * / / * SWITCH (tipo de coluna em CD (ajustar durante o processamento de nodo anterior) ) * / / * agrupai? tipo de coluna = CHAR MIXED*/ /* Armazenar tipo de coluna CHAR em campo tipo CD * / / * END CASE * / / * agrupar tipo de coluna = VARCHAR MLXED * / / * Armazenar tipo de coluna VARCHAR em campo tipo CD * / / * END CASE * / / * agrupar tipo de coluna » LONG VARCHAR MIXED * / / * Armazenar tipo de coluna LONG VARCHAR em campo tipo CD * / / * END CASE * / / * Tipo de coluna ENDSWITCH * / / * IP (foi especificada a página de código)

THEN * / / * Obter a página de código a partir da área de salvaguarda / / * Armazenar a página de código no campo da página de código CD Νδ 1 * / / * Armazenar 0 no campo da página de código CD Nfi 2 * / / * ENDIP * / ^SWaa.» / * END CASE SBCS * / / * agrupar tipo de nó MIXED CHARACTERS * / / * IF (a página de código foi especificada)

THEN ^x / / * Obter a página de código 2 a partir da área de salvaguarda ³⁵ / / * Armazenar página de código no campo da página da código N? 2 * / / Obter a pagina de código N°i a partir da area de salvaguarda * / / Armazenar a pagina de codigo no campo do codigo de pagina Ns l / / * ENDIF * / / * END CASE MIXED * / / * subtipo ENDSWITCH de FOR * / / * END CASE FOR OPTION * / / * Agrupar tipo de nodo de página de código * / / Salvaguardar identificador da pagina de codigo/ / * END CASE * / / * agrupar nodo de tipo de dados (cbar, varchar ...) por coluna * / /* SWITCH (tipo de dados) */ / agrupar tipo de dados CHAR / / * Armazenar tipo de coluna CHAR MIXED no campo tipo CD * / / * END CASE * / / * agrupar tipo de dados - VARCHAR * / /* IF (for especificado o conqarimento, isto á, xe este for um VARCHAR) THEN * / / Armazenar tipo de coluna VARCHAR MIXED no campo tipo CD / / * ELSE * / / * Armazenar tipo de coluna LONG VARCHAR MIXED no campo tipo CD * / / * ENDIF * / / * END CASE * /

/ * agrupar tipo de nodos CD (fim de definição de coluna) * / / * nenhuma acção * / / * END CASE * / / *ENDSWITCH tipo de nodo de árvore de análise lógica * / / * Incrementar o indicador da árvore de análise lógica para o nodo seguinte * / / * ENDWHILE * /

Com referência às fig. 13A a 13E e ao pseudocódigo atras listado, verificannse as fases seguintes, conforme o tipo de nodo. Se o nodo for uma coluna de cabeçalho, fase (121),, ó inicializada a coluna de descrição em bloco, fase (123). Se o nodo for um nodo de coluna, (fase 125), é atribuido o armazenamento para a descrição da informação da coluna na descrição em bloco, fase (127). Estabelece-se depois a informação da coluna, fase (129) e inicializam-se a página de código de um só octeto e a página de código de octeto duplo da base de dados, fases (131) e(133)« Actualiza-se depois o comprimento da descrição em bloco, fase (135)·

Se o nodo for uma opção FOR, tal como FOR BIT,

FOR SBCS ou FOR MIXED, fase (137), verifica-se o seguinte para todos os casos anteriores.

Se forem os nodos FOR BIT ou FOR SBCS, ou FOR MIXED, fase (137), verifica-se o seguinte para todos os casos anteriores.

Se forem os nodos FOR BIT ou FOR SBCS, fases (139) e (141) e o tipo de coluna for CHAR MIXED, fase (143), fig· 13B, então armazena-se CHAR no campo do tipo de coluna de descrição da coluna, fase (145)· Se o tipo de coluna for VARCHAR MIXED, fase (147), então armazena-se VARCHAR no campo do tipo de descrição da coluna, fase (149)· Se o tipo de coluna for LONG VARCHAR MIXED, fase (151), então armazena-se LONG VARCHAR no campo

do tipo de coluna da descrição da coluna, fase (153).

Voltando a referir a fig. 13A, no caso da opção POR BIT, fase (139), as páginas de código, quer para a página de codigo de um só octeto, quer para a página de código de octeto duplo, são ajustadas para zero, fase (155), fig. 13C.

No caso da opção POR SBCS, fase (141), fig. 13A, se o campo da página de código estiver especificado, fase (157), fig. 13 C, então a pagina de código é recuperada e armazenada na descrição da ooluna para a primeira página de código, a página de código ajustada para caracteres com um só octeto, fases (159) e (161). A página de código parâ octeto duplo é ajustado a zero.

Fazendo referência às fig. 13A e 13D, no caso em que esteja especificada a opção POR MIXED, fase (163), fig. 13A, e estiver além disso especificadas as páginas de código, fase (165), fig. 13D, é recuperada a segunda página de código e armazenada na descrição das colunas, sob página de código Ns 2, fases (167) e (169). Então a primeira página de código é recuperada e armazenada na descrição das colunas, sob página de código N9 1, fases (171) e(l73).

Com referência às fig. 13A e 13E, se o nodo que está a ser indicado for um nodo de tipo de dados, fase (175) , fig. 13A, verificam-se as seguintes fases, como se mostra na fig. 13E. Se o tipo de dados for CBAR, regista-se CHAR MIXED no campo do tipo de coluna na descrição das colunas, fases (177) e (179). Se o tipo de dados for VARCHAR e o comprimento estiver especificado, fases (181) e(l83), é armazenado VARCHAR MIXED no campo do tipo de coluna da descrição das colunas, fase (185). Se não estiver especificado o comprimento, armazena-se LONG VARCHAR MIXED no campo de tipo de coluna da descrição das colunas, fase (187).

As fases anteriores sao repetidas até que todos

- 28 Os nodos tenham sido processados da maneira atrás indicadas.

Depois de o compilador SQL realizar as fases anteriores, os serviços de dados relacionais chamam o interpretador para executar o código contínuo e a descrição agrupada em bloco que foi gerada. A saída será uma nova tabela que é criada na base de dados, uma linha na tabela do catálogo SYSTABLES para a nova tabela criada, e uma linha na tabela do catálogo SYSCOLUMNS para cada coluna da nova tabela, se a instrução for uma instrução CREATE TABLE. A saída para uma instrução ALTER TABLE será uma linha na tabela do catálogo SYSCOLUMNS para cada nova coluna adicionada e uma linha actualizada para a tabela alterada na tabela do catálogo SYSTABLES. 0 pseudo código seguinte ilustra as fases de execução do código contínuo e a descrição em bloco que foi gerada pelo interpretador.

C) Chamar o interpretador de tempo de execução para executar a instrução CREATE TABLE Notai a entrada ó:

código contínuo e descrição em bloco gerados pelo compilador SQL. a saída ó:

nova tabela criada na base de dados; linha na tabela do catálogo SYSTABLES para a tabela criada

Tínha na tabela do catálogo SYSCOLUMNS para cada coluna da nova tabela.

/ * estabelecer a estrutura da descrição da tabela DMS a partir da descrição em bloco / / * Chamar DMS para criar a tabela * / / * Para SYSTABLES , /* /* adicionar linha (incluindo coluna da descrição em bloco) para a nova tabela^* /

Obter um indicador para a descrição da primeira coluna * /

Para cada coluna na descrição em bloco para a tabela * /

/ * Estabelecer o campo SYCGLUMNS CODEPAGE a partir da página de código Ne 1 * / / * Estabelecer o campo SYSCOLUMNS DBCSCODEPG a partir da página de código Ne 2 * / / * Estabelecer o campo SYSCOLUMNS COLTYPE com o tipo dos caracteres, nao o subtipo * / / * SWITCH (tipo de coluna na descrição em bloco CD/ / * Agrupar o tipo de coluna = CHAR MIXED * / / * Armazenar CHAR” no campo do tipo de coluna

SYSCOLUMNS * / / * END CASE * / / ^x agrupar o tipo de coluna = VARCHAR MIXED * / Armazenar **VARCHAR^H no campo do tipo de coluna SYSCOLUMNS * / /* / END CASE / * Agrupar o tipo de coluna

LONG VARCHAR

MIXED * / / Armazenar LONGVAR no campo do tipo de coluna SYSCOLUMNS * / / * END CASE * / / * ENDSWITCH * / / * Inserir a linha em SYSCOLUMNS * / / * ENDFOR * /

B) Chamar o interpretador de tempo de execução para executar a instrução ALTER TABLE

Nota: A entrada á: código contínuo e descrição compacta ou em bloco gerados pelo compilador SQL.

A saída é: descrição das novas colunas adicionadas à tabela na base de dados:

linha actualizada na tabela do catálogo SYSTAELES para a tabela alterada; linha na tabela do catálogo SYSCOLUMNS para cada nova coluna na tabela / * estabelecer a estrutura da descrição da tabela DMS a partir da descrição em bloco *”/

/ * Chamar DMS para alterar a descrição da tabela na base de dados * / / * Nas SYSTABLES, actualizar a coluna da descrição compacta para a tabela alterada * / / * Obter um indicador para a descrição da primeira coluna * / / Para cada coluna na descrição compacta para a tabela * / / * Estabelecer o campo SYOOLUMNS CODEPAGE a partir da página de código Ne 1 * / / * Estabelecer o campo STSCOLUMNS DBCSCODEPG a partir da página de código N° 2 * / / ^X Estabelecer o campo SYSCOLUMNS COLTYPE com o tipo dos caracteres não com os subtipos * / / ^K SWITCH (tipo de coluna na descrição compacta CD) * / / * Agrupar tipo de coluna => CHAR MIXED * / / * Armazenar CHAR no tampo do tipo de coluna SYSCOLUMNS * / / * END CASE * / / * agrupar tipo de coluna » VARCHAR MIXED & / / * Armazenar VARCHAR” no campo do tipo de coluna SYSCOLUMNS * / / * END CASE * / / * agrupar tipo de coluna = LONG VARCHAR MIXED / * Armazenar LONGVAR no campo do tipo de coluna de SYSCOLUMNS * / / * END CASE * / / * ENDSWITCH ^X / / * Inserir a linha em SYSCOLUMNS ^x / / * ENDPOR * /

Com referência à fig. 14, vai descrever-se o pseudocódigo atrás listado. A descrição das tabelas dos serviços de gestão de dados será estabelecida a partir da descrição compacta, fase (201). Os serviços de gestão de dados cria- 51 -

rao então efectivamente a nova tabela ou coluna fisicas, fase (203)· Os serviços de catálogos adicionarão a Unha a SYSTABLES, fase (205). Será adicionada uma linha em SYSCOLUMNS por cada coluna da nova tabela criada ou nova coluna adicionada.

A coluna SYSCOLUMNS CODEPAGE será estabelecida com a página de código Ns 1 a partir da descrição das colunas, fase (209) , e a coluna SYSCOLUMNS DBCSDODEPG será estabelecida com a página de código NS 2 a partir da descrição das colunas for CHAR.

Se o tipo de coluna da descrição das colunas for CHAR MIXED, SYSCQLUMN COLTYPE será estabelecido com CEAR, fases (213) e (214). Se o tipo de coluna na descrição das colunas for VARCHAR MIXED, SYSCOLUMN CQLTYPE será estabelecido com VARCHAR, fases (215) θ (216). Se o tipo de coluna na descrição das colunas não for nem CHAR MIXED, NEM VARCHAR MIXED nem LONG VARCHAR MIXED, então SYSCOLUMN COLTYPE será estabelecido com o tipo de coluna da descrição de colunas, fase (219). Será acrescentada uma linha a SYSCOLUMNS, fase (221) e será recuperada a descrição de coluna seguinte, fase (223).

pseudocódigo seguinte ilustra a actualização de SQLDA com a página de código especificada. Para uma descrição mais avançada e para a utilização de SQLDA, sugere-se o manual seguinte, que aqui se incorpora por referencia: IBM Systems Applications Architecture Common Programming Interface Datbase Reference, IBM Corporation, Document Number SC26-438-0,1987.

Aetna! j %ar SQLDA com informação da página de códigos enquanto se processam SQL PREPARE ou DESCRIBE da instrução SELECT / * Enquanto se processa a lista SELECT * / / * se o item da lista for coluna * / / * copiar a página de código Ns 1 (página de código SBCS) da descrição compacta para o campo SQLDA SQLDÔTA*/

/ * copiar a página de código Ns 2 (página de código DBCS) da descrição compacta para o campo SQLDA SQLIND * / / * se não for uma coluna * / /* Copiar a página de código Ns 1 (página de codigo SBCS) da área da página do código da base de dados para o campo SQLDA SQLDATA * / /* Copiar a página de código Ns 2 (página de código DBCS) da área da oágina de código da base de dados para o campo SQLDA SQLIND * / / * ENDIE * / / * ENDWHILE * /

Com referência à fig. 15, descreve-se o pseudocódigo atrás listado. Se a instrução SQL nao for PREPARE oú DESCRIBE de um SELECT, SQLDA nao será actualizado, fases (225) e (227). Se a instrução SQL for um PREPARE ou um DESCRIBE de um SELECT, será recuperado o primeiro item da lista SELECT, fase (229). Se o item na lista SELECT for coluna, fase (231), a página de código SBCS (página de código Ns 1) será copiada da descrição compacta para o campo SQLDATA, fase (233). A página de código DBCS (página de código Nfi 2) será copiada da descrição compacta para o canipo SQLIND, fase (235)· Se o item da lista SELECT nao for coluna, a página de código SBCS(página de código Ns l) será copiada da área da página de código da base de dados para SQLDATA, fase (239)· A página de código DBCS (página de código Nfi 2) será copiada da área da página de código da base de dados para SQLlinD, fase (24l). Recupera-se o item seguinte na lista, fase (237) θ repetem-se as fases anteriores para todos os itens da lista SELECT, fase (243)· que se segue ilustra o funcionamento da recuperação de dados a partir das tabelas da base de dados com colunas especificadas além disso com o subtipo, como dados mis- 33 tos ou dados de conjuntos de caracteres com um só octeto, como no sistema e no processo segundo a presente invenção.

Os dados sao extraídos das tabelas da base de dados e neviados para um programa de aplicação usando as instruções SELEGT e FETCH. Usando uma SOÍDA (Área de descritor SQL) ou uma lista de hospedeiros variáveis, o gestor da base de dados desloca dados para as áreas de dados no programa de aplicação. Para os tipos de dados de caracteres, se o comprimento da área de destino no programa de aplicação for menor que o comprimento dos dados da base de dados pedidos, os dados serão truncados e será colocado um indicador de aviso na SC1CA, como se descreve na referência de Bases de Dados atrás indicada. Se os dados de caracteres forem dados de caracteres mistos, ó necessário um processamento especial durante o truncamento, de modo que o truncamento não faça a bisecção de um carácter de octeto duplo dando origem a um carácter final inválido.

algoritmo de truncamento para os dados mistos está representada na fig. 16A. N representa o comprimento, em octetos, da área de destino, fase (245). PB representa o endereço do octeto final dos dados truncados, fase (247). N” octe tos de dados são transferidos do endereço inicial dos dados da base de dados para o endereço de destino, fase (249). FB toma-se o início da área de destino - N - 1, fase (251). 0 limite do ultimo carácter é determinado antes de FB, fase (255). Se FB for o primeiro octeto de um carácter de octeto duplo, então FB é substituido por um espaço de um único octeto, fases (255) e (257). Caso contrário, não há qualquer acção.

Em comparação, 0 algoritmo de tniocamento para dados de um só octeto está representado na fig. 163. De novo, N á o comprimento em octetos da área de destino, fase (259). Depois, transferem-se N octetos de endereço inicial dos dados na base de dados para o endereço de destino, fase (261). Como está ilustrado, o algoritmo de truncamento de dados mistos da fig.

16A inclui as fases que não são necessárias para os dados com

um so octeto, fig· 16B. A determinação do limite do último caracter na fase (253), fig· 16A, pode ser particularmente dispendioso, conforme o comprimento e o conteúdo dos dados. A adi ção do tipo de dados internos que indica dados mistos, permite que o codigo de tempo de execução que faz o truncamento chame selectivamente a rotina simples de um octeto único, fig. 16, ou a rotina mista mais dispendiosa, fig. 16A.

A SUBSTR SCALAR FUNCTION é também mais eficiente para os dados com um só octeto que para os dados mistos. As fruições escalares podem ser usadas em vez das expressões nas instruções SQL. SUBSTR é uma função escalar que faz o retomo de uma subsequência de dados de um campa de dados de caracteres. As funções escalares incluindo SUBSTR estão descritas com pormenor em IBM Database 2 SQL Reference, Document Number SC26-4346-3, IBM Corporation.

primeiro parâmetro da função SUBSTR especifica a sequência de dados dos caracteres da base de dados da qual se extrairá uma subsequência. 0 parâmetro 2 é a posição do octeto Inicial da subsequência. 0 parâmetro 3 é o comprimento em octetos do resultado. Para dados mistos o octeto final da subsequência tem de ser processado usando a rotina de truncamento atrás descrita para assegurar que o último carácter é válido. 0 primeiro carácter da subsequência tem também de ser examinado para assegurar que a sequência restante não começa com o segundo octeto de um carácter de octeto duplo. 0 algoritmo para fazer esta verificação está representado na fig. 17·

A vai i adação do primeiro caróter de SUBSTR para os dados mistos é como segue. N é o parâmetro 2 de SUBSTR, fase (263)» SB é o octeto inicial da subsequência, fase (265). SB torna- se o endereço do parâmetro 1 dos dados da base de dados +N-1, fase (267). 0 limite do último carácter antes de SB é então determinado, fase (269). Se SB for o segundo octeto de um carácter de dois octetos, então o primeiro octeto da subsequência é substituído por um espaço de um só octeto, fases (271) e (273). Caso contrário, nao há qualquer acção.

Se o parâmetro 1 nao for do tipo MIXED, nao é necessário chamar as rotinas para fazer a verificação especial do limite e o processamento dos primeiro e último caracteres da subsequência, fases (269), (271), (273), (253), (255) e (257).

Um programa de aplicação pode ainda aproveitar a identificação de dados SBCS e dados MIXED. Um programa de aplicação não precisa de fazer 0 processamento especial de dados de caracteres em função de se tratar de caracteres com um só octeto ou mistos. Por exemplo, um programa pode pretender gerar um documento de saida que é escolhido num campo particular. Os dados mistos nao podem ser classificados com uma comparação e elaboração com base numa tabela de valores ordenados de 256 octetos. Os algoritmos de classifióação para caracteres com octetos duplos são complexos e variam com a linguagem implicada.

Portanto, seria útil que uma aplicação estivesse em condiçoes de inquirir os catálogos do sistema e determinar se uma coluna numa tabela é definida como sendo MI;ED, antes de tentar aplicar algoritmos dispendiosos aos dados. Isso permite que uma interface de utilizador generalizada ou uma aplicação de gerador de documentos de saida façam processamento sofisticado de dados de caracteres que foram criados por outras aplicações, visto que a informação acerca do tipo de dados de caracteres está armazenada na base de dados, independentemente da aplicação de criação.

Os processos por meio dos quais um programa de aplicação obtém informação dos catálogos do sistema são: l) SELECT de uma tabela do catálogo e 2) PREPARE ou DESCRIBE para nma SQLDA. Estas operações SQL são descritos com mais pormenor em IBM Database 2 SQL Reference Document Number SC26-4346-3, IBM Corporation. Como FOR MIXED DATA e FOR SBCS DATA sao subtipos de dados em vez de tipos de dados SQL, a aplicação não pode examinar a una CGLTYPE de SYSCCLUMNS ou o campo SQLTYPE da SQLDA e obter a informação do subtipo. Em vez disso, proporcio- 36 -

nam-se os seguintes processos para o retomo da informação para a aplicação. Para um tipo de dados de caracteres os campos SQLDATA e SQLLIND são codificados como se representa na fig.18, depois de uma instrução DESCRIBE (uma PREPARE com uma oração INTO). A aplicação pode também inquirir a coluna Codepage (94) e a coluna DBCSCODEPG (95) na SYSCGLUMNS (28), fig. 1QA) para o esquema de codificação como se representa na fig. 10C.

Analogamente, uma aplicação pode ser sensível à página de código específica que comanda a codificação dos dados de caracteres. Por exemplo, uma aplicação pode pretender determinar se compreende o esquema de codificação dos dados antes de qualquer tentativa de recuperação e em especial alterar esses dados. Como suporte para estas necessidades, a presente invançao permite que uma aplicação não só inquira a base de dados para determinar a págLna de código de um dado campo de caracteres, como também uma aplicação pode declarar 0 ambiente da página de código de um campo de caracteres quando o cria. Além disso, como a concepção da presente invenção permite que sejam declarados os atributos da página de código de cada coluna independentemente dos de qualquer outra, são suportados completamente sistemas e aplicações avançados que acomodam ambientes de páginas de código múltiplas.

que segue ilustra ainda melhor o signifiçado da especificação de dados de conjuntos de caracteres de um só octeto em sistemas de base de dados relacionais que permitem da dos com octetos mistos. Para fins de ilustração, os caracteres com um só octeto serão distinguidas dos caracteres com octetos duplos usando a convenção seguinte:

- os caracteres de um só octeto serão representados por letras minúsculas} por exemplo a,b,c, ...

- os naraeteres com octetos duplos serão representados por duas letras maiusculas; por exemplo AA, BB, CC, ...

Por exemplo, consideremos uma tabela denominada SAMPLE com duas colunas denominadas IVORY e HEINZ, contendo IVORT apenas sequências (valores) de caracteres com um só octeto e contendo HEINZ sequências de caracteres mistos com um só octeto e com octeto duplo. Uma tal tabela podia ter sido criada com a seguinte instrução SQL:

CREATE TABLE SAMPLE (IVORY VARCHAR (10) POR SBCS DATA,

HEINZ VARCHAR (10) POR MIXED DATA)

Usando a convenção atrás estabelecida para a representação dos caracteres com um só octeto e com octetos duplo dão-se a seguir alguns valores para IVORY e HEINZ.

LINHA DE SAMPLE	IVORY	HEINZ
1	abc	AABBCC
2	dog	DDOOg
3	qwertyuiop	ZZxCCvBBn
4	último valor	qQQqQQ

Utilizando a tabela SAMPLE anterior, o que se segue ilustra algumas diferenças no processo de tratamento das sequências de dados formadas por caracteres com um só octeto e no processo de tratamento de sequências de dados formadas quer por caracteres com um só octeto quer por caracteres com oc· tetos duplos.

Uma sequência mista tem a propriedade de ela apenas poder ser analisada a partir do principio da sequência. Isto ó, nenhum octeto tem qualquer significado a menos que se determine a natureza de todos os octetos anteriores da sequência. Para ilustrar, suponhamos que o utilizador/aplicação desejava apagar apenas o último octeto de cada valor em IVORY e HEINZ. 0 processo de tratamento usado para os valores da coluna IVORY ó fácil de compreender. Explora-se o fim da sequência e elimina-se o último octeto da sequência. Se se utilizasse este mesmo procedimento para os valores da coluna HEINZ, um tal algoritmo eliminaria o segundo octeto de um carácter de octeto du pio se o ultimo carácter da sequência fosse um carácter de octe to duplo· Portanto é necessário um algoritmo mais complicado pa ra uma coluna de caracteres mistos. Em primeiro lugar á necessá rio determinar a natureza (octeto único ou duplo) do último carácter da sequência. A simples verificação do valor do último octeto não é suficiente, pois quer os caracteres de octeto único quer os de octeto duplo compartilham valores pontuais de código, Assim, para determinar se o último carácter de uma sequên cia é um caracter de um so octeto ou de octeto duplo, é necessário utilizar um algoritmo de análise complexo. Isso é obviamente consumidor de tempo e incómodo, mas inevitável.

Os resultadès desta operação para truncar o últi mo octeto dos valores da nossa tabela SAMPLE estão indicados a seguir:

LINHA DE SAMPLE	IVORf	HEINZ
1	ab	AABB
2	do	DDOO
3	quertyuio	ZZxCCvBB
4	último valor	qQQq

Se pudermos de antemão partir da hipótese de que uma coluna contém apenas sequências de caracteres de um só octeto, é então possível utilizar algoritmos de truncamento para tais colunas que proporcionam melhorias de eficácia e de simpli. cidade importantes nos processos sobre sequências de caracteres com um só octeto ou com octetos duplos. A opção FOR SBCS DATA permite que o utilizador/aplicação da base de dados especifique este atributo das colunas.

Como outro exemplo que ilustra a maior complexidade do processamento de sequências mistas sobre o processamento de sequências de caracteres mistos, considera-se a função

subsequência”. Este operador de sequências permite a selecção de parte de uma sequência de um carácter por especificação da posição do octeto inicial e de um comprimento.

As mesmas diferenças de processamento entre as se quências puras e mistas que foram encontradas aplicam-se também à função subsequência. Se se seleccionasse uma subsequência de dados de um valor de um só octeto, a sequência apenas teria que ser exolorada até ao octeto de ordem n (sendo η o argumento da função subsequência que expecifica o caracter que inicia a sub sequência). Então este octeto seria seleccionado mais os m-1 oç tetos seguintes (sendo m o comprimento especificado da subsequência nos caracteres), como resultado. Mas se se estiver a processar uma sequência com um só octeto e cora octetos duplos, teria que determinar-se a natureza dos primeiro e ultimo octeto na subsequência para garantir a validade dos caracteres na subsequência. A penalização na eficácia de um algoritmo assim desenvolvido pode ser significativa.

Em resumo,as ilustrações anteriores devem esclarecer uma diferença fundamental entre as sequências com octetos simples ou com octetos duplos. Todo octeto numa sequência de oc tetos simples é um caracter. Nada pode dizer-se acerca de um octeto arbitrário numa sequência mista sem conhecer a natureza dos octetos que precedem a sequência.

efeito desta diferença consiste em que as operações em sequências em valores (e portanto colunas) com um só octeto são geralmente mais rápidas e mais simples que as mesmas operações em valores com valores de um só octeto e cora octetos duplos. Assim, a capacidade de declarar uma coluna como pura ou mista, associada a algoritmos sensíveis a esta diferença pode produzir beneficios de eficácia importantes. Então isso é uma forte motivação para a declaração de colunas EOR SBCS DATA e EOR MIXED DATA.

No sistema de base de dados relacional segundo a

- 40 presente invenção o que se segue foi mostrado e descrito em particular. Proporciona-se uma extensão da linguagem SQL para permitir a um utilizador/aplicação especificar se uma coluna numa tabela da base de dados contém apenas dados de conjuntos de caracteres com um octeto único ou caracteres com octetos mistos simples e duplos. A especificação de se uma coluna contém dados de conjuntos de caracteres com uft octeto único ou dados mistos é obtida especificando o subtipo dos tipos de dados de caracteres que incluem CHAR VARCHAR e LONG VARCHAR. A aplicação do utilizador pode especificar o subtipo dos dados dos caracteres dentro de uma coluna, quando a coluna é criada ou acrescentada, pela especificação de dados FOR SBCS ou FOR MIXED ou FOR BIT e toda instrução CREATE TABLE ou ALTER DATA.

Juntamente com â. especificação do subtipo de octeto único ou duplo a utilizador/aplicação pode ainda especificar as páginas de código a utilizar para a coluna da tabela na bâse de dados. Intemamente, dentro do gestor da base de dados segundo a presente invenção, o subtipo é registado em termos dos atributos da página de código do tipo de dados de caracteres, registados nos catálogos do sistema da base de dados. Este esquema de codificação proporciona um processo eficiente para a determinação de se uma coluna é apenas para dados de conjuntos de caracteres com um só octeto ou para dados de caracteres com octeto duplo e ao mesmo tempo conhecer a página de código correcta que deve ser usada para essa coluna por simples inquirição das colunas de páginas de código no interior dos catálogos do sistema da base da dados·

Embora a invenção anterior tenha sido ilustrada e descrita partieularmente com referência a uma sua forma de realização preferida, os especialistas compreenderão que podem ser introduzidas alterações de forma sem nos afastarmos dos objecttvos da invenção definidos pelas reivindicações anexas.

Claims (1)

1. Sistema de base da dados relacional tendo dados mistos, com dados de conjuntos de caracteres de octetos (bytes) sinqxLes e dados de conjuntos de caracteres com octetos duplos, caracterizado por compreender um certo número da colunas em pelo menos uma tabela do referido sistema de base de dados relacional e meios para designar selectivamente uma coluna na referida tabela como sendo apenas para dados de conjuntos de caracteres com octetos simples.

   ί

   - 2ô Sistema de acordo com a reivindicação 1, caracterizado por compreender meios para designar selectivamente uma ί

   ι coluna diferente na referida tabela como sendo para dados mistos, quer para dados de conjuntos de caracteres com octetos sim·· ! pies quer para dados de conjuntos de caracteres com octetos duplos.

   H Sistema de acordo com as reivindicações 1 ou 2, caracterizado por os referidos meios para designar selectivamente uma coluna como sendo apenas para dados de conjuntos de caracteres com octetos simples poderem ser operados quando a ι tabela é criada.

   í - 4δ Sistema de acordo com a reivindicação 3, caracterizado por os referidos meios para designar selectivamente uma coluna diferente como sendo para dados mistos, quer para ί dados de conjuntos de caracteres com octetos simples, quer para dados de conjuntos de oaracteres com octetos duplos, poderem ser operados quando a tabela é criada.

   - 5§

   Sistema de acordo com as reivindicações 3 ou 4, caracterizado por os referidos meios para designar selectivamente as referidas colunas compreenderem meios para responder a uma declaração CREATE TABLE para especificar uma coluna na referida tabela como sendo apenas para dados de conjuntos de caracteres com octetos simples.

   - 6β Sistema de acordo com qualquer das reivindicações anteriores, caracterizado por os referidos meios para desigiar selectivamente uma coluna como sendo apenas para dados de conjuntos de caracteres com octetos simples poderem ser operados quando uma coluna deste tipo for adicionada à referida tabela.

   - 70 Sistema de acordo com a reivindicação 6, caracterizado por os referidos meios para desigiar selectivamente uma coluna diferente como sendo para dados mistos, quer para dados de conjuntos de caracteres com octetos simples, quer para dados de conjuntos de caracteres com octetos duplos, poderem ser operados quando uma das referidas colunas diferentes for adicionada a referida tabela.

   - 8&

   Sistema de acordo com ae reivindicações 6 e 7, caracterizado por os referidos meios para designar as referidas colunas compreenderem meios para responder a uma declaraçao A1TER TABLE para especificar uma coluna na referida tabela como sendo para dados de conjuntos de caracteres com octetos simples

   - 90 43

   Sistema de acordo com qualquer das reivindicações anteriores, caracterizado por os referidos meios para desig^iar selectivamente uma coluna compreenderem meios para especificar um subtipo de um tipo de dados de caracteres.

   - 10® Sistema de acordo com qualquer das reivindicações anteriores, caracterizado por compreender meios para especificar uma página de código que deve ser usada para uma coluna na tabela.

   I

   - 11® j Sistema de acordo com a reivindicação 10, caracj terizado por compreender meios para especificar uma segunda página de código para uma coluna diferente na referida tabela.

   - 12 s I

   Sistema de acordo com as reivindicações 10 ou 11, caracterizado por os referidos meios para especificar uma página de código compreenderem meios para registar um atributo da página de código num de vários catálogos do sistema de base de dados.

   - 13® Sistema de acordo com a reivindicação 12, caracterizado por compreender ainda para interrogar pelo menos ura dos referidos catálogos do sistema da base de dados para determinar simultaneamente uma págLna de código para uma coluna e se a coluna contém apenas dados de conjuntos de caracteres com octetos simples.

   - 14® Sistema de acordo com qualquer das reivindicações anteriores, caracterizado por compreender além disso meios para o processamento de dados numa coluna baseada no tipo de dados especificados para uma coluna.

   - 15^â Sistema de acordo com a reivindicação 14, caracterizado por compreender uma primeira lógica de processamento para colunas com dados mistos com octetos simples e com octetos duplos e uma segunda lógica de processamento, mais rápida que a referida primeira lógica de processamento, para processamento de colunas de dados designadas para apenas dados com octetos simples.

   - I6â Sistema de base de dados relacional, caracterizado por compreender: um certo número de colunas numa tabela de da dos, meios para especificar um certo número de tipos de caracteres para cada uma das várias colunas e meios para especificar vários subtipos dos referidos tipos de dados de caracteres.

   - 17- Sistema de acordo com a reivindicação 16, caracterizado por compreender ainda meios para o processamento de dados das referidas colunas baseado no referido subtipo especificado.

   — 18 δ —

   Sistema de acordo com a reivindicação 17, carac terizado por compreender meios para registar, numa estrutura SQLDA do referido sistema de base de dados relacional, um atributo da página de código do referido subtipo.

   - 19& - 45 Sistema de acordo com a reivindicação 18, caracterizado por compreender um certo número de atributos da página cie código dos subtipos numa coluna da página de código com octetos simples e uma coluna de página de código com octe tos duplos de um catálogo do sistema de base de dados.

   - 20ã Sistema de acordo com a reivindicação 19, caracterizado por compreender ainda meios para a interrogação do catálogo da base de dados para determinar simultaneamente os subtipos dos dados de caracteres para uma qualquer das referidas colunas e um certo número de azributos de página de código para uma qualquer das colunas.

   A requerente declara que o primeiro pedido desta patente foi apresentado nos Estados Unidos da América em 8 de Abril de 1938, sob o número de série 179,191·