Hvad er OLTP og OLAP. Hvad er forskellen mellem dem? Informationsteknologi i en økonoms professionelle aktivitet: Gennemgang af IT designet til operationel og analytisk databehandling

Mode operationel behandling transaktioner OLTP(On-Line Transaction Processing) bruges i organisatoriske ledelsesinformationssystemer til at reflektere nuværende tilstand emneområde til enhver tid, og batchbehandling indtager en meget begrænset niche.

OLTP

Typisk er de analytiske muligheder for OLTP-systemer meget begrænsede, de bruges til at lette virksomhedens daglige aktiviteter og er baseret på data, der er relevante for øjeblikket. OLTP-klasseinformationssystemer er designet til at indsamle, registrere, indtaste kildedata relateret til et bestemt emneområde, primær databehandling, lagring, tilstrækkelig visualisering, søgning, udstedelse af certifikater og rapporteringsmateriale. Primær behandling omfatter kontrol af korrektheden af inputdata og deres overensstemmelse med integritetsbegrænsninger, identifikation af objekterne beskrevet af dataene, kodning og transmission af data gennem horisontale og vertikale forbindelser. Data indtastes i informationssystemet enten fra et dokument, der har en vis retskraft, eller direkte fra det sted, hvor dataene stammer fra. I sidstnævnte tilfælde udskrives dokumentet, der indeholder de indtastede data, af systemet og får retskraft.

I OLTP-systemer udføres måltransaktioner på måldatabaser (f.eks. indtastning af en post i en tabel med parametrene for en udstedt faktura, en bogført faktura eller enhver anden kendsgerning), som ændrer databasens tilstand og bringer dem ind i overholdelse nuværende tilstand det fragment af den virkelige verden, som databasen modellerer. Således er hovedformålet med måldatabaser transaktionsbehandling.

Sådanne systemer er designet til input, struktureret lagring og behandling af information i realtid. OLTP-systemer giver dig mulighed for at formulere forespørgsler som: hvor meget, hvor osv. Ved at levere data fra konstant synkroniserede (opdaterede) databaser sporer operativsystemer ikke dynamikken i ændringer i processer over store tidsperioder, behandler praktisk talt ikke dataene (bortset fra visse beregninger) og, vigtigst af alt, danner de ikke konklusioner baseret på tilgængelige data, og overlader denne funktion til den person, der træffer beslutningen.

Disse analysesystemer er distribueret som selvstændige software produkter, beregnet til analytisk behandling af ledelsesinformation, udarbejdelse af analytisk rapportering, undersøgelse og analyse af beslutninger. De mest udviklede af disse systemer har midler til informationsudveksling med eksterne baser data og kan bruges som analytiske moduler i et virksomhedsledelsessystem. OLTP applikationer dækker en bred vifte af opgaver i mange brancher - automatisering af regnskab og lagerregnskab og bogføring af dokumenter mv.

Hovedfunktionen af sådanne systemer er samtidig at udføre et stort antal korte transaktioner fra et stort antal brugere. Selve transaktionerne ser relativt enkle ud, for eksempel "træk et beløb fra konto A, tilføj dette beløb til konto B."

OLTP-klasseinformationssystemer er kendetegnet ved følgende funktioner.

Karakteristika for IS - informationssystemer - OLTP-klasse

relativ algoritmisk enkelhed,
øget dynamik med hensyn til nomenklaturen og strukturen af behandlede dokumenter, som er forbundet med disse systemers tætte nærhed til emneområdet,
masse og territorial fordeling af steder, hvor de første data blev indsamlet,
høje krav til pålideligheden og relevansen af de indtastede data,
massivitet, ret hyppig omsætning og relativt lave computerkvalifikationer hos personalet (brugerne).
støtte til et stort antal brugere;
kort responstid på anmodninger;
relativt korte forespørgsler;
deltage i forespørgsler på et lille antal borde.

Historisk set er sådanne systemer primært opstået, fordi de opfyldte behovene for regnskab, servicehastighed, dataindsamling osv. Det blev dog hurtigt klart, at dataindsamling ikke er et mål i sig selv, og de akkumulerede data kan være nyttige: information kan udtrækkes fra dataene.

Systemudviklingsstrategi

I lang tid blev følgende strategi brugt til at udvikle sådanne systemer:

konstruktion af separate arbejdsstationer beregnet til behandling af grupper af funktionelt relaterede dokumenter og replikering af færdige arbejdsstationer på stedet,
opbygning af parametriserbare systemer med alle funktioner med replikering og lokal tilpasning. Systemerne opnået på denne måde havde imidlertid lave tilpasningsevner til at overvinde dynamikken i fagområder. De stillede høje krav til driftspersonalet og krævede store vedligeholdelsesomkostninger.

Relativt for nylig begyndte en ny, tredje strategi til udvikling af informationssystemer af OLTP-klassen at blive brugt. Dens essens er som følger: ikke færdiglavede systemer replikeres, men nogle blanks og teknologiske værktøjer, der giver dig mulighed for hurtigt at bygge/fuldføre et system med den nødvendige funktionalitet direkte på stedet og derefter ved hjælp af det samme værktøj ændre det iht. dynamikken i fagområdet

Online databehandlingssystem (ON LINE TRANSAKTIONSBEHANDLING) OLTP er designet til relativt hurtig service simple forespørgsler et stort antal brugere. Disse systemer kræver beskyttelse mod uautoriseret adgang, dataintegritet og hardware- og programmeringsfejl.

De er kendetegnet ved lave ventetider på anmodninger, der skal udfyldes.

Anvendelsesområde: betalinger, regnskab, reservationer, banker og børsdrift

Transaktion- dette er en fuldført handling på databasen fra brugerens synspunkt.

Analytiske databehandlingssystemer (ON LINE ANALIZIS PROCESSING) OLAP er beslutningsstøttesystemer fokuseret på at yde mere komplekse forespørgsler, der kræver statistisk behandling af historiske data akkumuleret over en vis periode. Analytiske systemer omfatter:

1. Informationsbehandlingsværktøjer baseret på metoder kunstig intelligens

2. betyder grafisk fremstilling data.

Disse systemer er bestemt af en stor mængde historiske data, hvilket gør det muligt at udtrække meningsfuld information fra dem, dvs. få viden fra data.

Krav til analysehastighed og kvalitet førte til fremkomsten af analytiske behandlingssystemer (OLAP). Behandlingseffektivitet opnås gennem brug af kraftfuld multiprocessorteknologi, komplekse analysemetoder og specialiserede datavarehuse.

De givne klasser af systemer (OLAP og OLTP), de er baseret på brugen af et DBMS, men typerne af forespørgsler er meget forskellige.

Transaktionsbehandling i OLTP-systemer

Transaktion - en udelelig sekvens af datamanipulationsoperationer ud fra perspektivet om at påvirke databasen. Dette kan være en læsning, sletning, indsættelse osv. handling.

Transaktionen implementerer en handling, der er meningsfuld fra brugerens synspunkt, for eksempel at overføre penge fra en konto, reservere en plads, levere en ny medarbejder.

En transaktion skal have 4 grundlæggende egenskaber:

1. atomicitet, transaktionen skal udføres som en enkelt databaseadgangsoperation, den skal fuldføres fuldstændigt eller slet ikke udføres.

2. konsistens, garanterer gensidig dataintegritet.

3. isolation, vil transaktioner blive udført isoleret på brugersystemet.

4. holdbarhed, hvis transaktionen gennemføres med succes, vil de ændringer, den foretager til dataene, under ingen omstændigheder gå tabt.

Resultatet af en transaktion kan være dens fiksering Og tilbagerulning

Fiksering - Dette er en handling, der sikrer, at alle ændringer registreres i databasen.

Rul tilbage- hvis normal gennemførelse af transaktionen ikke er mulig, vender databasen tilbage til den oprindelige tilstand, annulleres alle ændringer.

Når du ruller tilbage og begår en transaktion, bruges den transaktionslog, hvor alle ændringer gemmes.

Når du udfører en operation, der ændrer databasen, gemmer DBMS automatisk tilstandene for de ændrede rækker før og efter operationen i transaktionsloggen. Først herefter foretages ændringer i databasen.

Når der rulles tilbage, bruger DBMS transaktionsloggen til at gendanne de rækker, der blev ændret.

Transaktionsgrænser- Dette er den første og sidste operation, der er inkluderet i den. Det antages, at transaktionen begynder med den 1. SQL-sætning, følgende sætninger udgør kroppen af transaktionen, og kroppen kan forgrene sig:

1. SQL-sætning begå arbejde

SQL rollback operatør

2. ved blot at udfylde den erklæring, der kaldte transaktionen.

Gem point- bruges i lange transaktioner, dvs. transaktionens brødtekst kan definere punkter, hvor databasens tilstand gemmes.

Brug af en transaktion er en effektiv mekanisme til at organisere flerbrugeradgang til en database.

Problemer:

1. hvordan man undgår at miste ændringer til databasen i en situation, hvor flere programmer læser de samme data, ændrer dem og skriver dem til gammelt sted. Ændringer fra et program kan gemmes i databasen, resultaterne af alle andre vil gå tabt.

