By Doble Engineering Company in Enterprise Asset Management / June 25, 2020
Jaa tämä…
Facebook
Pinterestissä
Facebookilla
Linkedin
datan ja analytiikan maailma kehittyy jatkuvasti. Yksinkertaisimmillaan tyypillinen tietoorganisaatio koostui joistakin tiedostoista, sovellus-tai tapahtumatietokannoista, tietovarastoista ja raportointitietokannoista. Koska tietolähteet, volyymit, tuotantonopeudet ja keruuprosessi ovat kasvaneet vuosien varrella, nykypäivän laskentaympäristössä on käsiteltävä erittäin suuria tietokokonaisuuksia – joita kutsutaan yleisesti ”big dataksi” – jotka paljastavat malleja, suuntauksia ja paljon muuta, joihin organisaatiot voivat perustaa päätöksensä.
useimmilla organisaatioilla on nykyään monia, ellei kaikkia, kaaviossa 1 esitetyssä viitearkkitehtuurissa korostettuja komponentteja – Sovellukset, järjestelmät ja lähteet, tiedonsiirto, yritystietokerros, tietopalvelut, analytiikka ja raportointi sekä kehittynyt tietojenkäsittely.
Kuva 1-Complex Reference Architecture
kun tietovarasto ja marts ovat edustettuina yhtenä 28 mahdollisesta komponentista, on ensi silmäyksellä vaikea ymmärtää, miten ne sopivat kuvaan. Mutta useimmat organisaatiot ovat tällä hetkellä huolissaan enemmän kuin tietovarasto – niiden on yhtenäisesti hallita monimutkainen ympäristö, kuten kuvassa 1.
Kimball-ja Inmon-arkkitehtuurit tarjoavat molemmat puitteet monimutkaisen viitearkkitehtuurin kehittämiseen.
nopea kertaus kahdesta lähestymisestä
ennen kuin sovelletaan Kimball-tai Inmon-kuvioita, kannattaa käydä läpi näiden kahden lähestymisen erot. Katso kuva 21 ja kuva 32 .
Kimballin ja inmonin – kyseisten mallien perustajien-työ haastoi toisensa. Vaikka molemmat lähestymistavat perustuvat pääasiassa tietomallin kehityssykliin, mallit perustuvat joko alhaalta ylöspäin tai ylhäältä alaspäin suuntautuvaan lähestymistapaan. Nämä jännitteet vaikuttivat yleisesti Tietojen tallennus-ja analytiikkaympäristöjen kehitykseen.
kuva 2-visuaalinen Kimball
View Figure 3-Visual Inmon View
Kimball-lähestymistapa osoittaa, että tietovarastoja ja datamarketteja ohjaavat liiketoimintaprosessit ja liiketoimintakysymykset. Ilmeinen vaara Tämä on hyödyllistä tietoa ei välttämättä luokitella tai kiinni, koska se ei sovi liiketoimintaprosessin määritellään.
inmonin lähestymistapa viittaa yrityksen tietovaraston luomiseen loogisilla malleilla, jotka on suunniteltu jokaiselle kokonaisuudelle aiheen ympärillä, kuten mittarille, laskulle ja omaisuudelle. Haasteena on, että vaikka tärkeimmät aiheet voivat edustaa eriytymistä, niitä tukevat kokonaisuudet voivat edustaa yhteneväisyyksiä, jotka voidaan menettää.
esimerkiksi palvelupaikan edustama mittarin sijainti, laskussa esitetty laskutusosoite ja hyödykkeen varaston sijainti tai käyttöönottopaikka voivat olla yhteisiä ominaisuuksia. Jopa inmonin alaisuudessa on vaara, että palvelun sijainti, laskutusosoite, varallisuus, varaston sijainti ja omaisuuden käyttöönottopaikka voidaan esittää viidenä eri objektina, koska niiden katsotaan tukevan organisaatiossa eri vertikaaleja erilaisilla datamarteilla.
sekä inmonin että Kimballin lähestymistapoja ohjaa sykli, joka kehittää käsitteellisen tietomallin ja toteuttaa sitten tietomallit fyysisessä muodossa. Tämä sykli voi tukea ketterämpiä kehittämistapoja, mutta se on läheisimmin linjassa vesiputoustyyppisen kehittämistavan kanssa johtuen tutkimuksen lineaarisuudesta (prosessin tai yritysaiheen perusteella), käsitteellisen mallin kehittämisestä (prosessin tai yritysaiheen perusteella) ja fyysisen mallin kehittämisestä.
seuraavan askeleen ottaminen
ketterä prosessi voi vaikeuttaa syklien pistämistä tämäntyyppiseen kehitystoimintaan. Jokaisen organisaation haasteena on ottaa oppia Inmonin ja Kimballin lähestymistavoista ja soveltaa niitä uudessa kontekstissa.
tarkempaa tietoa siitä, miten kuvioita voi soveltaa monimutkaiseen ympäristöön tämän blogisarjan toisessa osassa-pysy kuulolla!
sillä välin, tutustu tuoreeseen viestiimme enterprise information management (EIM) – ohjelman onnistuneesta toteuttamisesta.
