Hensikten med foredraget

Etter å ha studert materialet til denne forelesningen, vil du vite:

• hva bedriftsdatamodell ;
• hvordan konvertere bedriftsdatamodell inn i datavarehusmodellen;
• hovedelementer bedriftens datamodell ;
• presentasjonslag av bedriftsdatamodellen ;
• en algoritme for å transformere en bedriftsdatamodell til en flerdimensjonal datavarehusmodell ;

og lære å:

• utvikle datavarehusmodeller basert på bedriftens datamodell organisasjoner;
• designe et stjerneskjema ved å bruke CASE-verktøy;
• partisjonstabeller flerdimensjonal modell ved hjelp av CASE-verktøy.

Enterprise datamodell

Introduksjon

Kjernen i enhver HD er datamodellen. Uten en datamodell vil det være svært vanskelig å organisere dataene i HD. Derfor bør CD-utviklere bruke tid og krefter på å utvikle en slik modell. Utviklingen av HD-modellen faller på skuldrene til HD-designeren.

Sammenlignet med utformingen av OLTP-systemer, har designmetodikken til CD en rekke karakteristiske trekk knyttet til orienteringen av lagringsdatastrukturene for å løse problemene med analyse og informasjonsstøtte i beslutningsprosessen. HD-datamodellen skal gi en effektiv løsning på nettopp disse problemene.

Utgangspunktet i utformingen av CD kan være den såkalte bedriftsdatamodell(bedriftsdatamodell eller bedriftsdatamodell, EDM), som lages i prosessen med å designe en organisasjons OLTP-systemer. Ved utforming bedriftens datamodell vanligvis et forsøk på å lage en datastruktur basert på forretningsdrift som vil samle og syntetisere alle informasjonsbehovene til en organisasjon.

Og dermed, bedriftsdatamodell inneholder nødvendig informasjon for å bygge en CD-modell. Derfor, på det første stadiet, hvis en slik modell eksisterer i organisasjonen, HD-designeren kan starte HD-designet ved å løse transformasjonsproblemet bedriftens datamodell inn i HD-modellen.

Enterprise datamodell

Hvordan løse transformasjonsproblemet bedriftens datamodell inn i HD-modellen? For å løse dette problemet må du ha denne modellen, dvs. bedriftens datamodell skal bygges og dokumentert... Og du må forstå hva fra denne modellen og hvordan bør transformeres til HD-modellen.

La oss klargjøre konseptet fra en CD-designers ståsted bedriftens datamodell. Under bedriftens datamodell forstå en flernivå, strukturert beskrivelse av en organisasjons fagområder, fagområdedatastrukturer, forretningsprosesser og forretningsprosedyrer, organisasjonsdataflyter, tilstandsdiagrammer, dataprosessmatriser og andre modellrepresentasjoner som brukes i organisasjonens aktiviteter. Altså, i ordets videste forstand, bedriftsdatamodell er et sett med modeller på ulike nivåer som karakteriserer (modellerer på et eller annet abstrakt nivå) aktivitetene til en organisasjon, dvs. innhold bedriftsmodell avhenger direkte av hvilke modellkonstruksjoner som ble inkludert i den i en gitt organisasjon.

Hovedelementene bedriftens datamodell er:

• beskrivelse av organisasjonens fagområder (definisjon av aktivitetsområder);
• forholdet mellom fagområdene definert ovenfor;
• informasjonsdatamodell (ERD-modell eller enhetsrelasjonsmodell);
• beskrivelse for hvert fagområde:
  • enhetsnøkler;
  • enhetsattributter;
  • undertyper og supertyper;
  • forhold mellom enheter;
  • gruppere attributter;
  • forhold mellom fagområder;
• funksjonell eller forretningsprosessmodell;
• dataflytdiagrammer;
• tilstandsdiagrammer;
• andre modeller.

Og dermed, bedriftsdatamodell inneholder enheter, attributter og relasjoner som representerer informasjonsbehovene til en organisasjon. I fig. 16.1 viser hovedelementene bedriftens datamodell.

Presentasjonsnivåer for bedriftsdatamodellen

Enterprise datamodell underinndelt etter fagområder, som representerer grupper av enheter knyttet til å støtte spesifikke forretningsbehov. Noen fagområder kan dekke spesifikke forretningsfunksjoner som kontraktsstyring, mens andre kan inkludere enheter som beskriver produkter eller tjenester.

Hver logisk modell må samsvare med det eksisterende domenet bedriftens datamodell... Hvis den logiske modellen ikke oppfyller dette kravet, må en domenemodell legges til den.

Enterprise datamodell har vanligvis flere presentasjonsnivåer. Faktisk høy level(høy level) bedriftens datamodell det er en beskrivelse av hovedfagområdene i organisasjonen og deres relasjoner på enhetsnivå. I fig. 16.2 er et utdrag bedriftens datamodell toppnivå.

Ris. 16.2.

Diagrammet vist i figuren presenterer fire fagområder: "Kjøper" ( Kunde), "Kryss av" ( regnskap), "Rekkefølge" ( Rekkefølge) og "Produkt" ( Produkt). Som regel bare direkte forbindelser mellom fagområder, som for eksempel registrerer følgende faktum: kjøperen betaler fakturaen for varebestillingen. Detaljer og indirekte relasjoner på dette nivået bedriftsmodell ikke vist.

På den neste, mellomnivå(midtnivå) bedriftens datamodell detaljert informasjon om gjenstander til fagområder vises, dvs. nøkler og enhetsattributter, deres relasjoner, undertyper og supertyper, etc. For hvert domene i toppnivåmodellen er det én mellomnivåmodell. I fig. 16.3 viser det midtre presentasjonsnivået bedriftsmodell for et fragment av "Rekkefølge"-fagområdet.

Fra fig. 16.3 kan det ses at "Bestill"-fagområdet ( Rekkefølge) inkluderer flere enheter, definert gjennom deres attributter, og relasjonene mellom dem. Den presenterte modellen lar deg svare på spørsmål som datoen for bestillingen, hvem som gjorde bestillingen, hvem som sendte bestillingen, hvem som mottar bestillingen og en rekke andre. Fra diagrammet ovenfor kan det ses at i denne organisasjonen er det to typer bestillinger - bestillinger for en kampanje ( Kommersiell) og detaljhandelsordrer ( Detaljhandel).

Legg merke til det bedriftsdatamodell kan representere ulike sider ved organisasjonens virksomhet og med ulik grad av detaljering og fullstendighet. Hvis bedriftsmodell representerer alle sider ved organisasjonens aktiviteter, kalles det også organisasjonsdatamodell(bedriftsdatamodell).

Fra synspunktet om å designe en CD, en viktig faktor for å bestemme seg for å lage en CD-modell fra bedriftens datamodell er staten fullstendighet bedriftens datamodell.

Enterprise datamodell organisasjonen har karakteristikken av evolusjonær, dvs. det utvikles og forbedres hele tiden. Noen fagområder bedriftens datamodell kan være godt utviklet, for noen har arbeidet kanskje ikke startet ennå. Dersom et fragment av fagområdet ikke er utarbeidet bedriftens datamodell, så er det ingen måte å bruke denne modellen som utgangspunkt for design av CD.

Fullføringsgrad bedriftsmodell kan nivelleres i utformingen av CD som følger. Siden HD-utviklingsprosessen vanligvis er delt inn i tid i en sekvens av stadier, kan prosessen med design synkroniseres med fullføringsprosess utvikling av individuelle fragmenter bedriftens datamodell organisasjoner.

På det laveste presentasjonslaget av bedriftens datamodell informasjon om de fysiske egenskapene til databaseobjekter tilsvarende logisk datamodell midten presentasjonslaget av bedriftens datamodell.

Industridatamodeller