2. udelukke muligheden for at læse ukommitterede ændringer, f.eks. når en transaktion foretager ændringer i databasen, læses de straks i andre transaktioner, men så afbrydes en anden transaktion af rollback-operatøren.

For at eliminere dette, brug serialisering (fælles behandling):

1. transaktion kan ikke få adgang til uforpligtende data

2. Resultatet af fælles udførelse af transaktioner skal svare til resultatet af deres udførelsesrækkefølge.

I moderne DBMS transaktionsserialisering implementeres gennem låsemekanisme: Under udførelsen af transaktion 1 blokerer DBMS den del af databasen, som transaktion 1 tilgår. Låsen opretholdes, indtil transaktion 1 forpligtes; hvis en anden transaktion 2 på dette tidspunkt får adgang til de låste data, suspenderes transaktion 2, indtil transaktion 1 er gennemført.

Transaktions dødvande

Lad transaktion t1 opdatere relation - o1. Dernæst forsøger denne transaktion t1 at modificere relationen o2, som tidligere var blokeret af transaktionen t2. Transaktion t1 overføres til ventetilstand, indtil låsen på relation o2 udløses; i samme øjeblik forsøger transaktion t2 at ændre dataene for relation o1, som tidligere var blokeret af transaktion t1. DBMS'et er tvunget til at sætte transaktion T2 i ventetilstand; derfor opstår en transaktions-deadlock-situation.

DBMS tjekker med jævne mellemrum låsen, og hvis der er deadlocks, bliver en af transaktionerne tvangsafbrudt.

Disaster Recovery Tools

Et af hovedkravene til moderne informationssystemer er pålideligheden af datalagring. DBMS'et skal være i stand til at gendanne databasen efter hardware- eller softwarefejl. Der er en transaktionslog til dette. Gendannelsesprincippet - resultaterne af transaktionen før fejlen skal genoprettes, de resultater, der ikke er begået af transaktionen, skal slettes.

Hvis indholdet er fysisk ødelagt ekstern hukommelse, så for at eliminere dette implementeres duplikatdatalagring.

Fejl
OLTP-systemer er optimeret til små, diskrete transaktioner. Men anmodninger om nogle komplekse oplysninger (f.eks. kvartalsvise dynamik af salgsmængder for en bestemt produktmodel i en bestemt branche), typisk for analytiske applikationer(OLAP), vil generere komplekse tabelsammenføjninger og visning af hele tabeller. En sådan anmodning vil tage meget tid og computerressourcer, hvilket vil bremse behandlingen af igangværende transaktioner.

Transaktion er en gruppe af sekventielle operationer, der repræsenterer en logisk enhed for arbejde med data. En transaktion kan udføres enten helt og med succes, ved at bevare dataintegriteten og uafhængigt af andre transaktioner, der kører parallelt, eller den kan slet ikke udføres, og så burde den ikke have nogen effekt. Transaktioner behandles af transaktionssystemer, under driften af hvilke der oprettes en transaktionshistorik.

Der er sekventielle (regulære), parallelle og distribuerede transaktioner. Distribuerede transaktioner involverer brugen af mere end ét transaktionssystem og kræver meget mere kompleks logik (for eksempel to-faset commit - en to-faset transaktion commit protokol). Nogle systemer implementerer også autonome transaktioner eller deltransaktioner, som er en autonom del af modertransaktionen.

Eksempel: Det er nødvendigt at overføre et beløb på 10 pengeenheder fra bankkonto nummer 5 til konto nummer 7. Dette kan for eksempel opnås ved følgende rækkefølge af handlinger:
Start transaktion
aflæs saldoen på konto nr. 5
reducere saldoen med 10 monetære enheder
gem den nye kontosaldo nummer 5
aflæs saldoen på kontonummer 7
øge saldoen med 10 monetære enheder
gem den nye saldo på kontonummer 7

Afslut transaktion
Disse handlinger repræsenterer en logisk arbejdsenhed "at overføre et beløb mellem konti", og udgør således en transaktion. Hvis du afbryder en given transaktion for eksempel på midten og ikke annullerer alle ændringer, er det nemt at lade ejeren af kontonummer 5 stå uden 10 enheder, mens ejeren af kontonummer 7 ikke modtager dem.

Online transaktionsbehandlingstilstand OLTP

OLTP-tilstanden (On-Line Transaction Processing) til online transaktionsbehandling bruges i organisatoriske ledelsesinformationssystemer til at afspejle den aktuelle tilstand af emneområdet til enhver tid, og batchbehandling optager en meget begrænset niche.
OLTP

I OLTP-systemer udføres måltransaktioner på måldatabaser (f.eks. indtastning af en post i en tabel med parametrene for en udstedt faktura, en bogført faktura eller enhver anden kendsgerning), som ændrer databasens tilstand og bringer dem ind i linje med den aktuelle tilstand af fragmentet af den virkelige verden, der modellerer databasen. Således er hovedformålet med måldatabaser transaktionsbehandling.

OLTP-ansøgninger dækker en bred vifte af opgaver indenfor mange brancher - automatisering af regnskab og lagerregnskab og bilagsregnskab mv.

Informationssystemer OLTP-klassen er kendetegnet ved følgende funktioner.
Karakteristika for IS - informationssystemer - OLTP-klasse
- relativ algoritmisk enkelhed,
- øget dynamik med hensyn til nomenklaturen og strukturen af behandlede dokumenter, som er forbundet med disse systemers tætte nærhed til emneområdet,
- masse og territorial fordeling af steder til indsamling af indledende data,
- høje krav til pålideligheden og relevansen af de indtastede data,
- massiv skala, ret hyppig omsætning og relativt lav computer - kvalifikationer hos personalet (brugerne).
- støtte til et stort antal brugere;
-kort responstid på anmodninger;
-relativt korte forespørgsler;
-deltagelse i forespørgsler på et lille antal borde.

Historisk set sådanne systemer opstod primært, fordi de opfyldte behovene for regnskab, servicehastighed, dataindsamling osv. Det blev dog hurtigt klart, at dataindsamling ikke er et mål i sig selv, og de akkumulerede data kan være nyttige: information kan udtrækkes fra data.
Systemudviklingsstrategi
I lang tid blev følgende strategi brugt til at udvikle sådanne systemer:
konstruktion af separate arbejdsstationer beregnet til behandling af grupper af funktionelt relaterede dokumenter og replikering af færdige arbejdsstationer på stedet,
opbygning af parametriserbare systemer med alle funktioner med replikering og lokal tilpasning. Systemerne opnået på denne måde havde imidlertid lave tilpasningsevner til at overvinde dynamikken i fagområder. De stillede høje krav til driftspersonalet og krævede store vedligeholdelsesomkostninger.
Relativt for nylig begyndte en ny, tredje strategi til udvikling af informationssystemer af OLTP-klassen at blive brugt. Dens essens er som følger: ikke færdiglavede systemer replikeres, men nogle blanks og teknologiske værktøjer, der giver dig mulighed for hurtigt at bygge/fuldføre et system med den nødvendige funktionalitet direkte på stedet og derefter ved hjælp af det samme værktøj ændre det iht. dynamikken i fagområdet.

Transaktioner er handlinger, der enten udføres fuldstændigt eller slet ikke udføres. Hvis der opstår en systemafbrydelse under en transaktion, returneres databasen til sin oprindelige tilstand før transaktionen (rollback). Alle gennemførte transaktioner registreres i transaktionsloggen. En transaktion anses for afsluttet, når en tilsvarende transaktionspostering vises i kladden.

OLTP teknologier

I praksis med at kommunikere med repræsentanter for støder man ofte på en alvorlig misforståelse af forskellene i kapaciteten, formålet og rollen af teknologier designet til at indsamle information - OLTP-systemer (On-Line Transaction Processing) og informationsanalyseteknologier. I mellemtiden er de væsentligt forskellige i funktionalitet, og hver af dem er ansvarlige for sit eget område i informationssystemet.
OLTP-systemopgaver– er den hurtige indsamling og mest optimale placering af information i databasen, samt at sikre dens fuldstændighed, relevans og konsistens. Sådanne systemer er dog ikke designet til den mest effektive, hurtige og multidimensionelle analyse.
Det er selvfølgelig muligt at bygge rapporter baseret på de indsamlede data, men det kræver, at forretningsanalytikeren enten konstant interagerer med en it-specialist, eller har en særlig uddannelse i programmering og computerteknologi.
Hvordan ser den traditionelle beslutningsproces ud i en russisk virksomhed, der bruger et informationssystem bygget på OLTP-teknologi?
Lederen giver opgaven til informationsafdelingens specialist i overensstemmelse med hans forståelse af problemstillingen. Informationsafdelingens specialist, der har forstået opgaven på sin egen måde, bygger en anmodning til det operationelle system, modtager en elektronisk rapport og bringer den til lederens opmærksomhed. Denne ordning til at træffe kritiske beslutninger har følgende væsentlige ulemper:
-en ubetydelig mængde data bruges;
-processen tager lang tid, da udarbejdelse af anmodninger og fortolkning af en elektronisk rapport er ret kedelige operationer, mens lederen muligvis skal træffe en beslutning med det samme;
-gentagelse af cyklussen er påkrævet, hvis det er nødvendigt at præcisere dataene eller overveje dataene i en anden sammenhæng, samt hvis der opstår yderligere spørgsmål. Desuden skal denne langsomme cyklus gentages og som regel flere gange, mens der bruges endnu mere tid på dataanalyse;
Forskellen i faglig uddannelse og aktivitetsområder for en informationsteknologispecialist og en leder har en negativ indvirkning. Ofte tænker de i forskellige kategorier og forstår som følge heraf ikke hinanden;
en ugunstig effekt udøves af en faktor som kompleksiteten af elektroniske rapporter til perception. Lederen har ikke tid til at vælge antallet af interesse fra rapporten, især da der kan være for mange af dem. Det er klart, at arbejdet med at udarbejde data oftest falder på specialister i informationsafdelinger. Som et resultat bliver en kompetent specialist distraheret af rutinemæssigt og ineffektivt arbejde med at kompilere tabeller, diagrammer osv., hvilket naturligvis ikke bidrager til at forbedre hans færdigheder.
Der er kun én vej ud af denne situation, og den blev formuleret af Bill Gates i form af udtrykket: "Information lige ved hånden." Indledende information skal være tilgængelig for dens direkte forbruger - analytikeren. Den er direkte tilgængelig (!). Og opgaven for informationsafdelingens medarbejdere er at skabe et system til at indsamle, akkumulere, opbevare, beskytte information og sikre dens tilgængelighed for analytikere.

