Ez a cikk az adattárházak architektúrájára összpontosít. Mire kell támaszkodni az építés során, milyen megközelítések működnek – és miért.

"A mese hazugság - de van benne utalás..."

Nagyapa ültetett ... tároló. A raktár pedig egyre nagyobbra nőtt. Csak nem igazán tudtam, hogyan működik. És nagyapa elkezdte a felülvizsgálatot. A nagypapa családi tanácsra hívta a nagymamát, unokáját, macskát és egeret. És a következő témát mondja: „Nőtt a tárhelyünk. Az összes rendszerből származó adatok gyülekeznek, a táblázatok láthatóak és láthatatlanok. A felhasználók elkészítik a jelentéseiket. Úgy tűnik, minden rendben van - élni és élni. Igen, csak egy szomorúság – senki sem tudja, hogyan működik. Látszólag-láthatatlanul lemezekre van szükség - nem fogsz eleget kapni! Aztán vannak olyan felhasználók, akik különböző panaszokkal fordulnak hozzám: vagy lefagy a jelentés, vagy elavultak az adatok. És ez néha elég katasztrófa - jelentésekkel érkezünk a cár-atyához, de a számok nem egyeznek egymással. Még nincs is az óra - haragszik meg a király -, akkor ne rombold le a fejed - sem nekem, sem neked. Ezért úgy döntöttem, hogy összegyűjtöm önöket, és tanácskozunk: mit fogunk csinálni?

Tekintetét a gyülekezetre vetette, és megkérdezte:
- Tessék, nagymama, tudod, hogy van elrendezve a raktárunk?
- Nem, nagyapa, nem tudom. És honnan kellene tudnom? Odaát, micsoda bátor legények őrzik őt! Néhány bajusz! Ne lépj fel. Elmentem hozzájuk valahogy, pitét sütöttem. És ettek néhány pitét, megtörölték a bajuszukat, és azt mondták: „Miért jöttél, nagymama? Mi a tárhelyed? Mondja el nekünk, hogy milyen jelentésre van szüksége – mi elkészítjük Ön helyett! A legfontosabb, hogy gyakrabban hozz pitét! Fájdalmasan finom ízük van.”
- És te, szeretett unokám, tudod, hogyan van elrendezve a raktárunk?
- Nem, nagyapa, nem tudom. Adott egy kis hozzáférést hozzá. Csatlakoztam, nézem - és vannak táblázatok - láthatóan láthatatlanok. És különböző sémák rejtve vannak. Kikerekednek a szemek.... Először össze voltam zavarodva. Aztán alaposan megnéztem – némelyik üres, mások tele vannak, de csak a fele. Ezenkívül az adatok ismétlődőnek tűnnek. Nem csoda, hogy ilyen redundanciával nem lehet lemezeket felhalmozni!
- Nos, te, macska, mit mondhatsz a tárolónkról? Van benne valami jó?
- Igen, hogy ne mondjam, nagyapa - mondom. Az unokám kérésére megpróbáltam pilótapilótát készíteni egy külön sémában - egy kis vitrinben. Ahhoz, hogy megértsük, milyen kereskedelem előnyös államunknak - milyen termékek jók a kereskedőknek, tisztelegnek -, feltöltődik a kincstár. És melyik a rossz. És elkezdtem adatokat gyűjteni ebből a tárolóból. Összegyűjtött tények. És elkezdte összehasonlítani őket a termékekkel. És mit láttam, nagyapa - a termékek ugyanazok, de nézzük a jeleket - különböznek! Aztán elkezdtem fésülni őket az unokám fésűjével. Karmolt, karmolta – és bizonyos egyformasághoz vezetett, simogatta a szemet. De korán megörültem – másnap elindítottam a szkriptjeimet, hogy frissítsem az ablakban lévő csodálatos adatokat –, és minden eltűnt számomra! "Hogy hogy?" - Azt hiszem, - háborodik fel a nagylány -, ma meg kellene mutatni a pilótánkat a miniszternek. Hogyan álljunk hozzá – ilyen adatokkal?
- Igen, szomorú mesék, macska, mondod. Nos, te, kisegér, tényleg nem próbáltál tájékozódni a trezorról? Élénk, fürge, társaságkedvelő lány vagy! Mit mondasz nekünk?
- Igen, hogyan, nagyapa, ne próbálkozz - persze, én csendes egér vagyok, de mozgékony. Valahogy a macska unokája kérte az állami tárhelyünk adatmodelljét, hogy megszerezze. És a macska természetesen hozzám jött - rajtad, mondja az egér, minden remény! Nos, milyen jó cselekedetet nem tudnak a jó emberek (és a macskák) megtenni? Elmentem a kastélyba, ahol az adattár vezetője egy széfben rejti el az adatmodellt. És elbújt. Vártam, hogy kivegye a modellt a széfből. Amint kiment kávézni – ugrottam az asztalra. Nézem a modellt - nem értek semmit! Hogy hogy? Nem ismerem fel a trezorunkat! Számtalan ezer táblánk, adatunk van - megunhatatlan folyamunk! És itt - minden harmonikus és gyönyörű... Ránézett erre a modellre - és visszatette a széfbe.
- Igen, nagyon furcsa dolgokat mondtál nekünk, egér.
Nagyapa erősen gondolkodott.
Mit tegyünk, barátaim? Végül is nem fog sokáig élni egy ilyen tárolóval ... A felhasználók hamarosan teljesen elveszítik a türelmüket.

Bárhogyan is dönt a mesebeli nagyapánk - új tárolót épít, vagy megpróbálja újraéleszteni a meglévőt -, le kell vonnunk a következtetéseket, mielőtt ismét „felgyűrjük az ingujjat”.
Tegyük félre a szervezési szempontokat - mint például a szakértelem valamely szűk zárt csoportba való összpontosításának veszélye, az ellenőrzési folyamatok hiánya, a vállalati rendszerek architektúrájának átláthatóságának biztosítása stb.
Ma egy adott rendszer (vagy rendszercsoport) – adattárházak – architektúrájának felépítésére szeretnék összpontosítani. Mit kell elsősorban fókuszban tartani, ha egy szervezet egy olyan bonyolult és költséges rendszert kezd építeni, mint a tárolás.

Kikérdezés

Egyikünk sem, aki bármilyen rendszer létrehozásán, fejlesztésén dolgozik, nem akarja, hogy ez „átmeneti ház” legyen, vagy egy-két éven belül „elsorvadó” megoldás, mert. nem lesz képes megfelelni az ügyfelek és a vállalkozások követelményeinek és elvárásainak. Bármilyen erős manapság az elmozdulás a „rugalmas módszertanok” felé, sokkal kellemesebb, ha az ember hegedűt készítő „mesternek” érzi magát, mint egy kézművesnek, aki botokat farag az eldobható dobokhoz.
Természetesnek hangzik a szándékunk: olyan szilárd és minőségi rendszereket készíteni, amelyek nem igényelnek majd rendszeres „fájllal éjszakai virrasztást”, amit nem fogunk szégyellni a végfelhasználók előtt, és amelyek nem úgy néznek ki. „fekete doboz” minden „beavatatlan” követőnek.

Először is soroljuk fel azokat a tipikus problémákat, amelyekkel rendszeresen találkozunk a tárolókkal való munka során. Csak írjuk le, amink van – eddig anélkül, hogy megpróbálnánk racionalizálni és formalizálni.

1. Elvileg jó tárolónk van: ha nem nyúlsz hozzá, akkor minden működik. Igaz, amint változtatásra van szükség, elkezdődnek a „helyi összeomlások”.
2. Az adatok feltöltése naponta, az előírásoknak megfelelően egy nagy folyamaton belül, 8 órán belül történik. És nekünk megfelel. De ha hirtelen meghibásodás következik be, ez manuális beavatkozást igényel. És akkor még sokáig minden beláthatatlanul működhet, mert. emberi részvétel szükséges a folyamatban.
3. Hengerelt kiadás - problémákra számíthat.
4. Valamelyik forrás nem tudta időben megadni az adatokat - minden folyamat vár.
5. Az adatok integritását az adatbázis ellenőrzi – így folyamataink összeomlanak, ha megszakad.
6. Nagyon nagy tárolónk van - 2000 asztal egyben általános séma. És még 3000 sok más rendszerben. Arról, hogy hogyan vannak elrendezve, és mi okból jelentek meg, már alig van fogalmunk. Ezért nehéz lehet valamit újrafelhasználnunk. És sok problémát újra meg kell oldani. Mert könnyebb és gyorsabb (mint a "valaki más kódjában" megérteni). Ennek eredményeként eltérések és duplikált funkciók vannak.
7. A forrástól elvárjuk, hogy minőségi adatokat szolgáltasson. De kiderül, hogy ez nem így van. Ennek eredményeként sok időt töltünk zárójelentéseink egyeztetésével. És ebben nagyon sikeresek voltak. Még egy egyszerűsített folyamatunk is van. Igaz, ehhez idő kell. De a felhasználók hozzászoktak...
8. A felhasználó nem mindig bízik a jelentéseinkben, és megköveteli egy adott szám indoklását. Egyes esetekben igaza van, másokban pedig téved. De ezeket nagyon nehezen tudjuk alátámasztani, mert nem biztosítunk eszközt a "végponttól végpontig" történő elemzéshez (vagy adatsorhoz).
9. További fejlesztőket is bevonhatunk. De van egy problémánk – hogyan alakítsuk át őket munkává? Mi a leghatékonyabb módja a munka párhuzamosításának?
10. Hogyan lehet fokozatosan fejleszteni a rendszert anélkül, hogy belemennénk a „rendszer magjának” egy egész éven át tartó fejlesztésébe?
11. Az adattárház a vállalati modellhez van társítva. Azt viszont biztosan tudjuk (az XYZ bankban láttuk), hogy a végtelenségig lehet modellt építeni (az XYZ bankban hat hónapig jártunk körbe és tárgyaltunk a gazdasági társaságokról, minden mozgás nélkül). Miért van egyáltalán? Vagy talán jobb nélküle, ha annyi probléma van vele? Esetleg generálni valahogy?
12. Úgy döntöttünk, hogy vezetjük a modellt. De hogyan lehet szisztematikusan fejleszteni a raktári adatmodellt? Kellenek-e „játékszabályok”, és mik lehetnek azok? Mit fog ez adni nekünk? Mi van, ha hibázunk a modellel?
13. Mentsük el az adatokat, vagy azok változástörténetét, ha „a vállalkozásnak nincs rájuk szüksége”? Nem szeretnék "szemetet raktározni" és megbonyolítani ezeknek az adatoknak a valós feladatokhoz való felhasználását. A trezornak meg kell őriznie a történelmet? Milyen érzés? Hogyan működik a tárolás az idő múlásával?
14. Meg kell-e próbálni egységesíteni a tárolóban lévő adatokat, ha van NSI kezelő rendszerünk? Ha van MDM, ez azt jelenti, hogy most az egész törzsadat probléma megoldódott?
15. Várhatóan hamarosan lecseréljük a kulcsfontosságú számviteli rendszereket. Az adattárnak készen kell állnia a forrásváltásra? Hogyan lehet ezt elérni?
16. Szükségünk van metaadatokra? Mit értsünk ezen? Pontosan hol lehet őket használni? Hogyan valósítható meg? "Egy helyen" kell őket tartani?
17. Ügyfeleink rendkívül instabilak az igényeiket és vágyaikat illetően – valami folyamatosan változik. Általánosságban elmondható, hogy vállalkozásunk nagyon dinamikus. Amíg csinálunk valamit, az már feleslegessé válik. Hogyan biztosíthatjuk, hogy a lehető leggyorsabban hozzunk eredményt – például forró süteményt?
18. A felhasználók gyorsaságot követelnek. De a fő rendszerindítási folyamatainkat nem tudjuk gyakran futtatni, mert ez betölti a forrásrendszereket (rossz hatással van a teljesítményre) - ezért további adatfolyamokat akasztunk le - ami pontonként viszi -, amire szükségünk van. Igaz, kiderül, sok folyik. És akkor kidobunk néhány adatot. Ezen túlmenően a konvergencia problémája lesz. De nincs más út...

Elég sok minden történt már. De ez nem teljes lista– könnyen kiegészíthető, fejleszthető. Nem a táblázatba rejtjük el, hanem jól látható helyre akasztjuk fel – a munka során ezeket a kérdéseket figyelmünk középpontjában tartva.
Feladatunk egy átfogó megoldás kidolgozása ennek eredményeként.

törékenység elleni

A listánkat tekintve egy következtetés vonható le. Nem nehéz létrehozni valamiféle „adatbázist a jelentéshez”, adatokat dobni oda, vagy akár valamilyen rutin adatfrissítési folyamatokat felépíteni. A rendszer valahogy élni kezd, megjelennek a felhasználók, és velük együtt kötelezettségek és SLA-k, új követelmények, további források kapcsolódnak, módosulnak a módszertanok – mindezt figyelembe kell venni a fejlesztési folyamatban.

Egy idő után a kép a következő:
"Itt a páncélszekrény. És működik, ha nem nyúlsz hozzá. Problémák akkor merülnek fel, ha valamit változtatnunk kell.”

Változás érkezik hozzánk, aminek a hatását képtelenek vagyunk felmérni és felfogni (mivel eleinte ilyen eszközöket nem tettünk a rendszerbe) - és hogy ne kockáztassunk, nem nyúlunk ahhoz, ami van, hanem teszünk még egy kiterjesztést. oldalán, és még egy, és még több - döntésünket nyomornegyedekké, vagy ahogy Latin-Amerikában mondják "favelákká" változtatva, ahová még a rendőrök is félnek bemenni.
Érezhető a saját rendszer feletti kontroll elvesztése, káosz. Egyre több kézre van szükség a meglévő folyamatok karbantartásához és a problémák megoldásához. És egyre nehezebb változtatni. Más szóval, a rendszer instabillá válik a feszültségekkel szemben, nem alkalmazkodik a változásokhoz. Ráadásul erős a függés azoktól a karakterektől, akik "ismerik a hajóutat", hiszen senkinek nincs "kártyája".

Az objektumnak ez a tulajdonsága, hogy összeomlik a káosz, véletlenszerű események és felfordulások hatására - hívja Nassim Nicholas Taleb törékenység . Bevezeti az ellenkező fogalmat is: törékenység elleni – amikor a tárgyat nem a stressz és a balesetek tönkreteszik, hanem közvetlen hasznot húznak belőle. ("Antifragility. Hogyan profitáljunk a káoszból")
Különben hívható alkalmazkodóképesség vagy ellenáll a változásnak .

Mit jelent ez ebben az összefüggésben? Mik a "káosz forrásai" az informatikai rendszerek számára? És mit jelent az IT-architektúra szempontjából "tőkésítés a káoszból"?
Az első gondolat, ami eszünkbe jut, a kívülről jövő változások. Mi a külvilág a rendszer számára? Főleg tárolásra. Természetesen mindenekelőtt - változások a tárhely adatforrásaiból:

• a bejövő adatok formátumának megváltoztatása;
• egyes adatforrás-rendszerek cseréje másokkal;
• szabályok/platformok megváltoztatása a rendszerintegrációhoz;
• az adatok értelmezésének megváltoztatása (a formátumok mentésre kerülnek, az adatokkal való munka logikája megváltozik);
• az adatmodell megváltoztatása, ha az integráció adatszinten történik (az adatbázis tranzakciós naplófájljainak elemzése);
• adatmennyiségek növekedése - miközben kevés adat volt a forrásrendszerben, és a terhelés is kicsi volt - bármikor átvehette, tetszőlegesen nagy kéréssel, nőtt az adatok és a terhelés - most szigorú korlátozások vannak érvényben;
• stb.

Maguk a forrásrendszerek, az információ összetétele és szerkezete, az integrációs interakció típusa, valamint az adatokkal való munka logikája változhat. Minden rendszer saját adatmodellt valósít meg és a velük való munkavégzés olyan megközelítéseit, amelyek megfelelnek a rendszer céljainak és célkitűzéseinek. És bármennyire is igyekeznek egységesíteni az iparági modelleket és referenciagyakorlatokat, árnyalatok mindenképpen előkerülnek. (Emellett maga az iparegyesítés folyamata különböző okokból nemigen halad előre.)
A vállalati adatokkal való munkavégzés kultúrája - az információs architektúra jelenléte és ellenőrzése, egyetlen szemantikai modell, törzsadat-kezelő rendszerek (MDM) némileg megkönnyítik az adatok konszolidációját a raktárban, de nem zárják ki annak szükségességét.

Nem kevésbé kritikus változtatásokat kezdeményeznek a tárolófogyasztók (követelményváltozások):

• korábban elegendő adat volt a jelentés elkészítéséhez - most további mezőket vagy új adatforrást kellett csatlakoztatni;
• a korábban megvalósított adatfeldolgozási módszerek elavultak - az algoritmusokat és mindent, amit érint, át kell dolgozni;
• Korábban mindenki elégedett volt a szótárattribútum aktuális értékével az információs panelen - most az az érték szükséges, amely az elemzett tény/esemény bekövetkezésekor releváns;
• előírás volt az adattárolás történetének mélységére, ami korábban nem volt - nem 2 évig, hanem 10 évig tárolni az adatokat;
• Korábban elég volt a „napvégi/időszaki” állapotú adatok birtokában lenni – most „napon belüli”, vagy egy adott esemény időpontjában (pl. hiteligénylési döntés meghozatalakor) kell az adatok állapota. Basel II);
• korábban megelégedtünk a tegnapi (T-1) vagy későbbi adatok jelentésével, most T0 kell;
• stb.

Mind a forrásrendszerekkel való integrációs interakciók, mind a raktári adatfogyasztók követelményei külső tényezők az adattárház számára: az egyik forrásrendszer felváltja a másikat, nő az adatmennyiség, megváltoznak a bejövő adatformátumok, változnak a felhasználói követelmények stb. És ezek mind tipikus külső változások, amelyekre rendszerünknek – adattárunknak – készen kell állnia. Megfelelő architektúrával nem szabad megölniük a rendszert.

De ez még nem minden.
A változékonyságról szólva mindenekelőtt a külső tényezőkre emlékeztetünk. Hiszen belül mindent irányíthatunk, úgy tűnik nekünk, igaz? Igen és nem. Igen, a hatászónán kívül eső tényezők többsége külső. De létezik „belső entrópia” is. És éppen jelenléte miatt kell néha visszatérnünk „a 0-s ponthoz”. Kezdje elölről a játékot.
Az életben gyakran hajlamosak vagyunk a nulláról kezdeni. Miért szoktuk ezt csinálni? És ez olyan rossz?
IT-re alkalmazva. Magának a rendszernek – ez nagyon jó lehet – az egyéni döntések átgondolásának képessége. Főleg, ha helyben tudjuk csinálni. Az újrafaktorálás a rendszerfejlesztés során időszakosan felmerülő "háló" feloldásának folyamata. Hasznos lehet visszatérni a „kezdethez”. De ennek ára van.
Megfelelő architektúrakezeléssel ez az ár csökken – és maga a rendszerfejlesztés folyamata is ellenőrizhetőbbé és átláthatóbbá válik. Egy egyszerű példa: ha betartjuk a modularitás elvét, átírhatunk egy külön modult anélkül, hogy ez befolyásolná külső interfészek. Ezt pedig monolit szerkezettel nem lehet megtenni.

A rendszer törékenységét a felépítése határozza meg. És ez a tulajdonság teszi alkalmazkodóvá.
Amikor arról beszélünk adaptív architektúra- ez alatt azt értjük, hogy a rendszer képes alkalmazkodni a változásokhoz, és egyáltalán nem arra, hogy magát az architektúrát folyamatosan változtatjuk. Ellenkezőleg, minél stabilabb és stabilabb az architektúra, minél kevesebb a felülvizsgálatát igénylő követelmény, annál adaptívabb a rendszer.

A teljes architektúra felülvizsgálatát igénylő megoldások ára sokkal magasabb lesz. És az elfogadásukhoz nagyon jó okok kell hogy legyenek. Ilyen ok lehet például olyan követelmény, amely a jelenlegi architektúrán belül nem valósítható meg. Aztán azt mondják – volt egy követelmény, ami az építészetet érinti.
Így tudnunk kell a „törékenység elleni határainkat is”. Az építészetet nem „vákuumban” fejlesztik – az aktuális követelményeken és elvárásokon alapul. Ha pedig a helyzet alapvetően megváltozik - meg kell értenünk, hogy túlléptünk a jelenlegi architektúrán -, és azt felül kell vizsgálnunk, más megoldást kell kidolgoznunk - és át kell gondolnunk az átállási utakat.
Például azt feltételeztük, hogy a nap végén mindig szükségünk lesz adatokra a raktárban, naponta gyűjtünk adatokat szabványos rendszerfelületeken (nézetkészleten keresztül). Aztán a kockázatkezelési osztálytól olyan kérések érkeztek, hogy nem a nap végén, hanem a hitelezési döntés meghozatalakor kell adatokat kapni. Nem kell megpróbálni "nyújtani a feszítetlent" - csak fel kell ismerni ezt a tényt - minél előbb, annál jobb. És kezdjünk el egy olyan megközelítésen dolgozni, amely lehetővé teszi számunkra a probléma megoldását.
Van itt egy nagyon finom vonal - ha csak a "pillanatbeli követelményeket" vesszük figyelembe, és nem tekintünk néhány lépéssel (és több évre) előre, akkor növeljük annak a kockázatát, hogy túl későn találkozunk az építészetet érintő követelményekkel - és a cserénk költsége nagyon magas lesz. Ha egy kicsit előre tekintünk – a látóhatárunk határain belül – soha senkinek nem ártott.

A „tároló tündérmese” rendszer példája csak egy példa egy nagyon ingatag rendszerre, amely törékeny tervezési megközelítésekre épül. És ha ez megtörténik, a pusztulás meglehetősen gyorsan megtörténik a rendszer ezen osztályában.
Miért mondhatom ezt? A tárolás témája nem új keletű. Az ez idő alatt kialakult megközelítések és mérnöki gyakorlatok pontosan ezt - a rendszer életképességének megőrzését - célozták.
Egy egyszerű példával élve, az egyik leggyakoribb ok, amiért a felszállótárolási projektek kudarcot vallanak, az, hogy a fejlesztés alatt álló forrásrendszerekre próbálnak tárhelyet építeni anélkül, hogy az integrációs interfészek illeszkednének – az adatok közvetlenül a táblákból való lehívására. Ennek eredményeként fejlesztésbe kezdtek - ez idő alatt változott a forrásadatbázis - és a tárolóban lévő letöltési folyamok működésképtelenné váltak. Már túl késő valamit újra csinálni. És ha nem biztosította magát azzal, hogy több réteg asztalt készít a tárolóban, akkor mindent eldobhat, és kezdheti elölről. Ez csak egy példa, és az egyik legegyszerűbb.

Taleb kritériuma a törékeny és a törékenységmentesség tekintetében egyszerű. A főbíró az idő. Ha a rendszer kiállja az idő próbáját, és megmutatja "túlélhetőségét" és "elpusztíthatatlanságát" - akkor megvan a törékenység elleni tulajdonsága.
Ha egy rendszer tervezésekor követelményként vesszük figyelembe a törékenységmentességet, akkor ez arra ösztönöz bennünket, hogy olyan megközelítéseket alkalmazzunk az architektúra felépítésében, amelyek alkalmazkodóbbá teszik a rendszert mind a „külső káoszhoz”, mind a „belülről jövő káoszhoz”. ”. És végül a rendszer élettartama hosszabb lesz.
Egyikünk sem akar "ideiglenes" lenni. És ne áltasd magad azzal, hogy most nincs más út. Néhány lépéssel előre tekinteni az ember számára mindenkor normális, különösen válság idején.

Mi az adattárház és miért építjük

A tárolási architektúra cikk azt feltételezi, hogy az olvasó nem csak tudja, mi az, hanem van némi tapasztalata is az ilyen rendszerekkel kapcsolatban. Ennek ellenére szükségesnek tartottam ezt - visszatérni az eredethez, az út kezdetéhez, mert. ott található a fejlődés „támaszpontja”.

Hogyan jutottak az emberek arra a következtetésre, hogy szükség van adattárházakra? És miben különböznek a "nagyon nagy adatbázistól"?
Réges-régen, amikor egyszerűen csak „üzleti adatfeldolgozó rendszerek” léteztek a világon, az informatikai rendszereket nem osztották fel olyan osztályokra, mint front-end oltp rendszerek, back-office dss, szöveges adatfeldolgozó rendszerek, adattárházak stb. .
Ekkor hozta létre az első relációs DBMS Ingrest Michael Stonebreaker.
És ez volt az az idő, amikor a személyi számítógépek korszaka forgószélként robbant be a számítástechnikai iparba, és örökre felforgatta az akkori informatikai közösség minden elképzelését.

Ezután könnyű volt megtalálni az asztali szintű DBMS-re írt vállalati alkalmazásokat - mint például a Clipper, a dBase és a FoxPro. A kliens-szerver alkalmazások és a DBMS piaca pedig csak lendületet kapott. Egymás után jelentek meg az adatbázis-kiszolgálók, amelyek hosszú ideig elfoglalják a rést az IT-térben - Oracle, DB2 stb.
És elterjedt az "adatbázis-alkalmazás" kifejezés. Mit tartalmazott egy ilyen pályázat? Leegyszerűsítve – bizonyos beviteli űrlapok, amelyeken a felhasználók egyszerre adhatnak meg információkat, bizonyos számítások, amelyeket „gombra” vagy „ütemezés szerint” indítottak el, valamint néhány jelentés, amely a képernyőn látható, vagy fájlként menthető és pecsételésre elküldhető. .
"Semmi különös - rendszeres alkalmazása, csak van adatbázis” – jegyezte meg az egyik korai mentorom. – Semmi különös? - gondoltam akkor.

Ha alaposan megnézi, akkor még mindig vannak funkciók. A felhasználók növekedésével a beérkező információk mennyisége növekszik, a rendszer terhelésének növekedésével a fejlesztők-tervezők a teljesítmény elfogadható szinten tartása érdekében néhány "trükkhöz" nyúlnak. A legelső egy monolitikus „üzleti adatfeldolgozó rendszer” felosztása a felhasználók munkáját on-line módban támogató számviteli alkalmazásra, valamint egy külön alkalmazásra a kötegelt adatfeldolgozásra és jelentéskészítésre. Ezeknek az alkalmazásoknak mindegyike saját adatbázissal rendelkezik, és az adatbázis-kiszolgáló egy külön példányán található, különböző beállításokkal a különböző típusú munkaterhelésekhez – OLTP és DSS. És adatfolyamok épülnek közéjük.

Ez minden? Úgy tűnik, hogy a probléma megoldódott. Mi történik ezután?
Aztán a cégek nőnek, információigényük megsokszorozódik. A külvilággal való interakciók száma is nő. Ennek eredményeként nem egy nagy alkalmazás létezik, amely teljesen automatizálja az összes folyamatot, hanem több különböző, különböző gyártóktól. Egyre növekszik az információt generáló rendszerek - adatforrás rendszerek száma a vállalatnál. És előbb-utóbb szükség lesz a különböző rendszerektől kapott információk megtekintésére és összehasonlítására. Így jelenik meg a cégben a Data Warehousing, a rendszerek új osztálya.
Közös meghatározás ez az osztály rendszerek így hangzanak.

