Hem / Problem/ Företagsdatamodellen innehåller element. Relationsdatamodell

Företagsdatamodellen innehåller element. Relationsdatamodell

Den här artikeln kommer att fokusera på datalagerarkitektur. Vad bör vägledas av när man bygger det, vilket närmar sig arbete – och varför.

"Sagan är en lögn - men det finns en antydan i den ..."

Farfar planterade ... förråd. Och förrådet har växt, jättefint. Men jag visste inte riktigt hur det fungerade. Och farfar startade en recension. Farfar kallade farmor, barnbarn, katt och mus till familjerådet. Och han säger följande: ”Vårt lager har växt. Data från alla system flyter ner, tabeller är synliga och osynliga. Användare skapar sina rapporter. Allt verkar vara bra – att leva och leva. Ja, bara en sorg - ingen vet hur det fungerar. Kräver diskar uppenbarligen-osynligt - du kommer inte att räcka! Och sedan fick användarna för vana att komma till mig med olika klagomål: antingen fryser rapporten, då är uppgifterna inaktuella. Och sedan är det ganska katastrof - vi kommer med rapporter till tsarfadern, men siffrorna stämmer inte överens med varandra. Timmen är inte jämn - kungen är arg - ta då inte av huvudet - varken för mig eller för dig. Så jag bestämde mig för att samla er och rådgöra: vad ska vi göra?"

Han kastade blicken över mötet och frågade:
– Du, mormor, vet du hur vårt förråd är ordnat?
– Nej, farfar, jag vet inte. Och hur skulle jag veta det? Där borta, vilka modiga killar som vaktar honom! Några av dem! Du kommer inte att närma dig. Jag gick för att se dem på något sätt, bakade pajer. Och de åt pajerna, torkade sin mustasch och sa: ”Varför kom du, mormor? Vilken typ av förvaring är du? Du berättar för mig vilken typ av rapport du behöver - vi gör det åt dig! Du borde ta med pajerna oftare! Smärtsamt är de läckra."
– Och du, älskade barnbarn, vet du hur vårt förråd är ordnat?
– Nej, morfar, jag vet inte. De gav mig tillgång till det på något sätt. Jag kopplade upp, jag tittar - och det finns bord - tydligen-osynligt. Och olika scheman är dolda. Ögonen springer upp.... Först var jag förvirrad. Och så tittade jag noga - några av dem är tomma, andra är fyllda, men bara hälften. Och uppgifterna verkar upprepas. Det är inte konstigt att du inte kommer att få nog av diskar, med sådan redundans!
– Jaha, du, katt, vad säger du om vårt förråd? Finns det något bra med det?
– Men hur ska man inte säga det, farfar – det ska jag. På mitt barnbarns begäran försökte jag göra en pilot i en separat krets - ett litet skyltfönster. För att förstå vilken typ av handel som är lönsam för vår stat - vilka produkter är bra för köpmän, de hyllar - de fyller på statskassan. Och vilka som är väldigt dåliga. Och jag började välja data för mig själv från det här förrådet. Samlade fakta. Och han började försöka jämföra dem med produkter. Och vad, farfar, jag såg - produkterna verkar vara desamma, men du tittar på tallrikarna - de är olika! Sedan började jag kamma dem med mitt barnbarns kam. Chesal-repade - och ledde till en viss enhetlighet, smekte ögonen. Men tidigt gladde jag mig – dagen efter lanserade jag mina skript för att uppdatera den underbara datan i fönstret – och allt var borta för mig! "Hur så?" – Jag tror – barnbarnet blir upprört – i dag skulle det bli nödvändigt att visa vår pilot för ministern. Hur kan vi gå med sådana uppgifter?
– Ja, sorgliga sagor, katt, berättar du. Tja, du, lilla mus, försökte verkligen inte ta reda på lagringen? Du är en pigg, pigg, sällskaplig tjej hos oss! Vad ska du berätta för oss?
– Ja, hur, farfar, försök inte – visst, jag är en tyst mus, men kvick. En gång bad kattens barnbarn mig att få datamodellen för vår statliga lagring. Och katten kom förstås till mig - för dig, säger han, musen, allt hopp! Tja, vad är en god gärning för goda människor (och katter) att inte göra? Jag gick till slottet, där chefen för lagret gömmer datamodellen i kassaskåpet. Och hon gömde sig. Jag väntade på att han skulle ta den modellen ur kassaskåpet. Så fort han gick ut och fikade hoppade jag upp på bordet. Jag tittar på modellen - jag kan inte förstå någonting! Hur så? Jag känner inte igen vårt lager! Vi har otaliga tusentals tabeller, dataströmmar är oslagbara! Och här - allt är harmoniskt och vackert ... Han tittade på just denna modell - och lade tillbaka den i kassaskåpet.
– Ja, mycket konstiga saker, sa du till oss, mus.
Farfar tänkte hårt.
- Vad ska vi göra, mina vänner? När allt kommer omkring, med ett sådant och ett sådant förråd kommer du inte att leva länge ... Användare kommer snart att förlora sitt tålamod.

Oavsett vad vår farfar bestämde från en saga - att bygga en ny förvaringsanläggning eller att försöka återuppliva en befintlig - är det nödvändigt att dra slutsatser innan vi "kavlar upp ärmarna" igen.
Låt oss lägga de organisatoriska aspekterna åt sidan - såsom faran med att koncentrera expertis i en viss snäv sluten grupp, bristen på kontrollprocesser och säkerställa transparensen i arkitekturen för de system som används i företaget, etc.
Idag skulle jag vilja fokusera på att bygga arkitekturen för ett specifikt system (eller grupp av system) - datalager. Det som måste hållas i fokus först och främst, när organisationen börjar bygga ett så komplext och dyrt system som ett lager.

Debriefing

Ingen av oss, som arbetar med att skapa och utveckla något system, vill inte att detta ska vara ett "tillfälligt hus", eller en lösning som kommer att "visna bort" om ett eller två år, eftersom kommer inte att kunna uppfylla kundernas och företagens krav och förväntningar. Oavsett hur stark fördomen mot "flexibla metoder" observeras idag, är det mycket trevligare för en person att känna sig som en "mästare" som gör fioler än en hantverkare som hyvlar pinnar för engångstrummor.
Vår avsikt låter naturlig: att göra system som är solida och av hög kvalitet, som inte kommer att kräva att vi har regelbundna "nattvakor med fil", som vi inte kommer att skämmas för inför slutanvändare och som inte kommer att se ut som en "svart låda" för alla "oinitierade" följare.

Till att börja med, låt oss slänga in en lista över typiska problem som vi regelbundet stöter på när vi arbetar med repositories. Låt oss bara skriva ner vad vi har – än så länge utan att försöka effektivisera och formalisera.

I princip har vi en bra förvaring: rör du inte vid den så fungerar allt. Men så fort en förändring krävs börjar "lokala kollapser".
Data laddas upp dagligen, enligt bestämmelserna, inom en stor process, inom 8 timmar. Och det passar oss. Men om ett fel plötsligt inträffar kräver det manuellt ingripande. Och då kan allt fungera oförutsägbart under lång tid, tk. kommer att kräva mänskligt deltagande i processen.
Har rullat upp releasen - räkna med problem.
Någon källa kunde inte skicka data i tid - alla processer väntar.
Dataintegriteten styrs av databasen - så våra processer kraschar när den går sönder.
Vi har ett mycket stort lager - 2000 tabeller i ett gemensamt schema. Och 3000 till i många andra system. Vi har redan en liten aning om hur de är ordnade och av vilken anledning de dök upp. Därför kan det vara svårt för oss att återanvända något. Och många uppgifter måste lösas på nytt. För det här är enklare och snabbare (än att förstå "någon annans kod"). Som ett resultat har vi avvikelser och duplicerad funktionalitet.
Vi förväntar oss att källan tillhandahåller data av god kvalitet. Men det visar sig att så inte är fallet. Som ett resultat av detta lägger vi mycket tid på att stämma av våra slutrapporter. Och de var mycket framgångsrika i detta. Vi har till och med en strömlinjeformad process. Det är sant att det tar tid. Men användarna är vana vid att...
Användaren litar inte alltid på våra rapporter och kräver en motivering av en eller annan siffra. I vissa fall har han rätt, och i andra inte. Men det är mycket svårt för oss att motivera dem, eftersom vi har inga medel för "end-to-end-analys" (eller datalinje).
Vi skulle kunna ta in ytterligare utvecklare. Men vi har ett problem – hur tar vi med dem i arbetet? Vad är det effektivaste sättet att parallellisera jobb?
Hur utvecklar man systemet gradvis, utan att gå in i utvecklingen av "systemets kärna" under ett helt år?
Datalagret är associerat med företagsmodellen. Men vi vet med säkerhet (vi såg det i banken XYZ) att att bygga en modell kan vara oändligt lång (vi gick till banken XYZ i sex månader och diskuterade affärsenheter, utan någon rörelse). Varför är hon det överhuvudtaget? Eller det kanske är bättre utan henne, om det är så mycket problem med henne? Kanske kan vi skapa det på något sätt?
Vi bestämde oss för att köra modellen. Men hur utvecklar du systematiskt din lagerdatamodell? Behöver vi "spelregler" och vad kan de vara? Vad kommer det att ge oss? Vad händer om vi har fel på modellen?
Ska vi spara data, eller historiken för dess ändringar, om "företaget inte behöver det"? Jag skulle inte vilja "lagra skräp" och komplicera användningen av denna data för riktiga uppgifter. Ska valvet hålla historia? Hur är det? Hur fungerar lagring över tid?
Ska vi försöka förena data på lagret om vi har ett masterdatahanteringssystem? Om det finns MDM, betyder det att hela problemet med masterdata nu är löst?
Vi förväntas byta ut viktiga redovisningssystem inom kort. Behöver datalagret vara redo att byta källa? Hur kan detta uppnås?
Behöver vi metadata? Vad menar vi med detta? Var exakt kan de användas? Hur kan du implementera det? Behöver jag förvara dem "på ett ställe"?
Våra kunder är extremt instabila i sina krav och önskemål – något förändras hela tiden. Generellt sett är vår verksamhet väldigt dynamisk. Medan vi gör något blir det redan onödigt. Hur kan vi göra det på ett sådant sätt att vi ger resultatet så snabbt som möjligt - som smör?
Användare kräver lyhördhet. Men vi kan inte köra våra huvudstartprocesser ofta, eftersom detta laddar källsystemen (har en dålig effekt på prestandan) - därför hänger vi upp ytterligare dataströmmar - som kommer att plocka upp punktvis - det vi behöver. Det är sant att det finns många strömmar. Och sedan kommer vi att kasta ut en del av datan. Dessutom kommer det att finnas ett konvergensproblem. Men det finns inget annat sätt...

Det har redan hänt en hel del. Men det här är inte en komplett lista – det är lätt att komplettera och utveckla den. Vi kommer inte att gömma det i bordet, utan hänga det på en iögonfallande plats - hålla dessa frågor i fokus för vår uppmärksamhet under arbetets gång.
Vår uppgift är att ta fram en helhetslösning som ett resultat.

Antibräcklighet

Om man tittar på vår lista kan man dra en slutsats. Det är inte svårt att skapa en sorts "rapporteringsdatabas", att ladda upp data dit, eller till och med bygga upp någon form av rutinmässiga datauppdateringsprocesser. Systemet börjar på något sätt leva, användare dyker upp och med dem skyldigheter och SLA uppstår nya krav, ytterligare källor ansluts, metoder förändras - allt detta måste tas med i beräkningen i utvecklingsprocessen.

Efter ett tag ser bilden ut som följer:
"Här är valvet. Och det fungerar om du inte rör det. Problem uppstår när vi måste ändra något."

En förändring kommer till oss, vars inflytande vi inte kan bedöma och förstå (eftersom vi inte lade in sådana verktyg i systemet från allra första början) - och för att inte riskera det, rör vi inte vad som är, men vi gör en förlängning till vid sidan av, och en annan, och även - förvandlar vårt beslut till slumkvarter, eller, som man säger i Latinamerika, "favelas", där till och med polisen är rädd för att komma in.
Det finns en känsla av förlust av kontroll över det egna systemet, kaos. Det krävs fler och fler händer för att underhålla befintliga processer och lösa problem. Och det blir svårare och svårare att göra förändringar. Systemet blir med andra ord instabilt för stress, missanpassat till förändringar. Och dessutom är det ett starkt beroende av karaktärer som "kan fairway", eftersom ingen har en "karta".

Denna egenskap hos ett objekt - att kollapsa under påverkan av kaos, slumpmässiga händelser och chocker - kallar Nassim Nicholas Taleb bräcklighet ... Och introducerar också det motsatta konceptet: antibräcklighet – när föremålet inte kollapsar av stress och olyckor, utan direkt drar nytta av det... ("Antifragility. Hur man drar nytta av kaoset")
Annars kan det kallas anpassningsförmåga eller motståndskraft mot förändring .

Vad betyder detta i detta sammanhang? Vilka är "källorna till kaos" för IT-system? Och vad innebär det att "kapitalisera på kaos" när det gäller IT-arkitektur?
Den första tanken som kommer att tänka på är förändringar som kommer utifrån. Vad är omvärlden för systemet? För förvaring i synnerhet. Naturligtvis, först av allt - ändringar från sidan av datakällor för butiken:

ändra formaten för inkommande data;
ersättning av vissa datakällsystem med andra;
förändring av regler / plattformar för systemintegration;
ändra tolkningen av data (format sparas, logiken i att arbeta med dataändringar);
ändra datamodellen om integrationen görs på datanivån (analys av databastransaktionsloggfilerna);
tillväxt i datavolymer - medan det inte fanns mycket data i källsystemet, och belastningen inte var hög - det var möjligt att hämta det när som helst, med en godtyckligt tung begäran ökade data och belastning - nu finns det strikta restriktioner ;
etc.

Själva källsystemen, sammansättningen av information och dess struktur, typen av integrationsinteraktion, liksom själva logiken i att arbeta med data kan förändras. Varje system implementerar sin egen datamodell och tillvägagångssätt för att arbeta med dem, som uppfyller systemets mål och mål. Och oavsett hur hårt de försöker förena industrimodeller och referenspraxis, kommer nyanser oundvikligen att uppstå. (Och dessutom gör själva processen för industriens enande, av olika anledningar, inga stora framsteg.)
Kulturen att arbeta med företagsdata - närvaron och kontrollen av informationsarkitektur, en enhetlig semantisk modell, masterdatahanteringssystem (MDM) underlättar något uppgiften att konsolidera data i lagret, men utesluter inte dess behov.

Inte mindre kritiska förändringar initieras av lagerkonsumenterna (kraven ändras):

tidigare fanns det tillräckligt med data för att skapa en rapport - nu krävdes det att ansluta ytterligare fält eller en ny datakälla;
de tidigare implementerade databehandlingsmetoderna är föråldrade - du måste omarbeta algoritmerna och allt som påverkar det;
Tidigare var alla nöjda med det aktuella värdet av ordboksattributet på informationspanelen - nu krävs det värde som är relevant vid tidpunkten för det analyserade faktumet/händelsen;
det fanns ett krav på djupet av datalagringshistoriken, som inte fanns tidigare - att lagra data inte i 2 år, utan i 10 år;
tidigare fanns det tillräckligt med data från "slutet av dagen / perioden" - nu behöver du datatillståndet "inom dagen", eller vid tidpunkten för en viss händelse (till exempel fatta beslut om en låneansökan - för Basel II);
tidigare var vi nöjda med att rapportera om data för gårdagen (T-1) eller senare, nu behöver vi T0;
etc.

Både integrationsinteraktionerna med källsystemen och kraven från konsumenterna av lagerdata är externa faktorer för datalagret: vissa källsystem ersätter andra, datavolymerna växer, formaten för inkommande data ändras, användarkraven ändras, etc. Och alla dessa är typiska externa förändringar som vårt system - vårt förråd - måste vara redo för. Med rätt arkitektur borde de inte döda systemet.

Men det är inte allt.
På tal om variabilitet kommer vi först och främst ihåg externa faktorer. Inuti kan vi ju kontrollera allt, det tror vi väl? Ja och nej. Ja, de flesta faktorer som ligger utanför påverkanszonen är externa. Men det finns också "intern entropi". Och just på grund av dess närvaro behöver vi ibland återgå "till punkt 0". Starta om spelet.
I livet brukar vi ofta börja om från början. Varför är detta speciellt för oss? Och är det verkligen så illa?
Tillämpas på IT. För systemet i sig - det kan vara mycket bra - förmågan att tänka om enskilda beslut. Speciellt när vi kan göra det lokalt. Refaktorering är processen att nysta upp den "webb" som regelbundet dyker upp under systemutvecklingsprocessen. Att gå tillbaka till början kan vara till hjälp. Men det har ett pris.
Med korrekt arkitekturhantering sjunker detta pris – och själva systemutvecklingsprocessen blir mer kontrollerbar och transparent. Ett enkelt exempel: om principen om modularitet iakttas kan du skriva om en separat modul utan att påverka de externa gränssnitten. Och detta kan inte göras med en monolitisk struktur.

Anti-bräckligheten av ett system bestäms av arkitekturen som är inbäddad i det. Och det är denna egenskap som gör den adaptiv.
När vi pratar om adaptiv arkitektur– vi menar att systemet kan anpassa sig till förändringar, och inte alls att vi hela tiden förändrar själva arkitekturen. Tvärtom, ju mer stabil och stabil arkitekturen är, desto färre krav som medför revidering, desto mer adaptivt är systemet.

Lösningar som innebär en revidering av hela arkitekturen kommer att ha ett mycket högre pris. Och du måste ha mycket goda skäl för deras adoption. Till exempel kan en sådan motivering vara ett krav som inte kan implementeras inom den befintliga arkitekturen. Då säger man – det finns ett krav som påverkar arkitekturen.
Därför måste vi också känna till våra "gränser för antibräcklighet". Arkitektur utvecklas inte "i ett vakuum" - den är baserad på nuvarande krav och förväntningar. Och om situationen förändras i grunden - vi måste förstå att vi har gått bortom den nuvarande arkitekturen - och vi måste revidera den, utarbeta en annan lösning - och tänka över övergångsvägarna.
Till exempel antog vi att vi alltid kommer att behöva data i lagringen i slutet av dagen, vi kommer att ta data varje dag med standardsystemgränssnitt (genom en uppsättning vyer). Då fick riskhanteringsenheten krav på behovet av att ta emot uppgifter inte i slutet av dagen, utan vid tidpunkten för beslut om utlåning. Du behöver inte försöka "dra det icke-sträckta" - du behöver bara erkänna detta faktum - ju förr desto bättre. Och börja arbeta med ett tillvägagångssätt som gör att vi kan lösa problemet.
En mycket fin linje uppstår här - om vi bara tar hänsyn till "kraven i nuet" och inte ser flera steg framåt (och flera år framåt), så ökar vi risken att möta ett krav som påverkar arkitekturen för sent - och priset på vår förändring kommer att bli mycket högt. Att se lite framåt – inom gränserna för vår horisont – har ännu inte skadat någon.

Exemplet med ett system från "lagringssagan" är bara ett exempel på ett mycket skakigt system byggt på bräckliga designmetoder. Och om detta händer sker förstörelse ganska snabbt, för just denna klass av system.
Varför kan jag säga så? Ämnet arkiv är inte nytt. De tillvägagångssätt och ingenjörspraxis som har utvecklats under denna tid syftade till just detta - att upprätthålla systemets livskraft.
Ett enkelt exempel: En av de vanligaste orsakerna till misslyckande med startlagringsprojekt är att försöka bygga lagring över utvecklingskällsystem utan att komma överens om integrationsgränssnitt – att försöka hämta data direkt från tabeller. Som ett resultat gick vi in i utvecklingen - under denna tid ändrades källdatabasen - och laddningsströmmarna i förvaret blev inoperativa. Det är för sent att göra om något. Och har du ännu inte säkrat dig genom att göra flera lager med bord inne i förrådet, då kan du slänga ut allt och börja om. Detta är bara ett exempel, och ett av de enkla.

Taleb-kriteriet för ömtåligt och antibräckligt är enkelt. Huvuddomaren är tiden. Om systemet står emot tidens tand, och visar sin "vitalitet" och "oförstörbarhet" - har det egenskapen antibräcklighet.
Om vi, när vi designar ett system, tar hänsyn till antibräcklighet som ett krav, kommer detta att uppmuntra oss att använda sådana tillvägagångssätt för att bygga dess arkitektur som kommer att göra systemet mer anpassningsbart både till "kaos från utsidan" och till "kaos inifrån ”. Och i slutändan kommer systemet att ha en längre livslängd.
Ingen av oss vill göra "provisoriska hus". Och lura inte dig själv, vilket inte är något annat sätt idag. Det är normalt att en person tittar några steg framåt när som helst, särskilt under en kris.

Vad är ett datalager och varför bygger vi det

Artikeln om lagringsarkitektur förutsätter att läsaren inte bara vet vad det är, utan också har viss erfarenhet av sådana system. Ändå ansåg jag det nödvändigt att göra detta - att återvända till ursprunget, till början av vägen, eftersom det är där utvecklingens "stödpunkt" ligger.

Hur kom folk till idén att datalager behövs? Och hur skiljer de sig från bara en "mycket stor databas"?
För länge sedan, när det helt enkelt fanns "business data processing systems" i världen, fanns det ingen uppdelning av IT-system i sådana klasser som front-end oltp-system, back-office dss, textbehandlingssystem, datalager, etc.
Det var under denna tid som den första relationsdatabasmotorn, Ingres, skapades av Michael Stonebreaker.
Och det var den tiden då persondatorernas era brast in i datorbranschen som en virvelvind och för alltid förändrade alla idéer från den tidens IT-gemenskap.

På den tiden var det lätt att hitta företagsapplikationer skrivna på basis av DBMS:er i desktopklass, som Clipper, dBase och FoxPro. Och marknaden för klient-serverapplikationer och DBMS tog bara fart. Databasservrar dök upp en efter en, som kommer att ockupera sin nisch i IT-utrymmet under lång tid - Oracle, DB2, etc.
Och termen "databasapplikation" har varit vanlig. Vad innehöll en sådan ansökan? Förenklat - några inmatningsformulär genom vilka användare samtidigt kunde lägga in information, några beräkningar som lanserades "med knapp" eller "på schemat", samt några rapporter som kunde ses på skärmen eller sparas som filer och skickas för att försegla.
"Inget speciellt - bara en vanlig ansökan, bara en databas", sa en av mina mentorer tidigt i min karriär. "Så inget speciellt?" – Jag tänkte då.

Om man tittar noga så finns det fortfarande en del egenheter. När användarna växer, mängden inkommande information, när belastningen på systemet växer, går dess utvecklare, designers, för att upprätthålla prestanda på en acceptabel nivå, till några "tricks". Den allra första är uppdelningen av ett monolitiskt "business data processing system" i en redovisningsapplikation som stödjer användarnas on-line arbete, och en applikation för batchbehandling av data och rapportering tilldelas separat. Var och en av dessa applikationer har sin egen databas och är till och med värd på en separat instans av databasservern, med olika inställningar för olika typer av belastning - OLTP och DSS. Och dataströmmar radas upp mellan dem.

Det är allt? Det verkar som att problemet är löst. Vad händer sen?
Och sedan företag växer, deras informationsbehov multipliceras. Antalet interaktioner med omvärlden växer också. Och som ett resultat finns det inte en stor applikation som helt automatiserar alla processer, utan flera olika från olika tillverkare. Antalet system som genererar information – datakällssystem i företaget ökar. Och förr eller senare kommer det att finnas ett behov av att se och jämföra informationen från olika system. Så ser datalager ut i företaget – en ny klass av system.
Den allmänt accepterade definitionen av denna klass av system är följande.

Data Warehouse (eller Data Warehouse)- en ämnesorienterad informationsdatabas speciellt utformad och designad för utarbetande av rapporter och affärsanalyser för att stödja beslutsfattande i en organisation

Således, konsolidering data från olika system, möjligheten att titta på dem på ett visst "enhetligt" (enhetligt) sätt - detta är en av nyckelegenskaperna hos system av klassen datalager. Detta är anledningen till att lager har uppstått under utvecklingen av IT-system.

Nyckelfunktioner i datalager

Låt oss ta en närmare titt. Vilka är de viktigaste egenskaperna hos dessa system? Vad skiljer datalager från andra IT-system för företag?

För det första är det stora volymer. Väldigt stor. VLDB - det är så ledande leverantörer kallar sådana system när de ger sina rekommendationer om användningen av sina produkter. Från företagets alla system flödar data in i denna stora databas och lagras där "för evigt och oförändrat", som man säger i läroböcker (i praktiken är livet mer komplicerat).

För det andra är detta historiska data - "Företagsminne" - så kallade datalager. När det gäller att arbeta med tid i repositories är allt ganska intressant. I bokföringssystem är uppgifterna aktuella för tillfället. Sedan utför användaren en operation – och data uppdateras. Samtidigt kan förändringshistoriken inte sparas - det beror på redovisningspraxis. Ta till exempel ett saldo på bankkontot. Vi kan vara intresserade av det aktuella saldot "nu", i slutet av dagen eller vid tidpunkten för någon händelse (till exempel vid tidpunkten för att beräkna poängpoängen). Medan de två första är ganska lätta att lösa, kommer de senare med största sannolikhet att kräva speciella ansträngningar. Användaren, som arbetar med lagringen, kan referera till de senaste perioderna, jämföra dem med den nuvarande osv. Det är dessa tidsrelaterade förmågor som avsevärt skiljer datalager från bokföringssystem - att erhålla datatillstånd vid olika punkter på tidsaxeln - till ett visst djup i det förflutna.

För det tredje är det så konsolidering och datasammanslutning ... För att deras gemensamma analys ska bli möjlig är det nödvändigt att föra dem till en gemensam form - enhetlig datamodell , för att jämföra fakta med enhetliga referensböcker. Det kan finnas flera aspekter och svårigheter här. För det första - konceptuella – Under samma term kan olika personer från olika avdelningar förstå olika saker. Och vice versa - att kalla något annorlunda, vilket i grunden är samma sak. Hur tillhandahåller man en "enkel vy" samtidigt som den specifika visionen för en viss användargrupp bibehålls?

För det fjärde är detta arbete med Datakvalitet ... I processen att ladda data i lagringen rensas de, allmänna transformationer och transformationer utförs. Generella omvandlingar ska göras på ett ställe – och sedan användas för att bygga olika rapporter. Detta kommer att undvika inkonsekvenser som irriterar företagsanvändare - särskilt chefer som ställs till bordet med siffror från olika avdelningar som inte håller med varandra. Dålig datakvalitet skapar fel och avvikelser i rapporterna, vilket blir en minskning av nivån användarnas förtroende till hela systemet, till hela analystjänsten som helhet.

Arkitektoniska koncept

Alla som har stött på ett förvar har med största sannolikhet observerat någon form av "skiktad struktur" - sedan dess det är detta arkitektoniska paradigm som har slagit rot för system av denna klass. Och det är ingen slump. Lagringslager kan uppfattas som separata komponenter i systemet - med sina egna uppgifter, ansvarsområde, "spelregler".
Skiktad arkitektur är ett sätt att hantera komplexiteten i systemet - varje efterföljande nivå abstraheras från komplexiteten i den interna implementeringen av den föregående. Detta tillvägagångssätt låter dig peka ut problem av samma typ och lösa dem på ett enhetligt sätt, utan att återuppfinna "hjulet" från grunden varje gång.
Det konceptuella arkitektoniska diagrammet visas schematiskt i figuren. Detta är ett förenklat diagram som endast återspeglar nyckelidén - konceptet, men utan de "anatomiska detaljerna" som skulle uppstå vid djupare utarbetande av detaljer.

Som visas i diagrammet, välj konceptuellt följande lager. De tre huvudskikten som innehåller datalagringsområdet (indikeras av den fyllda rektangeln) och programvaran för dataladdning (konventionellt indikerad med pilar i samma färg). Och även ett extra - servicelager, som dock spelar en mycket viktig kopplingsroll - databelastningshantering och kvalitetskontroll.

Primärt datalager - primärt datalager (eller iscensättning , eller driftlager ) - utformad för att ladda från källsystem och spara primär information, utan transformationer - i originalkvalitet och stödja en komplett historik över ändringar.
Uppgiften för detta lager- att abstrahera de efterföljande lagren av lagring från den fysiska strukturen av datakällor, metoder för datainsamling och metoder för att allokera delta av förändringar.

Core Data Layer - kärnlagring - den centrala komponenten i systemet som skiljer lagringen från bara en "batch integrationsplattform" eller "big data dump", eftersom dess huvudsakliga roll är datakonsolidering från olika källor, reduktion till enhetliga strukturer, nycklar. Det är när man laddar in i kärnan som det huvudsakliga arbetet görs med datakvalitet och allmänna transformationer, vilket kan vara ganska komplicerat.
Uppgiften för detta lager- att abstrahera sina konsumenter från egenskaperna hos den logiska enheten för datakällor och behovet av att jämföra data från olika system, för att säkerställa datas integritet och kvalitet.

Data Mart Layer - analytiska skyltfönster - en komponent vars huvudsakliga funktion är att konvertera data till strukturer som är bekväma för analys (om BI arbetar med skyltfönster är detta som regel en dimensionell modell), eller enligt konsumentsystemets krav.
Som regel tar datamarts data från kärnan - som en pålitlig och verifierad källa - d.v.s. använda tjänsten för denna komponent för att föra data till en enda form. Vi kommer att kalla sådana skyltfönster regelbunden ... I vissa fall kan skyltfönster ta data direkt från iscensättningen - med primärdata (i källnycklarna). Detta tillvägagångssätt används vanligtvis för lokala uppgifter där datakonsolidering från olika system inte krävs och där effektivitet behövs mer än datakvalitet. Sådana montrar kallas fungerar ... Vissa analytiska indikatorer kan ha mycket komplexa beräkningsmetoder. Därför, för sådana icke-triviala beräkningar och transformationer, den s.k sekundära montrar .
Visa upp lageruppgift- förberedelse av data enligt kraven från en specifik konsument - en BI-plattform, en grupp användare eller ett externt system.