Hovedformålet med modeller er å lette orienteringen i datarommet og bidra til å synliggjøre detaljene som er viktige for forretningsutvikling. I dagens miljø, for en vellykket virksomhet, er det avgjørende å ha en klar forståelse av koblingene mellom de ulike komponentene og å ha en god ide om det overordnede bildet av organisasjonen. Identifikasjon av alle detaljer og relasjoner ved hjelp av modeller gir den mest effektive bruken av tiden og verktøyene for å organisere arbeidet til selskapet.

Datamodeller er abstrakte modeller som beskriver hvordan data presenteres og aksesseres. Datamodeller definerer dataelementer og relasjonene mellom dem i et bestemt område. En datamodell er et navigasjonsverktøy for både forretnings- og IT-fagfolk som bruker et spesifikt sett med symboler og ord for nøyaktig å forklare en bestemt klasse av informasjon fra den virkelige verden. Dette gir mulighet for bedre kommunikasjon innad i organisasjonen og skaper dermed et mer fleksibelt og stabilt applikasjonsmiljø.

Datamodellen definerer unikt betydningen av dataene, som i dette tilfellet er strukturerte data (i motsetning til ustrukturerte data som for eksempel et bilde, binær fil eller tekst, der betydningen kan være tvetydig).

Som regel skilles det mellom modeller på et høyere nivå (og mer generelt innhold) og et lavere (henholdsvis mer detaljert). Det øvre nivået av modellering er det såkalte konseptuelle datamodeller(konseptuelle datamodeller), som gir det mest generelle bildet av hvordan en virksomhet eller organisasjon fungerer. Den konseptuelle modellen inkluderer hovedbegrepene eller fagområdene som er kritiske for organisasjonens funksjon; vanligvis overstiger ikke antallet 12-15. En slik modell beskriver klassene av enheter som er viktige for organisasjonen (forretningsobjekter), deres egenskaper (attributter) og assosiasjonene mellom par av disse klassene (det vil si relasjoner). Siden terminologien i forretningsmodellering ennå ikke endelig har satt seg, kan konseptuelle datamodeller i ulike engelskspråklige kilder også kalles fagområdemodellen (som kan oversettes som domenemodeller) eller faget bedriftsdatamodell (faget bedriftsdata). modeller).

Det neste hierarkiske nivået er logiske datamodeller(logiske datamodeller). De kan også kalles bedriftsdatamodeller eller forretningsmodeller. Disse modellene inneholder datastrukturer, deres attributter og forretningsregler, og representerer informasjonen som brukes av en bedrift fra et forretningsperspektiv. I en slik modell er data organisert i form av enheter og relasjoner mellom dem. Den logiske modellen presenterer data på en måte som gjør det enkelt for forretningsbrukere å forstå. I en logisk modell kan en dataordbok skilles - en liste over alle enheter med deres presise definisjoner, som lar ulike kategorier av brukere ha en felles forståelse av alle input- og informasjonsutdatastrømmer av modellen. Det neste, lavere nivået av modellering er den fysiske implementeringen av den logiske modellen ved å bruke spesifikk programvare og tekniske plattformer.

Den logiske modellen inneholder en detaljert bedriftsbeslutning, som vanligvis har form av en normalisert modell. Normalisering er en prosess som sikrer at hvert dataelement i en modell kun har én verdi og er helt og unikt avhengig av primærnøkkelen. Dataelementer er organisert i grupper i henhold til deres unike identifikasjon. Forretningsreglene som styrer dataelementer må være fullt innlemmet i den normaliserte modellen med forutgående validering og validering. For eksempel vil et dataelement som Kundenavn sannsynligvis bli delt inn i Fornavn og Etternavn og gruppert med andre relaterte dataelementer i en kundeenhet med en primærnøkkel kunde-ID.

Den logiske datamodellen er uavhengig av applikasjonsteknologier som databaser, nettverksteknologier eller rapporteringsverktøy, og metodene for deres fysiske implementering. Det kan bare være én Enterprise Data Model i en organisasjon. Logiske modeller inkluderer vanligvis tusenvis av enheter, relasjoner og attributter. For eksempel kan en datamodell for en finansinstitusjon eller teleselskap inneholde ca 3000 bransjekonsepter.

Det er viktig å skille mellom logisk og semantisk datamodell. Den logiske datamodellen representerer en bedriftsforretningsløsning, og den semantiske datamodellen representerer en anvendt forretningsløsning. Den samme bedriftslogiske datamodellen kan implementeres ved hjelp av forskjellige semantiske modeller, dvs. semantiske modeller kan sees på som neste nivå av modellering som nærmer seg fysiske modeller. Dessuten vil hver av disse modellene representere en egen "del" av bedriftens datamodell i samsvar med kravene til ulike applikasjoner. For eksempel, i bedriftens logiske datamodell, vil klientenheten være fullstendig normalisert, og i den semantiske modellen for datamarkedet kan den representeres som en flerdimensjonal struktur.

En bedrift kan ha to måter å lage en bedriftslogisk datamodell på: bygge den uavhengig eller bruke en ferdig. bransjemodell(bransjelogisk datamodell). I dette tilfellet gjenspeiler forskjeller i termer bare forskjellige tilnærminger til å bygge den samme logiske modellen. I tilfelle et selskap uavhengig utvikler og implementerer sin egen logiske datamodell, kalles en slik modell som regel bare en bedriftslogisk modell. Hvis en organisasjon bestemmer seg for å bruke et ferdig produkt fra en profesjonell leverandør, kan vi snakke om en industrilogisk datamodell. Sistnevnte er en ferdiglaget logisk datamodell som gjenspeiler funksjonen til en bestemt industri med høy grad av nøyaktighet. En industrilogikkmodell er en domenespesifikk og integrert oversikt over all informasjonen som må ligge i et datavarehus for bedrifter for å svare på både strategiske og taktiske forretningsspørsmål. Som enhver logisk datamodell er industrimodellen uavhengig av søknadsbeslutninger. Den inkluderer heller ikke avledede data eller andre beregninger for raskere datainnhenting. Som regel er de fleste av de logiske strukturene til en slik modell godt nedfelt i dens effektive fysiske implementering. Slike modeller er utviklet av mange leverandører for et bredt spekter av aktivitetsområder: finans, produksjon, turisme, helsevesen, forsikring, etc.

En bransjelogisk datamodell inneholder informasjon som er felles for bransjen og kan derfor ikke være en helhetlig løsning for en bedrift. De fleste bedrifter må øke modellen med gjennomsnittlig 25 % ved å legge til dataelementer og utvide definisjoner. Out-of-the-box-modeller inneholder kun nøkkeldataelementer, og resten av elementene må legges til de tilsvarende forretningsobjektene under installasjonen av modellen i bedriften.

Bransjelogiske datamodeller inneholder en betydelig mengde abstraksjon. Abstraksjoner betyr foreningen av lignende konsepter under vanlige navn som Event eller Deltaker. Dette gir bransjemodeller fleksibilitet og enhetlighet. Konseptet med et arrangement er derfor aktuelt for alle bransjer.

Business Intelligence-spesialist Steve Hoberman identifiserer fem faktorer du bør vurdere når du skal bestemme om du skal anskaffe en industridatamodell. Den første er tiden og pengene som trengs for å bygge modellen. Hvis en organisasjon trenger å oppnå resultater raskt, vil bransjemodellen være gunstig. Bruk av en bransjemodell gir kanskje ikke umiddelbart et bilde av hele organisasjonen, men det kan spare mye tid. I stedet for å modellere seg selv, vil det brukes tid på å knytte eksisterende strukturer til bransjemodellen og diskutere hvordan man best kan tilpasse den til organisasjonens behov (for eksempel hvilke definisjoner som bør endres og hvilke dataelementer som bør legges til).

Den andre faktoren er tiden og pengene som kreves for å holde modellen i god stand. Hvis bedriftsdatamodellen ikke er en del av en metodikk som lar deg overvåke overholdelse av dens nøyaktighet og overholdelse av moderne standarder, blir en slik modell veldig raskt utdatert. Bransjedatamodellen kan forhindre at denne risikoen skjer da den holdes oppdatert med eksterne ressurser. Selvfølgelig skal endringer som skjer i organisasjonen reflekteres i modellen av selskapet selv, men bransjeendringer vil bli gjengitt i modellen av leverandøren.