Adattárház (vagy adattárház)- egy tartományspecifikus információs adatbázis, amelyet kifejezetten jelentések és üzleti elemzések készítésére terveztek és szánnak a szervezeti döntéshozatal támogatására

Ily módon konszolidáció különböző rendszerekből származó adatok, az adattárolási osztályú rendszerek egyik kulcsfontosságú tulajdonsága, hogy azokat egy bizonyos „egyszeri” (egységes) módon lehet tekinteni. Ez az oka annak, hogy a tárolás az informatikai rendszerek fejlődése során jött létre.

Az adattárházak legfontosabb jellemzői

Nézzük meg részletesebben. Milyen Főbb jellemzők vannak ezek a rendszerek? Miben különböznek az adattárházak a többi vállalati informatikai rendszertől?

Először is, ezek nagy mennyiségek. Nagyon nagy. VLDB - így nevezik a vezető gyártók az ilyen rendszereket, amikor javaslataikat adják termékeik felhasználására. A cég összes rendszeréből az adatok ebbe a nagy adatbázisba áramlanak, és ott tárolódnak "örökké és változatlanul", ahogy a tankönyvekben mondják (a gyakorlatban az élet bonyolultabbnak bizonyul).

Másodszor, történelmi adatokról van szó "Céges memória" - úgynevezett adattárházak. A tárolási idővel való munka szempontjából minden nagyon érdekes. A számviteli rendszerekben az adatok jelen pillanatban relevánsak. Ezután a felhasználó végrehajt valamilyen műveletet - és az adatok frissülnek. Ugyanakkor előfordulhat, hogy a változások történetét nem lehet megőrizni - ez a számviteli gyakorlattól függ. Vegyünk például egy bankszámla egyenleget. Érdekelhet minket az aktuális egyenleg a "most", a nap végén vagy valamilyen esemény időpontjában (például a pontszám kiszámításakor). Ha az első kettőt egyszerűen megoldják, akkor az utóbbi valószínűleg különleges erőfeszítéseket igényel. A felhasználó az adattárral dolgozva hivatkozhat az elmúlt időszakokra, összehasonlíthatja azokat a jelenlegivel stb. Ezek az időhöz kapcsolódó képességek azok, amelyek a múltban egy bizonyos mélységig jelentősen megkülönböztetik az adattárházakat a számviteli rendszerektől - az időtengely különböző pontjain leolvasva az adatok állapotát.

Harmadszor, ezt konszolidáció és adategyesítés . Ahhoz, hogy közös elemzésük lehetővé váljon, közös formába kell hozni őket - egységes adatmodell , hasonlítsa össze a tényeket egységes kézikönyvekkel. Itt több szempont és nehézség is adódhat. Elsősorban - fogalmi – ugyanazon kifejezés alatt a különböző részlegekről származó különböző emberek különböző dolgokat érthetnek meg. És fordítva – másképp nevezni valamit, ami lényegében ugyanaz. Hogyan biztosítható az "egyetlen nézet", és egyben megőrizheti egy adott felhasználói csoport jövőképének sajátosságait?

Negyedszer, ez a munka adat minőség . Az adatok tárolóba való betöltése során megtisztítják azokat, általános átalakításokat, átalakításokat hajtanak végre. Az általános átalakításokat egy helyen kell elvégezni – majd felhasználni a különféle riportok összeállításához. Ezzel elkerülhetőek azok az eltérések, amelyek az üzleti felhasználókat – különösen a menedzsmentet – okozzák, akiket a különböző részlegek egymással nem egyező számai hoznak az asztalhoz. A rossz adatminőség hibákat és eltéréseket okoz a jelentésekben, aminek a következménye a szint csökkenése felhasználói bizalom az egész rendszerre, a teljes analitikai szolgáltatás egészére.

építészeti koncepció

Mindenki, aki találkozott a tárolóval, valószínűleg valamiféle "réteges szerkezetet" észlelt - mert. ez az építészeti paradigma honosodott meg az ebbe az osztályba tartozó rendszerekben. És nem véletlenül. A tárolórétegek a rendszer különálló elemeiként is felfoghatók - saját feladataikkal, felelősségi körükkel, "játékszabályaikkal".
A réteges architektúra egy eszköz a rendszer összetettségének kezelésére - minden következő réteg elvonatkoztatott az előző belső megvalósításának bonyolultságától. Ez a megközelítés lehetővé teszi az azonos típusú feladatok azonosítását és egységes megoldását anélkül, hogy a „kerékpárt” minden alkalommal újra fel kellene találni.
Egy sematikus elvi építészeti diagram látható az ábrán. Ez egy leegyszerűsített diagram, amely csak a kulcsötletet – a koncepciót – tükrözi, de az „anatómiai részletek” nélkül, amelyek a részletek mélyebb tanulmányozása során merülnek fel.

A diagramon látható módon válassza ki a következő rétegeket. Három fő réteg, amely tartalmazza az adattároló területet (ezt egy kitöltött téglalap jelzi) és az adatbetöltő szoftvert (feltételesen azonos színű nyilak jelzik). Valamint egy kisegítő - szolgáltatási réteg, amely azonban nagyon fontos összekötő szerepet tölt be - adatbetöltés és minőségellenőrzés irányítása.

Elsődleges adatréteg – elsődleges adatréteg (vagy színrevitel , vagy működési réteg ) - úgy tervezték, hogy a forrásrendszerekből töltsék be és mentsék el az elsődleges információkat, átalakítások nélkül - -ba eredeti minőségés támogatja a változások teljes történetét.
Ennek a rétegnek a feladata– az adatforrások fizikai eszközétől a későbbi tárolási rétegek elvonatkoztatása, az adatgyűjtés módszerei és a változások delta kinyerésének módszerei.

Core Data Layer – tárolómag - a rendszer központi eleme, amely megkülönbözteti a tárolót egy „batch integrációs platformtól”, vagy egy „nagy adatkiírattól”, mivel fő szerepe az adatkonszolidáció különböző forrásokból, redukció egységes szerkezetekre, kulcsokra. A kernelbe való betöltéskor történik az adatminőséggel és az általános átalakításokkal kapcsolatos fő munka, amely meglehetősen bonyolult lehet.
Ennek a rétegnek a feladata- elvonatkoztatni fogyasztóikat az adatforrások logikai szerkezetének sajátosságaitól és a különböző rendszerek adatainak összehasonlításának szükségességétől, biztosítani az adatok integritását és minőségét.

Data Mart Layer – elemző bemutatók - olyan komponens, amelynek fő funkciója az adatok elemzésre alkalmas struktúrákká alakítása (ha a BI kirakatokkal működik, akkor ez általában egy dimenziós modell), vagy a fogyasztói rendszer követelményei szerint.
Az adatpiacok rendszerint a magból veszik az adatokat - megbízható és ellenőrzött forrásként -, pl. használja ennek az összetevőnek a szolgáltatását az adatok egyetlen űrlapra hozásához. Az ilyen ablakokat hívjuk szabályos . Egyes esetekben a kirakatok közvetlenül az állomásozásból vehetnek át adatokat – az elsődleges adatokkal (forráskulcsokban) operálva. Ezt a megközelítést általában olyan helyi feladatoknál alkalmazzák, ahol nincs szükség a különböző rendszerekből származó adatok konszolidációjára, és ahol a hatékonyságra nagyobb szükség van, mint az adatminőségre. Az ilyen kijelzőket ún üzemeltetési . Egyes analitikai mutatóknak nagyon összetett számítási módszerei lehetnek. Ezért az ilyen nem triviális számításokhoz és transzformációkhoz ún másodlagos vitrinek .
Kirakatréteg feladat– adatok készítése egy adott fogyasztó – egy BI platform, egy felhasználói csoport vagy egy külső rendszer – igényei szerint.

A fent leírt rétegek egy állandó adattárolási területből, valamint egy adatok betöltésére és átalakítására szolgáló szoftvermodulból állnak. Ez a rétegekre és régiókra való felosztás logikus. Ezeknek az összetevőknek a fizikai megvalósítása eltérő lehet - akár különböző platformokon is tárolhat vagy átalakíthat adatokat különböző rétegeken, ha ez hatékonyabb.
A tárolóterületek technikai (puffertáblákat) tartalmaznak, amelyeket az adatátalakítási folyamat során használnak, ill céltáblák, amelyekhez a fogyasztói összetevő fér hozzá. Jó gyakorlat a céltáblázatok nézetekkel való „lefedése”. Ez megkönnyíti a rendszer későbbi karbantartását és fejlesztését. Mindhárom réteg céltáblázatában található adatok speciális technikai mezőkkel (metaattribútumokkal) vannak megjelölve, amelyek az adatbetöltési folyamatok biztosítását, valamint a tárolóban zajló adatfolyamok információs auditálását szolgálják.

Megkülönböztetünk egy speciális komponenst (vagy komponenskészletet), amely minden réteg számára szolgáltatási funkciókat biztosít. Ennek egyik kulcsfontosságú feladata - a vezérlési funkció -, hogy "egyetlen játékszabályt" biztosítson a teljes rendszer egészére vonatkozóan, meghagyva a jogot, hogy a fent leírt egyes rétegek megvalósításához különböző lehetőségeket alkalmazzanak - beleértve. használat különböző technológiák adatok betöltése és feldolgozása, különböző tárolási platformok stb. Hívjuk fel szolgáltatási réteg (szolgáltatási réteg) . Nem tartalmaz üzleti adatokat, de saját tárolási struktúrái vannak - tartalmaz egy metaadat-területet, valamint egy területet az adatminőséggel való munkavégzéshez (és esetleg más struktúrákat is, a hozzá rendelt funkcióktól függően).

A rendszer ilyen egyértelmű felosztása különálló komponensekre jelentősen növeli a rendszerfejlesztés irányíthatóságát:

• csökken az adott komponens funkcionalitásának fejlesztőjére háruló feladat összetettsége (nem kell egyszerre megoldani a külső rendszerekkel való integrációs problémákat, és átgondolni az adattisztítási eljárásokat, és az adatok optimális megjelenítését fogyasztók) - a feladat könnyebben bontható, értékelhető és kis szállítást végezhet;
• különféle előadókat (sőt csapatokat vagy vállalkozókat) vonhat be a munkába – mert ez a megközelítés lehetővé teszi a feladatok hatékony párhuzamosítását, csökkentve azok egymásra gyakorolt ​​hatását;
• a perzisztens állomásozás megléte lehetővé teszi az adatforrások gyors összekapcsolását anélkül, hogy a teljes magot vagy vitrineket megterveznénk a teljes témakörre, majd fokozatosan építhetjük fel a többi réteget a prioritásoknak megfelelően (sőt, az adatok már a tárolóban lesznek – elérhető rendszerelemzőknek, ami nagyban megkönnyíti az adattár későbbi fejlesztésének feladatait);
• a mag jelenléte lehetővé teszi, hogy minden adatminőséggel kapcsolatos munkát (valamint az esetleges hiányosságokat és hibákat) elrejtse a kirakatok és a végfelhasználó elől, és ami a legfontosabb, ha ezt az összetevőt egyetlen adatforrásként használja a kirakatokhoz, elkerülheti a problémákat. adatkonvergenciával a közös algoritmusok egy helyen való megvalósítása miatt;
• a kirakatok kiemelése lehetővé teszi, hogy figyelembe vegye a különböző részlegek felhasználóinak adatainak megértésének különbségeit és sajátosságait, a BI-követelményekhez való tervezésük pedig nem csak összesített adatok kiadását teszi lehetővé, hanem az adatok megbízhatóságának biztosítását is lehetővé teszi a részletezésre. elsődleges mutatókra;
• a szolgáltatási réteg jelenléte lehetővé teszi a végpontok közötti adatelemzés (adatvonal) elvégzését, az egységes adataudit-eszközök használatát, a változások delta kiemelésének közös megközelítéseit, az adatminőséggel, terheléskezeléssel, hibafigyelő és diagnosztikai eszközökkel való munkát. , és felgyorsítja a problémamegoldást.

A bomlásnak ez a megközelítése egyben ellenállóbbá teszi a rendszert a változásokkal szemben (a "monolit szerkezethez" képest) - biztosítja annak törékenységét:

• a forrásrendszerekből származó változtatások az állomásoztatásra kerülnek kidolgozásra - a kernelben csak azok a szálak módosulnak, amelyeket ezek a staging táblák érintenek, a kirakatokra gyakorolt ​​hatás minimális vagy hiányzik;
• A vásárlói igények változásait többnyire a kirakatokban dolgozzák fel (kivéve, ha olyan további információkra van szükség, amelyek még nincsenek a raktárban).

Ezután végigmegyünk a fenti összetevők mindegyikén, és egy kicsit részletesebben megvizsgáljuk őket.

Rendszermag

Kezdjük "középről" - a rendszer magjából vagy a középső rétegből. Nincs Core Layer címkével. A mag az adatkonszolidáció szerepét tölti be - egyetlen struktúrákra, könyvtárakra, kulcsokra redukálás. Itt történik az adatminőséggel kapcsolatos fő munka - tisztítás, átalakítás, egységesítés.

Ennek az összetevőnek a jelenléte lehetővé teszi a forrásrendszerekből kapott elsődleges adatokat egyetlen formátumba átalakító adatfolyamok újrafelhasználását, közös szabályokat és algoritmusokat követve, ahelyett, hogy ugyanazt a funkcionalitást külön-külön megismételné minden egyes alkalmazás kirakatához, amely amellett, hogy az erőforrások nem hatékony felhasználása az adatokban is eltéréseket okozhat.
A tárolómag adatmodellben valósul meg, amely általában különbözik mind a forrásrendszerek modelljétől, mind a fogyasztók formátumaitól és struktúráitól.

Tárolómotor-modell és vállalati adatmodell

A középső tárolóréteg fő feladata a stabilitás. Éppen ezért itt a fő hangsúly az adatmodellen van. Általában "vállalati adatmodellnek" nevezik. Sajnos mítoszok és abszurditások bizonyos glóriája alakult ki körülötte, amelyek időnként az építkezés teljes feladásához vezetnek, de hiába.

1. mítosz. A vállalati adatmodell egy hatalmas modell, amely több ezer entitásból (táblázatból) áll.
Valójában. Bármely témakörben, bármely üzleti területen, bármely cég adataiban, még a legösszetettebbeknél is, kevés az alapvető entitás - 20-30.

2. mítosz. Nincs szükség "saját modell" fejlesztésére - veszünk egy iparági referenciamodellt - és mindent aszerint csinálunk. Pénzt költünk – de garantált eredményt kapunk.
Valójában. A referenciamodellek valóban nagyon hasznosak lehetnek, mert. iparági tapasztalattal rendelkezik ezen a területen. Ezekből lehet ötleteket, megközelítéseket, névadási gyakorlatokat meríteni. Ellenőrizze a terület "lefedettségének mélységét", hogy ne hagyjon ki valami fontosat. De nem valószínű, hogy egy ilyen modellt "dobozból" fogunk tudni használni - úgy, ahogy van. Ez ugyanaz a mítosz, mint például egy ERP-rendszer (vagy CRM) vásárlása és bevezetése anélkül, hogy „csavarna magára”. Az ilyen modellek értéke az adott üzletág, az adott cég realitásához való alkalmazkodásban születik meg.

3. mítosz. A tárolómag-modell kidolgozása több hónapig is eltarthat, ezalatt a projekt ténylegesen lefagy. Ráadásul őrült mennyiségű találkozót és sok ember részvételét igényli.
Valójában. A repository modell iteratív módon, darabonként fejleszthető a tárolóval együtt. A fedetlen területekre "kiterjesztési pontokat" vagy "csonkokat" helyeznek el - pl. néhány "univerzális konstrukciót" alkalmaznak. Ugyanakkor ismerni kell a mértéket, hogy ne kapjunk egy szuperuniverzális 4 táblás dolgot, amibe nehéz egyszerre „adatokat betenni” és (még nehezebb) beszerezni. És ami teljesítmény szempontjából rendkívül nem optimális.

A modell kidolgozása időbe telik. De ez nem az „entitások rajzolására” fordítandó idő – ez az az idő, amelyre a témakör elemzéséhez, az adatok szerkezetének megértéséhez van szükség. Éppen ezért ebben a folyamatban nagyon szorosan részt vesznek az elemzők, valamint különböző üzleti szakértők. És ez szelektíven történik. És nem úgy, hogy őrülten sok emberrel találkozókat szervezünk, hatalmas kérdőíveket postázunk stb.
A minőségi üzleti és rendszerelemzés a kulcsa a tárolási alapmodell felépítésének. Sok mindent meg kell érteni: hol (milyen rendszerekben) keletkeznek az adatok, hogyan vannak elrendezve, milyen üzleti folyamatokban keringenek stb. A kvalitatív elemzés soha nem ártott egyetlen rendszernek sem. Ellenkezőleg, a problémák a mi felfogásunk szerinti „üres foltokból” adódnak.

Az adatmodell fejlesztése nem egy új kitalálás és kitalálás folyamata. Valójában az adatmodell már létezik a vállalatnál. A tervezési folyamat pedig inkább „ásatások” jellegű. A modell gyengéden és gondosan kerül napvilágra a vállalati adatok "földjéről", és strukturált formába öltöztetik.

4. mítosz. Cégünknél az üzletmenet annyira dinamikus, és minden olyan gyorsan változik, hogy felesleges modellt készítenünk – az elavulttá válik, mielőtt a rendszernek ezt a részét üzembe helyeznénk.
Valójában. Emlékezzünk vissza, hogy a mag kulcstényezője a stabilitás. És mindenekelőtt a modell topológiája. Miért? Mert ez az összetevő a központi és minden mást befolyásol. A stabilitás a kernelmodellhez is követelmény. Ha a modell túl gyorsan elavulttá válik, akkor rosszul van megtervezve. Kidolgozásához rossz megközelítéseket és „játékszabályokat” választottak. Ez is kvalitatív elemzés kérdése. A vállalati modell kulcselemei rendkívül ritkán változnak.
De ha az jut eszünkbe, hogy egy mondjuk édesipari termékeket forgalmazó cégnél a „Termékek” címtár helyett „Édességet”, „Süteményt” és „Pástétomot” készítsünk. Aztán amikor a pizza megjelenik az áruk listájában - igen, sok új asztalt kell megadnia. És ez csak megközelítés kérdése.

5. mítosz. A vállalati modell kialakítása nagyon komoly, összetett és felelősségteljes vállalkozás. És félelmetes hibázni.
Valójában. Az alapmodell, bár stabilnak kell lennie, mégsem „fémbe öntött”. Mint minden más tervezési döntés, felépítése is áttekinthető és módosítható. Csak ne felejtsd el ezt a tulajdonságát. De ez egyáltalán nem jelenti azt, hogy „ne tudna levegőt venni” rajta. Ez pedig nem jelenti azt, hogy elfogadhatatlanok lennének az ideiglenes megoldások és a feldolgozásra tervezett "csonkok".

6. mítosz. Ha van adatforrásunk - például NSI rendszer (vagy törzsadatkezelő rendszer - MDM), akkor annak jó értelemben meg kell felelnie a vállalati modellnek (különösen, ha nemrégiben tervezték, és nem volt ideje beszerezni „mellékhatások”, „hagyományok” és ideiglenes épületek). Kiderült, hogy ebben az esetben - nincs szükségünk kernelmodellre?
Valójában. Igen, ebben az esetben nagymértékben megkönnyíti a tárolómag modell felépítését - mert csúcsszintű kész koncepcionális modellt követünk. De egyáltalán nincs kizárva. Miért? Mert egy bizonyos rendszer modelljének felépítésekor bizonyos szabályok érvényesek – milyen típusú táblákat kell használni (az egyes entitásokhoz), hogyan kell verziózni az adatokat, milyen részletességgel kell tárolni az előzményeket, milyen metaattribútumokat (műszaki mezőket kell használni) stb. .

Ezen túlmenően, bármennyire is csodálatos és átfogó az NSI és MDM rendszerünk, általában árnyalatok társulnak a helyi címtárak „kb. ugyanilyen” létezéséhez más számviteli rendszerekben. Ezt a problémát pedig, ha akarjuk, ha nem, a tárhelyen kell majd megoldani, mert itt gyűjtik a riportokat és az elemzéseket.

Elsődleges adatréteg (vagy historizálható átmeneti vagy működési réteg)

Ez elsődleges adatrétegként van megjelölve. Ennek a komponensnek a szerepe: integráció a forrásrendszerekkel, elsődleges adatok betöltése és tárolása, valamint előzetes adattisztítás - a formátum-logikai ellenőrzés szabályainak betartásának ellenőrzése, a forrással kötött "interakciós interfész megállapodásban" rögzített.
Ráadásul ez a komponens a tároló számára egy nagyon fontos feladatot old meg - kiemelve a "valódi változás delta" -t, függetlenül attól, hogy a forrás lehetővé teszi-e az adatok változásainak nyomon követését vagy sem, és hogyan (milyen kritériummal lehet "elfogni") . Amint az adatok állomásoztatásba kerültek, a metaattribútumokkal történő jelölésnek köszönhetően már minden más réteg esetében egyértelmű a delta-kiválasztás kérdése.

Az ebben a rétegben lévő adatokat a forrásrendszerhez lehető legközelebb eső struktúrákban tároljuk - annak érdekében, hogy az elsődleges adatok a lehető legközelebb maradjanak eredeti formájukhoz. Ennek az összetevőnek egy másik neve "működési réteg".
Miért nem használjuk a bevett „színreállítás” kifejezést? A helyzet az, hogy korábban, a "big data és VLDB korszaka" előtt a lemezterület nagyon drága volt - és gyakran az elsődleges adatok, ha tárolták, csak korlátozott ideig voltak. És gyakran a "színreállítás" nevet hívják tisztítható puffer.
Mostanra a technológia előrelépett – és megengedhetjük magunknak, hogy ne csak tároljuk az összes elsődleges adatot, hanem a lehető legrészletesebben historizáljuk azokat. Ez nem jelenti azt, hogy ne irányítsuk az adatok növekedését, és nem szünteti meg az információ életciklusának kezelését az adattárolás költségeinek optimalizálásával, a felhasználás "hőmérsékletétől" függően - pl. a kevésbé keresett "hideg adatok" áthelyezése olcsóbb adathordozókra és tárolóplatformokra.

Mi adja számunkra a „történelmi színrevitel” jelenlétét:

• tévedés lehetősége (struktúrákban, transzformációs algoritmusokban, az előzmények megőrzésének granularitásában) - a tárhely rendelkezésre állási zónában teljesen historizálható elsődleges adatok birtokában bármikor újratölthetjük tábláinkat;
• lehetőség a gondolkodásra - időt szakíthatunk a mag egy nagy töredékének fejlesztésére a repository fejlesztésének ebben az iterációjában, mert a mi színrevitelünkben mindenesetre azok lesznek, mégpedig egyenletes időhorizonttal (egy „történelem kiindulópontja lesz”);
• az elemzés lehetősége - azokat az adatokat is elmentjük, amelyek már nem szerepelnek a forrásban - ott felülírhatók, archívumba menjen, stb. – nálunk elemzésre rendelkezésre állnak;
• információs auditálás lehetősége - a legrészletesebb elsődleges információknak köszönhetően ezután kideríthetjük, hogyan működött nálunk a letöltés, hogy végül ilyen számokat kaptunk (ehhez metaattribútumokkal való jelölés is szükséges és a megfelelő metaadatok, amelyeken a letöltés működik – ezt a szolgáltatási réteg dönti el).

Milyen nehézségek adódhatnak a „történelmi színtér” felépítésében:

• kényelmes lenne ennek a rétegnek a tranzakciós integritására követelményeket támasztani, de a gyakorlat azt mutatja, hogy ezt nehéz elérni (ez azt jelenti, hogy ezen a területen nem vállalunk garanciát referenciális integritás szülő és gyermek táblák) - az integritás igazítása a következő rétegeken történik;
• ez a réteg nagyon nagy köteteket tartalmaz (a legnagyobb a tárolóban - az analitikai struktúrák minden redundanciája ellenére) - és ezeket a köteteket kezelni kell - mind a betöltés, mind a lekérdezések szempontjából (ellenkező esetben komolyan leronthatja a a teljes tárhely teljesítménye).

Mit lehet még elmondani erről a rétegről.
Először is, ha eltávolodunk a „végponttól végpontig berakodási folyamatok” paradigmától, akkor a „karaván az utolsó teve sebességével mozog” szabály nálunk már nem működik, vagy inkább feladjuk a „karaván” elvet. és váltson át a „szállítószalag” elvre: az adatokat a forrásból vettük – helyezzük el a rétegébe – készen állunk a következő rész felvételére. Ez azt jelenti
1) nem várjuk meg a feldolgozást más rétegeken;
2) nem függünk más rendszerek adatszolgáltatási ütemtervétől.
Egyszerűen fogalmazva, ütemezünk egy betöltési folyamatot, amely egy forrásból egy adott kapcsolódási módszeren keresztül adatokat visz át oda, ellenőrzi, kivonja a deltát – és az adatokat állomásozó céltáblákba helyezi. És ez az.

Másodszor, ezek a folyamatok látszólag nagyon egyszerűen vannak elrendezve - mondhatni triviálisan, a logika szempontjából. Ez pedig azt jelenti, hogy nagyon jól optimalizálhatók és paraméterezhetők, csökkentve a rendszerünk terhelését és felgyorsítva a források összekapcsolásának folyamatát (fejlesztési idő).
Ahhoz, hogy ez megtörténjen, nagyon jól kell ismernie annak a platformnak a technológiai jellemzőit, amelyen ez az összetevő működik – és akkor nagyon hatékony eszközt készíthet.

Az elemző kirakat rétege

A Storefront réteg (Data mart réteg) felelős az adatok előkészítéséért és a végfelhasználóknak – embereknek vagy rendszereknek – való továbbításáért. Ezen a szinten a lehető legnagyobb mértékben figyelembe veszik a fogyasztó igényeit - logikai (fogalmi) és fizikailag egyaránt. A szolgáltatásnak pontosan azt kell nyújtania, amire szükség van – se többet, se kevesebbet.

Ha a fogyasztó egy külső rendszer, akkor főszabály szerint ő határozza meg a számára szükséges adatstruktúrákat és az információgyűjtés szabályait. A jó megközelítés az, amikor a fogyasztó felelős a helyes adatgyűjtésért. Az adattárház előkészítette, kialakította a kirakatot, lehetőséget biztosított a növekményes adatgyűjtésre (metaattribútumokkal történő jelölés a deltaváltozások későbbi kiválasztásához), majd a fogyasztói rendszer kezeli és felelős azért, hogy ezt a kirakatot hogyan használja. De vannak sajátosságok: amikor a rendszerben nincs aktív adatgyűjtési komponens, akkor vagy egy külső komponensre van szükség, amely integráló funkciót lát el, vagy a tároló „integrációs platformként” működik, és biztosítja az adatok helyes növekményes feltöltését. tovább – a tárolón kívül. Itt sok árnyalat merül fel, és az interfész interakció szabályait mindkét félnek át kell gondolnia és megértenie (azonban, mint mindig, ha integrációról van szó). Általában az ilyen kirakatoknál rutinszerű adattisztítást/archiválást alkalmaznak (ritkán szükséges ezeket a „tranzitadatokat” hosszú ideig tárolni).