De ovan beskrivna lagren består av ett beständigt datalagringsområde, samt en mjukvarumodul för att ladda och transformera data. Denna uppdelning i lager och regioner är logisk. Fysiskt kan implementeringen av dessa komponenter vara olika – du kan till och med använda olika plattformar för att lagra eller transformera data på olika lager, om detta är mer effektivt.
Lagringsområden innehåller tekniska (bufferttabeller) som används i processen för datatransformation och måltabeller som den konsumerande komponenten syftar på. Det är god praxis att "täcka" måltabellerna med vyer. Detta underlättar det efterföljande underhållet och utvecklingen av systemet. Data i måltabellerna för alla tre lager är markerade med speciella tekniska fält (metaattribut), som används för att stödja dataladdningsprocesser, samt för att möjliggöra informationsrevision av dataflöden i lagret.

Dessutom urskiljs en speciell komponent (eller en uppsättning komponenter), som tillhandahåller servicefunktioner för alla lager. En av dess nyckeluppgifter är kontrollfunktionen - att tillhandahålla "enhetliga spelregler" för hela systemet som helhet, vilket ger rätten att använda olika alternativ för att implementera vart och ett av de ovan beskrivna lagren - inkl. använda olika teknologier för att ladda och bearbeta data, olika lagringsplattformar osv. Låt oss kalla det servicelager ... Den innehåller inte affärsdata, men den har sina egna lagringsstrukturer – den innehåller ett metadataområde, samt ett område för att arbeta med datakvalitet (och eventuellt andra strukturer, beroende på vilka funktioner som tilldelats den).

En sådan tydlig uppdelning av systemet i separata komponenter ökar avsevärt styrbarheten för utvecklingen av systemet:

komplexiteten i uppgiften som ställs till utvecklaren av funktionaliteten för en eller annan komponent minskas (han bör inte samtidigt lösa frågorna om integration med externa system, och tänka över procedurer för rengöring av data och tänka på den optimala presentationen av data för konsumenter) - uppgiften är lättare att bryta ner, utvärdera och utföra en liten leverans;
du kan ansluta till olika artisters arbete (och till och med team eller entreprenörer) - eftersom detta tillvägagångssätt gör att du effektivt kan parallellisera uppgifter, vilket minskar deras ömsesidiga inflytande på varandra;
närvaron av beständig iscensättning gör att du snabbt kan ansluta datakällor utan att designa hela kärnan eller skyltfönster för hela ämnesområdet, och sedan gradvis slutföra de återstående lagren enligt prioriteringar (desutom kommer data redan att finnas i lagret - tillgängligt för systemet analytiker, vilket i hög grad kommer att underlätta uppgifterna för den efterföljande utvecklingen av lagret);
närvaron av en kärna gör att allt arbete med datakvalitet (liksom eventuella misstag och fel) kan döljas från skyltfönster och för slutanvändaren, och viktigast av allt - genom att använda denna komponent som en enda datakälla för skyltfönster kan du undvika data konvergensproblem på grund av implementeringen av gemensamma algoritmer på ett ställe;
urvalet av marts låter dig ta hänsyn till skillnaderna och detaljerna för att förstå data som användare av olika avdelningar kan ha, och deras design för BI-krav tillåter inte bara att utfärda aggregerade siffror, utan att säkerställa datavalidering genom att ge möjligheter att borra ner till primära indikatorer;
närvaron av ett tjänstelager gör att du kan utföra end-to-end dataanalys (datalinje), använda enhetliga datagranskningsverktyg, allmänna tillvägagångssätt för att belysa förändringarnas delta, arbeta med datakvalitet, lasthantering, övervakning och feldiagnostikverktyg och påskyndar problemlösningen.

Detta tillvägagångssätt för nedbrytning gör också systemet mer motståndskraftigt mot förändringar (i jämförelse med den "monolitiska strukturen") - det säkerställer dess antibräcklighet:

förändringar från källsystemens sida bearbetas vid iscensättning - i kärnan ändras endast de strömmar som påverkas av dessa uppsättningstabeller, effekten på skyltfönster är minimal eller frånvarande;
Ändringar i krav från konsumenternas sida behandlas till största delen i skyltfönster (om detta inte kräver ytterligare information som ännu inte finns i butiken).

Därefter kommer vi att gå igenom var och en av komponenterna som presenteras ovan och ta en titt på dem lite mer detaljerat.

Systemkärna

Låt oss börja från mitten - kärnan i systemet eller mellanskiktet. Det är märkt som Core Layer. Kärnan spelar rollen som datakonsolidering - att föra till enhetliga strukturer, referensböcker, nycklar. Det är här det huvudsakliga arbetet med datakvalitet bedrivs – städning, transformation, enande.

Närvaron av denna komponent gör att du kan återanvända dataströmmar som omvandlar primärdata som tas emot från källsystem till ett visst enhetligt format, enligt allmänna regler och algoritmer, och inte upprepa implementeringen av samma funktionalitet separat för varje applikationsskyltfönster, vilket i utöver ineffektiv resursanvändning kan det också innebära avvikelser i uppgifterna.
Kärnan i förvaret är implementerad i en datamodell, i det allmänna fallet, som skiljer sig både från modellerna för källsystem och från konsumenternas format och strukturer.

Warehouse Core Model och Enterprise Data Model

Det främsta problemet med lagringsmellanskiktet är stabilitet. Det är därför huvudfokus här ligger på datamodellen. Det kallas vanligtvis för "företagsdatamodellen". Tyvärr har det skapats en sorts aura av myter och absurditeter kring den, som ibland leder till att man vägrar bygga den helt, men förgäves.

Myt 1. En företagsdatamodell är en enorm modell med tusentals enheter (tabeller).
Faktiskt. Inom vilket ämnesområde som helst, i vilken affärsdomän som helst, i alla företags data, även de mest komplexa, finns det få grundläggande enheter - 20-30.

Myt 2. Det finns ingen anledning att utveckla någon "egen modell" - vi köper en industrireferensmodell - och vi gör allt efter den. Vi spenderar pengar – men vi får ett garanterat resultat.
Faktiskt. Referensmodeller kan verkligen vara mycket användbara eftersom innehåller branscherfarenhet av att modellera detta område. Från dem kan du hämta idéer, tillvägagångssätt, namngivningsmetoder. Kontrollera "täckningsdjupet" för området så att något viktigt inte förbises. Men vi kommer sannolikt inte att kunna använda en sådan modell "out of the box" - som den är. Detta är samma myt som till exempel köpet av ett affärssystem (eller CRM) och dess implementering utan att "strama upp för dig själv". Värdet av sådana modeller föds i deras anpassning till verkligheten i just denna verksamhet, just detta företag.

Myt 3. Utvecklingen av en kärnförvarsmodell kan ta många månader, under vilken tid projektet faktiskt kommer att frysas. Dessutom kräver det galet mycket möten och mycket folk.
Faktiskt. Förvarsmodellen kan utvecklas med förvaret iterativt, bit för bit. För otäckta områden är "expansionspunkter" eller "stubbar" inställda. vissa "universella mönster" används. Samtidigt måste du veta när du ska sluta så att du inte får en superuniversell sak med 4 tabeller, i vilka det är svårt att både "sätta in data" och (ännu svårare) att få tag i det. Och vilket är extremt suboptimalt sett till prestanda.

Det tar verkligen tid att utveckla modellen. Men det här är inte tiden som ägnas åt att "rita enheter" - det här är den tid som krävs för att analysera ämnesområdet, förstå hur data är ordnade. Det är därför analytiker är mycket nära involverade i denna process, och olika affärsexperter är också involverade. Och detta görs punktvis, selektivt. Och inte genom att organisera möten med ett vansinnigt antal människors deltagande, skicka ut enorma frågeformulär osv.
Bra affärs- och systemanalys är nyckeln till att bygga en kärnlagermodell. Det finns mycket att förstå: var (i vilka system) data genereras, hur det fungerar, i vilka affärsprocesser det cirkulerar osv. Kvalitativ analys har aldrig skadat ett enda system. Snarare, tvärtom, problem uppstår från "vita fläckar" i vår förståelse.

Att utveckla en datamodell är inte en process att uppfinna och uppfinna något nytt. Faktum är att datamodellen redan finns i företaget. Och designprocessen är mer som "utgrävning". Modellen är noggrant och noggrant extraherad från "jorden" av företagsdata och klädd i en strukturerad form.

Myt 4. Vår verksamhet är så dynamisk i vårt företag, och allt förändras så snabbt att det är värdelöst för oss att göra en modell – den kommer att bli föråldrad innan vi sätter den här delen av systemet i drift.
Faktiskt. Kom ihåg att kärnfaktorn är stabilitet. Och framför allt modellens topologi. Varför? För det är denna komponent som är central och påverkar allt annat. Stabilitet är också ett krav för kärnmodellen. Om en modell blir föråldrad för snabbt är den felaktigt utformad. Fel tillvägagångssätt och "spelregler" valdes för dess utveckling. Och det är också en fråga om kvalitativ analys. Nyckelenheterna i företagsmodellen förändras sällan.
Men om det faller oss in att göra ett företag som säljer till exempel konfektyr, istället för katalogen "Produkter", gör du "Sötsaker", "kakor" och "pajer". Sedan när pizza dyker upp i listan över varor - ja, du kommer att behöva ange många nya tabeller. Och det här är bara en fråga om tillvägagångssätt.

Myt 5. Skapandet av en företagsmodell är en mycket seriös, komplex och ansvarsfull verksamhet. Och det är läskigt att göra ett misstag.
Faktiskt. Kärnmodellen, även om den borde vara stabil, är fortfarande inte "gjuten i metall". Liksom alla andra designlösningar kan dess struktur revideras och modifieras. Du behöver bara inte glömma den här kvaliteten på det. Men det betyder inte alls att "du inte kan andas på det". Och det betyder inte att tillfälliga lösningar och "stubbar" som borde planeras för återvinning är oacceptabla.

Myt 6. Om vår datakälla till exempel är ett referensdatasystem (eller ett masterdatahanteringssystem - MDM), så borde den redan motsvara företagsmodellen på ett vänskapligt sätt (särskilt om den nyligen designades och inte hade tid att förvärva en "sida", "traditioner "Och tillfälliga hyddor). Det visar sig att för det här fallet - behöver vi inte en kärnmodell?
Faktiskt. Ja, i det här fallet är det mycket lättare att bygga förvarets kärnmodell. vi följer en färdig konceptuell modell på toppnivå. Men det är inte alls uteslutet. Varför? För när man bygger en modell av ett visst system gäller några av dess egna regler - vilka typer av tabeller som ska användas (för varje enhet), hur man versionerar data, med vilken granularitet man ska behålla historik, vilka metaattribut (tekniska fält att använda ), etc.

Dessutom, oavsett hur underbart och allomfattande system av referensdata och MDM vi har, kommer det som regel att finnas nyanser förknippade med förekomsten av lokala kataloger "ungefär samma" i andra redovisningssystem. Och detta problem, vare sig vi vill det eller inte, kommer att behöva lösas på förvaret - trots allt samlas rapportering och analyser här.

Primärt datalager (eller historiserad iscensättning eller driftlager)

På den är den betecknad som Primärt datalager. Rollen för denna komponent: integration med källsystem, laddning och lagring av primära data, såväl som preliminär datarensning - kontroll av överensstämmelse med reglerna för format och logisk kontroll, fast i "överenskommelsen om gränssnittet för interaktion" med källan .
Dessutom löser denna komponent en mycket viktig uppgift för förvaret - allokering av det "sanna deltat av förändringar" - oavsett om källan tillåter dig att spåra ändringar i data eller inte och hur (med vilket kriterium de kan "fångas upp) "). Så snart data kom in i iscensättning - för alla andra lager är frågan om deltaallokering redan klar - tack vare märkningen med metaattribut.

Data i detta lager lagras i strukturer så nära källsystemet som möjligt - för att hålla primärdata så nära sin ursprungliga form som möjligt. Ett annat namn för denna komponent är "operativt lager".
Varför inte bara använda den väletablerade termen "staging"? Faktum är att tidigare, före "eran av stora data och VLDB", var diskutrymme mycket dyrt - och ofta var primärdata, om den bevarades, bara en begränsad tidsperiod. Och ofta kallas namnet "staging". rengörbar buffert.
Nu har teknologier tagit steget framåt - och vi har råd att inte bara lagra all primär data, utan att historisisera dem med den grad av granularitet som är möjlig. Detta betyder inte att vi inte ska kontrollera datatillväxten och eliminerar inte behovet av att hantera informationens livscykel, optimera kostnaden för datalagring, beroende på "temperaturen" för användningen - dvs. tar "kall data" som är mindre efterfrågad till billigare media- och lagringsplattformar.

Vad ger närvaron av "historiserad iscensättning" oss:

möjligheten att göra misstag (i strukturer, i transformationsalgoritmer, i historiens granularitet) - med fullständigt historisiserade primärdata i tillgänglighetszonen för lagringen kan vi alltid ladda om våra tabeller;
en möjlighet att tänka - vi kan ta oss tid att arbeta fram ett stort fragment av kärnan just i denna iteration av lagringsutvecklingen, eftersom i vår iscensättning kommer det i alla fall att finnas, och med en jämn tidshorisont (det kommer att finnas en punkt med "historisk referens");
möjligheten till analys - vi sparar även de data som inte längre finns i källan - de kan skrivas över där, gå till arkivet osv. - hos oss förblir de tillgängliga för analys;
möjligheten till en informationsrevision - tack vare den mest detaljerade initiala informationen kommer vi senare att kunna förstå hur nedladdningen fungerade för oss, att vi så småningom fick sådana siffror (för detta måste vi också ha märkning med metaattribut och motsvarande metadata som nedladdningen fungerar på - detta bestäms av tjänsteskiktet).

Vilka svårigheter kan uppstå när man bygger en "historiserad iscensättning":

det skulle vara bekvämt att ställa krav på transaktionsintegriteten för detta lager, men praxis visar att detta är svårt att uppnå (detta betyder att vi på detta område inte garanterar referensintegriteten för överordnade och underordnade tabeller) - integritetsanpassning sker vid efterföljande skikten;
detta lager innehåller mycket stora volymer (de mest voluminösa på lagret - trots all redundans av analytiska strukturer) - och du måste kunna hantera sådana volymer - både när det gäller belastning och vad gäller förfrågningar (annars kan du seriöst försämra prestandan för hela lagringen).

Vad mer är intressant att säga om detta lager.
För det första, om vi går bort från paradigmet med "end-to-end-lastningsprocesser", fungerar inte längre regeln "karavanen rör sig med den sista kamelens hastighet" för oss, mer exakt, vi överger "karavanen" principen och byt till "transportör"-principen: vi tog data från källan - lägg i ditt lager - redo att ta nästa del. Det betyder att
1) vi väntar inte på att bearbetningen ska ske på andra lager;
2) vi är inte beroende av schemat för tillhandahållande av data från andra system.
Enkelt uttryckt schemalägger vi en laddningsprocess som tar data från en källa genom ett specifikt sätt att ansluta till den, kontrollerar, extraherar delta - och lägger in data i måluppsättningstabeller. Och det är allt.

För det andra är dessa processer, som du kan se, mycket enkla - man kan säga trivialt, ur logikens synvinkel. Detta innebär att de kan optimeras och parametriseras mycket väl, vilket minskar belastningen på vårt system och påskyndar processen att ansluta källor (utvecklingstid).
För att detta ska hända måste du mycket väl känna till funktionerna i de tekniska funktionerna på plattformen som den här komponenten fungerar på - och då kan du göra ett mycket effektivt verktyg.

Visa lager

Data Mart Layer ansvarar för att förbereda och tillhandahålla data till slutanvändare - personer eller system. På denna nivå beaktas konsumentens krav så mycket som möjligt - både logiskt (konceptuellt) och fysiskt. Tjänsten ska ge precis det som behövs – varken mer eller mindre.

Om konsumenten är ett externt system, så dikterar det som regel de datastrukturer som den behöver och reglerna för insamling av information. Ett bra tillvägagångssätt är ett där konsumenten ansvarar för korrekt datainsamling. Datalagret förberedde, bildade ett skyltfönster, gav möjlighet till inkrementell datainsamling (markering med metaattribut för efterföljande val av förändringsdelta), och konsumentsystemet styr sedan självt och ansvarar för hur det använder detta skyltfönster. Men det finns några särdrag: när systemet inte har en aktiv komponent för datainsamling - antingen behövs en extern komponent som kommer att utföra den integrerande funktionen, eller så kommer lagringen att fungera som en "integrationsplattform" - och kommer att säkerställa korrekt inkrementell dataöverföring vidare - utanför lagringen. Många nyanser kommer upp här, och reglerna för gränssnittsinteraktion bör vara genomtänkta och förstådda av båda parter (dock som alltid när det kommer till integration). Som regel tillämpas rutinmässig datarensning/arkivering på sådana datamarts (det är sällan nödvändigt att denna "transitdata" lagras under lång tid).

Viktigast ur analytiska uppgifters synvinkel är skyltfönster "för människor" - närmare bestämt för de BI-verktyg som de arbetar med.
Det finns dock en kategori av "särskilt avancerade användare" - analytiker, datavetare - som inte behöver BI-verktyg eller regulatoriska processer för att fylla externa specialiserade system. De behöver någon form av "delade skyltfönster" och "en egen sandlåda" där de kan skapa tabeller och transformationer som de vill. I detta fall är förvarets ansvar att se till att dessa gemensamma skyltfönster är fyllda med data i enlighet med regelverket.
Separat kan vi peka ut sådana konsumenter som Data Mining-verktyg - djup dataanalys. Dessa verktyg har sina egna krav på dataförberedelser och används även av datavetare. För lagringen handlar uppgiften om – återigen, att stödja tjänsten för att ladda vissa skyltfönster av ett överenskommet format.

Men tillbaka till de analytiska skyltarna. Det är dessa som är intressanta ur lagringsdesigners synvinkel i detta datalager.
Enligt min mening är det bästa beprövade tillvägagångssättet för att designa datamarts, till vilket nästan alla BI-plattformar nu är "vässade", Ralph Kimballs tillvägagångssätt. Det är känt som dimensionell modellering - multidimensionell modellering. Det finns många publikationer om detta ämne. Till exempel finns de grundläggande reglerna i publikationen. Och naturligtvis kan du rekommendera från den flerdimensionella modelleringsgurun. En annan användbar resurs är Kimballs tips
Det flerdimensionella tillvägagångssättet för skapandet av skyltfönster beskrivs och utarbetas så väl - både från "metod-evangelisters" sida och från ledande mjukvaruleverantörers sida att det inte är någon idé att uppehålla sig vid det i detalj här - den ursprungliga källan är alltid att föredra.

Jag skulle bara vilja göra en betoning. "Rapportering och analys" är annorlunda. Det finns "tung rapportering" - förbeställda rapporter som genereras i form av filer och levereras till användarna via de tillhandahållna leveranskanalerna. Och så finns det dashboards - BI dashboards. I grunden är dessa webbapplikationer. Och svarstiden för dessa applikationer är densamma som för alla andra webbapplikationer. Detta innebär att den normala tiden för en BI-panel att uppdatera är sekunder, inte minuter. Det är viktigt att ha detta i åtanke när du utformar din lösning. Hur kan detta uppnås? Standardoptimeringsmetoden: vi tittar på vad svarstiden består av och vad vi kan påverka. Vilken är mest bortkastad tid? För fysisk (disk) databasavläsning, för dataöverföring över nätverket. Hur minskar man mängden data som läses och överförs i en begäran? Svaret är uppenbart och enkelt: du måste antingen aggregera data eller tillämpa ett filter på de stora tabellerna för de faktiska tabellerna som deltar i frågan, och utesluta sammanfogning av stora tabeller (referenser till faktatabellerna ska bara gå genom dimensioner) .

Vad är BI till för? Hur är det bekvämt? Varför är den flerdimensionella modellen effektiv?
BI låter användaren köra vad som kallas ad hoc-frågor. Vad betyder det? Det betyder att vi inte känner till den exakta begäran i förväg, men vi vet vilka indikatorer i vilka aspekter användaren kan begära. Användaren genererar en sådan fråga genom att välja lämpliga BI-filter. Och uppgiften för BI-utvecklaren och skyltfönsterdesignern är att tillhandahålla en sådan logik för applikationen så att data antingen filtreras eller aggregeras, vilket förhindrar en situation när för mycket data efterfrågas - och applikationen "hänger sig". Vanligtvis börjar de med aggregerade siffror, fördjupar sig sedan djupare i mer detaljerad data, men installerar på vägen de nödvändiga filtren.

Det räcker inte alltid att bara bygga "rätt stjärna" och få en bekväm struktur för BI. Ibland kommer du att behöva tillämpa denormalisering någonstans (medan du ser tillbaka på hur detta kommer att påverka belastningen), och någonstans för att göra sekundära skyltfönster och aggregat. Lägg till index eller projektioner någonstans (beroende på DBMS).

Genom "trial and error" kan man alltså få en struktur som är optimal för BI – som kommer att ta hänsyn till både DBMS:s och BI-plattformens egenheter, samt användarens krav på datapresentation.
Om vi tar data från "kärnan" kommer sådan behandling av skyltfönster att vara lokal till sin natur, utan att på något sätt påverka den komplexa behandlingen av primärdata som erhålls direkt från källsystem - vi "skiftar" bara data till ett format som är bekvämt för BI. Och vi har råd att göra detta många gånger, på olika sätt, i enlighet med olika krav. Det är mycket enklare och snabbare att göra detta på kärndata än att samla in från den "primära" (vars struktur och regler, som vi vet, också kan "flyta").

Servicelager

Tjänsteskiktet ansvarar för implementeringen av allmänna (tjänste)funktioner som kan användas för att bearbeta data i olika lagringsskikt - lasthantering, datakvalitetshantering, problemdiagnos och övervakningsverktyg m.m.
Närvaron av denna nivå ger transparens och strukturerade dataflöden i lagringen.

Detta lager inkluderar två datalagringsområden:

metadataområde - används för kontrollmekanism för dataladdning;
datakvalitetsområde - för implementering av offline-datakvalitetskontroller (dvs de som inte är inbyggda direkt i ETL-processer).

Du kan ordna nedladdningshanteringsprocessen på olika sätt. Ett möjligt tillvägagångssätt är detta: vi delar upp hela uppsättningen lagringsbord i moduler. Modulen kan innehålla tabeller med endast ett lager. Tabellerna som ingår i varje modul laddas i en separat process. Låt oss kalla det kontrollprocess ... Starten av kontrollprocessen är inställd på sitt eget schema. Kontrollprocessen orkestrerar anrop till atomära processer, som var och en laddar en måltabell, och innehåller även några allmänna steg.
Uppenbarligen räcker det med att helt enkelt dela upp mellanställningstabellerna i moduler - efter källsystem, eller snarare efter deras anslutningspunkter. Men för kärnan är det redan svårare att göra detta. där måste vi säkerställa dataintegriteten, vilket innebär att vi måste ta hänsyn till beroenden. De där. det blir kollisioner som måste lösas. Och det finns olika metoder för att lösa dem.

En viktig punkt i lasthantering är att utveckla ett konsekvent förhållningssätt till felhantering. Fel klassificeras efter deras svårighetsgrad. När ett kritiskt fel uppstår måste processen stoppas, och så snart som möjligt, eftersom dess förekomst indikerar ett betydande problem som kan leda till datakorruption i lagringen. Belastningshantering handlar alltså inte bara om att starta processer, utan också att stoppa dem, samt att förhindra otidig start (av misstag).

För driften av tjänsteskiktet skapas en speciell metadatastruktur. Detta område kommer att lagra information om laddningsprocesser, laddade datamängder, kontrollpunkter som används för att upprätthålla inkrementet (vilken process har läst till vilken punkt) och annan serviceinformation som är nödvändig för att systemet ska fungera.
Det är viktigt att notera att alla måltabeller i alla lager är markerade med en speciell uppsättning metafält, varav ett är identifieraren för processen som uppdaterade den här raden. För tabeller i ett arkiv tillåter denna processmarkering ett konsekvent sätt att senare markera förändringarnas delta. När data laddas in i det primära datalagret är situationen mer komplicerad - deltaallokeringsalgoritmen för olika laddade objekt kan vara olika. Men logiken i att bearbeta accepterade ändringar och deras rullning på måltabeller för kärnan och skyltfönster är mycket mer komplicerad än för iscensättning, där allt är ganska trivialt - det är lätt att parametrisera och tänka över återanvändbara standardsteg (procedurer).

Jag ställer inte in uppgiften här för att helt täcka detta ämne - organisationen av nedladdningar - jag lyfter bara fram de accenter som är värda att uppmärksamma.
Detta tillvägagångssätt är bara ett av alternativen. Det är ganska lyhört. Och dess "konceptuella prototyp" var Toyota-transportören och just-in-time-systemet. De där. här går vi bort från det utbredda paradigmet med enbart "nattlig datanedladdning", och vi laddar ner i små portioner under dagen - så fort uppgifterna är klara i olika källor: det som kom - det laddades ner. Samtidigt har vi många parallella processer igång. Och den "heta svansen" av färsk data kommer ständigt att "blinka" - och jämna ut sig över tiden. Vi måste ta hänsyn till denna funktion. Och, om det behövs, forma skräddarsydda montrar med "skivor", där allt redan är holistiskt. De där. det är omöjligt att uppnå både effektivitet och konsekvens (integritet) samtidigt. Vi behöver en balans – någonstans är en sak viktig, någon annanstans.

Det är absolut nödvändigt att tillhandahålla avverknings- och övervakningsanläggningar. Det är god praxis att använda maskinskrivna händelser, där du kan ställa in olika parametrar och anpassa aviseringssystemet - prenumerera på vissa händelser. Eftersom det är mycket viktigt att när systemadministratörens ingripande krävs, han skulle veta om det så tidigt som möjligt och få all nödvändig diagnostisk information. Loggarna kan även användas för att analysera post-facto problem, samt för att undersöka incidenter av systemfel, inkl. Datakvalitet.

Designa och underhålla lagerdatamodeller

Varför är det viktigt att vara uppmärksam på design av datamodeller när man utvecklar alla system där en databas är involverad (och speciellt i ett lager)? Varför inte bara kasta en uppsättning tabeller var som helst - även i en textredigerare? Varför behöver vi "dessa bilder"?
Märkligt nog ställer även erfarna utvecklare sådana frågor.
Egentligen, ja, ingenting hindrar dig från att skissa tabeller – och börja använda dem. Om ... om samtidigt i huvudet (!) Utvecklaren har en sammanhängande allmän bild av strukturen som han skulpterar. Vad händer om det finns flera utvecklare? Vad händer om någon annan använder dessa tabeller? Och vad händer om tiden går - personen lämnar detta område och sedan återvänder till det igen?

Kan du lista ut det utan modell? I princip kan du. Och för att lista ut det, och "klura ut bilderna på ett papper", och "shag - lösa" data. Men det är mycket enklare, tydligare och snabbare att använda en färdig artefakt – en datamodell. Och också förstå "logiken i dess enhet" - dvs. det skulle vara trevligt med allmänna spelregler.

Och det viktigaste är inte ens det. Det viktigaste är att när vi designar en modell tvingas vi (bara utan alternativ!) att studera ämnesområdet närmare och djupare, funktionerna hos dataenheten och deras användning i olika affärsfall. Och de där frågorna som vi lätt skulle ha "skjutit undan" som komplexa, "suddiga" genom att kasta våra tecken, utan att samtidigt försöka design modell - vi kommer att tvingas leverera och bestämma nu, när vi analyserar och designar, och inte senare - när vi kommer att bygga rapporter och tänka på "hur man kan minska det inkompatibla" och "uppfinna hjulet på nytt" varje gång.

Detta tillvägagångssätt är en av de tekniska metoder som gör att du kan skapa anti-bräckliga system. Eftersom de är tydligt arrangerade, transparenta, bekväma för utveckling, och även deras "bräcklighetsgränser" är omedelbart synliga - du kan mer exakt uppskatta "katastrofens omfattning" när nya krav dyker upp och den tid som krävs för omdesign (om det behövs).
Således är datamodellen en av de viktigaste artefakterna som måste underhållas under utvecklingen av systemet. På ett vänskapligt sätt bör det vara "på bordet" för varje analytiker, utvecklare, etc. - alla som deltar i systemutvecklingsprojekt.

Att designa datamodeller är ett stort och separat ämne. Det finns två huvudsakliga tillvägagångssätt för lagringsdesign.
Tillvägagångssättet fungerar bra för kärnan Entitetsförhållande - när en normaliserad (3NF) modell byggs upp utifrån studiet av ämnesområdet, eller snarare dess valda område. Samma "företagsmodell" som diskuterades ovan spelar här.

Vid design av montrar är det lämpligt flerdimensionell modell ... Detta tillvägagångssätt passar bra med företagsanvändares förståelse – eftersom det är en modell som är enkel och bekväm för mänsklig perception - människor arbetar med förståeliga och välbekanta begrepp av mått (indikatorer) och sektioner genom vilka de analyseras. Och detta låter dig enkelt och tydligt bygga processen för att samla in krav - vi ritar en uppsättning "matriser av sektioner och indikatorer", kommunicerar med representanter för olika avdelningar. Och sedan tar vi in det i en struktur - "analysmodellen": vi bildar "mätbussen" och definierar fakta som definieras på dem. Längs vägen arbetar vi med hierarkier och aggregeringsregler.

Då är det väldigt lätt att gå till den fysiska modellen, lägga till optimeringselement med hänsyn till DBMS:s egenheter. Till exempel, för Oracle skulle det vara partitionering, en uppsättning index, etc. För Vertica kommer andra tekniker att användas - sortering, segmentering, sektionering.
Dessutom kan speciell denormalisering krävas - när vi medvetet introducerar redundans i data, tack vare vilket vi förbättrar frågeprestanda, men samtidigt komplicerar datauppdatering (eftersom redundans kommer att behöva beaktas och underhållas under dataladdningen bearbeta). För att förbättra prestandan kanske vi också måste skapa ytterligare aggregerade tabeller, eller använda sådana ytterligare DBMS-funktioner som projektioner i Vertica.

Så när vi modellerar datalager löser vi faktiskt flera problem:

uppgiften att bygga en konceptuell (logisk) modell av kärnan - system- och affärsanalys - undersöka ämnesområdet, gå in på detaljer och ta hänsyn till nyanserna av "live-data" och deras användning i affärer;
uppgiften att bygga en analysmodell – och sedan en konceptuell (logisk) skyltfönstermodell;
uppgiften att bygga fysiska modeller - dataredundanshantering, optimering med hänsyn till DBMS:s egenheter för frågor och dataladdning.

När vi utvecklar konceptuella modeller kanske vi inte tar hänsyn till särdragen hos ett visst DBMS för vilket vi designar en databasstruktur. Dessutom kan vi använda en konceptuell modell för att skapa flera fysiska - för olika DBMS.

Låt oss sammanfatta.

En datamodell är inte en samling av "snygga bilder", och designprocessen är inte processen att rita dem. Modellen speglar vår förståelse av domänen. Och processen att sammanställa den är processen att studera och forska i den. Det här är bortkastad tid. Och inte alls att "rita och måla".
En datamodell är en designartefakt, ett sätt att utbyta information på ett strukturerat sätt mellan teammedlemmar. För att göra detta måste det vara tydligt för alla (detta tillhandahålls genom notation och förklaring) och tillgängligt (publicerat).
Datamodellen skapas inte en gång och fryses, utan skapas och utvecklas i systemutvecklingsprocessen. Vi sätter själva reglerna för dess utveckling. Och vi kan ändra dem om vi ser - hur man gör det bättre, enklare, mer effektivt.
Datamodellen (fysisk) låter dig konsolidera och utnyttja en uppsättning bästa praxis som syftar till optimering - d.v.s. använd de tekniker som redan har fungerat för detta DBMS.

Funktioner i datalagerprojekt

Låt oss uppehålla oss vid funktionerna i de projekt inom vilka företaget bygger och utvecklar datalager. Och låt oss titta på dem från synvinkeln av inflytandet från den arkitektoniska aspekten. Varför är det viktigt för sådana projekt att bygga en arkitektur, och det redan från början? Och det är närvaron av en genomtänkt arkitektur som ger flexibilitet till datalagerprojektet, gör att du effektivt kan fördela arbete mellan utförare, samt göra det lättare att förutsäga resultatet och göra processen mer förutsägbar.

Data warehouse är anpassad programvara

Ett datalager är alltid en "anpassad utveckling", inte en boxad lösning. Ja, det finns branschspecifika BI-applikationer som inkluderar en referensdatamodell, förkonfigurerade ETL-processer från vanliga källor (till exempel ERP-system), en uppsättning standard BI-paneler och rapporter. Men i praktiken implementeras lagring sällan - som en "låda". Jag har arbetat med repositories i cirka 10 år och har aldrig sett en sådan historia. Det finns alltid några nyanser förknippade med företagets unika egenskaper – både verksamheten och IT-landskapet. Att hoppas att arkitekturen kommer att tillhandahållas av "leverantören" som tillhandahåller lösningen är därför något hänsynslöst. Arkitekturen för sådana system "mognar" ofta inom själva organisationen. Eller så bildas det av specialisterna från entreprenörsföretaget, som är den huvudsakliga utföraren för projektet.

Data Warehouse är ett integrationsprojekt

Datalagret laddar och bearbetar information från många källsystem. Och för att upprätthålla "vänliga relationer" med dem måste du vara extremt försiktig med dem. I synnerhet är det nödvändigt att minimera belastningen på källsystemen, ta hänsyn till fönstren "tillgänglighet och otillgänglighet", välj interaktionsgränssnitt med hänsyn till deras arkitektur etc. Då kommer lagringen att kunna hämta data så tidigt som möjligt och med erforderlig frekvens. Annars kommer du att "transplanteras" till backupkretsen, som inte uppdateras med den mest operativa frekvensen.
Dessutom måste den "mänskliga faktorn" beaktas. Integration handlar inte bara om interaktion mellan maskiner. Det är också kommunikation mellan människor.

Data Warehouse är ett samarbetsprojekt

I ett stort företag kan ett sådant system sällan göras av bara ett team. Här arbetar som regel flera team som vart och ett löser ett specifikt problem.

Arkitekturen ska ge möjligheten att organisera sitt parallella arbete, samtidigt som den bibehåller sin integritet och undviker duplicering av samma funktionalitet på olika platser, av olika personer. Förutom onödiga arbetskostnader kan sådan dubbelarbete leda till avvikelser i uppgifterna senare.

Dessutom, när så många människor och team, ofta utspridda, är involverade i utvecklingen av systemet, uppstår frågan oundvikligen: hur man bygger kommunikation och informationsinteraktion mellan dem. Ju mer standardiserade och begripliga tillvägagångssätt och praxis används, desto lättare, bekvämare och mer effektivt är det att organisera sådant arbete. Och bland annat är det värt att tänka på sammansättningen av "arbetsartefakter", bland vilka för datalager # 1 är datamodeller (se föregående avsnitt).

Datalagret har en längre livslängd än andra system

För att förtydliga - påståendet är sant för en "live", fungerande lagring, integrerad med nyckelkällor, som besitter historiska data och tillhandahåller information och analytiska tjänster till många divisioner av företaget.

Vilka skäl har jag för att tro det?
För det första är att bygga ett lager en mycket resurskrävande process: förutom de faktiska kostnaderna för utrustning, licenser för nödvändig teknisk programvara och utveckling, är nästan alla system och divisioner inom företaget också involverade i detta. Att upprepa hela processen från början igen är en väldigt vågad idé.

För det andra, om lagringen har rätt arkitektur, kan den ganska enkelt överleva förändringar av källsystem, och uppkomsten av nya krav från slutanvändare och tillväxten av datavolymer.
Om arkitekturen är korrekt, informationsflöden är transparenta, då kan ett sådant system utvecklas under lång tid utan att riskera att hamna i en stupor-situation vid förändringar på grund av svårigheter att bedöma påverkan.

Gradvis iterativ utveckling

Det sista som kunden skulle vilja, att engagera sig i historien med lagringen, är att frysa sina krav i ett eller två år, tills en komplett företagsdatamodell är designad, alla källor är fullt anslutna, etc.

I kundernas ögon ser datalagret ofta ut som ett absolut monster - systemets uppgifter, mål och utvecklingshorisont är så omfattande. Och ofta är kunden rädd att "på bekostnad av sin budget" IT-avdelningen kommer att lösa några "sina egna problem". Och återigen står vi inför frågan om interaktion mellan människor och förmågan att lugnt uttrycka vår ståndpunkt och förhandla.

Kompetenta arkitektoniska tillvägagångssätt låter dig utveckla systemet iterativt, öka funktionaliteten gradvis, utan att gå in i "utveckling" i flera år innan du börjar ge ett resultat.

Även om det bör noteras att "mirakel inte sker" - och "starten" tar också tid. För lagringar kan det vara ganska stort – eftersom det handlar om stora datamängder är detta historiska data – för de gamla perioderna då reglerna för behandling av information kunde skilja sig från de nuvarande. Därför tar det tillräckligt med tid för analysarbete, interaktion med källsystem och ett antal "trial and error", inklusive belastningstester på verklig data.

Datalager - "multi-project story"

Det är svårt att peka ut en enskild företagskund för ett datalager. Och man tror (inte utan anledning) att nyckelfaktorn för framgången för projektet att bygga en lagringsanläggning är stödet från företagets ledning - direkt den första personen.
Ett förvar byggs och utvecklas sällan som en del av ett enda projekt. Vanligtvis finns det olika behov av datakonsolidering och analys, bakom dem finns olika kunder och användargrupper. Därför utvecklas förvaret ofta inom ramen för flera parallella projekt.

Balans mellan innovation och beprövade lösningar

Trots att ämnet lagring är väldigt "urgammalt" (om ett sådant ord är tillämpligt för en så ung bransch som IT) och ganska konservativt. Ändå står inte framstegen stilla - och de begränsningar som tidigare fanns på grund av dyra och långsamma diskar, dyrt minne osv. - är nu borttagna. Samtidigt är det dags att revidera några av de arkitektoniska angreppssätten. Dessutom gäller detta både för tekniska plattformar och arkitekturen för de tillämpade systemen som är baserade på dem.

Det är viktigt att hitta en balans här - och upprätthålla ett ganska "grönt" förhållningssätt till både resurser och lagrad information. Annars kan du mycket snabbt förvandla lagringen till en semistrukturerad "sophög", som, om det kommer att vara möjligt att ta reda på det, då med ganska stor ansträngning.
Ja, vi har fler möjligheter, men det betyder inte att vi behöver förneka alla ackumulerade och beprövade metoder, som det är tydligt hur och varför man ska använda, och "hänge oss åt alla dåliga nyheter" bara ledda av det dimmiga spöket av "innovationer".
Att hålla balans innebär att använda nya metoder och tillvägagångssätt där de öppnar nya möjligheter, men samtidigt använda gamla beprövade – för att lösa akuta problem som inte har avbrutits.
Vad kan vi göra som utvecklare och designers av applikationslösningar? Först och främst att känna till och förstå de tekniska förändringarna av de plattformar som vi arbetar på, deras möjligheter, funktioner och tillämpningsgränser.

Låt oss titta på DBMS som den mest kritiska och viktigaste tekniska plattformen för lagring.
På senare tid har det skett en tydlig drift av relationsdatabaser, skapade från början som "universella", mot specialisering. Under lång tid har ledande leverantörer släppt olika alternativ - för tillämpningar av olika klasser (OLTP, DSS & DWH). Dessutom dyker det upp ytterligare möjligheter att arbeta med text, geo-data m.m.

Men detta var inte slutet på det - det började dyka upp produkter som från början var inriktade på en viss klass av uppgifter - d.v.s. specialiserad DBMS. De kanske använder relationsmodellen eller inte. Det är viktigt att de initialt "vässas" inte bara för att lagra och bearbeta "affärsinformation" i allmänhet, utan för specifika uppgifter.

Tydligen är centralisering och specialisering två kompletterande trender som periodvis avlöser varandra, vilket säkerställer utveckling och balans. Samt evolutionär (gradvis) gradvis utveckling och kardinalförändringar. Till exempel på 90-talet var Michael Stonebreaker en av författarna till Generation III Database Manifesto, som tydligt uttryckte tanken att världen inte behöver ytterligare en revolution i databasernas värld. Men 10 år senare publicerar han verk där han tillkännager förutsättningarna för början på en ny era i DBMS-världen – utifrån deras specialisering.
Han fokuserar på det faktum att vanliga universella DBMS är byggda på en "one-size-fits-all"-arkitektur som inte tar hänsyn till vare sig förändringar i hårdvaruplattformar eller uppdelning av applikationer i klasser för vilka man kan komma med en mer optimal lösning än att implementera universella krav.
Och han börjar utveckla ett antal projekt i enlighet med denna idé. En av dem - C-Store - är ett kolumnformat DBMS designat i arkitekturen shared nothing (SN), som ursprungligen skapades specifikt för system av klassen datalager. Denna produkt marknadsfördes sedan som HP Vertica.

Det verkar som att nu ämnet utveckling av datalager har glidit in i ett nytt utvecklingsstadium. Ny teknik, tillvägagångssätt och verktyg dyker upp. Deras studie, testning och intelligenta applikation gör att vi kan skapa riktigt intressanta och användbara lösningar. Och ta dem till implementering och njut av att dina utvecklingar används i verkligt arbete och är användbara.

Epilog

När jag förberedde den här artikeln försökte jag främst fokusera på arkitekter, analytiker och utvecklare som direkt arbetar med datalager. Men det visade sig att det oundvikligen "tog ämnet lite bredare" - och andra kategorier av läsare föll in i synfältet. Vissa punkter kommer att verka kontroversiella, vissa är otydliga, andra är uppenbara. Människor är olika – med olika bakgrund, bakgrund och positioner.
Typiska chefsfrågor är till exempel "när ska man anställa arkitekter?", "När ska man göra arkitektur?" låter för oss (utvecklare, designers) ganska konstigt, för för oss uppträder systemets arkitektur med dess födelse - det spelar ingen roll om vi är medvetna om det eller inte. Och även om det inte finns någon formell roll för en arkitekt i ett projekt, "inkluderar en normal utvecklare alltid sin egen interna arkitekt".

I stort sett spelar det ingen roll vem som exakt utför rollen som arkitekt – det är viktigt att någon ställer liknande frågor och undersöker svaren. Om arkitekten tydligt pekas ut betyder det bara att han är primärt ansvarig för systemet och dess utveckling.
Varför tyckte jag att ämnet "antifragility" var relevant för detta ämne?

"Det unika med antibräcklighet är att det tillåter oss att arbeta med det okända, att göra något under förhållanden när vi inte förstår vad vi gör, och att nå framgång."/ Nassim N.Taleb /

Därför är krisen och en hög grad av osäkerhet inte en ursäkt till förmån för frånvaron av arkitektur, utan faktorer som förstärker dess nödvändighet.

Epilog

"Det unika med antibräcklighet är att det tillåter oss att arbeta med det okända, att göra något under förhållanden när vi inte förstår vad vi gör, och att nå framgång."/ Nassim N.Taleb /

Därför är krisen och en hög grad av osäkerhet inte en ursäkt till förmån för frånvaron av arkitektur, utan faktorer som förstärker dess nödvändighet.

Taggar: Lägg till taggar

5.1. Organisering av data i företagens informationssystem.

Med tanke på CIS på den mest förenklade nivån kan vi säga att den innehåller ett företagsdatornätverk och ett specialiserat applikationspaket (PPP) för att lösa problem inom ämnesområdet. I sin tur förutsätter både PPP och datanätet användning av informationsdata om tillstånd och utveckling av de system som styrs och kontrolleras av dem. Historiskt sett består CIS av separata förgrenade delsystem av enskilda företag, sammankopplade med varandra och ofta representerar ett hierarkiskt system. Det är naturligt att anta att sådana delsystem har både egna källor och egna lagringsplatser för relaterad data. Genom att kombineras till ett enda system uppstår frågor om den gemensamma korrekta användningen av data geografiskt placerade på olika platser där de lagras. Följaktligen, för framgångsrik ledning av en produktionsförening utrustad med en ICS, behöver den ett tillförlitligt system för att samla in, lagra och bearbeta data. Du behöver med andra ord en enhetlig informationsinfrastruktur som möter strategiska BI-projekt (Business Intelligence) eller en integrerad databas för att lagra och använda data. Huvudmålet med dataintegration är att få en enhetlig och sammanhängande bild av tillståndet för företags affärsdata. Integration i sig är en komplex process, baserad på vilken det är tillrådligt att peka ut:

Teknik,

Produkter,

Ansökningar.

Metoder Finns metoder för dataintegration.

TeknologierÄr processer som implementerar vissa metoder för dataintegration.

ProdukterÄr kommersiella lösningar som stödjer en eller annan dataintegrationsteknik.

Ansökningar- dessa är färdiga tekniska lösningar som tillhandahålls av utvecklare i enlighet med önskemål från kunder - kunder.

Beroende på komplexiteten hos företagens informationssystem och på de uppgifter de är utformade för att lösa, är organisationen av data i dem något annorlunda. I synnerhet i CIS, utformat för att säkerställa effektiv hantering av affärsprocesser för både enskilda filialer och företaget som helhet, är det vanligt att prata om förekomsten av företagsdatabaser. I företagsinformationssystem som används på de högsta nivåerna av ledning och mestadels förknippas med processerna för operativ analys och beslutsfattande, i processen att planera, designa och prognostisera olika typer av ledningsaktiviteter, använder de terminologin för ett datalager. Det är relevant att notera att frasen integrerad lagring inneboende i båda.

5.2. Företagsdatabaser och krav på dem

Som en systemomfattande integrerad datalagring är företagsdatabasen utformad för att tillhandahålla information för effektiv hantering av alla affärsprocesser och divisioner i företaget. Dataintegration möjliggör skapandet av en ny struktur som organiskt inkluderar data från databaserna för separata separata divisioner, därför måste en sådan struktur uppfylla vissa krav:

Enkel och användarvänlig datainmatning i databasen,

Att lagra data på ett sätt som inte leder till överdriven datatillväxt,

Tillgång till allmän information för anställda i alla avdelningar av företaget, med förbehåll för det obligatoriska villkoret om differentiering av åtkomsträttigheter,

Att snabbt hitta och hämta den nödvändiga informationen,

Sortering och filtrering av nödvändig data,

gruppering av data med samma namn,

Mellanliggande och slutliga beräkningar ovanför fälten,

· Konvertering och tydlighet av utdata,

Skalbarhet,

· Skydd mot oavsiktliga fel, oåterkallelig dataförlust och obehörig åtkomst.

Dessutom, när man integrerar isolerade (distribuerade) databaser i en enda företagsdatabas, är det viktigt att säkerställa förmågan att arbeta med databasen på ett sådant sätt att användaren arbetar med den som med en oallokerad.

Skapandet av en integrerad företagsdatabas är möjligt med olika metoder, varav de viktigaste är:

Konsolidering,

Federalisering,

· Spridning.

5.3. Egenskaper för företagsdatabasintegrationslösningar

Konsolidering. Under konsolidering betyder vanligtvis tillägg av data med samma namn. En liknande term används ofta i banksektorn, där en årlig konsoliderad balansräkning bildas, som gör att du kan presentera alla tillgångar och skulder i moderbanken tillsammans med dess filialer.

Som tillämpat på ett företag, när man använder denna metod, kopieras och samlas data in från primära databaser (DB - Slave) genom integration i en enda lagringsplats (DB - Master). Som regel väljs servern för det centrala (huvud)kontoret som sådan lagringsplats (Figur 5.1).

Figur 5.1. Datakonsolideringsmetod

Data i databasen - Master används för rapportering, analys, utveckling och beslutsfattande, samt en datakälla för andra grenar av företaget.

De vanligaste teknikerna för att stödja sådana beslut under konsolidering är följande tekniker:

· Extraktion, transformation och lastning - ETL (Extract Transform Load);

· Hantering av företagets innehåll - ECM (Enterprise Content Management).

Fördelarna med konsolideringsmetoden är:

1. Förmåga att genomföra transformation(omstrukturering, avstämning, rengöring och/eller aggregering) av betydande mängder data under överföringen från primära system till slutliga lagringsplatser med hjälp av ETL-teknik,

2. Förmåga att hantera ostrukturerad data såsom dokument, rapporter och sidor tack vare ECM-tekniklösningar.

För att arbeta med den konsoliderade CIS-databasen, special affärsapplikationer, som låter dig skapa frågor till databasdata, rapporter och, på grundval av dem, utföra dataanalys.

Nackdelen med integration genom konsolidering är oförmågan att uppdatera den konsoliderade datan i den integrerade lagringsplatsen i synk med datauppdateringarna i de primära systemen på grund av de konflikter som uppstår under synkroniseringen.

Det finns en tidsfördröjning mellan det att data uppdateras i de primära systemen och på den slutliga lagringsplatsen.

Denna fördröjning kan variera från några sekunder till flera timmar eller till och med dagar.

Federalisering. Under federalisering betyder vanligtvis förening. En liknande term används ofta inom politiken när man ordnar statsgränser (till exempel Förbundsrepubliken Tyskland, Ryska federationen, USA).

Processen för datafederalisering i en företagsdatabas är skapandet av en virtuell (skenbar) bild som kombinerar flera primära datafiler till en enda virtuell helhet (se figur 5.2). Datafederation i sig handlar om att extrahera data från primära system baserat på externa krav. Hantering av arbetet med företagsdatabasen integrerad enligt den federala metoden utförs av federaliseringsprocessor.

Fig. 2. Datafederationsmetod

Genom att komma åt data i en virtuell databas genererar alla affärsapplikationer en begäran till den virtuella bilden. Federationsprocessorn, baserat på denna begäran, extraherar data från respektive primära system, integrerar den enligt den virtuella bilden och levererar resultatet till affärsapplikationen som genererade begäran. I detta fall utförs alla nödvändiga datatransformationer när de extraheras från de primära systemen.

Stödet för ett federerat tillvägagångssätt för dataintegration tillhandahålls av Enterprise information integration (E I I), som i översättning betyder - integration av företagsinformation.

En egenskap hos den federerade lösningen är att federaliseringsprocessorn använder metadata(kunskap), som inkluderar data om den virtuella bildens sammansättning och egenskaper, om mängden data, semantiska relationer mellan dem och åtkomstvägar till dem, vilket hjälper den federerade lösningen att optimera åtkomsten till primära system.

De främsta fördelarna med det federerade tillvägagångssättet är:

Möjligheten att komma åt aktuell data utan att skapa ytterligare en ny databas,

Möjlighet att ansöka efter förvärv eller fusion av företag,

Oersättlig i de fall där det av säkerhetsskäl finns licensbegränsningar för kopiering av data från primära system,

Använd, om nödvändigt, av den höga autonomin hos företagets lokala divisioner och flexibiliteten i centraliserad kontroll av deras verksamhet,

· En hög grad av användbarhet för stora transnationella företag.

Nackdelarna med detta tillvägagångssätt inkluderar:

Minskad prestanda på grund av den extra kostnaden för åtkomst till flera datakällor,

Federalisering är mest lämplig för att hämta små mängder data,

· Höga krav på kvaliteten på primärdata.

Spridning. Under spridning hänvisar vanligtvis till territoriell överföring av multiplicerade objekt. Dataspridning avser spridning av primära databaser och deras förflyttning från en plats till en annan. När du implementerar denna metod affärsapplikationer arbeta online och flytta data till destinationer baserat på specifika händelser som inträffar. För denna tekniska lösning blir det viktigt att uppdatera data, som är möjliga i synkront eller asynkront läge.Synkront läge förutsätter att uppdateringar i både primärsystemet och målsystemet sker under samma fysiska transaktion.

Exempel på tekniker som stödjer implementeringen av en dataspridningsmetod är:

Integration av företagsapplikationer EAI - Enterprise Application Integration,

· Replikering av företagsdata EDR - Enterprise Data Replication.

Den generaliserade strukturen för implementeringen av dataspridningsmetoden är som visas i figur 5.3.

Figur 5.3. Dataspridningsmetod

En utmärkande egenskap hos datadistributionsmetoden är den garanterade leveransen av data till destinationssystemet med en minimal fördröjning nära realtid.

Kombinationen av teknologier för integration (EAI) och replikering (EDR) ger flera fördelar, i form av följande fördelar:

· Hög prestanda,

· Förmåga att omstrukturera och rensa data,

· Balansera belastningen genom att skapa säkerhetskopior och återställa data.

Hybrid tillvägagångssätt. Verkligheten för ekonomisk verksamhet är sådan att det inte finns två identiska företag, än mindre två identiska företag. Denna omständighet sätter sin prägel på processen att skapa och fylla företagets informationssystem. Detta gäller också helt och hållet metoder för dataintegration i databaser. Av denna anledning använder många CIS-system den så kallade hybrid ett tillvägagångssätt som involverar flera integrationsmetoder samtidigt, exempel på dessa är teknologier som ger en konsekvent bild av kundinformation:

Integration av kunddata i CDI-system - Customer Data Integration,

· Integration av kunddata i modulerna CRM - Customer Relations Management.

I synnerhet kan CDI-implementeringsmetoden åstadkommas på en mängd olika sätt.

Det enklaste sättet är att skapa en konsoliderad kunddatabas som innehåller data från primära system. I det här fallet kan eftersläpningen av information regleras genom att använda olika konsolideringslägen: operationell eller batch, beroende på hur ofta denna information uppdateras.

Det andra sättet är datafederation, när det är virtuellt affärspresentation kunddata som finns i primära system. Och metadatafilen kan innehålla generella nyckelelement som kan användas för att koppla kundinformation.

Således kan allmänna (till exempel krav) kunddata konsolideras som de mest statiska uppgifterna. Och mer dynamisk data (som orderinformation) kan federaliseras.

Dessutom kan hybridmetoden utökas med hjälp av dataspridningsmetoden. Till exempel ändrar en kund som använder tjänsterna i en onlinebutik sina uppgifter under tjänsten. Dessa ändringar kan skickas till den konsoliderade delen av databasen och därifrån spridas till alla primära system som innehåller data om butikens kunder.

Med tanke på fördelarna och nackdelarna med var och en av metoderna, är det lämpligt att kreativt närma sig deras tillämpning och gemensam användning.

Datafederation är till exempel användbart när kostnaderna för att konsolidera data uppväger de affärsfördelar som konsolideringen ger. I synnerhet onlinebehandling av förfrågningar och utarbetande av rapporter är exakt en sådan situation.

Praktiska tillämpningar av metoden för dataspridning är mycket varierande, både när det gäller prestanda och när det gäller förmågan att omstrukturera och rensa data.

5.4. Datalagers koncept och strukturella lösningar

Datalagring - det är en ämnesorienterad integrerad lagring av information som ackumulerar externa och operativa data, samt data från andra system, utifrån vilka beslutsfattande och dataanalysprocesser byggs upp.

Till skillnad från databaser och databanker är grunden för datalager inte interna, utan externa datakällor: olika informationssystem, elektroniska arkiv, offentliga elektroniska kataloger, referensböcker och samlingar.

Data warehouse-konceptet bygger på två huvudidéer:

1. Integrering av disaggregerade detaljerade data (som beskriver specifika fakta, egenskaper, händelser etc.) i ett enda arkiv.

2. Separation av datauppsättningar och applikationer som används för bearbetning och analys.

Datalagret är organiserat i de fall det är nödvändigt att skaffa:

Integration av aktuella och historiska datavärden,

Genom att kombinera data från olika källor,

Skapande av en pålitlig dataplattform för analytiska ändamål,

Säkerställa datakonsistens i hela organisationen,

Underlätta implementeringen av företagsdatastandarder utan att ändra befintliga operativsystem,

· Ge en bred historisk bild och möjligheter att analysera utvecklingstrender.

Historiskt sett har datalager byggts på ett en-, två- och trenivåschema.

System på en nivå var ursprungligen avsedda för de enklaste arkitekturerna, som inkluderar funktionella DSS:er, med en otillräckligt utvecklad informationsinfrastruktur, när analys utförs med data från operativa system, enligt principen: data - presentationsformer.

Fördelarna med sådana system är:

Snabb dataöverföring från operativa system till ett specialiserat system utan mellanliggande länkar,

· Minimikostnader på grund av användningen av en enda plattform.

Nackdelar:

Ett snävt antal problem som ska lösas på grund av en enda datakälla,

· Dålig datakvalitet på grund av bristande rengöringssteg.

Tvådelade system tillhandahålla en kedja: data - data marts - presentationsformulär. De används i företag med ett stort antal oberoende divisioner som använder sin egen informationsteknik.

Fördelar:

De montrar som används är utformade för att svara på en specifik uppsättning frågor,

· Det är möjligt att optimera data i datamarts för att förbättra prestandan.

Nackdelar:

Svårigheter att säkerställa datakonsistens på grund av att de upprepas flera gånger i skyltfönster,

Potentiell komplexitet hos datamarts som fylls med ett stort antal datakällor,

· På grund av bristen på datakonsolidering på företagsnivå finns det ingen enskild bild av verksamheten.

Utvecklingen av utvecklingen har lett till att konstruktionen av ett fullfjädrat datalager för moderna företagssystem började utföras av trestegsarkitektur (se figur 5.4).

På först nivån innehåller en mängd olika inspelningssystem som är datakällor. Sådana system kan vara företagsresursplaneringssystem (ERP - Enterprise Resource Planning), referenssystem (operativa) system, externa källor eller system som levererar data från informationsbyråer, etc.

På andra nivån innehåller en central lagring, där data från alla källor på den första nivån samlas in, samt ett operativt datalager, som är utformat för att utföra två funktioner:

Lagret är en källa till analytisk information som används för operativ ledning,

· I driftlagret förbereds data för att senare laddas in i centrallagret. Databeredning innebär att utföra kontroller och datatransformation i samband med olika föreskrifter för mottagande av data från första nivån.

Tredje en nivå är en samling domänspecifika datamarts.

Data mars - dessa är relativt små funktionellt orienterade enheter, vars innehåll bidrar till lösningen av analytiska uppgifter för enskilda divisioner av företaget. Faktum är att datamarts är delmängder av data från ett lager. Samtidigt har slutanvändare möjlighet att få tillgång till detaljerad information om lagret, om det inte finns tillräckligt med data i marknaden, samt att få en mer komplett bild av verksamhetens tillstånd.

Figur 5.4. Data warehouse arkitektur

De huvudsakliga tekniska operationerna för sådana organiserade datalager är:

· Hämtar data är processen att överföra data från heterogena källor till ett operativt lager,

· Omvandling data är en modifiering av data baserat på särskilda regler med efterföljande överföring till en central lagring,

· Rengöring data är eliminering av dubbelarbete av data som kommer från olika källor,

· Uppdatering data är spridningen av en datauppdatering till originaldata från bastabellerna och de härledda data som lagras i lagret.

Fördelar:

· Att fylla skyltfönster är förenklat tack vare användningen av en enda källa med rensad data,

Datamars är synkroniserade med företagets affärsbild, vilket gör det enkelt att utöka det centrala arkivet och lägga till datamart,

· Garanterad prestanda.

Nackdelar:

Närvaron av dataredundans, vilket leder till ökade krav på datalagringsteknik,

5. 5. Databashanteringssystem och teknologier för åtkomst av data i CIS

Databashanteringssystem(DBMS) är en uppsättning språk- och mjukvaruverktyg utformade för att skapa, underhålla och dela en databas av en eller flera användare.

För närvarande är de mest utbredda DBMS byggda på basis av en relationsdatamodell som beskrivs av en rigorös matematisk apparat. teori om relationer.

En egenskap hos DBMS som fungerar i företagsinformationssystemet är det faktum att de måste hantera databaser som finns på media distribuerade i rymden.

I syfte att eliminera ytterligare duplicering eller kopiering av data i CIS, ligger huvudvikten på principen om fjärrdatabehandling. Databaser i CIS innehåller data som många användare behöver. Att få åtkomst av flera användare samtidigt till databasen är möjligt vid installation i ett lokalt datornätverk DBMS som fungerar med användare och med en enda databas.