Den tredje faktoren er erfaring med risikovurdering og modellering. Opprettelsen av en bedriftsdatamodell krever kvalifiserte ressurser fra både virksomheten og IT-personalet. Som regel er ledere godt klar over enten arbeidet til organisasjonen som helhet, eller aktivitetene til en bestemt avdeling. Få av dem har både bred (bedriftsomfattende) og dyp (innenfor avdelinger) kunnskap om virksomheten sin. De fleste ledere kjenner vanligvis bare ett område godt. Derfor, for å få det generelle bedriftsbildet, kreves det betydelige forretningsressurser. Dette øker også kravene til IT-personalet. Jo mer forretningsressurser som kreves for å lage og teste en modell, jo mer erfarne må analytikere være. De må ikke bare vite hvordan de skal få informasjon fra bedriftens ansatte, men også kunne finne et felles synspunkt på omstridte områder og kunne presentere all denne informasjonen på en integrert måte. Den som lager modellen (i mange tilfeller samme analytiker) må ha gode modelleringsferdigheter. Å bygge bedriftslogikkmodeller krever modellering "for fremtiden" og evnen til å bokstavelig talt konvertere kompleks virksomhet "til firkanter og linjer".

På den annen side lar bransjemodellen utnytte ekstern ekspertise. Bransjespesifikke logikkmodeller er bygget ved å bruke utprøvde modelleringsmetoder og team av erfarne fagfolk for å unngå vanlige og kostbare problemer som kan oppstå når man utvikler bedriftsdatamodeller i en organisasjon.

Den fjerde faktoren er eksisterende applikasjonsinfrastruktur og leverandørforhold. Hvis en organisasjon allerede bruker mange verktøy fra samme leverandør og har etablert relasjoner med ham, så er det fornuftig og bransjemodellen å bestille fra ham. Denne modellen vil kunne fungere fritt med andre produkter fra samme leverandør.

Den femte faktoren er utveksling av informasjon innen industrien. Hvis en bedrift trenger å kommunisere med andre organisasjoner som jobber i samme felt, kan bransjemodellen være svært nyttig i denne situasjonen. Organisasjoner innenfor samme bransje bruker lignende strukturelle komponenter og terminologi. I dag, i de fleste bransjer, er selskaper tvunget til å utveksle data for å kunne drive forretninger.

De mest effektive er bransjemodellene som tilbys av profesjonelle leverandører. Høy effektivitet av bruken deres oppnås på grunn av det betydelige detaljnivået og nøyaktigheten til disse modellene. De inneholder vanligvis mange dataattributter. I tillegg har skaperne av disse modellene ikke bare omfattende erfaring med modellering, men er også godt kjent med å bygge modeller for en bestemt bransje.

Bransjedatamodeller gir bedrifter en enkelt, integrert oversikt over forretningsinformasjonen deres. Mange bedrifter synes det er vanskelig å integrere dataene sine, selv om dette er en forutsetning for de fleste bedriftsomfattende prosjekter. I følge en studie fra The Data Warehousing Institute (TDWI) fant mer enn 69 % av de spurte organisasjonene integrasjon som en betydelig barriere for å ta i bruk nye applikasjoner. Tvert imot, implementering av dataintegrasjon genererer konkrete inntekter for selskapet.

Bransjedatamodellen, i tillegg til å koble til eksisterende systemer, gir store fordeler for bedriftsomfattende prosjekter som Enterprise Resource Planning (ERP), masterdataadministrasjon, business intelligence, forbedring av datakvalitet og medarbeiderutvikling.

Dermed er bransjelogiske datamodeller et effektivt verktøy for å integrere data og få et helhetlig syn på virksomheten. Bruken av logiske modeller ser ut til å være et nødvendig skritt mot etableringen av bedriftens datavarehus.

Publikasjoner

1. Steve Hoberman. Utnytte den logiske datamodellen for industrien som din bedriftsdatamodell.
2. Claudia Imhoff. Rask sporing av datavarehus og Business Intelligence-prosjekter via intelligent datamodellering

I økende grad retter IT-fagfolk oppmerksomheten mot dataadministrasjonsløsninger basert på industristandard datamodeller og forretningsbeslutningsmaler. Klare til å laste ned komplekse fysiske datamodeller og business intelligence-rapporter for spesifikke aktivitetsområder lar deg forene informasjonskomponenten i bedriften og øke hastigheten på gjennomføringen av forretningsprosesser betydelig. Løsningsmaler gjør det mulig for tjenesteleverandører å utnytte kraften til ikke-standard informasjon som er skjult i eksisterende systemer, og dermed redusere prosjektledelse, kostnader og risiko. For eksempel viser virkelige prosjekter at datamodeller og forretningsbeslutningsmaler kan redusere utviklingsinnsatsen med 50 %.

En industrilogikkmodell er en domenespesifikk, integrert og logisk strukturert oversikt over all informasjonen som må ligge i et datavarehus for bedrifter for å svare på både strategiske og taktiske forretningsspørsmål. Hovedformålet med modeller er å lette orienteringen i datarommet og bidra til å synliggjøre detaljene som er viktige for forretningsutvikling. Under moderne forhold, for en vellykket virksomhet, er det avgjørende å ha en klar forståelse av koblingene mellom de ulike komponentene og å ha en god ide om det overordnede bildet av organisasjonen. Identifikasjon av alle detaljer og relasjoner ved hjelp av modeller gir den mest effektive bruken av tiden og verktøyene for å organisere arbeidet til selskapet.

Datamodeller er abstrakte modeller som beskriver hvordan data presenteres og aksesseres. Datamodeller definerer dataelementer og relasjonene mellom dem i et bestemt område. En datamodell er et navigasjonsverktøy for både forretnings- og IT-fagfolk som bruker et spesifikt sett med symboler og ord for nøyaktig å forklare en bestemt klasse av informasjon fra den virkelige verden. Dette gir mulighet for bedre kommunikasjon innad i organisasjonen og skaper dermed et mer fleksibelt og stabilt applikasjonsmiljø.

Et eksempel på en "GIS for statlige og lokale myndigheter"-modell.

I dag er det strategisk viktig for programvare- og tjenesteleverandører å raskt kunne reagere på endringer i bransjen knyttet til teknologiske innovasjoner, fjerning av statlige restriksjoner og komplikasjoner av forsyningskjeder. Sammen med endringene i forretningsmodellen øker kompleksiteten og kostnadene for informasjonsteknologien som kreves for å støtte virksomhetens drift. Databehandling er spesielt vanskelig i et miljø der bedriftens informasjonssystemer, så vel som funksjonelle og forretningsmessige krav til dem, er i konstant endring.

Bransjedatamodeller er ment å bidra til å lette og optimalisere denne prosessen, ved å overføre IT-tilnærmingen til det moderne nivået.

Bransjedatamodeller fra selskapetEsri

Esri ArcGIS datamodeller er arbeidsmaler for bruk i GIS-prosjekter og for å lage datastrukturer for ulike applikasjonsområder. Datamodellbygging innebærer å lage en konseptuell design, logisk og fysisk struktur, som deretter kan brukes til å bygge en personlig eller bedrifts geodatabase. ArcGIS gir verktøy for å lage og administrere et databaseskjema, og datamodellmaler brukes til raskt å starte et GIS-prosjekt på tvers av en rekke applikasjoner og bransjer. Esri har brukt mye tid sammen med brukerfellesskapet for å utvikle en rekke maler som kan gi en rask start på utformingen av en bedrifts geodatabase. Disse prosjektene er beskrevet og dokumentert på support.esri.com/datamodels. Nedenfor, i den rekkefølgen de vises på dette nettstedet, er en semantisk oversettelse av Esris industrimodellnavn:

• Adresseregister
• Jordbruk
• Meteorologi
• Grunnleggende romlige data
• Biologisk mangfold
• Innvendig plass i bygninger
• Klimagassregnskap
• Opprettholde administrative grenser
• Militær etablering. Etterretningstjeneste
• Energi (inkludert den nye ArcGIS MultiSpeak-protokollen)
• Økologiske strukturer
• Beredskapsdepartementet. Brannvesen
• Skoginventar
• Skogbruk
• Geologi
• Nasjonalt nivå GIS (e-gov)
• Grunnvann og avløpsvann
• Helsevesen
• Arkeologi og bevaring av minnesteder
• nasjonal sikkerhet
• Hydrologi
• Den internasjonale hydrografiske organisasjonen (IHO). S-57-format for ENC
• Irrigasjon
• Matrikkelen
• Kommunale myndigheter
• Nautisk navigasjon
• Statens matrikkel
• Olje- og gassstrukturer
• Rørledninger
• Rasterlagring
• Batymetri, havbunnsrelieff
• Telekommunikasjon
• Transportere
• Vannforsyning, avløp, bolig og fellestjenester

Disse modellene inneholder alle nødvendige funksjoner i industristandarden, nemlig:

• er fritt tilgjengelig;
• er ikke knyttet til teknologien til den "valgte" produsenten;
• opprettet som et resultat av gjennomføringen av virkelige prosjekter;
• opprettet med deltakelse av bransjeeksperter;
• designet for å gi informasjonsinteraksjon mellom ulike produkter og teknologier;
• ikke motsi andre standarder og forskrifter;
• brukt i fullførte prosjekter rundt om i verden;
• er designet for å jobbe med informasjon gjennom hele livssyklusen til systemet som opprettes, og ikke selve prosjektet;
• kan utvides i henhold til kundens behov uten å miste kompatibilitet med andre prosjekter og/eller modeller;
• ledsaget av tilleggsmaterialer og eksempler;
• brukt i retningslinjer og tekniske materialer fra ulike industribedrifter;
• et stort fellesskap av deltakere, mens tilgang til fellesskapet er åpent for alle;
• et stort antall referanser til datamodeller i publikasjoner de siste årene.

Esri er en del av en ekspertgruppe av uavhengige organer som anbefaler ulike industrimodeller, for eksempel PODS (Pipeline Open Data Standards - en åpen standard for olje- og gassindustrien; PODS implementeres for tiden som en Esri PODS Esri Spatial 5.1.1 geodatabase ) eller en geodatabase (geodatabase) fra ArcGIS for Aviation, som tar hensyn til ICAO og FAAs anbefalinger, samt AIXM 5.0rden. I tillegg er det anbefalte modeller som strengt følger eksisterende industristandarder, slik som S-57 og ArcGIS for Maritime (marine og kystnære funksjoner), samt modeller laget av arbeidet utført av Esri Professional Services og er de facto standarder i det tilsvarende området. For eksempel, GIS for nasjonen og lokale myndigheter påvirket NSDI og INSPIRE standarder, og Hydro og grunnvann (hydrologi og grunnvann) er mye brukt i den fritt tilgjengelige profesjonelle ArcHydro suiten og kommersielle produkter. Det skal bemerkes at Esri også støtter de-facto standarder som NHDI. Alle foreslåtte datamodeller er dokumentert og klare til bruk i bedriftens IT-prosesser. Medfølgende materialer for modeller inkluderer:

• UML-diagrammer av relasjoner mellom enheter;
• datastrukturer, domener, kataloger;
• ferdige geodatabasemaler i ArcGIS GDB-format;
• prøvedata og prøveapplikasjoner;
• eksempler på datainnlastingsskript, eksempler på analyseverktøy;
• oppslagsverk om den foreslåtte datastrukturen.

Esri samler sin erfaring med å bygge industrimodeller i form av bøker og lokaliserer publisert materiale. Følgende bøker er lokalisert og utgitt av Esri CIS:

• Geospatial Service Oriented Architecture (SOA);
• Designe geodatabaser for transport;
• Geografiske informasjonssystemer for bedrifter;
• GIS: ny energi for elektriske og gassbedrifter;
• Olje og gass på et digitalt kart;
• Modellerer vår verden. Esri Geodatabase Design Guide;
• Tenker på GIS. GIS-planlegging: En håndbok for ledere;
• Geografiske informasjonssystemer. Grunnleggende;
• GIS for administrativ og økonomisk styring;
• Web GIS. Prinsipper og anvendelser;
• Systems Design Strategies, 26. utgave;
• 68 utgaver av ArcReview magazine med publikasjoner av selskaper og brukere av GIS-systemer;
• ... og mange andre tematiske notater og publikasjoner.

For eksempel boken " Modeller vår verden ..."(oversettelse) er en omfattende guide og referanse for GIS-datamodellering generelt, og geodatabasedatamodell spesielt. Boken viser hvordan man kan komme opp med de riktige datamodelleringsbeslutningene, beslutninger som er involvert i alle aspekter av et GIS-prosjekt, fra databasedesign til data- og datainnsamling til romlig analyse og visualisering Beskriver i detalj hvordan man designer en geografisk database som passer for prosjektet, konfigurerer databasefunksjonalitet uten programmering, administrerer arbeidsflyt i komplekse prosjekter, modellerer ulike nettverksstrukturer som elv, transport eller elektrisk nettverk, integrer satellittbilder i prosessen med geografisk analyse og visning, og lag 3D-modeller av GIS-data. Book " Designe geodatabaser for transport"inneholder metodiske tilnærminger som har blitt testet på et stort antall prosjekter og fullt ut i samsvar med lovkravene i Europa og USA, samt internasjonale standarder. Og i boken" GIS: Ny energi for elektriske og gassanlegg"Ved å bruke eksempler fra den virkelige verden viser den fordelene som bedriftens GIS kan gi energileverandøren, inkludert aspekter som kundeservice, nettverksdrift og andre forretningsprosesser.

Noen av bøkene, oversatt og original, utgitt på russisk av Esri CIS og DATA +. De tar opp både konseptuelle problemer knyttet til GIS-teknologi og mange anvendte aspekter ved modellering og distribusjon av GIS av forskjellige størrelser og formål.

Vi vil vurdere bruken av industrimodeller ved å bruke eksemplet med BISDM (Building Interior Space Data Model, informasjonsmodell for det indre rommet til en bygning) versjon 3.0. BISDM er en utvikling av en mer generell BIM-modell (Bygningsinformasjonsmodell) og er beregnet for bruk i prosjektering, konstruksjon, drift og demontering av bygninger og konstruksjoner. Brukt i GIS-programvare lar den deg effektivt utveksle geodata med andre plattformer og samhandle med dem. Refererer til den generelle gruppen av FM-oppgaver (organisasjonsinfrastrukturstyring). La oss liste opp hovedfordelene med BISDM-modellen, hvis bruk tillater:

• organisere utveksling av informasjon i et heterogent miljø i henhold til enhetlige regler;
• få en "fysisk" utførelse av BIM-konseptet og anbefalte regler for byggeprosjektledelse;
• å opprettholde ved hjelp av GIS et enkelt depot gjennom hele livssyklusen til en bygning (fra design til dekommisjonering);
• koordinere arbeidet til ulike spesialister i prosjektet;
• visualisere planlagt tidsplan og byggetrinn for alle deltakere;
• gi et foreløpig estimat av kostnad og byggetid (4D og 5D data);
• overvåke fremdriften til prosjektet;
• sikre drift av bygningen av høy kvalitet, inkludert vedlikehold og reparasjoner;
• bli en del av aktivastyringssystemet, inkludert funksjonene for å analysere effektiviteten av bruken av plass (leasing, lager, ansattes ledelse);
• beregne og administrere bygningens energieffektivitetsmål;
• simulere bevegelsen av menneskelige strømmer.

