ITMI951510A1

ITMI951510A1 - Emulatore per un database relazionale in linguaggio sql

Info

Publication number: ITMI951510A1
Application number: IT95MI001510A
Authority: IT
Inventors: Rodolfo Bonzi
Original assignee: Alcatel Italia
Priority date: 1995-07-14
Filing date: 1995-07-14
Publication date: 1997-01-14
Also published as: EP0839358B1; DE69605553D1; ATE187565T1; WO1997004407A1; JPH11509349A; DE69605553T4; CN1191026A; ES2140116T3; CN1098501C; DE69605553T2; ITMI951510A0; US6003026A; CA2223490A1; EP0839358A1; IT1275529B

Abstract

Metodo e mezzi per il porting di una applicazione esistente (An) che usa un database relazionale con interfaccia SQL verso una piattaforma hardware (HW2) con configurazione software ridotta che non include un database relazionale SQL. L'invenzione emula un database SQL consentendo un risparmio di risorse hardware e fornendo un sottoinsieme di funzioni per - creare tabelle SQL e definire i campi;- memorizzare, modificare e cancellare dati sulle tabelle create, con controllo di tipo;- recuperare tali dati usando filtri SQL.Le funzioni sono suddivisibili in livelli (M1, M2, M3) allo scopo di:- convertire una istruzione SQL, proveniente da una esistente applicazione (An) di utente, in una sequenza di funzioni (IF1 ...IFn) di interfaccia elementari,- usare dette funzioni di interfaccia per leggere/scrivere file (F1 ... Fn) di dati,- processare dati in uscita da fornire alla applicazione (An) di utente richiedente.

Description

DESCRIZIONE

La presente invenzione si riferisce ad un metodo per fornire un sottoinsieme di funzioni di database relazionale con interfaccia in linguaggio SQL (Structured Query Language) ad applicazioni già' esistenti.

Esistono già' svariati database disponibili in commercio con interfaccia SQL i quali forniscono un insieme esaustivo di funzioni, ma essi richiedono un forte dispendio di risorse "hardware".

Di conseguenza, programmi di elaboratori scritti per un elaboratore con una piattaforma software comprendente un database relazionale in linguaggio SQL di tipo commerciale sono spesso inadeguati per l'uso con elaboratori aventi una ridotta configurazione hardware.

In passato molte applicazioni esistenti hanno dovuto essere riscritte per renderle adatte ad interfacciarsi con un database proprietario esistente in quella apparecchiatura.

Inoltre, i database proprietari sono di solito dipendenti dalla apparecchiatura e non possono essere usati per la stessa o per altre applicazioni su altre apparecchiature.

Uno dei maggiori problemi che gli sviluppatori di applicazioni incontrano allorché' si tratta di effettuare il c.d. "porting" cioè' di portare applicazioni esistenti, sviluppate su una diversa piattaforma hardware e software che usano un database relazionale in linguaggio SQL, verso apparecchiature con limitata configurazione hardware, per esempio "server" di comunicazione, altre apparecchiature di rete, ecc., e' la necessita' di riscrivere parte delle applicazioni allo scopo di renderle atte ad interfacciarsi con un database proprietario esistente su quella apparecchiatura, altrimenti le applicazioni non potrebbero essere usate o dovrebbero essere riscritte completamente.

Talvolta l’apparecchiatura di destinazione possiede una ridotta disponibilità' di risorse hardware a causa della installazione di altre applicazioni dispendiose in risorse (per esempio, software per comunicazioni quali i protocolli Stack ISO/OSI, TCP/IP e altri) e poiché' i database relazionali in linguaggio SQL di tipo commerciale sono fortemente dispendiosi in risorse hardware, potrebbe essere desiderabile evitare di installarla, per esempio nel caso di "porting" di una applicazione verso uno o piu' server di comunicazione.

Bisognerà* riconoscere che un database SQL che gira su una apparecchiatura con qualsiasi configurazione e' essenziale allo scopo di consentire ad una applicazione esistente che usa un database SQL di essere "portato" verso una apparecchiatura e di funzionare correttamente allorché' non sia stato installato un database commerciale.

