SE509645C2 - En metod för att samtidigt med protokollbaserad funktionsändring i en databas utföra verifiering av konverterad data - Google Patents

Description

15 20 25 30 35 509 645 Z Figur 1 visar ett exempel på hur ett generellt känt databassystem 100 utför en funktionsändring. Dessutom ingår, ett i figuren ej visat datorsystem, till exempel en PC, en stordator eller en telefonstation. Det kända databassystemet 100, visat schematiskt i Fig. la, gör en funktionsändring på följande sätt: En befintlig databas 102 tillfälligt med ett applikationssystem 106. Med hjälp av ett applikationsprogram i (gammal) samverkar applikationssystemet 106 läses data in från den gamla databasen 102. Data modifieras därefter av ett konverteringsprogram, data läggs eventuellt till eller tas bort, samt skrivs till en ny databas 104. Detta sker enligt ett känt protokoll 110, beskrivet i Fig. 1b, som indelas i en initieringsdel 112 och en arbetsdel 114.

Initieringsdelen 112 omfattar dels en specificering av den nya databasen 104, dels en deklaration av data till den nya databasen 104. I specifikationen bestäms sålunda hur den nya databasen 104 skall se ut, vad den skall innehålla samt vad som är tillåtet att göra med den nya databasen 104. I deklarationen bestäms konverteringsdirektiv, dvs regler för hur konverteringen av data från den gamla databasen 102 till den nya databasen 104 skall gå till. Detta program skrivs till exempel i SQL tillsammans med ett värdspråk.

I denna del skrivs även applikationsprogrammet.

Applikationsprogrammet utför själva konverteringen som i vissa fall kan bli mycket komplicerad, speciellt då en stor databas med många tabeller skall funktionsändras.

Arbetsdelen 114 utförs när databassystemet 100 år i passiv mod och den innefattar följande delar; utläsning av data från den gamla databasen 102, konvertering, samt verifiering och inläggning. Dessa delar år även visade i Fig. la, i enlighet med de i figuren anvisade markeringarna, romersk I-III; I. Utläsning data, varvid en rad läses ut från den befintliga databasen 102 till applikationsprogrammet i applikationssystemet 106. Det sker med kommandona SQL OPEN och SQL FETCH.

II. Konvertering, varvid den utlästa raden konverteras till den nya databasens format med hjälp av applikationsprogrammet. 10 15 20 25 30 35 3 509 645 III. Verifiering + inläggning, varvid verifiering, inläggning och även aktivering av raden till den nya databasen 104 sker. Med aktivering avses SQL COMMIT. I det fall aktivering kan ske beror det till exempel pà om främmande nyckelsamband har konverterats rätt. Ett exempel på detta kommer att beskrivas pà sid 6.

Aktivering kan ske här eller när hela databasen har gàtts igenom.

Vid verifieringen kontrolleras att raden är riktig, till exempel att primära nycklar är unika. Därefter kontrolleras att raden är konsistent och till slut godkännes raden. För att undvika inkonsistens så mäste rad för rad i varje tabell gås igenom tills alla tabeller i databasen har gàtts igenom. För att klara av en fullständig verifiering av stora databaser måste ibland mycket omfattande transaktioner ske. Transaktion för en databas betyder förändring från ett konsistent tillstànd till ett annat konsistet tillstànd. Däremellan kan ett inkonsistent läge råda.

Transaktionen kan också bestå av flera rader som ingàr i ett och samma överföringspaket till den nya databasen 104. Det betyder att flera rader läses in och konverteras innan verifieringen och inläggningen sker. I vissa fall kan det medföra problem, exempelvis vid stora transaktioner kommer det att behövas stora resurser. Inläggning innebär att raden läggs in i den nya databasen 104. Vid aktivering görs raden åtkomlig utanför transaktionen.

Nedan ges ett exempel på vilken typ av problem som kan uppstå vid funktionsändring. Antag att en befintlig databas, illustrerad av tabellen nedan, innehåller information om anställda och respektive närmaste chef i ett företag.

AnsNo Avd Närmastechef 345 A 123 456 A 123 567 A 123 123 A 234 234 A - 10 15 20 25 30 509 645 ” Tabellen visar en databas, ANSTÄLLDA, med ett antal poster. Varje post har flera fält; AnsNo (anställningsnummer), Avd (avdelning) och Närmastechef (närmaste chef). Databasens schema innehåller för vart och ett av fälten, bland annat en domän som specificerar tillåtna värden; ans_no_dom, avd_dom och ans_no_dom, respektive.