Az analitikai feladatok szempontjából a legnagyobb jelentőségűek az „emberek számára” – pontosabban a BI-eszközök –, amelyekkel dolgoznak.
Létezik azonban a „különösen haladó felhasználók” kategóriája – elemzők, adattudósok –, akiknek nincs szükségük sem BI-eszközökre, sem rutinfolyamatokra a külső speciális rendszerek kitöltéséhez. Szükségük van valamiféle "közös kirakatra" és "saját homokozóra", ahol saját belátásuk szerint hozhatnak létre táblázatokat, átalakításokat. Ebben az esetben a repository felelőssége annak biztosítása, hogy ezek a közös adattárak az előírásoknak megfelelően legyenek feltöltve.
Külön kiemelhetünk olyan fogyasztókat, mint az adatbányászati ​​eszközök - mély adatelemzés. Ezeknek az eszközöknek saját adat-előkészítési követelményeik vannak, és adatkutatók is használják őket. A repository esetében a feladat lecsökken - ismét a szolgáltatás támogatására bizonyos megállapodás szerinti formátumú vitrinek letöltéséhez.

Térjünk azonban vissza az elemző kirakatokhoz. Ebben az adatrétegben a tárolótervezők szempontjából ők érdeklik őket.
Véleményem szerint Ralph Kimball megközelítése a legjobb időtálló megközelítés az adatpiacok tervezésére, amelyre ma már szinte minden BI-platform „ki van élesítve”. A névről ismerik dimenziós modellezés – többdimenziós modellezés. Nagyon sok publikáció létezik ebben a témában. Például az alapvető szabályok Marga Ross kiadványában találhatók. És persze ajánlhat a többváltozós modellezés guruitól. Egy másik hasznos forrás a Kimball tippjei.
A kirakatkészítés többdimenziós megközelítését olyan jól leírták és kidolgozták - mind a módszerevangélisták, mind a vezető szoftvergyártók -, hogy nincs értelme itt részletesen foglalkozni vele - mindig előnyben kell részesíteni az eredeti forrást.

Csak egy hangsúlyt szeretnék fektetni. A „jelentéskészítés és elemzés” más. Létezik „súlyos jelentéskészítés” – előre megrendelt jelentések, amelyeket fájlok formájában generálnak, és a megadott kézbesítési csatornákon keresztül eljuttatnak a felhasználókhoz. És vannak információs panelek – BI irányítópultok. Alapvetően ezek webes alkalmazások. És ezeknek az alkalmazásoknak a válaszidő követelményei ugyanazok, mint bármely más webalkalmazás esetében. Ez azt jelenti, hogy a BI panel normál frissítési ideje másodpercek, nem percek. Ezt fontos szem előtt tartani a megoldás kialakításakor. Hogyan lehet ezt elérni? Szabványos optimalizálási módszer: megnézzük, miből tevődik össze a válaszidő és mit tudunk befolyásolni. Mivel töltöd a legtöbb időt? Az adatbázis fizikai (lemezes) olvasásához, hálózaton keresztüli adatátvitelhez. Hogyan csökkenthető a kérésenként kiolvasott és továbbított adatok mennyisége? A válasz kézenfekvő és egyszerű: vagy összesíteni kell az adatokat, vagy szűrőt kell alkalmazni a lekérdezésben részt vevő nagy ténytáblákra, és ki kell zárni a nagy táblák összekapcsolását (a ténytáblákra való hivatkozás csak dimenziókon keresztül menjen át).

Mire való a BI? Hogyan kényelmes? Miért hatékony a többváltozós modell?
A BI lehetővé teszi a felhasználó számára, hogy úgynevezett "ad hoc lekérdezéseket" hajtson végre. Mit jelent? Ez azt jelenti, hogy pontosan nem ismerjük előre a kérést, de tudjuk, hogy a felhasználó milyen jelzőszámokat mely rovatokban kérhet. A felhasználó a megfelelő BI-szűrők kiválasztásával generál ilyen lekérdezést. A BI-fejlesztő és a kirakattervező feladata pedig egy ilyen alkalmazásműködési logika biztosítása, hogy az adatok vagy szűrve, vagy összesítve legyenek, elkerülve azt a helyzetet, amikor túl sok adatot kérnek, és az alkalmazás „lefagy”. Általában összesített számadatokkal kezdik, majd mélyebbre mennek a részletesebb adatokba, de közben beállítják a szükséges szűrőket.

Nem mindig elég egyszerűen megépíteni a „megfelelő csillagot” – és beszerezni egy kényelmes szerkezetet a BI számára. Néha valahol denormalizációt kell alkalmazni (miközben vissza kell nézni, hogy ez hogyan befolyásolja a terhelést), valahol másodlagos kirakatokat és aggregátumokat kell készíteni. Valahol indexek vagy előrejelzések hozzáadásához (a DBMS-től függően).

Így a „próbálkozás és hiba” révén a BI számára optimális struktúrát kaphat - amely figyelembe veszi mind a DBMS, mind a BI platform jellemzőit, valamint a felhasználó adatmegjelenítési követelményeit.
Ha a "magból" vesszük az adatokat, akkor a kirakatok ilyen feldolgozása helyi jellegű lesz, anélkül, hogy ez bármilyen módon befolyásolná a közvetlenül a forrásrendszerekből kapott elsődleges adatok összetett feldolgozását - csak "áthelyezzük" az adatokat egy kényelmes formátumba. BI számára. És megengedhetjük magunknak, hogy sokszor, különböző módon, más-más követelményeknek megfelelően tegyük. Sokkal egyszerűbb és gyorsabb ezt a kernel adatai alapján megtenni, mint az „elsődlegesből” összerakni (amelynek szerkezete és szabályai, mint tudjuk, „lebeghetnek is”).

szolgáltatási réteg

A szolgáltatási réteg ( - Service Layer) felelős a közös (szolgáltatási) funkciók megvalósításáért, amelyek segítségével a különböző tárolási rétegekben feldolgozhatók az adatok - terheléskezelés, adatminőség-kezelés, problémadiagnosztikai és monitorozó eszközök stb.
Elérhetőség adott szintátláthatóságot és strukturált adatfolyamokat biztosít a tárolóban.

Ez a réteg két adattárolási területet tartalmaz:

• metaadat-terület – az adatbetöltés-vezérlő mechanizmushoz használatos;
• adatminőségi terület - off-line adatminőség-ellenőrzések megvalósítása (azaz olyanok, amelyek nem közvetlenül az ETL folyamatokba vannak beépítve).

A terheléskezelési folyamatot különféle módon építheti fel. Az egyik lehetséges megközelítés a következő: a tárolótáblák teljes készletét modulokra bontjuk. Egy modulban csak egy réteg táblázatai szerepelhetnek. Az egyes modulokban található táblázatok egy külön folyamat részeként kerülnek betöltésre. Nevezzük el ellenőrzési folyamat . Az ellenőrzési folyamat elindítása saját ütemterv szerint történik. A vezérlési folyamat atomi folyamatok hívásait hangszereli, amelyek mindegyike egy-egy céltáblát tölt be, és tartalmaz néhány közös lépést is.
Nyilvánvalóan elegendő az állomásozó táblákat egyszerűen modulokra bontani - a forrásrendszerek, vagy inkább azok kapcsolódási pontjai szerint. De a kernel számára ezt már nehezebb megtenni - mert. ott biztosítanunk kell az adatok integritását, ami azt jelenti, hogy figyelembe kell vennünk a függőségeket. Azok. lesznek konfliktusok, amelyeket meg kell oldani. És különféle módok vannak a megoldásukra.

A terheléskezelés fontos pontja a hibakezelés egységes megközelítésének kialakítása. A hibákat kritikussági szint szerint osztályozzuk. Kritikus hiba esetén a folyamatot le kell állítani, és a lehető leghamarabb, mert. előfordulása jelentős problémát jelez, amely adatsérüléshez vezethet a tárolóban. Így a terheléskezelés nemcsak a folyamatok elindítását, hanem leállítását is jelenti, valamint a (tévedésből) idő előtti indulás megakadályozását.

A szolgáltatási réteg működéséhez egy speciális metaadat-struktúra jön létre. Ez a terület információkat tárol a betöltési folyamatokról, a betöltött adatkészletekről, a növekmény fenntartására használt ellenőrző pontokról (melyik folyamat melyik pontig olvasott be), valamint egyéb, a rendszer működéséhez szükséges szolgáltatási információkat.
Fontos megjegyezni, hogy az összes rétegben lévő összes céltábla speciális metamezőkkel van megjelölve, amelyek közül az egyik a karakterláncot frissítő folyamat azonosítója. A lerakaton belüli táblák esetében ez a folyamatjelölés egységes módot tesz lehetővé a delta-változások későbbi kinyerésére. Az adatok elsődleges adatrétegbe való betöltésekor a helyzet bonyolultabb - a különböző betöltött objektumok delta kinyerésének algoritmusa eltérő lehet. Másrészt az elfogadott változtatások feldolgozásának és a céltáblákra való görgetésnek a logikája a maghoz és a kirakatokhoz sokkal bonyolultabb, mint a színpadra állításnál, ahol minden elég triviális - könnyen paraméterezhető és átgondolható az újrafelhasználható tipikus lépések (eljárások). ).

Itt nem azt a feladatot tűzöm ki, hogy ezt a témát - a betöltés megszervezését - maradéktalanul lefedjem, csak olyan ékezeteket helyezek el, amelyekre érdemes odafigyelni.
A fenti megközelítés csak egy a lehetőségek közül. Eléggé alkalmazkodó. Az ő „koncepcionális prototípusa” pedig a Toyota szállítószalag és a „just-in-time” rendszer volt. Azok. eltávolodunk a kizárólagosan „éjszakai adatbetöltés” ​​elterjedt paradigmájától, és kis adagokban töltünk be napközben – hiszen különböző forrásokban készen állnak az adatok: ami be van töltve, az bejött. Ugyanakkor számos párhuzamos folyamat fut. A friss adatok „forró farka” pedig folyamatosan „villogni fog” – és egy idő után ki is alszik. Ezt a tulajdonságot figyelembe kell vennünk. És ha szükséges, egyedi vitrinek „szeleteket” alakítsunk ki, ahol már minden szervesen beépült. Azok. lehetetlen egyszerre elérni a hatékonyságot és a következetességet (integritást). Egyensúlyra van szükségünk – hol egy dolog fontos, hol máshol.

Rendkívül fontos a naplózási és megfigyelési eszközök biztosítása. Jó gyakorlat a gépelt események használata, ahol beállíthatja különböző lehetőségeketés beállít egy értesítési rendszert – előfizetést bizonyos eseményekre. Mert nagyon fontos, hogy amikor a rendszergazda beavatkozására van szükség, arról a lehető leghamarabb értesüljön, és minden szükséges diagnosztikai információt megkapjon. A naplók felhasználhatók utólagos problémaelemzésre, valamint rendszerhibás események kivizsgálására, pl. adat minőség.

Raktári adatmodellek tervezése és karbantartása

Miért fontos odafigyelni az adatmodellek kialakítására minden olyan rendszer fejlesztésekor, ahol adatbázis is szerepel (és különösen egy raktárban)? Miért nem dob be egy sor táblázatot bárhol – akár egy szövegszerkesztőben is? Miért van szükségünk ezekre a képekre?
Furcsa módon még a tapasztalt fejlesztők is felvetnek ilyen kérdéseket.
Valójában igen, semmi sem akadályozza meg abban, hogy táblázatokat vázoljon fel – és elkezdje használni őket. Ha... ha egyszerre fejben (!) A fejlesztőnek harmonikus összképe van az általa kialakított szerkezetről. Mi van, ha több fejlesztő van? De mi van akkor, ha valaki más fogja használni ezeket a táblázatokat? De mi van, ha telik az idő – az ember elhagyja ezt a területet, majd újra visszatér hozzá?

Ki lehet deríteni modell nélkül? Alapvetően megteheti. És hogy kitalálja, és „becsülje meg a képeket egy darab papírra”, és „seperje – rendezze” az adatokat. De sokkal egyszerűbb, áttekinthetőbb és gyorsabb egy kész műterméket - adatmodellt - használni. És megérteni a „szerkezetének logikáját” - pl. Jó lenne, ha lennének közös játékszabályok.

És a legfontosabb még csak nem is ez. A legfontosabb, hogy egy modell megtervezésekor kénytelenek vagyunk (egyszerűen opciók nélkül!) alaposabban és elmélyültebben áttanulmányozni a tárgykört, az adatstruktúra jellemzőit és azok felhasználását különböző üzleti esetekben. És azok a kérdések, amelyeket könnyen „félretolnánk”, mint összetetteket, „elmosódnánk” a jeleinket dobva anélkül, hogy megpróbálnánk tervezés modellt - most, az elemzés és tervezés során kénytelenek leszünk felállítani és dönteni, és nem később - amikor jelentéseket készítünk, és minden alkalommal azon gondolkodunk, hogy „hogyan csökkentsük az összeférhetetlent” és „feltaláljuk újra a kereket”.

Ez a megközelítés egyike azoknak a mérnöki gyakorlatoknak, amelyek lehetővé teszik törékeny rendszerek létrehozását. Mivel érthetőek, átláthatóak, könnyen fejleszthetőek, „törékenységi határaik” azonnal láthatóak, így pontosabban felmérhető a „katasztrófa mértéke” az új követelmények megjelenésekor és az újratervezés (ha szükséges) időigénye.
Így az adatmodell az egyik fő műtermék, amelyet a rendszer fejlesztése során karban kell tartani. Jó értelemben minden elemző, fejlesztő stb. számára „terítéken” kell lennie. – mindazok, akik részt vesznek a rendszerfejlesztési projektekben.

Az adatmodellek tervezése egy különálló, igen kiterjedt témakör. A tárolás tervezésének két fő megközelítése van.
A megközelítés jó a kernel számára "entitás-kapcsolat" - amikor egy normalizált (3NF) modellt építünk a tárgyterület, pontosabban annak kiválasztott terület tanulmányozása alapján. Itt ugyanaz a „vállalati modell” játszik szerepet, amelyről fentebb volt szó.

Az elemző vitrinek tervezésénél alkalmas többdimenziós modell . Ez a megközelítés kiválóan alkalmas az üzleti felhasználók megértésére. ez egy olyan modell, amely egyszerű és kényelmes az emberi észlelés számára - az emberek a metrikák (mutatók) érthető és ismert fogalmaival és az elemzésükre szolgáló szakaszokkal dolgoznak. És ez lehetővé teszi számunkra, hogy egyszerűen és egyértelműen felállítsuk a követelmények összegyűjtésének folyamatát - "vágási és mutatói mátrixokat" készítünk, kommunikálva a különböző osztályok képviselőivel. Ezután egy szerkezetbe hozzuk - az „elemzési modellbe”: létrehozzuk a „mérési buszt”, és meghatározzuk a rajtuk meghatározott tényeket. Útközben a hierarchiákon és az összesítési szabályokon dolgozunk.

Ezen túlmenően, nagyon könnyű áttérni a fizikai modellre, optimalizálási elemek hozzáadásával, figyelembe véve a DBMS jellemzőit. Például az Oracle esetében ez particionálás, indexek halmaza és így tovább. A Vertica esetében más technikákat alkalmaznak – válogatást, szegmentálást, szakaszolást.
Speciális denormalizálásra is szükség lehet - amikor szándékosan redundanciát viszünk be az adatokba, aminek köszönhetően javítjuk a lekérdezések teljesítményét, ugyanakkor bonyolítjuk az adatfrissítést (mert a redundanciát figyelembe kell venni és támogatni kell a adatbetöltési folyamat). Talán a teljesítmény javítása érdekében további összesítő táblákat is kell készítenünk, vagy ilyeneket kell használnunk további jellemzők DBMS mint vetületek a Vertica-ban.

Tehát a raktári adatok modellezésekor több problémát is megoldunk:

• a feladat a témakör alap - rendszer- és üzleti elemzése - tanulmányozásának fogalmi (logikai) modelljének felépítése, a részletekbe mélyedve, figyelembe véve az "élő adatok" árnyalatait és azok üzleti felhasználását;
• az elemzési modell - majd a kirakatok fogalmi (logikai) modelljének felépítése;
• a fizikai modellek felépítésének feladata az adatredundancia-kezelés, az DBMS adottságait figyelembe vevő optimalizálás a lekérdezésekhez és az adatbetöltésekhez.

Elvi modellek kidolgozásakor előfordulhat, hogy nem vesszük figyelembe egy adott DBMS jellemzőit, amelyhez adatbázis-struktúrát tervezünk. Sőt, egy elvi modell segítségével több fizikai modellt is létrehozhatunk – különböző DBMS-ekhez.

Foglaljuk össze.

• Az adatmodell nem „szép képek” halmaza, és a tervezési folyamat nem a rajzolás folyamata. A modell azt tükrözi, hogy megértjük a témakört. Összeállításának folyamata pedig tanulmányozásának és kutatásának folyamata. Itt vesztegetik az időt. És egyáltalán nem „rajzolni és színezni”.
• Az adatmodell egy tervezési műtermék, az információ strukturált megosztásának módja a csapat tagjai között. Ehhez mindenki számára érthetőnek (ezt a jelölés és magyarázat biztosítja) és hozzáférhetőnek (közzétételnek) kell lennie.
• Az adatmodellt nem egyszer hozzuk létre és fagyasztjuk be, hanem a rendszerfejlesztés folyamatában jön létre és fejlesztjük. Fejlesztésének szabályait magunk határozzuk meg. És megváltoztathatjuk őket, ha látjuk, hogyan tehetjük jobbá, egyszerűbbé, hatékonyabbá.
• Az adatmodell (fizikai) lehetővé teszi az optimalizálást célzó bevált gyakorlatok összességének konszolidálását és alkalmazását - pl. használja azokat a technikákat, amelyek már működtek ennél a DBMS-nél.

Adattárház projektek jellemzői

Foglalkozzunk azon projektek jellemzőivel, amelyeken belül a vállalat adattárházakat épít és fejleszt. És nézzük meg őket az építészeti szempont hatásának felől. Miért fontos építészetet építeni az ilyen projektekhez, és már a kezdetektől fogva? És az átgondolt architektúra jelenléte az, amely rugalmasságot ad az adattárház projektnek, lehetővé teszi a munka hatékony elosztását az előadók között, valamint megkönnyíti az eredmény előrejelzését, és kiszámíthatóbbá teszi a folyamatot.

A Data Warehouse egyedi szoftver

Az adattárház mindig „egyedi fejlesztés”, nem egy dobozos megoldás. Igen, vannak olyan iparág-specifikus BI-alkalmazások, amelyek referenciaadat-modellt, általános forrásokból (például ERP-rendszerekből) származó előre konfigurált ETL-folyamatokat, tipikus BI-irányítópultok és -jelentések készletét tartalmazzák. De a gyakorlatban a tárolást ritkán hajtják végre - "dobozként". Körülbelül 10 éve dolgozom a tárolással, és még soha nem láttam ilyen történetet. Mindig vannak árnyalatok a vállalat egyedi jellemzőihez – mind az üzleti, mind az informatikai környezethez. Ezért némileg vakmerőség azt remélni, hogy a megoldást szolgáltató „szállító” biztosítja az architektúrát. Az ilyen rendszerek architektúrája gyakran magán a szervezeten belül érik ki. Vagy a kivitelező cég szakemberei alkotják, amely a projekt fővállalkozója.

Az adattárház egy integrációs projekt

Az adattárház számos forrásrendszerből tölti be és dolgozza fel az információkat. És ahhoz, hogy „baráti kapcsolatokat” tudjon fenntartani velük, rendkívül óvatosnak kell lennie velük. Többek között minimálisra kell csökkenteni a forrásrendszerek terhelését, figyelembe kell venni az „elérhetőség és elérhetetlenség” ablakait, az interakciós felületeket ki kell választani, figyelembe véve azok architektúráját, stb. Ekkor a tároló a lehető legkorábban és a szükséges gyakorisággal tud majd adatokat gyűjteni. Ellenkező esetben „átviszik” egy tartalék áramkörre, amely nem frissül a leggyakrabban működőképes gyakorisággal.
Emellett az „emberi tényezőt” is figyelembe kell venni. Az integráció nem csak a gépek interakciója. Ez is az emberek közötti kommunikáció.

A Data Warehouse egy csapatprojekt

Egy nagy cégnél ritkán tud egy ilyen rendszert egyedül egy csapat elkészíteni. Általában több csapat dolgozik itt, amelyek mindegyike egy adott problémát old meg.

Az architektúrának biztosítania kell annak lehetőségét, hogy párhuzamos munkájukat megszervezzék, megőrizve integritását, és elkerülve ugyanazt a funkcionalitást különböző helyeken, különböző személyek által. A felesleges munkaerőköltségeken túl az ilyen duplikáció a későbbiekben eltérésekhez vezethet az adatokban.

Ezen túlmenően, amikor oly sok ember és csapat, gyakran szétszórtan vesz részt a rendszerfejlesztési folyamatban, óhatatlanul felmerül a kérdés: hogyan lehet kommunikációt és információs interakciót kiépíteni közöttük. Minél standardabb és érthetőbb megközelítéseket és gyakorlatokat alkalmazunk, annál egyszerűbb, kényelmesebb és hatékonyabb az ilyen munka felállítása. És ideértve érdemes elgondolkodni a „munkatermékek” összetételén, amelyek között az 1. számú adattárházak esetében adatmodellek találhatók (lásd az előző részt).

Az adattárház élettartama hosszabb a többi rendszerhez képest

Pontosítom: az állítás igaz egy "élő", működő, kulcsfontosságú forrásokkal integrált, történelmi adatokkal rendelkező, a vállalat számos részlegének információs és elemző szolgáltatásokat nyújtó tárolóra.

Milyen okom van arra, hogy ezt higgyem?
Egyrészt a tároló építése rendkívül erőforrásigényes folyamat: a tényleges berendezések, a szükséges technológiai szoftverek licencei és fejlesztési költségei mellett a cég szinte minden rendszere és részlege is részt vesz ebben. Ezt az egész folyamatot a semmiből megismételni nagyon merész vállalkozás.

Másodszor, ha a tároló megfelelő architektúrával rendelkezik, akkor könnyen túléli a forrásrendszerek változását, a végfelhasználói igények megjelenését és az adatmennyiségek növekedését.
Ha az architektúra megfelelő, az információáramlás átlátható, akkor egy ilyen rendszer hosszú ideig fejleszthető anélkül, hogy a hatás felmérési nehézségei miatt kábult helyzetbe kerülne a változtatások során.

Fokozatos iteratív fejlesztés

Az utolsó dolog, amit a Megrendelő szeretné, ha belekeveredne a tárolással kapcsolatos történetbe, az az, hogy egy-két évre befagyasztja igényeit, amíg meg nem készül a teljes vállalati adatmodell, minden forrás teljes mértékben be van kapcsolva stb.

Az adattárház az Ügyfelek szemében gyakran úgy néz ki, mint egy abszolút szörnyeteg – a rendszerfejlesztés feladatai, céljai és horizontja igen terjedelmes. És gyakran az Ügyfél attól tart, hogy „a költségvetése terhére” az informatikai részleg megold néhány „saját feladatot”. És ismét szembe kell néznünk az emberek közötti interakció kérdésével, valamint a higgadt álláspont kinyilvánításának és a tárgyalások képességének kérdésével.

A hozzáértő építészeti megközelítések lehetővé teszik a rendszer iteratív fejlesztését, fokozatosan növelve a funkcionalitást anélkül, hogy több éves „fejlesztésbe” kellene belemenni, mielőtt elkezdené az eredményt.

Bár meg kell jegyezni, hogy "csodák nem történnek" - és a "kezdés" is időbe telik. A tárolóknál ez elég nagy lehet - mivel nagy mennyiségű adatról van szó, ez historikus adat - olyan régi időszakokra, amikor az információfeldolgozás szabályai eltérhettek a jelenlegitől. Ezért elegendő időre van szükség az analitikai fejlesztéshez, a forrásrendszerekkel való interakcióhoz és a „próbálkozás és hiba” sorozatához, beleértve a valós adatokon végzett terhelési teszteket.

Adattárházak – "többprojekt történet"

Egy adattárházhoz nehéz egyetlen üzleti ügyfelet kiemelni. És úgy gondolják (nem ok nélkül), hogy a raktárépítési projekt sikerének kulcstényezője a vállalat vezetőségének – közvetlenül az első személy – támogatása.
Egy adattárat ritkán építenek és fejlesztenek egyetlen projekten belül. Általános szabály, hogy az adatkonszolidációra és elemzésre sokféle igény van, ezek mögött különböző Ügyfelek és felhasználói csoportok állnak. Ezért az adattárat gyakran több párhuzamos projekt keretében fejlesztik.

Az innováció és a bevált megoldások egyensúlya

Annak ellenére, hogy a tárolás témája nagyon „ősi” (ha ez a szó egy olyan fiatal iparágra vonatkozik, mint az IT) és meglehetősen konzervatív. Ennek ellenére a fejlődés nem áll meg – és a korábban létező korlátok a drága és lassú lemezek, a drága memória stb. miatt. - most eltávolították. És ugyanakkor itt az ideje, hogy újragondoljunk néhány építészeti megközelítést. Sőt, ez vonatkozik mind a technológiai platformokra, mind az ezeken alapuló alkalmazott rendszerek architektúrájára.

Itt fontos egyensúlyt teremteni – és fenntartani a meglehetősen „zöld” megközelítést mind az erőforrások, mind a tárolt információk tekintetében. Ellenkező esetben nagyon gyorsan félig strukturált "szemétteleppé" változtathatja a tárat, amit ha sikerül rendbe tenni, akkor elég sok erőfeszítésen megy keresztül.
Igen, több lehetőségünk van, de ez nem jelenti azt, hogy meg kell tagadnunk minden olyan, az idő által kidolgozott és kipróbált praktikát, amelyek világosan érthetőek, hogyan és miért kell használni, és csak a ködösség vezette „minden komoly dologba bele kell engednünk”. az „innováció” szelleme.
Az egyensúly megtartása azt jelenti, hogy új módszereket és megközelítéseket alkalmazunk, ahol új lehetőségeket nyitnak meg, ugyanakkor a régi, bevált módszereket olyan sürgős problémák megoldására, amelyeket senki sem mondott le.
Mit tehetünk alkalmazott megoldások fejlesztőjeként és tervezőjeként? Mindenekelőtt ismerni és megérteni azon platformok technológiai változásait, amelyeken dolgozunk, képességeiket, jellemzőit és alkalmazási korlátaikat.

