Multidimensionel datarepræsentation. Generel ordning for organisering af et datavarehus

Karakteristika for et OLTP-system Stor mængde information Ofte forskellige databaser for forskellige afdelinger Normaliseret skema, ingen duplikering af information Intensive dataændringer Transaktionsmetode Transaktioner påvirker en lille mængde data Behandling af aktuelle data - et øjebliksbillede Mange klienter Kort responstid - nogle få sekunder Karakteristika for et OLAP-system Stor mængde information Synkroniseret information fra forskellige databaser ved hjælp af almindelige klassifikatorer Unormaliseret databaseskema med dubletter Dataændringer sjældent, Ændring sker gennem batch-indlæsning Komplekse ad-hoc-forespørgsler udføres på store mængder data med omfattende brug af grupperinger og aggregerede funktioner. Tidsafhængighedsanalyse Lille antal arbejdende brugere - analytikere og ledere Længere svartid (men stadig acceptabel) - flere minutter

Codds regler for relationsdatabaser 1. Informationsregel. 2. Reglen om garanteret adgang. 3. Regel for understøttelse af ugyldige værdier. 4. Dynamisk katalogregel baseret på den relationelle model. 5. Regel om udtømmende dataundersprog. 6. Se opdateringsregel. 7. Regel for tilføjelse, opdatering og sletning. 8. Regel om uafhængighed af fysiske data. 9. Regel om uafhængighed af logiske data. 10. Regel om uafhængighed af integritetsbetingelser. 11. Regel om uafhængig distribution. 12. Regel om unikhed.

Codds regler for OLAP 1. Konceptuel flerdimensionel repræsentation. 2. Gennemsigtighed. 3. Tilgængelighed. 4. Konsekvent præstation i rapportudvikling. 5. Klient-server arkitektur. 6. Generel multidimensionalitet. 7. Dynamisk kontrol sparsomme matricer. 8. Multi-user support. 9. Ubegrænset krydsoperationer. 10. Intuitiv datamanipulation. 11. Fleksible muligheder for at modtage rapporter. 12. Ubegrænset dimension og antal aggregeringsniveauer.

Implementering af OLAP Typer af OLAP - MOLAP (Multidimensional OLAP) servere - både detaljerede data og aggregater gemmes i en multidimensionel database. ROLAP (Relational OLAP) - detaljerede data gemmes i en relationel database; aggregater gemmes i den samme database i specielt oprettede servicetabeller. HOLAP (Hybrid OLAP) - detaljerede data gemmes i en relationsdatabase, og aggregater gemmes i en multidimensionel database.

Funktioner ved ROLAP - stjerneskema 1. Én faktatabel, som er stærkt denormaliseret 2. Flere dimensionstabeller, som også er denormaliseret 3. Faktatabellens primære nøgle er sammensat og har én kolonne for hver dimension 4. Aggregerede data lagres sammen med de oprindelige Ulemper Hvis aggregater gemmes sammen med kildedataene, så er det i målinger nødvendigt at bruge ekstra parameter– hierarkiniveau

Lagerstruktur i ORACLE DBMS SQL-klientMOLAP-klient Java API JDBC OCI ODBC OLE DB CWM eller CWM2 OLAP-lagring (BLOB i en relationstabel) Stjerneskema Metadataregistrering Multidimensionel kerne (proces i ORACLE-kernen) OLAP DML SQL-grænseflade til OLAP (DBMS_AW, OLAP_TABLE , ... ) Multidimensionelle metadata

datavarehuse er dannet på baggrund af data registreret over en længere periode øjebliksbilleder operationelle databaser informationssystem og muligvis forskellige eksterne kilder. Datavarehuse bruger databaseteknologier, OLAP, dyb dataanalyse og datavisualisering.

Hovedkarakteristika for datavarehuse.

indeholder historiske data;
gemmer detaljerede oplysninger samt delvist og fuldstændigt opsummerede data;
dataene er for det meste statiske;
en ad hoc, ustruktureret og heuristisk måde at behandle data på;
medium og lavt;
uforudsigelig måde at bruge data på;
beregnet til analyse;
fokuseret på fagområder;
støtte til strategisk beslutningstagning;
betjener et relativt lille antal ledelsesmedarbejdere.

Begrebet OLAP (On-Line Analytical Processing) bruges til at beskrive modellen til præsentation af data og dermed teknologien til at behandle dem i datavarehuse. OLAP bruger en multidimensionel repræsentation af aggregerede data til at levere hurtig adgang til strategisk vigtig information med henblik på en dybdegående analyse. OLAP-applikationer skal have følgende grundlæggende egenskaber:

flerdimensionelle datapræsentation;
støtte til komplekse beregninger;
korrekt overvejelse af tidsfaktoren.

Fordele ved OLAP:

forfremmelse produktivitet produktionsmedarbejdere, udviklere applikationsprogrammer. Rettidig adgang til strategisk information.
giver brugerne tilstrækkelig mulighed for at foretage deres egne ændringer i skemaet.
OLAP-applikationer er afhængige af datavarehuse og OLTP-systemer, der modtager aktuelle data fra dem, hvilket gør det muligt at gemme integritetskontrol virksomhedsdata.
reducere belastningen på OLTP-systemer og datavarehuse.

