I föregående underavsnitt noterades att för en adekvat representation ämnesområde, enkel utveckling och underhåll av databas relationer bör föras till den tredje normal form(det finns former av normalisering och högre ordningar, men i praktiken används de ganska sällan), det vill säga att vara högst normaliserade. Samtidigt har svagt normaliserade relationer också sina fördelar, varav den främsta är att om databasen huvudsakligen endast nås med frågor, och ändringar och tillägg av data utförs mycket sällan, är deras sampling mycket snabbare. Detta förklaras av det faktum att i svagt normaliserade relationer har deras anslutning redan gjorts och processortid slösas inte bort på detta. Det finns två klasser av system för vilka starkt och svagt normaliserade relationer är mer lämpade.

Mycket normaliserade datamodeller är väl lämpade för OLTP-applikationer − Transaktionsbearbetning online (OLTP) – applikationer för onlinetransaktionsbearbetning. Typiska exempel OLTP-applikationer är system lagerbokföring͵ biljettorder, operativa banksystem och annat. Huvudfunktionen hos sådana system är att utföra stor kvantitet korta transaktioner. Transaktionerna i sig är ganska enkla, men problemen är att det finns många sådana transaktioner, de utförs samtidigt och om fel uppstår måste transaktionen rullas tillbaka och återställa systemet till det tillstånd det var i innan transaktionen började . Nästan alla databasfrågor i OLTP-applikationer består av kommandon infoga, uppdatera och ta bort. Urvalsfrågor är främst avsedda att ge användarna ett urval av data från olika typer av kataloger. De flesta av förfrågningarna är dock kända i förväg vid systemdesignstadiet. Avgörande för OLTP-applikationer är hastigheten och tillförlitligheten hos korta datauppdateringsoperationer. Ju högre nivå av datanormalisering i OLTP-applikationer, desto snabbare och mer tillförlitlig är den. Avvikelser från denna regel kan uppstå när man redan på utvecklingsstadiet känner till några frekvent förekommande förfrågningar som kräver anslutningsrelationer och driften av applikationer avsevärt beror på exekveringshastigheten för vilka.

En annan typ av applikation är OLAP-applikationer − On-Line analytisk bearbetning (OLAP) – operativa applikationer analytisk bearbetning data. Detta är en generaliserad term som kännetecknar principerna för att bygga beslutsstödssystem - Decision Support System (DSS), datalager - Data Warehouse, data mining system - Data Mining. Sådana system är designade för att hitta beroenden mellan data, för att utföra dynamisk analys baserad på "tänk om..."-principen och liknande uppgifter. OLAP-applikationer fungerar med stora mängder data som samlas på företaget eller hämtas från andra källor. Sådana system kännetecknas av följande egenskaper:

Ny data läggs till systemet relativt sällan i stora block, till exempel en gång i månaden eller kvartalet;

Data som läggs till systemet raderas vanligtvis aldrig;

Innan data laddas genomgår olika förberedande procedurer för att föra dem till vissa format;

Frågor till systemet är oreglerade och ganska komplexa;

Hastigheten för utförande av en fråga är viktig, men inte kritisk.

Baser OLAP-data-applikationer presenteras vanligtvis i form av en eller flera hyperkuber, vars dimensioner representerar referensdata, och själva hyperkubens celler lagrar värdena för dessa data. Fysiskt kan en hyperkub byggas på basis av en speciell multidimensionell datamodell - Flerdimensionell OLAP (MOLAP) eller representeras med hjälp av en relationsdatamodell - Relationell OLAP (ROLAP).

I OLAP-system använder relationsmodell data, är det tillrådligt att lagra data i form av svagt normaliserade relationer som innehåller förberäknade grundsummor. Dataredundans och relaterade problem är inte ett problem här, eftersom de uppdateras ganska sällan och tillsammans med datauppdateringen räknas resultaten om.

OLTP- och OLAP-system. Data Mining