De huvudsakliga tekniska lösningarna för fleranvändararbete med databaser är fil-/server- och klient-/serverteknologier. Med det lämpligaste alternativet från dessa tekniker, är klienten / servern i CIS organiserade specialiserade system för bearbetning av distribuerade databaser. I detta fall utförs hanteringen av distribuerade databaser på ett sådant sätt att data distribueras inte på den logiska, utan på den fysiska nivån, och själva databasen betraktas som en enda "superkrets". I en distribuerad databas är administrativa funktioner fördelade mellan den integrerade databasadministratören och de lokala databasadministratörerna. Den integrerade databasadministratören övervakar differentieringen av åtkomsten för olika användare till databasen och säkerställer integriteten och säkerheten för data, samt skydd av data från att de korrigeras samtidigt av flera användare. Åtkomstkontroll utförs i enlighet med de rättigheter som beviljas enskilda användare i nätverksoperativsystemet.

En karakteristisk egenskap hos program skapade med hjälp av DBMS för att arbeta med fjärranslutna och distribuerade företagsdatabaser är användningen av ett gränssnitt för öppen dataåtkomst - ODBC (Open Data Base Connectivity). Alla funktioner för dataöverföring är tilldelade ODBC-gränssnittet, som är en kopplingsbrygga mellan den integrerade databasen DBMS och klientapplikationen DBMS. Samtidigt kan klientens DBMS interagera inte bara med sina lokala databaser utan även med data som finns i den integrerade databasen. Klienten har möjlighet att skicka förfrågningar till den integrerade databasen DBMS, ta emot data om dem och skicka sina egna uppdaterade data.

Industridatamodeller

Huvudsyftet med modellerna är att underlätta orienteringen i datautrymmet och hjälpa till att lyfta fram de detaljer som är viktiga för affärsutvecklingen. I dagens miljö, för ett framgångsrikt företag, är det absolut nödvändigt att ha en tydlig förståelse för kopplingarna mellan de olika komponenterna och att ha en god uppfattning om den övergripande bilden av organisationen. Identifiering av alla detaljer och relationer med hjälp av modeller möjliggör den mest effektiva användningen av tiden och verktygen för att organisera företagets arbete.

Datamodeller är abstrakta modeller som beskriver hur data presenteras och nås. Datamodeller definierar dataobjekt och relationerna mellan dem i ett visst område. En datamodell är ett navigeringsverktyg för både affärs- och IT-proffs som använder en specifik uppsättning symboler och ord för att exakt förklara en specifik klass av verklig information. Detta möjliggör bättre kommunikation inom organisationen och skapar därmed en mer flexibel och stabil applikationsmiljö.

Datamodellen definierar unikt betydelsen av datan, som i detta fall är strukturerad data (till skillnad från ostrukturerad data som till exempel en bild, binär fil eller text, där innebörden kan vara tvetydig).

Som regel särskiljs modeller av en högre nivå (och mer generell till innehållet) och en lägre (respektive mer detaljerad). Den övre nivån av modellering är den så kallade konceptuella datamodeller(konceptuella datamodeller), som ger den mest allmänna bilden av hur ett företag eller en organisation fungerar. Den konceptuella modellen inkluderar de huvudkoncept eller ämnesområden som är avgörande för organisationens funktion; vanligtvis överstiger deras antal inte 12-15. En sådan modell beskriver de klasser av enheter som är viktiga för organisationen (affärsobjekt), deras egenskaper (attribut) och associationerna mellan par av dessa klasser (det vill säga relationer). Eftersom terminologin inom affärsmodellering ännu inte helt har satt sig kan i olika engelskspråkiga källor även konceptuella datamodeller kallas för ämnesområdesmodellen (som kan översättas till domänmodeller) eller ämnesdatamodellen företagsdata (ämne företagsdata). modeller).

Nästa hierarkiska nivå är logiska datamodeller(logiska datamodeller). De kan också kallas företagsdatamodeller eller affärsmodeller. Dessa modeller innehåller datastrukturer, deras attribut och affärsregler och representerar den information som används av företaget ur ett affärsperspektiv. I en sådan modell organiseras data i form av enheter och relationer mellan dem. Den logiska modellen presenterar data på ett sätt som gör det lätt för företagsanvändare att förstå. I en logisk modell kan en datalexikon särskiljas - en lista över alla enheter med deras exakta definitioner, vilket gör att olika kategorier av användare kan ha en gemensam förståelse av alla indata- och informationsutgångsströmmar i modellen. Nästa, lägre nivå av modellering är den fysiska implementeringen av den logiska modellen med hjälp av specifika mjukvaruverktyg och tekniska plattformar.

Den logiska modellen innehåller ett detaljerat företagsbeslut, som vanligtvis tar formen av en normaliserad modell. Normalisering är en process som säkerställer att varje datapost i en modell bara har ett värde och är helt och unikt beroende av primärnyckeln. Dataobjekt är organiserade i grupper enligt deras unika identifiering. Affärsreglerna som styr dataposter måste vara helt införlivade i den normaliserade modellen med förhandsvalidering och validering. Till exempel kommer en datapost som kundnamn sannolikt att delas upp i förnamn och efternamn och grupperas med andra relaterade dataobjekt till en kundenhet med primärnyckeln kund-ID.

Den logiska datamodellen är oberoende av tillämpad teknik som databaser, nätverkstekniker eller rapporteringsverktyg, och sätten för deras fysiska implementering. Det kan bara finnas en Enterprise Data Model i en organisation. Logiska modeller inkluderar vanligtvis tusentals enheter, relationer och attribut. Till exempel kan en datamodell för ett finansinstitut eller ett teleföretag innehålla cirka 3 000 branschbegrepp.

Det är viktigt att skilja mellan logisk och semantisk datamodell. Den logiska datamodellen representerar en affärslösning för företag, och den semantiska datamodellen representerar en tillämpad affärslösning. Samma företagslogiska datamodell kan implementeras med hjälp av olika semantiska modeller, d.v.s. semantiska modeller kan ses som nästa nivå av modellering som närmar sig fysiska modeller. Dessutom kommer var och en av dessa modeller att representera en separat "del" av företagsdatamodellen i enlighet med kraven för olika applikationer. Till exempel, i företagets logiska datamodell, kommer Kundentiteten att vara helt normaliserad, och i den semantiska modellen för datamarknaden kan den representeras som en flerdimensionell struktur.

Ett företag kan ha två sätt att skapa en företagslogisk datamodell: bygga den självständigt eller använda en färdig. branschmodell(industrilogisk datamodell). I det här fallet återspeglar skillnader i termer endast olika tillvägagångssätt för att bygga samma logiska modell. I händelse av att ett företag självständigt utvecklar och implementerar sin egen logiska datamodell, kallas en sådan modell som regel helt enkelt en företagslogisk modell. Om en organisation bestämmer sig för att använda en färdig produkt från en professionell leverantör, kan vi prata om en industrilogisk datamodell. Den senare är en färdig logisk datamodell som speglar hur en viss industri fungerar med en hög grad av noggrannhet. En industrilogikmodell är en domänspecifik och integrerad bild av all information som måste finnas i ett företagsdatalager för att kunna svara på både strategiska och taktiska affärsfrågor. Precis som alla andra logiska datamodeller är industrimodellen oberoende av applikationslösningar. Det inkluderar inte heller härledda data eller andra beräkningar för snabbare datahämtning. Som regel är de flesta av de logiska strukturerna i en sådan modell väl förkroppsligade i dess effektiva fysiska implementering. Sådana modeller utvecklas av många leverantörer för en mängd olika verksamhetsområden: ekonomi, tillverkning, turism, sjukvård, försäkring, etc.

En branschlogisk datamodell innehåller information som är gemensam för branschen och därför inte kan vara en heltäckande lösning för ett företag. De flesta företag måste utöka modellen med i genomsnitt 25 % genom att lägga till dataposter och utöka definitioner. De out-of-the-box-modellerna innehåller endast viktiga dataelement och resten av elementen måste läggas till motsvarande affärsobjekt under installationen av modellen i företaget.

Branschlogiska datamodeller innehåller en betydande mängd abstraktion. Abstraktioner betyder föreningen av liknande begrepp under vanliga namn som Event eller Participant. Detta ger branschmodeller flexibilitet och enhetlighet. Konceptet med ett evenemang är alltså tillämpligt på alla branscher.

Business Intelligence-specialisten Steve Hoberman identifierar fem faktorer att ta hänsyn till när man bestämmer sig för att skaffa en industridatamodell. Den första är tiden och pengarna som behövs för att bygga modellen. Om en organisation behöver uppnå resultat snabbt, kommer branschmodellen att vara fördelaktig. Att använda en branschmodell ger kanske inte omedelbart en bild av hela organisationen, men det kan spara mycket tid. Istället för att modellera sig själv kommer tid att läggas på att koppla befintliga strukturer till branschmodellen och diskutera hur man bäst kan anpassa den efter organisationens behov (till exempel vilka definitioner som bör ändras och vilka dataposter som ska läggas till).

Den andra faktorn är den tid och pengar som krävs för att hålla modellen i gott skick. Om företagsdatamodellen inte är en del av en metod som låter dig övervaka överensstämmelse med dess noggrannhet och överensstämmelse med moderna standarder, blir en sådan modell mycket snabbt föråldrad. Branschdatamodellen kan förhindra att denna risk inträffar eftersom den hålls uppdaterad med externa resurser. Naturligtvis bör förändringar som sker inom organisationen återspeglas i modellen av företaget självt, men branschförändringar kommer att reproduceras i modellen av dess leverantör.

Den tredje faktorn är erfarenhet av riskbedömning och modellering. Skapandet av en företagsdatamodell kräver kvalificerade resurser från både verksamheten och IT-personalen. Som regel är chefer väl medvetna om antingen verksamheten i organisationen som helhet eller verksamheten på en viss avdelning. Få av dem har både bred (företagsövergripande) och djup (inom avdelningar) kunskap om sin verksamhet. De flesta chefer känner vanligtvis bara ett område väl. Därför, för att få den övergripande företagsbilden, krävs betydande affärsresurser. Detta ökar också kraven på IT-personalen. Ju mer affärsresurser som krävs för att skapa och testa en modell, desto mer erfarna analytiker måste vara. De ska inte bara veta hur de ska få information från verksamhetspersonalen, utan också kunna hitta en gemensam synpunkt på stridsområden och kunna presentera all denna information på ett integrerat sätt. Den som skapar modellen (i många fall samma analytiker) måste ha goda modelleringsförmåga. Att bygga företagslogiska modeller kräver modellering "för framtiden" och förmågan att bokstavligen omvandla komplexa affärer "till rutor och linjer".

Å andra sidan tillåter branschmodellen att extern expertis utnyttjas. Branschspecifika logiska modeller byggs med hjälp av beprövade modelleringsmetoder och team av erfarna yrkesmän för att undvika vanliga och kostsamma problem som kan uppstå när man utvecklar företagsdatamodeller inom en organisation.

Den fjärde faktorn är den befintliga applikationsinfrastrukturen och leverantörsrelationer. Om en organisation redan använder många verktyg från samma leverantör och har etablerade relationer med honom, då är det vettigt att beställa branschmodellen från honom. Denna modell kommer att kunna arbeta fritt med andra produkter från samma leverantör.

Den femte faktorn är utbyte av information inom branschen. Om ett företag behöver kommunicera med andra organisationer som arbetar inom samma område kan branschmodellen vara mycket användbar i denna situation. Organisationer inom samma bransch använder liknande strukturella komponenter och terminologi. Numera, i de flesta branscher, tvingas företag att utbyta data för att framgångsrikt kunna bedriva affärer.

De mest effektiva är branschmodellerna som erbjuds av professionella leverantörer. Hög effektivitet av deras användning uppnås på grund av den betydande detaljnivån och noggrannheten hos dessa modeller. De innehåller vanligtvis många dataattribut. Dessutom har skaparna av dessa modeller inte bara lång erfarenhet av modellering, utan är också väl bevandrade i att bygga modeller för en viss bransch.

Branschdatamodeller ger företag en enda integrerad bild av sin affärsinformation. Många företag har svårt att integrera sin data, även om detta är en förutsättning för de flesta företagsövergripande projekt. Enligt en undersökning från The Data Warehousing Institute (TDWI) fann mer än 69 % av de tillfrågade organisationerna att integration är ett betydande hinder för att nya applikationer ska användas. Tvärtom genererar implementeringen av dataintegration påtagliga intäkter för företaget.

Branschdatamodellen, förutom att länka till befintliga system, ger stora fördelar för företagsomfattande projekt som Enterprise Resource Planning (ERP), master data management, business intelligence, datakvalitetsförbättring och personalutveckling.

Således är industrilogiska datamodeller ett effektivt verktyg för att integrera data och få en helhetssyn på verksamheten. Användningen av logiska modeller verkar vara ett nödvändigt steg mot skapandet av företagsdatalager.

Publikationer

Steve Hoberman. Utnyttja industrins logiska datamodell som din företagsdatamodell.
Claudia Imhoff. Snabbspårande datalager och Business Intelligence-projekt via intelligent datamodellering

Företagsdatabasen är den centrala länken i företagsinformationssystemet och låter dig skapa ett enda informationsutrymme för företaget. Företagsdatabaser

Dela ditt arbete på sociala medier

Om detta verk inte passade dig längst ner på sidan finns en lista över liknande verk. Du kan också använda sökknappen

ÄMNE V. FÖRETAGSDATABASER

V .1. Organisering av data i företagssystem. Företagsdatabaser.

V .2. DBMS och strukturella lösningar i företagssystem.

V.3. Internet / Intranät-teknik och företagslösningar för databasåtkomst.

V .1. ORGANISERING AV DATA I FÖRETAGSSYSTEM. FÖRETAGSDATABASER

Företagsbas data är den centrala länken i företagsinformationssystemet och låter dig skapa ett enda informationsutrymme för företaget. Företagsdatabaser (Figur 1.1).

Det finns olika definitioner av databaser.

Under databasen (DB) förstå en uppsättning information logiskt kopplad på ett sådant sätt att den utgör en enda uppsättning data lagrad i en dators minnesenheter. Denna uppsättning fungerar som de initiala uppgifterna för de uppgifter som löses under driften av automatiserade styrsystem, databehandlingssystem, informations- och datorsystem.

Termen databas kan sammanfattas som en samling logiskt relaterad data avsedd för delning.

Under databasen förstås som en uppsättning data som lagras tillsammans med en sådan minimal redundans som gör att de kan användas på ett optimalt sätt för en eller flera applikationer.

Syftet med att skapa databaser som former av datalagring konstruktion av ett datasystem som inte är beroende av de antagna algoritmerna (mjukvaran), de tekniska medel som används, den fysiska platsen för datan i datorn. Databasen förutsätter mångsidig användning (flera användare, många former av dokument och förfrågningar från en användare).

Grundläggande krav för databaser:

Datapresentationens fullständighet. Data i databasen bör representera all information om objektet på ett adekvat sätt och de bör vara tillräckliga för ODS.
Databasintegritet. Uppgifterna ska sparas vid bearbetning av deras ODS och i eventuella situationer som uppstår under arbetets gång.
Datastrukturflexibilitet. Databasen bör tillåta förändringar av datastrukturer utan att kränka dess integritet och fullständighet när yttre förhållanden förändras.
Genomförbarhet. Det innebär att det ska finnas en objektiv representation av olika objekt, deras egenskaper och samband.
Tillgänglighet. Det är nödvändigt att säkerställa avgränsningen av åtkomst till uppgifter.
Redundans. Databasen bör ha en minsta redundans i representationen av data om vilket objekt som helst.

Kunskap förstås som en uppsättning fakta, mönster och heuristiska regler som kan användas för att lösa problemet.

Kunskapsbas (KB)  en uppsättning databaser och använda regler som erhållits från beslutsfattare. Kunskapsbasen är en del av expertsystem.

Skilja på olika sätt att presentera data.

Fysiska data - det är data som lagras i datorns minne.

Logisk datarepresentation motsvarar en anpassad vy av fysisk data. Skillnaden mellan fysiska och motsvarande logiska representationer av data är att de senare återspeglar några viktiga samband mellan fysiska data.

Under företagsdatabasen förstå en databas som i en eller annan form förenar all nödvändig data och kunskap om den organisation som automatiseras. I företagens informationssystem, ett begrepp somintegrerade databaser, där principen om enkel inmatning och upprepad användning av information implementeras.

Ris. 1.1. Strukturen för avdelningarnas interaktion med företagets informationsresurser.

Företagsdatabaser är fokuserad (centraliserad) och distribueras.

Klumpad (centraliserad) databas är en databas, vars data lagras fysiskt i lagringsenheterna på en dator. I fig. 1.2 visar ett diagram över en serverapplikation för åtkomst till databaser på olika plattformar.

Figur 1.2. Schema heterogen centraliserad databas

Centralisering av informationsbehandlingen gjorde det möjligt att eliminera sådana nackdelar med traditionella filsystem som datainkoherens, inkonsekvens och redundans. Men när databaser växer, och särskilt när de används i geografiskt spridda organisationer, uppstår problem. Till exempel, för koncentrerade databaser belägna vid noden av ett telekommunikationsnätverk, med hjälp av vilka olika avdelningar i organisationen får tillgång till data, med ökningen av informationsvolymen och antalet transaktioner, uppstår följande svårigheter:

Stort flöde av datautbyte;
Hög trafik på nätverket;
Låg tillförlitlighet;
Dålig prestanda totalt sett.

Även om det är lättare att säkerställa informationens säkerhet, integritet och konsistens under uppdateringar i en koncentrerad databas, utgör dessa problem vissa utmaningar. Datadecentralisering föreslås som en möjlig lösning på dessa problem. Decentralisering uppnår:

Högre grad av samtidig bearbetning på grund av lastbalansering;
Förbättra användningen av data i fält när man utför fjärrförfrågningar;
Lägre kostnader;
Lätt att hantera lokala databaser.

Kostnaderna för att skapa ett nätverk, i vars noder arbetsstationer (små datorer) finns, är mycket lägre än kostnaderna för att skapa ett liknande system med en stor dator. Figur 1.3 visar det logiska diagrammet för en distribuerad databas.

Figur 1.3. Distribuerad företagsdatabas.

Låt oss ge följande definition av en distribuerad databas.

Distribuerad databas - det är en samling information, filer (relationer) lagrade i olika noder i informationsnätverket och logiskt sammankopplade på ett sådant sätt att de utgör en enda uppsättning data (kommunikation kan vara funktionell eller genom kopior av samma fil). Det är alltså en uppsättning databaser kopplade logiskt, men fysiskt placerade på flera maskiner som ingår i samma datornätverk.

De viktigaste prestandakraven för en distribuerad databas är:

Skalbarhet;
Kompatibilitet;
Stöd för olika datamodeller;
Bärbarhet;
Platstransparens;
Autonomi för distribuerade databasnoder (Site Autonomy);
Behandling av distribuerad begäran;
Utförande av distribuerade transaktioner.
Stöd för ett homogent säkerhetssystem.

Platstransparens tillåter användare att interagera med databaser utan att veta något om var de befinner sig. De distribuerade databasnodernas autonomi innebär att varje databas kan underhållas oberoende av de andra. En distribuerad fråga är en fråga (SQL-sats), under exekveringen av vilken objekt (tabeller eller vyer) i olika databaser nås. Vid exekvering av distribuerade transaktioner utförs samtidighetskontroll av alla inblandade databaser. Oracle7 använder två-fas informationsöverföringsteknik för att utföra distribuerade transaktioner.

Databaserna som utgör en distribuerad databas behöver inte vara homogena (dvs. underhållas av ett DBMS) eller bearbetas i miljön för samma operativsystem och/eller på datorer av samma typ. Till exempel kan en databas vara en Oracle-databas på en SUN-maskin som kör SUN OS (UNIX), en andra databas kan vara värd för en DB2-databas på en IBM 3090 stordator med ett MVS-operativsystem, och en tredje databas kan köras av SQL / DS även på IBM stordator, men med operativsystemet VM. Endast ett villkor är nödvändigt - alla maskiner med databaser måste vara tillgängliga över nätverket de ingår i.

Huvuduppgiften för en distribuerad databas - distribution av data över nätverket och tillhandahållande av tillgång till det. Det finns följande sätt att lösa detta problem:

Varje nod lagrar och använder sin egen datauppsättning som är tillgänglig för fjärrfrågor. Denna fördelning är uppdelad.
Vissa data som ofta används på avlägsna platser kan dupliceras. Denna fördelning kallas delvis duplicerad.
All data dupliceras vid varje nod. Denna fördelning kallas fullständigt duplicerad.
Vissa filer kan delas horisontellt (en delmängd av poster väljs) eller vertikalt (en delmängd av attributfält väljs), medan de valda delmängderna lagras i olika noder tillsammans med odelade data. Denna fördelning kallas split (fragmenterad).

När du skapar en distribuerad databas, på konceptuell nivå, måste du lösa följande uppgifter:

Det är nödvändigt att ha ett enda konceptuellt diagram över hela nätverket. Detta kommer att ge logisk insyn i data för användaren, som ett resultat av vilket han kommer att kunna skapa en begäran till hela databasen, bakom en separat terminal (det verkar fungera med en centraliserad databas).
Ett schema behövs för att lokalisera data i nätverket. Detta kommer att ge insyn i dataplaceringen, tack vare vilken användaren inte behöver ange vart den ska skicka förfrågan för att få den nödvändiga informationen.
Det är nödvändigt att lösa problemet med heterogenitet hos distribuerade databaser. Distribuerade databaser kan vara homogena eller heterogena vad gäller hårdvara och mjukvara. Problemet med heterogenitet är relativt lätt att lösa om den distribuerade databasen är heterogen i bemärkelsen hårdvara, men homogen i bemärkelsen mjukvara (samma DBMS i noderna). Om olika DBMS används i noderna i ett distribuerat system krävs verktyg för att konvertera datastrukturer och språk. Detta bör ge transparens för transformation över noderna i den distribuerade databasen.
Det är nödvändigt att lösa problemet med ordbokshantering. För att tillhandahålla all slags transparens i en distribuerad databas behöver du program som hanterar flera ordböcker och referensböcker.
Du måste definiera metoder för att köra frågor i en distribuerad databas. Metoder för att utföra frågor i en distribuerad databas skiljer sig från de i centraliserade databaser, eftersom enskilda delar av frågorna måste exekveras på platsen för motsvarande data och delresultat måste skickas till andra noder; samtidigt måste samordning av alla processer säkerställas.
Det är nödvändigt att lösa problemet med att köra parallella frågor. En distribuerad databas kräver en sofistikerad mekanism för samtidighetskontroll, som i synnerhet måste säkerställa synkronisering när information uppdateras, vilket säkerställer datakonsistens.
En avancerad metodik för att distribuera och placera data krävs, inklusive delning, är ett av huvudkraven för en distribuerad databas.

Ett av de aktivt utvecklande nya områdena för arkitektur av datorsystem, som är ett kraftfullt verktyg för icke-numerisk informationsbehandling, är databasmaskiner... Databasmaskiner används för att lösa icke-numeriska uppgifter som att lagra, söka och transformera dokument och fakta samt att arbeta med objekt. Efter definitionen av data som digital och grafisk information om objekt i omvärlden, är olika innehåll inbäddat i begreppet data i numerisk och icke-numerisk bearbetning. Numerisk bearbetning använder objekt som variabler, vektorer, matriser, flerdimensionella arrayer, konstanter och så vidare, medan icke-numerisk bearbetning använder objekt som filer, poster, fält, hierarkier, nätverk, relationer etc. icke-numerisk bearbetning är intresserad direkt i information om objekt (till exempel en specifik anställd eller en grupp anställda), och inte i registret över anställda som sådan. Filen med anställda indexeras inte här för att välja en specifik person; här är innehållet i den önskade posten mer intressant. Stora mängder information utsätts vanligtvis för icke-numerisk behandling. I olika applikationer kan du till exempel utföra följande operationer på denna data:

öka lönen för alla anställda i företaget;
beräkna bankräntan på alla kunders konton;
göra ändringar i listan över alla varor i lager;
hitta det nödvändiga sammandraget från alla texter som finns lagrade i biblioteket eller i det bibliografiska informationssökningssystemet;
hitta en beskrivning av det obligatoriska kontraktet i en fil som innehåller juridiska dokument;
bläddra igenom alla filer som innehåller beskrivningar av patent och hitta ett patent (om något) som liknar det föreslagna igen.

Att implementera databasmotorn, parallell och associativ arkitektur som ett alternativ till enprocessorvon Neumannstruktur, vilket gör det möjligt att arbeta med stora mängder information i realtid.

Databasmaskiner blir allt viktigare i samband med forskning och tillämpning av artificiell intelligenskoncept som kunskapsrepresentation, expertsystem, inferens, mönsterigenkänning m.m.

Informationslagringar. Idag erkänner många att redan nu driver de flesta företag flera databaser och för ett framgångsrikt arbete med information krävs inte bara olika typer av databaser utan olika generationer av DBMS. Enligt statistiken använder varje organisation i genomsnitt 2,5 olika DBMS. Det blev uppenbart behovet av att "isolera" företagens, eller snarare, de personer som är involverade i denna verksamhet, från de tekniska egenskaperna hos databaser, för att ge användarna en enda vy av företagsinformation, oavsett var den fysiskt lagras. Detta stimulerade framväxten av informationslagringsteknik ( Data Warehousing, DW).

Huvudsyftet med DW är skapa en enda logisk representation av data som finns i olika typer av databaser, eller, med andra ord, en enda företagsdatamodell.

Den nya omgången av DW-utveckling blev möjlig på grund av förbättringen av informationsteknik i allmänhet, i synnerhet uppkomsten av nya typer av databaser baserade på parallell frågebehandling, som i sin tur förlitade sig på framsteg inom området parallella datorer. Skapades frågebyggaremed ett intuitivt grafiskt gränssnitt, vilket gjorde det enkelt att bygga komplexa frågor till databasen. Olika mjukvarormellanlager (mellanvara)tillhandahållit kommunikationmellan olika typer av databaseroch slutligen föll kraftigtlagringsenheter.

En databank kan finnas i ett företags struktur.

Databas - Funktionell och organisatorisk komponent i automatiserade kontrollsystem och informations- och datorsystem, tillhandahållande av centraliserat informationsstöd för ett användarteam eller en uppsättning uppgifter lösta i systemet.

Databas betraktas som ett informations- och referenssystem, vars huvudsakliga syfte är:

i ackumulering och underhåll av en uppsättning information som utgör informationsbasen för hela det automatiserade systemet eller en viss uppsättning uppgifter lösta i det;
vid utfärdandet av de uppgifter som krävs av uppgiften eller användaren;
tillhandahållande av kollektiv åtkomst till lagrad information;
för att säkerställa den nödvändiga hanteringen av användningen av information som finns i informationsbasen.

Således är en modern databank ett komplext mjukvaru- och hårdvarukomplex, som inkluderar tekniska, system- och nätverksverktyg, databaser och DBMS, informationshämtningssystem för olika ändamål.

V .2. DBMS OCH STRUKTURELLA LÖSNINGAR I FÖRETAGSSYSTEM

Databas och kunskapshanteringssystem

En viktig komponent i moderna informationssystem är databashanteringssystem (DBMS).

DBMS - En uppsättning programvara och språkverktyg avsedda för att skapa, underhålla och använda databaser.

Databashanteringssystemet ger åtkomst av databehandlingssystem till databaser. Som redan nämnts får DBMS en viktig roll i skapandet av företagsinformationssystem och, en särskilt viktig roll, i skapandet av informationssystem som använder distribuerade informationsresurser baserade på modern nätverksdatorteknik.

Huvuddragen hos moderna DBMS är att moderna DBMS stöder teknologier som:

Klient-/serverteknik.
Stöd för databasspråk. denschemadefinitionsspråk DB (SDL - Schema Definition Language),datamanipulationsspråk (DML), integrerade språk SQL (Structured Queue Language), QDB (Query - By - Example) och QMF (Query Management Facility ) Är ett avancerat perifert frågespecifikations- och rapporteringsverktyg för DB 2, etc.;
Direkt datahantering i externt minne.
Hantering av RAM-buffertar.
Transaktionshantering. OLTP - teknik (On-Line transaktionsbearbetning), OLAP - teknologi (On-Line Analys Processing) för DW.
Säkerställ dataskydd och integritet. Användning av systemet är endast tillåtet för användare som har rätt att få tillgång till uppgifterna. När användare utför operationer på data bibehålls konsistensen av den lagrade datan (integriteten). Detta är viktigt i företagsinformationssystem för flera användare.
Journalisering.

Modernt DBMS måste säkerställa överensstämmelse med databaskraven som anges ovan. Dessutom måste de följa följande principer:

Dataoberoende.
Mångsidighet. DBMS måste ha kraftfullt stöd för konceptuella datamodeller för att visa anpassade logiska vyer.
Kompatibilitet. DBMS måste förbli i drift med utveckling av mjukvara och hårdvara.
Redundans av data. Till skillnad från filsystem måste en databas vara en enda samling av integrerade data.
Dataskydd. DBMS måste ge skydd mot obehörig åtkomst.
Dataintegritet. DBMS måste förhindra användare från att bryta databasen.
Hantering av samtidigt arbete. DBMS måste skydda databasen från inkonsekvenser i läget för delad åtkomst. För att säkerställa ett konsekvent tillstånd för databasen måste alla användarförfrågningar (transaktioner) utföras i en specifik ordning.
DBMS måste vara universellt. Det bör stödja olika datamodeller på en enda logisk och fysisk grund.
DBMS bör stödja både centraliserade och distribuerade databaser och därmed bli en viktig länk i datornätverk.

Med tanke på ett DBMS som en klass av mjukvaruprodukter fokuserade på att underhålla databaser i automatiserade system, kan vi urskilja två viktigaste funktioner som bestämmer typerna av DBMS. Enligt dem kan ett DBMS ses ur två synvinklar:

deras kapacitet i förhållande till distribuerade (företags)databaser;
deras relation till typen av datamodell implementerad i DBMS.

I förhållande till företags (distribuerade) databaser kan följande typer av DBMS villkorligt särskiljas:

DBMS "skrivbord". Dessa produkter är främst inriktade på att arbeta med personuppgifter ("desktop"-data). De har kommandouppsättningar för att dela gemensamma databaser, men små i storlek (som ett litet kontor). Först och främst är det en DBMS som Assess, dBASE, Paradox, EohPgo. Varför Assess, dBASE, Paradox, EohPgo har dålig tillgång till företagsdata. Poängen är att det inte finns något enkelt sätt att övervinna barriären mellan personlig och företagsinformation. Och poängen är inte ens att mekanismen för personlig data (eller små kontor) DBMS är fokuserad på att komma åt data genom många gateways, internetarbetande produkter, etc. Problemet är att dessa mekanismer vanligtvis är förknippade med fullständiga filöverföringar och brist på indexstöd, vilket resulterar i att serverköer praktiskt taget stannar på stora system.
Specialiserat högpresterande DBMS för flera användare. Sådana DBMS kännetecknas av närvaron av en fleranvändarsystemkärna, ett datamanipuleringsspråk och följande funktioner som är typiska för utvecklade DBMS:er för flera användare:
organisation av buffertpoolen;
närvaron av ett system för att behandla transaktionsköer;
närvaron av mekanismer för fleranvändardatalåsning;
transaktionsloggning;
tillgångskontrollmekanismer.

Dessa är DBMS som Oracle, DB2, SQL/Server, Informix, Sybase, ADABAS, Titanium och andra tillhandahåller en bred tjänst för bearbetning av företagsdatabaser.

När man arbetar med databaser används transaktionsmekanismen.

Transaktion Är en logisk arbetsenhet.

Transaktion är en sekvens av datamanipulationssatser som körssom helhet(allt eller inget) och översätta databasenfrån ett holistiskt tillstånd till ett annat holistiskt tillstånd.

En transaktion har fyra viktiga egenskaper, så kallade ASID-egenskaper:

(A) Atomicitet ... En transaktion utförs som en atomär operation - antingen utförs hela transaktionen eller så utförs den inte helt.
(C) Konsistens... En transaktion flyttar en databas från ett konsekvent (konsistent) tillstånd till ett annat konsekvent (konsistent) tillstånd. Inom en transaktion kan databaskonsistensen kränkas.
(I) Isolering ... Transaktioner från olika användare bör inte störa varandra (till exempel som om de utfördes strikt i tur och ordning).
(E) Hållbarhet... Om transaktionen är slutförd, bör resultaten av dess arbete sparas i databasen, även om systemet kraschar nästa ögonblick.

Transaktionen startar vanligtvis automatiskt från det ögonblick som användaren ansluter till DBMS och fortsätter tills en av följande händelser inträffar:

Kommando COMMIT WORK utfärdat.
Kommandot ROLLBACK WORK utfärdades.
Användaren har kopplat från DBMS.
Det var ett fel i systemet.

För brukaren bär hon vanligtvis atomär karaktär... I själva verket är detta en komplex användare (applikation) - databas interaktion mekanism. Programvara för företagssystem använder en transaktionsbearbetningsmotor i realtid (On-line Transaction Processing Systems, OLTP), i synnerhet bokföringsprogram, programvara för att ta emot och bearbeta kundorder, finansiella applikationer, producerar mycket information. Dessa system är designade (och lämpligt optimerade) för att hantera stora mängder data, komplexa transaktioner och intensiva läs-/skrivoperationer.

Tyvärr är informationen som placeras i OLTP-systemens databaser inte särskilt lämplig för användning av vanliga användare (på grund av den höga graden av normalisering av tabeller, specifika datapresentationsformat och andra faktorer). Därför skickas data från olika informationspipelines (i betydelsen kopieras) till lagerlager, sortering och efterföljande leverans till konsumenten. Inom informationsteknologin spelas lagrens roll avinformationslagringar.

Leverans av information till slutanvändaren - analytiska databehandlingssystem i realtid (Online analytisk bearbetning, OLAP)som ger extremt enkel tillgång till data genom bekväma sätt att generera frågor och analysera resultat. I OLAP-system ökar värdet av en informationsprodukt på grund av användningen av olika metoder för analys och statistisk bearbetning. Dessutom är dessa system optimerade när det gäller hastigheten för datautvinning, insamling av generaliserad information och riktar sig till vanliga användare (de har ett intuitivt gränssnitt). Om OLTP-system ger svar på enkla frågor som "hur var försäljningsnivån för produkt N i region M i januari 199x?", sedan OLAP-system redo för mer komplexa användarförfrågningar, till exempel: "Att ge en analys av försäljningen av produkt N i alla regioner enligt planen för andra kvartalet i jämförelse med de två föregående åren."

Klient/serverarkitektur

I moderna system distribuerad informationsbehandling, tekniken står i centrum klient-server. I systemet klient-server-arkitekturdatabehandlingen är uppdelad mellan klientdatorn och serverdatorn, mellan vilka kommunikationen sker över nätverket. Denna separation av databehandling baseras på grupperingen av funktioner. Vanligtvis är en databasserverdator dedikerad till att utföra databasoperationer, och en klientdator kör applikationsprogram. Figur 2.1 visar ett enkelt klient-server-arkitektursystem som inkluderar en dator som fungerar som server och en annan dator som fungerar som dess klient. Varje maskin utför olika funktioner och har sina egna resurser.

		Databas
Serverdator
Nätverk
IBM-kompatibel PC	IBM-kompatibel PC	IBM-kompatibel PC
		Ansökningar

Ris. 2.1. Klient-server-arkitektursystem

Klientdatorns huvudfunktion är att köra applikationen (användargränssnitt och presentationslogik) och kommunicera med servern när applikationen kräver det.

Server Är ett objekt (dator) som tillhandahåller tjänster till andra objekt på deras begäran.

Som följer av själva termen är serverdatorns huvudsakliga funktion att tillgodose kundens behov. Termen "Server" används för att hänvisa till två olika grupper av funktioner: en filserver och en databasserver (nedan betyder dessa termer, beroende på sammanhanget, antingen programvara som implementerar de specificerade grupperna av funktioner, eller datorer med denna programvara ). Filservrar är inte designade för att utföra databasoperationer, deras huvudsakliga funktion är att dela filer mellan flera användare, d.v.s. tillhandahåller samtidig åtkomst för många användare till filer på dator - filserver. Ett exempel på en filserver är Novells NetWare-operativsystem. Databasservern kan installeras och drivas på en filserverdator. Oracle DBMS i form av NLM (Network Loadable Module) exekveras i NetWare-miljön på filservern.

Den lokala nätverksservern måste ha de resurser som är lämpliga för dess funktionella syfte och nätverkets behov. Observera att på grund av fokus på öppna system-metoden är det mer korrekt att tala om logiska servrar (vilket betyder en uppsättning resurser och programvara som tillhandahåller tjänster över dessa resurser), som inte nödvändigtvis finns på olika datorer. En egenskap hos en logisk server i ett öppet system är att om det av effektivitetsskäl är tillrådligt att flytta servern till en separat dator, så kan detta göras utan behov av någon modifiering, både av sig själv och av applikationerna som använder det.

Ett av de viktiga serverkraven är att operativsystemet som är värd för databasservern måste vara multitasking (och helst, men inte nödvändigtvis, multianvändare). Till exempel kan en Oracle DBMS installerad på en persondator med ett MS-DOS (eller PC-DOS) operativsystem som inte uppfyller multitasking-kravet inte användas som en databasserver. Och samma Oracle-databas installerad på en dator med ett multitasking (men inte flera användare) OS / 2 operativsystem kan vara en databasserver. Många varianter av UNIX, MVS, VM och vissa andra operativsystem är både multitasking och multi-användare.

Distribuerad databehandling

Termen "distribuerad datoranvändning" används ofta för att hänvisa till två olika, om än kompletterande, begrepp:

Distribuerad databas;
Distribuerad databehandling.

Tillämpningen av dessa koncept gör det möjligt att organisera åtkomst till information lagrad på flera maskiner för slutanvändare med olika metoder.

Det finns många typer av servrar:

Databasserver;
Skrivarserver;
Fjärråtkomstserver;
Faxserver;
Webbserver osv.

I hjärtat av den underliggande tekniken är klient/server är sådana grundläggande teknologier som:

Operativsystemsteknologier, konceptet med interaktion mellan öppna system, skapandet av objektorienterade miljöer för programs funktion;
Telekommunikationsteknik;
Nätverksteknik;
Grafiska användargränssnittstekniker ( GUI);
Etc.

Fördelar med klient-server-teknik:

Klient-/serverteknik möjliggör beräkning i heterogena datormiljöer. Plattformsoberoende: Tillgång till heterogena nätverksmiljöer som inkluderar olika typer av datorer med olika operativsystem.
Oberoende från datakällor: tillgång till information från heterogena databaser. Exempel på sådana system är DB2, SQL/DS, Oracle, Sybase.
Belastningsbalans mellan klient och server.
Utför beräkningar där det är mest effektivt;
Ge förmågan att skala effektivt;
Platsöverskridande datoranvändning... Cross-platform computing definieras helt enkelt som implementering av teknologier i heterogena datormiljöer. Följande möjligheter bör ges här:
Applikationen måste köras på flera plattformar;
Den måste ha samma gränssnitt och logik på alla plattformar;
Applikationen måste integreras med den ursprungliga operativa miljön;
Det ska bete sig likadant på alla plattformar;
Enkelt och konsekvent stöd bör ges för det.

 Distribuerad databehandling. Distribuerad datoranvändning innebär fördelning av arbete mellan flera datorer (även om distribuerad datoranvändning är ett bredare begrepp).

 Neddragning. Downsizing är portering av stordatorapplikationer till små datorplattformar.

Minskade kostnader för infrastruktur och hårdvara. Ekonomiskt: Tillgången till billig datorutrustning och den ökande spridningen av lokala nätverk gör klient-server-tekniken mer ekonomisk än annan databehandlingsteknik. Utrustningen kan uppgraderas så snart behov uppstår.

 Att minska den totala körtiden för applikationen;

 Minska klientminnesanvändning;

 Minska nätverkstrafiken.

Förmåga att arbeta med multimedia: hittills har många multimediaprogram skapats för PC. Det finns inga sådana program för terminal-värd-konfigurationen, eller så är de mycket dyra.
Möjligheten att attrahera stora datorresurser för databasoperationer: eftersom applikationer körs på klientdatorer frigörs ytterligare (jämfört med terminal-värdkonfigurationen) resurser på serverdatorn för databasoperationer, såsom datorresurser för den centrala processorn och driftminne.
Bättre programmerarproduktivitet: Programmerarproduktiviteten ökas genom att använda verktyg som SQL * Forms och CASE, som låter dig utveckla applikationer snabbare än programmeringsspråk som C, PL1 eller COBOL.
Ökad slutanvändarproduktivitet: Nuförtiden har många slutanvändare bemästrat system som Lotus, Paradox, Word Perfect, Harvard Graphics, etc.

Gränssnittet på serversidan är definierat och fixat. Därför är det möjligt att skapa nya klientdelar av ett befintligt system (ett exempel på interoperabilitet på systemnivå).

Ris. 2.2. Illustration av klientåtkomst till en serverresurs.

Hur man implementerar klient-server-teknik

Installationen av ett system baserat på klient-server-teknologi och som kan utföra distribuerad databehandling diskuteras nedan. Följande maskinvara och programvara krävs:

databasserverdator;
klientdatorer;
kommunikationsnätverk;
nätverksprogramvara;
programvara.

SQL-språk ... Frågespråk på hög nivå - SQL (Structured Query Language ) tjänar till att implementera frågor till databaser, såsom YAMD, YOD och PNP och används som standard. Språk SQL antogs ursprungligen som dataspråk för företagets mjukvaruprodukter IBM och YAMD relations-DBMS SYSTEM R från IBM ... Ett viktigt inslag i språket SQL är att ett och samma språk presenteras genom två olika gränssnitt, nämligen: genom ett interaktivt gränssnitt och genom ett applikationsprogrammeringsgränssnitt (dynamiskt SQL). Dynamisk SQL består av många inbyggda språkfunktioner SQL , tillhandahålls specifikt för konstruktion av interaktiva applikationer, där en interaktiv applikation förstås som ett program som är skrivet för att stödja åtkomst till databasen för en slutanvändare som arbetar på en interaktiv terminal. Språk SQL tillhandahåller funktionerna för att definiera, manipulera och hantera databasdata och är transparent för användaren från den implementerade DBMS-synpunkten.

Ris. 2.3. Schema för att köra användarfrågor till distribuerade databaser.

Databasernas interna struktur bestäms av de datamodeller som används. Den konceptuella modellen har mer abstraktionsförmåga och rikare semantik än externa modeller. Externa modeller hänvisas ofta till som syntaktiska eller operativa modeller, med hänvisning till den syntaktiska karaktären hos kontroll och användning som ett sätt för användarinteraktion med databasen. Inom informationsmodellering finns det olika abstraktionsnivåer, från den konceptuella modellnivån till den fysiska datamodellnivån, som påverkar DBMS:s arkitektur.

Datamodellen har tre komponenter:

Datastrukturen att representera från användarens synvinkel av databasen.
Giltiga operationer utförda på datastrukturen. Det är nödvändigt att kunna arbeta med denna struktur med hjälp av olika NOD- och NMD-operationer. En rik struktur är värdelös om det inte finns något sätt att manipulera dess innehåll.
Integritetskontrollbegränsningar. Datamodellen måste förses med medel för att upprätthålla sin integritet och skydda den. Som ett exempel, betrakta följande två begränsningar:
Varje underträd måste ha en källnod. I hierarkiska databaser kan du inte lagra underordnade noder utan en källnod.
Med avseende på en relationsdatabas kan det inte finnas identiska tupler. För en fil kräver detta krav att alla poster är unika.

En av de viktigaste egenskaperna hos ett DBMS är förmågan att länka objekt.

Det finns följande typer av länkar mellan objekt:

En-till-en (1:1)... Ett objekt i en uppsättning kan associeras med ett objekt i en annan uppsättning.
En-till-många (1:M)... Ett objekt i en uppsättning kan associeras med många objekt i en annan uppsättning.
Många-till-många (M:N)... Ett objekt i en uppsättning kan associeras med många objekt i en annan uppsättning, men samtidigt kan ett objekt i en annan uppsättning associeras med många objekt i den första uppsättningen.
Förgrenad ... Ett objekt i en uppsättning kan associeras med objekt av många uppsättningar.
Rekursiv ... Ett objekt i en given uppsättning kan länkas av ett objekt i samma uppsättning.

Följande grundläggande datamodeller finns:

Relationsdatamodell.
Hierarkisk datamodell.
Ofullständig nätverksdatamodell.
CODASYL datamodell.
Utökad nätverksdatamodell.

V.3. INTERNET / INTRANET-TEKNIKER OCH LÖSNINGAR FÖR ÅTKOMST FÖR FÖRETAGS DATABAS

Huvudproblemet med system baserade på klient-server-arkitekturen är att, i enlighet med konceptet med öppna system, krävs att de är mobila i bredast möjliga klass av hård- och mjukvarulösningar för öppna system. Även om vi begränsar oss till UNIX-baserade lokala nätverk, använder olika nätverk olika utrustning och kommunikationsprotokoll. Försök att skapa system som stöder alla möjliga protokoll leder till att de överbelastas med nätverksdetaljer på bekostnad av funktionaliteten.

En ännu mer komplex aspekt av detta problem är förknippad med möjligheten att använda olika representationer av data i olika noder i ett heterogent lokalt nätverk. Olika datorer kan ha olika adressering, nummerrepresentation, teckenkodning osv. Detta är särskilt viktigt för servrar på hög nivå: telekommunikation, datorer, databaser.

En vanlig lösning på problemet med mobilitet i system baserade på en klient-server-arkitektur är att förlita sig på programvarupaket som implementerar Remote Procedure Call (RPC)-protokoll. Med dessa verktyg ser ett anrop till en tjänst på en fjärrplats ut som ett normalt proceduranrop. RPC-verktyg, som naturligtvis innehåller all information om detaljerna för den lokala nätverkshårdvaran och nätverksprotokollen, översätter samtalet till en sekvens av nätverksinteraktioner. Således är specifikationerna för nätverksmiljön och protokoll dolda för applikationsprogrammeraren.

När en fjärrprocedur anropas konverterar RPC-program klientdataformat till mellanliggande maskinoberoende format och konverterar sedan till serverdataformat. När svarsparametrarna passeras utförs liknande transformationer.

Andra liknande verk som kan intressera dig. Wshm>
6914.		Databas koncept	11,56 kB
	Databasen presenteras i en objektiv form, en uppsättning oberoende material av artiklar av beräkningar av normativa handlingar av domstolsbeslut och annat liknande material systematiserat på ett sådant sätt att dessa material kan hittas och bearbetas med hjälp av en elektronisk dator Civil Code of the Russian Federation Art. En databas organiserad i enlighet med vissa regler och bevarad i datorns minne är en uppsättning data som kännetecknar det aktuella tillståndet för vissa ...
8064.		Distribuerade databaser	43,66 kB
	Distribuerade databaser En distribuerad databas RDB förstås som en uppsättning logiskt sammankopplade delade data som är fysiskt distribuerade över olika noder i ett datornätverk. Dataåtkomst bör inte bero på närvaron eller frånvaron av datarepliker. Systemet bör automatiskt bestämma metoderna för att utföra datafusionsanslutningen, nätverkskanalen kan klara av mängden överförd information och noden har tillräcklig processorkraft för att gå med i tabellerna. RDBMS måste kunna ...
20319.		DATABASER OCH DERAS SKYDD	102,86 KB
	Online onlinedatabaser uppstod i mitten av 1960-talet. Operationer på operativa databaser bearbetades interaktivt med hjälp av terminaler. Enkla indexsekventiella skivorganisationer utvecklades snabbt till en mer kraftfull uppsättningsorienterad skivmodell. Charles Bachmann fick Turing-priset för att ha lett Data Base Task Group (DBTG), som utvecklade ett standardspråk för databeskrivning och datamanipulation.
5031.		Databasutvecklingsbibliotek	11,72 MB
	Databasdesignteknik. Bestämma relationer mellan enheter och skapa en datamodell. Huvudidéerna för modern informationsteknologi är baserade på konceptet enligt vilket data bör organiseras i databaser för att på ett adekvat sätt återspegla den föränderliga verkliga världen och möta användarnas informationsbehov. Dessa databaser skapas och fungerar under kontroll av speciella mjukvarusystem som kallas databashanteringssystem DBMS.
13815.		DATABAS HIERARKISK MODELL	81,62 kB
	Huvudidéerna för modern informationsteknologi är baserade på begreppet databaser, enligt vilken grunden för informationsteknologi är data organiserade i databaser som adekvat återspeglar tillståndet för ett visst ämnesområde och ger användaren relevant information inom detta ämnesområde. Det måste erkännas att uppgifterna är ...
14095.		Utveckling av biblioteksdatabas	11,72 MB
	Ökningen av volymen och strukturell komplexitet hos lagrad data, utvidgningen av kretsen av användare av informationssystem har lett till den utbredda användningen av det mest bekväma och relativt lättförståeliga relations-(tabell)DBMS.
5061.		Skapande av poliklinikens databas	2,4 MB
	Utvecklingen av datateknik och informationsteknik har gett möjligheter till skapande och utbredd användning av automatiserade informationssystem (AIS) för olika ändamål. Informationssystem för att hantera ekonomiska och tekniska anläggningar utvecklas och implementeras
13542.		Geologiska informationsdatabaser	20,73 kB
	Nyligen har införandet av datorteknik och i synnerhet databaser på det vetenskapliga området gått snabbt. Denna process går inte heller förbi geologin, eftersom det är inom naturvetenskapen som det finns ett behov av att lagra och bearbeta stora mängder information.
9100.		Databas. Grundläggande koncept	26,28 kB
	En databas är en samling information om specifika objekt i den verkliga världen inom vilket ämnesområde som helst inom ekonomi, förvaltning, kemi, etc. Syftet med ett informationssystem är inte bara lagring av data om objekt, utan också manipulation av dessa data , med hänsyn till kopplingar mellan objekt. Varje objekt kännetecknas av en uppsättning egenskapsdata, som kallas attribut i databasen.
5240.		Skapande av databasen "Dekanus vid universitetet"	1,57 MB
	Databas (DB) är en uppsättning sammankopplade data lagrade tillsammans på externa lagringsmedier på en dator, med en sådan organisation och minimal redundans som gör att de kan användas på ett optimalt sätt för en eller flera applikationer

Syftet med föreläsningen

Efter att ha studerat materialet i denna föreläsning kommer du att veta:

Vad företagsdatamodell ;
hur man konverterar företagsdatamodell in i datalagermodellen;
huvudelement företagsdatamodell ;
presentationslager av företagsdatamodellen ;
en algoritm för att omvandla en företagsdatamodell till en multidimensionell datalagermodell ;

och lär dig:

utveckla datalagermodeller utifrån företagsdatamodell organisationer;
designa ett stjärnschema med hjälp av CASE-verktyg;
partitionstabeller flerdimensionell modell använda CASE-verktyg.

Företagsdatamodell

Introduktion

Kärnan i varje HD är dess datamodell. Utan en datamodell blir det mycket svårt att organisera data i HD. Därför bör HD-utvecklare lägga tid och kraft på att utveckla en sådan modell. Utvecklingen av HD-modellen faller på HD-designerns axlar.

Jämfört med designen av OLTP-system, har designmetodologin för CD ett antal utmärkande drag förknippade med orienteringen av datalagrets datastrukturer för att lösa problemen med analys och informationsstöd i beslutsprocessen. HD-datamodellen bör ge en effektiv lösning på just dessa uppgifter.

Utgångspunkten i utformningen av CD kan vara den sk företagsdatamodell(företagsdatamodell eller företagsdatamodell, EDM), som skapas i processen att designa en organisations OLTP-system. Vid design företagsdatamodell vanligtvis görs ett försök att skapa en datastruktur baserad på affärsverksamhet som skulle samla in och syntetisera alla informationsbehov i organisationen.

Således, företagsdatamodell innehåller nödvändig information för att bygga en CD-modell. Därför, i det första skedet, om en sådan modell finns i organisationen, HD-designern kan starta HD-designen genom att lösa transformationsproblemet företagsdatamodell till HD-modellen.

Företagsdatamodell

Hur man löser transformationsproblemet företagsdatamodell till HD-modellen? För att lösa detta problem behöver du ha denna modell, d.v.s. företagsdatamodell ska byggas och dokumenterat... Och du måste förstå Vad från denna modell och hur bör omvandlas till HD-modellen.

Låt oss förtydliga konceptet från en CD-designers synvinkel företagsdatamodell. Under företagsdatamodell förstå den skiktade, strukturerade beskrivningen av en organisations ämnesområden, ämnesområdes datastrukturer, affärsprocesser och affärsprocedurer, organisatoriska dataflöden, tillståndsdiagram, dataprocessmatriser och andra modellrepresentationer som används i organisationens verksamhet. Alltså, i ordets vidaste bemärkelse, företagsdatamodellär en uppsättning modeller på olika nivåer som kännetecknar (modellerar på någon abstrakt nivå) en organisations aktiviteter, d.v.s. innehåll företagsmodell beror direkt på vilka modellkonstruktioner som ingick i den i en given organisation.

Huvudelementen företagsdatamodellär:

beskrivning av organisationens ämnesområden (definition av verksamhetsområden);
relationer mellan ämnesområdena definierade ovan;
informationsdatamodell (ERD-modell eller "entity-relationship"-modell);
beskrivning för varje ämnesområde:
- enhetsnycklar;
- enhetsattribut;
- undertyper och supertyper;
- relationer mellan enheter;
- gruppera attribut;
- relationer mellan ämnesområden;
funktionell eller affärsprocessmodell;
dataflödesdiagram;
tillståndsdiagram;
andra modeller.

Således, företagsdatamodell innehåller enheter, attribut och relationer som representerar en organisations informationsbehov. I fig. 16.1 visar huvudelementen företagsdatamodell.

Presentationsnivåer för företagsdatamodellen

Företagsdatamodellen är kategoriserad efter ämnesområden, som representerar grupper av enheter relaterade till att stödja specifika affärsbehov. Vissa ämnesområden kan täcka specifika affärsfunktioner såsom kontraktshantering, medan andra kan omfatta enheter som beskriver produkter eller tjänster.

Varje logisk modell måste motsvara den befintliga domänen företagsdatamodell... Om den logiska modellen inte uppfyller detta krav måste en domänmodell läggas till den.

En företagsdatamodell har vanligtvis flera presentationsnivåer. Faktiskt hög nivå(hög nivå) företagsdatamodell det finns en beskrivning av organisationens huvudsakliga ämnesområden och deras relationer på enhetsnivå. I fig. 16.2 är ett utdrag företagsdatamodell högsta nivån.

Ris. 16.2.

Diagrammet som visas i figuren representerar fyra ämnesområden: "Köpare" ( Kund), "Kontrollera" ( konto), "Beställa" ( Beställa) och "Produkt" ( Produkt). Som regel bara direkta anslutningar mellan ämnesområden, som till exempel registrerar följande faktum: köparen betalar fakturan för beställningen av varor. Detaljer och indirekta relationer på denna nivå företagsmodell inte visad.

På nästa, mellannivå(mellannivå) företagsdatamodell visar detaljerad information om föremål i ämnesområden, d.v.s. nycklar och enhetsattribut, deras relationer, undertyper och supertyper, etc. För varje domän i toppnivåmodellen finns det en mellannivåmodell. I fig. 16.3 visar presentationens mellannivå företagsmodell för ett fragment av ämnesområdet "Ordning".

Fikon. 16.3 kan man se att ämnesområdet "Beställ" ( Beställa) inkluderar flera enheter, definierade genom deras attribut, och relationerna mellan dem. Den presenterade modellen låter dig svara på frågor som datum för beställningen, vem som gjorde beställningen, vem som skickade beställningen, vem som tar emot beställningen och ett antal andra. Från diagrammet ovan kan det ses att det i denna organisation finns två typer av beställningar - beställningar för en kampanj ( Kommersiellt) och detaljhandelsbeställningar ( Detaljhandeln).

Lägg märke till att företagsdatamodell kan representera olika aspekter av organisationens verksamhet och med varierande detaljeringsgrad och fullständighet. Om företagsmodell representerar alla aspekter av organisationens verksamhet, kallas det också organisationsdatamodell(företagsdatamodell).

Ur synvinkel att designa en CD, en viktig faktor i beslutet att skapa en CD-modell från företagsdatamodellär staten fullständighet företagsdatamodell.

En organisations företagsdatamodell har karaktären av evolution, d.v.s. det utvecklas och förbättras hela tiden. Vissa ämnesområden företagsdatamodell kan vara väl utvecklad, för vissa kanske arbetet inte har börjat ännu. Om ett fragment av ämnesområdet inte är utarbetat i företagsdatamodell, då finns det inget sätt att använda denna modell som utgångspunkt för designen av CD.

Genomförande examen företagsmodell kan utjämnas i utformningen av CD enligt följande. Eftersom HD-utvecklingsprocessen vanligtvis är uppdelad i tid i en sekvens av steg, kan processen för dess design synkroniseras med färdigställandeprocess utveckling av enskilda fragment företagsdatamodell organisationer.

Som lägst presentationslager av företagsdatamodellen information om de fysiska egenskaperna hos databasobjekt motsvarande logisk datamodell mitten presentationslager av företagsdatamodellen.

Zaitsev S.L., Ph.D.

Upprepade grupper

Dubblettgrupper är attribut för vilka en enskild instans av en enhet kan ha mer än ett värde. Till exempel kan en person ha mer än en färdighet. Om vi, när det gäller affärskrav, behöver känna till kompetensnivån för var och en, och varje person bara kan ha två färdigheter, kan vi skapa enheten som visas i fig. 1.6. Här är enheten EN PERSON med två attribut för att lagra färdigheter och färdighetsnivå för varje.

Ris. 1.6. Det här exemplet använder upprepade grupper.

Problemet med att upprepa grupper är att vi inte kan veta exakt hur många färdigheter en person kan ha. I verkliga livet har vissa människor en färdighet, vissa har flera och andra har ingen ännu. Figur 1.7 visar modellen reducerad till den första normalformen. Notera det tillagda Färdighets-ID som var och en identifierar unikt SKICKLIGHET.

Ris. 1.7. Modell reducerad till första normalform.

Ett faktum på ett ställe

Om samma attribut finns i mer än en enhet och inte är en främmande nyckel, anses detta attribut vara överflödigt. Den logiska modellen bör inte innehålla redundanta data.

Redundans kräver ytterligare utrymme, men även om minneseffektivitet är viktigt, ligger det verkliga problemet någon annanstans. Att se till att redundant data synkroniseras är overhead, och du löper alltid risk för motstridiga värden.

I föregående exempel SKICKLIGHET beror på Person-ID och från Färdighets-ID. Det betyder att du inte kommer att ha SKICKLIGHET tills det dyker upp EN PERSON, besitter denna färdighet. Detta gör det också svårt att ändra kompetensnamnet. Det är nödvändigt att hitta varje post med namnet på färdigheten och ändra det för varje person som äger denna färdighet.

Figur 1.8 visar modellen i andra normalform. Observera att den tillagda enheten SKICKLIGHET, och attributet TITEL kompetensen överförs till denna enhet. Skicklighetsnivån höll sig, respektive, i korsningen PERSONER OCH FÄRDIGHET.

Ris. 1.8. I den andra normala formen flyttas den upprepande gruppen till en annan enhet. Detta ger flexibiliteten att lägga till det nödvändiga antalet färdigheter och ändra färdighetsnamnet eller färdighetsbeskrivningen på ett ställe.

Varje attribut beror på nyckeln

Varje attribut för en entitet måste bero på den primära nyckeln för den entiteten. I föregående exempel Skolnamn och Geografiskt område finns i tabellen EN PERSON men beskriv inte personen. För att uppnå den tredje normala formen måste du flytta attributen till enheten, där de kommer att bero på nyckeln. Figur 1.9. visar modellen i tredje normalform.

Ris. 1.9. I tredje normalform Skolnamn och Geografisk regionöverförs till entitet, där deras värden beror på nyckeln.

Många-till-många relationer

Relation många-till-många spegla verkligheten i omvärlden. Observera att i figur 1.9 finns det ett många-till-många-samband mellan PERSONLIG och SKOLA... Attityden återspeglar exakt det faktum att EN PERSON kan studera i många SKOLOR och i SKOLA kan lära sig mycket PERSON. För att uppnå den fjärde normala formen skapas en associativ enhet som eliminerar monogin-till-många-relationen genom att generera en separat post för varje unik kombination av skola och person. Figur 1.10 visar modellen i fjärde normalform.