OLAP og OLTP. Karakteristika og væsentligste forskelle

OLAP	OLTP
Datalager bør omfatte både interne virksomhedsdata og eksterne data	hovedkilden til information, der kommer ind i den operationelle database, er virksomhedens aktiviteter, og dataanalyse kræver inddragelse af eksterne informationskilder (f.eks. statistiske rapporter)
Mængden af analytiske databaser er mindst en størrelsesorden større end mængden af operationelle. at udføre pålidelige analyser og prognoser i datalager du skal have information om selskabets aktiviteter og markedsforhold over flere år	Til operationel behandling data for de sidste par måneder er påkrævet
Datalager skal indeholde ensartet præsenteret og sammenhængende information, der er så tæt som muligt på indholdet af operationelle databaser. En komponent er nødvendig for at udtrække og "rense" information fra forskellige kilder. I mange store virksomheder Samtidig er der flere operationelle informationssystemer med egne databaser (af historiske årsager).	Operationelle databaser kan indeholde semantisk ækvivalente oplysninger præsenteret i forskellige formater, med forskellige indikationer af tidspunktet for dens ankomst, nogle gange endda modstridende
Sættet af forespørgsler til en analytisk database kan ikke forudsiges. datavarehuse eksisterer for at reagere på ad hoc-anmodninger fra analytikere. Du kan kun regne med, at forespørgsler ikke kommer for ofte og vil involvere store mængder information. Størrelsen af den analytiske database tilskynder til brug af forespørgsler med aggregater (sum, minimum, maksimum, gennemsnits værdi etc.)	Databehandlingssystemer er bygget med løsninger i tankerne. specifikke opgaver. Information fra databasen udvælges hyppigt og i små portioner. Typisk kendes et sæt forespørgsler til en operationel database allerede under design
Når variabiliteten af analytiske databaser er lav (kun ved indlæsning af data), viser rækkefølgen af arrays, hurtigere indekseringsmetoder til masseprøvetagning og lagring af præ-aggregerede data at være rimelige	Databehandlingssystemer er i sagens natur meget variable, hvilket tages i betragtning i det anvendte DBMS (normaliseret databasestruktur, rækker gemt i uorden, B-træer til indeksering, transaktionelle)
Analytisk databaseinformation er så kritisk for en virksomhed, at der kræves større detaljeret beskyttelse (individuelle adgangsrettigheder til bestemte rækker og/eller kolonner i tabellen)	For databehandlingssystemer er det normalt tilstrækkeligt informationsbeskyttelse på bordniveau

Codds regler for OLAP-systemer

I 1993 udgav Codd OLAP for User Analysts: What It Should Be. I den skitserede han de grundlæggende begreber for operationel analytisk bearbejdning og identificeret 12 regler, der skal overholdes af produkter, der giver mulighed for onlineanalyse.

Konceptuel flerdimensionel repræsentation. En OLAP-model skal være multidimensionel i sin kerne. Et multidimensionelt konceptuelt diagram eller brugerdefineret repræsentation letter modellering og analyse samt beregninger.
Gennemsigtighed. Brugeren er i stand til at få alle de nødvendige data fra OLAP-motoren uden selv at vide, hvor de kommer fra. Uanset om OLAP-produktet er en del af brugerens værktøjer eller ej, bør dette faktum være usynligt for brugeren. Hvis OLAP leveres af klient-server computing, så bør denne kendsgerning også, hvis det er muligt, være usynlig for brugeren. OLAP skal leveres i ægte sammenhæng åben arkitektur, der giver brugeren mulighed for, uanset hvor han er, at kommunikere ved hjælp af et analytisk værktøj med serveren. Ud over dette bør der også opnås gennemsigtighed, når det analytiske værktøj interagerer med homogene og heterogene databasemiljøer.
Tilgængelighed. OLAP skal levere sin egen logisk kredsløb at få adgang til i et heterogent databasemiljø og udføre passende transformationer for at levere data til brugeren. Desuden er det nødvendigt på forhånd at være opmærksom på, hvor og hvordan, og hvilke typer fysisk organisering af data, der rent faktisk vil blive brugt. Et OLAP-system bør kun få adgang til de data, der faktisk er påkrævet, og ikke gælde generelt princip"køkkentragt", hvilket medfører unødvendige input.
Konstant ydeevne ved udarbejdelse af rapporter. Ydeevne evnen til at generere rapporter bør ikke falde væsentligt, efterhånden som antallet af dimensioner og databasestørrelsen øges.
Klient-server arkitektur. Det kræver, at produktet ikke kun er klient-server, men også at serverkomponenten er intelligent nok til at tillade forskellige klienter at forbinde med et minimum af indsats og programmering.
Generel multidimensionalitet. Alle dimensioner skal være ens, hver dimension skal være ens i både struktur og operationelle muligheder. Sandt nok, yderligere operationelle kapaciteter for individuelle dimensioner (formentlig er tid underforstået), men sådan yderligere funktionalitet skal leveres til enhver dimension. Det burde ikke være så grundlæggende datastrukturer, beregnings- eller rapporteringsformater var mere specifikke for én dimension.
Dynamisk kontrol sparsomme matricer. OLAP-systemer bør automatisk konfigurere deres fysisk diagram afhængig af modeltype, datamængder og databasesparhed.
Multi-user support. Et OLAP-værktøj skal give funktioner deling(forespørgsel og færdiggørelse), integritet og sikkerhed.
Ubegrænset krydsoperationer. Alle typer operationer skal være tilladt for alle målinger.
Intuitiv datamanipulation. Datamanipulation blev udført gennem direkte handlinger på celler i visningstilstand uden brug af menuer og flere operationer.
Fleksible rapporteringsmuligheder. Dimensioner skal placeres i rapporten, som brugeren har brug for det.
Ubegrænset