Nézzük a DBMS-t – mint a tárolás legkritikusabb és legfontosabb technológiai platformját.
Az utóbbi időben az eredetileg "univerzálisként" létrehozott relációs adatbázisok egyértelműen a specializáció felé sodródnak. A vezető gyártók hosszú ideje különféle opciókat bocsátanak ki - különböző osztályok (OLTP, DSS és DWH) alkalmazásokhoz. Ezenkívül további lehetőségek vannak a szöveggel, földrajzi adatokkal stb.

De a dolog nem korlátozódott erre - kezdtek megjelenni olyan termékek, amelyek kezdetben egy bizonyos feladatcsoportra összpontosítottak - pl. speciális DBMS. Használhatják vagy nem használják a relációs modellt. A lényeg az, hogy kezdetben nem csak általában az "üzleti információk" tárolására és feldolgozására vannak "kihegyezve", hanem bizonyos feladatokra.

Úgy tűnik, a centralizáció és a specializáció két egymást kiegészítő irányzat, amelyek időszakosan felváltják egymást, biztosítva a fejlődést és az egyensúlyt. Valamint evolúciós (fokozatos) fokozatos fejlődés és kardinális változások. Tehát a 90-es években Michael Stonebreaker volt az egyik szerzője a Generation III Database Manifesto-nak, amely egyértelműen azt a gondolatot hangoztatta, hogy a világnak nincs szüksége újabb forradalomra az adatbázisok világában. 10 évvel később azonban olyan műveket ad ki, amelyekben a DBMS világában egy új korszak kezdetének előfeltételeit hirdeti meg - pontosan azok specializációja alapján.
Arra összpontosít, hogy a széles körben elterjedt univerzális DBMS-ek egy „egy méretben” architektúrára épülnek, amely nem veszi figyelembe a hardverplatformok változásait vagy az alkalmazások osztályokra osztását, amelyekre jobb megoldást lehet találni, mint egyetemes követelmények megvalósítása.
És ennek az ötletnek megfelelően számos projektet kezd kidolgozni. Az egyik a C-Store, egy oszlopos DBMS, amelyet a megosztott semmi (SN) architektúrában terveztek, és eredetileg kifejezetten adattárolási osztályú rendszerek számára készültek. Ezt a terméket HP Vertica néven forgalmazták tovább.

Úgy tűnik, most az adattárházak fejlesztésének témája egy újabb fejlesztési körbe csúszott. Új technológiák, megközelítések és eszközök jelennek meg. Tanulmányozásuk, tesztelésük és ésszerű alkalmazásuk lehetővé teszi számunkra, hogy igazán érdekes és hasznos megoldásokat alkossunk. És valósítsd meg őket, élvezve, hogy fejlesztéseidet valódi munkában használják fel, és hasznot hoznak.

Epilógus

A cikk elkészítése során elsősorban az adattárházakkal közvetlenül dolgozó építészekre, elemzőkre és fejlesztőkre igyekeztem koncentrálni. De kiderült, hogy elkerülhetetlenül „kicsit szélesebbre vettem a témát” - és az olvasók más kategóriái is a látómezőbe kerültek. Egyes pontok ellentmondásosnak tűnnek, néhány nem egyértelmű, néhány nyilvánvaló. Az emberek különbözőek – különböző tapasztalatokkal, háttérrel és pozíciókkal.
A menedzserek tipikus kérdései például a következők: „mikor érdemes építészeket vonzani?”, „Mikor kezdjek építészettel?”, „Építészet – nem lesz túl drága?” elég furcsán hangzik nekünk (fejlesztőknek, tervezőknek), mert számunkra a rendszer architektúrája a megszületésével jelenik meg - teljesen mindegy, hogy észrevesszük-e vagy sem. És még ha nincs is formális építész szerep a projektben, egy normális fejlesztő mindig „belekapcsolja a belső építészét”.

A dolgok nagy vázlatában teljesen mindegy, hogy ki az építész, az számít, hogy valaki felteszi ezeket a kérdéseket, és megkeresi a válaszokat. Ha az építészt egyértelműen kiemelik, az csak azt jelenti, hogy elsősorban ő a felelős a rendszerért és annak fejlesztéséért.
Miért tűnt számomra relevánsnak az „antitörékenység” témája ezzel a témával kapcsolatban?

„A törékenység elleni küzdelem egyedisége abban rejlik, hogy lehetővé teszi számunkra, hogy együtt dolgozzunk az ismeretlennel, tegyünk valamit olyan körülmények között, amikor nem értjük, mit csinálunk pontosan – és hogy sikeresek legyünk.”/Nassim N.Taleb/

Ezért a válság és a nagyfokú bizonytalanság nem mentség az architektúra hiányára, hanem olyan tényezők, amelyek megerősítik annak szükségességét.

Ipari adatmodellek

A modellek fő célja, hogy megkönnyítsék az adattérben való tájékozódást és segítsenek kiemelni az üzletfejlesztés szempontjából fontos részleteket. A mai üzleti környezetben elengedhetetlen a különböző összetevők közötti kapcsolatok világos megértése és a szervezet átfogó képének megfelelő megértése. Az összes részlet és kapcsolat modellek segítségével történő azonosítása lehetővé teszi az idő és az eszközök leghatékonyabb felhasználását a vállalati munkaszervezéshez.

Az adatmodellek olyan absztrakt modellek, amelyek leírják az adatok megjelenítését és elérését. Az adatmodellek egy adott területen adatelemeket és a köztük lévő kapcsolatokat határozzák meg. Az adatmodell egy navigációs eszköz mind az üzleti, mind az informatikai szakemberek számára, amely meghatározott szimbólum- és szókészletet használ a valós információk egy bizonyos osztályának pontos magyarázatára. Ez javítja a szervezeten belüli kommunikációt, és így rugalmasabb és stabilabb alkalmazási környezetet teremt.

Az adatmodell egyedileg határozza meg az adatok jelentését, amelyek ebben az esetben strukturált adatok (szemben a strukturálatlan adatokkal, például képekkel, bináris fájlokkal vagy szövegekkel, ahol az érték nem egyértelmű).

Általában megkülönböztetünk magasabb szintű (és tartalmilag általánosabb) és alacsonyabb szintű (illetve részletesebb) modelleket. A modellezés felső szintje az ún fogalmi adatmodellek(fogalmi adatmodellek), amelyek a legáltalánosabb képet adják egy vállalkozás vagy szervezet működéséről. A fogalmi modell tartalmazza azokat a főbb fogalmakat vagy tématerületeket, amelyek kritikusak a szervezet működése szempontjából; általában számuk nem haladja meg a 12-15-öt. Egy ilyen modell leírja a szervezet számára fontos entitásosztályokat (üzleti objektumok), azok jellemzőit (attribútumait), valamint ezen osztályok párjai közötti asszociációkat (azaz kapcsolatokat). Mivel az üzleti modellezés terminológiája még nem teljesen rendeződött, a különféle angol nyelvű forrásokban a fogalmi adatmodelleket tárgyterületi modellnek (amely lefordítható tárgyterületi modellnek) vagy tárgyi vállalati adatmodellnek (alanyi vállalati adatmodellek) is nevezhetjük. ).

A következő hierarchikus szint az logikai adatmodellek(logikai adatmodellek). Ezeket vállalati adatmodelleknek vagy üzleti modelleknek is nevezhetjük. Ezek a modellek adatstruktúrákat, azok attribútumait és üzleti szabályait tartalmazzák, és a vállalat által üzleti szempontból használt információkat jelenítenek meg. Egy ilyen modellben az adatok entitások és a köztük lévő kapcsolatok formájában szerveződnek. A logikai modell az adatokat az üzleti felhasználók számára könnyen érthető módon ábrázolja. Egy logikai modellben hozzá lehet rendelni egy adatszótárat – az összes entitás listája a pontos definíciókkal, amely lehetővé teszi a különböző felhasználói kategóriák számára, hogy egységesen értelmezzék a modell összes bemeneti és információs kimeneti áramlását. következő, több alacsony szint A modellezés már egy logikai modell fizikai megvalósítása meghatározott szoftvereszközök és technikai platformok segítségével.

A logikai modell tartalmazza a részletes vállalati üzleti döntést, amely általában egy normalizált modell formáját ölti. A normalizálás az a folyamat, amely biztosítja, hogy a modellben minden adatelemnek csak egy értéke legyen, és teljesen és egyedileg függjön az elsődleges kulcstól. Az adatelemek egyedi azonosításuk szerint csoportokba vannak rendezve. Az adatelemeket vezérlő üzleti szabályokat teljes mértékben be kell építeni a normalizált modellbe, érvényességük és helyességük előzetes ellenőrzésével. Például egy olyan adatelemet, mint például az Ügyfél neve, nagy valószínűséggel felosztanák Keresztnévre és Vezetéknévre, és más releváns adatelemekkel egy Ügyfél-entitásba csoportosítanák, amelynek elsődleges kulcsa az Ügyfél-azonosító.

A logikai adatmodell független az olyan alkalmazástechnológiáktól, mint az adatbázis-, hálózati vagy jelentéskészítő eszközök, és ezek fizikai megvalósítása. Egy szervezetnek csak egy vállalati adatmodellje lehet. A logikai modellek általában több ezer entitást, kapcsolatot és attribútumot tartalmaznak. Például egy pénzintézet vagy egy távközlési vállalat adatmodellje körülbelül 3000 iparági koncepciót tartalmazhat.

Fontos különbséget tenni a logikai és a szemantikai adatmodell között. A logikai adatmodell a vállalati üzleti megoldást, míg a szemantikai adatmodell az alkalmazott üzleti megoldást reprezentálja. Ugyanaz a vállalati logikai adatmodell különböző szemantikai modellekkel valósítható meg, pl. A szemantikai modellek a fizikai modellekhez közelítő modellezés következő szintjének tekinthetők. Ezen túlmenően, ezek a modellek mindegyike a vállalati adatmodell külön „szeletét” képviseli majd, a különféle alkalmazások követelményeinek megfelelően. Például egy vállalati logikai adatmodellben az Ügyfél entitás teljesen normalizálva lesz, egy adatpiac szemantikai modelljében pedig többdimenziós struktúraként ábrázolható.

Egy vállalat kétféleképpen hozhat létre vállalati logikai adatmodellt: saját maga készítheti el, vagy használhat készen iparági modell(iparági logikai adatmodell). Ebben az esetben a kifejezések közötti különbségek csak ugyanazon logikai modell felépítésének eltérő megközelítéseit tükrözik. Abban az esetben, ha egy vállalat önállóan kifejleszti és megvalósítja saját logikai adatmodelljét, akkor egy ilyen modellt általában egyszerűen vállalati logikai modellnek neveznek. Ha a szervezet úgy dönt, hogy professzionális beszállító késztermékét használja fel, akkor iparági logikai adatmodellről beszélhetünk. Ez utóbbi egy kész logikai adatmodell, amely nagy pontossággal tükrözi egy adott iparág működését. Az iparági logikai modell egy tartomány-specifikus és integrált nézet minden olyan információról, amelynek a vállalati adattárházban kell lennie ahhoz, hogy megválaszolja mind a stratégiai, mind a taktikai üzleti kérdéseket. Mint minden más logikai adatmodell, az iparági modell sem függ az alkalmazási megoldásoktól. Nem tartalmaz továbbá származtatott adatokat vagy egyéb számításokat a gyorsabb adatlekéréshez. Általános szabály, hogy egy ilyen modell logikai struktúráinak többsége jó megtestesülést talál a hatékony fizikai megvalósításban. Ilyen modelleket sok szállító fejleszt a legkülönfélébb területeken: pénzügy, gyártás, turizmus, egészségügy, biztosítás stb.

Az iparági logikai adatmodell olyan információkat tartalmaz, amelyek egy iparágra jellemzőek, ezért nem jelenthetnek teljes megoldást egy vállalat számára. A legtöbb vállalatnak átlagosan 25%-kal kell növelnie a modellt adatelemek hozzáadásával és definíciók bővítésével. Az elkészült modellek csak a legfontosabb adatelemeket tartalmazzák, a többi elemet a modell vállalati telepítése során kell a megfelelő üzleti objektumokhoz hozzáadni.

Az iparági logikai adatmodellek jelentős számú absztrakciót tartalmaznak. Az absztrakció a hasonló fogalmak egyesülésére utal olyan köznevek alatt, mint az esemény vagy a résztvevő. Ez rugalmasabbá teszi az iparági modelleket, és egységesebbé teszi őket. Így az esemény fogalma minden iparágra alkalmazható.

Steve Hoberman üzleti intelligencia szakértő öt olyan tényezőt vázol fel, amelyeket figyelembe kell venni egy iparági adatmodell megvásárlásakor. Az első a modell elkészítéséhez szükséges idő és erőforrás. Ha egy szervezetnek gyorsan kell eredményeket elérnie, akkor az iparági modell előnyt jelent. Egy iparági modell használata nem biztos, hogy azonnal képet ad a teljes szervezetről, de jelentős időt takaríthat meg. A tényleges modellezés helyett a meglévő struktúrák iparági modellhez való kapcsolásával, valamint annak megvitatásával kell számolni, hogyan lehet a legjobban testreszabni azt a szervezet igényeihez (például milyen definíciókat érdemes megváltoztatni, és mely adatelemeket kell hozzáadni).

A második tényező a modell működéséhez szükséges idő és pénz. Ha a vállalati adatmodell nem része egy olyan módszertannak, amely lehetővé teszi a pontosságának és konzisztenciájának való megfelelés ellenőrzését modern szabványok, akkor egy ilyen modell nagyon gyorsan elavulttá válik. Az iparági adatmodell megelőzheti ezt a kockázatot, mivel külső erőforrások tartják naprakészen. Természetesen a szervezeten belüli változásokat magának a vállalatnak kell tükröznie a modellben, de az iparági változásokat a beszállítója reprodukálja a modellben.

A harmadik tényező a kockázatértékelésben és modellezésben szerzett tapasztalat. A vállalati adatmodell létrehozása szakképzett erőforrásokat igényel mind az üzleti, mind az informatikai személyzettől. A vezetők általában jól ismerik vagy a szervezet egészének munkáját, vagy egy adott részleg tevékenységét. Közülük csak kevesen rendelkeznek széleskörű (vállalati szintű) és mély (egységszintű) ismeretekkel a vállalkozásukat illetően. A legtöbb menedzser általában csak egy területet ismer jól. Ezért a vállalati szintű kép kialakításához jelentős üzleti erőforrásokra van szükség. Ez növeli az informatikusokkal szemben támasztott követelményeket is. Minél több üzleti erőforrásra van szükség egy modell létrehozásához és teszteléséhez, annál tapasztaltabbnak kell lenniük az elemzőknek. Nemcsak tudnia kell, hogyan szerezzen információkat az üzletemberektől, hanem a vitás területeken is meg kell tudnia találni a közös hangot, és képesnek kell lennie mindezt az információ integrált bemutatására. A modellt létrehozónak (sok esetben ugyanaz az elemző) jó modellező képességekkel kell rendelkeznie. A vállalati logikai modellek létrehozásához szükség van a „jövő” modellezésére, valamint arra, hogy az összetett üzletet szó szerint „négyzetekké és vonalakban” alakítsuk át.

Másrészt az iparági modell lehetővé teszi a külső szakértők tapasztalatainak felhasználását. Az iparág-specifikus logikai modellek bevált modellezési módszereket és tapasztalt szakemberekből álló csapatokat használnak, hogy elkerüljék a gyakori és költséges problémákat, amelyek a vállalati adatmodellek szervezeten belüli fejlesztése során merülhetnek fel.

A negyedik tényező a meglévő alkalmazási infrastruktúra és szállítói kapcsolatok. Ha egy szervezet már sok eszközt használ ugyanattól a szállítótól, és van velük kapcsolat, akkor érdemes az iparági modellt is tőlük megrendelni. Egy ilyen modell szabadon együttműködhet ugyanazon szállító más termékeivel.

Az ötödik tényező az iparágon belüli információcsere. Ha egy vállalatnak meg kell osztania az adatokat más, ugyanazon a területen működő szervezetekkel, akkor ebben a helyzetben egy iparági modell nagyon hasznos lehet. Az azonos iparágon belüli szervezetek hasonló szerkezeti összetevőket és terminológiát használnak. Manapság a legtöbb iparágban a vállalatok arra kényszerülnek, hogy megosszák egymással az adatokat, hogy sikeresen működhessenek.

A professzionális gyártók által kínált iparági modellek a leghatékonyabbak. Használatuk nagy hatékonyságát e modellek jelentős részletessége és pontossága biztosítja. Általában sok adatattribútumot tartalmaznak. Ezen túlmenően ezeknek a modelleknek a készítői nemcsak széles körű modellezési tapasztalattal rendelkeznek, hanem jártasak egy adott iparág modelljének építésében is.

Az iparági adatmodellek a vállalatok számára egységes, integrált nézetet biztosítanak üzleti információikról. Sok vállalat nehezen tudja integrálni adatait, bár ez a legtöbb vállalati szintű projekt előfeltétele. A The Data Warehousing Institute (TDWI) tanulmánya szerint a megkérdezett szervezetek több mint 69%-a az integrációt jelentős akadálynak találta az új alkalmazások elfogadása előtt. Éppen ellenkezőleg, az adatintegráció megvalósítása jelentős bevételt hoz a cégnek.

Az iparági adatmodell amellett, hogy összekapcsolódik a meglévő rendszerekkel, nagy előnyöket biztosít az olyan vállalati szintű projektekhez, mint a vállalati erőforrás-tervezés (ERP), a törzsadatok kezelése, az üzleti intelligencia, az adatminőség javítása és az alkalmazottak fejlesztése.

Így az iparági logikai adatmodellek hatékony eszközt jelentenek az adatok integrálására és az üzletről alkotott holisztikus kép kialakítására. A logikai modellek alkalmazása szükséges lépésnek tűnik a vállalati adattárházak létrehozása felé.

Publikációk

1. Steve Hoberman. Az iparági logikai adatmodell kihasználása vállalati adatmodellként
2. Claudia Imhoff. Gyors nyomon követhető adattárház- és üzleti intelligenciaprojektek intelligens adatmodellezés segítségével

Úgy tűnik, most az adattárházak fejlesztésének témája egy újabb fejlesztési körbe csúszott. Új technológiák, megközelítések és eszközök jelennek meg. Tanulmányozásuk, tesztelésük és ésszerű alkalmazásuk lehetővé teszi számunkra, hogy igazán érdekes és hasznos megoldásokat alkossunk. És valósítsd meg őket, élvezve, hogy fejlesztéseidet valódi munkában használják fel, és hasznot hoznak.

Epilógus

A cikk elkészítése során elsősorban az adattárházakkal közvetlenül dolgozó építészekre, elemzőkre és fejlesztőkre igyekeztem koncentrálni. De kiderült, hogy elkerülhetetlenül „kicsit szélesebbre vettem a témát” - és az olvasók más kategóriái is a látómezőbe kerültek. Egyes pontok ellentmondásosnak tűnnek, néhány nem egyértelmű, néhány nyilvánvaló. Az emberek különbözőek – különböző tapasztalatokkal, háttérrel és pozíciókkal.
A menedzserek tipikus kérdései például a következők: „mikor érdemes építészeket vonzani?”, „Mikor kezdjek építészettel?”, „Építészet – nem lesz túl drága?” elég furcsán hangzik nekünk (fejlesztőknek, tervezőknek), mert számunkra a rendszer architektúrája a megszületésével jelenik meg - teljesen mindegy, hogy észrevesszük-e vagy sem. És még ha nincs is formális építész szerep a projektben, egy normális fejlesztő mindig „belekapcsolja a belső építészét”.

A dolgok nagy vázlatában teljesen mindegy, hogy ki az építész, az számít, hogy valaki felteszi ezeket a kérdéseket, és megkeresi a válaszokat. Ha az építészt egyértelműen kiemelik, az csak azt jelenti, hogy elsősorban ő a felelős a rendszerért és annak fejlesztéséért.
Miért tűnt számomra relevánsnak az „antitörékenység” témája ezzel a témával kapcsolatban?

„A törékenység elleni küzdelem egyedisége abban rejlik, hogy lehetővé teszi számunkra, hogy együtt dolgozzunk az ismeretlennel, tegyünk valamit olyan körülmények között, amikor nem értjük, mit csinálunk pontosan – és hogy sikeresek legyünk.”/Nassim N.Taleb/

Ezért a válság és a nagyfokú bizonytalanság nem mentség az architektúra hiányára, hanem olyan tényezők, amelyek megerősítik annak szükségességét.

Címkék: Címkék hozzáadása

5.1. Adatok rendszerezése vállalati információs rendszerekben.

A CIS-t a legegyszerűbb szinten tekintve azt mondhatjuk, hogy egy vállalati számítógépes (számítógépes) hálózatot és egy speciális alkalmazási szoftvercsomagot (APP) tartalmaz a témakörben felmerülő problémák megoldására. Viszont mind a PPP, mind a számítógépes hálózat magában foglalja az általuk vezérelt és kezelt rendszerek állapotáról és fejlődéséről szóló információs adatok felhasználását. Történelmileg a FÁK az egyes vállalkozások elágazó alrendszereiből áll, amelyek összekapcsolódnak és gyakran reprezentálnak hierarchikus rendszer. Természetes azt feltételezni, hogy az ilyen alrendszerek saját forrásokkal és saját helyekkel rendelkeznek a kapcsolódó adatok tárolására. Egy rendszerré egyesítve kérdések merülnek fel a földrajzilag különböző tárolási helyeken elhelyezkedő adatok együttes helyes felhasználásával kapcsolatban. Ezért a CIS-sel felszerelt termelési társulás sikeres menedzseléséhez megbízható adatgyűjtési, -tárolási és -feldolgozási rendszerre van szüksége. Más szóval, szükség van egy egységes információs infrastruktúrára, amely megfelel a stratégiai BI (Business Intelligence) projekteknek, vagy egy integrált adatbázisra az adatok tárolására és felhasználására. Az adatintegráció fő célja, hogy egységes és teljes képet kapjunk a vállalati üzleti adatok állapotáról. Maga az integráció egy összetett folyamat, amely alapján célszerű kiemelni:

Technológia,

Termékek,

Alkalmazások.

Mód az adatintegráció megközelítései.

Technológia- ezek bizonyos adatintegrációs módszereket megvalósító folyamatok.

Termékek olyan kereskedelmi megoldások, amelyek támogatják az egyik vagy másik adatintegrációs technológiát.

Alkalmazások- ezek kész műszaki megoldások, amelyeket a fejlesztők szállítanak a megrendelők - vásárlók kívánságainak megfelelően.

A vállalati információs rendszerek összetettségétől és az általuk megoldandó feladatoktól függően némileg eltérő az adatok rendszerezése bennük. Különösen a FÁK-ban, amelynek célja, hogy biztosítsa az egyes ágazatok és a vállalat egészének üzleti folyamatainak hatékony kezelését, szokás beszélni a vállalati adatbázisok jelenlétéről. A legmagasabb vezetési szinteken használt vállalati információs rendszerekben, amelyek többnyire az operatív elemzés és döntéshozatal folyamataihoz kapcsolódnak, a különböző típusú menedzsment tevékenységek tervezése, tervezése és előrejelzése során az adattárház terminológiáját használják. Helyénvaló megjegyezni, hogy a kifejezés integrált információtárolás mindkettőhöz tartozik.

5.2. Vállalati adatbázisok és követelményeik

Az egész rendszerre kiterjedő integrált adattárként a vállalati adatbázist úgy alakították ki, hogy információkat nyújtson a vállalat összes üzleti folyamatának és részlegének hatékony kezeléséhez. Az adatintegráció egy új struktúra létrehozását jelenti, amely szervesen tartalmazza az egyes részlegek adatbázisainak adatait, így egy ilyen struktúrának bizonyos követelményeket kell teljesítenie:

Egyszerű és felhasználóbarát adatbevitel az adatbázisba,

Az adatok olyan formában történő tárolása, amely nem vezet túlzott adatnövekedéshez,

· Elérhetőség Általános információ a társaság valamennyi részlegének alkalmazottai a hozzáférési jogok megkülönböztetésének kötelező feltétele mellett,

A szükséges információk gyors megtalálása és kiválasztása,

A szükséges adatok rendezése és szűrése,

Hasonló adatok csoportosítása

Közbenső és végső számítások mezőkön,

A kimeneti adatok átalakítása és láthatósága,

méretezhetőség,

· Biztonság a véletlen meghibásodások, az állandó adatvesztés és az illetéktelen hozzáférés ellen.

Emellett különálló (elosztott) adatbázisok egyetlen vállalati adatbázisba integrálásakor fontos biztosítani az adatbázissal való munkavégzés lehetőségét úgy, hogy a felhasználó úgy dolgozzon vele, mint egy nem elosztott adatbázissal.

Az integrált vállalati adatbázis létrehozása többféle módszerrel lehetséges, amelyek közül a legfontosabbak:

· Konszolidáció,

föderalizáció,

· Terítés.

5.3. Vállalati adatbázisok integrációs megoldásainak jellemzői

Konszolidáció. Alatt konszolidációáltalában azonos nevű adatok hozzáadására utal. Hasonló kifejezést széles körben használnak a bankszektorban, ahol éves összevont mérleget készítenek, amely lehetővé teszi az anyabank összes eszközének és forrásának bemutatását fiókjaival együtt.

Egy vállalat esetében ennek a módszernek a használatakor az adatok másolása és összegyűjtése elsődleges adatbázisokból (DB - Slave) történik egyetlen tárolóhelyre (DB - Master) való integrálással. Ilyen tárolóhelynek általában a központi (fő)iroda szerverét választják (5.1. ábra).

5.1. ábra. Adatkonszolidációs módszer

A DB - Master adatait jelentéskészítésre, elemzésre, fejlesztésre és döntéshozatalra használják, valamint adatforrásként szolgálnak a vállalat más ágai számára.

Az ilyen megoldások konszolidáció során történő támogatására a leggyakoribb technológiák a következő technológiák:

Kivonás, átalakítás és betöltés - ETL (Extract Transform Load);

· Vállalati tartalomkezelés – ECM (Enterprise Content Management).

A konszolidációs módszer előnyei a következők:

1. Az átalakulás képessége jelentős mennyiségű adat (átstrukturálása, egyeztetése, tisztítása és/vagy összesítése) az elsődleges rendszerekből a végső tárolóhelyekre történő átvitele során az ETL technológiának köszönhetően,

2. Strukturálatlan adatok kezelésének képessége, mint például dokumentumok, jelentések és oldalak az ECM technológiai megoldásoknak köszönhetően.

A konszolidált CIS adatbázissal való munkához speciális üzleti alkalmazások, amelyek lehetővé teszik adatbázis-adatokhoz, riportokhoz lekérdezések készítését és ezek alapján adatelemzések elvégzését.