Ris. 1.10. I fjärde normalform, en monogo-till-många-relation mellan PERSONLIG och SKOLA lösas genom att införa en associativ enhet, där en separat post tilldelas för varje unik kombination SKOLOR och PERSONER.

Formella definitioner av normala former

Följande definitioner av normala former kan verka skrämmande. Se dem helt enkelt som formler för att uppnå normalisering. Normalformer bygger på relationalgebra och kan tolkas som matematiska transformationer. Även om den här boken inte ägnas åt en detaljerad diskussion om normala former, uppmuntras modellbyggare att ta en djupare titt på ämnet.

I en given relation R beror Y-attributet funktionellt på X-attributet. I symbolisk form, RX -> RY (läs som "RX definierar funktionellt RY") - om och endast om varje X-värde i R är associerat med exakt ett Y värde i R (vid varje given tidpunkt). Attributen X och Y kan vara sammansatta (Datum CJ. Introduction to Database Systems. 6:e upplagan. Ed. Williams: 1999, 848 s.).

Relationen R motsvarar den första normalformen (1NF) om och endast om alla domäner som hör till den endast innehåller atomvärden (Datum, ibid.).

En relation R motsvarar andra normalformen (2NF) om och endast om den motsvarar 1NF, och varje icke-nyckelattribut är helt beroende av primärnyckeln (Datum, ibid.).

Relationen R motsvarar tredje normalformen (3NF) om och endast om den motsvarar 2NF, och varje icke-nyckelattribut inte transitivt beror på primärnyckeln (Datum, ibid.).

Relationen R motsvarar Boyes-Codd normalform (BCNF) om och endast om varje determinant är en kandidat för användning som nyckel.

NOTERA Nedan följer en kort förklaring av några av de förkortningar som används i Dates definitioner.

MVD (multi-valued dependency) är ett multi-valued dependency. Används endast för enheter med tre eller fler attribut. I ett beroende med flera värden beror värdet på attributet endast på en del av primärnyckeln.

FD (funktionellt beroende) - funktionellt beroende. Med funktionellt beroende beror värdet på ett attribut på värdet av ett annat attribut som inte är en del av primärnyckeln.

JD (join dependency) är ett join-beroende. I ett förbundsberoende spåras den primära nyckeln för den överordnade enheten tillbaka till åtminstone den tredje nivåns ättlingar, samtidigt som den behåller förmågan att användas i föreningen av den ursprungliga nyckeln.

Förhållandet motsvarar den fjärde normalformen (4NF) om och endast om det finns en MVD i R, till exempel A®®B. Dessutom är alla R-attribut funktionellt beroende av A. Med andra ord innehåller R endast beroenden (FD eller MVD) av K®X-formen (dvs. X-attributets funktionella beroende av kandidaten för användning som nyckel K). Följaktligen uppfyller R kraven i 4NF om den uppfyller BCNF och alla MVD:er faktiskt är FD:er (Datum, ibid.).

För den femte normalformen uppfyller relationen R unionsberoendet (JD) * (X, Y,..., Z) om och endast om R är ekvivalent med dess projektioner på X, Y, ..., Z, där X, Y ,..., Z är en delmängd av uppsättningen attribut R.

Det finns många andra normala former för komplexa datatyper och specifika situationer som ligger utanför ramen för denna diskussion. Vilken modellentusiast som helst vill också lära sig andra normala former.

Affärs normala former

I sin bok tog Clive Finklestein (An Introduction to Information Engineering: From Strategic Planning to Information Systems. Reading, Massachusetts: Addison-Wesley, 1989) ett annat förhållningssätt till normalisering. Den definierar affärsnormala former i termer av tvång till dessa former. Många modellerare tycker att detta tillvägagångssätt är mer intuitivt och mer pragmatiskt.

Den första affärsnormala formen (1BNF) tar ut dubbletter av grupper till en annan enhet. Denna enhet får sitt eget namn och primära (sammansatta) nyckelattribut från den ursprungliga enheten och dess återkommande grupp.

Den andra affärsnormala formen (2BNF) tar ut attribut som delvis är beroende av primärnyckeln till en annan enhet. Den primära (sammansatta) nyckeln för denna entitet är den primära nyckeln för den entitet där den ursprungligen fanns, tillsammans med ytterligare nycklar som attributet helt beror på.

Den tredje affärsnormala formen (3BNF) tar attribut som är oberoende av en primärnyckel till en annan enhet, där de är helt beroende av den primära nyckeln för den enheten.

Den fjärde affärsnormala formen (4BNF) tar attribut som beror på värdet av primärnyckeln eller är valfria för en sekundär enhet, där de helt beror på värdet på primärnyckeln, eller där de (nödvändigtvis) måste finnas i den entitet.

Den femte affärsnormala formen (5BNF) visas som en strukturell enhet om det finns ett rekursivt eller annat beroende mellan instanser av en sekundär enhet, eller om det finns ett rekursivt beroende mellan instanser av dess primära enhet.

Genomförd logisk datamodell

Den färdiga logiska modellen måste uppfylla kraven i den tredje affärsnormala formen och inkludera alla enheter, attribut och relationer som är nödvändiga för att stödja de datakrav och affärsregler som är kopplade till data.

Alla enheter måste ha namn som beskriver deras innehåll och ha en tydlig, koncis, fullständig beskrivning eller definition. Ett framtida inlägg kommer att täcka en första uppsättning riktlinjer för korrekt bildande av enhetsnamn och beskrivningar.

Relationer bör innehålla en verbkonstruktion som beskriver förhållandet mellan entiteter, tillsammans med egenskaper som pluralitet, nödvändigheten av existens eller möjligheten till frånvaro av en relation.

NOTERA Mångfald relation beskriver det maximala antalet sekundära entitetsinstanser som kan associeras med en instans av den ursprungliga entiteten.Nödvändighet av existens ellermöjlighet till frånvaro relation används för att bestämma det minsta antalet instanser av en sekundär enhet som kan associeras med en instans av den ursprungliga enheten.

Fysisk datamodell

När en komplett och adekvat logisk modell har skapats är du redo att fatta ett beslut om valet av en implementeringsplattform. Valet av plattform beror på kraven för användningen av data och de strategiska principerna för att forma företagets arkitektur. Val av plattform är en komplex fråga utanför denna bok.

I ERwin är en fysisk modell en grafisk representation av en databas i den verkliga världen. Den fysiska databasen kommer att bestå av tabeller, kolumner och relationer. Den fysiska modellen beror på vilken plattform som valts för implementering och kraven för att använda data. Den fysiska modellen för IMS kommer att skilja sig mycket från den för Sybase. Den fysiska modellen för OLAP-rapporter kommer att se annorlunda ut än modellen för OLTP (online transaktionsbearbetning).

Datamodelleraren och databasadministratören (DBA) använder den logiska modellen, användningskraven och strategiska principer för företagsarkitektur för att utveckla en fysisk datamodell. Du kan avnormalisera den fysiska modellen för att förbättra prestandan och skapa vyer för att stödja användningskrav. Följande avsnitt beskriver processen för att denormalisera och skapa vyer.

Det här avsnittet ger en översikt över processen för att bygga en fysisk modell, samla in dataanvändningskrav, definiera komponenterna i en fysisk modell och tillhandahålla omvänd konstruktion. I följande publikationer behandlas dessa frågor mer i detalj.

Samla in krav på dataanvändning

Vanligtvis samlar du in krav på dataanvändning tidigt under intervjuer och arbetssessioner. Samtidigt bör kraven så fullständigt som möjligt avgöra användarens användning av data. Den ytliga attityden och luckorna i den fysiska modellen kan leda till oplanerade kostnader och förseningar i projektgenomförandet. Krav för användning inkluderar:

Krav på åtkomst och prestanda

Volumetriska egenskaper (en uppskattning av mängden data som ska lagras) som gör att administratören kan representera databasens fysiska volym

Uppskattning av antalet användare som behöver åtkomst till data samtidigt för att hjälpa dig designa din databas för acceptabla prestandanivåer

Aggregat, sammanfattning och annan beräknad eller härledd data som kan anses vara kandidater för lagring i beständiga datastrukturer

Rapporteringskrav och standardfrågor för att hjälpa databasadministratören att bygga index

Vyer (beständiga eller virtuella) som hjälper användaren att utföra dataaggregering eller filtrering.

Förutom ordföranden, sekreteraren och användarna måste modelleraren, databasadministratören och databasarkitekten delta i användningskravssessionen. Användarens krav på historiska data bör diskuteras. Tiden som data lagras har en betydande inverkan på databasens storlek. Äldre data lagras ofta i en generaliserad form, och atomära data arkiveras eller raderas.

Användare bör ta med sig exempel på förfrågningar och rapporter till sessionen. Rapporter måste vara strikt definierade och måste innehålla atomvärden som används för alla sammanfattningar och sammanfattningsfält.

Komponenter för fysiska datamodeller

Komponenterna i en fysisk datamodell är tabeller, kolumner och relationer. Logiska modellenheter kommer sannolikt att bli tabeller i den fysiska modellen. Booleska attribut blir kolumner. Logiska relationer kommer att bli begränsningar för relationernas integritet. Vissa logiska relationer kan inte implementeras i en fysisk databas.

Reverse engineering

När en logisk modell inte är tillgänglig blir det nödvändigt att återskapa modellen från den befintliga databasen. I ERwin kallas denna process reverse engineering. Reverse engineering kan göras på flera sätt. Modellören kan utforska datastrukturerna i databasen och återskapa tabeller i en visuell modelleringsmiljö. Du kan importera datadefinitionsspråk (DDL) till ett verktyg som stöder reverse engineering (som Erwin). Avancerade verktyg som ERwin inkluderar funktioner som ger ODBC-kommunikation med en befintlig databas för att skapa en modell genom att direkt läsa datastrukturer. Reverse engineering med ERwin kommer att diskuteras i detalj i ett framtida inlägg.

Använda företagets funktionella gränser

När man bygger en logisk modell för en modellerare är det viktigt att se till att den nya modellen överensstämmer med företagsmodellen. Att använda företags funktionella gränser innebär att modellera data i termer som används inom ett företag. Hur data används i ett företag förändras snabbare än själva data. I varje logisk modell måste data presenteras på ett holistiskt sätt, oavsett vilken affärsdomän den stöder. Entiteter, attribut och relationer måste definiera affärsregler på företagsnivå.

NOTERA Några av mina kollegor hänvisar till dessa företags funktionella gränser som modellering i verkligheten. Verklig modellering uppmuntrar modelleraren att se information i termer av dess faktiska inneboende relationer och relationer.

Användningen av företagets funktionella gränser för en datamodell som är konstruerad på lämpligt sätt ger grunden för att stödja informationsbehoven för ett antal processer och applikationer, vilket gör det möjligt för företaget att mer effektivt utnyttja en av sina mest värdefulla tillgångar, information.

Vad är en Enterprise Data Model?

Enterprise Data Model (EDM) innehåller enheter, attribut och relationer som representerar ett företags informationsbehov. EDM kategoriseras vanligtvis efter ämnesområden, som representerar grupper av enheter relaterade till att stödja specifika affärsbehov. Vissa ämnesområden kan täcka specifika affärsfunktioner såsom kontraktshantering, medan andra kan omfatta enheter som beskriver produkter eller tjänster.

Varje logisk modell måste motsvara den befintliga domänen för företagsdatamodellen. Om den logiska modellen inte uppfyller detta krav måste en domänmodell läggas till den. Denna jämförelse säkerställer att företagsmodellen förbättras eller justeras och att alla logiska modelleringsinsatser samordnas inom företaget.

EDM inkluderar även specifika enheter som definierar omfattningen av värden för nyckelattribut. Dessa enheter har inga föräldrar och definieras som oberoende. Oberoende enheter används ofta för att upprätthålla integriteten i relationer. Dessa entiteter identifieras med flera olika namn, såsom kodtabeller, referenstabeller, typtabeller eller klassificeringstabeller. Vi kommer att använda termen "företagets affärsobjekt". Ett företags affärsobjekt är en enhet som innehåller en uppsättning attributvärden som är oberoende av någon annan enhet. Företagens affärsobjekt bör användas konsekvent inom ett företag.

Bygga en företagsdatamodell genom att utöka

Det finns organisationer där företagsmodellen har byggts upp från början till slut som ett resultat av en enda samlad insats. Å andra sidan bygger de flesta organisationer ganska kompletta företagsmodeller genom att skala upp.

Att bygga upp innebär att bygga något sekventiellt, lager för lager, precis som ett ostron växer en pärla. Varje datamodell som skapas ger ett bidrag till bildandet av EDM. Att bygga en EDM på detta sätt kräver ytterligare modelleringssteg för att lägga till nya datastrukturer och domäner eller utöka befintliga datastrukturer. Detta gör det möjligt att bygga en företagsdatamodell genom att utöka, iterativt lägga till detaljnivåer och förfining.

Modellering metodik koncept

Det finns flera metoder för visuell datamodellering. ERwin stöder två:

IDEF1X (Integration Definition for Information Modeling - en integrerad beskrivning av informationsmodeller).

IE (Informationsteknik).

IDEF1X är en bra metod och användningen av dess notation är utbredd

Integrerad beskrivning av informationsmodeller

IDEF1X är en mycket strukturerad datamodelleringsmetod som utökar IDEF1-metoden som antagits som FIPS-standard (Federal Information Processing Standards). IDEF1X använder en mycket strukturerad uppsättning modelleringskonstruktionstyper och resulterar i en datamodell som kräver en förståelse av datas fysiska natur innan sådan information kan göras tillgänglig.

Den stela strukturen hos IDEF1X tvingar modelleraren att tilldela egenskaper till enheter som kanske inte motsvarar verkligheten i omvärlden. Till exempel kräver IDEF1X att alla entitetsundertyper är exklusiva. Detta leder till att en person inte kan vara både kund och anställd. Medan verklig övning säger oss annorlunda.

Informationsteknik

Clive Finklestein kallas ofta för informationsteknikens fader, även om liknande koncept delades med honom av James Martin (Martin, James. Managing the Database Environment. Upper Saddle River, New Jersey: Prentice Hall, 1983.). Information Engineering använder ett affärsdrivet tillvägagångssätt för informationshantering och använder en annan notation för att representera affärsregler. IE fungerar som en förlängning och utveckling av notationen och kärnkoncepten i ER-metoden som föreslagits av Peter Chen.

IE tillhandahåller infrastrukturen för att stödja informationskrav genom att integrera företagets strategiska planering med informationssystem som håller på att utvecklas. Denna integration gör det möjligt för hanteringen av informationsresurser att bli mer anpassad till företagets långsiktiga strategiska utsikter. Detta affärsdrivna tillvägagångssätt har fått många modellbyggare att välja IE framför andra metoder som tenderar att fokusera på kortsiktiga utvecklingsutmaningar.

IE föreslår en sekvens av åtgärder som leder till att ett företag identifierar alla sina informationsbehov för att samla in och hantera data och identifiera relationer mellan informationsobjekt. Som ett resultat är informationskraven tydligt formulerade utifrån ledningsdirektiv och kan direkt översättas till ett ledningsinformationssystem som kommer att stödja strategiska informationsbehov.

Slutsats

Att förstå hur man använder ett datamodelleringsverktyg som ERwin är bara en del av problemet. Dessutom behöver du förstå när datamodelleringsuppgifter löses och hur de informationskrav och affärsregler som bör representeras i datamodellen samlas in. Att genomföra arbetssessioner ger den mest gynnsamma miljön för att samla in informationskrav i en miljö som inkluderar domänexperter, användare och IT-proffs.

Att bygga en bra datamodell kräver att man analyserar och undersöker informationskraven och affärsregler som samlats in genom arbetssessioner och intervjuer. Den resulterande datamodellen bör jämföras med företagsmodellen, om möjligt, för att säkerställa att den inte kommer i konflikt med befintliga objektmodeller och inkluderar alla nödvändiga objekt.

Datamodellen består av logiska och fysiska modeller som representerar informationskrav och affärsregler. Den logiska modellen måste reduceras till tredje normalform. Den tredje normala formen begränsar, lägger till, uppdaterar och tar bort datastrukturavvikelser för att stödja principen "ett faktum på ett ställe". De insamlade informationskraven och affärsreglerna bör analyseras och undersökas. De måste jämföras med företagsmodellen för att säkerställa att de inte kommer i konflikt med befintliga objektmodeller och inkluderar alla nödvändiga objekt.

I ERwin innehåller datamodellen både logiska och fysiska modeller. ERwin implementerar ER-metoden och låter dig skapa logiska och fysiska modellobjekt för att representera informationskrav och affärsregler. Logiska modellobjekt inkluderar entiteter, attribut och relationer. Fysiska modellobjekt inkluderar tabeller, kolumner och begränsningar.

En av följande publikationer kommer att täcka frågorna om att identifiera entiteter, definiera enhetstyper, välja enhetsnamn och beskrivningar, samt vissa tekniker för att undvika de vanligaste modelleringsfelen i samband med användningen av entiteter.

Entiteter måste ha en komplett uppsättning attribut, så att varje fakta om varje entitet kan representeras av dess attribut. Varje attribut måste ha ett namn som återspeglar dess betydelse, en boolesk datatyp och en tydlig, kort, fullständig beskrivning eller definition. I ett framtida blogginlägg kommer vi att titta på en första uppsättning riktlinjer för korrekt formatering av attributnamn och beskrivningar. Relationer bör innehålla en verbkonstruktion som beskriver förhållandet mellan entiteter, tillsammans med egenskaper som pluralitet, nödvändigheten av existens eller möjligheten till frånvaro av en relation.

NOTERA Mångfald relation beskriver det maximala antalet sekundära entitetsinstanser som kan associeras med en instans av den ursprungliga entiteten.Nödvändighet av existens eller möjlighet till frånvaro relation tjänar till att bestämma det minsta antalet instanser av en sekundär enhet som kan associeras med en instans av originalet

IT-proffs vänder sig alltmer mot datahanteringslösningar baserade på industristandarddatamodeller och affärsbeslutsmallar. Redo att ladda ner komplexa fysiska datamodeller och business intelligence-rapporter för specifika verksamhetsområden gör att du kan förena informationskomponenten i företaget och avsevärt påskynda exekveringen av affärsprocesser. Lösningsmallar gör det möjligt för tjänsteleverantörer att utnyttja kraften i icke-standardiserad information gömd i befintliga system, och därigenom minska projektledtider, kostnader och risker. Till exempel visar verkliga projekt att datamodeller och mallar för affärsbeslut kan minska utvecklingsarbetet med 50 %.

En industrilogikmodell är en domänspecifik, integrerad och logiskt strukturerad bild av all information som behöver finnas i ett företagsdatalager för att svara på både strategiska och taktiska affärsfrågor. Huvudsyftet med modeller är att underlätta orienteringen i datautrymmet och hjälpa till att lyfta fram de detaljer som är viktiga för affärsutvecklingen. I moderna förhållanden, för ett framgångsrikt företag, är det absolut nödvändigt att ha en klar förståelse för sambanden mellan de olika komponenterna och att ha en god uppfattning om den övergripande bilden av organisationen. Identifiering av alla detaljer och relationer med hjälp av modeller möjliggör den mest effektiva användningen av tiden och verktygen för att organisera företagets arbete.

Ett exempel på en "GIS för statliga och lokala myndigheter"-modell.

Idag är det strategiskt viktigt för mjukvaru- och tjänsteleverantörer att snabbt kunna reagera på förändringar i branschen i samband med tekniska innovationer, borttagandet av statliga restriktioner och komplexiteten i försörjningskedjor. Tillsammans med förändringarna i affärsmodellen ökar komplexiteten och kostnaderna för den informationsteknologi som krävs för att stödja ett företags verksamhet. Datahantering är särskilt svårt i en miljö där företagens informationssystem, såväl som funktionella och affärsmässiga krav på dem, ständigt förändras.

Branschdatamodeller är avsedda att hjälpa till att underlätta och optimera denna process, för att överföra IT-metoden till den moderna nivån.

Branschdatamodeller från företagetEsri

Esri ArcGIS datamodeller är arbetsmallar för användning i GIS-projekt och för att skapa datastrukturer för olika applikationsområden. Datamodellbyggnad innebär att skapa en konceptuell design, logisk och fysisk struktur, som sedan kan användas för att bygga en personlig eller företags geodatabas. ArcGIS tillhandahåller verktyg för att skapa och hantera ett databasschema, och datamodellmallar används för att snabbt starta ett GIS-projekt i en mängd olika applikationer och branscher. Esri har spenderat en betydande tid med användargemenskapen för att utveckla ett antal mallar som kan ge en snabb start på utformningen av en företags geodatabas. Dessa projekt beskrivs och dokumenteras på support.esri.com/datamodels. Nedan, i den ordning de visas på den här webbplatsen, finns en semantisk översättning av Esris industrimodellnamn:

Adressregister
Lantbruk
Meteorologi
Grundläggande rumslig data
Biologisk mångfald
Inre utrymme av byggnader
Växthusgasredovisning
Upprätthålla administrativa gränser
Militär etablering. Underrättelsetjänst
Energi (inklusive det nya ArcGIS MultiSpeak-protokollet)
Ekologiska strukturer
Ministeriet för nödsituationer. Brandkår
Skogsmatrikel
Skogsbruk
Geologi
Nationell nivå GIS (e-gov)
Grundvatten och avloppsvatten
Sjukvård
Arkeologi och bevarande av minnesplatser
nationell säkerhet
Hydrologi
International Hydrographic Organization (IHO). S-57-format för ENC
Bevattning
Fastighetsregistret
Kommunal förvaltning
Nautisk navigering
Statens matrikel
Olje- och gasstrukturer
Rörledningar
Rasterförvaring
Batymetri, havsbottenrelief
Telekommunikation
Transport
Vattenförsörjning, avlopp, bostäder och kommunal service

Dessa modeller innehåller alla nödvändiga funktioner i industristandarden, nämligen:

är fritt tillgängliga;
är inte bundna till den "valda" tillverkarens teknik;
skapas som ett resultat av genomförandet av verkliga projekt;
skapad med deltagande av industriexperter;
utformad för att tillhandahålla informationsinteraktion mellan olika produkter och teknologier;
inte motsäga andra standarder och föreskrifter;
används i avslutade projekt runt om i världen;
är utformade för att arbeta med information under hela livscykeln för systemet som skapas, och inte själva projektet;
expanderbar enligt kundens behov utan att förlora kompatibilitet med andra projekt och/eller modeller;
åtföljs av ytterligare material och exempel;
används i riktlinjer och tekniska material från olika industriföretag;
en stor gemenskap av deltagare, medan tillgången till gemenskapen är öppen för alla;
ett stort antal referenser till datamodeller i publikationer de senaste åren.

Esri ingår i en expertgrupp av oberoende organ som rekommenderar olika industrimodeller, såsom PODS (Pipeline Open Data Standards - en öppen standard för olje- och gasindustrin; PODS implementeras för närvarande som en Esri PODS Esri Spatial 5.1.1 geodatabas ) eller en geodatabas (GDB) från ArcGIS for Aviation, som tar hänsyn till ICAO- och FAA-rekommendationer, samt AIXM 5.0-standarden för navigationsdatautbyte. Dessutom finns det rekommenderade modeller som strikt följer befintliga industristandarder, såsom S-57 och ArcGIS for Maritime (marina och kustnära funktioner), samt modeller skapade från det arbete som utförts av Esri Professional Services och är de facto standarder i motsvarande område. Till exempel, GIS för nationen och lokala myndigheter påverkade NSDI- och INSPIRE-standarder, och Hydro och grundvatten (hydrologi och grundvatten) används flitigt i den fritt tillgängliga professionella ArcHydro-sviten och kommersiella produkter. Det bör noteras att Esri också stöder de-facto standarder som NHDI. Alla föreslagna datamodeller är dokumenterade och redo att användas i företags IT-processer. Medföljande material för modeller inkluderar:

UML-diagram över relationer mellan enheter;
datastrukturer, domäner, kataloger;
färdiga geodatabasmallar i ArcGIS GDB-format;
exempeldata och exempelapplikationer;
exempel på dataladdningsskript, exempel på analysverktyg;
referensböcker om den föreslagna datastrukturen.

Esri konsoliderar sin erfarenhet av att bygga industrimodeller i form av böcker och lokaliserar publicerat material. Följande böcker har lokaliserats och publicerats av Esri CIS:

Geospatial Service Oriented Architecture (SOA);
Designa geodatabaser för transport;
Geografiska informationssystem för företag;
GIS: ny energi för el- och gasföretag;
Olja och gas på en digital karta;
Modellera vår värld. Esri Geodatabase Design Guide;
Funderar på GIS. GIS-planering: En manual för chefer;
Geografiska informationssystem. Grunderna;
GIS för administrativ och ekonomisk förvaltning;
Web GIS. Principer och tillämpningar;
Systems Design Strategies, 26:e upplagan;
68 nummer av ArcReview magazine med publikationer av företag och användare av GIS-system;
... och många andra tematiska anteckningar och publikationer.

Till exempel boken " Modellera vår värld..."(översättning) är en omfattande guide och referens för GIS-datamodellering i allmänhet, och geodatabasdatamodell i synnerhet. Boken visar hur man kommer fram till rätt datamodelleringsbeslut, beslut som är involverade i varje aspekt av ett GIS-projekt, från databasdesign till data- och datainsamling till rumslig analys och visualisering Beskriver i detalj hur man designar en geografisk databas lämplig för ett projekt, konfigurerar databasfunktionalitet utan programmering, hanterar arbetsflöden i komplexa projekt, modellerar en mängd olika nätverksstrukturer såsom flod, transport eller elektriska nätverk, integrera satellitbilder i processen för geografisk analys och visning och skapa 3D-modeller av GIS-data. Boka " Designa geodatabaser för transporter"innehåller metodologiska tillvägagångssätt som har testats på ett stort antal projekt och helt överensstämmer med lagstiftningens krav i Europa och USA, såväl som internationella standarder. Och i boken" GIS: Ny energi för el- och gasföretag"Med hjälp av verkliga exempel visas fördelarna som företagens GIS kan tillföra energileverantören, inklusive aspekter som kundservice, nätverksdrift och andra affärsprocesser.

Några av böckerna, översatta och original, publicerade på ryska av Esri CIS och DATA +. De tar upp både konceptuella frågor relaterade till GIS-teknik och många tillämpade aspekter av modellering och distribution av GIS av olika storlekar och syften.

Vi kommer att överväga tillämpningen av industrimodeller med hjälp av exemplet med datamodellen BISDM (Building Interior Space Data Model, informationsmodell för det inre utrymmet i en byggnad) version 3.0. BISDM är en utveckling av en mer generell BIM-modell (Building Information Model) och är avsedd att användas vid design, konstruktion, drift och avveckling av byggnader och konstruktioner. Används i GIS-programvara, låter den dig effektivt utbyta geodata med andra plattformar och interagera med dem. Avser den allmänna gruppen av FM-uppgifter (förvaltning av organisationens infrastruktur). Låt oss lista de viktigaste fördelarna med BISDM-modellen, vars användning tillåter:

organisera utbyte av information i en heterogen miljö enligt enhetliga regler;
få en "fysisk" utföringsform av BIM-konceptet och rekommenderade regler för byggprojektledning;
att med hjälp av GIS upprätthålla ett enda förvar under hela en byggnads livscykel (från design till avveckling);
samordna arbetet för olika specialister i projektet;
visualisera det planerade schemat och byggskeden för alla deltagare;
ge en preliminär uppskattning av kostnaden och tidpunkten för konstruktionen (4D- och 5D-data);
övervaka projektets framsteg;
säkerställa högkvalitativ drift av byggnaden, inklusive underhåll och reparationer;
bli en del av tillgångshanteringssystemet, inklusive funktionerna för att analysera effektiviteten av användningen av utrymme (leasing, lager, personalhantering);
beräkna och hantera byggnadens energieffektivitetsmål;
simulera rörelsen av mänskliga flöden.

BISDM definierar reglerna för att arbeta med rumslig data på nivån för de interna lokalerna i en byggnad, inklusive syfte och användningsområden, utlagd kommunikation, installerad utrustning, redovisning av reparationer och underhåll, loggningsincidenter och relationer med andra företagstillgångar. Modellen hjälper till att skapa ett enhetligt arkiv av geografiska och icke-geografiska data. Erfarenheterna från världens ledande företag användes för att isolera enheter och modellera på geodatabasnivå (geodatabas) av de rumsliga och logiska relationerna mellan alla fysiska element som utgör både själva byggnaden och dess interna lokaler. Att följa principerna för BISDM kan avsevärt förenkla uppgifterna för integration med andra system. Det första steget är vanligtvis CAD-integration. Sedan, under driften av byggnaden, används datautbyte med ERP- och EAM-system (SAP, TRIRIGA, Maximo, etc.).

Visualisering av BISDM strukturella element med hjälp av ArcGIS.

Vid användning av BISDM får kunden/ägaren av anläggningen ett fullständigt informationsutbyte från idén om att skapa ett objekt till utvecklingen av ett komplett projekt, kontroll av konstruktionen med inhämtning av relevant information av tidpunkt då anläggningen tas i drift, kontroll av parametrar under drift, och även under ombyggnad eller avveckling av anläggningen. Efter BISDM-paradigmet blir GIS och den geo-geografiska databasen som skapats med dess hjälp ett gemensamt datalager för relaterade system. Ofta innehåller GDB data som skapats och drivs av tredje parts system. Detta måste beaktas vid utformningen av arkitekturen för systemet som skapas.

I ett visst skede tillåter den ackumulerade "kritiska massan" av information dig att flytta till en ny kvalitativ nivå. Till exempel, när projekteringsstadiet för en ny byggnad har slutförts, är det möjligt att automatiskt visualisera 3D-undersökningsmodeller i GIS, sammanställa en lista över installerad utrustning, beräkna körsträcka för verktyg som ska läggas, utföra ett antal kontroller och till och med ge en preliminär ekonomisk uppskattning av projektkostnaden.

Återigen noterar vi att när BISDM och ArcGIS används tillsammans blir det möjligt att automatiskt bygga 3D-modeller från den ackumulerade data, eftersom geodatabasen innehåller en fullständig beskrivning av objektet, inklusive z-koordinater, våningsmedlemskap, typer av elementkopplingar , utrustningsinstallationsmetoder, material, tillgängliga vägar förflyttning av personal, funktionellt syfte för varje element, etc. etc. Det bör noteras att efter den första importen av allt designmaterial till BISDM GDB, finns det ett behov av ytterligare informationsinnehåll för:

placering av 3D-modeller av föremål och utrustning på avsedda platser;
samla in information om kostnaderna för material och förfarandet för deras läggning och installation;
kontroll av permeabiliteten enligt dimensionerna på den installerade icke-standardutrustningen.

På grund av användningen av ArcGIS är det lättare att importera ytterligare 3D-objekt och referenser från externa källor, eftersom ArcGIS Data Interoperability-modulen låter dig skapa procedurer för att importera sådan data och placera den korrekt i modellen. Alla format som används i branschen stöds, inklusive IFC, AutoCAD Revit, Bentlye Microstation.

Industridatamodeller från IBM

IBM tillhandahåller en uppsättning verktyg och modeller för lagringshantering för en mängd olika affärsområden:

IBM Banking and Financial Markets Data Warehouse (ekonomi)
IBM Banking Data Warehouse
IBM Banking Process and Service Models
IBM Health Plan Data Model (sjukvård)
IBM Insurance Information Warehouse (försäkring)
IBMs försäkringsprocess och servicemodeller
IBM Retail Data Warehouse (detaljhandel)
IBM Telecommunications Data Warehouse (telekommunikation)
InfoSphere Warehouse Pack:
- för kundinsikt (för att förstå kunder)
- för Market and Campaign Insight (för att förstå företaget och marknaden)
- för Supply Chain Insight (för att förstå leverantörer).

Till exempel modellen IBMBankverksamhetochFinansiellMarknaderDatalagerär utformad för att ta itu med de specifika problemen i banksektorn när det gäller data, och IBMBankverksamhetBearbetaochServiceModeller- vad gäller processer och SOA (Service Oriented Architecture). För telekombranschen presenteras modeller IBMInformationRamverk (IFW) och IBMTelekommunikationDataLager (TDW)... De hjälper till att avsevärt påskynda processen för att skapa analytiska system, samt minska riskerna förknippade med utvecklingen av business intelligence-applikationer, företagsdatahantering och organisation av datalager, med hänsyn till telekommunikationsindustrins särdrag. IBM TDW:s kapacitet täcker hela spektrumet av telekommunikationsmarknaden - från internetleverantörer och kabelnätsoperatörer som erbjuder trådbundna och trådlösa telefonitjänster, dataöverföring och multimediainnehåll, till multinationella företag som tillhandahåller telefon-, satellit-, långdistans- och internationella kommunikationstjänster, som såväl som organisationers globala nätverk. Idag används TDW av stora och små leverantörer av tråd- och trådlösa tjänster runt om i världen.

Ett verktyg som heter InfoSphere Warehouse Pack för kundinsikt tillhandahåller strukturerat och lättanvänt affärsinnehåll för ett växande antal affärsprojekt och branscher, inklusive bank, försäkring, finans, sjukförsäkring, telekommunikation, detaljhandel och distribution. För företagsanvändare InfoSphere Warehouse Pack för Market and Campaign Insight hjälper till att maximera effektiviteten av marknadsanalysaktiviteter och marknadsföringskampanjer genom en steg-för-steg-process för att utveckla och ta hänsyn till verksamhetens särdrag. Genom att använda InfoSphere Warehouse Pack för Supply Chain Insight organisationer har möjlighet att ta emot aktuell information om leveranskedjans verksamhet.

Esris position inom IBMs lösningsarkitektur.

Särskilt anmärkningsvärt är IBM:s syn på verktyg och verktyg. För att möta de växande kraven från konsumenter behöver verktyg en mer flexibel arkitektur än de som används idag, samt en industristandardobjektmodell för att underlätta det fria informationsflödet. Detta kommer att förbättra kommunikationskapaciteten hos verktyg, möjliggöra kommunikation på ett mer kostnadseffektivt sätt och ge nya system bättre överblick över alla resurser som behövs, oavsett var de är placerade i organisationen. Grunden för detta tillvägagångssätt är SOA (Service Oriented Architecture), en komponentmodell som kartlägger affärsenhetsfunktioner till återanvändbara applikationstjänster. "Tjänsterna" för sådana komponenter utbyter data genom gränssnitt utan stel bindning, och döljer för användaren all komplexitet i systemen bakom dem. I det här läget kan företag enkelt lägga till nya applikationer oavsett programvaruleverantör, operativsystem, programmeringsspråk eller andra inneboende egenskaper hos programvaran. Baserat på SOA implementeras konceptet SÄKER ( Solution Architecture for Energy) tillåter det energiföretaget att få en standardbaserad, holistisk bild av sin infrastruktur.

Esri ArcGIS® är en globalt erkänd mjukvaruplattform för geografiska informationssystem (GIS), som tillhandahåller skapandet och hanteringen av digitala tillgångar för elkraft, gasöverföring, distribution och telekommunikationsnätverk. ArcGIS låter dig utföra den mest kompletta inventeringen av komponenterna i det elektriska distributionsnätet, med hänsyn till deras rumsliga placering. ArcGIS utökar dramatiskt IBM SAFE-arkitekturen genom att tillhandahålla de verktyg, applikationer, arbetsflöden, analys- och informationsintegrationsmöjligheter som behövs för att hantera ett smart energiföretag. ArcGIS inom ramen för IBM SAFE låter dig ta emot information från olika källor om infrastrukturanläggningar, tillgångar, kunder och anställda med korrekt data om deras plats, samt skapa, lagra och bearbeta georefererad information om företagstillgångar (stöd, pipelines, ledningar) , transformatorer, kabelkanaler etc.). ArcGIS inom SAFE-infrastrukturen kopplar dynamiskt samman kärnverksamhetens applikationer genom att kombinera data från GIS, SCADA och kundtjänstsystem med extern information som trafikintensitet, väderförhållanden eller satellitbilder. Verktyg använder denna kombinerade information för en mängd olika ändamål, från S.O.R. (den övergripande bilden av den operativa miljön) till platsinspektion, underhåll, nätverksanalys och planering.

Informationskomponenterna i ett energibolag kan modelleras med hjälp av flera nivåer som sträcker sig från den lägsta - fysiska - till den högsta, mest komplexa nivån av affärslogik. Dessa lager kan integreras för att möta typiska industrikrav såsom automatiserad mätloggning och SCADA-hantering. Genom att bygga SAFE-arkitekturen tar verktygen betydande framsteg när det gäller att främja en industriomfattande modell med öppna objekt som kallas Common Information Model (CIM) för energi och verktyg. Denna modell tillhandahåller den nödvändiga ramen för att flytta många företag mot en tjänsteorienterad arkitektur eftersom den uppmuntrar användningen av öppna standarder för att strukturera data och objekt. På grund av det faktum att alla system använder samma objekt kommer förvirringen och oelasticiteten förknippad med olika implementeringar av samma objekt att reduceras till ett minimum. Sålunda kommer definitionen av klientobjektet och andra viktiga affärsobjekt att förenas över alla system hos strömförsörjningsföretaget. Nu, med CIM, kan tjänsteleverantörer och tjänstekonsumenter dela en gemensam datastruktur, vilket gör det lättare att lägga ut dyra affärskomponenter på entreprenad eftersom CIM etablerar en gemensam bas för att bygga informationsutbyte.

Slutsats

Omfattande industridatamodeller ger företag en enda, integrerad bild av sin affärsinformation. Många företag har svårt att integrera sin data, även om detta är en förutsättning för de flesta företagsövergripande projekt. Enligt en undersökning från The Data Warehousing Institute (TDWI) fann mer än 69 % av de tillfrågade organisationerna att integration är ett betydande hinder för att nya applikationer ska användas. Tvärtom ger implementeringen av dataintegration företaget påtagliga intäkter och ökad effektivitet.

En välkonstruerad modell identifierar unikt betydelsen av datan, vilket i det här fallet är strukturerad data (till skillnad från ostrukturerad data som en bild, binär fil eller text, där innebörden kan vara tvetydig). De mest effektiva industrimodellerna är de som erbjuds av professionella leverantörer som Esri och IBM. Den höga avkastningen på användningen av deras modeller uppnås på grund av den betydande detaljnivån och noggrannheten. De innehåller vanligtvis många dataattribut. Dessutom har både Esri och IBM lång erfarenhet av modellering och är väl insatta i att bygga branschspecifika modeller.

DB arkitektur

KMD-schemat är en beskrivning av datamodellens struktur ur administratörens synvinkel.

Ett AMD-schema är en beskrivning av en intern eller fysisk modell. Det är här beskrivningen av den fysiska platsen för uppgifterna på media lagras. Schemat lagrar direkta indikationer på platsen för data i minnet (volymer, diskar).

KMD-schemat beskriver strukturen för data, poster och fält.

Alla DBMS stöder tre huvudtyper av datamodeller:

1. Hierarkisk modell. Det förutsätter någon form av rotinträde. Grenar kommer från rötterna.

Alla objekt är inte bekvämt beskrivna på detta sätt. Det finns inga länkar i hierarkin och det finns en stor redundans av information.

2. Nätverksmodell. Låter dig visa alla komplexiteten i relationer korrekt.

Modellen är bekväm för att representera länkar med data från den externa miljön, men mindre bekväm att beskriva i en databas, vilket leder till ytterligare arbete för användaren att studera navigeringen genom länkar.

3. Relationsmodellen. Den är baserad på den matematiska termen Relation - en relation, och helt enkelt - en tabell. Till exempel rektangulär 2D.

Den relationella datastrukturen utvecklades i slutet av 1960-talet av ett antal forskare, av vilka det mest betydande bidraget gjordes av IBM-anställde Edgar Codd. Med den relationella ansatsen presenteras data i form av tvådimensionella tabeller – de mest naturliga för människor. Samtidigt, för databehandling, föreslog Codd att man skulle använda apparaten för mängdteorin - förening, skärningspunkt, skillnad, kartesisk produkt.

Data typ- detta koncept har samma betydelse som i programmeringsspråk (dvs datatypen bestämmer den interna representationen i datorminnet och sättet att lagra datainstansen, såväl som uppsättningen värden som datainstansen kan ta och uppsättningen av giltiga dataoperationer). Alla befintliga moderna databaser stöder speciella datatyper som är utformade för att lagra data av heltalstyp, fraktionerad flyttal, tecken och strängar, kalenderdatum. Många databasservrar har andra typer implementerade, till exempel har Interbase-servern en speciell datatyp för att lagra stora arrayer av binär information (BLOB).

DomänÄr en potentiell uppsättning värden av en enkel datatyp, den liknar en dataundertyp i vissa programmeringsspråk. En domän definieras av två element - en datatyp och ett booleskt uttryck som tillämpas på data. Om detta uttryck utvärderas till sant, tillhör datainstansen domänen.

AttitydÄr en tvådimensionell tabell av ett speciellt slag, bestående av en rubrik och en kropp.

RubrikÄr en fast uppsättning attribut, som vart och ett är definierat på någon domän, och det finns en en-till-en-överensstämmelse mellan attributen och de definierande domänerna.

Vart och ett av attributen definieras på sin egen domän. Domänen är heltalsdatatypen och det booleska villkoret är n> 0. Titeln är oföränderlig över tid, i motsats till förhållandets kropp. RelationsorganÄr en samling tupler, som vart och ett är ett attribut-värdepar.

Kraften i relationenär antalet av dess tupler, och graden av attityd- antalet attribut.

Graden av förhållandet är konstant för ett givet förhållande, medan kraften i förhållandet ändras över tiden. Relationens makt kallas också för kardinalnumret.

Ovanstående begrepp är teoretiska och används i utvecklingen av språkverktyg och mjukvarusystem för relationell DBMS. I det dagliga arbetet används istället deras informella motsvarigheter:

attityd - tabell;

attribut - kolumn eller fält;

tuppel - skiva eller sträng.

Således är graden av förhållandet antalet kolumner i tabellen, och kardinalnumret är antalet rader.

Eftersom en relation är en mängd, och i klassisk mängdlära, per definition, en mängd inte kan innehålla sammanfallande element, kan en relation inte ha två identiska tupler. Därför, för en given relation, finns det alltid en uppsättning attribut som unikt identifierar en tupel. Denna uppsättning attribut kallas nyckel.

Nyckeln måste uppfylla följande krav:

· Måste vara unik;

· Måste vara minimal, det vill säga att ta bort alla attribut från nyckeln leder till en kränkning av unikheten.

Som regel är antalet attribut i nyckeln mindre än graden av sambandet, men som en sista utväg kan nyckeln innehålla alla attribut, eftersom kombinationen av alla attribut uppfyller unikhetsvillkoret. Vanligtvis har en relation flera nycklar. Av alla nycklar i relationen (de kallas även "möjliga nycklar"), väljs en som primärnyckel... När man väljer primärnyckel nyckeln med minst attribut är vanligtvis att föredra. Det är också opraktiskt att använda nycklar med långa strängvärden.

I praktiken används ofta ett speciellt numeriskt attribut som en primärnyckel - en autoinkrementell nolla, vars värde kan genereras av en trigger (en trigger är en speciell procedur som kallas när ändringar görs i databasen) eller av speciella medel definierade i DBMS-motorn.

De grundläggande begreppen som beskrivs i detta kapitel är inte specifika för någon speciell databasimplementering, utan är gemensamma för dem alla. Dessa begrepp är alltså grunden för en viss generell modell, som kallas den relationella datamodellen.

Grundaren av det relationella tillvägagångssättet, Date fastställde att den relationella modellen har tre delar:

· Strukturell;

· Manipulativ;

· Holistiskt.

I den strukturella delen av modellen är relationer fixerade som den enda datastrukturen som används i relationsmodellen.

I manipulationsdelen är två grundläggande mekanismer för att manipulera relationsbaser fasta - relationalgebra och relationskalkyl.

En integrerad del förstås som en viss mekanism för att säkerställa att data inte är förstörbara. Den integrerade delen innehåller två grundläggande krav för relationsdatabasers integritet – entitetsintegritet och referensintegritet.

Krav enhetens integritetär att varje tupel av vilken relation som helst måste kunna särskiljas från vilken annan tupel av denna relation, det vill säga, med andra ord, varje relation måste ha en primärnyckel. Detta krav måste uppfyllas om förhållandets grundläggande egenskaper är uppfyllda.

I datamanipuleringsspråket, såväl som i frågespråket, exekveras en matematisk apparat som kallas relationernas algebra, för följande åtgärder definieras:

1. Standardoperationer: - skärningspunkt, - union, \ - skillnad, X - Kartesisk produkt.

2. Specifikt: projektion, begränsning, anslutning, division.

a. Union.

ShD SHM EI NR

R 1 (artikelnummer, materialnummer, måttenheter, förbrukningsgrad)

R 2 (ШД, ШМ, ЕИ, НР)

Måste hitta

Fastsättning av uppsättningarna R1 och R2 antas. I denna operation bevaras graden och kardinaliteten av resultatet

b. Genomskärning.

Markera matchande linjer.

c. Skillnad.

Eliminera tupler från R 1 som sammanfaller med R 2.

d. Kartesisk produkt.

Det är här tuplar är sammanlänkade.

Varje rad i en uppsättning sammanfogas med varje rad i den andra.

Två uppsättningar ges:

Den kartesiska produkten är som följer:

I detta fall är S-graden lika med, och, dvs. du får 12 rader och 5 kolumner.

Företagsdatabasen är den centrala länken i företagsinformationssystemet och låter dig skapa ett enda informationsutrymme för företaget. Företagsdatabaser

Dela ditt arbete på sociala medier

Om detta verk inte passade dig längst ner på sidan finns en lista över liknande verk. Du kan också använda sökknappen

ÄMNE V. FÖRETAGSDATABASER

V .1. Organisering av data i företagssystem. Företagsdatabaser.

V .2. DBMS och strukturella lösningar i företagssystem.

V.3. Internet / Intranät-teknik och företagslösningar för databasåtkomst.

V .1. ORGANISERING AV DATA I FÖRETAGSSYSTEM. FÖRETAGSDATABASER

Företagsbas data är den centrala länken i företagsinformationssystemet och låter dig skapa ett enda informationsutrymme för företaget. Företagsdatabaser (Figur 1.1).

Det finns olika definitioner av databaser.

Termen databas kan sammanfattas som en samling logiskt relaterad data avsedd för delning.

Under databasen förstås som en uppsättning data som lagras tillsammans med en sådan minimal redundans som gör att de kan användas på ett optimalt sätt för en eller flera applikationer.

Grundläggande krav för databaser:

Datapresentationens fullständighet. Data i databasen bör representera all information om objektet på ett adekvat sätt och de bör vara tillräckliga för ODS.
Databasintegritet. Uppgifterna ska sparas vid bearbetning av deras ODS och i eventuella situationer som uppstår under arbetets gång.
Datastrukturflexibilitet. Databasen bör tillåta förändringar av datastrukturer utan att kränka dess integritet och fullständighet när yttre förhållanden förändras.
Genomförbarhet. Det innebär att det ska finnas en objektiv representation av olika objekt, deras egenskaper och samband.
Tillgänglighet. Det är nödvändigt att säkerställa avgränsningen av åtkomst till uppgifter.
Redundans. Databasen bör ha en minsta redundans i representationen av data om vilket objekt som helst.

Kunskap förstås som en uppsättning fakta, mönster och heuristiska regler som kan användas för att lösa problemet.

Kunskapsbas (KB)  en uppsättning databaser och använda regler som erhållits från beslutsfattare. Kunskapsbasen är en del av expertsystem.

Skilja på olika sätt att presentera data.

Fysiska data - det är data som lagras i datorns minne.

Ris. 1.1. Strukturen för avdelningarnas interaktion med företagets informationsresurser.

Företagsdatabaser är fokuserad (centraliserad) och distribueras.

Figur 1.2. Schema heterogen centraliserad databas

Stort flöde av datautbyte;
Hög trafik på nätverket;
Låg tillförlitlighet;
Dålig prestanda totalt sett.

Högre grad av samtidig bearbetning på grund av lastbalansering;
Förbättra användningen av data i fält när man utför fjärrförfrågningar;
Lägre kostnader;
Lätt att hantera lokala databaser.

Figur 1.3. Distribuerad företagsdatabas.

Låt oss ge följande definition av en distribuerad databas.

De viktigaste prestandakraven för en distribuerad databas är:

Skalbarhet;
Kompatibilitet;
Stöd för olika datamodeller;
Bärbarhet;
Platstransparens;
Autonomi för distribuerade databasnoder (Site Autonomy);
Behandling av distribuerad begäran;
Utförande av distribuerade transaktioner.
Stöd för ett homogent säkerhetssystem.

Huvuduppgiften för en distribuerad databas - distribution av data över nätverket och tillhandahållande av tillgång till det. Det finns följande sätt att lösa detta problem:

Varje nod lagrar och använder sin egen datauppsättning som är tillgänglig för fjärrfrågor. Denna fördelning är uppdelad.
Vissa data som ofta används på avlägsna platser kan dupliceras. Denna fördelning kallas delvis duplicerad.
All data dupliceras vid varje nod. Denna fördelning kallas fullständigt duplicerad.
Vissa filer kan delas horisontellt (en delmängd av poster väljs) eller vertikalt (en delmängd av attributfält väljs), medan de valda delmängderna lagras i olika noder tillsammans med odelade data. Denna fördelning kallas split (fragmenterad).

När du skapar en distribuerad databas, på konceptuell nivå, måste du lösa följande uppgifter:

Det är nödvändigt att ha ett enda konceptuellt diagram över hela nätverket. Detta kommer att ge logisk insyn i data för användaren, som ett resultat av vilket han kommer att kunna skapa en begäran till hela databasen, bakom en separat terminal (det verkar fungera med en centraliserad databas).
Ett schema behövs för att lokalisera data i nätverket. Detta kommer att ge insyn i dataplaceringen, tack vare vilken användaren inte behöver ange vart den ska skicka förfrågan för att få den nödvändiga informationen.
Det är nödvändigt att lösa problemet med heterogenitet hos distribuerade databaser. Distribuerade databaser kan vara homogena eller heterogena vad gäller hårdvara och mjukvara. Problemet med heterogenitet är relativt lätt att lösa om den distribuerade databasen är heterogen i bemärkelsen hårdvara, men homogen i bemärkelsen mjukvara (samma DBMS i noderna). Om olika DBMS används i noderna i ett distribuerat system krävs verktyg för att konvertera datastrukturer och språk. Detta bör ge transparens för transformation över noderna i den distribuerade databasen.
Det är nödvändigt att lösa problemet med ordbokshantering. För att tillhandahålla all slags transparens i en distribuerad databas behöver du program som hanterar flera ordböcker och referensböcker.
Du måste definiera metoder för att köra frågor i en distribuerad databas. Metoder för att utföra frågor i en distribuerad databas skiljer sig från de i centraliserade databaser, eftersom enskilda delar av frågorna måste exekveras på platsen för motsvarande data och delresultat måste skickas till andra noder; samtidigt måste samordning av alla processer säkerställas.
Det är nödvändigt att lösa problemet med att köra parallella frågor. En distribuerad databas kräver en sofistikerad mekanism för samtidighetskontroll, som i synnerhet måste säkerställa synkronisering när information uppdateras, vilket säkerställer datakonsistens.
En avancerad metodik för att distribuera och placera data krävs, inklusive delning, är ett av huvudkraven för en distribuerad databas.

öka lönen för alla anställda i företaget;
beräkna bankräntan på alla kunders konton;
göra ändringar i listan över alla varor i lager;
hitta det nödvändiga sammandraget från alla texter som finns lagrade i biblioteket eller i det bibliografiska informationssökningssystemet;
hitta en beskrivning av det obligatoriska kontraktet i en fil som innehåller juridiska dokument;
bläddra igenom alla filer som innehåller beskrivningar av patent och hitta ett patent (om något) som liknar det föreslagna igen.

Databasmaskiner blir allt viktigare i samband med forskning och tillämpning av artificiell intelligenskoncept som kunskapsrepresentation, expertsystem, inferens, mönsterigenkänning m.m.

Huvudsyftet med DW är skapa en enda logisk representation av data som finns i olika typer av databaser, eller, med andra ord, en enda företagsdatamodell.

En databank kan finnas i ett företags struktur.

Databas betraktas som ett informations- och referenssystem, vars huvudsakliga syfte är:

i ackumulering och underhåll av en uppsättning information som utgör informationsbasen för hela det automatiserade systemet eller en viss uppsättning uppgifter lösta i det;
vid utfärdandet av de uppgifter som krävs av uppgiften eller användaren;
tillhandahållande av kollektiv åtkomst till lagrad information;
för att säkerställa den nödvändiga hanteringen av användningen av information som finns i informationsbasen.

V .2. DBMS OCH STRUKTURELLA LÖSNINGAR I FÖRETAGSSYSTEM

Databas och kunskapshanteringssystem

En viktig komponent i moderna informationssystem är databashanteringssystem (DBMS).

DBMS - En uppsättning programvara och språkverktyg avsedda för att skapa, underhålla och använda databaser.

Huvuddragen hos moderna DBMS är att moderna DBMS stöder teknologier som:

Klient-/serverteknik.
Stöd för databasspråk. denschemadefinitionsspråk DB (SDL - Schema Definition Language),datamanipulationsspråk (DML), integrerade språk SQL (Structured Queue Language), QDB (Query - By - Example) och QMF (Query Management Facility ) Är ett avancerat perifert frågespecifikations- och rapporteringsverktyg för DB 2, etc.;
Direkt datahantering i externt minne.
Hantering av RAM-buffertar.
Transaktionshantering. OLTP - teknik (On-Line transaktionsbearbetning), OLAP - teknologi (On-Line Analys Processing) för DW.
Säkerställ dataskydd och integritet. Användning av systemet är endast tillåtet för användare som har rätt att få tillgång till uppgifterna. När användare utför operationer på data bibehålls konsistensen av den lagrade datan (integriteten). Detta är viktigt i företagsinformationssystem för flera användare.
Journalisering.

Modernt DBMS måste säkerställa överensstämmelse med databaskraven som anges ovan. Dessutom måste de följa följande principer:

Dataoberoende.
Mångsidighet. DBMS måste ha kraftfullt stöd för konceptuella datamodeller för att visa anpassade logiska vyer.
Kompatibilitet. DBMS måste förbli i drift med utveckling av mjukvara och hårdvara.
Redundans av data. Till skillnad från filsystem måste en databas vara en enda samling av integrerade data.
Dataskydd. DBMS måste ge skydd mot obehörig åtkomst.
Dataintegritet. DBMS måste förhindra användare från att bryta databasen.
Hantering av samtidigt arbete. DBMS måste skydda databasen från inkonsekvenser i läget för delad åtkomst. För att säkerställa ett konsekvent tillstånd för databasen måste alla användarförfrågningar (transaktioner) utföras i en specifik ordning.
DBMS måste vara universellt. Det bör stödja olika datamodeller på en enda logisk och fysisk grund.
DBMS bör stödja både centraliserade och distribuerade databaser och därmed bli en viktig länk i datornätverk.

deras kapacitet i förhållande till distribuerade (företags)databaser;
deras relation till typen av datamodell implementerad i DBMS.

I förhållande till företags (distribuerade) databaser kan följande typer av DBMS villkorligt särskiljas:

DBMS "skrivbord". Dessa produkter är främst inriktade på att arbeta med personuppgifter ("desktop"-data). De har kommandouppsättningar för att dela gemensamma databaser, men små i storlek (som ett litet kontor). Först och främst är det en DBMS som Assess, dBASE, Paradox, EohPgo. Varför Assess, dBASE, Paradox, EohPgo har dålig tillgång till företagsdata. Poängen är att det inte finns något enkelt sätt att övervinna barriären mellan personlig och företagsinformation. Och poängen är inte ens att mekanismen för personlig data (eller små kontor) DBMS är fokuserad på att komma åt data genom många gateways, internetarbetande produkter, etc. Problemet är att dessa mekanismer vanligtvis är förknippade med fullständiga filöverföringar och brist på indexstöd, vilket resulterar i att serverköer praktiskt taget stannar på stora system.
Specialiserat högpresterande DBMS för flera användare. Sådana DBMS kännetecknas av närvaron av en fleranvändarsystemkärna, ett datamanipuleringsspråk och följande funktioner som är typiska för utvecklade DBMS:er för flera användare:
organisation av buffertpoolen;
närvaron av ett system för att behandla transaktionsköer;
närvaron av mekanismer för fleranvändardatalåsning;
transaktionsloggning;
tillgångskontrollmekanismer.

Dessa är DBMS som Oracle, DB2, SQL/Server, Informix, Sybase, ADABAS, Titanium och andra tillhandahåller en bred tjänst för bearbetning av företagsdatabaser.

När man arbetar med databaser används transaktionsmekanismen.

Transaktion Är en logisk arbetsenhet.

Transaktion är en sekvens av datamanipulationssatser som körssom helhet(allt eller inget) och översätta databasenfrån ett holistiskt tillstånd till ett annat holistiskt tillstånd.

En transaktion har fyra viktiga egenskaper, så kallade ASID-egenskaper:

(A) Atomicitet ... En transaktion utförs som en atomär operation - antingen utförs hela transaktionen eller så utförs den inte helt.
(C) Konsistens... En transaktion flyttar en databas från ett konsekvent (konsistent) tillstånd till ett annat konsekvent (konsistent) tillstånd. Inom en transaktion kan databaskonsistensen kränkas.
(I) Isolering ... Transaktioner från olika användare bör inte störa varandra (till exempel som om de utfördes strikt i tur och ordning).
(E) Hållbarhet... Om transaktionen är slutförd, bör resultaten av dess arbete sparas i databasen, även om systemet kraschar nästa ögonblick.

Transaktionen startar vanligtvis automatiskt från det ögonblick som användaren ansluter till DBMS och fortsätter tills en av följande händelser inträffar:

Kommando COMMIT WORK utfärdat.
Kommandot ROLLBACK WORK utfärdades.
Användaren har kopplat från DBMS.
Det var ett fel i systemet.

Klient/serverarkitektur

		Databas
Serverdator
Nätverk
IBM-kompatibel PC	IBM-kompatibel PC	IBM-kompatibel PC
		Ansökningar

Ris. 2.1. Klient-server-arkitektursystem

Klientdatorns huvudfunktion är att köra applikationen (användargränssnitt och presentationslogik) och kommunicera med servern när applikationen kräver det.

Server Är ett objekt (dator) som tillhandahåller tjänster till andra objekt på deras begäran.

Distribuerad databehandling

Termen "distribuerad datoranvändning" används ofta för att hänvisa till två olika, om än kompletterande, begrepp:

Distribuerad databas;
Distribuerad databehandling.

Tillämpningen av dessa koncept gör det möjligt att organisera åtkomst till information lagrad på flera maskiner för slutanvändare med olika metoder.

Det finns många typer av servrar:

Databasserver;
Skrivarserver;
Fjärråtkomstserver;
Faxserver;
Webbserver osv.

I hjärtat av den underliggande tekniken är klient/server är sådana grundläggande teknologier som:

Operativsystemsteknologier, konceptet med interaktion mellan öppna system, skapandet av objektorienterade miljöer för programs funktion;
Telekommunikationsteknik;
Nätverksteknik;
Grafiska användargränssnittstekniker ( GUI);
Etc.

Fördelar med klient-server-teknik:

Klient-/serverteknik möjliggör beräkning i heterogena datormiljöer. Plattformsoberoende: Tillgång till heterogena nätverksmiljöer som inkluderar olika typer av datorer med olika operativsystem.
Oberoende från datakällor: tillgång till information från heterogena databaser. Exempel på sådana system är DB2, SQL/DS, Oracle, Sybase.
Belastningsbalans mellan klient och server.
Utför beräkningar där det är mest effektivt;
Ge förmågan att skala effektivt;
Platsöverskridande datoranvändning... Cross-platform computing definieras helt enkelt som implementering av teknologier i heterogena datormiljöer. Följande möjligheter bör ges här:
Applikationen måste köras på flera plattformar;
Den måste ha samma gränssnitt och logik på alla plattformar;
Applikationen måste integreras med den ursprungliga operativa miljön;
Det ska bete sig likadant på alla plattformar;
Enkelt och konsekvent stöd bör ges för det.

 Distribuerad databehandling. Distribuerad datoranvändning innebär fördelning av arbete mellan flera datorer (även om distribuerad datoranvändning är ett bredare begrepp).

 Neddragning. Downsizing är portering av stordatorapplikationer till små datorplattformar.