BISDM definerer reglene for arbeid med romlige data på nivå med de interne lokalene i en bygning, inkludert formål og bruk, lagt kommunikasjon, installert utstyr, regnskap for reparasjoner og vedlikehold, logging av hendelser og relasjoner til andre bedriftsmidler. Modellen bidrar til å skape et enhetlig depot av geografiske og ikke-geografiske data. Erfaringene til verdens ledende selskaper ble brukt til å isolere enheter og modellere på geodatabasenivå (geodatabase) av de romlige og logiske relasjonene til alle fysiske elementer som danner både selve bygningen og dens interne premisser. Å følge prinsippene til BISDM kan betydelig forenkle oppgavene med integrasjon med andre systemer. Det første trinnet er vanligvis CAD-integrasjon. Deretter, under driften av bygget, benyttes datautveksling med ERP- og EAM-systemer (SAP, TRIRIGA, Maximo, etc.).

Visualisering av BISDM strukturelle elementer ved hjelp av ArcGIS.

Ved bruk av BISDM mottar kunden / eieren av anlegget en ende-til-ende utveksling av informasjon fra ideen om å lage et objekt til utvikling av et komplett prosjekt, kontroll av konstruksjon med mottak av oppdateringer datoinformasjon innen tidspunktet anlegget settes i drift, kontroll av parametere under drift, og til og med under rekonstruksjon eller avvikling av anlegget. Etter BISDM-paradigmet blir GIS og den geografiske databasen opprettet med dets hjelp et felles datalager for relaterte systemer. Ofte inneholder GDB data opprettet og drevet av tredjepartssystemer. Dette må tas i betraktning ved utforming av arkitekturen til systemet som lages.

På et visst stadium lar den akkumulerte "kritiske massen" av informasjon deg flytte til et nytt kvalitetsnivå. For eksempel, etter fullføring av designfasen av et nytt bygg, er det mulig å automatisk visualisere 3D-undersøkelsesmodeller i GIS, kompilere en liste over installert utstyr, beregne kjørelengden til verktøy som skal legges, utføre en rekke kontroller og til og med gi et foreløpig økonomisk overslag over prosjektkostnaden.

Nok en gang merker vi at når BISDM og ArcGIS brukes sammen, blir det mulig å automatisk bygge 3D-modeller fra de akkumulerte dataene, siden geodatabasen inneholder en fullstendig beskrivelse av objektet, inkludert z-koordinater, etasjemedlemskap, typer elementforbindelser , utstyrsinstallasjonsmetoder, materiale, tilgjengelige veier for bevegelse av personell, funksjonelle formål med hvert element, etc. etc. Det skal bemerkes at etter den første importen av alle designmaterialer til BISDM GDB, er det behov for ytterligere informasjonsinnhold for:

• plassering av 3D-modeller av objekter og utstyr på anviste steder;
• samle informasjon om kostnadene for materialer og prosedyren for legging og installasjon;
• kontroll av permeabilitet i henhold til dimensjonene til det installerte ikke-standardutstyret.

På grunn av bruken av ArcGIS er det lettere å importere ytterligere 3D-objekter og referanser fra eksterne kilder, fordi ArcGIS Data Interoperability lar deg lage prosedyrer for å importere slike data og plassere dem riktig i modellen. Alle formater som brukes i bransjen støttes, inkludert IFC, AutoCAD Revit, Bentlye Microstation.

Bransjedatamodeller fra IBM

IBM tilbyr et sett med lagringsadministrasjonsverktøy og modeller for en rekke forretningsområder:

• IBM Banking and Financial Markets Data Warehouse (finans)
• IBM Banking Data Warehouse
• IBM Banking Process and Service Models
• IBM Health Plan Data Model (helsetjenester)
• IBM Insurance Information Warehouse (forsikring)
• IBMs forsikringsprosess og servicemodeller
• IBM Retail Data Warehouse (detaljhandel)
• IBM Telecommunications Data Warehouse (telekommunikasjon)
• InfoSphere Warehouse Pack:
  - for kundeinnsikt (for å forstå kunder)
  - for Market and Campaign Insight (for å forstå selskapet og markedet)
  - for Supply Chain Insight (for å forstå leverandører).

For eksempel modellen IBMBankvirksomhetogFinansiellMarkederDataLager er designet for å løse de spesifikke problemene til banknæringen når det gjelder data, og IBMBankvirksomhetProsessogServiceModeller- når det gjelder prosesser og SOA (Service Oriented Architecture). For telekommunikasjonsbransjen presenteres modeller IBMInformasjonFrameWork (IFW) og IBMTelekommunikasjonDataLager (TDW)... De bidrar til å fremskynde prosessen med å lage analytiske systemer betydelig, samt redusere risikoen knyttet til utviklingen av business intelligence-applikasjoner, bedriftsdataadministrasjon og organisering av datavarehus, med tanke på spesifikasjonene til telekommunikasjonsindustrien. Mulighetene til IBM TDW dekker hele spekteret av telekommunikasjonsmarkedet - fra Internett-leverandører og kabelnettverksoperatører som tilbyr lednings- og trådløse telefonitjenester, dataoverføring og multimedieinnhold, til multinasjonale selskaper som leverer telefon-, satellitt-, langdistanse- og internasjonale kommunikasjonstjenester, som samt organisasjoners globale nettverk. I dag brukes TDW av store og små leverandører av tråd- og trådløse tjenester over hele verden.

Et verktøy som heter InfoSphere Warehouse Pack for Customer Insight gir strukturert og lett distribuerbart forretningsinnhold for et økende antall forretningsprosjekter og bransjer, inkludert bank, forsikring, finans, helseforsikring, telekommunikasjon, detaljhandel og distribusjon. For bedriftsbrukere InfoSphere Warehouse Pack for Market and Campaign Insight bidrar til å maksimere effektiviteten av markedsanalyseaktiviteter og markedsføringskampanjer gjennom en trinnvis prosess for å utvikle og ta hensyn til virksomhetens spesifikasjoner. Ved bruk av InfoSphere Warehouse Pack for Supply Chain Insight organisasjoner har muligheten til å motta aktuell informasjon om forsyningskjedeoperasjoner.

Esris posisjon innenfor IBMs løsningsarkitektur.

Spesielt bemerkelsesverdig er IBMs tilnærming til verktøy og verktøy. For å møte de økende kravene til forbrukere trenger verktøy en mer fleksibel arkitektur enn de som brukes i dag, samt en industristandard objektmodell for å lette den frie flyten av informasjon. Dette vil øke kommunikasjonsevnen til verktøy ved å muliggjøre mer kostnadseffektiv interoperabilitet og gi nye systemer bedre synlighet av alle ressursene som trengs, uansett hvor de befinner seg i organisasjonen. Grunnlaget for denne tilnærmingen er SOA (Service Oriented Architecture), en komponentmodell som kartlegger funksjonene til avdelinger og tjenester til ulike applikasjoner som kan gjenbrukes. "Tjenestene" til slike komponenter utveksler data gjennom grensesnitt uten stiv binding, og skjuler for brukeren all kompleksiteten til systemene bak dem. I denne modusen kan bedrifter enkelt legge til nye applikasjoner uavhengig av programvareleverandør, operativsystem, programmeringsspråk eller andre iboende egenskaper ved programvaren. Basert på SOA er konseptet under implementering SIKKER ( Solution Architecture for Energy), lar det energiselskapet få et standardbasert, helhetlig syn på infrastrukturen.

Esri ArcGIS® er en globalt anerkjent programvareplattform for geografiske informasjonssystemer (GIS), som gir opprettelse og administrasjon av digitale eiendeler for elektrisk kraft, gassoverføring, distribusjon og telekommunikasjonsnettverk. ArcGIS lar deg utføre den mest komplette beholdningen av komponentene i det elektriske distribusjonsnettverket, med tanke på deres romlige plassering. ArcGIS utvider IBM SAFE-arkitekturen dramatisk ved å tilby verktøyene, applikasjonene, arbeidsflytene, analyse- og infsom trengs for å administrere en smart energibedrift. ArcGIS innenfor rammen av IBM SAFE lar deg motta informasjon fra ulike kilder om infrastrukturanlegg, eiendeler, kunder og ansatte med nøyaktige data om deres plassering, samt opprette, lagre og behandle georeferert informasjon om bedriftsressurser (støtter, rørledninger, ledninger) , transformatorer, kabelkanaler etc.). ArcGIS innenfor SAFE-infrastrukturen kobler dynamisk sammen kjernevirksomhetsapplikasjoner ved å kombinere data fra GIS, SCADA og kundeservicesystemer med ekstern informasjon som trafikkintensitet, værforhold eller satellittbilder. Verktøy bruker denne kombinerte informasjonen til en rekke formål, fra S.O.R. (det overordnede bildet av driftsmiljøet) til inspeksjon, vedlikehold, nettverksanalyse og planlegging.