Uno scopo della presente invenzione e' quello di provvedere un metodo e mezzi di porting fornenti un insieme di funzioni di database SQL ad una applicazione esistente su qualsiasi apparecchiatura, senza un sensibile dispendio di risorse "hardware" . Lo scopo viene raggiunto da un metodo avente le caratteristiche esposte nella rivendicazione 1 e da mezzi di porting esposti nella rivendicazione 4. L’invenzione cosi come rivendicata permette di effettuare il porting di applicazioni di software di utente già' esistenti usando un database SQL verso qualsiasi configurazione di hardware ridotta sulla quale un database relazionale in linguaggio SQL di tipo commerciale dispendioso in risorse non può essere installato, solo copiando, ricompilando ed eseguendo i file dell’applicazione senza alcuna modifica del codice sorgente.

Usando l'invenzione, lo spreco di tempo per modificare il codice sorgente già' esistente viene eliminato, laddove talvolta tale codice sorgente non e' facilmente modificabile e richiederebbe un grosso sforzo.

Inoltre, talvolta e' preferibile risparmiare sulle risorse hardware per altre applicazioni di run-time: in questi casi l'emulatore oggetto della presente invenzione permette il risparmio in una fase di configurazione.

Ancora, l'emulatore può' essere "customizzato" per essere usato con differenti piattaforme su qualsiasi apparecchiatura differente.

Ulteriori vantaggiose caratteristiche della invenzione sono esposte nelle rivendicazioni dipendenti.

Vantaggiosamente, la sicurezza dei dati di utente può' essere garantita, quando e' necessario, usando un modulo di cifratura/decifratura per accedere ai file dati.

L'invenzione verrà' ora descritta in dettaglio, per mezzo di un esempio, con riferimento ai disegni allegati in cui:

- Fig. 1 mostra l'uso dell'emulatore durante una fase di porting secondo la presente invenzione;

- Fig. 2 enumera tutte le parti che costituiscono 1'architettura software dell'emulatore secondo l'invenzione;

- Fig. 3 mostra come una istruzione (statement) SQL viene convertita in una funzione d'interfaccia la quale viene quindi tradotta in una sequenza di funzioni libreria di emulazione che accedono ai file ASCII, secondo l'invenzione;

- Fig. 4 mostra l implementazione di come una istruzione SQL viene convertita in una funzione d' interfaccia la quale viene quindi tradotta in una sequenza di funzioni libreria di emulazione che accedono ai file ASCII, secondo l'invenzione;

- Fig. 4-B mostra un esempio particolare di Fig. 4; - Fig. 5 mostra un sistema per gestire una rete telefonica, implementato usando una rete per area locale (LAN) comprendente dei server di comunicazione di ridotta configurazione hardware che può' attuare l’invenzione ; e

- Fig. 6 mostra un esempio di una topologia di rete crescente comprendente server di comunicazione aventi una configurazione hardware ridotta, che può' attuare l'invenzione .

La presente invenzione si rivolge a un approccio di emulazione di un database come illustrato in Fig. 1. In ciò’ che segue, si fara' particolare attenzione al servizio fornito alla applicazione che necessita il database sebbene si dovrebbe intendere ‘che l'emulatore pot rebbe'implementa re un set di funzioni differente che sara' il minimo richiesto dalla applicazione per poter funzionare.

Con la presente invenzione si offre un metodo originale per fornire le prestazioni di un database SQL. commerciale in un modo differente, usando un emulatore 1.

Questo emulatore e‘ un database modulare: solo le funzioni necessarie per soddisfare i requisiti di un'applicazione An di utente già' esistente sono configurate ed installate cosi da permettere la minima flessibilità', onde ridurre il consumo di risorse hardware, in particolare tempo di memoria e di CPU.

L'emulatore gestisce i file ASCII di configurazione e di dati utente F1...Fn facendo uso di una libreria modulare di funzioni e strutture di dati predefiniti. Questa semplice struttura modulare permette un facile miglioramento e manutenzione della configurazione allo scopo di ridurre le dimensioni dell'emulatore tenendo conto dei requisiti dell'applicazione e della configurazione hardware di un'apparecchiatura.

La succitata applicazione An e' stata, per esempio, sviluppata su una prima piattaforma hardware HW1 che interfaccia l'applicazione An verso il database relazionale SQL con una configurazione software SW1, e si suppone essere usata su una seconda piattaforma hardware HW2 quando il database SQL non e' disponibile e quindi non si può' usare SW1. L'architettura software dell'emulatore 1 e' mostrata in Fig.2.

L'emulatore 1 e' composto dalle seguenti parti:

- un modulo interfaccia MI che fornisce alle applicazioni un'interfaccia SQL (essa sostituisce la piattaforma SW1). Questo modulo e' dipendente dalla applicazione e dovrebbe essere "customizzato'' a seconda del tipo di istruzione SQL usata, con particolare riguardo alla istruzione di interrogazione (query statement) avente una sintassi complessa. Esso include un insieme di funzioni, una per ogni specifica istruzione SQL usata dall'applicazione An;

- una libreria M2 di emulazione modulare espandibile e indipendente dalla applicazione, includente un insieme di funzioni che eseguono le funzioni di base sui file ASCII, richieste da M1 allo scopo di implementare le istruzioni SQL usate dall'applicazione An;

- un modulo di gestione di errori (non mostrato in figura);

- un modulo di cifratura M3 (non obbligatorio);

- file ASCII F1, Fm-1 di configurazione, comprendente il database e definizione di tabelle; - file ASCII Fm....Fn di dati di utente (i quali possono essere cifrati) comprendenti i dati di utente inseriti in accordo alla definizione delle tabelle .

L'emulatore gestisce un certo numero di file ASCII contenenti la definizione di tabelle e i dati delle applicazioni di utente.

Per ragioni di sicurezza, i dati possono essere opzionalmente cifrati.

Usando l'emulatore, il tempo di CPU dedicato e la quantità’ di memoria RAM e il numero di megabyte del hard disk richiesto vengono fortemente ridotti rispetto ai database SQL esistenti.

L’emulatore di database relazionale in linguaggio SQL fornisce alle applicazioni di utente una libreria modulare includente un insieme di funzioni per :

- creazione tabelle SQL e definizione campi;

- memorizzazione, modifica e cancellazione di dati sulle tabelle create, laddove un controllo di tipo viene eseguito in accordo alla definizione di campo; e

- recupero di tali dati usando filtri SQL.

L'emulatore implementa i comandi SQL in due modi differenti :

1. per definire la struttura del database, i seguenti comandi di configurazione di tabella possono essere implementati usando un editor per aggiornare i file di configurazione:

- create table

- modify table configuration

- delete

- description

- insert row to pre-populate thè table.

2. per usare il database definito, la modifica runtime del contenuto della tabella viene realizzata usando le funzioni IF1 ... IFn di interfaccia di modulo, come mostrato in Fig. 3:

select rows;

insert one row;

delete rows;

update one row.

Questa descrizione continua a prendere come esempio un database SQL i cui servizi devono essere emulati. Prima di procedere ad una descrizione dettagliata della invenzione, sarebbe d'ausilio tratteggiare certi aspetti rilevanti della fase di configurazione delle tabelle. Verrà' descritta la maniera in cui le seguenti istruzioni SQL vengono gestite:

create table (II),

modify table configuration (alter / drop / create) (I, III, II),

delete (alter / drop) (I, III), description (IV),

insert row to pre-populate the table (V).

La sintassi SQL delle suddette istruzioni e' la seguente :

I) per modificare un database:

ALTER DATABASE nome del database;

II) per definire una nuova struttura di tabella:

CREATE TABLE nome della tabella

(field_namel NUMBER(9),

field_name2 CHARC14));

III) per cancellare una tabella:

DROP TABLE nome della tabella;

IV) per vedere la definizione di tabella:

DESC nome della tabella;

V) dati inseriti per default:

INSERT INTO nome della tabella

(field_namel , field_name2)

VALUES