A konszolidációval történő integráció hátránya, hogy az integrált tárolóhelyen lévő konszolidált adatok nem frissíthetők szinkronban az elsődleges rendszerek adatfrissítéseivel a szinkronizálási ütközések miatt.

Időkésleltetés az adatok frissítésének pillanatai között az elsődleges rendszerekben és a végső tárolási helyen.

Ez a késleltetés néhány másodperctől több óráig vagy akár napig is terjedhet.

Föderalizáció. Alatt föderalizációáltalában szakszervezetnek nevezik. Hasonló kifejezést gyakran használnak a politikában egy állam határainak rendezésekor (például Németország, Oroszország, USA).

Az adatok föderalizálásának folyamata egy vállalati adatbázisban egy virtuális (látszólagos) kép létrehozása, amely több elsődleges adatfájlt egyesít egyetlen virtuális egésszé (lásd 5.2. ábra). Maga az adatföderalizáció abban áll, hogy külső követelmények alapján adatokat nyernek ki az elsődleges rendszerekből. A szövetségi módszer szerint integrált vállalati adatbázis kezelését a föderalizációs processzor.

2. ábra. Adat-összevonási módszer

A virtuális adatbázishoz fordulva minden üzleti alkalmazás kérést küld a virtuális képhez. A kérés alapján az összevonási processzor kivonja az adatokat a releváns elsődleges rendszerekből, integrálja azokat a virtuális képnek megfelelően, és az eredményt visszaküldi a kérést generáló üzleti alkalmazásnak. Ebben az esetben az összes szükséges adatátalakítás végrehajtásra kerül, amikor azokat az elsődleges rendszerekből kinyerjük.

Az adatintegráció egyesített megközelítésének támogatását az Enterprise Information Integration (E I I) technológia biztosítja, ami azt jelenti: - Corporate Information Integration.

Az egyesített megoldás egyik jellemzője, hogy az elsődleges adatok eléréséhez az összevonási processzort használja metaadatokat(knowledge), amely a virtuális kép összetételére és jellemzőire, az adatok mennyiségére, a köztük lévő szemantikai kapcsolatokra és a hozzáférési módokra vonatkozó adatokat tartalmazza, amelyek segítik a föderatív megoldást az elsődleges rendszerekhez való hozzáférés optimalizálásában.

Az egyesített megközelítés fő előnyei a következők:

az aktuális adatokhoz való hozzáférés lehetősége további új adatbázis létrehozása nélkül,

az alkalmazás célszerűsége a társaságok felvásárlását vagy egyesülését követően,

nélkülözhetetlen olyan esetekben, amikor biztonsági okokból licenckorlátozások vonatkoznak az adatok elsődleges rendszerekről történő másolására,

szükség esetén kihasználják a társaság helyi részlegeinek nagyfokú autonómiáját és tevékenységeik központosított ellenőrzésének rugalmasságát,

· nagyfokú hasznosság a transznacionális nagyvállalatok számára.

A megközelítés hátrányai a következők:

Csökkent teljesítmény a több adatforráshoz való hozzáférés többletköltsége miatt,

föderalizáció a legalkalmasabb kis kitermelésére adattömbök,

Az elsődleges adatok magas minőségi követelményei.

Terítés. Alatt terjedésáltalában a sokszorosított objektumok területi átadására utal. Az adatterjesztés az elsődleges adatbázisok reprodukálására és egyik helyről a másikra való áthelyezésére vonatkozik. Ennek a módszernek a megvalósítása során üzleti alkalmazások online működjön, és bizonyos események alapján adatokat vigyen át a célállomásokra. Ennél a technikai megoldásnál fontossá válik az adatok frissítésének kérdése, amely szinkron vagy aszinkron módban lehetséges A szinkron mód feltételezi, hogy a frissítések mind az elsődleges rendszerben, mind a végső rendszerben ugyanazon fizikai tranzakció során történnek.

Példák az adatterjesztési módszer megvalósítását támogató technológiákra:

Vállalati alkalmazások integrációja EAI - Enterprise Application Integration,

· Vállalati adatok replikációja EDR – Vállalati adatreplikáció.

Az adatterjesztési módszer megvalósításának általánosított struktúrája az 5.3. ábrán látható.

5.3. ábra. Adatterjesztés módszere

Az adatelosztási módszer megkülönböztető jellemzője az adatok garantált eljuttatása a célrendszerhez a valós időhöz közeli minimális késleltetéssel.

A technológiai integráció (EAI) és a replikáció (EDR) kombinációja a módszerben számos előnnyel jár, a következő előnyök formájában:

· Nagy teljesítményű,

Adatok átstrukturálásának és tisztításának lehetősége,

· Terheléselosztás biztonsági mentések készítésével és adatok visszaállításával.

hibrid megközelítés. A gazdasági tevékenység valósága olyan, hogy nincs két egyforma vállalkozás, különösen két egyforma társaság. Ez a körülmény rányomja bélyegét a CIS létrehozásának és kitöltésének folyamatára. Ez teljes mértékben vonatkozik az adatok adatbázisba integrálásának módszereire. Emiatt sok EIS használja az úgynevezett adatintegrációt adatintegrációs alkalmazásaiban. hibrid egy olyan megközelítés, amely egyidejűleg több integrációs módszert is magában foglal. Példák erre a megközelítésre olyan technológiák, amelyek következetes képet adnak az ügyfelek információiról:

Ügyféladatok integrálása CDI rendszerekbe - Ügyféladatok integrációja,

· Ügyféladatok integrálása a CRM-be – Customer Relations Management modulok.

Különösen a CDI-megvalósítási megközelítést lehet többféleképpen alkalmazni.

A legegyszerűbb módja egy összevont ügyféladatbázis létrehozása, amely az elsődleges rendszerek adatait tartalmazza. Ugyanakkor az információhátralék különböző konszolidációs módokkal szabályozható: operatív vagy kötegelt, az információk frissítésének gyakoriságától függően.

A második mód az adat-összevonás, amikor virtuális üzleti prezentációk az elsődleges rendszerekben található ügyféladatok. A metaadatfájl pedig közös kulcselemeket tartalmazhat, amelyekkel kapcsolatba hozható az ügyféladatok.

Így az általános (például részletek) vásárlói adatok a legstatikusabb adatként konszolidálhatók. A dinamikusabb adatok (például a rendelés részletei) pedig egyesíthetők.

Ezenkívül a hibrid megközelítés kiterjeszthető az adatterjesztési módszerrel. Például egy internetes áruház szolgáltatásait igénybe vevő ügyfél a szolgáltatás során megváltoztatja adatait. Ezeket a változtatásokat el lehet küldeni az adatbázis konszolidált részére, és onnan továbbítani minden elsődleges, ügyféladatokat tartalmazó elsődleges rendszerre.

Az egyes módszerek előnyeit és hátrányait szem előtt tartva ajánlatos kreatívnak lenni alkalmazásuk és megosztásuk során.

Az adatok összevonása például akkor hasznos, ha az adatkonszolidáció költségei meghaladják a konszolidáció üzleti előnyeit. Különösen a kérelmek gyors feldolgozása és a jelentések elkészítése egy ilyen helyzet.

Az adatterjesztési módszer gyakorlati alkalmazása igen sokrétű, mind a teljesítmény, mind az adatok átstrukturálhatósága, tisztítása szempontjából.

5.4. Az adattárházak koncepciója és szerkezeti megoldásai

Adattár - külső és működési, valamint más rendszerek adatait felhalmozó, tantárgyorientált integrált információtároló, amelyre a döntéshozatali és adatelemzési folyamatok épülnek.

Az adatbázisokkal és adatbankokkal ellentétben az adattárházak nem belső, hanem külső adatforrásokon alapulnak: különféle Információs rendszerek, elektronikus archívumok, nyilvános elektronikus katalógusok, címtárak és gyűjtemények.

Az adattárházak koncepciója két fő gondolaton alapul:

1. Különböző részletes adatok (konkrét tények, tulajdonságok, események stb. leírása) integrálása egyetlen tárolóba.

2. A feldolgozáshoz és elemzéshez használt adatkészletek és alkalmazások szétválasztása.

Az adattárolást olyan esetekben szervezzük meg, amikor szükséges:

A jelenlegi és a történelmi integrációja adatértékek,

Különböző forrásokból származó adatok konszolidálása,

Megbízható adatplatform létrehozása elemzési célokra,

Az adatok homogenitásának biztosítása a szervezeten belül,

A vállalati adatszabványok megvalósításának megkönnyítése a meglévő operációs rendszerek megváltoztatása nélkül,

· Széles körű történeti kép és lehetőségek biztosítása a fejlődési trendek elemzéséhez.

A történelem során az adattárházak egy-, két- és háromszintű sémára épültek.

Egyszintű sémák eredetileg a legegyszerűbb architektúrákhoz készültek, amelyek magukban foglalják a funkcionális DSS-t is, fejletlen információs infrastruktúrával, amikor az elemzés az operációs rendszerek adatainak felhasználásával történik, a következő elv szerint: adat - prezentációs formák.

Az ilyen rendszerek előnyei a következők:

Gyors adatátvitel az operációs rendszerekről egy speciális rendszerre köztes kapcsolatok nélkül,

· Minimális költségek egyetlen platform használata miatt.

Hibák:

Az egyetlen adatforrás miatt megoldandó problémák szűk köre,

· Rossz adatminőség a tisztítási lépés hiánya miatt.

Kétszintű sémák láncot biztosítanak: adatok - adatpiacok - prezentációs formák. Olyan vállalatoknál használják őket, amelyek nagyszámú független részleggel rendelkeznek saját információs technológiájuk segítségével.

Előnyök:

A használt vitrineket úgy tervezték, hogy megválaszoljanak egy adott kérdéscsoportot,

· Lehetőség van a kirakatokban lévő adatok optimalizálására, ami javítja a teljesítményt.

Hibák:

Nehézségek az adatok konzisztenciájának biztosításában a kirakatokban való ismétlődés miatt,

A vitrinek nagyszámú adatforrással való kitöltésének lehetséges bonyolultsága,

· Tekintettel a vállalati szintű adatkonszolidáció hiányára, nincs egységes kép az üzletről.

A fejlődés fejlődése oda vezetett, hogy a korszerű vállalati rendszerek teljes értékű adattárházának kiépítése a háromszintű architektúra (lásd 5.4. ábra).

A első szinten vannak különféle rögzítési rendszerek, amelyek adatforrásként szolgálnak. Ilyen rendszerek lehetnek vállalati erőforrás-tervező (ERP) rendszerek, referencia (operatív) rendszerek, külső források vagy hírügynökségektől adatokat szolgáltató rendszerek stb.

A második szint tartalmaz egy központi adattárat, ahol az első szint összes forrásából gyűjtik az adatokat, valamint egy működő adattárházat, amely két funkciót lát el:

A raktár az operatív irányításhoz használt analitikai információk forrása,

· Az üzemi raktárban az adatok előkészítése a központi tárolóba történő utólagos betöltésre. Az adatkészítés alatt az első szintről történő adatfelvételre vonatkozó eltérő szabályozásokhoz kapcsolódóan az ellenőrzések, adatátalakítások lebonyolítását értjük.

Harmadik a szint tartomány-specifikus adatpiacok gyűjteménye.

Adatpiacok – ezek viszonylag kisméretű, funkcionálisan orientált meghajtók, amelyek tartalma hozzájárul a vállalat egyes részlegeinek elemzési problémáinak megoldásához. Valójában az adatpiacok egy raktárból származó adatok részhalmazai. A végfelhasználók ugyanakkor hozzáférhetnek a részletes raktári adatokhoz, ha nincs elegendő adat az adatpiacon, valamint teljesebb képet kaphatnak az üzlet helyzetéről.

5.4. ábra. Adattárház architektúra

Az ilyen szervezett adattárházak fő technológiai műveletei a következők:

· kitermelés az adat az adatok heterogén forrásokból egy működő raktárba történő átvitelének folyamata,

· átalakítás az adat az adatok speciális szabályok alapján történő módosítása, utólagos központi tárolóba történő átvitelével,

· tisztítás az adat a különböző forrásokból származó adatok megkettőzésének kiküszöbölése,

· Frissítés Az adat az adatfrissítések elosztása az alaptáblázatok forrásadataihoz és a raktárban tárolt származtatott adatokhoz.

Előnyök:

A vitrinek kitöltése leegyszerűsödik az egyetlen tisztított adatforrás használatának köszönhetően,

· Az adattárak szinkronizálva vannak a vállalati üzleti képpel, ami megkönnyíti a központi tárhely bővítését és az adattárak hozzáadását,

· Garantált teljesítmény.

Hibák:

az adatredundancia jelenléte, ami az adattárolási technológia iránti követelmények növekedéséhez vezet,

5. 5. Adatbázis-kezelő rendszerek és adathozzáférési technológiák a CIS-ben

Adatbázis kezelő rendszer(DBMS) egy komplex nyelv és szoftver eszközök adatbázis létrehozásához, karbantartásához és egy vagy több felhasználóval való megosztásához.

Jelenleg a legszélesebb körben használt DBMS-ek egy szigorú matematikai apparátus által leírt relációs adatmodell alapján épülnek fel. kapcsolatelmélet.

A CIS-ben működő DBMS-ek sajátossága, hogy az űrben elosztott médián található adatbázisokat kell kezelniük.

A VIR-ben található adatok további megkettőzésének vagy másolásának elkerülése érdekében a fő hangsúly a távoli adatfeldolgozás elvén van. A CIS adatbázisai sok felhasználó számára szükséges adatokat tartalmaznak. Több felhasználó egyidejű hozzáférése az adatbázishoz lehetséges, ha helyi számítógépes hálózatra telepítik a felhasználókkal és egyetlen adatbázissal működő DBMS-t.

Az adatbázisokkal végzett többfelhasználós munka fő technológiai megoldásai a fájl/szerver és a kliens/szerver technológiák. E technológiák közül a legelfogadhatóbb lehetőséget választva a CIS-ben lévő kliens/szerver speciális rendszereket szervez az elosztott adatbázisok feldolgozására. Ugyanakkor az elosztott adatbázisokat úgy kezelik, hogy az adatok nem logikai, hanem fizikai szinten kerülnek elosztásra, és magát az adatbázist egyetlen "szuperséma"-nak tekintik. Egy elosztott adatbázisban az adminisztrátor funkciói meg vannak osztva az egyesített adatbázis-adminisztrátor és a helyi adatbázis-adminisztrátorok között. Az integrált adatbázis adminisztrátora figyelemmel kíséri a különböző felhasználók adatbázishoz való hozzáférésének differenciálását, és gondoskodik az adatok sértetlenségéről, biztonságáról, valamint az adatok védelméről a több felhasználó egyidejű javításától. A hozzáférés-ellenőrzés a hálózati operációs rendszerben az egyes felhasználók számára biztosított jogosultságokkal összhangban történik.

A DBMS segítségével létrehozott programok távoli és elosztott vállalati adatbázisokkal való munkavégzésére jellemző jellemzője a nyílt adatelérési felület - ODBC (Open Data Base Connectivity) használata. Minden adatátviteli funkció az ODBC interfészhez van hozzárendelve, amely összekötő híd az integrált adatbázis DBMS-e és a kliens alkalmazások DBMS-ei között. Ugyanakkor a kliens DBMS-je nem csak a helyi adatbázisaival, hanem az integrált adatbázisban található adatokkal is kölcsönhatásba léphet. A kliensnek lehetősége van kéréseket küldeni az integrált adatbázis DBMS-ére, adatokat fogadni azokon és elküldeni saját frissített adatait.

Ipari adatmodellek

A modellek fő célja, hogy megkönnyítsék az adattérben való tájékozódást és segítsenek kiemelni az üzletfejlesztés szempontjából fontos részleteket. A mai üzleti környezetben elengedhetetlen a különböző összetevők közötti kapcsolatok világos megértése és a szervezet átfogó képének megfelelő megértése. Az összes részlet és kapcsolat modellek segítségével történő azonosítása lehetővé teszi az idő és az eszközök leghatékonyabb felhasználását a vállalati munkaszervezéshez.

Az adatmodellek olyan absztrakt modellek, amelyek leírják az adatok megjelenítését és elérését. Az adatmodellek egy adott területen adatelemeket és a köztük lévő kapcsolatokat határozzák meg. Az adatmodell egy navigációs eszköz mind az üzleti, mind az informatikai szakemberek számára, amely meghatározott szimbólum- és szókészletet használ a valós információk egy bizonyos osztályának pontos magyarázatára. Ez javítja a szervezeten belüli kommunikációt, és így rugalmasabb és stabilabb alkalmazási környezetet teremt.

Az adatmodell egyedileg határozza meg az adatok jelentését, amelyek ebben az esetben strukturált adatok (szemben a strukturálatlan adatokkal, például képekkel, bináris fájlokkal vagy szövegekkel, ahol az érték nem egyértelmű).

Általában megkülönböztetünk magasabb szintű (és tartalmilag általánosabb) és alacsonyabb szintű (illetve részletesebb) modelleket. A modellezés felső szintje az ún fogalmi adatmodellek(fogalmi adatmodellek), amelyek a legáltalánosabb képet adják egy vállalkozás vagy szervezet működéséről. A fogalmi modell tartalmazza azokat a főbb fogalmakat vagy tématerületeket, amelyek kritikusak a szervezet működése szempontjából; általában számuk nem haladja meg a 12-15-öt. Egy ilyen modell leírja a szervezet számára fontos entitásosztályokat (üzleti objektumok), azok jellemzőit (attribútumait), valamint ezen osztályok párjai közötti asszociációkat (azaz kapcsolatokat). Mivel az üzleti modellezés terminológiája még nem teljesen rendeződött, a különféle angol nyelvű forrásokban a fogalmi adatmodelleket tárgyterületi modellnek (amely lefordítható tárgyterületi modellnek) vagy tárgyi vállalati adatmodellnek (alanyi vállalati adatmodellek) is nevezhetjük. ).

A következő hierarchikus szint az logikai adatmodellek(logikai adatmodellek). Ezeket vállalati adatmodelleknek vagy üzleti modelleknek is nevezhetjük. Ezek a modellek adatstruktúrákat, azok attribútumait és üzleti szabályait tartalmazzák, és a vállalat által üzleti szempontból használt információkat jelenítenek meg. Egy ilyen modellben az adatok entitások és a köztük lévő kapcsolatok formájában szerveződnek. A logikai modell az adatokat az üzleti felhasználók számára könnyen érthető módon ábrázolja. Egy logikai modellben hozzá lehet rendelni egy adatszótárat – az összes entitás listája a pontos definíciókkal, amely lehetővé teszi a különböző felhasználói kategóriák számára, hogy egységesen értelmezzék a modell összes bemeneti és információs kimeneti áramlását. A modellezés következő, alacsonyabb szintje már a logikai modell fizikai megvalósítása speciális szoftvereszközök és technikai platformok segítségével.

A logikai modell tartalmazza a részletes vállalati üzleti döntést, amely általában egy normalizált modell formáját ölti. A normalizálás az a folyamat, amely biztosítja, hogy a modellben minden adatelemnek csak egy értéke legyen, és teljesen és egyedileg függjön az elsődleges kulcstól. Az adatelemek egyedi azonosításuk szerint csoportokba vannak rendezve. Az adatelemeket vezérlő üzleti szabályokat teljes mértékben be kell építeni a normalizált modellbe, érvényességük és helyességük előzetes ellenőrzésével. Például egy olyan adatelemet, mint például az Ügyfél neve, nagy valószínűséggel felosztanák Keresztnévre és Vezetéknévre, és más releváns adatelemekkel egy Ügyfél-entitásba csoportosítanák, amelynek elsődleges kulcsa az Ügyfél-azonosító.

A logikai adatmodell független az olyan alkalmazástechnológiáktól, mint az adatbázis-, hálózati vagy jelentéskészítő eszközök, és ezek fizikai megvalósítása. Egy szervezetnek csak egy vállalati adatmodellje lehet. A logikai modellek általában több ezer entitást, kapcsolatot és attribútumot tartalmaznak. Például egy pénzintézet vagy egy távközlési vállalat adatmodellje körülbelül 3000 iparági koncepciót tartalmazhat.

Fontos különbséget tenni a logikai és a szemantikai adatmodell között. A logikai adatmodell a vállalati üzleti megoldást, míg a szemantikai adatmodell az alkalmazott üzleti megoldást reprezentálja. Ugyanaz a vállalati logikai adatmodell különböző szemantikai modellekkel valósítható meg, pl. A szemantikai modellek a fizikai modellekhez közelítő modellezés következő szintjének tekinthetők. Ezen túlmenően, ezek a modellek mindegyike a vállalati adatmodell külön „szeletét” képviseli majd, a különféle alkalmazások követelményeinek megfelelően. Például egy vállalati logikai adatmodellben az Ügyfél entitás teljesen normalizálva lesz, egy adatpiac szemantikai modelljében pedig többdimenziós struktúraként ábrázolható.

Egy vállalat kétféleképpen hozhat létre vállalati logikai adatmodellt: saját maga készítheti el, vagy használhat készen iparági modell(iparági logikai adatmodell). Ebben az esetben a kifejezések közötti különbségek csak ugyanazon logikai modell felépítésének eltérő megközelítéseit tükrözik. Abban az esetben, ha egy vállalat önállóan kifejleszti és megvalósítja saját logikai adatmodelljét, akkor egy ilyen modellt általában egyszerűen vállalati logikai modellnek neveznek. Ha a szervezet úgy dönt, hogy professzionális beszállító késztermékét használja fel, akkor iparági logikai adatmodellről beszélhetünk. Ez utóbbi egy kész logikai adatmodell, amely nagy pontossággal tükrözi egy adott iparág működését. Az iparági logikai modell egy tartomány-specifikus és integrált nézet minden olyan információról, amelynek a vállalati adattárházban kell lennie ahhoz, hogy megválaszolja mind a stratégiai, mind a taktikai üzleti kérdéseket. Mint minden más logikai adatmodell, az iparági modell sem függ az alkalmazási megoldásoktól. Nem tartalmaz továbbá származtatott adatokat vagy egyéb számításokat a gyorsabb adatlekéréshez. Általános szabály, hogy egy ilyen modell logikai struktúráinak többsége jó megtestesülést talál a hatékony fizikai megvalósításban. Ilyen modelleket sok szállító fejleszt a legkülönfélébb területeken: pénzügy, gyártás, turizmus, egészségügy, biztosítás stb.

Az iparági logikai adatmodell olyan információkat tartalmaz, amelyek egy iparágra jellemzőek, ezért nem jelenthetnek teljes megoldást egy vállalat számára. A legtöbb vállalatnak átlagosan 25%-kal kell növelnie a modellt adatelemek hozzáadásával és definíciók bővítésével. Az elkészült modellek csak a legfontosabb adatelemeket tartalmazzák, a többi elemet a modell vállalati telepítése során kell a megfelelő üzleti objektumokhoz hozzáadni.

Az iparági logikai adatmodellek jelentős számú absztrakciót tartalmaznak. Az absztrakció a hasonló fogalmak egyesülésére utal olyan köznevek alatt, mint az esemény vagy a résztvevő. Ez rugalmasabbá teszi az iparági modelleket, és egységesebbé teszi őket. Így az esemény fogalma minden iparágra alkalmazható.

Steve Hoberman üzleti intelligencia szakértő öt olyan tényezőt vázol fel, amelyeket figyelembe kell venni egy iparági adatmodell megvásárlásakor. Az első a modell elkészítéséhez szükséges idő és erőforrás. Ha egy szervezetnek gyorsan kell eredményeket elérnie, akkor az iparági modell előnyt jelent. Egy iparági modell használata nem biztos, hogy azonnal képet ad a teljes szervezetről, de jelentős időt takaríthat meg. A tényleges modellezés helyett a meglévő struktúrák iparági modellhez való kapcsolásával, valamint annak megvitatásával kell számolni, hogyan lehet a legjobban testreszabni azt a szervezet igényeihez (például milyen definíciókat érdemes megváltoztatni, és mely adatelemeket kell hozzáadni).

A második tényező a modell működéséhez szükséges idő és pénz. Ha egy vállalati adatmodell nem része a pontos és naprakész módszertannak, a modell nagyon gyorsan elavulttá válik. Az iparági adatmodell megelőzheti ezt a kockázatot, mivel külső erőforrások tartják naprakészen. Természetesen a szervezeten belüli változásokat magának a vállalatnak kell tükröznie a modellben, de az iparági változásokat a beszállítója reprodukálja a modellben.

A harmadik tényező a kockázatértékelésben és modellezésben szerzett tapasztalat. A vállalati adatmodell létrehozása szakképzett erőforrásokat igényel mind az üzleti, mind az informatikai személyzettől. A vezetők általában jól ismerik vagy a szervezet egészének munkáját, vagy egy adott részleg tevékenységét. Közülük csak kevesen rendelkeznek széleskörű (vállalati szintű) és mély (egységszintű) ismeretekkel a vállalkozásukat illetően. A legtöbb menedzser általában csak egy területet ismer jól. Ezért a vállalati szintű kép kialakításához jelentős üzleti erőforrásokra van szükség. Ez növeli az informatikusokkal szemben támasztott követelményeket is. Minél több üzleti erőforrásra van szükség egy modell létrehozásához és teszteléséhez, annál tapasztaltabbnak kell lenniük az elemzőknek. Nemcsak tudnia kell, hogyan szerezzen információkat az üzletemberektől, hanem a vitás területeken is meg kell tudnia találni a közös hangot, és képesnek kell lennie mindezt az információ integrált bemutatására. A modellt létrehozónak (sok esetben ugyanaz az elemző) jó modellező képességekkel kell rendelkeznie. A vállalati logikai modellek létrehozásához szükség van a „jövő” modellezésére, valamint arra, hogy az összetett üzletet szó szerint „négyzetekké és vonalakban” alakítsuk át.

Másrészt az iparági modell lehetővé teszi a külső szakértők tapasztalatainak felhasználását. Az iparág-specifikus logikai modellek bevált modellezési módszereket és tapasztalt szakemberekből álló csapatokat használnak, hogy elkerüljék a gyakori és költséges problémákat, amelyek a vállalati adatmodellek szervezeten belüli fejlesztése során merülhetnek fel.

A negyedik tényező a meglévő alkalmazási infrastruktúra és szállítói kapcsolatok. Ha egy szervezet már sok eszközt használ ugyanattól a szállítótól, és van velük kapcsolat, akkor érdemes az iparági modellt is tőlük megrendelni. Egy ilyen modell szabadon együttműködhet ugyanazon szállító más termékeivel.

Az ötödik tényező az iparágon belüli információcsere. Ha egy vállalatnak meg kell osztania az adatokat más, ugyanazon a területen működő szervezetekkel, akkor ebben a helyzetben egy iparági modell nagyon hasznos lehet. Az azonos iparágon belüli szervezetek hasonló szerkezeti összetevőket és terminológiát használnak. Manapság a legtöbb iparágban a vállalatok arra kényszerülnek, hogy megosszák egymással az adatokat, hogy sikeresen működhessenek.