Informasjonskomponentene til et energiselskap kan modelleres ved hjelp av flere nivåer som spenner fra det laveste, fysiske, til det høyeste, mest komplekse nivået av forretningslogikk. Disse lagene kan integreres for å møte typiske bransjekrav som automatisert målelogging og tilsynskontroll og datainnsamling (SCADA). Ved å bygge SAFE-arkitekturen, gjør verktøy betydelige fremskritt i å fremme en bransjeomfattende åpen objektmodell kalt Common Information Model (CIM) for energi og verktøy. Denne modellen gir det nødvendige rammeverket for å flytte mange virksomheter mot en tjenesteorientert arkitektur, da den oppmuntrer til bruk av åpne standarder for strukturering av data og objekter. På grunn av det faktum at alle systemer bruker de samme objektene, vil forvirringen og uelastisiteten knyttet til ulike implementeringer av de samme objektene reduseres til et minimum. Dermed vil definisjonen av klientobjektet og andre viktige forretningsobjekter være enhetlig på tvers av alle systemer i strømforsyningsselskapet. Nå, med CIM, kan tjenesteleverandører og tjenesteforbrukere dele en felles datastruktur, noe som gjør det enklere å outsource forretningskomponenter med høy verdi ettersom CIM etablerer en felles base å bygge informasjonsutveksling på.

Konklusjon

Omfattende bransjedatamodeller gir bedrifter en enkelt, integrert oversikt over forretningsinformasjonen deres. Mange bedrifter synes det er vanskelig å integrere dataene sine, selv om dette er en forutsetning for de fleste bedriftsomfattende prosjekter. I følge en studie fra The Data Warehousing Institute (TDWI) fant mer enn 69 % av de spurte organisasjonene integrasjon som en betydelig barriere for å ta i bruk nye applikasjoner. Tvert imot gir implementeringen av dataintegrasjon selskapet konkrete inntekter og økt effektivitet.

En godt konstruert modell identifiserer unikt betydningen av dataene, som i dette tilfellet er strukturerte data (i motsetning til ustrukturerte data som et bilde, binær fil eller tekst, der betydningen kan være tvetydig). Mest effektive er bransjemodellene som tilbys av profesjonelle leverandører som Esri og IBM. Den høye avkastningen på å bruke modellene deres oppnås på grunn av det betydelige detaljnivået og nøyaktigheten. De inneholder vanligvis mange dataattributter. I tillegg har både Esri og IBM lang erfaring med modellering og er godt kjent med å bygge bransjespesifikke modeller.

Det ser ut til at temaet utvikling av datavarehus nå har gått inn i et nytt utviklingsstadium. Nye teknologier, tilnærminger og verktøy dukker opp. Deres studie, testing og intelligente applikasjon lar oss lage virkelig interessante og nyttige løsninger. Og ta dem til implementering, og nyt det faktum at utviklingen din brukes i virkelig arbeid og er nyttig.

Epilog

I utarbeidelsen av denne artikkelen prøvde jeg å fokusere primært på arkitekter, analytikere og utviklere som jobber direkte med datavarehus. Men det viste seg at hun uunngåelig «tok temaet litt bredere» – og andre kategorier lesere falt inn i synsfeltet. Noen punkter vil virke kontroversielle, noen er uklare, noen er åpenbare. Folk er forskjellige – med ulik bakgrunn, bakgrunn og posisjon.
For eksempel er typiske lederspørsmål "når skal man ansette arkitekter?", "Når skal man gjøre arkitektur?" høres for oss (utviklere, designere) ganske rart ut, fordi for oss vises systemets arkitektur med dets fødsel - det spiller ingen rolle om vi er klar over det eller ikke. Og selv om det ikke er noen formell rolle for en arkitekt i et prosjekt, inkluderer en normal utvikler alltid sin egen interne arkitekt.

I det store og hele spiller det ingen rolle hvem som nøyaktig utfører rollen som arkitekt – det er viktig at noen stiller lignende spørsmål og undersøker svarene. Dersom arkitekten er tydelig utpekt, betyr dette kun at han er hovedansvarlig for systemet og dets utvikling.
Hvorfor fant jeg temaet "antiskjørhet" relevant for dette emnet?

"Det unike med antiskjørhet er at det lar oss jobbe med det ukjente, å gjøre noe under forhold når vi ikke forstår hva vi gjør, og å oppnå suksess."/ Nassim N. Talb /

Derfor er ikke krisen og en høy grad av usikkerhet en unnskyldning til fordel for fraværet av arkitektur, men faktorer som forsterker behovet.

Tagger:

• arkitektur
• datalager

Legg til merkelapper

Artikkelen beskriver hovedarkitekturene til datavarehus, diskuterer noen av de generelle prinsippene for konstruksjonen deres. Metoder for å representere hierarkier i en relasjonsdatastruktur er beskrevet i detalj.

Introduksjon

På begynnelsen av åttitallet av forrige århundre, i perioden med rask utvikling avr, oppsto det en forståelse av de begrensede mulighetene for deres anvendelse med det formål å analysere data og bygge på deres grunnlagssystemer for støtte og beslutningstaking. . Registreringssystemer ble opprettet for å automatisere rutineoperasjonene for å gjøre forretninger - fakturering, utarbeide kontrakter, sjekke statusen til et lager, etc., og hovedbrukerne av slike systemer var linjepersonell. Hovedkravene for slike systemer var å sikre den transaksjonelle karakteren av endringene og maksimere hastigheten på gjennomføringen av dem. Det er disse kravene som avgjorde valget av relasjons-DBMS og enhetsrelasom de viktigste tekniske løsningene som ble brukt i konstruksjonen av registreringssystemer.

For ledere og analytikere var det på sin side nødvendig med systemer som ville tillate:

Åpenbart oppfylte ikke opptakssystemene noen av kravene ovenfor. I registreringssystemet er informasjonen kun relevant på tidspunktet for tilgang til databasen, i neste øyeblikk for samme forespørsel kan du få et helt annet resultat. Grensesnittet til opptakssystemene er designet for å utføre stivt definerte operasjoner, og muligheten for å oppnå resultater for en ad-hoc-forespørsel er svært begrenset. Evnen til å behandle store datamengder er også lav på grunn av innstillingen av DBMS for å utføre korte transaksjoner og den uunngåelige nedgangen i arbeidet til andre brukere.

Svaret på dette behovet var fremveksten av en ny teknologi for å organisere databaser - datalagringsteknologi.

Definisjon og typiske arkitekturer for HD

Konseptet med et datavarehus er basert på to hovedideer - integreringen av disaggregerte detaljerte data (detaljert i den forstand at de beskriver noen spesifikke fakta, egenskaper, hendelser, etc.) i en enkelt lagring og separasjonen av datasett og applikasjoner som brukes for operasjonell behandling og brukes til å løse analyseproblemer. Definisjonen av "datavarehus" ble først gitt av William G. Inmon i sin monografi. I den definerte han datavarehuset som "et emneorientert, integrert, inneholdende historiske data, ikke-destruktivt datasett designet for å støtte ledelsesbeslutninger."