Vissa klasser kan särskiljas informationssystem, för vilka starkt eller svagt normaliserade datamodeller är mer lämpade.

Högt normaliserade datamodeller lämpar sig väl för sk OLTP-system (Transaktionsbearbetning online - snabb transaktionsbearbetning).

Typiska exempel på OLTP-system är lagerbokföringssystem, biljettbeställningssystem, banksystem som utför pengaöverföringar, etc. Huvudfunktionen hos sådana system är att utföra ett stort antal korta transaktioner. Transaktionsmekanismen kommer att diskuteras i detalj i föreläsning 16, för att förstå principerna för driften OLTP-system Det räcker att tänka på en transaktion som en atomär handling som förändrar databasens tillstånd.

Transaktioner i OLTP - system är relativt enkla, till exempel "ta ut en summa pengar från konto A och lägg till det beloppet på konto B." Problemet är att det för det första är många transaktioner, för det andra exekveras de samtidigt (flera tusen samtidiga användare kan anslutas till systemet), för det tredje, om ett fel uppstår måste transaktionen rullas tillbaka helt och returnera systemet till den stat som var före transaktionens start (det bör inte finnas en situation där pengar togs ut från konto A, men inte kom till konto B).

Nästan alla databasfrågor i OLTP-applikationer består av kommandon infoga, uppdatera och ta bort. Utvalda frågor är i första hand utformade för att tillåta användare att välja mellan olika uppslagsböcker. De flesta av förfrågningarna är kända i förväg vid systemdesignstadiet. Därför är hastighet och tillförlitlighet för korta datauppdateringsoperationer avgörande för OLTP-applikationer.

Databasen som OLTP-applikationer arbetar med uppdateras ständigt, i samband med detta brukar den kallas operativ databas. Ju högre nivå av normalisering av den operativa databasen är, desto snabbare och mer tillförlitliga OLTP-applikationer fungerar. Avvikelser från denna regel kan uppstå när man redan på utvecklingsstadiet känner till några frekvent förekommande frågor som kräver anslutningsrelationer och vars exekveringshastighet avsevärt påverkar driften av applikationer. I det här fallet kan du medvetet införa viss redundans i databasen för att påskynda exekveringen av sådana frågor.

En annan typ av informationssystem är de sk OLAP-system (On-Line analytisk bearbetning - operationell analytisk databehandling). OLAP används för att acceptera ledningsbeslut, så system som använder OLAP-teknik, ringde beslutsstödssystem (Beslutsstödssystem - DSS).

Begreppet OLAP beskrevs 1993 av Edgar Codd, författaren till den relationella datamodellen.

År 1995, utifrån de krav som Codd ställde, den s.k FASMI (Fast Analysis of Shared Multidimensional Information) test - snabb analys delad flerdimensionell information), inklusive följande applikationskrav för multivariat analys:

· förse användaren med analysresultat inom en acceptabel tid (vanligen inte mer än 5 s), även till en kostnad av mindre detaljerad analys;

· förmågan att implementera alla logiska och Statistisk analys, kännetecknande för den här applikationen, och hålla den tillgänglig för slutanvändare form;

· Fleranvändaråtkomst till data med stöd för lämpliga låsmekanismer och auktoriserade åtkomstmedel;

multidimensionell konceptuell representation av data, inklusive fullt stöd för hierarkier och flera hierarkier (detta är nyckelkrav OLAP);

· möjligheten att kontakta vem som helst nödvändig information oavsett dess volym och lagringsplats.

OLAP-applikationer fungerar med stora mängder data som redan har samlats in operativa baser OLTP-systemdata hämtade från kalkylblad eller från andra datakällor. Sådana system kännetecknas av följande egenskaper:

· Ny data läggs till systemet relativt sällan i stora block (till exempel laddas data baserade på kvartalsförsäljningsresultat en gång i kvartalet ned från OLTP-systemet).