Anvendelsesområdet er sfæren for betalinger, regnskaber, reservationer, banker og børsoperationer.

OLTP systemer, som er et yderst effektivt middel til at implementere operationel behandling, viste sig at være af ringe nytte til analytiske behandlingsopgaver. Dette er forårsaget af følgende:
1. Ved hjælp af traditionelle OLTP-systemer kan du opbygge en analytisk rapport og endda en prognose for enhver kompleksitet, men reguleret på forhånd. Ethvert skridt til side, ethvert ureguleret krav slutbruger, som regel kræver viden om datastruktur og en ret høj kvalifikation af programmøren;
2. mange nødvendige for operativsystemer funktionalitet er overflødig til analytiske opgaver og afspejler muligvis ikke fagområdet. Løsning af de fleste analytiske problemer kræver brug af eksterne specialiserede værktøjer til analyse, prognoser og modellering. Den stive struktur af databaserne gør det ikke muligt at opnå acceptabel ydeevne i tilfælde af komplekse udvælgelser og sorteringer, og det kræver derfor meget tid at organisere gateways.
3. I modsætning til transaktionssystemer kræver analysesystemer ikke og giver derfor ikke udviklede midler til at sikre dataintegritet, sikkerhedskopiering og gendannelse. Dette gør det ikke kun muligt at forenkle selve implementeringsværktøjerne, men også at reducere intern overhead og dermed forbedre ydeevnen ved hentning af data.

Den række af opgaver, der effektivt løses af hvert af systemerne, vil blive bestemt ud fra sammenlignende egenskaber OLTP- og OLAP-systemer

Data i OLTP-systemer er primært organiseret for at understøtte transaktioner som:

registrering af en ordre indtastet fra et kasseapparat eller via et websted;

afgive en ordre på komponenter, når deres mængde på lageret bliver mindre end et vist antal;

sporing af komponenter under samling af det endelige produkt i produktionen;

registrering af oplysninger om medarbejdere;

Registrering af identiteten på licensindehavere, såsom restaurantejere eller chauffører.

Individuelle transaktioner med adgang til en relativt lille mængde data gennemføres hurtigt. OLTP-systemer er designet og optimeret til at behandle hundredvis eller tusindvis af transaktioner samtidigt.

OLTP-systemer udmærker sig ved at fange de data, der er nødvendige for at understøtte den daglige drift. Dataene i dem er dog organiseret anderledes end nødvendigt, når oplysningerne er beregnet til, at ledere kan planlægge arbejdet i deres organisationer. Ledere har ofte brug for sammenfattende oplysninger for at analysere tendenser, der påvirker deres organisation eller gruppe.

Moderne data warehousing udfordringer
Deling af data til specifikke formål

Udviklingen af Data Warehouse-teknologi begyndte med behovet for at adskille data, der bruges til operationer, og data, der bruges til analytiske formål. Depotet giver funktioner, der er bedst egnede til rapportering. Derudover sikrer adskillelse af transaktions- og rapporteringsbrugere, hvis ad hoc-forespørgsler kan påvirke effektiviteten af operationelle systemer negativt, optimal brug af datainfrastrukturressourcer.
Tidsværdi af data

Og mens Warehouses giver en organisation en fantastisk rapporterings- og analyseplatform, kommer den typisk til kort i realtid baseret på alderen på de tilgængelige data. På grund af teknologiske begrænsninger genopfyldes lager normalt om natten ved hjælp af pakkedataoverførsler. For at gøre dette bruges et batchprogram, der lodret læser hele databasen på udkig efter ændringer. Data, der kommer ind i lageret ved hjælp af denne ETL-tilgang, er altid forældede (normalt en dag).

Efterhånden som mængden af behandlede data vokser, såvel som antallet og variationen af databehandlingssystemer, øges tiden og kompleksiteten af processen med at fylde lageret. Samtidig fører globaliseringen, den voksende varighed af systemdriften og begrænsede serviceaftaler til behovet for at reducere batchdriften. Kombinationen af mere data og konkurrencepres skaber betydelige udfordringer for en it-organisation.

Beslutninger truffet på baggrund af gårsdagens data er ikke længere tilfredsstillende for de fleste organisationer. Beslutningstagning i realtid kræver realtidsdata, hvilket stiller særlige krav til dataintegration til Lageret.

Derudover skal analytiske operationer udført i Lageret overføres igen til det OLTP-system, som dataene kom fra. På denne måde centraliseres analytisk behandling, og beslutninger, der træffes om aggregerede data i Lageret, overføres til de relevante OLTP-systemer.

Disse tendenser realiseres som følger:
Dataintegration i realtid til Data Warehouse. Modtagelse og transmission af data i realtid fra operativsystemer til Storage, hvilket gør dataene tilgængelige for analyse.
Aktivt datavarehus. Datavarehus i realtid suppleret med Business Intelligence-værktøjer til behandling og eksekvering af forretningsbeslutninger. Løsninger overføres automatisk til OLTP-systemer. Som et resultat dannes en lukket behandlingscyklus.

I jagten på at opnå realtidsfunktionalitet af Warehouse afhænger succes ofte af det kloge valg af integrationsværktøj og tilgang til dataindsamling, som giver mulighed for at forbedre kvaliteten og aktualiteten af information.
Dataintegration i realtid til Warehouse

For at understøtte realtidsintegration skal batchtilgangen til at hente driftsdata erstattes af processer, der kontinuerligt overvåger kildesystemernes tilstand, fanger og transformerer ændringer i data, efterhånden som de opstår, og derefter indlæser dem i lageret så tæt på realtid. som muligt. Kontinuerlig dataindsamling giver dig mulighed for at analysere profit- og priselementer i enhver tidsramme. Tendenser kan analyseres ved enhver valgt frekvens og uden forsinkelse.

ETL er en ideel løsning på problemet med lignende indlæsning af store mængder data i lageret og giver også omfattende datatransformationsmuligheder. ETL-operationer udføres dog typisk, mens opdatering af kildesystemet er sat på pause for at sikre, at kilden ikke ændres, når dataene modtages. Dette fører igen til uoverensstemmelser mellem OLTP-systemer og Storage. Som følge heraf er data og applikationer ikke altid tilgængelige for erhvervsbrugere.

EAI-løsninger, der tidligere er designet til applikationsintegration, konkurrerer eller eksisterer i dag ofte sammen med ETL-teknologier, der repræsenterer værktøjer til integration og dataindsamling i realtid. EAI-løsninger overfører information mellem kilde- og målsystemer, sikrer datalevering, giver avanceret flowunderstøttelse og forenkler vigtige konverteringselementer.

Imidlertid pålægger EAI-teknologi begrænsninger for mængder, da den oprindelige forudsætning for denne metode var integration af applikationer (ikke data), og dens essens er at starte applikationer og sende instruktioner og meddelelser. Men evnen til at flytte information i realtid og bevare dens integritet under integrationsprocessen i nogle tilfælde gør EAI-teknologi velegnet til udveksling mellem operativsystemer og aktiv Storage.

En anden tilgang til dataintegration i realtid er Transactional Data Management (TDM) teknologi, designet til at modtage, transmittere, transformere, levere og verificere transaktionsdata i et heterogent miljø i realtid. TDM opererer på gennemførte transaktioner: vælger dem fra OLTP-systemer gælder grundlæggende transformationsmetoder og overføre dem til Lageret. Ved sin arkitektur er teknologien asynkron, men den giver synkron adfærd, arbejder med en forsinkelse på en brøkdel af et sekund og opretholder integriteten af dataene i transaktionen.