Konseptuelt kan datavarehusmodellen representeres i form av diagrammet vist i figur 1. Data fra ulike kilder er plassert i CD-en, og beskrivelsene av disse dataene er plassert i metadatalageret. Sluttbrukeren, ved hjelp av ulike verktøy (visualisering, rapportering, statistisk behandling, etc.) og innholdet i depotet, analyserer dataene i lageret. Resultatet av hans aktivitet er informasjon i form av ferdige rapporter, funnet skjulte mønstre, eventuelle spådommer. Siden arbeidsmidlene til sluttbrukeren med datavarehuset kan være svært forskjellige, bør valget deres teoretisk sett ikke påvirke strukturen og vedlikeholdsfunksjonene i en oppdatert tilstand.

Den fysiske implementeringen av det gitte konseptuelle opplegget kan være svært mangfoldig. De vanligste tilnærmingene er listet opp nedenfor.

Virtuell datalagring Er et system som representerer grensesnitt og metoder for tilgang til opptakssystemet som emulerer arbeidet med data i dette systemet, som med et datavarehus. Et virtuelt datavarehus kan organiseres ved å opprette en rekke visninger i databasen, eller ved å bruke spesielle tilgangsverktøy, for eksempel Desktop OLAP-produkter, som inkluderer for eksempel BusinessObjects, Brio Enterprise og andre.

De viktigste fordelene med denne tilnærmingen er:

Imidlertid har det mye flere ulemper enn fordeler. Ved å lage et virtuelt datavarehus skaper du ikke varehuset som sådan, men illusjonen om dets eksistens. Datalagringsstrukturen og datalagringen i seg selv gjennomgår ikke endringer, og problemer gjenstår:

	Opptreden;
	Datatransformasjoner;
	Integrasjon av data med andre kilder;
	Mangel på historie;
	Data renhet;
	Avhengighet av tilgjengeligheten til hoveddatabasen;
	Avhengighet av strukturen til hoveddatabasen.

To-lags arkitektur datavarehus innebærer konstruksjon av datamart uten å opprette en sentral lagring, mens informasjonen kommer fra et lite antall registreringssystemer og er begrenset til et spesifikt fagområde. Når du bygger datamars, brukes de grunnleggende prinsippene for å bygge datavarehus, som vil bli diskutert nedenfor, slik at de kan betraktes som datavarehus i miniatyr. Fordelene med datamars er:

Å bygge et fullverdig bedriftsdatavarehus gjøres vanligvis i tre-lags arkitektur(Det skal bemerkes at her betyr ikke trelagsarkitekturen "DB - Application Server - Client" strukturen). Det første nivået inneholder en rekke datakilder - interne registreringssystemer, referansesystemer, eksterne kilder (data fra nyhetsbyråer, makroøkonomiske indikatorer). Det andre nivået inneholder et sentralt datavarehus, hvor informasjon fra alle kilder fra første nivå samles inn, og eventuelt et operasjonelt datavarehus (OSD). Driftslageret inneholder ikke historiske data og utfører to hovedfunksjoner. For det første er det en kilde til analytisk informasjon for operativ ledelse, og for det andre forberedes data her for senere lasting i et sentralt depot. Dataforberedelse forstås som deres transformasjon og implementering av visse kontroller. Tilstedeværelsen av en OSD er ganske enkelt nødvendig med forskjellige regler for mottak av informasjon fra kilder. Det tredje nivået i den beskrevne arkitekturen er et sett med domenespesifikke datamars, hvor informasjonskilden er det sentrale datavarehuset. Det er med datamarts de fleste sluttbrukere jobber.

Designe strukturen til et relasjonsdatavarehus

HD er bygget på grunnlag av en flerdimensjonal datamodell. En flerdimensjonal datamodell innebærer valg av separate dimensjoner (tid, geografi, kunde, konto) og fakta (salgsvolum, inntekt, varemengde), som analyseres i henhold til de valgte dimensjonene. En flerdimensjonal datamodell kan implementeres fysisk både i flerdimensjonale DBMS og i relasjonelle. I sistnevnte tilfelle utføres det i henhold til "stjerne" eller "snøfnugg" -skjemaet. Disse skjemaene forutsetter allokering av faktatabeller og dimensjonstabeller. Hver faktatabell inneholder detaljerte data og fremmednøkler for dimensjonstabellene. Teorien om å konstruere en flerdimensjonal datamodell og dens implementering i en relasjonsstruktur er mye dekket i både utenlandsk og innenlandsk litteratur.

Blant de dårlig dekkede temaene er problemet med å representere hierarkier. Som et eksempel på en måling som er mye brukt i analysen av en virksomhet og har en hierarkisk struktur, kan vi sitere en katalog over kostnadsposter. Tenk på kostnadssentermodellen vist i figur 2.

Klassisk informatikk løser problemet med å representere hierarkier ved å bruke rekursiv kommunikasjon. Denne enkle løsningen lar deg plassere et tre av enhver dybde og dimensjon i ett bord. I vårt tilfelle vil dataene som vurderes bli presentert i følgende form:

Foreldre-ID 1 Selskap 2 Kontroll 3 Infrastruktur 4 Produksjon 5 6 Service 7 Felt A 8 Felt B

Tabell 1.

Imidlertid er dens største ulempe skjult i enkelheten til denne løsningen. Dessverre støtter ikke standard SQL rekursive pekere, så andre metoder brukes til å representere trær i HD.

Metoden foreslått av Joe Celko er basert på settteori. I denne metoden krysses alle noder i treet i en direkte gjennomløpsrekkefølge, og for hver node fylles to verdier - venstre og høyre kantlinje, og for hver node av tregrenen fylles den venstre grensen først og bare så høyre - når man flytter tilbake fra etterkommere til foreldre. Så i vårt eksempel vil nummereringen av noder være som følger:

Med denne nummereringen av noder inneholder hver forelder barn, hvis venstre og høyre kant ligger i intervallet mellom venstre og høyre kant til forelderen. På samme måte har alle foreldre til et barn en venstre kant som er mindre enn venstre kant av barnet og en høyre kant som er større enn høyre kant av barnet. Derfor kan summen av kostnadene for et bestemt kostnadssted og alle dets komponenter fås med én forespørsel. For å få infrastrukturkostnader kan du for eksempel kjøre følgende SQL-spørring:

velg sum (faktatabell.kostnad)
fra faktatabell, dimensjonstabell D1, dimensjonstabell D2
der faktatabell.dimensjon_id = D2.id
og D2.venstre> = D1.venstre
og D2.høyre<= D1.right
og D1.name = "Infrastruktur"

For å lette arbeidet med en slik referanse, i tillegg til venstre og høyre felt, legg til to felt til: "Nivå" - nivået til en node i treet, "Is_leaf" - et flagg som viser om en node er et blad i treet eller ikke. Dermed får vi en tabell "dimensjonstabell" (se tabell 2), som lar deg lagre et tre med hvilken som helst hekkedybde og dimensjon og lar deg velge barn og foreldre med en enkelt spørring.

1 Selskap 2 Kontroll 3 Infrastruktur 4 Produksjon 5 6 Service 7 Felt A 8 Felt B

Tabell 2. Representasjon av hierarkier ved bruk av venstre og høyre kantlinje

En annen måte, beskrevet av Ralph Kimball, er basert på introduksjonen av en hjelpetabell der faktatabellen er knyttet til dimensjonstabellen. Denne hjelpetabellen gjenspeiler den hierarkiske strukturen til dimensjonen og overholder følgende lov: Hjelpetabellen inneholder hele settet med foreldre-barn-par, og barnet er kanskje ikke et umiddelbart barn av forelderen. Strukturen til en slik tabell og dens innhold er vist i tabell 3.

Foreldre-ID Barne-ID Avstand 1 1 1 1 1 1 1 1 2 2 0 Y 3 3 0 N 3 5 1 N 3 6 1 N 4 4 0 N 4 7 1 N 4 8 1 N 5 5 0 Y 6 6 0 Y 7 7 0 Y 8 8 0 Y

Tabell 3. Struktur og innhold i hjelpetabellen.