I dag blandt de værktøjer, der tilbydes af informationsteknologimarkedet til behandling og visualisering af data til adoption ledelsesbeslutninger OLTP- og OLAP-teknologier er bedst egnede. OLTP-teknologi er fokuseret på operationel databehandling, og den mere moderne OLAP-teknologi er fokuseret på interaktiv dataanalyse. Systemer, der er udviklet på basis af dem, gør det muligt at opnå en forståelse af de processer, der foregår på en ledelsesfacilitet gennem hurtig adgang til forskellige dataudsnit (repræsentationer af indholdet af databaser, organiseret for at afspejle forskellige aspekter af virksomhedens aktiviteter). Især at levere grafisk fremstilling data, er OLAP i stand til at lave behandlingsresultater data nemt for perception.

OLTP (Online Transaction Processing) - 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 den hurtigst mulige responstid fra systemet.

I moderne DBMS'er er transaktionsserialisering organiseret gennem en låsemekanisme, dvs. Under udførelsen af en transaktion låser DBMS databasen eller en del af den, som transaktionen har adgang til; låsen bibeholdes, indtil transaktionen er begået. Hvis i gang parallel bearbejdning Når en anden transaktion forsøger at få adgang til de låste data, suspenderes transaktionsbehandlingen og genoptages først, efter at transaktionen, der låste dataene, er fuldført, og låsen er frigivet. Jo mindre objektet, der blokeres, jo større effektivitet er databasen. En transaktion, der opdaterer data på tværs af flere netværksknuder, kaldes DISTRIBUTERT. Hvis en transaktion fungerer med en database placeret på én node, så kaldes den LOKAL. Fra brugerens synspunkt bør lokale og distribuerede transaktioner behandles på samme måde, dvs. DBMS'et skal organisere processen med at udføre transaktionsdistribution, så alle lokale transaktioner, der er inkluderet i det, synkroniseres på alle knudepunkter, der er påvirket af dem distribueret system. I dette tilfælde bør en distribueret transaktion kun begås, hvis alle dens konstituerende lokale transaktioner er begået, og hvis mindst en af de lokale transaktioner afbrydes, skal hele den distribuerede transaktion afbrydes. For at implementere disse krav i praksis bruger DBMS en to-trinsme.

1. Databaseserveren, der begår en distribueret transaktion, sender kommandoen "Forbered til commit" til alle netværksknuder, der er registreret til at udføre transaktioner. Hvis mindst én af serverne ikke svarer om parathed, så ruller den distribuerede databaseserver den lokale transaktion tilbage på alle noder.

2. Alle lokale DBMS'er er klar til committing, dvs. serveren behandler den distribuerede transaktion, afslutter begåelsen, sender en kommando for at begå transaktionen til alle lokale servere.

OLAP (eng. online analytical processing, analytical processing in real time) er en, herunder kompilering og dynamisk offentliggørelse af rapporter og dokumenter. Anvendes af analytikere til hurtig behandling komplekse forespørgsler til databasen. Tjener til udarbejdelse af forretningsrapporter om salg, marketing, ledelsesformål, den såkaldte. data mining - data mining (en metode til at analysere information i en database for at finde anomalier og tendenser uden at finde ud af det semantisk betydning optegnelser).

OLAP tager et øjebliksbillede af en relationsdatabase og strukturerer den ind i rumlig model for henvendelser. Den angivne behandlingstid for forespørgsler i OLAP er omkring 0,1 % af lignende forespørgsler i en relationsdatabase.

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. Ved tilføjelse af dimensioner til diagrammet vil antallet mulige muligheder når hurtigt op på titusinder af millioner 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".

Udfordringen ved at bruge OLAP er at oprette forespørgsler, vælge referencedata og udvikle et skema, hvorfor de fleste moderne OLAP-produkter leveres med et kæmpe beløb forudkonfigurerede forespørgsler. Et andet problem er i de underliggende data. De skal være fuldstændige og konsekvente