EAI og TDM er designet til at formidle ændringer og opdateringer til data i stedet for komplette dataeksempler. Ingen af dem kræver, at kildesystemerne suspenderes, fordi disse teknologier opretholder integriteten af datamanipulationssprog (DML) operationer. Dette reducerer mængden af påkrævet databevægelse markant. Og mens ETL-værktøjer primært er designet til den indledende indlæsning og transformation af data, er EAI og TDM mere velegnede til kontinuerlig dataindsamling.

Et stigende antal virksomheder bruger TDM-teknologi til at indsamle data til Lageret. TDM-værktøjer fanger, dirigerer, leverer og verificerer dataoperationer på tværs af heterogene databasemiljøer med latens på under sekunder.

Overførsel af ændrede data på transaktionsniveau gør det muligt for systemet at operere i aktiv tilstand og behandle operationer samtidig med påfyldning af Lageret. I dette tilfælde er afhængigheden af batchbehandlingsintervallet fuldstændig elimineret, og integriteten af hver transaktion bevares.

Integration af lager- og OLTP-systemet indebærer modtagelse og transmission af transaktionsdata til lageret samtidig med overførsel af data om beslutninger truffet på baggrund af datavarehusdata til et eller flere driftssystemer. Denne lukkede sløjfedrift er også sikret af TDM.
Vigtigste egenskaber og muligheder for integrationsværktøjer

TDM-integrationsværktøjer har en række vigtige funktionelle funktioner.

Dataindsamling

Dataindsamlingsmoduler er installeret på kildedatabasen og overvåger konstant alle nyligt modtagne transaktioner. Dette opnås ved at læse store mængder data fra transaktionslogfiler, mens transaktioner stadig er i gang og typisk i hukommelsen. Data behandles på transaktionsniveau, og kun afsluttede operationer sendes til Lageret.

Data levering

Alle nye data overføres til det mellemliggende lagerområde i datavarehuset med en tidsforsinkelse på en brøkdel af et sekund. Det betyder, at de mest opdaterede data altid er tilgængelige til avancerede Business Intelligence-teknikker, rapportering og beslutningstagning. Da mindre samples af data transmitteres over en given tidsperiode (end i tilfælde af pakketransmission), er den ekstra belastning på OLTP-systemet meget lille.

Heterogenitet

Datavarehuset kører ikke nødvendigvis i samme operativsystem eller database som OLTP-systemet. Derudover opstår der ofte situationer, hvor du skal indsamle data fra flere operativsystemer og baser. Derfor skal integrationsværktøjer understøtte en bred vifte af DBMS'er såvel som platforme, hvilket forenkler kravene til selv de mest heterogene it-infrastrukturer. På denne måde kan en organisation vælge en platform baseret på virksomhedens standarder og præferencer, og også udvikle sig med minimal indvirkning på dens færdige datalagringsløsning.

De data, der indsamles af integrationsværktøjet, konverteres til et platform- og DBMS-uafhængigt format. Dette bevarer heterogenitet og eliminerer risikoen for datatab eller korruption i tilfælde af en kilde- eller målsystemafbrydelse.

Dataselektivitet

Integrationsværktøjer overfører kun de data, der kræves i lageret. I et typisk OLTP-system er der felter, der kun er specifikke for det program, som databasen betjener. Ikke alle disse parametre er nødvendige i Storage. Integrationsværktøjet skal give identifikation af de kolonner, der skal udtrækkes fra databaserne og overføres til Storaget.

Afhængigt af brugerens kriterier kan visse rækker også vælges fra kildesystemets database. For eksempel for at adskille data efter geografi eller for at vælge produkter, der er specifikke for mållageret.

Datakonvertering

Selektivitet i dataoverførsel er vigtig, men udfordringen er fortsat at transformere, normalisere eller denormalisere dataene, afhængigt af målsystemet. På grund af de forskellige datamodeller og objektstrukturer mellem OLTP-databasen og Warehouse, kan kolonnerne i kildesystemet konverteres til at matche kolonnerne i målsystemet. I nogle tilfælde bliver det nødvendigt at flette flere kolonner fra forskellige kilderækker til en enkelt række og omvendt. For komplekse datatransformationer foreslås udgangspunkter til brugerprogrammet for at implementere eventuelle organisationsspecifikke regler for udfyldning af datavarehuset.

Fleksibilitet

Evnen til hurtigt og nemt at aktivere nye databasekilder eller målsystemer, herunder datafangst- og leveringsprocesser, er vigtig.

Dynamisk tabeldefinition

For ikke at afbryde driften af lageret, er det designet med evnen hurtig tilpasning til mulige ændringer i databasen. Definitionerne af kilde- og måltabellerne ændres enten med fremkomsten af nye softwareversioner eller med ændringer i krav til lagerkapacitet. Dynamisk indstilling af tabelskemaer er mulig ved hjælp af parametriske filer. På denne måde kan du foretage ændringer i kilde- eller måltabeller for hurtigt at implementere ændringer uden at opgradere software eller gøre systemer forældede.

Feedback

Active Storage overfører data, hvis visse betingelser eller regler er opfyldt. En kompleks operation kan involvere opdatering af poster i OLTP. For eksempel kan et svindeldetekteringssystem fremhæve mistænkelige transaktioner og ændre status for en brugers konto i Vault. Denne ændring i status kan overvåges af integrationsværktøjet og overføres til det relevante online transaktionsbehandlingssystem. Returnering af information til et OLTP-system er meget vigtig for enhver applikation med lukket kredsløb, såvel som for samtidig afsendelse af information til rapporteringsmiljøer, datavarehuse, sikkerhedskopier eller andre målsystemer.
At kombinere teknologier

I opgaven med at integrere DW og OLTP er det muligt at kombinere TDM og ETL processer. Herunder databehandling i realtid, kontinuerlig indsamling og genfinding af data på transaktionsniveau. TDM-værktøjer kan overføre data i realtid til det mellemliggende lagerlag i måldatabasen, hvor ETL-serveren opsnapper dataene og, efter at have anvendt transformationer til dem, indlæser dem i Warehouse. Denne tilgang har ulemper (herunder yderligere latenstid og behovet for at vedligeholde en ETL-server), men de er rimelige, hvis datatransformationskravene er for komplekse.

Fordelene er, at nye transaktionsdata straks fanges med meget lille præstationspåvirkning på OLTP-systemet (sammenlignet med en konventionel ETL-proces).
etc.................

Spørgsmål til statsprøven

CIS livscyklus. Stadier af CIS livscyklus

CIS-livscyklusmodeller (forretningsapplikationer)

Teknologiske processer til oprettelse af CIS

CASE-værktøjer til at understøtte CIS-livscyklussen

Metoder og værktøjer til strukturel systemanalyse og design

Grundlæggende elementer i virksomhedssystemarkitektur: forretningsarkitektur, informationsarkitektur, applikationsarkitektur, teknologiarkitektur

Virksomhedens informationssystemer. Deres struktur. Eksempler på CIS

Informationsarkitektur af CIS. Formål og sammensætning. Metoder og værktøjer til at beskrive dataarkitektur

Værktøjssæt til design, udvikling og vedligeholdelse afr

Arkitektoniske mønstre (OLTP, OLAP-systemer) ir

OLAP systemer

OLAP (eng. online analytical processing, analytical processing in real time) er en databehandlingsteknologi, der består i at udarbejde summarisk (aggregeret) information baseret på store mængder data struktureret efter et multidimensionelt princip. Implementeringer af OLAP-teknologi er komponenter i Business Intelligence-softwareløsninger.

Grundlæggeren af begrebet OLAP, Edgar Codd, foreslog de "12 love for analytisk behandling i realtid" i 1993.

Virksomheder har ofte flere informationssystemer – lagerregnskabssystemer, regnskabssystemer, ERP-systemer til automatisering af individuelle produktionsprocesser, systemer til indsamling af rapporter fra virksomhedens afdelinger, samt mange filer, der er spredt på medarbejdernes computere.

Med så mange forskellige informationskilder kan det ofte være meget svært at få svar på vigtige forretningsspørgsmål og se det store billede. Og når nødvendige oplysninger stadig er i et af de anvendte systemer eller en lokal fil, er den ofte forældet eller modsiger oplysninger indhentet fra et andet system.

Dette problem løses effektivt ved hjælp af informations- og analysesystemer bygget på basis af OLAP-teknologier (andre navne: OLAP-system, Business Intelligence System, Business Intelligence). OLAP-systemer integrerer eksisterende regnskabssystemer, hvilket giver brugeren værktøjer til at analysere store mængder data i realtid, dynamisk generere rapporter, overvåge og forudsige vigtige forretningsindikatorer.

Fordele ved OLAP-systemer

Information spiller en nøglerolle i virksomhedens ledelse. Som regel bruger selv små virksomheder flere informationssystemer til at automatisere forskellige aktivitetsområder. At opnå analytisk rapportering i informationssystemer baseret på traditionelle databaser er forbundet med en række begrænsninger:

Udviklingen af hver rapport kræver en programmørs arbejde.

Rapporter genereres meget langsomt (ofte flere timer), hvorved driften af hele informationssystemet bremses.

Data modtaget fra forskellige strukturelle elementer i virksomheden er ikke samlet og er ofte modstridende.

OLAP-systemer er, ud fra selve ideologien bag deres design, designet til at analysere store mængder information og tillade en at overvinde begrænsningerne ved traditionelle informationssystemer.