· Data som läggs till systemet tas vanligtvis aldrig bort eller ändras.

· Innan laddning genomgår data olika "rengöringsprocedurer" på grund av att ett system kan ta emot data från många källor som har olika format representationer och data kan vara felaktiga eller felaktiga.

· Förfrågningar till systemet är oreglerade och som regel ganska komplexa. Ofta ny förfrågan formulerad av analytikern för att förtydliga resultatet som erhållits som ett resultat av den föregående frågan.

· Frågeexekveringshastighet är viktig, men inte kritisk.

Baserat på de listade egenskaperna hos OLAP-system kan vi dra slutsatsen att databasen för ett sådant system till stor del kan denormaliseras. Eftersom huvudtypen av databasfrågor är utvalda frågor, kan de positiva aspekterna av normalisering inte användas, och det kommer att vara mycket användbart att minska kopplingsoperationerna i frågor.

I Nyligen Ett annat område för analytisk databehandling, kallad Data Mining (förståelse av data, ibland kallad "data mining"). Denna riktning syftar till att hitta dolda mönster i data och lösa prognosproblem. DataMining-applikationer ändrar inte heller data de arbetar med, så de föredrar en denormaliserad databas.

För att betona det speciella sättet att organisera data som effektivt kan användas för analys av OLAP- och Data Mining-applikationer, används en speciell term för den Datalager). Det är viktigt att notera att datalager, till skillnad från operativa databaser, lagrar historisk data, d.v.s. reflektera de fakta från företagets aktiviteter som redan har inträffat, därför kan de lagras oförändrade ("historien skrivs inte om") och ackumuleras under åren, och därför kan deras storlek bli mycket imponerande. Efter att data har överförts till lagring, tas de vanligtvis bort från driftdatabasen, vilket gör att dess storlek kan bibehållas inom specificerade gränser.

Inom området informationsteknologi finns det två ömsesidigt kompletterande områden:

Teknologier fokuserade på operationell (transaktionell) databehandling. Dessa teknologier ligger till grund för ekonomiska informationssystem utformade för snabb databehandling. Sådana system kallas - OLTP(transaktionsbearbetning online) system;

Teknologier fokuserade på dataanalys och beslutsfattande. Dessa teknologier ligger till grund för ekonomiska informationssystem utformade för att analysera

ackumulerade data. Sådana system kallas - OLAP

(uppkopplad analytisk bearbetning) system.

Huvudsyftet med OLAP-system- dynamisk flerdimensionell

analys av historiska och aktuella data, stabil över tid, analys

trender, modellering och framtidsprognoser. Sådan

system är som regel inriktade på att bearbeta godtyckliga,

förfrågningar som inte är reglerade i förväg. Som huvud

Egenskaperna hos dessa system kan noteras enligt följande:

Stöd för multidimensionell datarepresentation, jämlikhet av alla dimensioner, oberoende av prestanda från antalet dimensioner;

Transparens för användaren av strukturen, metoder för att lagra och bearbeta data;

Automatisk visning logisk struktur data till externa system;

Dynamisk bearbetning av glesa matriser på ett effektivt sätt.