A professzionális gyártók által kínált iparági modellek a leghatékonyabbak. Használatuk nagy hatékonyságát e modellek jelentős részletessége és pontossága biztosítja. Általában sok adatattribútumot tartalmaznak. Ezen túlmenően ezeknek a modelleknek a készítői nemcsak széles körű modellezési tapasztalattal rendelkeznek, hanem jártasak egy adott iparág modelljének építésében is.

Az iparági adatmodellek a vállalatok számára egységes, integrált nézetet biztosítanak üzleti információikról. Sok vállalat nehezen tudja integrálni adatait, bár ez a legtöbb vállalati szintű projekt előfeltétele. A The Data Warehousing Institute (TDWI) tanulmánya szerint a megkérdezett szervezetek több mint 69%-a az integrációt jelentős akadálynak találta az új alkalmazások elfogadása előtt. Éppen ellenkezőleg, az adatintegráció megvalósítása jelentős bevételt hoz a cégnek.

Az iparági adatmodell amellett, hogy összekapcsolódik a meglévő rendszerekkel, nagy előnyöket biztosít az olyan vállalati szintű projektekhez, mint a vállalati erőforrás-tervezés (ERP), a törzsadatok kezelése, az üzleti intelligencia, az adatminőség javítása és az alkalmazottak fejlesztése.

Így az iparági logikai adatmodellek hatékony eszközt jelentenek az adatok integrálására és az üzletről alkotott holisztikus kép kialakítására. A logikai modellek alkalmazása szükséges lépésnek tűnik a vállalati adattárházak létrehozása felé.

Publikációk

1. Steve Hoberman. Az iparági logikai adatmodell kihasználása vállalati adatmodellként
2. Claudia Imhoff. Gyors nyomon követhető adattárház- és üzleti intelligenciaprojektek intelligens adatmodellezés segítségével

A vállalati adatbázis a vállalati információs rendszer központi linkje, és lehetővé teszi egyetlen vállalati információs tér létrehozását. Vállalati adatbázisok

Ossza meg munkáját a közösségi hálózatokon

Ha ez a munka nem felel meg Önnek, az oldal alján található a hasonló művek listája. Használhatja a kereső gombot is

V. TÉMA VÁLLALATI ADATBÁZISOK

V .egy. Adatok rendszerezése vállalati rendszerekben. Vállalati adatbázisok.

V .2. DBMS és strukturális megoldások vállalati rendszerekben.

V.3. Internet / Intranet technológiák és vállalati adatbázis-hozzáférési megoldások.

V .egy. ADATSZERVEZÉS VÁLLALATI RENDSZEREKBEN. VÁLLALATI ADATBÁZISOK

Vállalati bázis Az adatok a vállalati információs rendszer központi láncszemei, és lehetővé teszik a vállalat egységes információs terének létrehozását. Vállalati adatbázisok (1.1. ábra).

Az adatbázisokra többféle definíció létezik.

Az adatbázis alatt (DB) megérteni egy logikailag összefüggő információhalmazt úgy, hogy egyetlen adathalmazt képezzenek, amelyeket a számítógép tárolóeszközein tárolnak. Ez a készlet az automatizált vezérlőrendszerek, adatfeldolgozó rendszerek, információs és számítástechnikai rendszerek működése során megoldott feladatok kiinduló adataiként szolgál.

Az adatbázis kifejezést röviden megfogalmazhatja logikailag összefüggő adatok megosztásra szánt gyűjteményeként.

Adatbázis alatt A kifejezés minimális redundanciával együtt tárolt adatok gyűjteményére utal, hogy optimálisan használható legyen egy vagy több alkalmazáshoz.

Adatbázisok létrehozásának célja mint adattárolási forma olyan adatrendszer felépítése, amely nem függ az elfogadott algoritmusoktól ( szoftver), az alkalmazott technikai eszközök, az adatok fizikai elhelyezkedése a számítógépen. Az adatbázis többcélú felhasználást feltételez (több felhasználó, sokféle dokumentum és egy felhasználó lekérdezése).

Alapvető adatbázis követelmények:

• Az adatok bemutatásának teljessége. Az adatbázisban lévő adatoknak megfelelően kell reprezentálniuk az objektumra vonatkozó összes információt, és elegendőnek kell lenniük az ODS-hez.
• Adatbázis integritás. Az adatokat az ODS-ek feldolgozása során és a munkavégzés során felmerülő minden esetben meg kell őrizni.
• Az adatstruktúra rugalmassága. Az adatbázisnak lehetővé kell tennie az adatszerkezetek megváltoztatását anélkül, hogy megsértené annak integritását és teljességét, amikor a külső feltételek megváltoznak.
• Megvalósíthatóság. Ez azt jelenti, hogy objektíven kell ábrázolni a különféle objektumokat, tulajdonságaikat és kapcsolataikat.
• Elérhetőség. Az adatokhoz való hozzáférés differenciáltságát biztosítani kell.
• redundancia. Az adatbázisnak minimális redundanciával kell rendelkeznie bármely objektum adatainak megjelenítésében.

A tudás érthető tények, minták és heurisztikus szabályok összessége, amellyel megoldhatja a problémát.

Tudásbázis (KB)  a döntéshozóktól kapott adatbázisok és használt szabályok gyűjteménye. A tudásbázis a szakértői rendszerek eleme.

meg kell különböztetni az adatok bemutatásának különböző módjai.

Fizikai adatok Ezek a számítógép memóriájában tárolt adatok.

Az adatok logikai megjelenítése megfelel a fizikai adatok felhasználó általi megjelenítésének. Az adatok fizikai és megfelelő logikai megjelenítése között az a különbség, hogy az utóbbi néhány fontos kapcsolatot tükröz a fizikai adatok között.

Vállalati adatbázis alatt megérteni egy olyan adatbázist, amely ilyen vagy olyan formában egyesíti az összes szükséges adatot és tudást egy automatizált szervezetről. A vállalati információs rendszerekben olyan fogalom, mint plintegrált adatbázisok, amelyben megvalósul az információ egyszeri bejegyzésének és többszörös felhasználásának elve.

Rizs. 1.1. Az osztályok és a vállalat információforrásai közötti interakció szerkezete.

A vállalati adatbázisok sűrített (központosított) és terjesztik.

Koncentrált (centralizált) adatbázis egy olyan adatbázis, amelynek adatai fizikailag egy számítógép tárolóeszközein vannak tárolva. ábrán. Az 1.2. ábra egy kiszolgálóalkalmazás diagramját mutatja különböző platformokon adatbázisokhoz való hozzáféréshez.

1.2. ábra. Egy heterogén diagramja központi adatbázis

Az információfeldolgozás központosítása lehetővé tette a hagyományos ilyen hiányosságok kiküszöbölését fájlrendszerek mint inkoherencia, következetlenség és adatredundancia. Az adatbázisok növekedésével azonban, különösen, ha földrajzilag szétszórt szervezetekben használják őket, problémák merülnek fel. Például a távközlési hálózati csomópontban található koncentrált adatbázisok esetében, amelyeken keresztül a szervezet különböző részlegei hozzáférnek az adatokhoz, az információ mennyiségének és a tranzakciók számának növekedésével a következő nehézségek merülnek fel:

• Nagy adatcsere áramlás;
• Magas hálózati forgalom;
• Alacsony megbízhatóság;
• Alacsony általános teljesítmény.

Bár egy koncentrált adatbázisban könnyebben biztosítható az információk biztonsága, integritása és konzisztenciája a frissítések során, ezek a problémák bizonyos nehézségeket okoznak. E problémák lehetséges megoldásaként az adatok decentralizálását javasolják. A decentralizáció a következőket eredményezi:

• Magasabb fokú feldolgozási egyidejűség a terhelésmegosztás miatt;
• Távoli (távoli) lekérdezések végrehajtása során az adatok terepen történő felhasználásának javítása;
• alacsonyabb költségek;
• Könnyen kezelhető helyi adatbázisok.

A csomópontokon munkaállomásokkal (kis számítógépekkel) rendelkező hálózat létrehozásának költségei sokkal alacsonyabbak, mint egy hasonló rendszer nagyszámítógépes létrehozásának költségei. Az 1.3. ábra egy elosztott adatbázis logikai diagramját mutatja.

1.3. ábra. Elosztott vállalati adatbázis.

Az alábbi definíciót adjuk az elosztott adatbázisra.

Elosztott adatbázis - ez az információs hálózat különböző csomópontjain tárolt információk, fájlok (kapcsolatok) gyűjteménye, amelyek logikailag olyan módon kapcsolódnak egymáshoz, hogy egyetlen adathalmazt alkotjanak (a hivatkozás lehet funkcionális vagy ugyanazon fájl másolatain keresztül). Így ez logikailag összekapcsolt, de fizikailag több gépen elhelyezkedő adatbázisok halmaza, amelyek ugyanannak a számítógépes hálózatnak a részét képezik.

Az elosztott adatbázis jellemzőivel szemben támasztott legfontosabb követelmények a következők:

• Skálázhatóság;
• Kompatibilitás;
• Különféle adatmodellek támogatása;
• hordozhatóság;
• Helyszín átláthatósága;
• Az elosztott adatbázis csomópontok autonómiája (Site Autonomy);
• Elosztott kérések feldolgozása;
• Elosztott tranzakciók végrehajtása.
• Homogén biztonsági rendszer támogatása.

A hely átláthatósága lehetővé teszi a felhasználók számára, hogy anélkül dolgozzanak adatbázisokkal, hogy bármit is tudnának a helyükről. Az elosztott adatbázis csomópontok autonómiája azt jelenti, hogy minden adatbázis a többitől függetlenül karbantartható. Az elosztott lekérdezés olyan lekérdezés (SQL-utasítás), amely során különböző adatbázisok objektumaihoz (táblázataihoz vagy nézeteihez) jut hozzá. Az elosztott tranzakciók végrehajtásakor a párhuzamosság ellenőrzése minden érintett adatbázison érvényesül. Az Oracle7 kétfázisú információátviteli technológiát használ az elosztott tranzakciók végrehajtásához.

Az elosztott adatbázist alkotó adatbázisoknak nem kell homogéneknek lenniük (azaz ugyanazon DBMS-en futniuk), és nem kell ugyanazon az operációs rendszer környezetben és/vagy azonos típusú számítógépeken futniuk. Például az egyik adatbázis lehet egy Oracle adatbázis egy SUN OS(UNIX) operációs rendszert futtató SUN számítógépen, egy másik adatbázist egy DB2 DBMS futtathat MVS operációs rendszert futtató IBM 3090 nagyszámítógépen, és egy harmadik adatbázis futhat egy SQL/DS DBMS szintén IBM nagyszámítógépen, de VM operációs rendszerrel. Csak egy feltétel kötelező: minden adatbázissal rendelkező gépnek elérhetőnek kell lennie azon a hálózaton keresztül, amelynek része.

Az elosztott adatbázis fő feladata adatok elosztása a hálózaton és hozzáférés biztosítása azokhoz. A probléma megoldásának a következő módjai vannak:

• Minden csomópont tárolja és használja a saját adatkészletét, amely elérhető a távoli lekérdezésekhez. Ez az eloszlás megosztott.
• Egyes távoli helyeken gyakran használt adatok megkettőzhetők. Az ilyen eloszlást részben duplikáltnak nevezzük.
• Minden adat megduplázódik minden csomópontban. Az ilyen eloszlást teljesen redundánsnak nevezzük.
• Egyes fájlok feloszthatók vízszintesen (rekordok egy részhalmaza van kiválasztva) vagy függőlegesen (az attribútummezők egy részhalmaza van kiválasztva), míg a felosztott részhalmazok a fel nem osztott adatokkal együtt különböző csomópontokban tárolódnak. Az ilyen eloszlást splitnek (fragmentáltnak) nevezzük.

Elosztott adatbázis fogalmi szintű létrehozásakor a következő feladatokat kell megoldani:

• Egyetlen koncepcionális sémára van szükség az egész hálózatra. Ez biztosítja a logikai adatok átláthatóságát a felhasználó számára, aminek eredményeként egy külön terminálon (úgymond, központosított adatbázissal működik) a teljes adatbázisra tud kérést formálni.
• Sémára van szükség az adatok hálózaton történő megtalálásához. Ez átláthatóságot biztosít az adatelhelyezésben, így a felhasználónak nem kell megadnia, hogy hova továbbítsa a kérést a szükséges adatok megszerzéséhez.
• Meg kell oldani az elosztott adatbázisok heterogenitásának problémáját. Az elosztott adatbázisok hardver és szoftver tekintetében lehetnek homogének vagy heterogének. A heterogenitás problémája viszonylag könnyen megoldható, ha az elosztott adatbázis hardveresen heterogén, de szoftveresen homogén (ugyanaz a DBMS a csomópontokban). Ha egy elosztott rendszer csomópontjaiban különböző DBMS-eket használnak, akkor szükség van az adatstruktúrák és nyelvek átalakítására. Ez biztosítja az átalakítás átláthatóságát az elosztott adatbázis-csomópontokban.
• Meg kell oldani a szótárkezelés problémáját. Az elosztott adatbázisok mindenfajta átláthatóságának biztosításához számos szótárt és kézikönyvet kezelő programokra van szükség.
• Meg kell határozni a lekérdezések végrehajtásának metódusait egy elosztott adatbázisban. Az elosztott adatbázisokban a lekérdezések végrehajtásának módszerei eltérnek a központi adatbázisok hasonló módszereitől, mivel a lekérdezések egyes részeit a megfelelő adatok helyén kell végrehajtani, és a részeredményeket más csomópontokhoz kell továbbítani; ugyanakkor biztosítani kell az összes folyamat összehangolását.
• Meg kell oldani a lekérdezések párhuzamos végrehajtásának problémáját. Egy elosztott adatbázisban egy komplex mechanizmusra van szükség az egyidejű feldolgozás kezelésére, amelynek különösen az információfrissítéskor kell a szinkronizálást biztosítania, ami garantálja az adatok konzisztenciáját.
• Az elosztott adatbázisok egyik fő követelménye, hogy kidolgozott módszertanra van szükség az adatok elosztására és elhelyezésére, beleértve a felosztást is.

A számítógépes rendszerarchitektúra egyik aktívan fejlődő új területe, amely a nem numerikus információfeldolgozás hatékony eszköze adatbázis gépek. Az adatbázis-gépek nem numerikus feladatok megoldására szolgálnak, mint például dokumentumok, tények tárolása, keresése, átalakítása, objektumokkal végzett munka. Az adatnak a környező világ tárgyaira vonatkozó digitális és grafikus információként való definícióját követve a numerikus és nem numerikus feldolgozás során eltérő tartalom ágyazódik be az adatfogalomba. A numerikus feldolgozás olyan objektumokat használ, mint a változók, vektorok, mátrixok, többdimenziós tömbök, konstansok és így tovább, míg a nem numerikus feldolgozásban az objektumok lehetnek fájlok, rekordok, mezők, hierarchiák, hálózatok, kapcsolatok stb. A nem numerikus feldolgozásnál az objektumokkal kapcsolatos információk közvetlenül érdekeltek (például egy adott alkalmazott vagy alkalmazottak csoportja), nem önmagában az alkalmazottak aktája. Nem indexeli az alkalmazotti fájlt egy adott személy kiválasztásához; itt jobban érdekli a kívánt rekord tartalma. Hatalmas mennyiségű információt rendszerint nem numerikus feldolgozásnak vetnek alá. Különféle alkalmazásokban ilyen műveletek hajthatók végre ezekkel az adatokkal, például:

• növelje a vállalat összes alkalmazottjának fizetését;
• kiszámítja a banki kamatot minden ügyfél számlájára;
• módosítsa a raktáron lévő összes áru listáját;
• megtalálja a szükséges kivonatot a könyvtárban vagy a bibliográfiai információkereső rendszerben tárolt összes szövegből;
• keresse meg a kívánt szerződés leírását egy jogi dokumentumokat tartalmazó fájlban;
• tekintse meg a szabadalmak leírását tartalmazó összes fájlt, és keressen egy szabadalmat (ha van), amely hasonló az ismét javasolthoz.

Az adatbázis-motor megvalósítása, párhuzamos és asszociatív architektúrák az egyprocesszoros alternatívakéntvon Neumannstruktúra, amely lehetővé teszi, hogy valós időben dolgozzon nagy mennyiségű információval.

Az adatbázis gépek beszerzik fontosságát olyan mesterséges intelligencia fogalmak tanulmányozása és alkalmazása kapcsán, mint a tudásreprezentáció, szakértői rendszerek, következtetés, mintafelismerés stb.

Információs tárolók. Ma már sokan felismerik, hogy a legtöbb cég már több adatbázist üzemeltet, és az információkkal való sikeres munkához nemcsak különböző típusú adatbázisokra van szükség, hanem a DBMS-ek különböző generációira. A statisztikák szerint minden szervezet átlagosan 2,5 különböző DBMS-t használ. Nyilvánvalóvá vált az az igény, hogy a cégek üzletét, vagy inkább az ebben az üzletágban érintett embereket "elszigeteljék" az adatbázisok technológiai jellemzőitől, hogy a felhasználók egyetlen képet kaphassanak a vállalati információkról, függetlenül attól, hogy azokat fizikailag hol tárolják. . Ez ösztönözte az információs raktározási technológia megjelenését ( Data Warehousing, DW).

A DW fő célja az a különböző típusú adatbázisokban található adatok egyetlen logikai megjelenítése, vagy más szóval egyetlen vállalati adatmodell létrehozása.

A fejlesztésnek köszönhetően a DW fejlesztés új köre vált lehetővé információs technológiákáltalában, különösen a párhuzamos lekérdezések feldolgozásán alapuló új típusú adatbázisok megjelenése, amelyek viszont a párhuzamos számítógépek fejlődésére támaszkodtak. Létre lett hozva lekérdezésépítőkintuitív grafikus felülettel, amely megkönnyítette az összetett adatbázis-lekérdezések felépítését. Vegyes szoftverekköztes szoftverkommunikációt biztosítottkülönböző típusú adatbázisok között, és végül nagyot esett az árinformációtároló eszközök.

Egy adatbank jelen lehet a vállalati struktúrában.

Adatbázis Az automatizált vezérlőrendszerekben és az információs és számítástechnikai rendszerekben funkcionális és szervezeti komponens, amely központosított információs támogatást nyújt egy felhasználói csoport vagy a rendszerben megoldott feladatsor számára.

Adatbázis információs és referenciarendszernek minősül, amelynek fő célja:

• a teljes automatizált rendszer információs bázisát alkotó információhalmaz felhalmozása és működőképes állapotban tartása, vagy az abban megoldott feladatok egy része;
• a feladat, illetve a felhasználó által igényelt adatok kiadásában;
• a tárolt információkhoz való kollektív hozzáférés biztosítása;
• az infobázisban található információk felhasználásának szükséges kezelésének biztosításában.

A modern adatbank tehát egy komplex szoftver- és hardverkomplexum, amely magában foglalja a technikai, rendszer- és hálózati létesítmények, adatbázisok és DBMS, információ-visszakereső rendszerek különféle célokra.

V .2. DBMS ÉS STRUKTURÁLIS MEGOLDÁSOK VÁLLALATI RENDSZEREKBEN

Adatbázis- és tudásmenedzsment rendszerek

A modern információs rendszerek fontos összetevői az adatbázis-kezelő rendszerek (DBMS).

DBMS adatbázisok létrehozására, karbantartására és használatára tervezett szoftverek és nyelvi eszközök.

Az adatbázis-kezelő rendszer az adatfeldolgozó rendszerek számára biztosít hozzáférést az adatbázisokhoz. Mint már említettük, a DBMS fontos szerepet kap a vállalati információs rendszerek létrehozása során, és különösen fontos szerepet az elosztott információs rendszerek létrehozása során. információs források modern hálózati számítógépes technológiákra épül.

A modern DBMS fő jellemzője, hogy a modern DBMS olyan technológiákat támogat, mint:

• kliens/szerver technológia.
• Adatbázis-nyelvek támogatása. aztsémadefiníciós nyelv DB (SDL – Sémadefiníciós nyelv),adatmanipulációs nyelv (DML - Data Manipulation Language), integrált nyelvek SQL (Structured Queue Language), QDB (Lekérdezés - Példa szerint) és QMF (Query Management Facility) ) Fejlett perifériaeszköz a lekérdezések specifikációjához és a jelentéskészítéshez DB 2 stb.;
• Adatok közvetlen kezelése a külső memóriában.
• Memóriapuffer-kezelés.
• Tranzakciókezelés. OLTP technológia (On-Line Tranzakciófeldolgozás), OLAP technológia (On-line elemzés feldolgozás) a DW számára.
• Biztosítsa az adatvédelmet és az integritást. A rendszert csak az adatokhoz való hozzáférésre jogosult felhasználók használhatják. Amikor a felhasználók műveleteket hajtanak végre az adatokon, a tárolt adatok konzisztenciája (integritása) megmarad. Ez fontos a vállalati többfelhasználós információs rendszerekben.
• Újságírás.

A modern DBMS-eknek meg kell felelniük a fent felsorolt ​​adatbázis-követelményeknek. Ezenkívül meg kell felelniük a következő elveknek:

• Adatfüggetlenség.
• Sokoldalúság. A DBMS-nek hatékony eszközökkel kell rendelkeznie a koncepcionális adatmodell támogatásához az egyéni logikai nézetek megjelenítéséhez.
• Kompatibilitás. A DBMS-nek működőképesnek kell maradnia a szoftver- és hardverfejlesztés során.
• Adatredundancia. A fájlrendszerekkel ellentétben az adatbázisnak egyetlen integrált adatkészletből kell állnia.
• Adat védelem. A DBMS-nek védelmet kell nyújtania a jogosulatlan hozzáférés ellen.
• Adatok integritása. A DBMS-nek meg kell akadályoznia, hogy a felhasználók manipulálják az adatbázist.
• Egyidejű munka irányítása. A DBMS-nek meg kell védenie az adatbázist a megosztott hozzáférési mód inkonzisztenciáitól. Az adatbázis konzisztens állapotának biztosítása érdekében minden felhasználói kérést (tranzakciót) meghatározott sorrendben kell végrehajtani.
• A DBMS-nek univerzálisnak kell lennie. Támogatnia kell különböző modellek adatok egyetlen logikai és fizikai alapon.
• A DBMS-nek támogatnia kell mind a központosított, mind az elosztott adatbázisokat, és ezáltal a számítógépes hálózatok fontos láncszemévé kell válnia.

Ha a DBMS-t olyan szoftvertermékek osztályának tekintjük, amelyek az adatbázisok automatizált rendszerekben való karbantartására összpontosítanak, megkülönböztethetünk két legfontosabb jellemzőt, amelyek meghatározzák a DBMS típusait. Szerintük a DBMS-t két szempontból lehet vizsgálni:

• az elosztott (vállalati) adatbázisokkal kapcsolatos képességeiket;
• kapcsolatuk a DBMS-ben megvalósított adatmodell típusával.

A vállalati (elosztott) adatbázisokkal kapcsolatban hagyományosan a következő típusú DBMS-eket lehet megkülönböztetni:

• DBMS "asztal". Ezek a termékek elsősorban a személyes adatokkal (asztali adatokkal) való munkavégzésre összpontosítanak. Vannak parancskészleteik a közös adatbázisok megosztására, de kis méretűek (kis irodai típus). Először is, ez egy olyan DBMS, mint az Access, dBASE, Paradox, ExPro. Miért fér hozzá rosszul az Access, a dBASE, a Paradox és az ExPro a vállalati adatokhoz? A tény az, hogy nincs egyszerű módja a személyes és a vállalati adatok közötti akadály leküzdésének. És a lényeg nem is az, hogy a személyes adatok DBMS (vagy egy kis iroda) mechanizmusa arra irányul, hogy sok átjárón, átjáró terméken stb. A probléma az, hogy ezek a mechanizmusok jellemzően teljes fájlátvitelt és a kiterjedt indextámogatás hiányát foglalják magukban, ami a kiszolgálóhoz vezető sorokat eredményez, amelyek gyakorlatilag leállnak a nagy rendszerekben.
• Speciális, nagy teljesítményű többfelhasználós DBMS. Az ilyen DBMS-eket egy többfelhasználós rendszermag, egy adatkezelési nyelv és a következő, a kifejlesztett többfelhasználós DBMS-ekre jellemző funkciók jellemzik:
• puffertár szervezése;
• a tranzakciós sorokat feldolgozó rendszer megléte;
• a többfelhasználós adatok blokkolására szolgáló mechanizmusok jelenléte;
• tranzakciónaplózás;
• hozzáférés-ellenőrzési mechanizmusok elérhetősége.

Ezek az olyan DBMS-ek, mint az Oracle, DВ2, SQL/Server, Informix, Sybase, ADABAS, Titanium és mások, amelyek széles körű szolgáltatást nyújtanak a vállalati adatbázisok feldolgozásához.

Az adatbázisokkal való munka során a tranzakciók mechanizmusát használják.

tranzakció a munka logikai egysége.

tranzakció adatkezelési utasítások sorozata, amely végrehajtódikmint az egyik(mindent vagy semmit) és az adatbázis fordításátegyik integrál állapotból egy másik integrál állapotba.

Egy tranzakciónak négy fontos tulajdonsága van, amelyek ASID tulajdonságokként ismertek:

• (A) Atomosság . A tranzakció atomi műveletként kerül végrehajtásra - vagy a teljes tranzakció végrehajtásra kerül, vagy a teljes tranzakció nem.
• (C) Konzisztencia. Egy tranzakció áthelyezi az adatbázist az egyik konzisztens (konzisztens) állapotból egy másik konzisztens (konzisztens) állapotba. Egy tranzakción belül megtörhet az adatbázis konzisztenciája.
• (I) Izoláció . A különböző felhasználók tranzakciói nem zavarhatják egymást (például mintha szigorúan egymás után hajtanák végre).
• (D) Tartósság. Ha a tranzakció befejeződött, akkor a munka eredményét el kell menteni az adatbázisba, még akkor is, ha a következő pillanatban a rendszer összeomlik.

A tranzakció általában automatikusan elindul attól a pillanattól kezdve, amikor a felhasználó csatlakozik a DBMS-hez, és addig tart, amíg a következő események egyike meg nem történik:

• COMMIT WORK parancsot adtak ki (tranzakció véglegesítésére).
• ROLLBACK WORK parancs kiadva.
• A felhasználó megszakadt az adatbázis-kezelő rendszertől.
• Hiba történt a rendszerben.

A felhasználó számára általában visel atomi karakter. Valójában ez a felhasználó (alkalmazás) és az adatbázis közötti interakció összetett mechanizmusa. A vállalati rendszerszoftverek valós idejű tranzakciófeldolgozó motort használnak (Online tranzakciófeldolgozó rendszerek, OLTP), különösen a számviteli programok, az ügyfélalkalmazások fogadására és feldolgozására szolgáló szoftverek, a pénzügyi alkalmazások, sok információt állítanak elő. Ezeket a rendszereket nagy mennyiségű adat, összetett tranzakciók és intenzív olvasási/írási műveletek feldolgozására tervezték (és megfelelően optimalizálták).