Oprettelse af et OLAP-system på en virksomhed vil tillade:

Integrer data fra forskellige informationssystemer, skab en enkelt version af sandheden

Design nye rapporter med et par museklik uden programmørers indgriben.

Analyser data i realtid på tværs af alle kategorier og forretningsindikatorer på ethvert detaljeniveau.

Overvåg og prognose nøgleforretningsindikatorer

Når du arbejder med et OLAP-system, kan du altid hurtigt finde svar på nye spørgsmål, se det store billede og konstant overvåge din virksomheds tilstand. Samtidig kan du være sikker på, at du kun bruger relevant information.

Resultater af implementeringen af OLAP-systemet

Ledelsen får en fuldstændig klar vision af situationen og en samlet mekanisme til regnskab, kontrol og analyse.

Ved at automatisere interne forretningsprocesser og øge medarbejdernes produktivitet reduceres behovet for menneskelige ressourcer.

OLAP handling

Grunden til at bruge OLAP til forespørgselsbehandling er hastighed. Relationelle databaser gemmer enheder i separate tabeller, som normalt er godt normaliserede. Denne struktur er praktisk til operationelle databaser (OLTP-systemer), men komplekse multi-table-forespørgsler er relativt langsomme at udføre.

En OLAP-struktur oprettet ud fra operationelle data kaldes en OLAP-kube. En terning oprettes ved at forbinde tabeller ved hjælp af et stjerneskema eller et snefnugskema. I midten af stjerneskemaet er en faktatabel, som indeholder de vigtigste fakta, som forespørgsler er baseret på. Tabeller med flere dimensioner er forbundet til en faktatabel. Disse tabeller viser, hvordan aggregerede relationelle data kan analyseres. Antallet af mulige sammenlægninger bestemmes af antallet af måder, hvorpå de originale data kan vises hierarkisk.

For eksempel kan alle kunder grupperes efter by eller region i landet (vest, øst, nord osv.), så 50 byer, 8 regioner og 2 lande vil udgøre 3 niveauer af hierarki med 60 medlemmer. Kunderne kan også forenes i forhold til produkter; hvis der er 250 produkter i 2 kategorier, 3 produktgrupper og 3 produktionsdivisioner, så vil antallet af enheder være 16560. Når der tilføjes dimensioner til diagrammet, når antallet af mulige muligheder hurtigt op på titusinder eller mere.

En OLAP-terning indeholder grundlæggende data og information om dimensioner (aggregater). Terningen indeholder potentielt al den information, der kan være nødvendig for at besvare eventuelle forespørgsler. På grund af det store antal enheder sker en fuld beregning ofte kun for nogle målinger, mens den for resten udføres "on demand".

Sammen med det grundlæggende koncept er der tre typer OLAP:

OLAP med mange dimensioner (Multidimensional OLAP - MOLAP);

relationel OLAP (Relationel OLAP - ROLAP);

hybrid OLAP (Hybrid OLAP - HOLAP).

MOLAP er den klassiske form for OLAP, så den kaldes ofte blot OLAP. Den bruger en opsummerende database, en speciel variant af den geografiske databaseprocessor, og opretter det nødvendige geografiske dataskema, der bevarer både grundlæggende data og aggregater.

ROLAP arbejder direkte med relationel lagring, fakta og dimensionstabeller gemmes i relationelle tabeller, og der oprettes yderligere relationelle tabeller for at gemme aggregater.

HOLAP bruger relationelle tabeller til at gemme basisdata og multidimensionelle tabeller til at gemme aggregater.

Et særligt tilfælde af ROLAP er ROLAP i realtid (R-ROLAP). I modsætning til ROLAP oprettes der i R-ROLAP ingen yderligere relationelle tabeller til lagring af aggregater, og aggregater beregnes på tidspunktet for anmodningen. I dette tilfælde konverteres en flerdimensionel forespørgsel til et OLAP-system automatisk til en SQL-forespørgsel til relationelle data.

Hver type opbevaring har visse fordele, selvom der er uenighed i deres vurdering forskellige producenter. MOLAP er bedst egnet til små datasæt, det beregner hurtigt aggregater og returnerer svar, men det genererer enorme mængder data. ROLAP er vurderet som en mere skalerbar løsning, der også bruger mindst mulig plads. Samtidig reduceres behandlingshastigheden betydeligt. HOLAP er i midten af disse to tilgange, den skalerer ret godt og er hurtig at behandle. R-ROLAP-arkitekturen giver mulighed for multidimensionel analyse af OLTP-data i realtid.

Udfordringen ved at bruge OLAP er at oprette forespørgsler, vælge de underliggende data og designe skemaet, og som et resultat kommer de fleste moderne OLAP-produkter med et stort antal prækonfigurerede forespørgsler. Et andet problem er i de underliggende data. De skal være fuldstændige og konsekvente

OLAP implementeringer

Historisk set den første multidimensionelt system Databasestyring, som i det væsentlige er en OLAP-implementering, anses for at være Express-systemet, udviklet i 1970 af IRI (rettighederne til produktet blev senere erhvervet af Oracle Corporation og omdannet til en OLAP-mulighed for Oracle Database). Udtrykket OLAP blev introduceret af Edgar Codd i en publikation i magasinet Computerworld i 1993, hvor han foreslog 12 principper for analytisk behandling, svarende til de 12 regler for relationelle databaser, som han formulerede et årti tidligere, som et referenceprodukt, der opfylder de foreslåede principper, indikerede Codd Essbase-systemet fra Arbor (erhvervet i 1997 af Hyperion, som igen blev købt af Oracle i 2007). Det er bemærkelsesværdigt, at publikationen efterfølgende blev fjernet fra Computerworlds arkiver på grund af en mulig interessekonflikt, da Codd senere leverede konsulenttjenester til Arbor.

Andre velkendte OLAP-produkter: Microsoft Analysis Services (tidligere kaldet OLAP Services, en del af SQL Server), SAS OLAP Server, TM1, PowerPlay, SAP BW, MicroStrategy Ingelligence Server, Mondrian, Analytical complex PROGNOZ.

Fra implementeringssynspunktet er de opdelt i "fysisk OLAP" og "virtuel" (relationel, engelsk Relationel OLAP, ROLAP). "Fysisk" er til gengæld, afhængigt af implementeringen, opdelt i multidimensionel (Multidimensional OLAP, MOLAP) og hybrid (Hybrid OLAP, HOLAP).

I det første tilfælde er der et program, der på tidspunktet for den foreløbige indlæsning af data til OLAP fra kilder udfører en foreløbig beregning af aggregater (beregninger baseret på flere begyndelsesværdier, f.eks. "Total for måneden"), som gemmes derefter i en speciel multidimensionel database, der giver hurtig genfinding og økonomisk lagring. Eksempler på sådanne produkter er Microsoft Analysis Services, Oracle OLAP Option, Essbase, SAS OLAP Server, TM1, PowerPlay.

Hybrid OLAP er en kombination. Selve dataene gemmes i relationel database data og aggregater - i multidimensional.

I ROLAP-implementeringer lagres og behandles alle data i relationelle databasestyringssystemer, og aggregater eksisterer muligvis slet ikke eller kan oprettes ved den første anmodning i DBMS eller analytisk softwarecache. Eksempler på sådanne produkter er SAP BW, Microstrategy Intelligence Server, Mondrian.

Fra brugerens synspunkt ligner alle muligheder ens. OLAP er mest udbredt i finansielle planlægningsprodukter, datavarehuse og Business Intelligence-løsninger.

OLTP-systemer (online transaktionsbehandlingssystemer)

OLTP (Online Transaction Processing), transaktionssystem - transaktionsbehandling i realtid. En metode til at organisere en database, hvor systemet arbejder med små transaktioner, men med et stort flow, og samtidig kræver klienten minimal responstid fra systemet.

Begrebet OLTP anvendes også på systemer (applikationer). OLTP-systemer er designet til indtastning, struktureret lagring og behandling af information (transaktioner, dokumenter) i realtid.

Problemet med integritet er at sikre, at databasedata er korrekte til enhver tid. Den kan overtrædes i følgende tilfælde: 1. ved indtastning og opdatering, ved afgivelse af forkerte oplysninger. 2. når data bruges samtidigt af flere brugere. 3. i tilfælde af APS-fejl.

Løsning af integritetsproblemer skal betragtes ud fra et programmatisk og organisatorisk synspunkt. For PObl 1. er en række organisatoriske foranstaltninger nødvendige (for at overvåge input), brugeren skal kende inputreglerne og restriktioner. Til problemer 2-3 - standard DBMS-værktøjer eller specielle softwaremoduler. DBMS – 2 hovedintegritetsbegrænsninger: 1. strukturelle begrænsninger (sæt funktionelle forbindelser og kontrolleres ved at kontrollere ligheden af DB-værdier) 2. restriktioner på reelle værdier. De kræver, at feltværdierne tilhører et bestemt område, eller der er en afhængighed mellem værdierne i nogle felter. (datatyper og inputmasker). Begrænsninger kan indstilles af DBA til enhver tid, men DBMS accepterer muligvis ikke begrænsningen (hvis mange poster ikke længere opfylder den), hvis der er et match, skrives det ind i ordbogen og bruges. Begrænsninger varierer i sværhedsgrad:

2. restriktioner på sættet af strengattributter. (position – rangsatser, region – byer).

3. restriktioner på mange linjer på samme tid.

Alle disse begrænsninger er statistiske, men når en database går fra en tilstand til en anden, er det nødvendigt at opfylde integritetsbegrænsninger før starten af alle ændringer og efter slutningen af alle, ikke hver. Sådanne begrænsninger kaldes udskudt, og begrebet transaktioner introduceres i forhold til dem. En transaktion er en handling gennemført på databasen fra brugerens synspunkt. Samtidig er det en logisk enhed for systemdrift. En transaktion implementerer en eller anden applikationsfunktion, for eksempel at overføre penge fra en konto til en anden i banksystemet.

Skal have 4 egenskaber: 1. Atomicitet (udelelighed): udføres som en enkelt databaseadgangsoperation, skal udføres fuldstændigt eller slet ikke udføres. 2. Konsistens – garanterer den gensidige integritet af data efter transaktionsbehandlingen er afsluttet. 3. Isolation (hver transaktion kan ændre data, der midlertidigt er i en inkonsistent tilstand). Samtidig nægtes andre transaktioner adgang til disse data, indtil transaktionen er gennemført. 4. holdbarhed - hvis transaktionen lykkes, vil ændringerne ikke gå tabt. Resultatet af at udføre en transaktion kan være dens commit (handlingen med at begå ændringer til databasen) eller rollback (annullering af transaktionen og returnering af databasen til den tilstand, før den begyndte). Commit og rollback mekanismen er baseret på brugen af en transaktionslog, hvor tilstanden FØR (i flere iterationer) og EFTER gemmes. Nogle SQL-dialekter inkluderer mellemliggende commit-sætninger (punkt-til-punkt rollback).

Transaction Processing Monitors (TPM) er softwaresystemer (klassificeret som mellemmand eller middleware), der løser problemet med effektiv styring af information og computerressourcer i distribueret system. De giver et fleksibelt, åbent miljø til udvikling og styring af mobile applikationer med fokus på hurtig behandling af distribuerede transaktioner. Blandt de vigtigste egenskaber ved TPM er skalerbarhed, understøttelse af funktionel fuldstændighed og integritet af applikationer, opnåelse af maksimal ydeevne ved behandling af data til lave omkostninger og opretholdelse af dataintegritet i et heterogent miljø. TPM'er er afhængige af en tre-tiers klient-server model

På det moderne marked for transaktionsovervågning er de vigtigste "aktører" systemer som ACMS (DEC), CICS (IBM), TOP END (NCR), TUXEDO Sytem (Novell).

Datadeling

Ved implementering af transaktioner opstår der et problem: tab af opdateringer (kun ændringerne fra en bruger registreres i databasen, resten går tabt). Og problem 2 er at læse uforpligtende data. For at løse dette skal du bruge specieller. Principper: 1. transaktionen har ingen adgang til uforpligtende data. 2. resultatet af fælles udførelse af transaktioner svarer til deres seneste udførelse. Denne mekanisme implementeres gennem et låsesystem: DBMS låser den del af databasen, som transaktionen har adgang til, indtil den er begået, dvs. Den 2. transaktion skal placeres i en ventekø. Jo større element, der blokeres, jo langsommere behandles transaktionen. I OLTP-systemer er en række typisk låst, og transaktioner kan blive deadlocked. For at forhindre dette, poller DBMS periodisk låse, og hvis der er en, afbrydes en af transaktionerne. For mere bekvemt arbejde er datadelingslåse tilladt: Parallelle brugere har forbud mod at ændre data, men har lov til at hente dem. Denne tilgang er ikke den eneste, du kan for eksempel bruge datareplikering i systemer med distribueret adgang. Denne teknologi indebærer at opgive distributionen af data, og hver node har sin egen kopi af databasen. Værktøjer, der sikrer dette, bør opretholde en ensartet databasetilstand ved at kopiere ændringer. Processen med at overføre ændringer fra kildedatabasen til databaserne for individuelle noder kaldes datareplikering. Disse funktioner udføres af et specifikt modul (cirkulationsserver/replikator). Måden det fungerer på er fuldstændig at opdatere indholdet af databasen på fjernservere(skema med fuld opdatering) eller opdatering kun skiftende data (skema med hurtig opdatering) Hvis der ikke er behov for konstant at opdatere data, akkumulerer replikatoren ændringer og kopierer dem på det rigtige tidspunkt.

OLTP - online transaktionsbehandlingssystemer er karakteriseret ved et stort antal ændringer, samtidig adgang for mange brugere til de samme data for at udføre forskellige operationer - læsning, skrivning, sletning eller ændring af data. Til Normal drift låse og transaktioner anvendes på mange brugere. Effektiv transaktionsbehandling og låsesupport er blandt de vigtigste krav til online transaktionsbehandlingssystemer.

Moderne databaseteknologier stiller visse arkitektoniske krav. Indtil for nylig blev der skelnet mellem tre klasser af problemer:

opgaver med operationel transaktionsbehandling;

batchbehandlingsopgaver;

beslutningsproblemer.

OLTP-systemer er systemer til online transaktionsbehandling. Hovedfunktionen af sådanne systemer er samtidig at udføre et stort antal korte transaktioner fra et stort antal brugere. Selve transaktionerne ser relativt enkle ud, for eksempel "træk et beløb fra konto A, tilføj dette beløb til konto B." Historisk set er sådanne systemer primært opstået, fordi de opfyldte behovene for regnskabsføring, servicehastighed, dataindsamling mv.

OLTP-systemer er karakteriseret ved:

støtte til et stort antal brugere;

kort responstid på anmodninger;

relativt korte forespørgsler;

korte transaktioner;

deltage i forespørgsler på et lille antal borde.

Næsten alle databaseforespørgsler i OLTP-systemer består af indsæt-, opdaterings- og sletkommandoer. Udvalgte forespørgsler er primært designet til at give brugerne mulighed for at vælge fra forskellige mapper. De fleste af anmodningerne er således kendt på forhånd på systemdesignstadiet. Derfor er hastighed og pålidelighed af korte dataopdateringsoperationer afgørende for OLTP-applikationer.

Online transaktionsbehandlingsserveren er bygget under antagelsen:

OLTP-operationer understøttes stort antal bruger;

korte simple transaktioner bruges oftest;

transaktioner bruger normalt ikke de samme data;

operatører normalt påvirker lille antal linjer;

responstid - brøkdele af et sekund;

kun få borde har store størrelser eller kan ændres.

Implementeringen af en sådan server afhænger af:

fysiske teknikker til at reducere diskoperationer;

forarbejdning små mængder data i hukommelsen;

primitiv forespørgselsoptimering;

Kravet til ansøgninger er at eliminere konkurrencen mellem anmodninger om brug af ressourcer og data.

Data Warehousing og Data Mining

Data Mining er oversat som "minedrift" eller "udgravning af data." Ordene "videnopdagelse i databaser" og "data mining" findes ofte ved siden af Data Mining. De kan betragtes som synonyme med Data Mining. Fremkomsten af alle disse udtryk er forbundet med en ny runde i udviklingen af databehandlingsværktøjer og -metoder.

Indtil begyndelsen af 1990'erne syntes der at være lidt behov for at genoverveje situationen på dette område. Alt foregik som normalt inden for rammerne af en retning, der kaldes anvendt statistik (se f.eks.). Teoretikere holdt konferencer og seminarer, skrev imponerende artikler og monografier, fyldt med analytiske beregninger.

Samtidig har praktikere altid vidst, at forsøg på at anvende teoretiske øvelser til at løse reelle problemer i de fleste tilfælde viser sig at være frugtesløse. Men foreløbig kunne man ikke være særlig opmærksom på praktiserende lægers bekymringer - de løste hovedsageligt deres egne private problemer med at behandle små lokale databaser.

Og så ringede klokken. På grund af forbedringen af teknologier til registrering og lagring af data er mennesker blevet bombarderet med kolossale strømme af informationsmalm på en række forskellige områder. Aktiviteterne i enhver virksomhed (kommerciel, fremstilling, medicinsk, videnskabelig osv.) er nu ledsaget af registrering og registrering af alle detaljer om dens aktiviteter. Hvad skal man gøre med disse oplysninger? Det blev klart, at uden produktiv behandling ville strømme af rådata danne en ubrugelig losseplads.

De særlige kendetegn ved moderne krav til sådan behandling er som følger:

Data har ubegrænset mængde

Dataene er heterogene (kvantitative, kvalitative, tekstuelle)

Resultaterne skal være specifikke og forståelige

Rådatabehandlingsværktøjer skal være nemme at bruge