('field_valuel', 'field_yalue2‘).

Le summenzionate istruzioni SQL possono essere emulate usando un file di configurazione ASCII scritto e modificato usando un editor.

Per ciascuna nuova tabella viene creato un file ASCII. Ciascuna riga definisce una colonna della tabella.

Il seguente e' un esempio di tabella su un file ASCII di configurazione tabella di emulatore, ove la prima parte e' la definizione di struttura di tabella e la seconda parte sono i dati di utente inseriti per default. I caratteri " ", e sono usati per dividere i dati.

Il carattere indica che c’e' una linea di commento .

Nella prima parte viene definita la struttura della tabella .

I dati inclusi tra H....H rappresentano la definizione di tabella, e ciascuna riga che inizia con una C e' una colonna della tabella definita.

I parametri specificati definiscono per ciascuna colonna della tabella:

- tipo,

lunghezza,

se il campo può’ essere nullo,

se il campo e' un indice unico per accedere ai record .

Nella seconda parte di questo esempio, le righe con i dati vengono inserite nella tabella.

Un controllo di tipo viene eseguito in accordo alla precedente definizione di tabella.

L'esperto del ramo sara' a conoscenza di ulteriori modi di configurazione.

Come ulteriore spiegazione, si fa riferimento alla Fig. 3 la quale e' in forma schematica.

Una istruzione SQL, inclusa nell'applicazione di utente, provoca l'attivazione di una funzione IFi di interfaccia dell'emulatore, la quale chiama una sequenza, a seconda della specifica istruzione SQL, di funzioni della libreria di emulazione LFl...LFm che accedono ai file AF1..AFk ASCII contenenti i dati di utente.

Per esempio allorché' l'istruzione SQL

INSERT INTO Tab2

(field_namel, field_name2)

VALUES ('field_valuel1, field_value2')

viene chiamata dall'applicazione An di utente, la funzione IF1 di interfaccia di emulatore INSERT viene attivata; essa chiama una sequenza di funzioni della libreria di emulazione che accedono alla Tab2 del file ASCTT AF? contenente 1 dati di utente, come verrà' spiegato in maggior dettaglio in seguito. Un altro esempio e' il seguente: quando l'istruzione SQL SELECT FROM Tab2

viene chiamata dalla applicazione An di utente, la funzione IFn di interfaccia dell'emulatore SELECTn viene attivata; essa chiama una sequenza di funzioni della libreria di emulazione che accedono al file ASCII di Tab2.

Una libreria di emulazione modulare che fornisce un insieme di funzioni LFl..LFm e' disponibile.

Un sottoinsieme di dette funzioni può' essere combinato per implementare una istruzione SQL.

Un esempio di funzioni di libreria e' il seguente:

Una descrizione dettagliata di ciascuna funzione verrà' fornita in seguito.

In Fig. 4 viene illustrata in dettaglio l'implementazione di una delle suddette funzioni di interfaccia IFl..IFn elencate come mostrato in Fig. 3.

Detta funzione viene tradotta in una sequenza di funzioni della libreria di emulazione LFl..LFm che accedono ai file ASCII.

La Descrizione di Tabella A e la Descrizione di Accesso B sono definite nella struttura dati contenente la descrizione della tabella del database; esse sono implementate come una disposizione ordinata di record aventi un elemento per ciascuna colonna di tabella del database.

La Descrizione di Tabella A e' costituita dai seguenti dati di configurazione:

1 =* tipo di colonna,

2 = lunghezza di colonna,

3 - se il campo può' essere nullo o no,

4 = se il campo e' un indice per accedere ai record o no.

La Descrizione di Accesso B include dati circa il tipo di accesso ed il modo a seconda del tipo di istruzione SQL di origine.

Essa e' costituita dai seguenti dati, inseriti dalla Funzione IFi Interfaccia di emulatore a seconda di quali colonne l'istruzione SQL usi:

1 = usare l'etichetta per indicare se la colonna è usata (T = true, F = false),

2 = dimensioni della stringa,

e i seguenti campi ove leggere/scrivere il risultato della operazione (scritto dalla _fetch __row o letto dalla _write_row):

3 = un’etichetta che indica se il campo può' essere nullo o meno (T = true, F = false), 4 - un'etichetta che indica se il campo contiene un valore numerico,

5 = un'etichetta che indica se il campo contiene un valore alfanumerico (char=character/ptr=pointer) .

La prima operazione eseguita in una memoria RAM e‘ l'attivazione della funzione _get_table_description per recuperare dai file del database la definizione di tabella di utente e copiarla nella Descrizione di Tabella A.

Successivamente tutte le funzioni della libreria di emulatore useranno la Descrizione di Tabella A per leggere/scrivere la Descrizione di Accesso B.

Un esempio di sistema per gestire una rete telefonica implementato usando una rete LAN comprendente del server di comunicazione con ridotta configurazione hardware i quali possono effettuare l'invenzione, e’ mostrato in Fig. 5.

Il sistema include due Server di Applicazione AS1 e AS2, uno attivo e l'altro in stand-by, che eseguono operazioni di gestione per una rete; queste apparecchiature hanno una configurazione completa hardware e software e includono dischi HD duplicati. Un operatore può' interfacciare il sistema di gestione usando un cosiddetto Terminale X collegato a un Server di Terminale X che fornisce una interfaccia di operatore grafica.

Una pluralità' di possibili Server di Comunicazione CSl..CSn di ridotta configurazione hardware vengono installati e possono effettuare l'invenzione. Il numero di Server di Comunicazione CSl..CSn con differenti configurazioni hardware può aumentare in futuri ampliamenti della rete. Sul server di comunicazione CS si dovrebbero installare applicazioni sviluppate su apparecchiature con differenti configurazioni hardware aventi una piattaforma software completa includente un database commerciale.

Poiché' la ridotta piattaforma software del server di comunicazione CS dovrebbe includere anche il software di comunicazione e poiché' i database relazionali sono altamente dispendiosi in risorse hardware, l'approccio di emulazione permette di risparmiare memoria e tempo di CPU.

In Fig. 6 viene mostrato un esempio di architettura di sistema di gestione di rete telefonica comprendente un sistema di gestione di rete secondo la Fig. 5, includente apparecchiature che possono effettuare l'invenzione.

L'approccio di emulazione può' essere utile in vista di una futura estensione della rete inserendo un numero crescente di apparecchiature di diversa configurazione hardware sulle quali applicazioni che necessitano di database relazionali in linguaggio SQL dovrebbero essere eseguite.

Man mano che la complessità' di una topologia di rete aumenta, i sistemi di gestione della rete si suppone vengano migliorati in termini di numero di apparecchiature installate e applicazioni che girano sulle suddette apparecchiature.

L’architettura del sistema di gestione della rete mostrata in Fig. 5 può essere scisso in una pluralità* di sottosistemi cooperanti, interconnessi tramite una rete.

I sistemi SYSTEM1, SYSTEM2 e SYSTEM3 di gestione di rete includenti apparecchiature aventi differente configurazione sono interconnessi ad una rete da gestire allo scopo di cooperare scambiandosi informazioni di gestione.

L'approccio emulazione permette il porting di applicazioni sviluppate su piattaforme hardware e software complete verso qualunque apparecchiatura di rete.

E’ stato accennato sopra che ogni suddetta funzione di interfaccia IF1..IFn, elencata e mostrata in F.ig.

3, viene tradotta in una sequenza di funzioni LFl..LFm della libreria di emulazione che accedono ai file ASCII.

Come ulteriore spiegazione, una istruzione SQL nella applicazione di utente viene convertita in una funzione IF, ciascuna funzione IF viene associata ad una sequenza di funzioni della libreria di emulazione, laddove la sequenza dipende dalla istruzione SQL, l'uscita del comando SQL viene restituita all'applicazione di utente, come descritto sopra.

Nel seguito si esamineranno in maggior dettaglio: 1) funzioni IF