Sajnos az OLTP rendszerek adatbázisaiban elhelyezett információk nem túl alkalmasak a hétköznapi felhasználók általi használatra (a nagyfokú táblanormalizáció, a specifikus adatmegjelenítési formátumok és egyéb tényezők miatt). Ezért a különböző információs csővezetékekből származó adatok elküldésre kerülnek (másolás értelmében). tároló raktár, válogatás és utólagos kiszállítás a fogyasztóhoz. Az információtechnológiában a raktárak szerepét ainformációtárolók.

Információk eljuttatása a végfelhasználóhoz - valós idejű analitikai adatfeldolgozási rendszerek vesznek részt (On-line Analytical Processing, OLAP), amelyek rendkívül egyszerű hozzáférést biztosítanak az adatokhoz a lekérdezések generálására és az eredmények elemzésére szolgáló kényelmes eszközökön keresztül. Az OLAP rendszerekben az információs termék értékét különféle elemzési és statisztikai feldolgozási módszerek alkalmazásával növelik. Ezen túlmenően ezek a rendszerek az adatkinyerési sebesség, az általánosított információk gyűjtése szempontjából optimalizáltak, és a hétköznapi felhasználókra összpontosítanak (intuitív felülettel rendelkeznek). Ha egy OLTP rendszer választ ad olyan egyszerű kérdésekre, mint "mi volt az N termék értékesítési szintje az M régióban 199x januárban?", majd OLAP rendszerek készen állnak az összetettebb felhasználói kérésekre, például: "Elemezze az N termék értékesítését minden régióban a második negyedévi terv szerint az előző két évhez képest."

Kliens/szerver architektúra

A modern rendszerekben elosztott információfeldolgozástechnológia kerül a középpontba kliens/szerver. Rendszerben kliens-szerver architektúrákaz adatfeldolgozás megoszlik egy kliens számítógép és egy szerver számítógép között, amelyek között a kommunikáció hálózaton keresztül történik. Az adatfeldolgozási folyamatok ezen szétválasztása a funkciók csoportosításán alapul. Általában az adatbázis-kiszolgáló számítógép az adatbázis-műveletek végrehajtására szolgál, míg az ügyfélszámítógép alkalmazási programokat futtat. A 2.1. ábra egy egyszerű kliens-szerver architektúra rendszert mutat be, amely egy kiszolgálóként működő számítógépet és egy másik számítógépet tartalmaz, amely kliensként működik. Minden gép más-más funkciókat lát el és saját erőforrásokkal rendelkezik.

		Adatbázis
Szerver számítógép
Háló
IBM kompatibilis PC	IBM kompatibilis PC	IBM kompatibilis PC
		Alkalmazások

Rizs. 2.1. Kliens-szerver architektúra rendszer

A kliens számítógép fő funkciója az alkalmazás futtatása (felhasználói felület és prezentációs logika) és kommunikáció a szerverrel, amikor az alkalmazás megköveteli.

szerver ez egy objektum (számítógép), amely szolgáltatásokat nyújt más objektumok kérésére.

Ahogy a kifejezés is sugallja, a szerver számítógép fő funkciója a kliens igényeinek kiszolgálása. A "szerver" kifejezés két különböző funkciócsoportra vonatkozik: egy fájlkiszolgálóra és egy adatbázis-kiszolgálóra (a továbbiakban ezek a kifejezések a kontextustól függően vagy az ezeket a funkciócsoportokat megvalósító szoftvereket, vagy az ezzel a szoftverrel rendelkező számítógépeket jelentik. ). A fájlszervereket nem adatbázis-műveletek elvégzésére tervezték, fő funkciójuk a fájlok több felhasználó közötti megosztása, pl. több felhasználó egyidejű hozzáférésének biztosítása a számítógépen lévő fájlokhoz - fájlszerver. Fájlkiszolgálóra példa a Novell NetWare operációs rendszere. Az adatbázis-kiszolgáló telepíthető és futtatható fájlkiszolgáló számítógépen. Az NLM (Network Loadable Module) formájú Oracle DBMS NetWare környezetben fut egy fájlkiszolgálón.

szerver helyi hálózat funkcionális céljának és hálózati igényeinek megfelelő erőforrásokkal kell rendelkeznie. Vegyük észre, hogy a nyílt rendszerek megközelítésére való orientáció miatt helyesebb logikai szerverekről (az erőforrások és az ezeken az erőforrásokon keresztül szolgáltatásokat nyújtó szoftvereszközök halmazáról) beszélni, amelyek nem feltétlenül különböző számítógépeken helyezkednek el. Nyílt rendszerben a logikai szerver sajátossága, hogy ha hatékonysági okokból célszerű a szervert külön számítógépre költöztetni, akkor ez minden változtatás nélkül megtehető, mind önmagában, mind az alkalmazásban. az azt használó programok.

Az egyik fontos szerverkövetelmény, hogy az operációs rendszernek, amelyben az adatbázis-kiszolgáló található, többfeladatosnak kell lennie (és lehetőleg, de nem feltétlenül többfelhasználósnak). Például az MS-DOS (vagy PC-DOS) operációs rendszerrel rendelkező személyi számítógépre telepített Oracle DBMS, amely nem felel meg a multitasking követelményeinek, nem használható adatbázis-kiszolgálóként. És ugyanaz az Oracle DBMS, amely többfeladatos (bár nem többfelhasználós) OS / 2 operációs rendszerrel rendelkező számítógépre telepítve lehet adatbázis-kiszolgáló. Sok fajta UNIX rendszerek, MVS, VM és néhány más operációs rendszer egyszerre többfeladatos és többfelhasználós.

Elosztott számítástechnika

Az "elosztott számítástechnika" kifejezést gyakran használják két különböző, bár egymást kiegészítő fogalomra:

• Elosztott adatbázis;
• Elosztott adatfeldolgozás.

Ezen koncepciók alkalmazása lehetővé teszi a több gépen tárolt információkhoz való hozzáférés különböző eszközökkel történő megszervezését a végfelhasználók számára.

Sokféle szerver létezik:

• Adatbázis szerver;
• Nyomtatószerver;
• Távoli hozzáférési szerver;
• Fax szerver;
• Webszerver stb.

A kliens/szerver technológia magja Vannak olyan alapvető technológiák, mint:

• Operációs rendszerek technológiái, nyílt rendszerek interakciójának fogalma, objektum-orientált környezetek létrehozása a programok működéséhez;
• Távközlési technológiák;
• Hálózati technológiák;
• Grafikai technológiák felhasználói felület ( GUI);
• Stb.

A kliens-szerver technológia előnyei:

• A kliens/szerver technológia lehetővé teszi a számítást heterogén számítási környezetekben. Platformfüggetlenség: Hozzáférés heterogén hálózati környezetekhez, amelyek különböző típusú számítógépeket tartalmaznak különböző operációs rendszerekkel.
• Függetlenség az adatforrásoktól: hozzáférés heterogén adatbázisokból származó információkhoz. Ilyen rendszerek például a DB2, SQL/DS, Oracle, Sybase.
• Terhelési egyensúly a kliens és a szerver között.
• Számítások elvégzése ott, ahol az a leghatékonyabban történik;
• Hatékony skálázási képességet biztosít;
• Platformos számítástechnika. A többplatformos számítástechnikát egyszerűen úgy definiálják, mint a technológiák heterogén számítási környezetekben való megvalósítását. Itt a következő lehetőségeket kell megadni:
• Az alkalmazásnak több platformon kell futnia;
• Minden platformon azonos felülettel és működési logikával kell rendelkeznie;
• Az alkalmazásnak integrálódnia kell a natív operációs környezetbe;
• Minden platformon ugyanúgy kell viselkednie;
• Egyszerű és következetes támogatással kell rendelkeznie.

 Elosztott számítástechnika. Az elosztott számítástechnika magában foglalja a munka több számítógép közötti elosztását (bár az elosztott számítástechnika tágabb fogalom).

 Lekicsinyítés. A nagyszámítógépes alkalmazások portolásának lekicsinyítése kis számítási platformokra.

• Csökkentse az infrastruktúra és a hardver költségeit. Költséghatékony: Az olcsó számítástechnikai hardver elérhetősége és a helyi hálózatok növekvő elterjedése költséghatékonyabbá teszi a kliens-szerver technológiát, mint más adatfeldolgozási technológiák. A berendezés igény szerint bővíthető.

 Az alkalmazás teljes végrehajtási idejének csökkentése;

 Csökkentett kliens memóriahasználat;

 A hálózati forgalom csökkentése.

• Képesség multimédiával való munkavégzéshez: A mai napig számos programot hoztak létre a számítógépes multimédiával való munkavégzéshez. Vagy nincsenek ilyen programok a terminál-gazda konfigurálásához, vagy nagyon drágák.
• Több számítási erőforrás használatának lehetősége adatbázis-műveletekhez: mivel az alkalmazások ügyfélszámítógépeken futnak, a kiszolgáló számítógépen további erőforrások szabadulnak fel (a terminál-gazda konfigurációhoz képest) az adatbázis-műveletekhez, mint például a CPU és a működési erőforrások.
• Fokozott programozói termelékenység: A programozók termelékenységét növeli, ha olyan eszközöket használnak, mint az SQL*Forms és a CASE, hogy gyorsabban fejleszthessenek alkalmazásokat, mint az olyan programozási nyelvek, mint a C, PL1 vagy COBOL.
• A végfelhasználói termelékenység növelése: Manapság sok végfelhasználó olyan rendszereket fogadott el, mint a Lotus, a Paradox, a Word Perfect, a Harvard Graphics stb.

A háttérfelület definiált és rögzített. Ezért lehetőség van egy meglévő rendszer új kliensrészeinek létrehozására (példa a rendszerszintű interoperabilitásra).

Rizs. 2.2. A kliens szervermegosztáshoz való hozzáférésének illusztrációja.

A kliens-szerver technológia megvalósítása

Az alábbiakban egy kliens-szerver technológián alapuló, elosztott adatfeldolgozásra képes rendszer telepítését tárgyaljuk. A következő számítógépes hardver és szoftver szükséges:

• adatbázis szerver számítógép;
• kliens számítógépek;
• kommunikációs hálózat;
• hálózati szoftverek;
• alkalmazás szoftver.

SQL nyelv . Magas szintű lekérdezési nyelv - SQL (strukturált lekérdezési nyelv ) adatbázis-lekérdezések megvalósítására szolgál, mint például az NMD, NDL és PJD, és szabványként fogadták el. Nyelv SQL eredetileg a cég szoftvertermékeinek adatnyelveként fogadták el IBM és egy relációs DBMS YMD-je SYSTEM R az IBM-től . A nyelv fontos jellemzője SQL ugyanazt a nyelvet két különböző interfészen keresztül reprezentálják, nevezetesen: egy interaktív felületen és egy alkalmazásprogramozási felületen keresztül (dinamikus SQL). Dinamikus SQL számos beépített nyelvi szolgáltatásból áll SQL , amely kifejezetten interaktív alkalmazások létrehozására szolgál, ahol az interaktív alkalmazás egy olyan program, amely az interaktív terminálon futó végfelhasználó adatbázishoz való hozzáférését támogatja. Nyelv SQL biztosítja az adatbázis adatok meghatározásának, manipulálásának és kezelésének funkcióit, és átlátható a felhasználó számára a megvalósított DBMS szempontjából.

Rizs. 2.3. Az elosztott adatbázisokhoz intézett felhasználói kérések végrehajtásának sémája.

Az adatbázisok belső szerkezetét az alkalmazott adatmodellek határozzák meg. A koncepcionális modell több absztrakciós képességgel és gazdagabb szemantikával rendelkezik, mint a külső modellek. Külső modellek gyakran szintaktikai vagy működési modelleknek nevezik, utalva a menedzsment és az alkalmazás szintaktikai természetére, mint az adatbázissal való felhasználói interakció eszközére. Az információs modellezésben az absztrakciónak különböző szintjei vannak, a fogalmi modell szintjétől a fizikai adatmodell szintjéig, amelyek befolyásolják a DBMS architektúráját.

Az adatmodell három összetevőből áll:

• Adatstruktúra, amely a felhasználó szemszögéből ábrázolható az adatbázisban.
• Az adatstruktúrán végrehajtandó érvényes műveletek. Ezzel a struktúrával különféle DDL és NML műveletek segítségével kell tudni dolgozni. A gazdag struktúra mit sem ér, ha a tartalmát nem tudod manipulálni.
• Az integritás ellenőrzésének megkötései. Az adatmodellt olyan eszközökkel kell ellátni, amelyek megőrzik integritását és védik. Példaként vegye figyelembe a következő két megszorítást:
• Minden részfának rendelkeznie kell egy forráscsomóponttal. A hierarchikus adatbázisok nem tárolhatnak utódcsomópontokat szülőcsomópont nélkül.
• Egy relációs adatbázissal kapcsolatban nem lehetnek azonos sorok. Egy fájl esetében ez a követelmény megköveteli, hogy minden rekord egyedi legyen.

Az egyik a legfontosabb jellemzőket A DBMS-munka az objektumok összekapcsolásának képessége.

A következő típusú hivatkozások léteznek az objektumok között:

• Egy az egyhez (1:1). Egy halmaz egyik objektuma társítható egy másik halmaz egyik objektumához.
• Egy a sokhoz (1:M). Egy halmaz egy objektuma egy másik halmaz sok objektumához kapcsolódhat.
• Sok a sokhoz (M:N). Egy halmaz egy objektuma társítható egy másik halmaz sok objektumához, ugyanakkor egy másik halmaz egyik objektuma az első halmaz sok objektumához társítható.
• elágazó . Egy halmaz egy objektuma több halmaz objektumához is társítható.
• Rekurzív . Egy tárgy adott készlet társítható ugyanazon halmaz objektumához.

A következő fő adatmodellek léteznek:

• Relációs adatmodell.
• Hierarchikus adatmodell.
• Hiányos hálózati adatmodell.
• CODASYL adatmodell.
• Kiterjesztett hálózati adatmodell.

V.3. INTERNET / INTRANET TECHNOLÓGIÁK ÉS VÁLLALATI ADATBÁZIS HOZZÁFÉRÉSI MEGOLDÁSOK

A "kliens-szerver" architektúrára épülő rendszerek fő problémája, hogy a nyílt rendszerek koncepciójának megfelelően mobilnak kell lenniük a nyílt rendszerek hardver- és szoftvermegoldások lehető legszélesebb osztályában. Még ha a UNIX-alapú helyi hálózatokra korlátozzuk is magunkat, a különböző hálózatok eltérő berendezéseket és kommunikációs protokollokat használnak. Az összes lehetséges protokollt támogató rendszerek létrehozásának kísérlete túlterheli a hálózat részleteit a funkcionalitás rovására.

A probléma még összetettebb aspektusa azzal a lehetőséggel kapcsolatos, hogy egy heterogén helyi hálózat különböző csomópontjaiban különböző adatábrázolásokat lehet használni. A különböző számítógépeken eltérő címzés, számábrázolás, karakterkódolás stb. lehet. Ez különösen fontos a magas szintű szervereknél: telekommunikáció, számítástechnika, adatbázisok.

Általános megoldás A „kliens-szerver” architektúrán alapuló rendszerek mobilitási problémája a távoli eljáráshívási protokollokat (RPC – Remote Procedure Call) megvalósító szoftvercsomagokra való támaszkodás. Ezekkel az eszközökkel egy szolgáltatás hívása a távoli gazdagépen úgy néz ki, mint egy normál eljáráshívás. Az RPC eszközök, amelyek természetesen tartalmaznak minden információt a helyi hálózati berendezések és a hálózati protokollok sajátosságairól, a hívást hálózati interakciók sorozatává alakítják át. Így a hálózati környezet és a protokollok sajátosságai el vannak rejtve az alkalmazásprogramozó elől.

Távoli eljárás hívásakor az RPC-programok a kliens adatformátumokat köztes, gépfüggetlen formátumokká alakítják, majd kiszolgáló adatformátumokká. A válaszparaméterek átadásakor hasonló átalakításokat hajtanak végre.

Egyéb kapcsolódó munkák, amelyek érdekelhetik.vshm>
6914.		Adatbázis koncepció	11,56 KB
	Az adatbázis olyan független anyagok készlete, amelyeket a bírósági határozatok normatív aktusai és más hasonló anyagok számítási cikkeinek objektív formájában mutatnak be, oly módon rendszerezve, hogy ezek az anyagok megtalálhatók és feldolgozhatók az Orosz Föderáció Polgári Törvénykönyve elektronikus számítógép segítségével. Művészet. Egy bizonyos szabályok szerint szervezett és a számítógép memóriájában karbantartott adatbázis, néhány ...
8064.		Elosztott adatbázisok	43,66 KB
	Elosztott adatbázisok Az elosztott RDB adatbázis logikailag összekapcsolt megosztott adatok halmaza, amely fizikailag el van osztva a számítógépes hálózat különböző csomópontjain. Az adatokhoz való hozzáférés nem függhet az adatreplikák meglététől vagy hiányától. A rendszernek automatikusan meg kell határoznia az adatcsatlakozás végrehajtásának módszereit, egy hálózati kapcsolatot, amely képes kezelni az átvitt információ mennyiségét, és egy csomópontot, amely elegendő feldolgozási teljesítménnyel rendelkezik a táblák összekapcsolásához. Az RDBMS-nek képesnek kell lennie...
20319.		ADATBÁZISOK ÉS VÉDELMÜK	102,86 KB
	Az online online adatbázisok az 1960-as évek közepén jelentek meg. Az operatív adatbázisokon végzett műveletek feldolgozása interaktívan, terminálok segítségével történt. Az egyszerű index-szekvenciális rekordszervezés gyorsan egy erősebb halmazorientált rekordmodellré fejlődött. Charles Bachmann Turing-díjat kapott a Data Base Task Group (DBTG) munkájának vezetéséért, amely szabványos nyelvet fejlesztett ki az adatok leírására és az adatok manipulálására.
5031.		Adatbázis-fejlesztési könyvtár	11,72 MB
	Adatbázis tervezési technológia. Entitások közötti kapcsolatok meghatározása és adatmodell létrehozása. A modern információs technológia főbb gondolatai azon a felfogáson alapulnak, hogy az adatokat adatbázisokba kell rendezni, hogy megfelelően tükrözzék a változó valós világot, és kielégítsék a felhasználók információs igényeit. Ezeket az adatbázisokat speciális készítik és üzemeltetik szoftverrendszerek DBMS adatbázis-kezelő rendszereknek nevezik.
13815.		HIERARCHIKAI ADATBÁZIS MODELL	81,62 KB
	A modern információtechnológia főbb elképzelései az adatbázisok koncepcióján alapulnak, amely szerint az információtechnológia alapját olyan adatbázisokba rendezett adatok képezik, amelyek megfelelően tükrözik az adott témakör állapotát, és releváns információkkal látják el a felhasználót ebben a témakörben. Tudomásul kell venni, hogy az adatok...
14095.		Könyvtári adatbázis fejlesztés	11,72 MB
	A tárolt adatok mennyiségének és szerkezeti összetettségének növekedése, az információs rendszerek felhasználói körének bővülése a legkényelmesebb és viszonylag könnyen érthető relációs (táblázatos) DBMS elterjedéséhez vezetett.
5061.		Poliklinikai adatbázis létrehozása	2,4 MB
	A számítástechnika és az informatika fejlődése lehetőséget teremtett a különféle célú automatizált információs rendszerek (AIS) létrehozására és széles körű alkalmazására. A gazdasági és műszaki létesítmények kezelésére szolgáló információs rendszerek fejlesztése és bevezetése folyamatban van
13542.		Földtani információs adatbázisok	20,73 KB
	Nemrég volt egy gyors bevezetés számítógépes technológiaés különösen adatbázisok a tudomány területén. Ez a folyamat a geológiát sem kerüli meg, hiszen a természettudományokban van szükség nagy mennyiségű információ tárolására és feldolgozására.
9100.		Adatbázis. Alapfogalmak	26,28 KB
	Az adatbázis a valós világ adott tárgyaira vonatkozó információk gyűjteménye bármely tárgykörben, közgazdaságtanban, menedzsmentben, kémiában stb. Az információs rendszer célja nem csupán az objektumokról szóló adatok tárolása, hanem az adatok manipulálása is. figyelembe veszi az objektumok közötti kapcsolatokat. Minden objektumot valamilyen adattulajdonság-készlet jellemez, amelyeket az adatbázisban attribútumoknak nevezünk.
5240.		Az "Egyetemi Dékáni Hivatal" adatbázis létrehozása	1,57 MB
	Az adatbázis (DB) egymással összefüggő adatok gyűjteménye, amelyeket egy számítógép külső adathordozóján tárolnak együtt, olyan szervezettel és minimális redundanciával, amely lehetővé teszi azok optimális felhasználását egy vagy több alkalmazás számára.

Az előadás célja

Az előadás anyagának tanulmányozása után tudni fogja:

• mit vállalati adatmodell ;
• hogyan kell átalakítani vállalati adatmodell az adattárház modellbe;
• fő elemei vállalati adatmodell ;
• a vállalati adatmodell bemutatási rétegei ;
• algoritmus egy vállalati adatmodell többdimenziós adattárházmodellvé alakításához ;

és tanulni:

• alapján dolgozzon ki adattárházi modelleket vállalati adatmodell szervezetek;
• csillagsémát fejleszteni a CASE eszközök segítségével;
• partíciós táblák többdimenziós modell CASE eszközök használatával.

Vállalati adatmodell

Bevezetés

Minden adattárház magja az adatmodell. Adatmodell nélkül nagyon nehéz lesz az adatokat rendszerezni egy adattárházban. Ezért a DW-fejlesztőknek időt és erőfeszítést kell fordítaniuk egy ilyen modell kifejlesztésére. A HD-modell fejlesztése a CD-tervező vállára esik.

Az OLTP rendszerek tervezésével összevetve az adattárház tervezésének módszertana számos megkülönböztető tulajdonsággal rendelkezik, amelyek a tárolási adatstruktúráknak a döntéshozatali folyamat elemzési és információtámogatási problémáinak megoldására való orientációjával kapcsolatosak. Az adattárház adatmodelljének hatékony megoldást kell nyújtania ezekre a problémákra.

Az adattárház tervezésénél kiindulópont lehet az ún vállalati adatmodell(vállalati adatmodell vagy vállalati adatmodell, EDM), amely egy szervezet OLTP-rendszereinek tervezése során jön létre. Tervezéskor vállalati adatmodelláltalában az üzleti működés alapján próbálnak olyan adatstruktúrát létrehozni, amely összegyűjti és szintetizálja a szervezet összes információszükségletét.

Ily módon vállalati adatmodell tartalmazza a DW modell felépítéséhez szükséges információkat. Ezért az első szakaszban, ha létezik ilyen modell a szervezetben, egy adattárház tervező egy átalakítási probléma megoldásával kezdheti meg az adattárház tervezését vállalati adatmodell HD modellben.

Vállalati adatmodell

Hogyan lehet megoldani a konverziós problémát vállalati adatmodell HD modellben? A probléma megoldásához rendelkeznie kell ezzel a modellel, pl. vállalati adatmodell meg kell építeni és dokumentált. És meg kell értened mit ebből a modellből és hogyan HD modellre kell alakítani.

Tisztázzuk a fogalmat vállalati adatmodell. Alatt vállalati adatmodell megérteni a szervezet tárgyköreinek többszintű, strukturált leírását, a tantárgyi területek adatstruktúráit, az üzleti folyamatokat és az üzleti eljárásokat, a szervezetben alkalmazott adatfolyamokat, állapotdiagramokat, adatfolyamat-mátrixokat és egyéb modell-reprezentációkat, amelyeket a rendszerben használnak. a szervezet tevékenységét. Így tágabb értelemben vállalati adatmodell különböző szintű modellek összessége, amelyek jellemzik (valamilyen elvont szinten modelleznek) a szervezet tevékenységét, azaz. tartalom vállalati modell közvetlenül függ attól, hogy egy adott szervezetben milyen modellstruktúrák kerültek bele.

Főbb elemek vállalati adatmodell vannak:

• a szervezet témaköreinek leírása (tevékenységi területek meghatározása);
• a fent meghatározott tématerületek közötti kapcsolatok;
• információs adatmodell (ERD-modell vagy "entitás-kapcsolat" modell);
• minden témakör leírásához:
  • entitáskulcsok;
  • entitás attribútumok;
  • altípusok és szupertípusok;
  • entitások közötti kapcsolatok;
  • attribútum-csoportosítások;
  • a tantárgyi területek közötti kapcsolatok;
• funkcionális modell vagy üzleti folyamat modell;
• adatfolyam diagramok;
• állapotdiagramok;
• egyéb modellek.

Ily módon vállalati adatmodell olyan entitásokat, attribútumokat és kapcsolatokat tartalmaz, amelyek a szervezet információs igényeit képviselik. ábrán. 16.1 mutatja a fő elemeket vállalati adatmodell.

A vállalati adatmodell bemutatási rétegei

A vállalati adatmodell tantárgyi területek szerint van felosztva, amelyek konkrét üzleti igények támogatásához kapcsolódó entitáscsoportokat képviselnek. Egyes témakörök konkrét üzleti funkciókat, például szerződéskezelést fedhetnek le, mások pedig termékeket vagy szolgáltatásokat leíró entitásokat csoportosíthatnak.

Minden logikai modellnek meg kell felelnie egy létező témakörnek vállalati adatmodell. Ha a logikai modell nem felel meg ennek a követelménynek, akkor hozzá kell adni egy, a tárgyterületet meghatározó modellt.

Egy vállalati adatmodell általában több megjelenítési rétegből áll. Tulajdonképpen magas szint(magas szint) vállalati adatmodell található a szervezet főbb tématerületeinek és ezek entitásszintű kapcsolatainak leírása. ábrán. A 16.2 egy töredék vállalati adatmodell legmagasabb szint.

Rizs. 16.2.

Az ábrán látható diagram négy témakört mutat be: "Ügyfél" ( vevő), "Jelölje be" ( fiókot), "Rendelés" ( rendelés) és "Termék" ( termék). Általában csak a modellnézet legfelső szintjén közvetlen kapcsolatokat tárgykörök között, amelyek például a következő tényt rögzítik: a vevő fizeti az árurendelés számláját. Részletes információk és közvetett kapcsolatok ezen a szinten vállalati modell nem adják meg.

A következőn középszint(középszint) vállalati adatmodell részletes információkat jelenít meg a tématerületek tárgyairól, azaz a kulcsokról és entitás attribútumok, kapcsolataik, al- és szupertípusaik stb. A legfelső szintű modell minden tartományához tartozik egy középszintű modell. ábrán. A 16.3 a bemutatás középső szintjét ábrázolja vállalati modell a „Megrendelés” tárgykör töredékéhez.