Termen OLAP är relativt ny och tolkas ibland olika i olika litteraturkällor. Denna term identifieras ofta med beslutsstödssystem (DSS (Decision Support Systems) - beslutsstödssystem. Och som en synonym för den senare termen använder de Data Warehousing - datalager, vilket betyder en uppsättning organisatoriska lösningar, mjukvara och hårdvara för att tillhandahålla analytiker med information baserad på data från transaktionsbehandlingssystem lägre nivå och andra källor

"Datalager" låter dig bearbeta data som ackumulerats över långa perioder tid. Dessa data är heterogena (och inte nödvändigtvis strukturerade). Datalager kännetecknas av frågornas flerdimensionella karaktär. Enorma mängder data, komplexiteten i strukturen för både data och frågor kräver användning speciella metoder tillgång till information.

I andra källor anses begreppet beslutsstödssystem (DSS) vara bredare. Datalager och analytiska bearbetningsverktyg online kan fungera som en av komponenterna i DSS-arkitekturen.

OLAP inkluderar alltid interaktiv frågebehandling och efterföljande multipass-analys av information, vilket gör att vi kan identifiera olika, inte alltid uppenbara, trender som observeras inom ämnesområdet.

Ibland görs skillnad på "OLAP" i snäv mening" - det här är system som endast tillhandahåller ett urval av data i olika sektioner, och " OLAP i vid mening", eller helt enkelt OLAP, som inkluderar:

Stöd för flera användare som redigerar databasen.

Modelleringsfunktioner, inklusive beräkningsmekanismer för att erhålla härledda resultat, samt aggregering och kombination av data;

Prognoser, trender och statistisk analys.

Naturligtvis kräver var och en av dessa typer av informationssystem en specifik organisation av data, såväl som speciell programvara säkerställa ett effektivt genomförande av de aktuella uppgifterna.

OLAP - verktyg ger analys av affärsinformation enligt många parametrar, såsom typ av produkt, geografisk position köpare, transaktionstid och säljare, som var och en gör det möjligt att skapa en hierarki av vyer. För tid kan du alltså använda årliga, kvartalsvisa, månatliga och till och med veckovisa och dagliga intervaller; geografisk uppdelning kan vara efter stad, stat, region, land eller hela halvklotet om det behövs.

OLAP-system kan delas in i tre klasser.

De mest komplexa och dyra av dem är baserade på patenterad teknik flerdimensionella databasservrar. Dessa system tillhandahålla en fullständig cykel av OLAP-bearbetning och antingen inkluderar, förutom serverkomponenten, ett eget integrerat klientgränssnitt, eller används för dataanalys externa program arbeta med kalkylblad. Produkter av denna klass är mest lämpade för användning i stora informationslager. Deras underhåll kräver en hel personal med anställda som både installerar och underhåller systemet och skapar datavyer för slutanvändare. Vanligtvis är dessa paket ganska dyra. Exempel på produkter i denna klass inkluderar Essbase-systemet från Arbor Software, Express från IRI (nu en del av Oracle), Lightship från Pilot Software och andra.

Det bör noteras att ett av sätten att säkerställa snabb bearbetning data när man analyserar det är organisationen av data i form av multidimensionella databaser (MDD). Information i MDD lagras inte som indexerade poster i tabeller, utan i form av logiskt ordnade arrayer. Det finns ingen allmänt accepterad multidimensionell datalagringsmodell. MDD:er har ingen standardiserad metod för att komma åt data och kan uppfylla kraven för specifik analytisk databehandling.

Med hänsyn till allt ovanstående kan jämförelser mellan olika MDD-produkter endast göras i de mest allmänna kategorierna. I den billigare delen av marknaden finns det bara enanvändare och avsedda för små lokala nätverk flerdimensionell datavisare. Även om de har ganska hög nivå funktionalitet och användarvänlighet är dessa system begränsade i skala. och de saknar de verktyg som behövs för att implementera OLAP - bearbetning i vid mening. Produkter som faller inom denna kategori inkluderar Cognos PowerPlay, Andynes PaBlo och Business Objects Mercury. Den dyra sektorn på marknaden representeras av Acumate ES-systemen från Kenan Technologies, Express från Oracle Corporation, Gentium från Planning Sciences och Holos från Holistic Systems. De skiljer sig så mycket i sina förmågor att vilken som helst av dem säkert kan delas in i en separat kategori. Och slutligen, MDD-system i sin rena form: Essbase från Arbor Software, LightShip Server från Pilot Software och TM/1 från Sinper [N. Raden (Software Marketplace)].

Den andra klassen av OLAP-verktyg - relationella OLAP-system(ROLAP). Här används gamla relationella DBMS:er för att lagra data, och ett metadatalager som definieras av systemadministratören är organiserat mellan databasen och klientgränssnittet. Genom denna mellanprogramvara kan klientkomponenten interagera med relationsdatabasen som om den vore en flerdimensionell. Liksom förstklassiga verktyg är ROLAP-system väl lämpade för att arbeta med stora informationsarkiv, kräver betydande underhållskostnader av specialister från informationsavdelningar och kräver drift i fleranvändarläge. Produkter av denna typ inkluderar IQ Softwares IQ/Vision, MicroStrategys DSS/Server och DSS/Agent, och Information Advantages DecisionSuite.

ROLAP - verktyg implementerar beslutsstödsfunktioner i ett tillägg över relationsdatabasens processor.

Sådan mjukvaruprodukter måste uppfylla ett antal krav, särskilt:

Har en kraftfull OLAP-optimerad SQL-uttrycksgenerator som låter dig använda multi-pass SQL-satser SELECT och/eller korrelerade underfrågor;

Ha tillräckligt utvecklade medel för att utföra icke-trivial bearbetning som säkerställer rangordning, jämförande analys och beräkna procentsatser inom en klass;

Generera SQL-uttryck optimerade för målet relationell DBMS, inklusive stöd för tilläggen av detta språk som finns på det;

Tillhandahålla mekanismer för att beskriva datamodellen med hjälp av metadata och ge möjligheten att använda denna metadata för att skapa frågor i verklig skala tid;

Inkludera en mekanism för att utvärdera kvaliteten på konstruktionen pivottabeller ur beräkningshastighetssynpunkt, helst med ackumulering av statistik över deras användning.

För det tredje, jämförelsevis ny typ OLAP-verktyg - Desktop-fråge- och rapporteringsverktyg, kompletterad med OLAP-funktioner eller integrerad med med externa medel utföra sådana funktioner. Dessa mycket avancerade system hämtar data från råkällor, omvandlar dem och placerar dem i en dynamisk flerdimensionell databas som körs på slutanvändarens PC. Detta tillvägagångssätt, som gör det möjligt att klara sig utan både en dyr flerdimensionell databasserver och ett komplext mellanliggande metadatalager som krävs för ROLAP-verktyg, säkerställer samtidigt tillräcklig analyseffektivitet. Dessa skrivbordsverktyg är bäst lämpade för att arbeta med små, enkla databaser. Behovet av kvalificerat underhåll är lägre för dem än för andra OLAP-system och är ungefär lika med nivån för konventionella frågebehandlingsmiljöer. Nyckelaktörer inom denna marknadssektor inkluderar Brio Technology med sitt Brio Query Enterprise-system, Business Objects med sin produkt med samma namn och Cognos med PowerPlay.

För närvarande ökar antalet webbkompatibla OLAP-produkter.

En viktig fråga är att anpassa OLAP till annan programvara. Även om OLAP-leverantörer börjar erbjuda några sätt att samverka med SQL och andra verktyg, varnar användare och analytiker för att integrationsnivån kommer att variera och troligen kommer att kräva en betydande mängd kodning, inklusive att skriva frågor i SQL-språk. Dessutom för att integrera OLAP med resten programvara företag finns det ingen branschstandard.

Lösningen på detta problem kan vara följande. Till exempel positionerar många företag OLAP-databaser som kunddelar datalager. I detta tillvägagångssätt matar lager den flerdimensionella OLAP-motorn med dataprover som senare kan nås av användare för att snabbt köra komplexa frågor. Målet är att skapa en frågemiljö som döljer platsen för data från användaren. Denna miljö kommer automatiskt att köra komplexa frågor mot kärnan flerdimensionell bearbetning eller sök efter detaljerad information och enkla frågor på relationsservrar. För företag som inte kan gå den här vägen, viktig roll Konsultföretag spelar en roll i att skapa kopplingar mellan OLAP-verktyg och annan programvara.

OLTP-system, som är ett mycket effektivt sätt att implementera operativ bearbetning, visade sig vara till liten användning för analytiska bearbetningsuppgifter. Detta orsakas av följande:

1. Med hjälp av traditionella OLTP-system kan du bygga en analytisk rapport och till och med en prognos av vilken komplexitet som helst, men reglerad i förväg. Varje steg åt sidan, alla oreglerade krav från slutanvändaren kräver som regel kunskap om datastrukturen och en ganska hög kvalifikation av programmeraren;

2. många nödvändiga för operativsystem funktionalitetär överflödiga för analytiska uppgifter och kanske samtidigt inte speglar ämnesområdet. Att lösa de flesta analytiska problem kräver användning av externa specialiserade verktyg för analys, prognoser och modellering. Den stela strukturen i databaserna tillåter inte att uppnå acceptabel prestanda vid komplexa urval och sorteringar och kräver därför mycket tid för att organisera gateways.

3. till skillnad från transaktioner, i analytiska system Utvecklade metoder för att säkerställa dataintegritet, säkerhetskopiering och återställning krävs inte och tillhandahålls därför inte. Detta gör det inte bara möjligt att förenkla själva implementeringsverktygen, utan också att minska intern overhead och därför förbättra prestandan vid hämtning av data.

Omfattningen av uppgifter som effektivt löses av vart och ett av systemen kommer att bestämmas baserat på jämförande egenskaper OLTP- och OLAP-system (tabell 8).

Det är möjligt att identifiera vissa klasser av system för vilka starkt eller svagt normaliserade datamodeller är mer lämpade.

Högt normaliserade datamodeller lämpar sig väl för sk OLTP-applikationer(Transaktionsbearbetning online (OLTP)-snabb transaktionsbearbetning ). Typiska exempel på OLTP-applikationer är lagerbokföringssystem, biljettbeställningssystem, banksystem som utför penningöverföringsoperationer, etc.

Huvudfunktionen hos sådana system är att utföra ett stort antal korta transaktioner. Transaktionerna i sig ser relativt enkla ut, till exempel "ta ut en summa pengar från konto A, lägg till detta belopp på konto B."

Problemet är att det för det första är många transaktioner, för det andra exekveras de samtidigt (flera tusen samtidiga användare kan anslutas till systemet), för det tredje, om ett fel uppstår måste transaktionen rullas tillbaka helt och returnera systemet till den stat som var före transaktionens start (det bör inte finnas en situation där pengar togs ut från konto A, men inte kom till konto B). Nästan alla databasfrågor i OLTP-applikationer består av kommandon infoga, uppdatera och ta bort. Därför är hastighet och tillförlitlighet för korta datauppdateringsoperationer avgörande för OLTP-applikationer. Ju högre nivå av datanormalisering i en OLTP-applikation, desto snabbare och mer tillförlitlig brukar den vara.

En annan typ av applikation är den sk OLAP-applikationer(On-Line analytisk bearbetning(OLAP) -operationell analytisk databehandling ). Detta är en generaliserad term som kännetecknar konstruktionsprinciperna beslutsstödssystem (Beslutsstödssystem-DSS),datalager(Datalager),datautvinningssystem (Data Mining). Sådana system är utformade för att hitta beroenden mellan data (du kan till exempel försöka bestämma hur försäljningsvolymen av varor är relaterad till egenskaperna potentiella köpare), för att utföra en "tänk om..."-analys.

OLAP-applikationer fungerar på stora mängder data som redan samlats i OLTP-applikationer, hämtade från kalkylblad eller andra datakällor. Sådana system kännetecknas av följande egenskaper:

Nya data läggs till systemet relativt sällan i stora block (till exempel en gång i kvartalet laddas data baserade på resultatet av kvartalsförsäljningen ned från en OLTP-applikation).

Data som läggs till systemet raderas vanligtvis aldrig.

Innan laddningen genomgår informationen olika ”rengöringsprocedurer”, på grund av att ett system kan ta emot data från många källor som har olika presentationsformat för samma koncept.

Förfrågningar till systemet är oreglerade och som regel ganska komplexa.

Hastigheten för utförande av en fråga är viktig, men inte kritisk.

Data från OLAP-applikationer representeras vanligtvis som en eller flera hyperkuber, vars dimensioner är referensdata, och cellerna i själva hyperkuben lagrar själva data. Till exempel kan du bygga en hyperkub, vars dimensioner är: tid (i kvartal, år), typ av produkt och företagsgrenar, och cellerna lagrar försäljningsvolymer. En sådan hyperkub kommer att innehålla försäljningsdata olika typer varor efter kvartal och divisioner. Baserat på dessa data kan du svara på frågor som "vilken division har de bästa försäljningsvolymerna i år?", eller "hur är försäljningstrenderna för divisionerna i sydvästra regionen i år jämfört med föregående år?"

För att återgå till problemet med datanormalisering kan vi säga att i OLAP-system som använder den relationella datamodellen (ROLAP) är det tillrådligt att lagra data i form av svagt normaliserade relationer som innehåller förberäknade grundsummor. Stor redundans och problemen i samband med det är inte skrämmande här, eftersom uppdateringen sker endast när en ny del av data laddas. I det här fallet läggs både nya data till och resultaten räknas om.

• < Назад
• Framåt >

OLTP och OLAP-system I föregående underavsnitt noterades att för en adekvat representation av ämnesområdet, enkel utveckling och underhåll av databasen måste relationerna reduceras till den tredje normala formen (det finns former av normalisering av högre ordningar, men i praktiken de används ganska sällan), det vill säga de måste vara mycket normaliserade. Men svagt normaliserade relationer har också sina fördelar, varav den främsta är att om databasen huvudsakligen endast nås med förfrågningar, och ändringar och tillägg av data utförs mycket sällan, går deras sampling mycket snabbare. Detta förklaras av det faktum att i svagt normaliserade relationer har deras anslutning redan gjorts och processortid slösas inte bort på detta. Det finns två klasser av system för vilka starkt och svagt normaliserade relationer är mer lämpade. Mycket normaliserade datamodeller är väl lämpade för OLTP-applikationer - On-Line Transaction Processing (OLTP) - applikationer för onlinetransaktionsbehandling. Typiska exempel på OLTP-applikationer är lagerbokföringssystem, biljettbeställningssystem, operativa banksystem och andra. Huvudfunktionen hos sådana system är att utföra ett stort antal korta transaktioner. Transaktionerna i sig är ganska enkla, men problemen är att det finns många sådana transaktioner, de utförs samtidigt och om fel uppstår måste transaktionen rullas tillbaka och återställa systemet till det tillstånd det var i innan transaktionen började . Nästan alla databasfrågor i OLTP-applikationer består av kommandon infoga, uppdatera och ta bort. Urvalsfrågor är främst avsedda att ge användarna ett urval av data från olika typer av kataloger. Således är de flesta av förfrågningarna kända i förväg vid systemdesignstadiet. Avgörande för OLTP-applikationer är hastigheten och tillförlitligheten hos korta datauppdateringsoperationer. Ju högre nivå av datanormalisering i OLTP-applikationer, desto snabbare och mer tillförlitlig är den. Avvikelser från denna regel kan uppstå när man redan på utvecklingsstadiet känner till några frekvent förekommande frågor som kräver anslutningsrelationer och vars exekveringshastighet avsevärt påverkar driften av applikationer. En annan typ av applikation är OLAP-applikationer - On-Line Analytical Processing (OLAP) - applikationer för operationell analytisk databehandling. Detta är en generaliserad term som kännetecknar principerna för att bygga beslutsstödssystem - Decision Support System (DSS), datalager - Data Warehouse, data mining system - Data Mining. Sådana system är designade för att hitta beroenden mellan data, för att utföra dynamisk analys baserad på "tänk om..."-principen och liknande uppgifter. OLAP-applikationer fungerar med stora mängder data som samlas på företaget eller hämtas från andra källor. Sådana system kännetecknas av följande egenskaper: * att lägga till nya data till systemet sker relativt sällan i stora block, till exempel en gång i månaden eller kvartalet; * data som läggs till systemet raderas som regel aldrig; * före laddning genomgår data olika förberedande procedurer för att föra dem till vissa format och liknande; * förfrågningar till systemet är oreglerade och ganska komplexa; * Hastigheten för exekvering av frågor är viktig, men inte kritisk. OLAP-applikationsdatabaser representeras vanligtvis som en eller flera hyperkuber, vars dimensioner representerar referensdata, och cellerna i själva hyperkuben lagrar värdena för dessa data. Fysiskt kan en hyperkub byggas på basis av en speciell multidimensionell datamodell - Multidimensional OLAP (MOLAP) eller representeras med hjälp av en relationsdatamodell - Relational OLAP (ROLAP). I OLAP-system som använder en relationsdatamodell är det användbart att lagra data i form av svagt normaliserade relationer som innehåller förberäknade grundsummor. Dataredundans och relaterade problem är inte ett problem här, eftersom de uppdateras ganska sällan och tillsammans med datauppdateringen räknas resultaten om. Egenskaperna och omfånget av uppgifter som effektivt löses av varje teknik illustreras av följande jämförande tabell: KarakteristiskOLTPOLAPPSyfte med systemetRegistrering, operativ sökning och transaktionsbearbetning, reglerad analys Arbeta med historiska data, analytisk bearbetning, prognoser, modellering Lagrade data Operationell, detaljerad Täcker en lång tidsperiod, aggregerad Datatyp Strukturerad Olika "Ålder" av data Aktuell (flera månader) Historisk (under åren) och prognostiserad Datauppdateringsfrekvens Hög, i små "portioner" Liten, i stora "bitar" Dataaggregationsnivå Detaljerade data Huvudsakligen - aggregerade data Övervägande operationer Datainmatning, sökning, uppdatering Dataanalys Metod för dataanvändning Förutsägbar Oförutsägbar Interaktion med användaren Kl. transaktionsnivån På nivån för hela databasen Typ av aktivitet Operativ, taktisk Analytisk, strategisk Prioriteringar Hög produktivitet Hög tillgänglighet Flexibilitet Användarautonomi Kategori av användare Stort antal ledande anställda Relativt litet antal anställda ledningsnivå Jämförelse av OLTP och OLAP Egenskaper för OLTP OLAP Typ av frågor Många enkla transaktioner Komplexa transaktioner Lagrade data Operationell, detaljerad Täcker en lång tidsperiod, aggregerad Typ av aktivitet Operationell, taktisk Analytisk, strategisk Typ av data Strukturerad Olika Systemegenskaper Redovisningssystem (OLTP) OLAP Interaktion med användaren Kl. transaktionsnivån På nivån för hela databasen Data , används när en användare kommer åt systemetEnskilda posterGrupper av posterSvarstidSekunderFlera sekunder till flera minuterAnvändning av hårdvaruresurserStableDynamicNatur av data Mestadels primär (lägsta detaljnivå)Mestadels härledd (aggregerade värden)Natur av databasåtkomstFördefinierad eller statiska åtkomstvägar och datarelationer Odefinierade eller dynamiska vägar åtkomst och datarelationer Datavariabilitet Hög (data uppdateras med varje transaktion) Låg (data uppdateras sällan under en förfrågan) Prioriteter Hög prestanda Hög tillgänglighet Flexibilitet Användarautonomi