Varje anställd har ingen eller en överordnad och omvänt så har varje anställd ingen eller flera underordnade. Primär nyckel (primary key) är i detta fall AnsNo och främmande nyckelsamband (foreign key) är i detta fall Närmastechef som likväl tillhör databasen ANSTÄLLDA. Detta kan skrivas i SQL enligt följande: CREATE TABLE ANSTÅLLDA ( AnsNo ans_no_dom NOT NULL, Avd avd_dom NOT NULL, Närmastechef ans_no_dom NULL, PRIMARY KEY (AnsNO) , FOREIGN KEY (Närmastechef) REFERENCES (ANSTÄLLDA) ON DELETE NULLIFY; Antag vidare att företaget omorganiserar så att samtliga anställda kommer att få ett nytt anställningsnummer. Efter den genomförda konverteringen vill man att den nya databasen skall ha följande utseende enligt nedan: AnsNb Avd Närmastechef 1345 A 1123 1456 A 1123 1567 A 1123 1123 A 1234 1234 A - Ett försök till rad-för-rad konvertering i det kända databassystemet 100 blir som nedan. lO 15 20 25 30 5 509 645 AnsNo Avd Närmastechef 1345 A ;¿g; 456 A 123 567 A 123 lg; A 234 234 A - Den första raden kommer att innehålla ett främmande nyckelsamband (understruket) vars värde ej blivit definierat och transaktionen kommer att rullas tillbaka. Det främmande nyckelsambandet pekar helt enkelt på en rad som inte existerar.

I det allmänna fallet har detta problem lösts genom att låta hela tabellen ingå i en och samma transaktion. Detta medför att stora resurser beläggs hos databassystemet 100. Resonemanget ovan kan generaliseras till att gälla även flera tabeller: Då en transaktion verkställs kontrolleras databasens konsistens genom att hämta in rader som refereras genom nyckelsamband. Misslyckas detta på grund av att refererad rad ej existerar, så analyseras den egna transaktionen. Analysen av stora transaktioner kommer därför att bli tidsödande och följaktligen även hela funktionsändringen.

För att kringgå nackdelarna enligt ovan kan konverteringen specificeras så att rader som kommer att refereras konverteras först. Analysen av detta och tillhörande konverteringsprogram är mycket komplexa.

US 5,l50,308 av Hooper m fl. beskriver uppbyggnaden av en databas som är relaterat till ett AI system, artificiell intelligens.

US 4,697,266 av Finely, beskriver en metod att förebygga att en databas fördärvas som ett resultat av ett oförväntat avbrott, stängning av systemet. 10 15 20 25 30 so9 645 2 REDoGöRELsE FÖR UPPFINNINGEN Problemet är att vid funktionsändring kan stora resurser beläggas i databassystemet. Ändamålet med föreliggande uppfinning är att minska resursutnyttjandet, förkorta konverteringstiderna och samtidigt förenkla dataöverföringen från den befintliga databasen till den nya databasen med hjälp av ett nytt databashanteringsprotokoll. Ändamålet med föreliggande uppfinning är vidare att förenkla förfarandet för databashantering, vilket uppnås genom att användaren ej behöver skriva ett applikationsprogram för att överföra data från den befintliga databasen till den nya databasen. Det enda som behöver göras är att deklarera konverteringsdirektiv.

Föreliggande uppfinning hänför sig till ett nytt databas- hanteringsprotokoll för förändring av data från en gammal databas till en ny databas. Det nya protokollet som ligger i ett nytt databassystem är indelat i olika delar; en initieringsdel, en arbetsdel och en verifieringsdel.

I initieringsdelen ingår en specificerings- och en deklarationsfas. Specificeringsfasen består av samma arbete som i det befintliga databassystemet 100, Pig. la. Däremot skiljer sig deklarationsfasen från det tidigare protokollet. Det nya är att konverteringsdirektiv tas fram och därefter de till konverteringsdirektiv görs skrivs, kompileras konverteringstabeller. Att skriva på ett enkelt sätt genom att specificera hur data i den nya databasen skall genereras baserat på data från den gamla databasen 202. Det sker exempelvis med hjälp av FUSQL.

I arbetsdelen ingår en inläsnings-, en utläsnings-, en konverterings- och en inläggningsfas. För hantering av de olika faserna i arbetsdelen används ett operativsystem. Inläsningsfasen innebär att konverteringsdirektiv läses in i operativsystemet 10 15 20 25 30 7 509 645 från konverteringstabeller. Därefter kommer utläsningsfasen, vilket innebär att data läses ut från den befintliga databasen till operativsystemet. Därpå följer konverteringsfasen som innebär att data konverteras i enlighet med specifikationen och konverteringsdirektiven som sattes upp i initieringsdelen. Under inläggningsfasen läggs sedan konverterade data in i. den nya databasen. Förfarandet upprepas (utläsning, konvertering, inläggning) tills hela databasen behandlats» Efter det att en konvertering har skett, är emellertid statusen för den nya databasen okänd, Det betyder till exempel att nya icke initialiserade andrahandsindex kan ha adderats, att kontrollvillkor som innehåller konverterade data, ej har exekverats. Detta innebär att den nya databasen kan vara inkonsistent. Med det menas att existensen av databasens orubbade tillstànd inte är garanterad, då till exempel primära nycklar kan ha konverterats fel. På samma sätt är heller inte främmande nyckelsamband.garanterade, eftersonxdessa kan innehålla felaktigt konverterade attribut. Den nya databasen är således laddad med verifierad. data (populerad) utan att vara Detta görs i verifieringsfasen.

I verifieringsdelen, verifieringsfasen, görs en verifiering av den nya databasen för att se om den är konsistent, exempelvis utförs test av primära nycklar, värdeomfáng, index, främmande nyckelsamband samt göres en registrering av fel. I de fall då fel detta och Verifieringsfasen sker i upptäcks så meddelas enklare fel korrigeras automatiskt. samarbete med ett databashanteringsystem (DBMS) och den nya databasen.

En fördel med ovannämnda uppfinning är att databassystemet är mer användarvänligt dä endast konverteringsdirektiv mäste framställas. Det enda användaren måste veta är hur den nya databasen skall se ut efter funktionsändringen.

En annan fördel med ovannämnda uppfinning är att den nya databasen verifieras efter det att data lagts in, vilket medför en bättre kontroll av att den nya databasen är korrekt efter 10 15 20 25 30 509 645 3 funktionsändringen. fördel med funktionsändringen sker Ytterligare ovannämnda uppfinning är att snabbare därför att databassystemet behöver belägga minimalt med resurser, tack vare att den nya databasen redan är uppbyggd och att de normala àtkomstvägarna kan användas. Verifiering av varje rad kommer att kunna ske på det mest optimala sätt som databassystemet erbjuder. Ännu en fördel med ovannämnda uppfinning är att det inte behövs någon beroendeanalys eftersom specifikationen av förändringarna är helt deklarativ. Ännu ytterligare en fördel med ovannämnda uppfinning är att det är möjligt att göra ändringar i databasen med minsta möjliga påverkan pä databassystemet.

Vidare fördel med ovannämnda uppfinning är att godtyckliga förändringar kan beskrivas och testas så att funktionsändringen kan ske snabbare därför att databassystemet behöver belägga minimalt med resurser. Detta tack vare att den nya databasen redan är uppbyggd och att de normala àtkomstvägarna kan användas.

Verifiering av varje rad kommer att kunna ske på det mest optimala sätt som databassystemet erbjuder.

Uppfinningen kommer nu att beskrivas närmare med hjälp av föredragna utföringsexempel och næd känvisning till bifogade ritningar.

FIGURBESKRIVNING Figur la visar ett redan befintligt förfarande för funktionsändring av en databas till en annan databas.

Figur lb visar ett befintligt överföringsprotokoll steg för steg.

Figur 2 visar ett blockdiagram över ett nytt databassystem.

Figur 3 visar ett nytt överföringsprotokoll för den nya funktionsändringen.

Figur 4 visar ett flödesschema på verifieringsfas del 1. 10 15 20 25 30 ° 509 645 Figur 5a visar ett flödesschema på verifieringsfas del 2.

Figur Sb visar fortsättningen.pà flödesschema för verifieringsfas del 2.

Figur 5c visar fortsättningen.pà flödesschema för verifieringsfas del 2.

Figur 6 visar ett flödesschema pà verifieringsfas del 3.

FÖREDRAGNA UTFöRINssFoRMER Databashantering finns pá många olika platser där data behöver och/eller detta fall är det i en telefonstation, mera samlas in lagras. I bestämt hantering av data i telefondatabaser. Uppfinningen behöver naturligtvis inte strikt hålla sig till detta område inom databashantering utan kan naturligtvis användas i vilken typ som helst av databas för att göra en funktionsändring av data till en annan databas.

Först beskrivs figurerna 2 - 6 översiktligt.

Figur 2 visar ett blockdiagram över ett nytt databassystem 200, en generell strukturbild av hur det nya databassystemet 200 kan arbeta. Figuren visar ett nytt förfarande, metod, för att göra en ny funktionsändring av en befintlig databas 202 till en för det nya databassystemet 200 ny databas 204. Det nya databassystemet 200 består av den befintliga databasen 202, den nya databasen 204, konverteringstabeller 208, ett operativsystem 210 och ett databashanteringssystem (DBMS) 212. Den befintliga databasen 202 kan innehålla exakt samma data som den befintliga databasen 102 i Fig. la. Slutresultatet i den nya databasen 204 är det innehåll som man ville uppnå i det gamla protokollet men kanske inte kunde få pà grund av det gamla protokollets struktur.

Figur 3 beskriver närmare ett nytt protokoll 300 för den nya funktionsändringen i det nya databassystemet 200, jämför även markeringarna A-F i Fig. 2. Det nya protokollet 300 är indelat i tre delar; En första del exempelvis en initieringsdel 302, en andra del exempelvis en arbetsdel 304 och en tredje del exempelvis en verifieringsdel 306. Initieringsdelen innebär en 10 15 20 25 30 35 509 645 2D specificerings- och eai deklarationsfas 24. Specificeringsfasen medför att man bestämmer hur den nya databasen 204 skall se ut.

Deklarationsfasen A, innebär att konverteringsdirektiv tas fram därefter och skrivs, för att konverteras till konverteringstabeller“ 208. Arbetsdelen 304 sköts av operativsystemet 210, vilken arbetsdelen innefattar följande faser; Inläsningsfasen B, vilken innebär att konverteringsdirektiv läses in i operativsystemet 210 från konverteringstabeller 208. Därefter kommer utläsningsfasen C, vilken innebär att data läses ut fràn den befintliga databasen 202 till konverteringsfasan D, vilken innebär att data konverteras i operativsystemet 210. Nästföljande fas är enlighet med specifikationer och de konverteringsdirektiv som satts upp i initieringsdelen 302. Konverterade data läggs in i den nya databasen 204 under en inläggningsfas E. Förfarandet upprepas (utläsning, konvertering, inläggning) tills hela den databasen 202 behandlats. verifieringsfas F som sköts av databashanteringssystemet (DBMS) gamla Verifieringsdelen 306, 212 är indelat i tre faser, se figurbeskrivningar 4-6. Här görs bland annat kontroll av primära nycklar, främmande nyckelsamband och värdeomfàng.

Figurerna 4 - 6 beskriver verifieringsfasen, F, vilken är indelad i tre faser. SQL kommandon har använts, där detta var möjligt, för att visa verifieringsfasens förfarande med den nya databasen 204.

Figur 4 beskriver i ett första flödesschema hur fas 1 i verifieringsfasen fungerar steg för steg. Flödesschemat börjar med ett block 400 "start fas 1" följt av ett block 402 "tabeller där ändring skett". Därefter kommer ett block 404 "SQL OPEN", ett block 406 "loop L10 tabeller" och ett block 408 "SQL FETCH".

Sedan kommer ytterligare ett block 410 "SQL OPEN". Nästa block 412 som följer är "loop L12 rader" och ett block 414 "SQL FETCH".

Ytterligare block 416 "SQL INSERT'" och block 418 "fel ?". I det fall då inget fel har uppstått görs "SQL COMMIT", block 420. I det fall då fel har uppstått görs "felhantering” block 422. Efter 10 15 20 25 30 35 H , 509 645 block 420 eller 422 kommer "nästa rad åter Ll2" block 424 och block 426 "SQL CLOSE". Därefter sker "registrering av hur det gått ftabeii", block 428, följt av "nästa tabell äter mo", block 430, nästa block 432 "SQL CLOSE" och det sista blocket 434 i det första flödesschemat för fas l är "slut fas 1".

Figur 5 beskriver i ett andra flödesschema hur fas 2 i verifieringsfasen utföres. Flödesschemat börjar med ett första block 500 "start fas 2", se Fig Sa, därefter följer "tabeller där ändring skett", block 502, följt av "SQL OPEN" block 504. Därnäst kommer block 506 "loop L20 tabeller" samt ytterligare nästa block 508 "SQL FETCH". Därefter följer i tur och ordning "SQL OPEN", block 510, "loop L22 rader", block 512, samt "SQL FETCH'" block 514. Nästa block 516 är "SQL PREPARE" därefter block 518 “fel ?“ samt block 520 "felhantering". "nästa rad åter L22", block 522, dà inget fel har uppstått eller efter block 524 görs "SQL CLOSE". Vidare följer block 526 "X2", se Fig Sb, därefter block 527 "SQL OPEN" samt block 528 "loop L24 FN" ytterligare block 530 "SQL FETCH". Nästa block 532 "SQL OPEN" följs av "loop L26 rad", block 534, och därefter av "SQL FETCH"H block 536, samt block 538 SQL OPEN. Ytterligare block 540 SQL FETCH' följs av nästa SQL CLOSE block 542 samt block 544 "existerar raden ?".

I det fall fel har uppstått görs I det fall raden existerar, svaret är JA, så L26", block 548, och därefter "SQL CLOSE", block 550. Existerar inte raden, svaret är NEJ, görs utföres "nästa rad åter "felhantering", block 546, så utföres "nästa rad åter L26", block 548. Efter block 550 så görs "nästa FN åter L24", block 552. Så block 554 "SQL CLOSE" och block 556 "registrering av hur det gått i tabell". Vidare följer block 558 "X3", se Fig 5c, därefter block 560 SQL OPEN och block 562 "loop L28 av tabeller". I nästa block som följer är block 564 SQL FETCH och block 566 SQL OPEN, därefter block 568 SQL FETCH samt fràgeblock 570 "finns FN". I det fall svaret är JA pà frågan i block 570 block 572 SQL SELECT. ytterligare en fråga "har refererande tabell analyserats", block 574. Är svaret NEJ så görs block 576 "blocken 532 - 550" följt av "registrering av hur det gàtt i tabell", block 578 och därefter följer ytterligare följer Därefter följer 10 15 20 25 30 35 509 645 121 “nästa rad åter L28" block 582. I det fall svaret är NEJ i block 570 "finns FN" så görs SQL CLOSE, block 580, i ett ytterligare steg görs "nästa rad åter L28", block 582. Är varet JA pà frågan "har refererande tabell analyserats" block 574 följer “nästa rad åter L28", block 582. Nästa steg som följer är SQL CLOSE, block 584 och följt av "registrering av hur det gått i tabell", block 586. Nästkommande steg är "nästa tabell åter L20", block 588.

Avslutningsvis slutar fasen 2 med att SQL CLOSE och härmed är fas 2 slut, block 592.

Figur 6 beskriver i ett tredje flödesschema hur fas 3 av verifieringen fungerar. Det börjar med ett första block 600 "start fas 3", därefter "tabeller där ändring skett", block 602, samt "SQL OPEN", block 604. Därefter kommer block 606 "loop L30 tabeller" och "SQL FETCH", block 608, samt "har felregistrering tidigare gjorts ?", block 610. Om svaret är NEJ görs "SQL OPEN", block 612, "loop L32 rader", block 614, "SQL FETCHW, block 616, samt "släpp lås för rader SQL INSERT"H block 618. Därefter genomlöps "nästa rad åter L32“, block 620, och "SQL CLOSE", block 622. Nästföljande block 624 är "uppdatera flaggor". "nästa tabell åter L30", block 626 som även följer efter JA i "har tidigare felregistrering gjorts", block 610. Till slut görs "SQL CLOSE", block 638, och "slut fas 3", block 630.

Därpå följer Här nedan beskrivs på ett övergripande sätt hur en funktionsändring, ändring av information, från den befintliga databasen 202 till den nya databasen 204 sker, se Fig. 2, för att uppnå ett givet slutresultat. Det nya protokollet innehåller följande faser, se Pig. 3: specificeringsfas, deklarationsfas, A, inläsningsfas, B, utläsningsfas, C, konverteringsfas, D, inläggningsfas, E, och verifieringsfas, F. Ovan nämnda faser kan byta ordning, de är ej bundna till ovan föreslagna följd. Denna fasföljd är för denna utföringsform den bästa. Verifieringen har i detta fall beskrivits med. SQL kommandon, men, det är inte nödvändigt utan även andra databashanteringssprák kan användas.

I specificeringsfasen sätts ett schema upp för hur den nya 10 15 20 25 30 13 509 645 databasen 204 skall se ut. Här bestäms vilka regler som skall användas mm för data som läggs till och tas bort. Denna fas är den samma som för det gamla protokollet och görs deklarativt i SQL-DDL (SQL Data Definition Language).

I deklarationsfasen deklareras hur den nya databasen skall se ut. vilket betyder att regler tas fram för hur data skall konverteras.

Här tas också frana och skrivs konverteringsdirektiv, Reglerna för hur data skall genereras från den gamla databasen 202 till den nya databasen 204 konverteringsdirektiv. De nya konverteringsdirektiven kompileras specificeras i till konverteringstabeller 208.

Inläsningsfasen medför att konverteringstabeller läses in i operativsystemet 206, Fig. 2. Operativsystemet 206 hanterar inläsnings-, utläsnings-, konverterings- och inläggningsfasen.

I utläsningsfasen hämtas gamla data från den befintliga databasen 102 till operativsystemet 210.

I konverteringsfasen konverteras gamla data med hjälp av konverteringsdirektiven och data för den nya databasen 204 genêreraS .

I inläggningsfasen läggs de nya datavärdena in så att databasen kommer att vara populerad, alltså alla datavärden kommer att ligga i den nya databasen 204. Däremot så har ingen verifiering gjorts av den nya databasen 204. Verifieringen sker i verifieringsfasen. Efter inläggningsfasen kan databasen vara inkonsistent I verifieringsfasen, som sköts av databashanteringssystemet 212, görs alla tester om databasen är konsistent eller ej. Denna fas är i sin tur indelad i flera olika faser.

Databasändringsfunktionen klarar av verifiering av den nya databasen 204 efter det att funktionsändring gjorts, där data har konverterats eller nya sökindex har blivit definierade. 10 15 20 25 30 35 509 645 H skall bli kontrollerade och vilka typer av kontroller som skall göras.

Information tas fram om vilka tabeller som Verifieringsfasen gör integritetskontroll, test av bland annat primära nycklar, värdeomfáng och främmande nyckelsamband.

Nedan beskrivs hur den nya verifieringsfasen fungerar steg för steg med bland annat hjälp av SQL kommandon. Verifieringsfasen är indelad i tre faser med olika underdelar, vilka är så indelade att det finns möjlighet att sätta dessa underdelar i annan följd än den som här visas.

Verifieringsfasen 1, Fig. 4, börjar med att starta fasen 1. Först läses en systemtabell, som innehåller metadata om systemets tabeller. Tabellen innehåller bland annat information om vilka ändringar som har skett. Systemtabellen har byggts upp i samband med att den nya databasen definierats. SQL OPEN används för att öppna systemtabellen med metadata, data om data. Kommandot SQL OPEN sätter upp sökvillkor för att läsa metadata om alla tabeller där en ändring har skett i den nya databasen 204. SQL OPEN är en standardoperation som för över sökvillkoret och positionerar en postpekare. Här börjar loop LIO av tabeller, vilket medför att fasen 1 tar den första tabellen ur systemtabellen, därefter nästa tabell tills alla ändrade tabeller i systemet har gåtts igenom. Kommandot SQL FETCH exekverar sökvillkoret som satts upp i SQL OPEN. I detta fall så hämtas första tabellen som uppfyller villkoret. Nästa gång SQL FETCH exekveras så hämtas nästa tabell som uppfyller villkoret i SQL OPEN. SQL OPEN medför i detta fall att sökvillkor sätts upp för läsning med hjälp av linjärsökning av samtliga rader i den ändrade tabellen. Här börjar loop L12 av rader i tabell, vilket medför att fas 1 tar den första raden och därefter nästa rad tills alla rader i tabellen har gåtts igenom. SQL FETCH exekverar sökvillkoret som satts upp med SQL OPEN, för en ändrad tabell, vilket medför att en rad hämtas in. Nästa gäng SQL FETCH utförs hämtas nästa rad. I uppfinningen används ett speciellt SQL sQL INSERT' som är situation. Det innebär att SQL INSERT*ej lägger in något data i kommando, särskilt framtaget för denna 10 15 20 25 30 35 *F .sne 645 raden eftersom data redan finns inlagt men gör verifiering, ett test som undersöker att det ej existerar någon rad i tabellen med samma värde för primärnyckeln. Därefter sätts lås för raden och en test om något fel uppstått. Har inget fel uppstått så görs SQL COMMIT, vilket bekräftar det som har skett med den nya raden, det vill säga verkställer den nya raden. SQL COMMIT innebär att sökfunktioner, accessfunktioner, uppdateras. Om däremot ett fel har uppstått vid SQL INSERT' görs en utförlig felregistrering.

Har ett fel uppstått så innebär det att konverteringsdirektivet är felaktigt. Felaktig rad elimineras efter antingen SQL COMMIT eller felregistreringen är loop L12 slut, vilket innebär att man gär tillbaka till början på loop Ll2 tills alla rader i tabellen har gâtts igenom. SQL CLOSE används för att stänga den ändrade tabellen. Därefter följer en registrering av hur det gått i tabellen, vilket innebär att en markering görs i systemtabellen över systemets tabeller. Åter nästa tabell loop LlO, till sista tabellen i systemtabellen är färdighanterad. Avslutningsvis i fasen 1 stängs systemtabellerna med SQL CLOSE. Därmed är fas 1 slut och befintliga sökfunktioner är uppdaterade.

Verifieringsfasen 2, Pig. 5, inleds med att fasen 2 startas.

Först läses systemtabellen, samma systemtabell som i fasen 1, som innehåller metadata om systemets tabeller som bland annat informerar om vilka ändringar som har skett. Därefter används SQL OPEN för att öppna systemtabellen med metadata, jämför med fasen 1 blocket 404.

En första underdel som bland värdeomfång. Nästa steg börjar med en loop L2O av tabeller, följer gör annat test på vilket innebär att varje tabell där en ändring tidigare har gjorts kommer att gås igenom, enligt data från systemtabellen.

Nästa steg används ett kommando SQL FETCH för att läsa ut data ur systemtabellerna om tabellen där en ändring har skett. I kommande steg används därefter SQL OPEN för att öppna tabellen där en ändring har skett. Jämför med fasen 1 küock 408. Nästa steg börjar med en loop L22 av rader, vilket innebär att första raden i tabellen tas fram. Detta medför att fasen 2 tar den första 10 15 20 25 30 35 509 645 Ib raden och därefter nästa rad tills alla rader i tabellen har gåtts igenom. Detta görs med SQL FETCHÜ Tack vare att SQL FETCH' ej tar hänsyn till eventuella radlås är raderna åtkomliga. I normal SQL FETCH kan man ej läsa lästa rader, jämför med fasen 1 blocket 408. Därefter följer SQL PREPARE, vilket innebär att en kontroll görs av index riktighet, att värdeomfàng stämmer överens med uppsatta regler. I nästa steg följer en fråga "har fel uppstått vid SQL PREPARE ?". I det fall ett fel har uppstått vid SQL PREPARE görs en felregistrering, se block 422. För det fall fel ej uppstått efter det att SQL PREPARE har utförts så kommer ett sista steg i loop L22, vilket innebär att fasen 2 går till nästa rad i tabellen och fortsätter så tills den sista raden i tabellen är bearbetad. Därefter kommer ytterligare ett steg med SQL CLOSE, vilket används för att stänga den ändrade tabellen.

Blocket X2 på nästkommande sida. är endast till för att kunna fortsätta flödesschemat Nästa underdel kommer att testa utgående referenser, främmande nyckelsamband och deras riktighet. Sökvillkor sätts upp för att hitta en refererad tabell som det främmande nyckelsambandet pekar på. Nästa steg börjar med att öppna den refererade tabellen, SQL OPEN, främmande nyckelsamband (FN), vilken gör att första tabellen som som sökvillkoret satt upp, därefter~ görs en loop> L24 refererats tas fram. Det medför att fasen 2 tar den första tabellen där ändring har skett och därefter nästa tabell där ändring har skett tills alla ändrade tabeller har gåtts igenom.

Som ännu ett steg används SQL FETCH för att läsa data om den refererade tabellen, vilket medför att främmande nyckelsamband läses. I de fall det finns främmande nyckelsamband att läsa så görs det med SQL OPEN, vilket innebär att i den refererande tabellen öppnas. Sökvillkor sätts upp sä, att den tabell som främmande nyckelsamband pekar på öppnar rader för läsning. Nästa steg är loop L26 av rader i den refererande tabellen, vilket medför att fasen 2 läser den första raden i den refererande tabellen, refererande rader i den refererande tabellen har gåtts igenom. I därefter' nästa ändrade refererande rad tills alla loop 26 ingår följande steg; Med hjälp av SQL FETCH* hämtas den 10 15 20 25 30 35 17 509 645 refererande raden i den refererande tabellen. Det lästa datat innehåller värdet på det främmande nyckelsambandet. Detta värde utgör sökvillkoret i den refererade tabellen. Villkoret överförs med SQL OPEN. En rad som uppfyller villkoret hämtas med SQL FETCH', varefter den refererade tabellen stängs med SQL CLOSE. I I de fall då den refererade raden ej existerar pekar det främmande nyckelsambandet nästkommande steg frågas: "existerar raden ?“. på en rad som ej existerar och en felregistrering görs, se block 422. I de fall då den refererade raden existerar eller efter fel- hanteringen så följer nästa steg, slut på loop L26. Detta steg, loop L26, innebär att nästa refererande rad bearbetas i den refe- rerande tabellen till den sista refererande raden i den ändrade refererande tabellen. Därefter följer SQL CLOSE, vilket används för att stänga den ändrade refererande tabellen. Efter SQL CLOSE eller då det ej finns något främmande nyckelsamband kommer ett steg' där det är slut på loop L24. Detta innebär att nästa främmande nyckelsamband läses från systemtabellen. När alla rader i den ändrade tabellen är färdigbehandlade så följer nästa steg, SQL CLOSE som stänger den ändrade tabellen. Vidare sker en registrering av hur det gått i tabellen. Blocket X3 är endast till för att kunna fortsätta flödesschemat på nästkommande sida.

Därpå följande underdel kommer att testa ingående referenser, främmande nyckelsamband och deras riktighet. Med SQL OPEN öppnas systemtabellen med metadata om systemets tabeller. Samtliga ändrade tabeller kommer att analyseras. Nästa steg börjar med en loop L28 av tabeller, vilket innebär att varje tabell som har en ingående referens kommer att gås igenom, enligt data från systemtabellen. Ändrade tabeller hämtas med SQL FETCH. Det lästa data är indata till en ny fråga till en annan systemtabell innhällande främmande nyckelsamband. Denna tabell öppnas med SQL OPEN för hämtning av det främmande nyckelsambandet där den analyserade tabellen ingår som refererad tabell hämtas med SQL FETCH. Därefter kommer frågan "finns FN?", finns främmande nyckelsamband. Är svaret JA att det finns främmande nyckelsamband hämtas data med SQL SELECT, vilket innebär att data hämtas om den tabelldata. refererande tabellen från systemtabellen med l0 l5 20 25 30 35 SÛ9 645 zš Ytterligare en fråga "har refererande tabell analyserats". Har sambandet ej analyserats, svaret är NEJ, görs test av utgående referens på samma sätt som i blocken 532-550 följt av en registrering av hur det gått i tabellen samt därefter nästa tabell loop L28. År svaret NEJ på frågan "finns FN" görs SQL CLOSE för att stänga tabellerna med främmande nyckelsamband varpå nästa tabell åter loop L28, vilket innebär att nästa tabell analyseras. Har refererande tabell analyserats, svaret är JA, görs nästa steg som är nästa tabell loop L28 eftersom sambandet analyserats i ett tidigare steg.

SQL CLOSE, främmande nyckelsamband. Därefter följer en registrering av hur Nästa steg som följer är vilket används för att stänga systemtabellen. med det gått i tabellen. Nästkommande steg är att gå till nästa tabell i sytemtabellen, slut på loop L20. Loopen L20 görs tills sista tabellen i systemtabellen är färdighanterad och till slut stängs systemtabellerna med hjälp av SQL CLOSE. Härmed är fas 2 slut.

Verifieringsfasen del 3, Fig. 6, inleds med att fasen 3 startas.

Först läses systemtabellen, samma systemtabell som fasen 1, som innehåller metadata om systemets tabeller bland annat information om vilka ändringar som har skett, för att kunna göra verifieringsfasen 3. Jämför med block 402. SQL OPEN används sedan för att öppna tabellen med metadata. Jämför med block 404. Nästa steg börjar med en loop L30 av tabeller, vilket innebär att varje tabell, där en ändring har skett, kommer att gås igenom till den sista tabellen. I loopen L3O ingår följande steg: Med hjälp av SQL FETCH läses data i tur och ordning om tabeller där en ändring har skett. Jämför med block 408. Steget därnäst är en fråga "har felregistrering tidigare gjorts ?", alltså, har tidigare fel- registrering gjorts i fasen 1 och fasen 2?. Besvaras frågan med ett NEJ görs SQL OPEN. Jämför med block 414. Detta innebär att tabellen öppnas. Nästa steg börjar med loop L32 av rader, vilket medför att fasen 3 tar den första raden i tabellen och därefter nästa rad, tills alla rader i tabellen har gåtts SQL FETCH' medför att data läses ur rad i tabellen. Jämför med block 514. Sista steget i loop L32 är att släppa lås för rader igenom. 10 15 20 25 30 35 19 509 645 som tidigare satts med SQL INSERT', se fasen 1. Här slutar loop L32, vilket innebär att fasen 3 går till nästa rad i tabellen till den sista raden är hämtad. Därefter sä kommer ett steg med SQL CLOSE som stänger den ändrade tabellen, varpá flaggor upp- dateras, vilket innebär att den information som finns i system- tabellerna om vad som ändrats, lagts till, tagits bort eller uppdateras. Är svaret JA pá frågan "har felregistrering tidigare gjorts ?", innebär detta att felregistrering tidigare gjorts i fasen 1 eller i fasen 2 och uppdateringen av flaggor ej skall ske. Därefter följer nästa tabell, som tidigare tagits fram i blocket 602, i denna fasen 3. Här slutar loop L30, den genomlöps till dess sista tabellen är färdighanterad och till slut stängs systemtabellerna med hjälp av SQL CLOSE. Härmed är fasen 3 slut.

Felhantering När konverteringen och inläggningen av data avslutats, kontrolleras att databasen är konsistent. Verifieringsfasen gör en första kontroll av att index som samtliga används av databassystemet är uppbyggda, till exempel primära nycklar.

Eventuella fel såsom dubbla primära nycklar registreras. När samtliga sökindex har byggts upp, kontrolleras att främmande nyckelsamband och övriga begränsande regler (restriktioner) är uppfyllda. Exempel på övriga begränsande regler kan vara att ett attribut har ett max-värde. När hela databasen har verifierats, och eventuell felinformation. ges meddelande om resultatet Databasen kan se på ut följande sätt efter steg E.

IIIIII_IIII_IIIIIIIIIIIIII___________-IIIIIIIII----III-I AnsNo Avd Nårmastechef 1345 A ll23 1456 A 1123 1567 A 1123 1123 A 1234 1234 A - 1345 C ll23 ! FEL NO l, DUBBLA PN ! 1789 C 1999 I FEL NO 2, ODEFINIERAD FN ! 0000 C 1123 I FEL NO 3, OGILTIG PN I 10 15 20 25 30 509 645 go Vid uppbyggnaden av accesstöd, kommer fel att upptäckas. Vid kontroll av främmande nyckelsamband kommer fel nummer 1 nummer 2 att upptäckas. Vid kontroll av restriktioner kommer fel nummer 3 att upptäckas.

Andra utföringsexempel beskrivs nedan.

Funktionsändring frán åtminstone två gamla databaser till en ny databas.

Funktionsändring från en gammal databas till åtminstone två nya databaser.

Funktionsändring av distribuerande databaser exempelvis från åtminstone två gamla databaser till åtminstone två nya databaser.

Att uföra en verifiering av den nya databasen efter det att data lagts in såsom beskrivits ovan medför vissa fördelar, som även framgått tidigare. Bland annat möjliggörs en god kontroll av att den nya databasen är korrekt efter funktionsändringen._ Vidare sker funktionsändringen snabbt, och varje rad kan verifieras på ett optimalt sätt. till de utan kan Uppfinningen är naturligtvis inte begränsad ovan beskrivna och pà ritningen visade utföringsformerna, modifieras inom ramen för de bifogade patentkraven. SQL INSERT* kan modifieras till att ej sätta làsbitar. I detta fall behöver SQL FETCH ej det att databasspràket SQL är ej nödvändigt att använda utan att andra modifieras. Tidigare har nämnts databasspràk gär bra.

Claims (11)

10 15 20 25 30 35 soà 645 21 PATENTKRAV

1. En metod att funktionsändra från en befintlig databas till en ny' databas i ett databassystem, vilken börjar' med att vissa specifikationer tas fram som specificerar hur den nya databasen skall se ut databasen, k ä n n e t e c k n a d av att metoden består av tre delar: jämfört med den befintliga initierings- (302), arbets- (304) och verifieringsdel (306), att specificering och framtagande av konverteringdirektiv görs i att i data ut från den befintliga databasen (202), konverteras och läggs in i den nya initieringsdelen, arbetsdelen tas databasen (204) i enlighet med de specifikationer som tidigare tagits fram, varefter i verifieringsdelen den nya databasen verifieras, vilket medför att kontroll sker av huruvida den nya att ändringar databasen är konsistent, och när den nya databasen verifieras skett från den befintliga databasen (202) till den nya databasen (204), där en kontrolleras vilka som verifiering av primära nycklar, främmande nyckelsamband och värdeomfång görs på data som ändrats.

2. Metod enligt patentkrav 1, k ä n n e t e c k n a d därav att när den nya databasen verifieras används ett speciellt SQL kommando SQL INSERT', vilket gör ett test, som undersöker om det endast finns en primärnyckel i varje tabell, varefter lås sätts för raden, vilket kommando även åstadkommer att raden senare kan läsas fast ett lås har satts på raden, och gör heller ingen inläggning av data i den nya databasen.

3. Metod enligt patentkrav 2, k ä n n e t e c k n a d därav att när den nya databasen verifieras använder ett special SQL kommando SQL FETCH' för att kunna läsa låsta data från låsta rader som kommandot SQL INSERT* har låst.

4. Metod enligt patentkrav 1, vilken metod omfattar en första del i vilken specifikationer ingår, k ä n n e t e c k n a d av att i den första delen även ingår* ett steg att ta frau1 och därefter läggs in i skriva konverteringsdirektiv (208), SOm konverteringstabeller och att metoden även omfattar en 10 15 20 25 30 35 509 645 22 andra (304) (306) del, (304) ingår följande steg: att konverteringsdirektiv läses in i och en tredje varvid i den andra delen ett operativsystem (210) från konverteringstabellerna (208), att data läses ut från en befintlig databas (202) till operativsystemet (210), att data konverteras i enlighet med specifikationerna och de konverteringsdirektiv som tidigare satts upp, och att konverterade data läggs in i den nya databasen (204), och att i den tredje delen (306) ingår ett databashanteringssystem (212) vilket utför kontroller av den nya verifiering av den nya databasen som sköts av databasens konsistens.

5. Metod enligt patentkrav 4, k ä n n e t e c k n a d därav att i den tredje delen (306) kontrolleras vilka ändringar som skett från den befintliga databasen (202) till den nya databasen (204), där en verifiering av primära nycklar, främmande nyckelsamband och värdeomfàng görs på data som ändrats.

6. Metod enligt patentkrav 4, k ä n n e t e c k n a d därav att (306) vilket gör ett test, i den tredje delen används ett speciellt SQL kommando SQL INSERTfl finns en primärnyckel i varje tabell, som undersöker om det endast varefter lås sätts för raden, vilket kommando även åstadkommer att raden senare kan läsas fast ett lås har satts på raden, och gör heller ingen inläggning av data i den nya databasen.

7. Metod enligt patentkrav 6, k ä n n e t e c k n a d därav att i den tredje delen (306) SQL FETCH' för att kunna läsa låsta data från låsta rader som kommandot SQL INSERT* har låst. använder ett special SQL kommando

8. Metod enligt patentkrav 1, vilken börjar med ett steg, en vilken specifikationer ingår, specificeringsfas i ingår: en (C), och en av att även följande steg (B), inläggningsfas (E) k ä n n e t e c k n a d (A), en inläsningsfas en utläsningsfas (D) , en deklarationsfas en konverteringsfas verifieringsfas (F), varvid deklarationsfasen (A) innebär att konverteringsdirektiv tas fram och skrivs för att därefter läggas in i konverteringstabeller (208), och varvid 10 15 20 25 509 645 23 inläsningsfasen (B) innebär att konverteringsdirektiv läses in i ett operativsystem (210) från konverteringstabellerna (208), och varvid utläsningsfasen (C) innebär att data läses ut från en befintlig databas (202) till operativsystemet (210), och varvid konverteringsfasen (D) innebär att data konverteras i enlighet med specifikationerna och de konverteringsdirektiv som tidigare upp, att konverterade data läggs in i den nya databasen (204), och varvid satts och varvid inläggningsfasen (E) innebär verifieringsfasen (F) sköts av ett databashanteringssystem (212) vilket utför kontroller av den nya databasens konsistens.

9. Metod enligt patentkrav 8, k ä n n e t e c k n a d därav att verifieringsfasen (F) innebär att de ändringar som skett fràn (202) (204) varvid görs en 'verifiering av ändrade data av den befintliga databasen till den nya databasen kontrolleras, primära nycklar, främmande nyckelsamband och värdeomfáng.

10. l0. Metod enligt patentkrav 8, k ä n n e t e c k n a d därav att ett SQL kommando som undersöker om det endast verifieringsfasen (F) använder SQL INsERI", finns en primärnyckel varje i tabell, speciellt vilket gör ett test, varefter lås sätts för raden, vilket kommandot även åstadkommer att raden senare kan läsas fast ett lås har satts pá raden, och gör heller ingen inläggning av data i den nya databasen.

11. Metod. enligt patentkrav 10, k ä n n e t e c k n a d därav att verifieringsfasen (E) SQL FETCH' för att kunna läsa lästa data från låsta rader som kommandot SQL INSERT* har låst. använder ett special SQL kommando