Minskade kostnader för infrastruktur och hårdvara. Ekonomiskt: Tillgången till billig datorutrustning och den ökande spridningen av lokala nätverk gör klient-server-tekniken mer ekonomisk än annan databehandlingsteknik. Utrustningen kan uppgraderas så snart behov uppstår.

 Att minska den totala körtiden för applikationen;

 Minska klientminnesanvändning;

 Minska nätverkstrafiken.

Förmåga att arbeta med multimedia: hittills har många multimediaprogram skapats för PC. Det finns inga sådana program för terminal-värd-konfigurationen, eller så är de mycket dyra.
Möjligheten att attrahera stora datorresurser för databasoperationer: eftersom applikationer körs på klientdatorer frigörs ytterligare (jämfört med terminal-värdkonfigurationen) resurser på serverdatorn för databasoperationer, såsom datorresurser för den centrala processorn och driftminne.
Bättre programmerarproduktivitet: Programmerarproduktiviteten ökas genom att använda verktyg som SQL * Forms och CASE, som låter dig utveckla applikationer snabbare än programmeringsspråk som C, PL1 eller COBOL.
Ökad slutanvändarproduktivitet: Nuförtiden har många slutanvändare bemästrat system som Lotus, Paradox, Word Perfect, Harvard Graphics, etc.

Gränssnittet på serversidan är definierat och fixat. Därför är det möjligt att skapa nya klientdelar av ett befintligt system (ett exempel på interoperabilitet på systemnivå).

Ris. 2.2. Illustration av klientåtkomst till en serverresurs.

Hur man implementerar klient-server-teknik

Installationen av ett system baserat på klient-server-teknologi och som kan utföra distribuerad databehandling diskuteras nedan. Följande maskinvara och programvara krävs:

databasserverdator;
klientdatorer;
kommunikationsnätverk;
nätverksprogramvara;
programvara.

Ris. 2.3. Schema för att köra användarfrågor till distribuerade databaser.

Datamodellen har tre komponenter:

Datastrukturen att representera från användarens synvinkel av databasen.
Giltiga operationer utförda på datastrukturen. Det är nödvändigt att kunna arbeta med denna struktur med hjälp av olika NOD- och NMD-operationer. En rik struktur är värdelös om det inte finns något sätt att manipulera dess innehåll.
Integritetskontrollbegränsningar. Datamodellen måste förses med medel för att upprätthålla sin integritet och skydda den. Som ett exempel, betrakta följande två begränsningar:
Varje underträd måste ha en källnod. I hierarkiska databaser kan du inte lagra underordnade noder utan en källnod.
Med avseende på en relationsdatabas kan det inte finnas identiska tupler. För en fil kräver detta krav att alla poster är unika.

En av de viktigaste egenskaperna hos ett DBMS är förmågan att länka objekt.

Det finns följande typer av länkar mellan objekt:

En-till-en (1:1)... Ett objekt i en uppsättning kan associeras med ett objekt i en annan uppsättning.
En-till-många (1:M)... Ett objekt i en uppsättning kan associeras med många objekt i en annan uppsättning.
Många-till-många (M:N)... Ett objekt i en uppsättning kan associeras med många objekt i en annan uppsättning, men samtidigt kan ett objekt i en annan uppsättning associeras med många objekt i den första uppsättningen.
Förgrenad ... Ett objekt i en uppsättning kan associeras med objekt av många uppsättningar.
Rekursiv ... Ett objekt i en given uppsättning kan länkas av ett objekt i samma uppsättning.

Följande grundläggande datamodeller finns:

Relationsdatamodell.
Hierarkisk datamodell.
Ofullständig nätverksdatamodell.
CODASYL datamodell.
Utökad nätverksdatamodell.

V.3. INTERNET / INTRANET-TEKNIKER OCH LÖSNINGAR FÖR ÅTKOMST FÖR FÖRETAGS DATABAS

Andra liknande verk som kan intressera dig. Wshm>
6914.		Databas koncept	11,56 kB
	Databasen presenteras i en objektiv form, en uppsättning oberoende material av artiklar av beräkningar av normativa handlingar av domstolsbeslut och annat liknande material systematiserat på ett sådant sätt att dessa material kan hittas och bearbetas med hjälp av en elektronisk dator Civil Code of the Russian Federation Art. En databas organiserad i enlighet med vissa regler och bevarad i datorns minne är en uppsättning data som kännetecknar det aktuella tillståndet för vissa ...
8064.		Distribuerade databaser	43,66 kB
	Distribuerade databaser En distribuerad databas RDB förstås som en uppsättning logiskt sammankopplade delade data som är fysiskt distribuerade över olika noder i ett datornätverk. Dataåtkomst bör inte bero på närvaron eller frånvaron av datarepliker. Systemet bör automatiskt bestämma metoderna för att utföra datafusionsanslutningen, nätverkskanalen kan klara av mängden överförd information och noden har tillräcklig processorkraft för att gå med i tabellerna. RDBMS måste kunna ...
20319.		DATABASER OCH DERAS SKYDD	102,86 KB
	Online onlinedatabaser uppstod i mitten av 1960-talet. Operationer på operativa databaser bearbetades interaktivt med hjälp av terminaler. Enkla indexsekventiella skivorganisationer utvecklades snabbt till en mer kraftfull uppsättningsorienterad skivmodell. Charles Bachmann fick Turing-priset för att ha lett Data Base Task Group (DBTG), som utvecklade ett standardspråk för databeskrivning och datamanipulation.
5031.		Databasutvecklingsbibliotek	11,72 MB
	Databasdesignteknik. Bestämma relationer mellan enheter och skapa en datamodell. Huvudidéerna för modern informationsteknologi är baserade på konceptet enligt vilket data bör organiseras i databaser för att på ett adekvat sätt återspegla den föränderliga verkliga världen och möta användarnas informationsbehov. Dessa databaser skapas och fungerar under kontroll av speciella mjukvarusystem som kallas databashanteringssystem DBMS.
13815.		DATABAS HIERARKISK MODELL	81,62 kB
	Huvudidéerna för modern informationsteknologi är baserade på begreppet databaser, enligt vilken grunden för informationsteknologi är data organiserade i databaser som adekvat återspeglar tillståndet för ett visst ämnesområde och ger användaren relevant information inom detta ämnesområde. Det måste erkännas att uppgifterna är ...
14095.		Utveckling av biblioteksdatabas	11,72 MB
	Ökningen av volymen och strukturell komplexitet hos lagrad data, utvidgningen av kretsen av användare av informationssystem har lett till den utbredda användningen av det mest bekväma och relativt lättförståeliga relations-(tabell)DBMS.
5061.		Skapande av poliklinikens databas	2,4 MB
	Utvecklingen av datateknik och informationsteknik har gett möjligheter till skapande och utbredd användning av automatiserade informationssystem (AIS) för olika ändamål. Informationssystem för att hantera ekonomiska och tekniska anläggningar utvecklas och implementeras
13542.		Geologiska informationsdatabaser	20,73 kB
	Nyligen har införandet av datorteknik och i synnerhet databaser på det vetenskapliga området gått snabbt. Denna process går inte heller förbi geologin, eftersom det är inom naturvetenskapen som det finns ett behov av att lagra och bearbeta stora mängder information.
9100.		Databas. Grundläggande koncept	26,28 kB
	En databas är en samling information om specifika objekt i den verkliga världen inom vilket ämnesområde som helst inom ekonomi, förvaltning, kemi, etc. Syftet med ett informationssystem är inte bara lagring av data om objekt, utan också manipulation av dessa data , med hänsyn till kopplingar mellan objekt. Varje objekt kännetecknas av en uppsättning egenskapsdata, som kallas attribut i databasen.
5240.		Skapande av databasen "Dekanus vid universitetet"	1,57 MB
	Databas (DB) är en uppsättning sammankopplade data lagrade tillsammans på externa lagringsmedier på en dator, med en sådan organisation och minimal redundans som gör att de kan användas på ett optimalt sätt för en eller flera applikationer

Industridatamodeller

Publikationer

Steve Hoberman. Utnyttja industrins logiska datamodell som din företagsdatamodell.
Claudia Imhoff. Snabbspårande datalager och Business Intelligence-projekt via intelligent datamodellering

Zaitsev S.L., Ph.D.

Upprepade grupper

Ris. 1.6. Det här exemplet använder upprepade grupper.

Ris. 1.7. Modell reducerad till första normalform.

Ett faktum på ett ställe

Om samma attribut finns i mer än en enhet och inte är en främmande nyckel, anses detta attribut vara överflödigt. Den logiska modellen bör inte innehålla redundanta data.

Varje attribut beror på nyckeln

Ris. 1.9. I tredje normalform Skolnamn och Geografisk regionöverförs till entitet, där deras värden beror på nyckeln.

Många-till-många relationer

Formella definitioner av normala former

Relationen R motsvarar den första normalformen (1NF) om och endast om alla domäner som hör till den endast innehåller atomvärden (Datum, ibid.).

En relation R motsvarar andra normalformen (2NF) om och endast om den motsvarar 1NF, och varje icke-nyckelattribut är helt beroende av primärnyckeln (Datum, ibid.).

Relationen R motsvarar tredje normalformen (3NF) om och endast om den motsvarar 2NF, och varje icke-nyckelattribut inte transitivt beror på primärnyckeln (Datum, ibid.).

Relationen R motsvarar Boyes-Codd normalform (BCNF) om och endast om varje determinant är en kandidat för användning som nyckel.

NOTERA Nedan följer en kort förklaring av några av de förkortningar som används i Dates definitioner.

FD (funktionellt beroende) - funktionellt beroende. Med funktionellt beroende beror värdet på ett attribut på värdet av ett annat attribut som inte är en del av primärnyckeln.

Affärs normala former

Den tredje affärsnormala formen (3BNF) tar attribut som är oberoende av en primärnyckel till en annan enhet, där de är helt beroende av den primära nyckeln för den enheten.

Genomförd logisk datamodell

Fysisk datamodell

Samla in krav på dataanvändning

Krav på åtkomst och prestanda

Volumetriska egenskaper (en uppskattning av mängden data som ska lagras) som gör att administratören kan representera databasens fysiska volym

Uppskattning av antalet användare som behöver åtkomst till data samtidigt för att hjälpa dig designa din databas för acceptabla prestandanivåer

Aggregat, sammanfattning och annan beräknad eller härledd data som kan anses vara kandidater för lagring i beständiga datastrukturer

Rapporteringskrav och standardfrågor för att hjälpa databasadministratören att bygga index

Vyer (beständiga eller virtuella) som hjälper användaren att utföra dataaggregering eller filtrering.

Komponenter för fysiska datamodeller

Reverse engineering

Använda företagets funktionella gränser

Vad är en Enterprise Data Model?

Bygga en företagsdatamodell genom att utöka

Modellering metodik koncept

Det finns flera metoder för visuell datamodellering. ERwin stöder två:

IDEF1X (Integration Definition for Information Modeling - en integrerad beskrivning av informationsmodeller).

IE (Informationsteknik).

IDEF1X är en bra metod och användningen av dess notation är utbredd

Integrerad beskrivning av informationsmodeller

Informationsteknik

Slutsats

NOTERA Mångfald relation beskriver det maximala antalet sekundära entitetsinstanser som kan associeras med en instans av den ursprungliga entiteten.Nödvändighet av existens eller möjlighet till frånvaro relation tjänar till att bestämma det minsta antalet instanser av en sekundär enhet som kan associeras med en instans av originalet

Skicka ditt goda arbete i kunskapsbasen är enkelt. Använd formuläret nedan

Studenter, doktorander, unga forskare som använder kunskapsbasen i sina studier och arbete kommer att vara er mycket tacksamma.

Postat på http://www.allbest.ru/

1. Relationsdatamodell

1.1 Den relationella datamodellen. Grundläggande definitioner
1.2 Operationer på relationer

2. Företagsinformationssystem
Bibliografi

1. Relationsdatamodell

1.1 Den relationella datamodellen. Grundläggande definitioner

Inom matematiska discipliner motsvarar begreppet "tabell" begreppet "relation" (relation). Tabellen speglar ett objekt av den verkliga världen - en enhet, och var och en av dess linjer speglar en specifik instans av enheten. Varje kolumn har ett namn som är unikt för tabellen. Strängar har inga namn, deras ordning är inte definierad och antalet är inte logiskt begränsat. En av de främsta fördelarna med en relationsdatamodell är homogenitet (varje rad i en tabell har samma format). Det är upp till användaren att avgöra om respektive enheter är homogena. Detta löser problemet med modelllämplighet.

Grundläggande koncept:

* En relation är en tvådimensionell tabell som innehåller vissa data.

* Entitet - ett objekt av vilken karaktär som helst, data om vilken lagras i databasen. Attribut är egenskaper som kännetecknar en enhet (kolumner).

* Graden av samband är antalet kolumner.

* Relationsschema - en lista över attributnamn, till exempel ANSTÄLLDA (Nr, Fullständigt namn, Födelseår, Befattning, Avdelning).

* Domän - en uppsättning värden för attributen för en relation (datatyp).

* En tuppel är en tabellrad.

* Kardinalitet (kardinalitet) - antalet rader i tabellen.

* Primärnyckel är ett attribut som unikt identifierar raderna i en relation. En primärnyckel med flera attribut kallas en sammansatt primärnyckel. Primärnyckeln kan inte vara helt eller delvis tom (null). Nycklar som kan användas som primärnycklar kallas potentiella eller alternativa nycklar.

* En främmande nyckel är ett eller flera attribut för en tabell som kan fungera som primärnyckel för en annan tabell. Refererar till primärnyckeln för en annan tabell.

Normalisering är en process som syftar till att minska redundansen av information i en databas. Utöver själva datan kan även olika namn, objektnamn och uttryck normaliseras i databasen.

En icke-normaliserad databas innehåller information i en eller flera olika tabeller; detta ger intrycket att inkluderingen av data i en viss tabell inte beror på några uppenbara skäl. Detta tillstånd kan ha en negativ inverkan på datasäkerheten, den rationella användningen av diskutrymme, hastigheten på frågorna, effektiviteten i att uppdatera databasen och, kanske viktigast, integriteten hos den lagrade informationen. Databasen före normalisering är en struktur som logiskt inte har brutits ner i mer hanterbara, mindre tabeller ännu.

Normalformen är en sorts indikator på nivån, eller djupet, av databasnormalisering. Normaliseringsnivån för databasen motsvarar den normala form som den finns i.

1.2 Operationer på relationer

För att få tabellen till den första normala formen (1NF) måste du följa två regler:

1. Atomicitet eller odelbarhet. Varje kolumn måste innehålla ett odelbart värde.

2. Tabellen bör inte innehålla dubbletter av kolumner eller grupper av data.

Till exempel, om en tabell i ett fält innehåller den fullständiga adressen till en person (gata, stad, postnummer), kommer den inte att uppfylla 1NF-reglerna, eftersom den kommer att innehålla olika värden i en kolumn, vilket skulle vara ett brott av atomicitetsregeln. Eller om databasen innehåller data om filmer och den innehåller kolumnerna skådespelare1, skådespelare2, skådespelare3 kommer den inte heller att följa reglerna, eftersom uppgifterna kommer att upprepas.

Normalisering bör börja med att kontrollera databasstrukturen för kompatibilitet med 1NF. Alla kolumner som inte är atomära måste delas upp i sina beståndsdelar. Om det finns dubbletter av kolumner i tabellen måste de välja en separat tabell.

För att få tabellen till den första normala formen bör du:

* Hitta alla fält som innehåller flera delar av information.

* De data som kan delas upp i beståndsdelar måste placeras i separata fält.

* Flytta dubblettdata till en separat tabell.

* Kontrollera om alla tabeller matchar villkoren för den första normala formen.

För att få tabellerna till den andra normala formen (2NF), bör tabellerna redan vara i 1NF. Normalisering bör göras i ordning.

Nu, i andra normala form, måste villkoret vara uppfyllt - varje kolumn som inte är en nyckel (inklusive främmande) måste bero på primärnyckeln. Vanligtvis är dessa kolumner, som har värden som är oberoende av nyckeln, lätta att identifiera. Om uppgifterna i kolumnen inte är relaterade till nyckeln som beskriver raden, bör de separeras i en egen separat tabell. Primärnyckeln måste returneras till den gamla tabellen.

För att få basen till den andra normala formen måste du:

* Identifiera alla kolumner som inte är direkt beroende av den här tabellens primärnyckel.

* Skapa de obligatoriska fälten i användar- och forumtabellerna, välj från befintliga fält eller skapa primärnycklar från nya.

* Varje tabell behöver sin egen primärnyckel

* Skapa främmande nycklar och utse deras relationer mellan tabeller. Det sista steget av normalisering till 2NF kommer att vara allokeringen av främmande nycklar för kommunikation med tillhörande tabeller. Primärnyckeln för en tabell måste vara en främmande nyckel i en annan.

Tips:

Ett annat sätt att konvertera ett schema till 2NF är att titta på relationerna mellan tabellerna. Helst skapa alla en-till-många-relationer. Många-till-många relationer behöver omstruktureras.

En korrekt normaliserad tabell kommer aldrig att ha dubbletter av rader (två eller flera rader vars värden inte är nycklar och innehåller samma data).

Databasen kommer att vara i tredje normalform om den konverteras till andra normalform och varje icke-nyckelkolumn är oberoende av varandra. Om normaliseringsprocessen följs korrekt fram till denna punkt, kan det inte finnas några frågor om konverteringen till 3NF. Du bör vara medveten om att 3NF bryts om ändring av värdet i en kolumn kräver en ändring i den andra kolumnen.

För att få basen till den tredje normala formen behöver du:

* Bestäm vilka fält av vilka tabeller som har ömsesidigt beroende, d.v.s. fält som är mer beroende av varandra än på raden som helhet.

* Skapa matchande tabeller. Om det finns en problematisk kolumn i steg 1, skapa delade tabeller för den.

* Skapa eller allokera primärnycklar. Varje tabell måste ha en primärnyckel.

* Skapa de nödvändiga främmande nycklarna som bildar någon av relationerna.

I den fjärde normalformen är en ytterligare regel att det är nödvändigt att utesluta flervärdiga beroenden. Med andra ord måste alla rader i tabellen vara oberoende av varandra. Närvaron av någon rad X bör inte betyda att rad Y också finns någonstans i den här tabellen.

2. Företagens informationssystem

relationsmodelldatasystem

Ett system (från det grekiska systema - en helhet, en förening som består av delar) är en uppsättning element som interagerar med varandra och bildar en viss integritet, enhet. Här är några begrepp som ofta används för att karakterisera ett system.

1. Systemelement - en del av systemet som har ett specifikt funktionellt syfte. Komplexa element i system, i sin tur, bestående av enklare sammanlänkade element, kallas ofta delsystem.

2. Organisation av systemet - intern ordning och reda, konsistens i samspelet mellan systemelement, manifesterad, i synnerhet, genom att begränsa mångfalden av tillstånd av element inom systemet.

3. Systemets struktur - sammansättningen, ordningen och principerna för interaktion mellan elementen i systemet, som bestämmer systemets grundläggande egenskaper. Om de enskilda elementen i systemet är fördelade över olika nivåer och de interna kopplingarna mellan elementen är organiserade endast från högre till lägre nivåer och vice versa, då talar man om systemets hierarkiska struktur. Rent hierarkiska strukturer är praktiskt taget sällsynta, därför, något utvidgar detta koncept, förstås den hierarkiska strukturen vanligtvis som sådana strukturer, där, bland andra kopplingar, hierarkiska relationer är av primär betydelse.

4. Systemarkitektur - en uppsättning systemegenskaper som är väsentliga för användaren.

5. Systemets integritet - den grundläggande irreducerbarheten av systemets egenskaper till summan av egenskaperna hos dess individuella element (uppkomsten av egenskaper) och samtidigt beroendet av egenskaperna hos varje element på dess plats och funktion i systemet.

Informationssystem är en sammankopplad uppsättning verktyg, metoder och personal som används för att lagra, bearbeta och utfärda information för att uppnå det uppsatta målet "

Den federala lagen "om information, informatisering och informationsskydd" ger följande definition:

"Informationssystem är en organisatoriskt ordnad uppsättning dokument (uppsättningar av dokument) och informationsteknik, inklusive användning av datorteknik och kommunikation som implementerar informationsprocesser"

Skalklassificering

När det gäller skala delas informationssystem in i följande grupper:

* singel;

* grupp;

* företag.

Ett företagsinformationssystem är ett skalbart system utformat för integrerad automatisering av alla typer av ekonomiska aktiviteter för stora och medelstora företag, inklusive företag som består av en grupp företag som kräver enhetlig ledning.

Ett företagsinformationssystem kan betraktas som ett system som automatiserar mer än 80 % av ett företags divisioner.

Nyligen, i många publikationer som ägnas åt användningen av informationsteknik vid hantering av ekonomiska objekt, används ofta termen "företagsinformationssystem", som i dem hänvisar till de faktiska automatiserade informationssystemen för ekonomiska objekt.

Ett automatiserat informationssystem (AIS) är en kombination av olika typer av stöd, samt specialister utformade för att automatisera behandlingen av redovisnings- och analytisk information. Typerna av stöd är som regel homogena för olika system i sammansättning, vilket gör det möjligt att implementera principen om systemkompatibilitet under driften. I processen att studera AIS som ett komplext system är det nödvändigt att peka ut enskilda delar och element och överväga funktionerna i deras användning i stadierna av skapande och drift.

Företagsinformationssystem är en utveckling av system för arbetsgrupper, de är fokuserade på stora företag och kan stödja geografiskt spridda noder eller nätverk. I grund och botten har de en hierarkisk struktur på flera nivåer. Sådana system kännetecknas av en klient-server-arkitektur med specialisering av servrar eller en flerskiktsarkitektur. Vid utveckling av sådana system kan samma databasservrar användas som vid utveckling av gruppinformationssystem. Men i stora informationssystem är de mest använda servrarna Oracle, DB2 och Microsoft SQL Server.

För koncern- och företagssystem höjs kraven på driftsäkerhet och datasäkerhet avsevärt. Dessa egenskaper stöds av data-, referens- och transaktionsintegritetsstöd i databasservrarna.

Klassificering efter omfattning

Beroende på tillämpningsområdet delas informationssystem vanligtvis in i fyra grupper:

* transaktionsbearbetningssystem;

* Beslutssystem;

* Informations- och referenssystem;

* kontorsinformationssystem.

Bibliografi

1. Agaltsov, V.P. Databas. I 2 volymer V. 2. Distribuerade och fjärranslutna databaser: Lärobok / V.P. Agaltsov. - M .: ID FORUM, NITs INFRA-M, 2013.

2. Golitsyna, O.L. Databaser: Lärobok / O.L. Golitsyna, N.V. Maksimov, I.I. Popov. - M .: Forum, 2012.

3. Karpova, I.P. Databaser: Lärobok / I.P. Karpov. - SPb .: Peter, 2013.

4. Kirillov, V.V. Introduktion till relationsdatabaser Introduktion till relationsdatabaser. Kirillov, G.Yu. Gromov. - SPb .: BHV-Petersburg, 2012.

5. Pirogov, V.Yu. Informationssystem och databaser: organisation och design: Lärobok / V.Yu. Pirogov. - SPb .: BHV-Petersburg, 2009.

6. G.N. Fedorov. Informationssystem. - M .: Akademin, 2013.

7. A.E. Satunina, L.A. Sysoeva. Projektledning av företagets företagsinformationssystem. - M .: Finans och statistik, Infra-M, 2009.

Postat på Allbest.ru

...

Liknande dokument

Kärnan och egenskaperna hos typerna av datamodeller: hierarkiska, nätverk och relationella. Grundläggande begrepp för relationsdatamodellen. Attribut, databasrelationsschema. Dataintegritetsvillkor. Relationer mellan tabeller. Allmän förståelse för datamodellen.

Terminuppsats tillagd 2011-01-29

Företagsinformationssystem och databaser, deras användning för att förbättra och felsöka affärer. Klassificering av företagsinformationssystem. OLTP-klassinformationssystem. Snabb analytisk bearbetning.

terminsuppsats, tillagd 2011-01-19

Databaser med tvådimensionella filer och (DBMS). Skapa en databas och bearbeta frågor till dem med hjälp av ett DBMS. De viktigaste typerna av databaser. Grundläggande begrepp för relationsdatabaser. Grundläggande egenskaper hos relationer.

abstrakt, tillagt 2010-12-20

Databassystem koncept. Relationsmodellen och dess egenskaper. Integritet i relationsmodellen. Relationell algebra. Databasdesignproblem. Normala former av relationer. Designa en databas med hjälp av entity-relationship-metoden. ER-diagram. SQL-språk.

föreläsningskurs, tillagd 2008-10-03

En definierad logisk struktur av data som lagras i en databas. Grundläggande datamodeller. Element i relationsdatamodellen. Ett exempel på användning av främmande nycklar. Grundläggande krav på relationen mellan relationsdatamodellen.

presentation tillagd 2013-10-14

Databaser och deras användning i datoranvändning. Funktioner och grundläggande byggstenar i nätverksdatamodellen. Hierarkisk modell, föremål för ämnesområdet. Relationsmodell, dess synlighet, presentation av data i tabellform.

abstrakt, tillagt 2011-12-19

Typer och funktioner för Microsoft Access-databashanteringssystemet. Hierarkisk, nätverks-, relationsmodell för att beskriva databaser. Grundläggande begrepp för en databastabell. Funktioner för att skapa databasobjekt, grundläggande former. Tillgång till Internet i Access.

test, tillagt 2011-08-01

Moderna databashanteringssystem (DBMS). Analys av den hierarkiska datamodellen. Relationsdatamodell. Post-relationell datamodell som en utökad relationsmodell som tar bort begränsningen på odelbarheten av data lagrad i tabellposter.

vetenskapligt arbete, tillagt 2010-08-06

Datamodeller inom databashantering. Konceptuella datamodeller. Databasernas roll i informationssystem. Relationsdatamodell. Definition av ämnesområdet. Bygga en databasmodell för informationssystemet "Husdjur".

terminsuppsats, tillagd 2011-04-19

Informationsmodell i Access som ett slags förenklat substitut för ett verkligt objekt eller system. Grundläggande strukturer som bestämmer organisationen av data och relationerna mellan dem; en relationell typ av dataorganisation. Ett exempel på en databas inom beskattning.

Företagsdatamodellen innehåller element. Relationsdatamodell

"Sagan är en lögn - men det finns en antydan i den ..."

Debriefing

Antibräcklighet

Vad är ett datalager och varför bygger vi det

Nyckelfunktioner i datalager

Arkitektoniska koncept

Systemkärna

Warehouse Core Model och Enterprise Data Model

Primärt datalager (eller historiserad iscensättning eller driftlager)

Visa lager

Servicelager

Designa och underhålla lagerdatamodeller

Funktioner i datalagerprojekt

Data warehouse är anpassad programvara

Data Warehouse är ett integrationsprojekt

Data Warehouse är ett samarbetsprojekt

Datalagret har en längre livslängd än andra system

Gradvis iterativ utveckling

Datalager - "multi-project story"

Balans mellan innovation och beprövade lösningar

Epilog

Epilog

Industridatamodeller

Publikationer

ÄMNE V. FÖRETAGSDATABASER

Företagsdatamodell

Introduktion

Företagsdatamodell

Presentationsnivåer för företagsdatamodellen

ÄMNE V. FÖRETAGSDATABASER

Industridatamodeller

Publikationer

Skicka ditt goda arbete i kunskapsbasen är enkelt. Använd formuläret nedan

1. Relationsdatamodell

2. Företagens informationssystem

relationsmodelldatasystem

Ett system (från det grekiska systema - en helhet, en förening som består av delar) är en uppsättning element som interagerar med varandra och bildar en viss integritet, enhet. Här är några begrepp som ofta används för att karakterisera ett system.

1. Systemelement - en del av systemet som har ett specifikt funktionellt syfte. Komplexa element i system, i sin tur, bestående av enklare sammanlänkade element, kallas ofta delsystem.

2. Organisation av systemet - intern ordning och reda, konsistens i samspelet mellan systemelement, manifesterad, i synnerhet, genom att begränsa mångfalden av tillstånd av element inom systemet.

4. Systemarkitektur - en uppsättning systemegenskaper som är väsentliga för användaren.

5. Systemets integritet - den grundläggande irreducerbarheten av systemets egenskaper till summan av egenskaperna hos dess individuella element (uppkomsten av egenskaper) och samtidigt beroendet av egenskaperna hos varje element på dess plats och funktion i systemet.

Informationssystem är en sammankopplad uppsättning verktyg, metoder och personal som används för att lagra, bearbeta och utfärda information för att uppnå det uppsatta målet "

Den federala lagen "om information, informatisering och informationsskydd" ger följande definition:

"Informationssystem är en organisatoriskt ordnad uppsättning dokument (uppsättningar av dokument) och informationsteknik, inklusive användning av datorteknik och kommunikation som implementerar informationsprocesser"

Skalklassificering

När det gäller skala delas informationssystem in i följande grupper:

* singel;

* grupp;

* företag.

Ett företagsinformationssystem är ett skalbart system utformat för integrerad automatisering av alla typer av ekonomiska aktiviteter för stora och medelstora företag, inklusive företag som består av en grupp företag som kräver enhetlig ledning.

Ett företagsinformationssystem kan betraktas som ett system som automatiserar mer än 80 % av ett företags divisioner.

Nyligen, i många publikationer som ägnas åt användningen av informationsteknik vid hantering av ekonomiska objekt, används ofta termen "företagsinformationssystem", som i dem hänvisar till de faktiska automatiserade informationssystemen för ekonomiska objekt.

För koncern- och företagssystem höjs kraven på driftsäkerhet och datasäkerhet avsevärt. Dessa egenskaper stöds av data-, referens- och transaktionsintegritetsstöd i databasservrarna.

Klassificering efter omfattning

Beroende på tillämpningsområdet delas informationssystem vanligtvis in i fyra grupper:

* transaktionsbearbetningssystem;

* Beslutssystem;

* Informations- och referenssystem;

* kontorsinformationssystem.

Bibliografi

Liknande dokument

Återställning av lösenord