Det første produkt til at udføre OLAP-forespørgsler var Express (IRI). Imidlertid blev udtrykket OLAP selv opfundet af Edgar Codd, "faderen til relationelle databaser." Og Codds arbejde blev finansieret af Arbor, et firma, der havde udgivet sit eget OLAP-produkt, Essbase (senere købt af Hyperion, som blev opkøbt af Oracle i 2007) året før.

Andre velkendte OLAP-produkter omfatter Microsoft Analysis Services (tidligere OLAP Services, SQL del Server), Oracle OLAP Option, DB2 OLAP Server fra IBM (faktisk EssBase med tilføjelser fra IBM), SAP BW, SAS OLAP Server, produkter fra Brio, BusinessObjects, Cognos, MicroStrategy og andre producenter.

OLAP bruges mest i forretningsplanlægning og data warehouse-produkter.

OLAP bruger en multidimensionel visning af aggregerede data for at give hurtig adgang til strategisk information til dybdegående analyse. OLAP-applikationer skal have følgende grundlæggende egenskaber:

multidimensionel datarepræsentation;
støtte til komplekse beregninger;
korrekt overvejelse af tidsfaktoren.

Fordele ved OLAP:

øge produktiviteten for produktionspersonale og udviklere af applikationsprogram. Rettidig adgang til strategisk information.
giver brugerne tilstrækkelig mulighed for at foretage deres egne ændringer i skemaet.
OLAP-applikationer er afhængige af datavarehuse og OLTP-systemer til at levere ajourførte data og derved bevare kontrollen over integriteten af virksomhedsdata.
reducere belastningen på OLTP-systemer og datavarehuse.

OLAP	OLTP
Datavarehuset bør omfatte både interne virksomhedsdata og eksterne data	hovedkilden til information, der kommer ind i den operationelle database, er virksomhedens aktiviteter, og dataanalyse kræver inddragelse af eksterne informationskilder (f.eks. statistiske rapporter)
Mængden af analytiske databaser er mindst en størrelsesorden større end mængden af operationelle. For at udføre pålidelige analyser og prognoser i et datavarehus skal du have information om virksomhedens aktiviteter og markedsforhold over flere år	For hurtig behandling kræves data for de sidste par måneder
Datavarehuset skal indeholde ensartet præsenteret og konsistent information, der er så tæt som muligt på indholdet af operationelle databaser. En komponent er nødvendig for at udtrække og "rense" information fra forskellige kilder. I mange store virksomheder eksisterer flere operationelle informationssystemer med deres egne databaser samtidigt (af historiske årsager).	Operationelle databaser kan indeholde semantisk ækvivalente oplysninger præsenteret i forskellige formater med forskellige indikationer på tidspunktet for deres modtagelse, nogle gange endda modstridende
Sættet af forespørgsler til en analytisk database kan ikke forudsiges. Datavarehuse findes til at besvare ad hoc-forespørgsler fra analytikere. Du kan kun regne med, at forespørgsler ikke kommer for ofte og vil involvere store mængder information. Størrelsen af den analytiske database tilskynder til brug af forespørgsler med aggregater (sum, minimum, maksimum, gennemsnit osv.)	Databehandlingssystemer er skabt til at løse specifikke problemer. Information fra databasen udvælges hyppigt og i små portioner. Typisk kendes et sæt forespørgsler til en operationel database allerede under design
Når variabiliteten af analytiske databaser er lav (kun ved indlæsning af data), viser rækkefølgen af arrays, hurtigere indekseringsmetoder til masseprøvetagning og lagring af præ-aggregerede data at være rimelige	Databehandlingssystemer er i sagens natur meget variable, hvilket tages i betragtning i det anvendte DBMS (normaliseret databasestruktur, rækker gemt ude af drift, B-træer til indeksering, transaktioner)
Analytisk databaseinformation er så kritisk for en virksomhed, at der kræves større detaljeret beskyttelse (individuelle adgangsrettigheder til bestemte rækker og/eller kolonner i tabellen)	For databehandlingssystemer er informationsbeskyttelse på tabelniveau normalt tilstrækkelig.

Formålet med et OLTP-system er hurtigt at indsamle og de fleste optimal placering oplysninger i databasen, samt sikring af 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? russisk selskab 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 adoptionsordning er kritisk vigtige beslutninger har følgende væsentlige mangler:

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;
cyklussen skal gentages, hvis det er nødvendigt at præcisere dataene eller betragte dataene i en anden sammenhæng, samt hvis yderligere spørgsmål. Desuden skal denne langsomme cyklus gentages og som regel flere gange, mens der bruges endnu mere tid på dataanalyse;
på en negativ måde påvirker forskellen i sprog træning og aktivitetsområder for en specialist i Informationsteknologi og en leder. 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.

Den globale industri har længe været bekendt med dette problem, og i næsten 30 år har der været OLAP-teknologier, der er designet specifikt til at gøre det muligt for forretningsanalytikere at operere med akkumulerede data og deltage direkte i deres analyse. Sådanne analytiske systemer er det modsatte af OLTP-systemer i den forstand, at de eliminerer informationsredundans ("kollaps"-information). Samtidig er det åbenlyst, at det er redundansen af primær information, der bestemmer analysens effektivitet. DSS, der kombinerer disse teknologier, gør det muligt at løse hele linjen opgaver:

Analytiske opgaver: beregning af specificerede indikatorer og statistiske karakteristika for forretningsprocesser baseret på retrospektive oplysninger placeret i datavarehuse.
Datavisualisering: præsentation af al tilgængelig information i brugervenlig grafisk og tabelform.
Indhentning af ny viden: bestemmelse af forholdet og indbyrdes afhængighed af forretningsprocesser baseret på eksisterende information (test af statistiske hypoteser, klyngedannelse, finde associationer og tidsmæssige mønstre).
Simuleringsopgaver: matematisk modellering opførsel af komplekse systemer over en vilkårlig periode. Det er med andre ord opgaver relateret til behovet for at besvare spørgsmålet: "Hvad vil der ske, hvis...?"
Kontrolsyntese: bestemmelse af acceptable kontrolhandlinger, der sikrer opnåelse af et givent mål.
Optimeringsproblemer: integration af simulering, styring, optimering og statistiske metoder til modellering og prognose.

Virksomhedsledere bruger værktøjer OLAP-teknologier, selv uden særlig uddannelse, kan uafhængigt og hurtigt få al den information, der er nødvendig for at studere forretningsmønstre, og i de fleste tilfælde forskellige kombinationer og forretningsanalyse tværsnit. En forretningsanalytiker har mulighed for at se foran sig en liste over målinger og indikatorer for et forretningssystem. Med sådan enkel grænseflade en analytiker kan bygge alle rapporter, omarrangere målinger (f.eks. lave krydstabulatorer - overlejre en måling på en anden). Derudover får han mulighed for at lave sine egne funktioner ud fra eksisterende indikatorer, udfør en "hvad nu hvis"-analyse - opnå et resultat ved at specificere afhængigheden af enhver indikator for forretningsfunktioner eller en forretningsfunktion af indikatorer. I dette tilfælde overstiger det maksimale svar for enhver rapport ikke 5 sekunder.