ábrából. 16.3 látható, hogy a "Megrendelés" tárgykörben ( rendelés) több entitást tartalmaz, amelyek attribútumaikon és a köztük lévő kapcsolatokon keresztül határozhatók meg. A bemutatott modell lehetővé teszi olyan kérdések megválaszolását, mint például a megrendelés dátuma, ki készítette a rendelést, ki küldte a megrendelést, ki kapja meg a rendelést és még számos más kérdés. A fenti diagramból látható, hogy ebben a szervezetben kétféle megrendelés létezik - reklámkampány rendelés ( Kereskedelmi) és kiskereskedelmi rendelések ( Kiskereskedelem).

vegye észre, az vállalati adatmodell a szervezet tevékenységének különböző aspektusait, különböző részletességgel és teljességgel reprezentálhatja. Ha egy vállalati modell a szervezet minden aspektusát képviseli, más néven szervezeti adatmodell(vállalati adatmodell).

Az adattárház tervezése szempontjából fontos tényező annak eldöntésében, hogy egy adattárház modellt vállalati adatmodell az állam teljesség vállalati adatmodell.

A szervezet vállalati adatmodellje evolúciós jellemzővel rendelkezik, pl. folyamatosan fejlődik és javul. Néhány témakör vállalati adatmodell lehet, hogy jól kidolgozott, egyeseknél a munka még el sem kezdődött. Ha a tárgyterület egy töredéke nincs kidolgozva vállalati adatmodell, akkor nincs mód arra, hogy ezt a modellt adattárház tervezésének kiindulópontjaként használjuk.

Elkészítési fok vállalati modell a HD kialakításában az alábbiak szerint lehet szintezni. Mivel egy adattárház fejlesztési folyamata általában időben több szakaszra oszlik, tervezésének folyamata szinkronizálható a befejezési folyamat az egyes töredékek fejlődése vállalati adatmodell szervezetek.

A legalacsonyabbon a vállalati adatmodell bemutatási rétege a megfelelő adatbázis-objektumok fizikai jellemzőiről jelenít meg információkat logikai adatmodell középső a vállalati adatmodell bemutatási rétege.

Az informatikai szakemberek egyre inkább az iparági szabványos adatmodelleken és üzleti döntési sablonokon alapuló adatkezelési megoldások felé fordítják figyelmüket. A betöltésre kész összetett fizikai adatmodellek és az üzleti intelligencia jelentések meghatározott tevékenységi területekre lehetővé teszik a vállalat információs összetevőinek egységesítését és az üzleti folyamatok jelentős felgyorsítását. A megoldássablonok lehetővé teszik a szolgáltatók számára, hogy kihasználják a meglévő rendszerekben rejtett, nem szabványos információk erejét, ezáltal csökkentve a projektek ütemezését, költségeit és kockázatait. Például a valós projektek azt mutatják, hogy az adatmodell és az üzleti döntési sablonok 50%-kal csökkenthetik a fejlesztési erőfeszítéseket.

Az iparági logikai modell egy tartomány-specifikus, integrált és logikusan strukturált nézet minden olyan információról, amelynek a vállalati adattárházban kell lennie ahhoz, hogy megválaszolja mind a stratégiai, mind a taktikai üzleti kérdéseket. A modellek fő célja, hogy megkönnyítsék az adattérben való tájékozódást és segítsenek kiemelni az üzletfejlesztés szempontjából fontos részleteket. A mai üzleti környezetben elengedhetetlen a különböző összetevők közötti kapcsolatok világos megértése és a szervezet átfogó képének megfelelő megértése. Az összes részlet és kapcsolat modellek segítségével történő azonosítása lehetővé teszi az idő és az eszközök leghatékonyabb felhasználását a vállalati munkaszervezéshez.

Az adatmodellek olyan absztrakt modellek, amelyek leírják az adatok megjelenítését és elérését. Az adatmodellek egy adott területen adatelemeket és a köztük lévő kapcsolatokat határozzák meg. Az adatmodell egy navigációs eszköz mind az üzleti, mind az informatikai szakemberek számára, amely meghatározott szimbólum- és szókészletet használ a valós információk egy bizonyos osztályának pontos magyarázatára. Ez javítja a szervezeten belüli kommunikációt, és így rugalmasabb és stabilabb alkalmazási környezetet teremt.

Példa egy térinformatikai rendszerre a hatóságok és a helyi önkormányzati modell számára.

Ma már stratégiai fontosságú, hogy a szoftver- és szolgáltatók gyorsan tudjanak reagálni a technológiai innovációkkal, a kormányzati korlátozások feloldásával és az ellátási láncok összetettségével összefüggő iparági változásokra. Az üzleti modell változásaival párhuzamosan növekszik a vállalat tevékenységének támogatásához szükséges információs technológia összetettsége és költsége. Az adatkezelés különösen nehéz olyan környezetben, ahol a vállalati információs rendszerek, valamint azok funkcionális és üzleti követelményei folyamatosan változnak.

Ennek a folyamatnak a megkönnyítése és optimalizálása érdekében az IT-megközelítés modern szintre való átültetéséhez iparági adatmodelleket kell alkalmazni.

Iparági adatmodellek a cégtőlEsri

Az Esri ArcGIS platform adatmodellei olyan munkasablonok, amelyek a térinformatikai projektekben használhatók, és adatstruktúrákat hozhatnak létre különböző alkalmazási területekhez. Az adatmodell felépítése magában foglalja egy elvi terv, a logikai struktúra és a fizikai struktúra létrehozását, amelyek azután személyes vagy vállalati geoadatbázis felépítéséhez használhatók. Az ArcGIS eszközöket biztosít adatbázissémák létrehozásához és kezeléséhez, az adatmodell-sablonok pedig a GIS-projektek gyors elindítására szolgálnak különféle alkalmazásokban és iparágakban. Az Esri a felhasználói közösséggel együtt jelentős időt töltött számos olyan sablon kifejlesztésével, amelyek segítségével gyorsan elkezdheti a vállalati geoadatbázis tervezését. Ezek a projektek leírása és dokumentálása a support.esri.com/datamodels oldalon található. Az alábbiakban az Esri iparági modellneveinek szemantikai fordításai találhatók, abban a sorrendben, ahogy ezen a webhelyen megjelennek:

• Címjegyzék
• Mezőgazdaság
• Meteorológia
• Alapvető térbeli adatok
• Biodiverzitás
• Épületek belső tere
• Üvegházhatású gázok elszámolása
• A közigazgatási határok fenntartása
• Fegyveres erők. Hírszerző szolgálat
• Energia (beleértve az új ArcGIS MultiSpeak protokollt)
• Ökológiai épületek
• Rendkívüli helyzetek minisztériuma. tűzvédelem
• Erdőkataszter
• Erdészet
• Geológia
• Országos szintű GIS (e-kormányzat)
• Talajvíz és szennyvíz
• egészségügyi ellátás
• Régészet és emlékhelyek védelme
• nemzetbiztonság
• Hidrológia
• Nemzetközi Hidrográfiai Szervezet (IHO). S-57 formátum az ENC-hez
• Öntözés
• Földhivatal
• önkormányzat
• Tengeri navigáció
• Állami kataszter
• Olaj- és gázszerkezetek
• Csővezetékek
• Raszteres üzletek
• Batimetria, tengerfenék topográfia
• Távközlés
• Szállítás
• Víz, csatorna, közművek

Ezek a modellek tartalmazzák az ipari szabvány összes szükséges jellemzőjét, nevezetesen:

• szabadon hozzáférhetők;
• nem kötődnek a „kiválasztott” gyártó technológiájához;
• valós projektek megvalósítása eredményeként jött létre;
• iparági szakértők részvételével készült;
• úgy tervezték, hogy információs interakciót biztosítson a különböző termékek és technológiák között;
• ne mondjon ellent más szabványoknak és szabályozó dokumentumoknak;
• használják megvalósított projektekben szerte a világon;
• úgy tervezték, hogy mindenről információval dolgozzon életciklus a létrehozandó rendszer, nem maga a projekt;
• az ügyfél igényei szerint bővíthető anélkül, hogy elveszítené a kompatibilitást más projektekkel és/vagy modellekkel;
• kiegészítő anyagok és példák kíséretében;
• különböző ipari vállalatok útmutatóiban és műszaki anyagaiban használják;
• a résztvevők nagy közössége, miközben a közösséghez való hozzáférés mindenki számára nyitva áll;
• az elmúlt évek publikációiban nagyszámú hivatkozás adatmodellekre.

Az Esri egy független testületekből álló szakértői csoport tagja, amely különféle iparági modelleket javasol használatra, mint például a PODS (Pipeline Open Data Standards – nyílt szabvány az olaj- és gázipar számára; jelenleg a PODS-t Esri PODS Esri Spatial-ként implementálják). 5.1.1 geoadatbázis) vagy az ArcGIS for Aviation geoadatbázisa (GDB), amely figyelembe veszi az ICAO és az FAA ajánlásait, valamint az AIXM 5.0 navigációs adatcsere szabványt. Ezenkívül vannak olyan ajánlott modellek, amelyek szigorúan betartják a meglévő iparági szabványokat, mint például az S-57 és az ArcGIS for Maritime (tengeri és part menti jellemzők), valamint az Esri Professional Services munkája alapján létrehozott modellek, amelyek „de facto” szabványok. az érintett területeken. Például a GIS for the Nation and Local Government hatással volt az NSDI és INSPIRE szabványokra, míg a Hydro és a Groundwater erősen használatos a szabadon elérhető ArcHydro professzionális csomagban és kereskedelmi termékekben. Meg kell jegyezni, hogy az Esri olyan „de facto” szabványokat is támogat, mint például az NHDI. Minden javasolt adatmodell dokumentált, és készen áll a vállalati informatikai folyamatokban való használatra. A modellekhez mellékelt anyagok a következők:

• entitáskapcsolatok UML diagramjai;
• adatstruktúrák, tartományok, könyvtárak;
• kész geoadatbázis sablonok ArcGIS GDB formátumban;
• mintaadatok és mintaalkalmazások;
• példák adatbetöltő szkriptekre, példák elemzési segédprogramokra;
• kézikönyvek a javasolt adatszerkezetről.

Az Esri könyvek formájában foglalja össze tapasztalatait az építőipari modellek terén, és lokalizálja a megjelent anyagokat. Az Esri CIS a következő könyveket lokalizálta és kiadta:

• Geospatial Service Oriented Architecture (SOA);
• Geoadatbázisok tervezése közlekedéshez;
• Vállalati térinformatikai rendszerek;
• GIS: elektromos és gázipari vállalkozások új energiája;
• Olaj és gáz digitális térképen;
• Világunk modellezése. Esri Geadatbázis tervezési útmutató;
• GIS-re gondolva. Térinformatikai tervezés: útmutató vezetőknek;
• Földrajzi információs rendszerek. Alapok;
• GIS adminisztratív és gazdasági irányításhoz;
• Webes GIS. Alapelvek és alkalmazás;
• Systems Design Strategies, 26. kiadás;
• Az ArcReview magazin 68 száma cégek és térinformatikai rendszerek felhasználói publikációival;
• ... és sok más tematikus jegyzet és kiadvány.

Például a könyv Világunk modellezése..."A (fordítás) egy átfogó útmutató és referencia útmutató a térinformatikai adatmodellezéshez általában, és különösen a geoadatbázis-adatmodellhez. A könyv bemutatja, hogyan kell meghozni a megfelelő adatmodellezési döntéseket, olyan döntéseket, amelyek egy térinformatikai projekt minden aspektusát érintik: az adatbázis-tervezési adatoktól és adatgyűjtéstől a térbeli elemzésig és megjelenítésig Részletesen leírja, hogyan lehet a projektnek megfelelő földrajzi adatbázist megtervezni, programozás nélkül beállítani az adatbázis-funkcionalitást, kezelni a munkafolyamatokat összetett projektekben, modellezni a különféle hálózati struktúrákat, mint például a folyó, a közlekedés. vagy elektromos hálózatokat, integrálja a műholdfelvételek adatait a földrajzi elemzésbe és térképezésbe, és 3D térinformatikai adatmodelleket készít. Szállítási geoadatbázisok tervezése" olyan módszertani megközelítéseket tartalmaz, amelyeket számos projekten teszteltek, és teljes mértékben megfelelnek Európa és az Egyesült Államok jogszabályi követelményeinek, valamint a nemzetközi szabványoknak. És a könyvben " GIS: elektromos és gázipari vállalkozások új energiája Valós példákon keresztül bemutatja azokat az előnyöket, amelyeket a vállalati térinformatikai rendszer hozhat az energiaszolgáltató számára, beleértve az olyan szempontokat, mint az ügyfélszolgálat, a hálózat üzemeltetése és egyéb üzleti folyamatok.

Néhány lefordított és eredeti könyv oroszul az Esri CIS és a DATA+ kiadásában jelent meg. Mind a térinformatikai technológiával kapcsolatos fogalmi kérdéseket, mind a különböző léptékű és célú GIS modellezésének és telepítésének számos alkalmazott szempontját lefedik.

Megfontoljuk a BISDM (Building Interior Space Data Model) 3.0-ás verziójú adatmodelljét használó iparági modellek használatát példaként. A BISDM egy általánosabb BIM modell (Building Information Model, Building Information Model) továbbfejlesztése, és épületek és építmények tervezésében, építésében, üzemeltetésében és leszerelésében való felhasználásra szolgál. A térinformatikai szoftverekben használatos, lehetővé teszi a geoadatok hatékony cseréjét más platformokkal és interakciót velük. Az FM (szervezeti infrastruktúra menedzsment) általános feladatcsoportra utal. Felsoroljuk a BISDM modell fő előnyeit, amelyek használata lehetővé teszi:

• megszervezi az információcserét heterogén környezetben azáltal közös szabályokat;
• szerezze meg a BIM koncepció "fizikai" megtestesülését és az építési projekt irányításának javasolt szabályait;
• egyetlen tároló fenntartása térinformatikai eszközök segítségével az épület teljes életciklusa során (a tervezéstől a leszerelésig);
• koordinálja a projektben részt vevő különböző szakemberek munkáját;
• vizualizálja a tervezett ütemtervet és az építési szakaszokat minden résztvevő számára;
• adjon előzetes becslést a költségekről és az építési időről (4D és 5D adatok);
• ellenőrizni a projekt előrehaladását;
• biztosítja az épület minőségi üzemeltetését, beleértve a karbantartást és javítást is;
• részévé váljon a vagyongazdálkodási rendszernek, ideértve a területfelhasználás hatékonyságát elemző funkciókat (bérbeadás, raktározás, dolgozói menedzsment);
• kiszámítja és kezeli az épület energiahatékonyságát;
• szimulálja az emberi áramlások mozgását.

A BISDM meghatározza a téradatokkal való munkavégzés szabályait az épület belső tereinek szintjén, beleértve a célt és a felhasználást, a lefektetett kommunikációt, telepített berendezések, javítások és karbantartások elszámolása, incidensek naplózása, összekapcsolás más cégvagyonnal. A modell segít a földrajzi és nem földrajzi adatok egységes tárházának létrehozásában. A világ vezető vállalatainak tapasztalatait felhasználták az entitások elkülönítésére, és GDB szinten (geoadatbázis) modellezték az épületet és annak belsejét egyaránt alkotó összes fizikai elem térbeli és logikai kapcsolatait. A BISDM elveinek követése jelentősen leegyszerűsíti a más rendszerekkel való integráció feladatait. Az első szakaszban ez általában a CAD-del való integráció. Ezután az épület üzemeltetése során ERP és EAM rendszerekkel (SAP, TRIRIGA, Maximo stb.) történik az adatcsere.

BISDM szerkezeti elemek megjelenítése ArcGIS segítségével.

A BISDM használata esetén a létesítmény megrendelője/tulajdonosa végpontok közötti információcserét kap a létesítmény létrehozásának ötletétől a komplett projekt kidolgozásáig, az építési ellenőrzésig, a naprakész információk megszerzésével. -dátuminformáció a létesítmény üzembe helyezésének időpontjára, a paraméterek ellenőrzése üzem közben, sőt a létesítmény rekonstrukciója vagy leszerelése során is. A BISDM paradigmát követve a térinformatika és a segítségével létrehozott földrajzi adatbázis közös adattárává válik kapcsolódó rendszerek. A GDB-ben gyakran vannak harmadik féltől származó rendszerek által létrehozott és üzemeltetett adatok. Ezt figyelembe kell venni a készülő rendszer architektúrájának kialakításakor.

Egy bizonyos szakaszban az információ felhalmozódott "kritikus tömege" lehetővé teszi, hogy egy új minőségi szintre lépjen. Például egy új épület tervezési fázisának befejeztével lehetőség nyílik a térinformatikai rendszerben a 3D-s felmérési modellek automatikus megjelenítésére, a telepítendő berendezések listájának összeállítására, a lefektetendő mérnöki hálózatok kilométereinek kiszámítására, számos ellenőrzés elvégzésére. , és még előzetes pénzügyi becslést is adnak a projekt költségére.

A BISDM és az ArcGIS együttes használatakor ismét lehetővé válik a felhalmozott adatokból 3D modellek automatikus felépítése, hiszen a GDB tartalmazza az objektum teljes leírását, beleértve a z-koordinátákat, egy emelethez való tartozást, az elemcsatlakozások típusait, felszereltségét. beépítési módok, anyagok, elérhető utak a személyzet mozgása, az egyes elemek funkcionális rendeltetése stb. stb. Meg kell jegyezni, hogy az összes tervezési anyag BISDM GDB-be való kezdeti importálása után további tartalomra van szükség:

• tárgyak és berendezések 3D-s modelljeinek elhelyezése a kijelölt helyeken;
• információk gyűjtése az anyagok költségéről, valamint a lerakásuk és felszerelésük eljárásáról;
• átjárhatóság ellenőrzése a telepített nem szabványos berendezés méretei szerint.

Az ArcGIS használata megkönnyíti a további 3D objektumok és hivatkozások importálását külső források, mert Az ArcGIS Data Interoperability modul lehetővé teszi eljárások létrehozását az ilyen adatok importálására és helyes elhelyezésére a modellben. Az iparágban használt összes formátum támogatott, beleértve az IFC-t, az AutoCAD Revit-et, a Bently Microstation-t.

Ipari adatmodellek az IBM-től

Az IBM tárkezelési eszközöket és modelleket kínál számos iparág számára:

• IBM Banking and Financial Markets Data Warehouse (pénzügy)
• IBM Banking Data Warehouse
• IBM banki folyamat- és szolgáltatásmodellek
• IBM egészségügyi terv adatmodell (egészség)
• IBM Insurance Information Warehouse (biztosítás)
• IBM biztosítási folyamat- és szolgáltatásmodellek
• IBM Retail Data Warehouse (kiskereskedelem)
• IBM Telecommunications Data Warehouse (telekommunikáció)
• InfoSphere Warehouse Pack:
  - a Customer Insight (az ügyfelek megértése érdekében)
  - Piac- és kampánybetekintéshez (a vállalat és a piac megértéséhez)
  - Supply Chain Insight számára (a beszállítók megértéséhez).

Például modell IBMbankiésPénzügyipiacokonAdatRaktár célja, hogy megfeleljen a bankszektor sajátos kihívásainak az adatok tekintetében, és IBMbankifolyamatésSzolgáltatásModellek- folyamatok és SOA (szolgáltatás-orientált architektúra) tekintetében. A távközlési ipar számára bemutatott modellek IBMinformációKeretrendszer(IFW)és IBMTávközlésAdatRaktár (TDW). Segítenek felgyorsítani a létrehozási folyamatot. elemző rendszerek, valamint az üzleti intelligencia alkalmazások fejlesztésével, a vállalati adatkezeléssel és az adattárházak szervezésével járó kockázatok csökkentése a távközlési iparág sajátosságait figyelembe véve. Az IBM TDW képességei a távközlési piac teljes spektrumát lefedik - a vezetékes és vezeték nélküli telefonszolgáltatást, adatátvitelt és multimédiás tartalmat kínáló internetszolgáltatóktól és kábelhálózat-üzemeltetőktől a telefon-, műhold-, távolsági és nemzetközi kommunikációs szolgáltatásokat nyújtó multinacionális cégekig, valamint mint szervezetek globális hálózatok. Ma a TDW-t nagy és kis vezetékes és vezeték nélküli szolgáltatók használják szerte a világon.

A szerszám ún InfoSphere Warehouse Pack a Customer Insight-hoz egy strukturált és könnyen megvalósítható üzleti tartalom egyre több üzleti projekt és iparág számára, beleértve a banki, biztosítási, pénzügyi, egészségbiztosítási programokat, telekommunikációt, kiskereskedelmet és forgalmazást. Üzleti felhasználóknak InfoSphere Warehouse Pack a Market és Campaign Insight számára segít maximalizálni a piaci intelligencia és a marketingkampányok hatékonyságát egy lépésről lépésre történő fejlesztési és üzletspecifikus folyamaton keresztül. Használva InfoSphere Warehouse Pack a Supply Chain Insight-hoz a szervezeteknek lehetőségük van aktuális információkat szerezni az ellátási lánc működéséről.

Az Esri pozíciója az IBM megoldásarchitektúrán belül.

Külön kiemelendő az IBM közüzemi és közüzemi társaságokkal kapcsolatos megközelítése. A növekvő fogyasztói igények kielégítése érdekében a közüzemi vállalatoknak a jelenleginél rugalmasabb architektúrára, valamint egy iparági szabványnak megfelelő objektummodellre van szükségük, amely megkönnyíti a szabad információcserét. Ez növeli az energiavállalatok kommunikációs képességeit azáltal, hogy költséghatékonyabb kommunikációt tesz lehetővé, és az új rendszerek jobban átlátják az összes szükséges erőforrást, függetlenül attól, hogy a szervezeten belül hol helyezkednek el. Ennek a megközelítésnek az alapja a SOA (Service Oriented Architecture), egy olyan komponens modell, amely megfeleltetést hoz létre a részlegek funkciói és a különféle alkalmazások szolgáltatásai között, amelyek újra felhasználhatók. Az ilyen komponensek „szolgáltatásai” interfészeken keresztül kommunikálnak kemény kötés nélkül, elrejtve a felhasználó elől a mögöttük lévő rendszerek teljes komplexitását. Ebben a módban a vállalatok könnyen hozzáadhatnak új alkalmazásokat a szoftver gyártójától, az operációs rendszertől, a programozási nyelvtől vagy a szoftver egyéb belső jellemzőitől függetlenül. A koncepció a SOA alapján valósul meg BIZTONSÁGOS ( A Solution Architecture for Energy lehetővé teszi a közműipar számára, hogy szabványokon alapuló, holisztikus képet kapjon infrastruktúrájáról.

Esri ArcGIS A ® a földrajzi információs rendszerek (GIS) világszerte elismert szoftverplatformja, amely a villamos energia, a gázszállítás, az elosztás és a távközlési hálózatok digitális eszközeinek létrehozását és kezelését biztosítja. Az ArcGIS lehetővé teszi az elektromos elosztó hálózat elemeinek legteljesebb leltározását, figyelembe véve azok térbeli elhelyezkedését. Az ArcGIS jelentősen kibővíti az IBM SAFE architektúrát azáltal, hogy biztosítja az intelligens grid kezeléséhez szükséges eszközöket, alkalmazásokat, munkafolyamatokat, elemzési, valamint információs és integrációs képességeket. Az IBM SAFE-en belüli ArcGIS lehetővé teszi, hogy különböző forrásokból információkat szerezzen az infrastrukturális objektumokról, eszközökről, ügyfelekről és alkalmazottakról, pontos adatokkal a helyükről, valamint georeferált információkat hozzon létre, tároljon és dolgozzon fel a vállalati eszközökről (pillérek, csővezetékek, vezetékek, transzformátorok, kábelcsatornák stb.). A SAFE infrastruktúrán belüli ArcGIS lehetővé teszi a kulcsfontosságú üzleti alkalmazások dinamikus összekapcsolását azáltal, hogy a GIS, SCADA és ügyfélszolgálati rendszerek adatait külső információkkal, például forgalmi, időjárási körülményekkel vagy műholdképekkel kombinálja. A közművek ezeket a kombinált információkat különféle célokra használják fel, a C.O.R. (az üzemi helyzet általános képe) a létesítmények ellenőrzése előtt, Karbantartás, hálózatok elemzése és tervezése.

Az áramszolgáltató vállalat információs komponensei több szinten is modellezhetők, amelyek a legalacsonyabb - fizikai - üzleti folyamatlogika legfelső, legösszetettebb szintjéig terjednek. Ezek a rétegek integrálhatók, hogy megfeleljenek a tipikus iparági követelményeknek, mint például az automatizált mérési naplózás, valamint a felügyeleti vezérlés és adatgyűjtés (SCADA) vezérlése. A SAFE architektúra felépítésével a közüzemi vállalatok jelentős előrelépéseket tesznek az energia- és közszolgáltatások közös információs modelljének (Common Information Model (CIM)) nevezett, az egész iparágra kiterjedő nyílt objektummodell továbbfejlesztésében. Ez a modell biztosítja a szükséges alapot ahhoz, hogy sok vállalkozást a szolgáltatás-orientált architektúra felé mozdítsanak el, mivel ösztönzi a nyílt szabványok használatát az adatok és objektumok strukturálására. Azáltal, hogy minden rendszer ugyanazokat az objektumokat használja, az ugyanazon objektumok különböző megvalósításaihoz kapcsolódó zavart és rugalmatlanságot a minimumra csökkenti. Így az „ügyfél” objektum és más fontos üzleti objektumok meghatározása egységes lesz az áramszolgáltató vállalat összes rendszerében. A CIM segítségével a szolgáltatók és a szolgáltatók fogyasztói közös adatstruktúrán osztozhatnak, ami megkönnyíti a költséges üzleti összetevők kiszervezését, mivel a CIM közös alapot hoz létre, amelyre az információmegosztást építhetik.

Következtetés

Az átfogó iparági adatmodellek egyetlen, integrált nézetet biztosítanak a vállalatoknak üzleti információikról. Sok vállalat nehezen tudja integrálni adatait, bár ez a legtöbb vállalati szintű projekt előfeltétele. A The Data Warehousing Institute (TDWI) tanulmánya szerint a megkérdezett szervezetek több mint 69%-a az integrációt jelentős akadálynak találta az új alkalmazások elfogadása előtt. Éppen ellenkezőleg, az adatintegráció megvalósítása kézzelfogható bevételt és hatékonyságnövekedést hoz a vállalat számára.

Egy jól felépített modell egyedileg határozza meg az adatok jelentését, amelyek ebben az esetben strukturált adatok (szemben a strukturálatlan adatokkal, például képekkel, bináris fájlokkal vagy szövegekkel, ahol az érték nem egyértelmű). A leghatékonyabb iparági modelleket professzionális gyártók kínálják, köztük az Esri és az IBM. Modelleik használatából származó magas megtérülést jelentős részletezettségük és pontosságuk miatt érik el. Általában sok adatattribútumot tartalmaznak. Ezen túlmenően az Esri és az IBM szakértői nemcsak széles körű modellezési tapasztalattal rendelkeznek, hanem jártasak egy adott iparág modelljének építésében is.