2) libreria di emulazione

3) file ASCII

Un esempio di insieme di funzioni IF può' essere il seguente :

- insert,

- delete,

- update,

- select,

- 6

- selectn.

Una istruzione di SELECT, secondo la sintassi SQL, può' avere una istruzione WHERE differente.

Ecco alcuni esempi di differente complessità'. Il carattere significa "ALL".

L'applicazione An di utente interfaccia il database usando istruzione SQL e passando parametri (puntatori a strutture dati contenente dati inviati al database e puntatori a strutture dati in cui l'uscita dei comandi SQL verrà1 restituita).

Si descrive ora una delle suddette funzioni TF, quella corrispondente alla istruzione SELECT SQL, per quanto concerne la sua implementazione.

TABI e’ un esempio di tabella di database avente sei colonne definite C1..C6.

Due linee dati sono state inserite in TABI; solo i dati rilevanti per l'esempio sono scritti, l'altro campo può' assumere qualsiasi valore.

La seguente istruzione SQL può' prò veni re dal la applicazione An di utente:

Verrà' ora descritto come funziona l'emulatore per ottenere i risultati.

In questa istruzione di SELECT con questa istruzione WHERE , la descrizione di accesso B definita in Fig. 4 viene duplicata in

- Descrizione Accesso Select B1 (non mostrata in figura) ;

- Descrizione Accesso Where B2 (non mostrata in figura) .

In questo caso due differenti accessi ai dati di utente vengono fatti usando due tabelle di Descrizione Accesso.