For at løse problemer med dataanalyse og søge efter løsninger er det nødvendigt at akkumulere og opbevare tilstrækkeligt store mængder data. Databaser (DB'er) tjener disse formål.

For at lagre data i henhold til en domænemodel skal databasestrukturen svare så meget som muligt til denne model. Den første sådan struktur, der blev brugt i et DBMS, var en hierarkisk struktur, som dukkede op i begyndelsen af 60'erne af forrige århundrede.

Den hierarkiske struktur involverede lagring af data i form af en træstruktur.

Forsøger at forbedre hierarkisk struktur der var en netværksstruktur af databasen, som involverer at repræsentere datastrukturen i form af et netværk.

Relationelle databaser er de mest almindelige i dag. For at lagre denne type information foreslås det at anvende post-relationelle modeller i form af objektorienterede datalagringsstrukturer. Den generelle tilgang er at gemme enhver information som objekter. I dette tilfælde kan selve objekterne organiseres i en hierarkisk model. Desværre er denne tilgang, i modsætning til den relationelle struktur, som er afhængig af relationel algebra, er ikke formaliseret nok, hvilket ikke tillader, at det bliver brugt bredt i praksis.

I overensstemmelse med Codds regler skal DBMS sikre udførelsen af operationer på databasen, samtidig med at den giver mulighed for samtidig arbejde til flere brugere (fra flere computere) og sikring af dataintegritet. For at implementere disse regler bruger DBMS en transaktionsstyringsmekanisme.

En transaktion er en sekvens af operationer på en database, betragtet af DBMS som en enkelt helhed. En transaktion flytter databasen fra en integreret tilstand til en anden.

Som regel består en transaktion af operationer, der manipulerer data tilhørende forskellige borde og logisk relateret til hinanden. Hvis der, når en transaktion udføres, udføres operationer, der kun ændrer en del af dataene, og de resterende data ikke ændres, vil integriteten blive krænket. Derfor skal enten alle operationer, der indgår i en transaktion, gennemføres, eller ingen af dem skal gennemføres. Processen med at fortryde en transaktion kaldes tilbagerulning af transaktioner. At gemme ændringer foretaget som følge af transaktionsoperationer kaldes at begå en transaktion.

En transaktions egenskab til at overføre en database fra en integreret tilstand til en anden giver os mulighed for at bruge begrebet en transaktion som en enhed af brugeraktivitet. I tilfælde af samtidige brugere, der får adgang til databasen, igangsatte transaktioner af forskellige brugere, udføres ikke parallelt (hvilket er umuligt for én database), men i overensstemmelse med en plan, sættes i kø og udføres sekventielt. For den bruger, på hvis initiativ transaktionen blev oprettet, vil tilstedeværelsen af transaktioner fra andre brugere således være usynlige, bortset fra en vis nedgang i driften sammenlignet med enkeltbrugertilstanden.

Der er flere grundlæggende algoritmer til planlægning af transaktioner. I centraliserede DBMS'er er de mest almindelige algoritmer dem, der er baseret på synkronisering af indfangning af databaseobjekter.

Når du bruger en hvilken som helst algoritme, er situationer med konflikter mellem to eller flere transaktioner for at få adgang til databaseobjekter mulige. I dette tilfælde skal en eller flere transaktioner rulles tilbage for at opretholde planen. Dette er et af tilfældene, hvor en bruger af et multi-user DBMS faktisk kan mærke tilstedeværelsen af andre brugeres transaktioner i systemet.

Historien om DBMS-udvikling er tæt forbundet med forbedringen af tilgange til løsning af problemer med datalagring og transaktionsstyring. Den udviklede transaktionsstyringsmekanisme i moderne DBMS'er har gjort dem til det vigtigste middel til at bygge OLTP-systemer, hvis hovedopgave er at sikre udførelsen af databaseoperationer.

3.1.3. Bruger OLTP-teknologi
i beslutningsstøttesystemer

OLTP online transaktionsbehandlingssystemer er kendetegnet ved stort beløbændringer, mange brugeres samtidige adgang til de samme data for at udføre forskellige operationer - læsning, skrivning, sletning eller ændring af data. Låse og transaktioner bruges til at sikre normal drift af flere brugere. Effektiv forarbejdning transaktioner og støtte til låsning er blandt de vigtigste krav til online transaktionsbehandlingssystemer.

Den første DSS tilhører i øvrigt også denne klasse af systemer − Informationssystemer Manualer. Sådanne systemer er normalt bygget på basis relationel DBMS, omfatter delsystemer til indsamling, lagring og informationssøgningsanalyse af information og indeholder også et foruddefineret sæt forespørgsler til daglig arbejde. Hver ny anmodning, uforudset ved design af et sådant system, skal først formelt beskrives, kodes af programmøren og først derefter udføres. Ventetiden i dette tilfælde kan være timer og dage, hvilket er uacceptabelt for hurtig beslutningstagning.

Praksis med at bruge OLTP-systemer har vist ineffektiviteten af deres brug til omfattende informationsanalyse. Sådanne systemer løser ganske vellykket problemerne med at indsamle, lagre og hente information, men de opfylder ikke kravene til moderne DSS. Tilgange til at øge funktionaliteten af OLTP-systemer har ikke givet tilfredsstillende resultater. Hovedårsagen til fejlen er de modstridende krav til OLTP- og DSS-systemer.

De vigtigste krav til OLTP- og DSS-systemer er følgende:

1. Detaljeringsgrad af de lagrede data. En typisk forespørgsel i et OLTP-system har en tendens til selektivt at påvirke individuelle poster i tabeller, som effektivt hentes ved hjælp af indekser.

2. Datakvalitet. OLTP-systemer gemmer som regel information indtastet direkte af systembrugere (computeroperatører). Tilstedeværelse" menneskelig faktor" når du indtaster øger sandsynligheden for fejlagtige data og kan skabe lokale problemer i system.

3. Datalagringsformat. OLTP-systemer, der betjener forskellige arbejdsområder, er ikke indbyrdes forbundne. De implementeres ofte på forskellige software- og hardwareplatforme. De samme data i forskellige databaser kan repræsenteres i i forskellige former og matcher muligvis ikke (f.eks. matcher data om en klient, der interagerede med forskellige afdelinger i virksomheden, muligvis ikke i disse afdelingers databaser).

4. Tillad redundante data. Strukturen af databasen, der betjener et OLTP-system, er normalt ret kompleks. Det kan indeholde mange snesevis eller endda hundredvis af tabeller, der refererer til hinanden. Dataene i en sådan database er meget normaliseret for at optimere de ressourcer, det tager. Analytiske forespørgsler til databasen er meget vanskelige at formulere og er ekstremt ineffektive at udføre, da de indeholder visninger, der kombinerer et stort antal tabeller.

5. Datahåndtering. Hovedkravet til OLTP-systemer er at sikre, at ændringshandlinger udføres på databasen. Det forudsættes, at de skal udføres i ægte tilstand, og ofte meget intenst.

6. Mængde af lagrede data. Som regel er analysesystemer designet til at analysere tidsafhængigheder, mens OLTP-systemer normalt håndterer de aktuelle værdier af nogle parametre.

7. Karakteren af dataforespørgsler. I OLTP-systemer er det på grund af databasenormalisering ret komplekst arbejde at skrive forespørgsler og kræver de nødvendige kvalifikationer.

8. Behandlingstid for dataanmodninger. OLTP-systemer fungerer typisk i realtid, så de har strenge krav til databehandling.

9. Arten af computerbelastningen på systemet. Som tidligere nævnt udføres arbejde med OLTP-systemer normalt i realtid.

10. Prioritet af systemkarakteristika. For OLTP-systemer prioriteres høj ydeevne og datatilgængelighed, da de arbejder med dem i realtid. For analysesystemer er de højere prioriterede opgaver at sikre systemfleksibilitet og brugeruafhængighed, det vil sige hvad analytikere skal bruge for at analysere data.

Det skal bemærkes, at de modstridende krav til OLTP-systemer og systemer fokuseret på dyb analyse af information komplicerer opgaven med at integrere dem som undersystemer af en enkelt DSS. I øjeblikket er den mest populære løsning på dette problem en data warehousing tilgang.

Generel idé datavarehuse består i at adskille databasen for − systemer og databasen til udførelse af analyser og derefter designe dem under hensyntagen til de tilsvarende krav.

DSS løser tre hovedopgaver: indsamling, opbevaring og analyse af lagret information. Analyseopgaven i generel opfattelse kan omfatte: informationssøgningsanalyse, operationel analytisk analyse og prædiktiv analyse.

Undersystemer til indsamling, lagring af information og løsning af problemer med informationssøgningsanalyse implementeres i øjeblikket med succes inden for rammerne af informationssøgningsanalysesystemer ved hjælp af DBMS. For at implementere undersystemer, der udfører operationel analytisk analyse, bruges begrebet multidimensionel datarepræsentation. Data mining-undersystemet implementerer metoderne.

For at forenkle udviklingen af applikationsprogrammer ved hjælp af databaser, oprettes databasestyringssystemer (DBMS) − software til datahåndtering, opbevaring og datasikkerhed.

DBMS'er har en udviklet transaktionsstyringsmekanisme, som har gjort dem til det vigtigste middel til at skabe online transaktionsbehandlingssystemer (OLTP-systemer). Sådanne systemer omfatter den første DSS, problemløsning informationssøgningsanalyse - ISR.

OLTP-systemer kan ikke effektivt bruges til at løse problemer med operationel analytisk og intellektuel informationsanalyse. Hovedårsagen er de modstridende krav til OLTP-systemet og DSS.

I øjeblikket, for at øge effektiviteten af operationel analytisk og intellektuel analyse, bruges begrebet datavarehuse til at kombinere OLTP-undersystemer og analyseundersystemer inden for et system. Den generelle idé er at allokere en database til OLTP-undersystemer og en database til at udføre analyse. Dette sikrer en optimal tilgang til databehandling i beslutningsstøttesystemer.

Spørgsmål til selvkontrol

1. Angiv de vigtigste opgaver, som beslutningsstøttesystemer løser.

2. Skitsere de konceptuelle retninger for opbygning af datavarehuse i beslutningsstøttesystemer.

3. Angiv typerne af strukturer til organisering af datavarehuse i DSS. Hvad er fordelene og ulemperne ved hver type struktur?

4. Begrund gennemførligheden af at bruge den post-relationelle model for delsystemet til indsamling og behandling af information i DSS.

5. Hvordan fortolkes begrebet transaktion i databehandlingssystemer?

6. Hvad er hovedegenskaben ved en transaktion i databehandlingssystemer?

7. Beskriv kort mekanismen til styring af transaktioner i OLTP-systemer.

8. Angiv rollen og stedet for OLTP-systemer til onlinetransaktionsbehandling. Hvorfor er OLTP-systemer ineffektive til at løse operationelle analytiske og forudsigelige analyseproblemer?

9. Hvad er de grundlæggende krav til OLTP-systemer. Hvad er de modstridende krav til OLTP-systemer?

10. Nævn måder at øge effektiviteten af operationel analytisk og intellektuel analyse i DSS.

I forrige underafsnit blev det bemærket, at for en tilstrækkelig repræsentation af emneområdet, let udvikling og vedligeholdelse af databasen, skal relationerne reduceres til den tredje normalform (der er former for normalisering af højere ordener, men i praksis de bruges ret sjældent), dvs. være stærkt normaliserede. Samtidig har svagt normaliserede relationer også deres fordele, hvoraf den vigtigste er, at hvis databasen hovedsagelig kun tilgås med forespørgsler, og ændringer og tilføjelser af data udføres meget sjældent, så er deres sampling meget hurtigere. Dette forklares ved, at i svagt normaliserede forhold er deres forbindelse allerede oprettet, og processortid er ikke spildt på dette. Der er to klasser af systemer, for hvilke stærkt og svagt normaliserede relationer er mere egnede.

Meget normaliserede datamodeller er velegnede til OLTP-applikationer − On-line transaktionsbehandling (OLTP) – applikationer til online transaktionsbehandling. Typiske eksempler på OLTP-applikationer er systemer lagerregnskab͵ billetbestillinger, operationelle banksystemer og andre. Hovedfunktion lignende systemer er at udføre stor mængde korte transaktioner. Selve transaktionerne er ret simple, men problemerne er, at der er mange sådanne transaktioner, de udføres samtidigt, og hvis der opstår fejl, skal transaktionen rulles tilbage og returnere systemet til den tilstand, det var i før transaktionen begyndte . Næsten alle databaseforespørgsler i OLTP-applikationer består af indsæt-, opdaterings- og sletkommandoer. Udvælgelsesforespørgsler er hovedsageligt beregnet til at give brugerne et udvalg af data fra forskellige typer mapper. De fleste af anmodningerne er dog kendt på forhånd på systemdesignstadiet. Kritisk for OLTP-applikationer er hastigheden og pålideligheden af korte dataopdateringsoperationer. Jo højere niveauet af datanormalisering i OLTP-applikationer, jo hurtigere og mere pålideligt er det. Afvigelser fra denne regel kan forekomme, når der allerede på udviklingsstadiet kendes nogle hyppigt forekommende anmodninger, der kræver forbindelsesrelationer, og driften af applikationer afhænger væsentligt af hastigheden af disses udførelse.

En anden type applikation er OLAP applikationer − On-line analytisk behandling (OLAP) – applikationer til online analytisk databehandling. Dette er en generaliseret term, der karakteriserer principperne for opbygning af beslutningsstøttesystemer - Decision Support System (DSS), datavarehuse - Data Warehouse, data mining-systemer - Data Mining. Sådanne systemer er designet til at finde afhængigheder mellem data, til at udføre dynamiske analyser baseret på "hvad nu hvis..." princippet og lignende opgaver. OLAP-applikationer fungerer med store mængder data akkumuleret i virksomheden eller hentet fra andre kilder. Sådanne systemer er kendetegnet ved følgende funktioner:

Nye data tilføjes systemet relativt sjældent i store blokke, for eksempel en gang om måneden eller kvartalet;

Data tilføjet til systemet slettes normalt aldrig;

Før indlæsning gennemgår data forskellige forberedende procedurer i forbindelse med at bringe dem til bestemte formater;

Forespørgsler til systemet er uregulerede og ret komplekse;

Hastigheden på udførelse af forespørgsler er vigtig, men ikke kritisk.

Baser OLAP-data-applikationer præsenteres normalt i form af en eller flere hyperkuber, hvis dimensioner repræsenterer referencedata, og cellerne i selve hyperkuben gemmer værdierne af disse data. Fysisk kan en hyperkube bygges ud fra en speciel multidimensionel model data - Multidimensionel OLAP (MOLAP) eller repræsenteret ved hjælp af en relationel datamodel - Relationel OLAP (ROLAP).

I OLAP systemer ved brug af relationel model data, er det tilrådeligt at gemme data i form af svagt normaliserede relationer indeholdende forudberegnede grundtotaler. Dataredundans og relaterede problemer er ikke et problem her, da de opdateres ret sjældent, og sammen med dataopdateringen genberegnes resultaterne.

- Måder at sikre pålideligheden af vandforsyningssystemet

Sikring af pålideligheden af vandforsyningssystemet såvel som andre systemer stå i kø, er en af hovedopgaverne i deres design. Systemet skal designes og bygges, så det under drift udfører sine funktioner med en given... [læs mere]

- I. Sikkerhedskoncept for beskyttelsessystemet

Sikkerhedskonceptet for det system, der udvikles, er "et sæt love, regler og adfærdsnormer, der bestemmer, hvordan en organisation behandler, beskytter og formidler information. Særligt reglerne bestemmer, i hvilke tilfælde brugeren har ret til at operere med... [læs mere]

- Efter at have taget de vigtigste beslutninger om design af varmesystemet

DESIGNERING AF ET VANDVARMESYSTEM TIL EN BYGNING Tegn diagrammer over termiske enheder ved tilslutning af et varmesystem med åbne og lukkede kredsløb. Spørgsmål til selvtest Ved tilførsel af varme til flere bygninger. Pumper og andet udstyr er installeret... [læs mere]

- Krav til sikring af brandsikkerheden af det brandforebyggende system.

Grundlæggende om at sikre brandsikkerhed af teknologiske processer. Spørgsmål 2. Brandforebyggelse af et anlæg (25 min.) Brandforebyggelse omfatter et sæt organisatoriske og tekniske foranstaltninger, der har til formål at sikre menneskers sikkerhed... [læs mere]

- Dyrevæv og organsystemer

Dyrevæv. Dyr har også flere typer væv. De vigtigste af dem er følgende. Epitelvæv er grænsevæv, der dækker kroppen udefra og beklæder de indre hulrum og organer, der udgør leveren, lungerne, kirtlerne... [læs mere]

Genomerne af højere eukaryoter indeholder adskillige gentagne DNA-sekvenser. Hos mennesker optager sådanne gentagelser for eksempel mere end 40 % af hele genomet. Og det følger, at når DSB'er dannes, er sandsynligheden for samtidig dannelse af flere brud langs ... [læs mere]

- Bestemmelse af blodgrupper i ABO-systemet ved hjælp af anti-A, anti-B og anti-AB cykloner

BESTEMMELSE AF BLODGRUPPER Ifølge denne regel kan alle patienter transfunderes med blod fra O(1)-gruppen, da det ikke indeholder agglutinogener, og modtagere af gruppe AB(1U) kan transfunderes med blod fra andre grupper, da det gør. indeholder ikke agglutinogener. Det er her, begreberne introduceres...