Traditionel matematisk statistik, i lang tid som hævdede at være det vigtigste dataanalyseværktøj, gav åbenlyst op i lyset af de problemer, der opstod. Hovedårsagen er konceptet med at beregne et gennemsnit over en prøve, hvilket fører til operationer på fiktive værdier (såsom gennemsnitstemperaturen for patienter på et hospital, den gennemsnitlige højde af et hus på en gade bestående af paladser og hytter osv. ). Metoder til matematisk statistik har vist sig at være nyttige hovedsageligt til at teste præformulerede hypoteser (verifikationsdrevet datamining) og til "grov" eksplorativ analyse, som danner grundlaget for online analytisk behandling (OLAP).

Grundlaget moderne teknologi Data Mining (opdagelsesdrevet datamining) er baseret på konceptet med skabeloner (mønstre), der afspejler fragmenter af multidimensionelle relationer i data. Disse mønstre repræsenterer mønstre, der er iboende i delprøver af data, der kan udtrykkes kompakt i en menneskelig læsbar form. Søgningen efter mønstre udføres ved hjælp af metoder, der ikke er begrænset af a priori antagelser om strukturen af prøven og typen af fordelinger af værdierne af de analyserede indikatorer. Eksempler på opgaver til en sådan søgning ved brug af Data Mining er givet i tabel. 1.

Et vigtigt punkt ved Data Mining er, at de mønstre, der søges efter, ikke er trivialiteter. Det betyder, at de fundne mønstre skal afspejle uoplagte, uventede regelmæssigheder i dataene, som udgør den såkaldte skjulte viden. Samfundet er kommet til at forstå, at rådata indeholder et dybt lag af viden, hvis korrekte udgravning kan afsløre rigtige klumper (fig. 1).

Figur 1. Niveauer af viden udtrukket fra data

Generelt er Data Mining-teknologi ret præcist defineret af Grigory Piatetsky-Shapiro, en af grundlæggerne af denne retning:

Data Mining er processen med at opdage i rådata tidligere ukendt, ikke-triviel, praktisk nyttig og fortolkelig viden, der er nødvendig for beslutningstagning inden for forskellige områder af menneskelig aktivitet.

2. Hvem har brug for det?

Omfanget af Data Mining er ikke begrænset på nogen måde - det er overalt, hvor der er nogen data. Men først og fremmest har Data Mining-metoder i dag mildt sagt fascineret kommercielle virksomheder, der implementerer projekter baseret på datavarehuse (Data Warehousing). Erfaringerne fra mange sådanne virksomheder viser, at afkastet ved hjælp af data Minedrift kan nå op på 1000%. For eksempel er der rapporter om en økonomisk effekt, der er 10-70 gange større end startomkostningerne på 350 til 750 tusind dollars. . Der er oplysninger om et projekt på 20 millioner dollars, der betalte sig selv på kun 4 måneder. Et andet eksempel er årlige besparelser på 700 tusind dollars. gennem implementering af Data Mining i en kæde af supermarkeder i Storbritannien.

Data Mining er af stor værdi for ledere og analytikere i deres daglige aktiviteter. Forretningsfolk har indset, at de ved hjælp af Data Mining-metoder kan opnå håndgribelige konkurrencefordele. Lad os kort beskrive nogle mulige forretningsapplikationer af Data Mining.

ELLER

Hvad er der sketDataMinedrift

Virksomhedsdatabasen for enhver moderne virksomhed indeholder normalt et sæt tabeller, der gemmer optegnelser om visse fakta eller objekter (for eksempel om varer, deres salg, kunder, konti). Som regel beskriver hver post i en sådan tabel et bestemt objekt eller et bestemt faktum. Eksempelvis afspejler en indtastning i salgstabellen det faktum, at et sådant og et produkt blev solgt til sådan og en kunde på det tidspunkt af en sådan og sådan en manager, og i det store og hele ikke indeholder andet end disse oplysninger. Imidlertid kan indsamlingen af et stort antal sådanne optegnelser, der er akkumuleret over flere år, blive en kilde til yderligere, meget mere værdifuld information, som ikke kan opnås på grundlag af én specifik registrering, nemlig information om mønstre, tendenser eller indbyrdes afhængighed mellem data. Eksempler på sådanne oplysninger er information om, hvordan salget af et bestemt produkt afhænger af ugedag, tidspunkt på dagen eller tidspunkt på året, hvilke kategorier af kunder, der oftest køber dette eller hint produkt, hvor stor en andel af køberne af et specifikt produkt, der køber. et andet specifikt produkt, hvilken kundekategori oftest ikke tilbagebetaler det ydede lån til tiden.

Denne form for information bruges normalt i prognoser, strategisk planlægning, risikoanalyse, og dens værdi for virksomheden er meget høj. Det er tilsyneladende derfor, at processen med at søge efter det blev kaldt Data Mining (mining på engelsk betyder "mining", og at søge efter mønstre i et stort sæt faktuelle data er virkelig beslægtet med dette). Udtrykket Data Mining betegner ikke så meget en specifik teknologi som processen med at søge efter korrelationer, tendenser, sammenhænge og mønstre gennem forskellige matematiske og statistiske algoritmer: klyngedannelse, skabelse af delprøver, regression og korrelationsanalyse. Formålet med denne søgning er at præsentere dataene i en form, der klart afspejler forretningsprocesser, og også at opbygge en model, hvormed du kan forudsige processer, der er kritiske for forretningsplanlægning (f.eks. dynamikken i efterspørgslen efter bestemte varer eller tjenester eller afhængigheden af deres erhvervelse af visse daværende forbrugeregenskaber).

Bemærk, at traditionel matematisk statistik, som i lang tid forblev hovedværktøjet til dataanalyse, såvel som værktøjer til online analytisk behandling (OLAP), som vi allerede har skrevet om flere gange (se materialer om dette emne på vores cd), kan ikke altid med succes bruges til at løse sådanne problemer. Typisk bruges statistiske metoder og OLAP til at teste præformulerede hypoteser. Ofte er det dog formuleringen af hypotesen, der viser sig at være mest udfordrende opgave ved implementering af forretningsanalyse til efterfølgende beslutningstagning, da ikke alle mønstre i dataene er tydelige ved første øjekast.

Oversigt over IT designet til operationel og analytisk databehandling

Efter at have studeret materialet med succes, vil du vide:

koncept og hovedformål med OLTP-systemer;

koncept og hovedformål med OLAP-systemer;

OLAP system klasser;

opgaver løst af OLTP- og OLAP-systemer.

Efter at have studeret dette emne vil du være i stand til at:

skelne mellem problemer løst af OLTP- og OLAP-systemer;

navigere i klasserne af OLAP-systemer.

Efter at have studeret materialet du du vil have færdighederne brug af OLTP- og OLAP-systemer i lederens arbejde.

Grundlæggende begreber for emne 7

teknologier med fokus på operationel (transaktionel) databehandling. Disse teknologier danner grundlaget for computerinformationssystemer designet til hurtig databehandling. Hedder lignende systemer- OLTP (online transaktionsbehandling) systemer;

teknologier med fokus på dataanalyse og beslutningstagning. Disse teknologier danner grundlaget for CISU designet til at analysere akkumulerede data. Sådanne systemer kaldes OLAP (online analytical processing) systemer.

OLAP systemer

Hovedformålet med OLAP-systemer: dynamisk multidimensionel analyse af historiske og aktuelle data, stabil over tid; trendanalyse; modellering og prognoser for fremtiden. Sådanne systemer er som regel fokuseret på at behandle vilkårlige, ikke-regulerede anmodninger. Som hovedkarakteristika disse systemer følgende kan bemærkes:

support flerdimensionel repræsentation data, lighed af alle dimensioner, uafhængighed af ydeevne fra antallet af dimensioner;

gennemsigtighed for brugeren af strukturen, metoder til lagring og behandling af data;

automatisk visning logisk struktur data i eksterne systemer;

dynamisk behandling af sparsomme matricer på en effektiv måde.

Begrebet OLAP identificeres ofte med DSS (Decision Support Systems). Og som et synonym for udtrykket "løsninger", de bruger Data warehousing - "data warehouses". Dette refererer til et sæt af organisatoriske løsninger, software og hardware til at give analytikere information baseret på data fra lavere transaktionsbehandlingssystemer og andre kilder.

"Datavarehuse" giver dig mulighed for at behandle data akkumuleret over lange perioder. Disse data er heterogene (og ikke nødvendigvis strukturerede). Datavarehuse er kendetegnet ved den multidimensionelle karakter af forespørgsler. Enorme mængder af data, kompleksiteten af strukturen af både data og forespørgsler - alt dette kræver brug af specielle metoder til at få adgang til information.

I andre kilder anses konceptet for et Decision Support System (DSS) for bredere. Datavarehuse og online analytiske behandlingsværktøjer kan tjene som en af komponenterne i DSS-arkitekturen.

OLAP inkluderer altid interaktiv forespørgselsbehandling og efterfølgende multi-pass-analyse af information, som giver os mulighed for at identificere forskellige, ikke altid indlysende, tendenser observeret i emneområdet.

Nogle gange skelnes OLAP som i snæver forstand- som systemer, der kun giver datasampling i forskellige sektioner, og OLAP i bred forstand, eller blot OLAP, herunder:

understøttelse af flere brugere, der redigerer databasen.

modelleringsfunktioner, herunder beregningsmekanismer til opnåelse af afledte resultater, samt aggregering og kombination af data;

prognoser, trendidentifikation og statistisk analyse.