Come spiegato in precedenza» ogni riga della Descrizione Tabella A e Descrizione Accesso B o B1 e B2 corrisponde a una colonna della tabella di database definita nella fase di creazione.

La Descrizione di Accesso Select B1 definisce quali fra i campi C1..C6 devono essere recuperati per ciascuna riga di dati selezionata tra quelli presenti in TABI e dovrebbero essere inviati all’applicazione An , etichettando con T i campi di interesse, in questo caso cl,c4,c5:

La Descrizione di Accesso Where B2 definisce la clausola per identificare quali righe presenti in TABI dovrebbero essere selezionate etichettando con T i campi citati nella clausola WHERE(c2=10 AND c6~ 'string ') :

Un'altra soluzione in una differente ist ruzione SELECT, per esempio SELECT fi, f2 FROM tabi, potrebbe essere eseguita usando un singolo accesso e una singola Descrizione Accesso B.

In Fig. 4-B viene mostrato un caso particolare di Fig. 4. Questo e' il caso della implementazione della seguente istruzione SQL.

);

che potrebbe essere eseguita usando:

- una Descrizione Tabella Al e A2 multipla

una Descrizione Accesso B1 e B2 multipla.

Nel paragrafo che segue verrà* spiegato come fasi differenti vengono eseguite dalla funzione IF SELECT chiamando una sequenza definita di funzioni libreria di emulatore.

Quando l'appiicazione An di utente chiede di recuperare dati dal database, essa invia all'emulatore un puntatore ad una struttura dati contenente parametri della istruzione SQL. di SELECT e alla fine della operazione ad An viene restituito un puntatore ai dati recuperati come risultato della query.

Un modo per eseguire il suddetto compito e* il seguente:

1) la Descrizione Tabella A, nell'area dati di Fig. 4, viene inizializzata secondo la descrizione tabella letta dal file ASCII contenente i dati di configurazione, chiamando la funzione libreria di emulatore _get_table_descr() LF in particolare l'array di struttura della Descrizione Tabella A viene inserito, una riga per ogni colonna della tabella;

2) all'apertura del file ASCII contenente i dati di utente riferiti alla configurazione di tabella acceduta in precedenza, la funzione verifica se il file non e' stato aperto prima. Se il file viene aperto per la prima volta:

- apre il file

- muove verso la prima riga chiamando la funzione _search_next_row().

In caso contrario, un puntatore al file si sposta verso la riga chiamando _search_next_row() e restituisce un puntatore alla riga, ripetendo il ciclo fino a:

- la fine del file, o

- quando e' stato letto il numero di righe specificato;

3) per ciascuna riga, esso legge la riga alla posizione corrente chiamando la funzione _fetch_row_at_curr_pos() e verificando se la istruzione WHERE scritta in B2 e' soddisfatta per quella riga; in questo caso i campi richiesti di quella riga di dati di utente vengono copiati in B1 (Descrizione di Accesso SELECT), inserendo nelle ultime tre colonne (nuli, long/int, char/ptr) in conformità' al tipo di dati;

4) alla fine chiudere il file della tabella di dati di utente.

Come conseguenza di questa funzione, l'uscita della istruzione di SELECT sara' disponibile nella tabella Descrizione Accesso (ultime tre colonne di Bl) e sara' restituita alla applicazione An.

Un esempio di LIBRERIA DI EMULAZIONE, come elencato sopra, può' essere il seguente.

Un sottoinsieme delle funzioni può' essere combinato per implementare una istruzione SQL.

Una piu' dettagliata descrizione di ciascuna funzione viene fatta qui di seguito.

FI NOME - _get„table_descr

DESCRIZIONE : Essa ottiene la descrizione della tabella per una tabella specificata (input parameter_table_name), inserendo nella struttura "row description" o descrizione di riga (output parameter__row_desc).

L‘appropriato file di tabella viene aperto e chiuso dopo il completamento della lettura della descrizione tabella. Essa registra un messaggio allorché' si verifica un errore.

F2

NOME : _open_table

DESCRIZIONE : Essa apre un file di tabella per una tabella specificata (input parameter _table_name). Il file può' essere aperto per la lettura o 1‘aggiornamento a seconda del tipo di azione o "action type" specificato (SELECT, DELETE e INSERT come specificato dal parametro d'ingresso __action_type). Essa restituisce alla funzione chiamante il puntatore al file aperto (parametro di uscita _file_ptr). Essa registra un messaggio allorché' si verifica un errore.