Nå, ved å koble faktatabellen (se figur 4) med underordnet ID i hjelpetabellen, og dimensjonstabellen med overordnet ID, kan vi beregne summen av kostnadene for hvert kostnadssenter og alle dets bestanddeler med én spørring , som i forrige tilfelle. Samtidig, ved å legge til begrensninger i feltene "Avstand" og "Er blad", kan vi enkelt beregne kostnadene for et hvilket som helst nivå i hierarkiet.

velg sum (faktatabell.kostnad)
fra faktatabell, dimensjonstabell, hjelpetabell
hvor fact_table.dimension_id = helper_table.child_id
og dimension_table.dimension_id = helper_table.parent_id
og dimension_table.name = "Infrastruktur"
og helper_table.distance = 1

Problemet med å designe hierarkiske referanser er enda mer komplisert når en dimensjon kan ha flere alternative hierarkier og det blir ganske vanskelig å løse når det er nødvendig å vedlikeholde endringshistorikken i dimensjonstabellen.

Generelt er problemet med sakte skiftende dimensjoner interessant i seg selv, uten å komplisere det med hierarkiet av klassifikatorer. I litteraturen vurderes det i de fleste tilfeller i sammenheng med «fakta – sakte skiftende dimensjon». Faktisk kan denne oppgaven løses relativt enkelt ved å legge til startdatoen og utløpsdatoen for posten til dimensjonstabellen. Endring av en oppføring i katalogen fører til at den gamle oppføringen "lukkes" og en ny legges til. Når vi nå går tilbake til eksemplet med linjeelementreferansen, må brukeren som ønsker å få informasjon om gjeldende linjeelement for en bestemt dato inkludere den i SQL-spørringsbetingelsen.

Anta at en linjereferanse er knyttet til en regnskapskontoreferanse. En eller flere regnskapskonti representerer en kostnadspost. Hvordan skal en endring i en hvilken som helst attributt til en linje gjenspeiles i referanseboken for regnskapskontoer? På den ene siden, sett fra kontoplanens ståsted, endrer ikke endring av attributt linjepostens enhet, og regnskapspostene gjennom kontoplanen må referere til samme linjepost. På den annen side har det dukket opp en ny oppføring i artikkelkatalogen, som på en eller annen måte må være knyttet til kontokatalogen. Dette problemet kan løses ved å dele dimensjonstabellen i to - som inneholder oppdatert informasjon og inneholder historikken for enhetsendringer. Denne tilnærmingen lar deg også løse problemet med en hierarkisk dimensjon med behovet for å opprettholde historien om endringer i poster i den.

La oss vurdere det mer detaljert (se fig. 5). Tabellen "dimensjon_faktisk" er en dimensjonstabell med en primærnøkkel dimensjons-id som inneholder de riktige attributtene for dimensjonen i dag. Den historiske tabellen "dimension_history" er koblet til den gjennom den fremmede nøkkelen dimension_id, som inneholder historien til postendringer bestemt av start-/sluttdatoene for postens gyldighet (date_start, date_end-felter). Posten som er oppdatert er også til stede i den med en åpen utløpsdato. Faktatabellen er knyttet til dimensjonstabellen gjennom helper_table, som gjenspeiler den hierarkiske strukturen til dimensjonen.

Den beskrevne tilnærmingen tillater: for det første å lagre og arbeide med dimensjonen som med et ubalansert tre; for det andre, utfør raskt spørringer der historien til dimensjonsendringen ikke er viktig (tabellen som inneholder historien er ikke involvert); for det tredje lar den deg spore historien til endringer i dimensjonen, og til slutt skiller den refleksjonen av historie og hierarki, noe som i stor grad forenkler vedlikeholdet av dimensjonen.

Det tredje viktige punktet som en lagerutvikler ofte må forholde seg til er knyttet til aggregerte verdier. Denne klassen av oppgaver kan betinget deles inn i to underklasser. Den første vurderer oppgavene med å lage og vedlikeholde aggregater i henhold til tilgjengelige detaljerte data og er mye dekket i litteraturen. Den andre er relatert til det faktum at datakilder for lageret ikke gir detaljerte verdier, men allerede et visst sett med aggregerte data. Denne situasjonen er typisk når du oppretter datavarehus for forvaltningsselskaper og offentlige reguleringsorganer, som samler inn mange rapporteringsskjemaer.

Et ekstremt tilfelle av denne tilnærmingen er en modell som konvensjonelt kan kalles "indikator-verdi". Dens essens ligger i det faktum at det samles inn et stort sett med indikatorer som kjennetegner virksomhetens finansielle og økonomiske aktiviteter. Disse indikatorene kan enten være funksjonelt relaterte eller ikke, de kan reflektere de samme verdiene, men med en annen detaljgrad, etc. Når du prøver å representere slike data i form av en flerdimensjonal modell, støter utvikleren på betydelige problemer og følger veldig ofte veien for å lage ikke et datalager, men et skjemalager. En typisk lagring av skjemaer er bygget på grunnlag av tre dimensjoner - økonomiske indikatorer, tid, rapporteringsskjemaer; faktatabeller - verdiene til økonomiske indikatorer og hjelpetabeller som beskriver hvordan indikatorene og deres verdier er plassert i rapporteringsskjemaene. Ved analyse av slike data vil analytikeren oppleve betydelige vanskeligheter, hovedsakelig på grunn av at indikatorer av ulike former ikke kan sammenlignes med hverandre. Det eneste som gjenstår for ham er å spore endringer i indikatorene for en form over tid.

Konklusjon

Ved implementering av prosjekter for bygging av datavarehus oppstår det en rekke vanlige oppgaver som ikke avhenger av emneområdet for informasjonen som behandles. Disse oppgavene inkluderer:

Denne artikkelen diskuterte mulige løsninger på disse problemene. Spesielt ble metoder for å implementere hierarkiske dimensjoner gitt ved å introdusere tilleggsattributter (venstre og høyre grenser), samt ved å introdusere en ekstra tabell - "hjelper-tabell". Men i alle problemene som vurderes, er det uløste problemer som krever videre forskning. Spesielt er det vanskelig å implementere tilfellet med hierarkiske målinger med behovet for å opprettholde en historikk med endringer som har koblinger til noen andre kataloger. Denne artikkelen inkluderer ikke spørsmål knyttet til datarensingsmetoder og algoritmer for å laste data inn i lagringen. Disse temaene krever separat vurdering.

LITTERATUR

1.	Joerg Reinschmidt, Allison Francoise. Business Intelligence-sertifiseringsveiledning. IBM røde bøker;
2.	Inmon W. Bygger datavarehuset. - New York: John Willey & Sons, 1992;
3.	Spirley, Eric. Bedriftsdatavarehus. Planlegging, utvikling, gjennomføring. Volum. 1: Per. fra engelsk - M .: Publishing House "Williams", 2001;
4.	Joe Celko. Trær i SQL: Intelligent Enterprise, 20. oktober 2000;
5.	Donald E. Knuth. Kunsten å programmere, bind 1. Grunnleggende algoritmer, 3. utg.: - M.: Forlag "Williams", 2000 .;
6.	Ralph Kimball. Hjelp for hierarkier: DBMS september 1998;
7.	Ralph Kimball. Sakte skiftende dimensjoner: DBMS april 1996;
8.	Statistisk ordbok: M. "Finans og statistikk", 1989;
9.	Duke V, Samoilenko A, Data mining: a training course. - SPb: Peter, 2001;
10.	Erhard Rahm, Hong Hai Do: Datarensing: Problemer og nåværende tilnærminger. IEEE Data Engineering Bulletin 23 (4): 3-13 (2000);
11.	Ralph Kimball: Datavarehusverktøysettet: praktiske teknikker for å bygge dimensjonale datavarehus. John Wiley 1996;
12.	Maria Sueli Almeida, Missao Ishikawa, Joerg Reinschmidt, Torsten Roeber, Getting Started with Data Warehouse og Business Intelligence. IBM røde bøker;
13.	Nigel Pendse, OLAP Architectures: OLAP-rapporten, http://www.olapreport.com/Architectures.htm#top.