Hver af disse typer systemer kræver en specifik organisering af data, såvel som specielle software sikre en effektiv gennemførelse af de forestående opgaver.

OLAP-værktøjer giver analyse af forretningsinformation på tværs af flere parametre, såsom produkttype, købers geografiske placering, transaktionstid og sælger, som hver især giver mulighed for at oprette et hierarki af visninger. Således kan du for tid bruge årlige, kvartalsvise, månedlige og endda ugentlige og daglige intervaller; geografiske opdelinger kan være efter by, stat, region, land eller hele halvkugle, hvis det er nødvendigt.

OLAP-systemer kan opdeles i tre klasser.

1 klasse. De mest komplekse og dyre af dem er baseret på patenterede teknologier multidimensionelle databaseservere. Disse systemer giver fuld cyklus OLAP-behandling og enten inkluderer, udover serverkomponenten, sin egen integrerede klientgrænseflade eller bruges til dataanalyse eksterne programmer arbejde med regneark. Produkter i denne klasse er bedst egnede til brug i store informationslagre. Deres vedligeholdelse kræver en hel stab af medarbejdere involveret i både at installere og vedligeholde systemet og skabe datavisninger til slutbrugere. Normalt er disse pakker ret dyre. Eksempler på produkter i denne klasse inkluderer Essbase-systemet fra Arbor Software, Express fra IRI (nu en del af Oracle), Lightship fra Pilot Software og andre.

Klasse 2 OLAP-systemer - relationelle OLAP-systemer(ROLAP). Her bruges gamle til at gemme data relationel DBMS, og mellem databasen og klientgrænsefladen organiseres et metadatalag bestemt af systemadministratoren. Gennem denne middleware kan klientkomponenten interagere med relationsdatabasen, som om den var en multidimensionel. Ligesom førsteklasses værktøjer er ROLAP-systemer velegnede til at arbejde med store informationslagre, kræver betydelige vedligeholdelsesomkostninger af specialister fra informationsafdelinger og sørger for arbejde i flerbrugertilstand. Produkter af denne type omfatter IQ Softwares IQ/Vision, MicroStrategys DSS/Server og DSS/Agent og Information Advantages DecisionSuite.

ROLAP-værktøjer implementerer beslutningsstøttefunktioner i en tilføjelse over den relationelle databaseprocessor.

Sådanne softwareprodukter skal opfylde en række krav, især:

har en kraftfuld OLAP-optimeret SQL-udtryksgenerator, der giver dig mulighed for at bruge multi-pass SQL SELECT-sætninger og/eller korrelerede underforespørgsler;

have tilstrækkeligt udviklede midler til at udføre ikke-triviel behandling, der giver rangordning, sammenlignende analyse og beregning af procenter inden for en klasse;

generere SQL-udtryk, der er optimeret til det relationelle mål-DBMS, inklusive understøttelse af de tilgængelige sprogudvidelser i det;

tilvejebringe mekanismer til at beskrive datamodellen ved hjælp af metadata og gøre det muligt at bruge disse metadata til at bygge forespørgsler i realtid;

inkludere en mekanisme, der giver dig mulighed for at evaluere kvaliteten af at bygge pivottabeller med hensyn til beregningshastighed, helst med akkumulering af statistikker om deres brug.

Klasse 3 OLAP-systemer - Desktop-forespørgsels- og rapporteringsværktøjer, suppleret med OLAP-funktioner eller integreret med med eksterne midler udføre sådanne funktioner. Disse meget avancerede systemer henter data fra råkilder, transformerer dem og placerer dem i en dynamisk multidimensionel database, der kører på slutbrugerens pc. Denne tilgang, som gør det muligt at undvære både en dyr multidimensionel databaseserver og et komplekst mellemliggende metadatalag, der kræves til ROLAP-værktøjer, sikrer samtidig tilstrækkelig analyseeffektivitet. Disse desktopværktøjer er bedst egnede til at arbejde med små, enkle databaser. De kræver mindre kvalificeret vedligeholdelse end andre OLAP-systemer og er nogenlunde på niveau med konventionelle forespørgselsbehandlingsmiljøer. Nøglespillere i denne sektor af markedet omfatter Brio Technology med sit Brio Query Enterprise-system, Business Objects med sit produkt af samme navn og Cognos med PowerPlay.

OLTP systemer

OLTP systemer, som er et yderst effektivt middel til at implementere operationel behandling, viste sig at være af ringe nytte til analytiske behandlingsopgaver. Dette er forårsaget af følgende.

Ved at bruge traditionelle OLTP-systemer kan du opbygge en analytisk rapport og endda en prognose for enhver kompleksitet, men reguleret på forhånd. Ethvert skridt til side, ethvert ureguleret krav fra slutbrugeren kræver som regel viden om datastrukturen og en ret høj kvalifikation af programmøren;

Mange nødvendige for operativsystemer funktionalitet er overflødige til analytiske opgaver og afspejler muligvis ikke fagområdet. Løsning af de fleste analytiske opgaver kræver brug af eksterne specialiserede værktøjer til analyse, prognose og modellering. Den stive struktur af databaserne gør det ikke muligt at opnå acceptabel ydeevne i tilfælde af komplekse udvælgelser og sorteringer, og det kræver derfor meget tid at organisere gateways.

I modsætning til transaktionssystemer kræver analytiske systemer ikke og sørger derfor ikke for udviklede midler til at sikre dataintegritet, backup og gendannelse. Dette gør det ikke kun muligt at forenkle selve implementeringsværktøjerne, men også at reducere intern overhead og dermed forbedre ydeevnen ved hentning af data.

Problemer løst af OLTP- og OLAP-systemer

Vi vil bestemme de opgaver, der effektivt løses af hvert af systemerne baseret på de komparative karakteristika for OLTP- og OLAP-systemer (Tabel 7.1, 7.2).

Tabel 7.1.
Problemer løst af OLTP- og OLAP-systemer

Egenskab
Dataopdateringshastighed	Høj frekvens, små portioner	Lav frekvens, store "portioner"
Data kilder	Hovedsageligt internt	I forhold til det analytiske system, hovedsageligt eksternt
Data alder	Nuværende (flere måneder)	Historisk (gennem årene) og fremskrevet
Dataaggregeringsniveau	Detaljerede data	For det meste aggregerede data
Analytiske operationsevner	Regulerede rapporter	Sekvens af interaktive rapporter, dynamisk forandring niveauer af aggregering og dataudsnit
Formålet med systemet	Registrering, operationel søgning og behandling af data, reguleret analytisk behandling	Arbejde med historiske data, analytisk bearbejdning, forecasting, modellering

Tabel 7.2.
SammenligningOLTP ogOLAP

Egenskab
Overvejende operationer	Dataindtastning, søgning	Dataanalyse
Arten af anmodninger	Masser af simple transaktioner	Komplekse transaktioner
Gemte data	Operationel, detaljeret	dækker en lang periode, samlet
En slags aktivitet	Operationel, taktisk	Analytisk, strategisk
Datatype	Struktureret	Forskellige typer

Hovedkonklusioner

Inden for it-ledelse er der to gensidigt komplementære områder:

teknologier fokuseret på operationel (transaktionel) databehandling - OLTP (online transaktionsbehandling) systemer;

teknologier med fokus på dataanalyse og beslutningstagning - OLAP (online analytical processing) systemer.

Hovedformålet med OLAP-systemer er dynamisk multidimensionel analyse af historiske og aktuelle data, stabile over tid, trendanalyse, modellering og prognoser for fremtiden.

OLAP-systemer kan opdeles i tre klasser.

1 klasse. Multidimensionelle databaseservere. Disse systemer giver en fuld cyklus af OLAP-behandling og inkluderer enten, ud over serverkomponenten, deres egen integrerede klientgrænseflade eller bruger eksterne regnearksprogrammer til dataanalyse.

2. klasse. Relationelle OLAP-systemer (ROLAP). Her bruges gamle relationelle DBMS'er til at lagre data, og et metadatalag defineret af systemadministratoren er organiseret mellem databasen og klientgrænsefladen. Gennem denne middleware kan klientkomponenten interagere med relationsdatabasen, som om den var en multidimensionel.

3. klasse. Forespørgsels- og rapporteringsværktøjer til stationære pc'er, forbedret med OLAP-funktioner eller integreret med eksterne værktøjer, der udfører sådanne funktioner. Disse systemer henter data fra kildekilder, transformerer dem og placerer dem i en dynamisk multidimensionel database, der kører på slutbrugerens pc.

OLTP-systemer, som er et yderst effektivt middel til at implementere online-behandling, viste sig at være af ringe nytte til analytiske behandlingsopgaver.

Data warehousing - "data warehouses". Dette refererer til et sæt af organisatoriske løsninger, software og hardware til at give analytikere information baseret på data fra lavere transaktionsbehandlingssystemer og andre kilder.

Kontrolspørgsmål

Hvilke to gensidigt komplementære områder findes inden for IT-ledelse?

Formuler hovedformålet med OLAP-systemer

Formuler hovedformålet med OL T P-systemer

Hvad menes med begrebet Data Warehousing?

Opgaver til selvstændigt arbejde