F3

NOME : _close_table

DESCRIZIONE : Essa chiude un file di tabella per un nome di tabella specificato (input parameter _table_name) .

Il puntatore di file e’ dato dalla funzione chiamante (input parameter _table_name) .

Esso registra un messaggio quando si verifica un errore.

FA NOME : _search_first_row

DESCRIZIONE : Essa ricerca la prima riga in una tabella. Ciò' significa: le linee della Descrizione Tabella vengono saltate, come linee di commento, finche' la seconda linea header (che chiude la Descrizione di Tabella) viene trovata.

Essa ricava dalla funzione di chiamata il puntatore di file (input parameter _file_pt r) e il nome della tabella (input parameter _table_name) che e' inserito nei messaggi di errore.

Se la riga viene trovata in modo corretto, essa restituisce alla funzione di trasferimento la posizione della riga nel file di tabella (output, parameter _file__pos): essa e' la posizione del line type char.

Essa assume il valore iniziale del file se il puntatore sta puntando al primo byte di una linea di file, altrimenti la ricerca fallisce.

Ultimo carattere ottenuto dal file:

- primo carattere della riga (quando e’ stato trovato correttamente)

- end-of-file trovato all'inizio di una linea (nessuna riga nella tabella)

- un primo carattere di linea inaspettato

- un end-of-file inaspettato.

Essa registra un messaggio quando si verifica un errore.

F5

NOME : _search_next_row

DESCRIZIONE : Essa ricerca la riga successiva in una tabella. Ciò' significa: le linee di Descrizione Tabella, se trovate, vengono trattate come "linee inaspettate".

Essa ricava dalla funzione di chiamata il puntatore di file (input parameter _file_ptr) ed il nome della tabella (input parameter _table_name) che e‘ inserito nei messaggi d'errore.

Se la riga e' trovata in modo corretto, essa restituisce alla funzione di chiamata la posizione della riga nel file della tabella (output parameter _fjle_pos): e' la posizione del carattere tipo di linea.

Essa assume il valore iniziale del file se il puntatore sta puntando al primo byte di una linea del file, altrimenti la ricerca fallisce.

Ultimo carattere ricavato dal file:

- primo carattere della riga (quando e' stato correttamente trovato)

- fine-del-file trovato all’inizio di una linea (non piu' righe nella tabella)

- un primo carattere di linea inaspettato

- un fine-del-file inaspettato.

Essa registra un messaggio quando si verifica un errore.

F6

NOME : _fetch_row_at_curr_pos

DESCRIZIONE : Essa esegue il fetch di una riga di tabella partendo dalla posizione attuale nel file di tabella (posizione data dalla funzione di chiamata nel puntatore al file _file_ptr).

Per scandire la riga essa usa la descrizione di riga data dalla funzione di chiamata nel parametro d'ingresso _row_cfesc.

Essa inserisce la "struttura di accesso" nell'area di memoria della funzione di chiamata (parametro _row_access).

Per maggiori dettagli, vedere la funzione interna _fetch_row.

Essa registra un messaggio quando si verifica un errore.

F7

NOME ; _fetch_row_at_abs_pos

DESCRIZIONE : Essa esegue il fetch di una riga di tabella partendo dalla posizione data esplicitamente dalla funzione di chiamata con il parametro d'ingresso _file_pos (in aggiunta al puntatore di file_file_ptr).

Per scandire la riga esso usa la descrizione di riga data dalla funzione di chiamata nel parametro d'ingresso _row_desc.

Essa inserisce la "struttura d'accesso" nell’area di memoria della funzione di chiamata (parametro _row_access).

Per maggiori dettagli, vedere la funzione interna _fetch_row.

Essa registra un messaggio quando si verifica un errore.

F8

NOME : _write_row

DESCRIZIONE : Essa registra un messaggio quando si verifica un errore.

Ingresso: A e B. Essa inserisce una riga in una tabella (la riga e' apposta in fondo alla tabella del file).

Essa usa la descrizione di riga data dalla funzione di chiamata come parametro d'ingresso. Essa prende i dati da scrivere dalla struttura Descrizione di Accesso B data dalla funzione di chiamata come parametro d'ingresso.

Apre e chiude il file di tabella.

Controlla se una riga con l’INDICE UNICO esiste già' in tabella.

F9

NOME : _delete_row

DESCRIZIONE : Essa cancella logicamente una riga in una tabella.

La funzione di trasferimento deve dare la posizione della riga nella tabella. Essa aggiorna il contatore delle linee cancellate.

FIO NOME : _refresh_table_file

DESCRIZIONE : Essa controlla, per una tabella specificata, se il contatore di linee cancellate ha raggiunto la soglia o meno . Se si, essa riscrive i file della tabella senza tutte le linee che sono state logicamente cancellate .in precedenza.

Il contatore viene resettato a Q quando la soglia viene superata e mantiene lo stesso valore quando il valore e' inferiore alla soglia.

FU

NOME __fetch_row

DESCRIZIONE : Essa esegue il fetch di una riga di tabella partendo dalla posizione attuale nel file della tabella (posizione data dalla funzione di chiamata nel puntatore di fiie_file_ptr).

Per scandire la riga essa usa la descrizione di riga data dalla funzione di chiamata nel parametro d'ingresso _row_desc.

Essa inserisce la "struttura d'accesso" nell'area di memoria della funzione di chiamata (parametro _row_access).

Essa ricava dalla funzione di chiamata il nome della tabella (parametro _table_name) e il numero di riga (parametro _row_nbr) che sono inseriti nei messaggi di errore.

Se non si verificano errori, la scansione termina alla fine di linea dopo l'ultima colonna.

Altrimenti, la scansione viene sospesa quando il primo errore viene rilevato.

Essa assume il valore iniziale del file se il puntatore sta puntando al carattere; immediatamente dopo lo speciale carattere che inizia la riga.

Ultimo carattere ottenuto dal file:

- fine_di__linea terminante l'ultima (o unica) linea che compone la riga (fetching terminato con successo);

- terminatone di colónna dell'ultima colonna di cui e' stato eseguito il fetch o cattivo carattere iniziante una ]inea o fine_di_linea inaspettato o fine_di_file inaspettato (fetching abortito).

Essa registra un messaggio quando si verifica un errore.

Il sopradescritto metodo di emulazione di un database relazionale in linguaggio SQL allo scopo di semplificare il porting di una applicazione esistente verso una apparecchiatura di destinazione presenta notevoli vantaggi in termini di risparmio di memoria e tempo di CPU.

Claims

RIVENDICAZIONI 1. Metodo per fornire un sottoinsieme di funzioni di database relazionale con interfaccia in linguaggio SQI. ad una applicazione esistente, comprendente le seguenti fasi: - creare tabelle SQL e definire i campi; - memorizzare, modificare e cancellare dati sulle tabelle create, ove un controllo di tipo viene eseguito in conformità' alla definizione di campo; e - recuperare tali dati usando filtri SQL; in cui il tempo di memoria e di CPU viene minimizzato riducendo le dimensioni del database in una fase di configurazione come richiesto, ed in cui le funzioni fornite possono essere suddivise in livelli differenti allo scopo di: - convertire una istruzione SQL, proveniente da una esistente applicazione (An) di utente, in una sequenza di funzioni (IFl...IFn) di interfaccia elementari, - usare dette funzioni di interfaccia per leggere/scrivere file (Fl...Fn) di dati, - processare dati in uscita da fornire alla applicazione (An) di utente richiedente.
2. Metodo secondo la rivendicazione 1, in cui le tabelle SQL create includenti le definizioni di campo vengono memorizzate in file (Fl...Fm-l) ASCII di configurazione e .i dati di utente vengono memorin oti in file (Fm,..Fn) ASCII di dall di utente.
3. Metodo secondo la rivendicazione 1, in cui i file dei dati di utente vengono citati secondo un algoritmo allo scopo di garantire la segretezza e l'accesso ai dati sono gestiti da un modulo (M3) di cifratura/decifratura.
4. Mezzi per effettuare il porting di una applicazione che usa un database relazionale in linguaggio SQL verso apparecchiature (HW2) a configurazione hardware ridotta su cui viene eseguito il metodo della rivendicazione 1, la fase di porting essendo solamente limitata a: - copiatura - ricompilazione - esecuzione dei file dell'applicazione.
5. Mezzi di porting secondo la rivendicazione 4, in cui un sottoinsieme di funzioni SQL da fornire, possono essere configurate e ridotte o incrementate a seconda delle necessita' della applicazione (An) di utente già’ esistente.