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

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

Nagyapa ültetett ... tárolót. És a raktár nőtt, nagyszerű, nagyszerű. De nem igazán tudtam, hogyan működik. És nagyapa elkezdte a felülvizsgálatot. A nagyapa behívta a nagymamát, unokát, macskát és egeret a családi tanácsba. És a következőket mondja: „Nőtt a tárhelyünk. Az összes rendszer adatai lefelé áramlanak, a táblázatok láthatók és láthatatlanok. A felhasználók összeállítják jelentéseiket. Minden jónak tűnik - élni és élni. Igen, csak egy szomorúság - senki sem tudja, hogyan működik. Láthatóan -láthatatlanul lemezeket igényel - nem lesz elég! És ekkor a felhasználók megszokták, hogy különböző panaszokkal fordulnak hozzám: vagy a jelentés lefagy, akkor az adatok elavultak. És akkor ez elég katasztrófa - jelentésekkel érkezünk a cár -atyához, de a számok nem egyeznek egymással. Még az óra sincs - mérges a király -, akkor ne vegye le a fejét - sem nekem, sem neked. Ezért úgy döntöttem, hogy összegyűjtök titeket, és megkérdezem: mit fogunk csinálni? "

Tekintetét a találkozóra vetette, és megkérdezte:
- Te, nagymama, tudod, hogyan van elrendezve a tárolónk?
- Nem, nagyapa, nem tudom. És honnan tudnám? Odaát, milyen bátor legények őrzik őt! Néhány közülük! Nem fog közeledni. Elmentem hozzájuk valahogy, lepényt sütöttem. És megették a pitét, megtörölték a bajuszukat, és azt mondták: „Miért jöttél, nagymama? Milyen tárhely vagy? Te mondd meg, milyen jelentésre van szükséged - mi megtesszük helyetted! Gyakrabban kell hozni a pitét! Fájdalmasan finomak. "
- És te, szeretett unokám, tudod, hogyan van elrendezve a tárolónk?
- Nem, nagypapa, nem tudom. Valahogy hozzáférést adtak hozzá. Csatlakoztam, nézem - és vannak táblázatok - látszólag -láthatatlanul. És a különböző sémák rejtve vannak. Felszaladnak a szemek…. Először zavarban voltam. És akkor jobban megnéztem - némelyik üres, mások tele vannak, de csak a fele. És az adatok ismétlődni látszanak. Nem csoda, hogy nem lesz elég a lemezekből, ilyen redundanciával!
- Nos, te, macska, mit szólsz a tárolónkhoz? Van benne valami jó?
- De hogyan ne mondjam, nagyapa - megteszem. Unokám kérésére próbáltam pilótát készíteni egy külön körben - egy kis vitrinben. Annak érdekében, hogy megértsük, milyen kereskedelem nyereséges államunk számára - milyen termékek jók a kereskedőknek, adót fizetnek - feltöltik a kincstárat. És melyek nagyon rosszak. És elkezdtem adatokat válogatni magamnak ebből a tárból. Összegyűjtött tények. És elkezdte összehasonlítani őket a termékekkel. És mit, nagyapa, láttam - a termékek látszólag ugyanazok, de ha a tányérokat nézed - azok különbözőek! Aztán elkezdtem fésülgetni őket az unokám fésűjével. Chesal -karcos - és bizonyos egyöntetűséghez vezetett, simogatva a szemet. De korán örültem - másnap elindítottam a szkripteimet, hogy frissítsem az ablak csodálatos adatait -, és minden eltűnt számomra! "Hogy hogy?" - Azt hiszem - ideges lesz az unokája -, ma meg kellene mutatni a pilótánkat a miniszternek. Hogyan járhatunk el ilyen adatokkal?
- Igen, szomorú mesék, macska, te mondod. Nos, te, kisegér, tényleg nem próbáltál tájékozódni a tárolásról? Élénk, fürge, társaságkedvelő lány vagy velünk! Mit fog nekünk mondani?
- Igen, hogyan, nagyapa, ne próbálkozzon - persze, csendes egér vagyok, de fürge. Egyszer a macska unokája megkért, hogy szerezzem be az állami tárhelyünk adatmodelljét. És a macska természetesen eljött hozzám - neked, mondja, az egér, minden remény! Nos, mi a jó cselekedet, ha a jó emberek (és macskák) nem tesznek? Elmentem a kastélyba, ahol a raktár vezetője elrejti az adatmodellt a széfben. És elrejtőzött. Vártam, hogy kivegye a modellt a széfből. Amint kiment kávézni, felugrottam az asztalra. Nézem a modellt - nem értek semmit! Hogy hogy? Nem ismerem a tárhelyünket! Számtalan ezer táblánk van, az adatfolyamok visszafordíthatatlanok! És itt - minden harmonikus és szép ... Ránézett erre a modellre - és visszatette a széfbe.
- Igen, nagyon furcsa dolgokat mondtál nekünk, egér.
A nagyapa keményen gondolkodott.
- Mit fogunk csinálni, barátaim? Végül is ilyen és ilyen tárolóval nem fog sokáig élni ... A felhasználók hamarosan elveszítik a türelmüket.

Bármit is döntött nagyapánk a mese alapján - új tároló létesítését vagy egy meglévő újjáélesztését -, le kell vonni a következtetéseket, mielőtt ismét "felhúzzuk az ingujjunkat".
Tegyük félre a szervezeti szempontokat - például azt a veszélyt, hogy a szakértelem egy bizonyos szűk zárt csoportba koncentrálódik, az ellenőrzési folyamatok hiánya és a vállalkozásban használt 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. Amit mindenekelőtt a fókuszban kell tartani, amikor a szervezet elkezd egy ilyen komplex és költséges rendszer kiépítését, mint a tároló.

Kikérdezés

Egyikünk sem, bármely rendszer létrehozásán és fejlesztésén dolgozva, nem akarja, hogy ez „ideiglenes ház” legyen, vagy olyan megoldás, amely egy -két év múlva „elhervad”, mert nem lesz képes megfelelni az ügyfelek és az üzleti elvárásoknak. Bármennyire erős ma is a "rugalmas módszerek" irányába mutató elfogultság, az ember számára sokkal kellemesebb, ha hegedűt készítő "mesternek" érzi magát, mint egy kézművesnek, aki repülőgépeket használ az eldobható dobokhoz.
Szándékunk természetesnek hangzik: olyan rendszereket kell készíteni, amelyek szilárdak és kiváló minőségűek, és amelyek nem igényelnek rendszeres "éjszakai virrasztást fájllal", amiért nem fogunk szégyenkezni a végfelhasználók előtt, és nem fognak úgy kinézni "fekete doboz" minden "avatatlan" követő számára.

Kezdjük azzal, hogy tegyünk egy listát azokról a tipikus problémákról, amelyekkel rendszeresen találkozunk, amikor tárházakkal dolgozunk. Csak írjuk le, amink van - eddig anélkül, hogy racionalizálnánk és formalizálnánk.

1. Elvileg jó tárhelyünk van: ha nem nyúl hozzá, akkor minden működik. Amint azonban változtatásra van szükség, „helyi összeomlások” kezdődnek.
2. Az adatokat naponta, az előírásoknak megfelelően, egy nagy folyamaton belül, 8 órán belül töltik fel. És ez megfelel nekünk. De ha hirtelen hiba lép fel, ez kézi beavatkozást igényel. És akkor sok minden kiszámíthatatlanul működhet sokáig, tk. emberi részvételt igényel a folyamatban.
3. Összeállítottuk a kiadást - problémákra számíthat.
4. Egyes források nem tudtak időben adatokat küldeni - minden folyamat várakozik.
5. Az adatok integritását az adatbázis vezérli - így folyamataink összeomlanak, amikor megszakadnak.
6. Nagyon nagy tárhelyünk van - 2000 tábla egy közös sémában. És még 3000 további programokban. Kevés fogalmunk van már arról, hogy hogyan vannak elrendezve és milyen okból jelentek meg. Ezért nehéz lehet valamit újra felhasználni. És sok feladatot újra meg kell oldani. Mert ez könnyebb és gyorsabb (mint megérteni "valaki más kódját"). Ennek eredményeként eltérések és kettős funkciók vannak.
7. A forrástól jó minőségű adatokat várunk. De kiderül, hogy ez nem így van. Ennek eredményeképpen sok időt töltünk végső jelentéseink összehangolásával. É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 az egyik vagy másik szám indoklását. Bizonyos esetekben igaza van, másokban nem. De nagyon nehéz megindokolnunk őket, hiszen nincs eszközünk a "végpontok közötti elemzésre" (vagy az adatok vonalára).
9. Hozhatunk további fejlesztőket. Van azonban egy problémánk - hogyan vegyük be őket a munkába? Mi a leghatékonyabb módja a munkák párhuzamosításának?
10. Hogyan lehet fokozatosan fejleszteni a rendszert, anélkül, hogy egy évig bele kellene menni a "rendszermag" fejlesztésébe?
11. Az adattárház a vállalati modellhez van társítva. De biztosan tudjuk (ezt láttuk az XYZ bankban), hogy egy modell elkészítése végtelenül hosszú lehet (hat hónapra elmentünk az XYZ bankba, és minden mozgás nélkül megbeszéltük az üzleti entitásokat). Miért van egyáltalán? Vagy talán jobb nélküle, ha ennyi probléma van vele? Lehet, hogy valahogy elő tudjuk állítani?
12. Úgy döntöttünk, hogy vezetjük a modellt. De hogyan fejlesztheti szisztematikusan a raktári adatmodellt? Szükségünk van "játékszabályokra", és mik lehetnek ezek? Mit ad ez nekünk? Mi van, ha tévedünk a modellel?
13. Mentsük az adatokat, vagy a változások történetét, ha "a vállalkozásnak nincs szüksége rá"? Nem szeretném "szemetet tárolni" és bonyolítani ezen adatok valódi feladatokhoz való felhasználását. A boltozatnak meg kell őriznie a történelmet? Milyen érzés? Hogyan működik a tárolás idővel?
14. Meg kell próbálnunk egyesíteni a raktáron lévő adatokat, ha van törzsadat -kezelő rendszerünk? Ha van MDM, ez azt jelenti, hogy a törzsadatokkal kapcsolatos teljes probléma most megoldódott?
15. Várhatóan hamarosan lecseréljük a legfontosabb 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 értünk ez alatt? Hol lehet őket pontosan használni? Hogyan tudod megvalósítani? Kell -e "egy helyen" tárolni őket?
17. Ügyfeleink rendkívül instabilak igényeikben és vágyaikban - valami folyamatosan változik. Általánosságban elmondható, hogy üzletünk nagyon dinamikus. Miközben csinálunk valamit, az már szükségtelenné válik. Hogyan tehetjük meg úgy, hogy a lehető leggyorsabban megkapjuk az eredményt - mint a forró sütemények?
18. A felhasználók reagálást követelnek. De nem tudjuk gyakran futtatni a fő rendszerindítási folyamatainkat, mert ez betölti a forrásrendszereket (rossz hatással van a teljesítményre) - ezért további adatfolyamokat felakasztunk - amelyek pontosan felveszik -, amire szükségünk van. Igaz, sok patak van. És akkor kidobunk néhány adatot. Sőt, konvergenciaprobléma is 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ő és fejleszthető. Nem elrejtjük a táblázatban, hanem felakasztjuk egy jól látható helyre - ezeket a kérdéseket a figyelmünk középpontjában tartva a munka során.
Feladatunk egy átfogó megoldás kidolgozása ennek eredményeként.

Antifragilitás

A listánkat tekintve egy következtetés levonható. Nem nehéz egyfajta "jelentési adatbázist" létrehozni, adatokat feltölteni oda, vagy akár rutinszerű adatfrissítési folyamatokat felépíteni. A rendszer valahogy elkezd élni, megjelennek a felhasználók, és velük együtt a kötelezettségek és az SLA, új követelmények merülnek fel, további források kapcsolódnak, a módszerek megváltoznak - mindezt figyelembe kell venni a fejlesztési folyamatban.

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

Olyan változás érkezik hozzánk, amelynek hatását nem vagyunk képesek felmérni és felfogni (mivel nem a kezdetektől fogva helyeztünk ilyen eszközöket a rendszerbe) - és hogy ne kockáztassunk, nem nyúlunk ahhoz, ami van, de csinálunk egy másik kiterjesztést az oldalon, és egy másikat, és azt is - a megoldásunkat nyomornegyedekké, vagy, ahogy Latin -Amerikában mondják, "favellákká" alakítjuk, ahová még a rendőrség is fél.
A saját rendszer feletti uralom elvesztésének érzése, káosz van. Egyre több kézre van szükség a meglévő folyamatok fenntartá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 stresszel szemben, rosszul alkalmazkodik a változásokhoz. Ezenkívül erősen függ a szereplőktől, akik "ismerik a hajóutat", mivel senkinek nincs "térképe".

Egy tárgynak ez a tulajdonsága - összeomlik a káosz, véletlenszerű események és sokkok hatására - Nassim Nicholas Taleb törékenység ... És bemutatja az ellenkező fogalmat is: törésgátló – amikor a tárgy nem bomlik le a stressztől és a balesetektől, hanem közvetlenül profitál belőle... ("Antifragilitás. Hogyan lehet kamatoztatni a káoszt")
Ellenkező esetben hívható alkalmazkodóképesség vagy a változással szembeni ellenálló képesség .

Mit jelent ez ebben az összefüggésben? Melyek a „káosz forrásai” az informatikai rendszerek számára? És mit jelent a „káosz kamatoztatása” az informatikai architektúra szempontjábó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? Különösen tároláshoz. Természetesen először is - változások az áruház adatforrásainak oldaláról:

• a bejövő adatok formátumának megváltoztatása;
• egyes adatforrás -rendszerek cseréje másokkal;
• a rendszerek integrálására vonatkozó szabályok / platformok megváltoztatása;
• az adatok értelmezésének megváltoztatása (a formátumok mentésre kerülnek, az adatok változásának logikája);
• az adatmodell megváltoztatása, ha az integráció adatszinten történik (az adatbázis tranzakciós naplófájljainak elemzése);
• az adatmennyiségek növekedése - míg a forrásrendszerben nem volt sok adat, és a terhelés sem volt magas - bármikor le lehetett kérni, tetszőlegesen nehéz kéréssel az adatok és a terhelés növekedett - 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 is változhat. Minden rendszer saját adatmodelljét és a velük való együttműködés módszereit valósítja meg, amelyek megfelelnek a rendszer céljainak. És bármennyire is igyekeznek egységesíteni az iparági modelleket és referenciagyakorlatokat, elkerülhetetlenül árnyalatok jelennek meg. (Ráadásul maga az iparegyesítési folyamat különböző okokból nem sok előrelépést tesz.)
A vállalati adatokkal való munka kultúrája - az információs architektúra jelenléte és ellenőrzése, az egységes szemantikai modell, a törzsadat -kezelő rendszerek (MDM) némileg megkönnyítik az adatok raktárban történő összevonásának feladatát, de nem zárják ki annak szükségességét.

Nem kevésbé kritikus változásokat kezdeményeznek a raktári fogyasztók (változnak a követelmények):

• korábban elegendő adat volt a jelentés elkészítéséhez - most további mezők vagy új adatforrás összekapcsolására volt szükség;
• a korábban megvalósított adatfeldolgozási módszerek elavultak - az algoritmusokat és mindent, amit ez érint, újra kell dolgozni;
• Korábban mindenki elégedett volt a szótár attribútum aktuális értékével az információs panelen - most az az érték szükséges, amely releváns az elemzett tény / esemény időpontjában;
• elvárás volt az adattárolási előzmények mélységére, ami korábban nem létezett - az adatokat nem 2, hanem 10 évig kell tárolni;
• korábban elegendő adat állt rendelkezésre a „nap végén / időszakban” - most szüksége van az adatállapotra „napon belül”, vagy egy bizonyos esemény idején (például döntés a hitelkérelemről - a Bázel II esetében);
• korábban elégedettek voltunk a tegnapi (T-1) vagy későbbi adatok jelentésével, most szükségünk van a T0-ra;
• stb.

Mind a forrásrendszerrel való integrációs interakciók, mind a raktári adatok fogyasztóitól származó követelmények külső tényezők az adattárház számára: egyes forrásrendszerek helyettesítik a másikat, nőnek az adatmennyiségek, változnak a bejövő adatok formátumai, változnak a felhasználói követelmények stb. Mindezek tipikus külső változások, amelyekre a rendszerünknek - tárházunknak - készen kell állnia. A megfelelő architektúrával nem szabad megölniük a rendszert.

De ez még nem minden.
Ha a változékonyságról beszélünk, először is külső tényezőkre emlékezünk. Hiszen belül mindent irányíthatunk, mi azt gondoljuk, nem? Igen és nem. Igen, a befolyásoló zónán kívüli tényezők többsége külső. De van „belső entrópia” is. És éppen jelenléte miatt néha vissza kell térnünk „a 0 ponthoz”. Kezdje elölről a játékot.
Az életben gyakran hajlamosak vagyunk a nulláról kezdeni. Miért különleges ez nekünk? És tényleg ennyire rossz?
IT -re alkalmazták. Magának a rendszernek - ez nagyon jó lehet - az egyéni döntések újragondolásának képessége. Főleg, ha helyben megtehetjük. A refaktorálás a rendszerfejlesztés során időszakosan felmerülő „web” feloldásának folyamata. A kezdetekhez való visszatérés hasznos lehet. De ennek ára van.
A hozzáértő architektúrakezeléssel ez az ár csökken - és maga a rendszerfejlesztési folyamat is ellenőrizhetőbbé és átláthatóbbá válik. Egy egyszerű példa: ha betartják a modularitás elvét, akkor átírhat egy külön modult anélkül, hogy befolyásolná a külső interfészeket. És ezt nem lehet monolitikus szerkezettel megtenni.

A rendszer törékenységét a beépített architektúra határozza meg. És ez a tulajdonság teszi alkalmazkodóvá.
Amikor arról beszélünk adaptív építészet- azt értjük, hogy a rendszer képes alkalmazkodni a változásokhoz, és egyáltalán nem azt, hogy folyamatosan megváltoztatjuk magát az architektúrát. Éppen ellenkezőleg, minél stabilabb és stabilabb az architektúra, annál kevesebb követelményt támaszt a felülvizsgálat, annál alkalmazkodóbb a rendszer.

A teljes architektúra felülvizsgálatával járó megoldások ára sokkal magasabb lesz. És nagyon jó okokkal kell rendelkeznie az elfogadásukhoz. Például egy ilyen indoklás olyan követelmény lehet, amely nem valósítható meg a meglévő architektúrán belül. Aztán azt mondják - van egy követelmény, amely befolyásolja az architektúrát.
Így nekünk is ismernünk kell a „törésgátlás határait”. Az építészet nem „légüres térben” fejlődik - az aktuális követelményeken és elvárásokon alapul. És ha a helyzet alapvetően megváltozik - meg kell értenünk, hogy túlléptünk a jelenlegi architektúrán -, és felül kell vizsgálnunk, más megoldást kell kidolgoznunk -, és át kell gondolnunk az átmeneti utakat.
Például azt feltételeztük, hogy a tárolóban mindig szükségünk lesz adatokra a nap végén, minden nap adatokat veszünk fel szabványos rendszerinterfészek használatával (nézetek halmazán keresztül). Aztán a kockázatkezelési részlegből jött az igény, hogy ne a nap végén, hanem a hitelezésről szóló döntéskor kelljen adatokat kapni. Nem kell megpróbálni „húzni a feszültségmenteseket” - csak be kell ismernie ezt a tényt - minél hamarabb, annál jobb. És kezdjen el dolgozni egy olyan megközelítésen, amely lehetővé teszi számunkra a probléma megoldását.
Itt egy nagyon finom vonal húzódik meg - ha csak a "pillanatnyi követelményeket" vesszük figyelembe, és nem nézünk több lépést előre (és több évvel előre), akkor növeljük annak kockázatát, hogy túl későn szembesülünk az architektúrát érintő követelményekkel - és a változásunk ára nagyon magas lesz. Kicsit előre tekintve - horizontunk határain belül - még senkinek sem ártott.

A "tároló mese" rendszerének 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, akkor a megsemmisítés meglehetősen gyorsan bekövetkezik az adott rendszerosztály számára.
Miért mondhatom ezt? Az adattárak témája nem új. Az ez idő alatt kidolgozott megközelítések és mérnöki gyakorlatok pontosan erre irányultak - a rendszer életképességének fenntartására.
Egy egyszerű példa: A felszálló tárolóprojektek sikertelenségének egyik leggyakoribb oka az, hogy a fejlesztés alatt álló forrásrendszerekre próbál tárolót építeni anélkül, hogy megállapodna az integrációs interfészekben-megpróbál adatokat lekérni közvetlenül a táblázatokból. Ennek eredményeként elkezdtük a fejlesztést - ez idő alatt a forrásadatbázis megváltozott -, és a tároló betöltési folyamai működésképtelenné váltak. Már késő valamit újracsinálni. És ha még nem biztosította magát azzal, hogy több réteg táblázatot készített a tároló belsejében, akkor mindent kidobhat, és kezdheti elölről. Ez csak egy példa, és az egyik egyszerű.

A törékeny és törésgátló Taleb -kritérium egyszerű. A főbíró az idő. Ha a rendszer ellenáll az idő próbájának, és megmutatja "vitalitását" és "elpusztíthatatlanságát" - akkor a törésgátló tulajdonsággal rendelkezik.
Ha egy rendszer tervezésekor követelményként figyelembe vesszük a törésgátlást, akkor ez arra ösztönöz bennünket, hogy olyan megközelítéseket alkalmazzunk az architektúrájának felépítéséhez, amelyek révén a rendszer jobban alkalmazkodik a „kívülről jövő káoszhoz” és a „káoszhoz belülről”. ”. És végül a rendszer hosszabb élettartamú lesz.
Egyikünk sem akar "rögtönzött házakat" csinálni. És ne áltasd magad, ami ma sincs másképp. Normális, ha az ember bármikor, különösen válság idején, néhány lépést előre néz.

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

A tárolási architektúráról szóló cikk feltételezi, hogy az olvasó nemcsak tudja, hogy mi az, hanem van némi tapasztalata az ilyen rendszerekkel kapcsolatban. Ennek ellenére szükségesnek tartottam ezt - visszatérni az eredethez, az út elejéhez, mert ott található a fejlődés "támaszpontja".

Hogyan jutottak az emberek arra a gondolatra, hogy adattárházakra van szükség? És miben különböznek csak egy "nagyon nagy adatbázistól"?
Régen, amikor a világon egyszerűen "üzleti adatfeldolgozó rendszerek" léteztek, az informatikai rendszereket nem osztották osztályokra, például front-end oltp rendszerekre, back-office dss rendszerekre, szövegfeldolgozó rendszerekre, adattárházakra stb. .
Ez idő alatt hozta létre az első relációs adatbázis -motort, az Ingres -t Michael Stonebreaker.
És ez volt az az idő, amikor a személyi számítógépek korszaka forgószélként tört be a számítógépiparba, és örökre megváltoztatta az akkori informatikai közösség minden elképzelését.

Abban az időben könnyű volt megtalálni az asztali osztályú DBMS -ek alapján írt vállalati alkalmazásokat, mint például a Clipper, a dBase és a FoxPro. Az ügyfél-szerver alkalmazások és a DBMS piaca pedig csak lendületet vett. Egymás után jelentek meg az adatbázis -kiszolgálók, amelyek sokáig elfoglalják résüket az informatikai térben - Oracle, DB2 stb.
És az "adatbázis -alkalmazás" kifejezés gyakori volt. Mit tartalmazott egy ilyen kérelem? Egyszerűsített - néhány beviteli űrlap, amelyen keresztül a felhasználók egyidejűleg vihetnek be információkat, néhány számítás, amelyet "gombbal" vagy "ütemterv szerint" indítottak el, valamint néhány jelentés, amelyek a képernyőn láthatók, vagy fájlként menthetők és pecsétre küldhetők.
„Semmi különös - csak egy normál alkalmazás, csak egy adatbázis” - jegyezte meg egyik mentorom karrierem elején. - Szóval semmi különös? - Akkor gondoltam.

Ha alaposan megnézzük, még mindig vannak sajátosságok. Ahogy nőnek a felhasználók, a bejövő információk mennyisége, ahogy nő a rendszer terhelése, fejlesztői, tervezői annak érdekében, hogy a teljesítményt elfogadható szinten tartsák, „trükkökhöz” mennek. A legelső egy monolitikus "üzleti adatfeldolgozó rendszer" felosztása egy számviteli alkalmazássá, amely támogatja a felhasználók on-line munkáját, és az adatok kötegelt feldolgozására és jelentésére külön alkalmazást különítenek el. Ezen alkalmazások mindegyike saját adatbázissal rendelkezik, sőt az adatbázis -kiszolgáló külön példányán is található, különböző beállításokkal a különböző típusú terhelésekhez - OLTP és DSS. És adatfolyamok sorakoznak közöttük.

Ez minden? Úgy tűnik, hogy a probléma megoldódott. Mi történik ezután?
És akkor a vállalatok növekednek, információigényük megsokszorozódik. A külvilággal való interakciók száma is növekszik. 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 származó. A vállalaton belül növekszik az információ - adatforrás rendszerek előállító rendszere. É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 jelennek meg a vállalatban az adattárházak - a rendszerek új osztálya.
A rendszer ezen osztályának általánosan elfogadott meghatározása a következő.

Adattárház (vagy adattárház)-tárgyközpontú információs adatbázis, amelyet kifejezetten jelentések készítésére és üzleti elemzésekre terveztek és terveztek a szervezeti döntéshozatal támogatása érdekében

És így, konszolidáció a különböző rendszerekből származó adatok, az a képesség, hogy bizonyos „egységes” (egységes) módon nézzünk rájuk - ez az adattárházak osztályának egyik legfontosabb tulajdonsága. Ez az oka annak, hogy miért lettek raktárak az informatikai rendszerek fejlődése során.

Az adattárházak legfontosabb jellemzői

Nézzük meg közelebbről. Melyek ezeknek a rendszereknek a fő jellemzői? Miben különbözik az adattárház a többi vállalati informatikai rendszertől?

Először is, ezek nagy mennyiségek. Nagyon nagy. VLDB - így hívják a vezető gyártók az ilyen rendszereket, amikor ajánlataikat adják termékeik használatára vonatkozóan. A vállalat minden rendszeréből az adatok ebbe a nagy adatbázisba áramlanak, és ott tárolódnak "örökre és változatlanul", ahogy a tankönyvekben mondják (a gyakorlatban az élet bonyolultabbnak bizonyul).

Másodszor, ez történelmi adat - "Vállalati memória" - úgynevezett adattárházak. Ami a tárolókkal való időt illeti, minden nagyon érdekes. A számviteli rendszerekben az adatok pillanatnyilag naprakészek. Ezután a felhasználó elvégez valamilyen műveletet - és az adatok frissülnek. Ugyanakkor előfordulhat, hogy a változások előzményei nem kerülnek mentésre - ez a számviteli gyakorlattól függ. Vegyük például a bankszámla egyenlegét. Érdekelhet minket az aktuális egyenleg "most", a nap végén, vagy valamilyen esemény idején (például a pontszámítás idején). Bár az első kettő meglehetősen könnyen megoldható, az utóbbi nagy valószínűséggel különleges erőfeszítéseket igényel. A tárolóval dolgozó felhasználó hivatkozhat az elmúlt időszakokra, összehasonlíthatja azokat a jelenlegivel stb. Ezek az időhöz kapcsolódó képességek jelentik jelentősen a különbséget az adattárházak között a számviteli rendszerektől - az adatok állapotának megszerzése az időtengely különböző pontjain - a múlt bizonyos mélységéig.

Harmadszor, az konszolidáció és adategyesítés ... Annak érdekében, hogy közös elemzésük megvalósulhasson, közös formába kell hozni őket - egységes adatmodell , összehasonlítani a tényeket az egységes referenciakönyvekkel. Itt több szempont és nehézség is felmerülhet. Először is - fogalmi - ugyanazon kifejezés alatt a különböző osztályok különböző emberei különböző dolgokat érthetnek meg. És fordítva - másképp hívni valamit, ami lényegében ugyanaz. Hogyan lehet „egyetlen nézetet” biztosítani, miközben meg kell őrizni egy adott felhasználói csoport sajátos elképzelését?

Negyedszer, ez a munka adat minőség ... Az adatok tárolóba történő betöltése során azokat megtisztítják, általános átalakításokat és átalakításokat hajtanak végre. Az általános átalakításokat egy helyen kell elvégezni - majd különféle jelentések készítésére kell használni. Ezzel elkerülhetőek azok az következetlenségek, amelyek bosszantják az üzleti felhasználókat - különösen azokat a vezetőket, akiket különböző osztályoktól származó számokkal hoznak az asztalra, amelyek nem értenek egyet. A rossz adatminőség hibákat és eltéréseket okoz a jelentésekben, amelyek következménye a szint csökkenése felhasználói bizalom a teljes rendszerre, a teljes elemzési szolgáltatás egészére.

Építészeti koncepció

Aki találkozott egy tárral, nagy valószínűséggel megfigyelt valamilyen "réteges szerkezetet". ez az építészeti paradigma gyökeret vert az ebbe az osztályba tartozó rendszerekben. És nem véletlen. A tároló rétegek a rendszer különálló alkotóelemeiként foghatók fel - saját feladataikkal, felelősségi területükkel, „játékszabályaikkal”.
A réteges architektúra a rendszer bonyolultságának kezelésére szolgál - minden következő szintet elvonnak 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ú problémák kiemelését és egységes megoldását, anélkül, hogy minden alkalommal feltalálná a „kereket” a semmiből.
A koncepcionális építészeti diagram vázlatosan az ábrán látható. Ez egy egyszerűsített diagram, amely csak a kulcsgondolatot tükrözi - a koncepciót, de anélkül, hogy a részletek mélyebb feldolgozása során felmerülnének az „anatómiai részletek”.

Az ábrán látható módon fogalmilag válassza ki a következő rétegeket. A három fő réteg, amely tartalmazza az adattároló területet (a kitöltött téglalap jelzi) és az adatbetöltő szoftvert (hagyományosan az azonos színű nyilak jelzik). És egy kiegészítő - szolgáltatási réteg, amely azonban nagyon fontos összekötő szerepet tölt be - az adatterhelés kezelése és a minőség -ellenőrzés.

Elsődleges adatréteg - elsődleges adatréteg (vagy színpadra állítása , vagy működési réteg ) - a forrásrendszerekből való betöltésre és az elsődleges információk mentésére, átalakítások nélkül - eredeti minőségben, és támogatja a változások teljes történetét.
Ennek a rétegnek a feladata- a későbbi tárolási rétegek elvonása az adatforrások fizikai szerkezetétől, az adatgyűjtés módszereitől és a változások delta elválasztásának módszereitől.

Core Data Layer - magtár - a rendszer központi eleme, amely megkülönbözteti a tárolást a "kötegelt integrációs platformtól" vagy a "big data dump" -tól, mivel fő szerepe adatkonszolidáció különböző forrásokból, redukció egységes szerkezetekre, kulcsokra. A kernelbe való betöltéskor a fő munka az adatminőséggel és az általános átalakításokkal történik, amelyek meglehetősen bonyolultak lehetnek.
Ennek a rétegnek a feladata- elvonatkoztatni fogyasztóikat az adatforrások logikai eszközének jellemzőitől és a különböző rendszerekből származó adatok összehasonlításának szükségességétől, az adatok integritásának és minőségének biztosítása érdekében.

Data Mart Layer - analitikus vitrinek - komponens, amelynek fő funkciója az adatok konvertálása elemzésekhez kényelmes struktúrákba (ha a BI kirakatokkal működik, ez rendszerint dimenziós modell), vagy a fogyasztói rendszer követelményeinek megfelelően.
Az adattérképek általában a magból veszik az adatokat - megbízható és ellenőrzött forrásként -, azaz használja ennek az összetevőnek a szolgáltatását, hogy egyetlen űrlapra vigye az adatokat. Hívjuk az ilyen kirakatokat szabályos ... Bizonyos esetekben a kirakatok közvetlenül az átvételből vehetnek fel adatokat - elsődleges adatokkal (a forráskulcsokban). Ezt a megközelítést általában olyan helyi feladatoknál alkalmazzák, ahol a különböző rendszerekből történő adatkonszolidáció nem szükséges, és ahol az adatminőségnél nagyobb hatékonyságra van szükség. Az ilyen vitrineket ún üzemeltetési ... Egyes elemzési mutatók nagyon bonyolult számítási módszerekkel rendelkezhetnek. Ezért az ilyen nem triviális számításokhoz és átalakításokhoz az ún másodlagos vitrinek .
Bemutató réteg feladat- adatok előkészítése egy adott fogyasztó - BI platform, felhasználói csoport vagy külső rendszer - követelményei szerint.

A fentebb leírt rétegek egy állandó adattárolási területből, valamint egy szoftvermodulból állnak az adatok betöltésére és átalakítására. Ez a rétegekre és régiókra való felosztás logikus. Fizikailag ezeknek az összetevőknek a megvalósítása eltérő lehet - akár különböző platformokat is használhat adatok tárolására vagy átalakítására különböző rétegekben, ha ez hatékonyabb.
A tárolóterületek technikai (puffertáblákat) tartalmaznak, amelyeket az adatok átalakításának folyamatában használnak és céltáblák amire a fogyasztó komponens utal. Jó gyakorlat, ha nézetekkel "lefedi" a céltáblákat. Ez megkönnyíti a rendszer későbbi karbantartását és fejlesztését. Mindhárom réteg céltábláiban szereplő adatok speciális technikai mezőkkel (metaattribútumokkal) vannak megjelölve, amelyek az adatbetöltési folyamatok támogatására, valamint a raktárban lévő adatfolyamok információs ellenőrzésének lehetővé tételére szolgálnak.

Ezenkívül 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. Egyik legfontosabb feladata a vezérlési funkció - az "egységes játékszabályok" biztosítása a teljes rendszer egészére vonatkozóan, meghagyva a jogot arra, hogy a fentiekben leírt rétegek mindegyikének megvalósításához különböző lehetőségeket alkalmazzon - beleértve. különböző technológiákat használnak az adatok betöltésére és feldolgozására, különböző tárolási platformokat stb. Nevezzük szolgáltatási réteg ... Nem tartalmaz üzleti adatokat, de saját tárolási struktúrákkal rendelkezik - metaadatterületet tartalmaz, valamint egy területet az adatminőséggel való munkához (és esetleg más struktúrákhoz, 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 rendszer fejlesztésének irányíthatóságát:

• csökken az egyik vagy másik komponens funkcionalitásának fejlesztőjének bonyolult feladat (nem szabad egyszerre megoldania a külső rendszerekkel való integráció kérdéseit, és át kell gondolnia az adatok tisztítására vonatkozó eljárásokat, és meg kell gondolnia az adatok a fogyasztók számára) - a feladat könnyebben lebontható, kiértékelhető és kis szállításra képes;
• csatlakozhat a különböző előadóművészek (sőt csapatok, vagy vállalkozók) munkájához - mert ez a megközelítés lehetővé teszi a feladatok hatékony párhuzamba állítását, csökkentve azok kölcsönös befolyását egymásra;
• a folyamatos szakaszolás lehetővé teszi az adatforrások gyors összekapcsolását anélkül, hogy megtervezné a teljes tárgyterület teljes magját vagy kirakatait, majd fokozatosan kiegészítené a fennmaradó rétegeket a prioritásoknak megfelelően (ráadásul az adatok már a tárolóban lesznek - a rendszer számára elérhető elemzők, ami nagyban megkönnyíti a tároló későbbi fejlesztésének feladatait);
• a mag jelenléte lehetővé teszi az adatminőséggel kapcsolatos minden munka (valamint a lehetséges hibák és hibák) elrejtését 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 kirakatok számára, elkerülheti az adatokat konvergencia problémák a közös algoritmusok egy helyen történő megvalósítása miatt;
• a marts kiválasztása lehetővé teszi, hogy figyelembe vegye a különböző részlegek felhasználóinak eltéréseit és az adatok megértésének sajátosságait, és a BI követelményekhez való kialakításuk lehetővé teszi nemcsak az összesített számok kiadását, hanem az adatok érvényesítésének biztosítását azáltal, hogy fúrja le az elsődleges mutatókat;
• a szolgáltatási réteg jelenléte lehetővé teszi a végpontok közötti adatelemzést (adatvonal), az egységes adatellenőrzési eszközök használatát, az általános megközelítéseket a változások delta kiemelésére, az adatminőséggel, a terheléskezeléssel, a megfigyeléssel és a hibadiagnosztikai eszközökkel , és felgyorsítja a problémák megoldását.

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

• a forrásrendszerek változásai feldolgozásra kerülnek a fázis során - a kernelben csak azok az adatfolyamok módosulnak, amelyeket ezek az átmeneti táblák befolyásolnak, a kirakatokra gyakorolt ​​hatás minimális vagy nincs;
• A vásárlói igények változásait többnyire a kirakatokban dolgozzák fel (ha ez nem igényel további információkat, amelyek még nincsenek az üzletben).

Ezután áttekintjük a fent bemutatott összetevőket, és részletesebben megvizsgáljuk őket.

A rendszer magja

Kezdjük a közepétől - a rendszer magját vagy a középső réteget. Core Rétegként van megjelölve. A mag az adatok konszolidációjának szerepét tölti be - egységes struktúrákat, referenciakönyveket, kulcsokat hoz. Itt történik az adatminőséggel kapcsolatos fő munka - tisztítás, átalakítás, egyesítés.

Ennek az összetevőnek a jelenléte lehetővé teszi az adatfolyamok újrafelhasználását, amelyek a forrásrendszerektől kapott elsődleges adatokat bizonyos egységes formátummá alakítják át, az általános szabályokat és algoritmusokat követve, és nem ismételhetik meg ugyanazon funkciók megvalósítását külön -külön minden alkalmazásboltban, az erőforrások nem hatékony felhasználása mellett eltéréseket is okozhat az adatokban.
A lerakat magja egy adatmodellben valósul meg, amely általában a forrásrendszerek modelljeitől, valamint a fogyasztók formátumától és struktúrájától eltér.

Raktári alapmodell és vállalati adatmodell

A középső tárolóréteg fő gondja a stabilitás. Éppen ezért a fő hangsúly itt az adatmodellön van. Általában "vállalati adatmodellnek" nevezik. Sajnos a mítoszok és abszurditások egyfajta glóriája alakult ki körülötte, ami néha az építés teljes megtagadásához vezet, de hiába.

1. mítosz. A vállalati adatmodell hatalmas modell, több ezer entitással (táblával).
Tulajdonképpen. Bármely tárgykörben, bármely üzleti területen, bármely cég adataiban, még a legösszetettebb is, kevés alapvető entitás található - 20-30.

2. mítosz. Nincs szükség semmilyen "saját modell" kifejlesztésére - ipari referenciamodellt vásárolunk -, és mindent ennek megfelelően teszünk. Pénzt költünk - de garantált eredményt kapunk.
Tulajdonképpen. A referenciamodellek valóban nagyon hasznosak lehetnek, mert iparági tapasztalatokat tartalmaznak e terület modellezésében. Tőlük lehet ötleteket, megközelítéseket, névadási gyakorlatokat szedni. Ellenőrizze a terület "lefedettségének mélységét", hogy valami fontos ne maradjon figyelmen kívül. De nem valószínű, hogy képesek leszünk egy ilyen modellt "a dobozból" használni - ahogy van. Ez ugyanaz a mítosz, mint például egy ERP rendszer (vagy CRM) megvásárlása és megvalósítása minden "szigorítás nélkül". Az ilyen modellek értéke abban rejlik, hogy alkalmazkodnak az adott üzletághoz, a vállalathoz.

3. mítosz. Egy alapvető tárolómodell kidolgozása sok hónapot vehet igénybe, ez idő alatt a projekt ténylegesen lefagy. Ráadásul őrülten sok találkozót és sok embert igényel.
Tulajdonképpen. A tároló modellt a tárolóval iteratívan, darabonként lehet fejleszteni. A le nem fedett területekhez "bővítési pontokat" vagy "csonkokat" kell beállítani. néhány "univerzális mintát" alkalmaznak. Ugyanakkor tudnod kell, mikor kell abbahagyni, hogy ne 4 asztaltól szerezz szuperuniverzális dolgot, amelybe nehéz "berakni az adatokat", és (még nehezebb) hozzájutni. És ami rendkívül szuboptimális a teljesítmény szempontjából.

Valóban időbe telik a modell kifejlesztése. De ez nem az "entitások rajzolására" fordított idő - ez az idő szükséges a tárgykör elemzéséhez, az adatok elrendezésének megértéséhez. Éppen ezért az elemzők nagyon szorosan részt vesznek ebben a folyamatban, és különböző üzleti szakértők is részt vesznek. És ezt pontosan, szelektíven végzik. És nem úgy, hogy eszeveszett számú ember részvételével találkozókat szervez, hatalmas kérdőíveket küld ki stb.
A jó üzleti és rendszerelemzés kulcsfontosságú az alapvető raktári modell felépítéséhez. Sok mindent meg kell érteni: hol (milyen rendszerekben) keletkeznek adatok, hogyan működnek, milyen üzleti folyamatokban keringenek stb. A minőségi elemzés soha nem ártott egyetlen rendszernek. Inkább ellenkezőleg, a problémák a „fehér foltokból” származnak, amelyekben mi értjük.

Az adatmodell kifejlesztése nem egy új dolog kitalálásának és feltalálásának folyamata. Valójában az adatmodell már létezik a vállalatnál. A tervezési folyamat pedig inkább „ásatásra” hasonlít. A modellt gondosan és gondosan kivonják a vállalati adatok "talajából", és strukturált formába öntik.

4. mítosz. Üzletünk olyan dinamikus a vállalatunkban, és minden olyan gyorsan változik, hogy felesleges modellt készítenünk - elavulttá válik, mielőtt üzembe helyezzük ezt a rendszert.
Tulajdonképpen. Ne feledje, hogy a legfontosabb tényező a stabilitás. És mindenekelőtt a modell topológiája. Miért? Mert ez az alkotóelem a központi és minden mást befolyásol. A stabilitás a kernelmodell feltétele is. Ha egy modell túl gyorsan elavul, akkor helytelenül tervezték. Fejlesztéséhez rossz megközelítéseket és „játékszabályokat” választottak. És ez minőségi elemzés kérdése is. A vállalati modell kulcsfontosságú entitásai ritkán változnak.
De ha eszünkbe jut, hogy a „Termékek” címtár helyett mondjuk cukrászsüteményeket árusító cégnek készítsünk „Édességet”, „Süteményt” és „Pite -t”. Majd amikor a pizza megjelenik az áruk listájában - igen, sok új táblázatot kell megadnia. És ez csak megközelítés kérdése.

5. mítosz. A vállalati modell létrehozása nagyon komoly, összetett és felelősségteljes üzlet. És ijesztő hibázni.
Tulajdonképpen. Az alapmodell, bár stabilnak kell lennie, még mindig nincs „fémbe öntve”. Mint minden más tervezési megoldás, szerkezete is felülvizsgálható és módosítható. Csak nem kell elfelejtenie ezt a minőséget. De ez egyáltalán nem jelenti azt, hogy „nem tudsz lélegezni rajta”. Ez pedig nem jelenti azt, hogy elfogadhatatlanok az ideiglenes megoldások és "csonkok", amelyeket újrahasznosításra kell tervezni.

6. mítosz. Ha adatforrásunk például egy referenciaadat -rendszer (vagy törzsadat -kezelő rendszer - MDM), akkor annak már baráti módon meg kell felelnie a vállalati modellnek (különösen, ha nemrég tervezték, és nem volt ideje szerezzenek "oldalt", "hagyományokat" és ideiglenes kunyhókat). Kiderül, hogy ebben az esetben - nincs szükségünk kernelmodellre?
Tulajdonképpen. Igen, ebben az esetben nagyban megkönnyíti a tároló alapmodelljének felépítését. kész felső szintű koncepcionális modellt követünk. De egyáltalán nem kizárt. Miért? Mert egy bizonyos rendszer modelljének felépítésekor bizonyos saját szabályok érvényesek - milyen típusú táblákat kell használni (minden entitáshoz), hogyan kell az adatokat verziószámozni, milyen részletességgel kell megőrizni az előzményeket, milyen metaattribútumokat (milyen technikai mezőket kell használni) ) stb.

Ezen túlmenően, bármennyire csodálatos és mindenre kiterjedő referenciaadat- és MDM-rendszerrel rendelkezünk, általában a többi könyvviteli rendszerben "hasonló" helyi könyvtárak létezéséhez kapcsolódó árnyalatok lesznek. És ezt a problémát, akár akarjuk, akár nem, a tárhelyen kell megoldani - elvégre itt gyűjtik a jelentéseket és az elemzéseket.

Elsődleges adatréteg (vagy historizált szakaszos vagy működési réteg)

Rajta elsődleges adatréteg. Ennek az összetevőnek a szerepe: integráció a forrásrendszerekkel, az elsődleges adatok betöltése és tárolása, valamint az előzetes adattisztítás - a formátumra és a logikai vezérlésre vonatkozó szabályok betartásának ellenőrzése, rögzítve a "kölcsönhatási felületről szóló megállapodásban" a forrással .
Ezenkívül ez az összetevő megold egy nagyon fontos feladatot a lerakat számára - a "változások valódi delta" kiosztását - függetlenül attól, hogy a forrás lehetővé teszi -e az adatok változásának nyomon követését, vagy sem, és hogyan (milyen kritérium alapján lehet "elkapni") ). Amint az adatok szakaszba kerültek - az összes többi réteg esetében a delta -allokáció kérdése már egyértelmű - köszönhetően a metatribútumokkal ellátott címkézésnek.

Az ebben a rétegben lévő adatokat a forrásrendszerhez a lehető legközelebb eső struktúrákban tárolják - annak érdekében, hogy az elsődleges adatok a lehető legközelebb maradjanak eredeti formájukhoz. Ennek az összetevőnek egy másik neve "operációs réteg".
Miért nem használja csak a jól bevált „színpadra állítás” kifejezést? A tény az, hogy korábban, a "big data és a VLDB korszaka" előtt a lemezterület nagyon drága volt - és gyakran az elsődleges adatok, ha megőrzik őket, csak korlátozott ideig voltak. És gyakran a "színpadra állítás" nevet hívják tisztítható puffer.
Most a technológiák léptek előre - és megengedhetjük magunknak, hogy ne csak az összes elsődleges adatot tároljuk, hanem a lehetséges részletességgel történelmessé tegyük őket. Ez nem jelenti azt, hogy ne irányíthatnánk az adatok növekedését, és nem szüntethetjük meg az információ életciklusának kezelésének szükségességét, optimalizálva az adattárolás költségeit, a felhasználás "hőmérsékletétől" függően - azaz. olcsóbb adathordozókra és tárolóplatformokra viszi a „hideg adatokat”, amelyekre kevésbé van igény.

Mit ad nekünk a "historizált színpadra állítás" jelenléte:

• a hibázás lehetősége (struktúrákban, transzformációs algoritmusokban, a történelem részletességében) - ha a tároláshoz rendelkezésre állási zónában teljesen historizált elsődleges adatok állnak rendelkezésre, mindig újratölthetjük tábláinkat;
• gondolkodási lehetőség - időt szakíthatunk arra, hogy a kernel nagy töredékét pontosan a tárolási fejlesztés ezen iterációjában dolgozzuk ki, mivel a mi rendezésünkben mindenesetre lesz, és egyenletes időhorizont mellett (lesz egy "történelmi referencia" pont);
• az elemzés lehetősége - még azokat az adatokat is elmentjük, amelyek már nincsenek a forrásban - ott felülírhatók, elmehetnek az archívumba stb. - nálunk továbbra is rendelkezésre állnak elemzésre;
• információs ellenőrzés lehetősége - a legrészletesebb kezdeti információknak köszönhetően később megérthetjük, hogyan működött nálunk a letöltés, hogy végül ilyen számokat kaptunk (ehhez a metatribútumokkal és a megfelelő metaadatok, amelyeken a letöltés működik - ezt a szolgáltatási réteg határozza meg).

Milyen nehézségek merülhetnek fel a "történelmivé tett színpad" építésekor:

• kényelmes lenne követelményeket szabni ennek a rétegnek a tranzakciós integritására, de a gyakorlat azt mutatja, hogy ezt nehéz elérni (ez azt jelenti, hogy ezen a területen nem garantáljuk a szülői és utódtáblák hivatkozási integritását) - az integritás igazítása a következő rétegek;
• ez a réteg nagyon nagy térfogatokat tartalmaz (a tárhelyen a legnagyobb térfogatú - az analitikai struktúrák minden redundanciája ellenére) -, és képesnek kell lennie kezelni az ilyen mennyiségeket - mind a terhelés, mind a kérések tekintetében (különben komolyan rontja a teljes tároló teljesítményét).

Mit lehet még érdekes mondani erről a rétegről.
Először is, ha eltávolodunk a „végpontok közötti betöltési folyamatok” paradigmájától, akkor a „karaván az utolsó teve sebességével mozog” szabály már nem működik számunkra, pontosabban elhagyjuk a „lakókocsit” elvét, és váltson át a „szállítószalag” elvére: a forrásból vettük az adatokat - helyezzük be a rétegébe - készen állunk a következő adag bevételére. Ez azt jelenti
1) nem várjuk meg, hogy a feldolgozás más rétegeken megtörténjen;
2) nem függünk a más rendszerek adatszolgáltatásának ütemtervétől.
Egyszerűen fogalmazva, beütemezünk egy betöltési folyamatot, amely egy forrásból szerzi be az adatokat a hozzájuk való csatlakozás meghatározott módján keresztül, ellenőrzi, kivonja a delta -t - és helyezi az adatokat a célközvetítő táblákba. És ennyi.

Másodszor, ezek a folyamatok, mint látható, nagyon egyszerűek - mondhatni triviálisan, a logika szempontjából. Ez azt jelenti, hogy nagyon jól optimalizálhatók és paraméterezhetők, csökkentve rendszerünk terhelését és felgyorsítva a források csatlakoztatásának folyamatát (fejlesztési idő).
Ahhoz, hogy ez megtörténhessen, nagyon jól kell ismernie annak a platformnak a technológiai jellemzőit, amelyeken ez az alkatrész működik - és ezután nagyon hatékony eszközt készíthet.

Bemutató réteg

A Data Mart Layer felelős a végfelhasználók - emberek vagy rendszerek - adatainak előkészítéséért és biztosításáért. Ezen a szinten a lehető legnagyobb mértékben figyelembe veszik a fogyasztó igényeit - logikai (fogalmi) és fizikai. A szolgáltatásnak pontosan azt kell nyújtania, amire szükség van - se többet, se kevesebbet.

Ha a fogyasztó külső rendszer, akkor általában szabályozza a 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 előkészített adattárház bemutatót hozott létre, amely lehetővé tette a növekményes adatgyűjtést (metaattribútumokkal történő megjelölés a változtatások delta későbbi elosztásához), a fogyasztói rendszer pedig maga ellenőrzi és felelős azért, hogy hogyan használja ezt a kirakatot. Van azonban néhány sajátosság: ha a rendszer nem rendelkezik aktív összetevővel az adatgyűjtéshez - vagy külső összetevőre van szükség, amely elvégzi az integrációs funkciót, vagy a tároló "integrációs platformként" fog működni - és biztosítja a megfelelő növekményt az adatok feltöltése tovább - a tárhelyen kívül. Itt sok árnyalat jelenik meg, és az interfész interakció szabályait mindkét félnek át kell gondolnia és meg kell értenie (azonban, mint mindig, amikor az integrációról van szó). Általában rutinszerű adattisztítást / archiválást alkalmaznak az ilyen adattérképekre (ritkán szükséges, hogy ezeket az "átviteli adatokat" hosszú ideig tárolják).

Az elemzési feladatok szempontjából a legfontosabbak az "embereknek szóló" kirakatok - pontosabban azoknak a BI -eszközöknek, amelyekkel dolgoznak.
Van azonban egy „különösen fejlett felhasználók” kategóriája - elemzők, adatkutatók -, akiknek nincs szükségük BI eszközökre vagy szabályozási folyamatokra a külső speciális rendszerek kitöltéséhez. Szükségük van valamilyen "közös kirakatra" és "saját homokozóra", ahol saját belátásuk szerint táblázatokat és átalakításokat készíthetnek. Ebben az esetben a tároló felelőssége annak biztosítása, hogy ezek a közös kirakatok az előírásoknak megfelelően tele legyenek adatokkal.
Külön ki lehet emelni 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 az adattudósok is dolgoznak velük. A tárolás esetében a feladat - ismét - a megállapodás szerinti formátumú kirakatok betöltésére szolgáló szolgáltatás támogatása.

Visszatérve azonban az analitikus vitrinekhez. Ezek azok, amelyek az adatréteg tárolótervezői szempontjából érdekesek.
Véleményem szerint Ralph Kimball megközelítése a legjobb időpróbált megközelítés az adattérképek tervezéséhez, amelyhez szinte minden BI platform "kihegyezett". Az úgynevezett dimenziós modellezés - többdimenziós modellezés. Sok publikáció található ebben a témában. Például az alapvető szabályok megtalálhatók Marga Ross kiadványában. És természetesen ajánlhat a többdimenziós modellező gurutól. Egy másik hasznos forrás a Kimball tippjei
A kirakatok létrehozásának többdimenziós megközelítését olyan jól leírták és kidolgozták - mind a "módszer -evangélisták", mind a vezető szoftvergyártók részéről, hogy nincs értelme itt részletesebben foglalkozni ezzel - az eredeti forrás mindig előnyösebb.

Csak egy hangsúlyt szeretnék emelni. A "jelentéskészítés és elemzés" más. Vannak "nehéz jelentések" - előre megrendelt jelentések, amelyek fájlok formájában jönnek létre, és a megadott szállítási csatornákon keresztül jutnak el a felhasználókhoz. És akkor vannak műszerfalak - BI műszerfalak. Ezek lényege, hogy webes alkalmazások. Ezen alkalmazások válaszideje pedig ugyanaz, mint bármely más webes alkalmazásé. Ez azt jelenti, hogy a BI panel frissítési ideje általában másodperc, nem perc. Ezt fontos szem előtt tartani a megoldás tervezésekor. Hogyan lehet ezt elérni? A standard optimalizálási módszer: megvizsgáljuk, hogy miből áll a válaszidő, és mit tudunk befolyásolni. Mi a legtöbb elvesztegetett idő? Fizikai (lemezes) adatbázis -leolvasásokhoz, hálózaton keresztüli adatátvitelhez. Hogyan csökkenthető az egy kérésben olvasott és továbbított adatmennyiség? A válasz nyilvánvaló és egyszerű: vagy összesítenie kell az adatokat, vagy szűrőt kell alkalmaznia a lekérdezésben részt vevő tényleges táblázatok nagy tábláira, és ki kell zárnia a nagy táblák összekapcsolását (a ténytáblázatokra való hivatkozásoknak csak dimenziókat kell megadniuk) .

Mire való a BI? Hogyan kényelmes? Miért hatékony a többdimenziós modell?
A BI lehetővé teszi a felhasználó számára az úgynevezett ad hoc lekérdezések futtatását. Mit jelent? Ez azt jelenti, hogy nem ismerjük előre a pontos kérést, de tudjuk, hogy mely mutatókat milyen szempontok szerint kérheti a felhasználó. A felhasználó létrehoz egy ilyen lekérdezést a megfelelő BI szűrők kiválasztásával. A BI fejlesztő és a kirakattervező feladata pedig az, hogy olyan logikát biztosítson az alkalmazás számára, hogy az adatokat vagy szűrjék, vagy összesítsék, megakadályozva azt a helyzetet, amikor túl sok adatot kérnek - és az alkalmazás "lefagy". Általában összesített számokkal kezdődnek, majd mélyebbre ásnak a részletesebb adatokba, de útközben telepítik a szükséges szűrőket.

Nem mindig elég csak a „megfelelő csillag” felépítése és a BI kényelmes felépítése. Néha valahol denormalizálást kell alkalmaznia (miközben visszanéz, hogyan befolyásolja ez a terhelést), és valahol másodlagos kirakatokat és aggregátumokat kell készítenie. Adjon hozzá indexeket vagy előrejelzéseket valahol (a DBMS -től függően).

Így a "próba és hiba" révén olyan struktúrát kaphat, amely optimális a BI számára - amely figyelembe veszi mind a DBMS, mind a BI platform sajátosságait, valamint a felhasználó adatmegjelenítési követelményeit.
Ha az adatokat a "magból" vesszük, akkor a kirakatok ilyen jellegű feldolgozása helyi jellegű lesz, anélkül, hogy bármilyen módon befolyásolná a közvetlenül a forrásrendszerekből nyert elsődleges adatok összetett feldolgozását - csak "áthelyezzük" az adatokat a a BI számára kényelmes formátum. És megengedhetjük magunknak, hogy ezt sokszor, különböző módon, különböző követelményeknek megfelelően tegyük meg. Ezt sokkal egyszerűbb és gyorsabb kerneladatokon megtenni, mint az "elsődlegesből" gyűjteni (amelynek szerkezete és szabályai, mint tudjuk, szintén "lebeghetnek").

Szolgáltatási réteg

A Szolgáltatási réteg felelős az általános (szolgáltatási) funkciók megvalósításáért, amelyek felhasználhatók az adatok különböző tárolási rétegekben történő feldolgozására - terheléskezelés, adatminőség -menedzsment, problémadiagnosztikai és felügyeleti eszközök stb.
Ennek a szintnek a jelenléte á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 - adatbetöltés -vezérlési mechanizmus;
• adatminőségi terület - off -line adatminőségi ellenőrzések végrehajtásához (azaz azok, amelyek nincsenek közvetlenül beépítve az ETL folyamatokba).

A letöltéskezelési folyamatot különböző módon rendezheti. Az egyik lehetséges megközelítés a következő: a teljes tároló táblát modulokra osztjuk. A modul csak egy rétegű táblákat tartalmazhat. Az egyes modulokban található táblázatok külön folyamatban töltődnek be. Nevezzük ellenőrzési folyamat ... A vezérlési folyamat kezdete a saját ütemterve szerint van beállítva. A vezérlési folyamat szervezi az atomfolyamatok hívásait, amelyek mindegyike betölt egy céltáblát, és tartalmaz néhány általános lépést is.
Nyilvánvaló, hogy elegendő egyszerűen az átmeneti táblákat modulokra osztani - forrásrendszerek szerint, vagy inkább csatlakozási pontjaik szerint. De a kernel számára ezt már nehezebb megtenni. ott biztosítanunk kell az adatok integritását, ami azt jelenti, hogy figyelembe kell vennünk a függőségeket. Azok. ütközések lesznek, amelyeket meg kell oldani. És különböző módszerek vannak ezek megoldására.

A terheléskezelés fontos pontja a hibakezelés következetes megközelítésének kialakítása. A hibákat súlyosságuk szerint osztályozzák. Kritikus hiba esetén a folyamatnak le kell állnia, és a lehető leghamarabb, mert előfordulása jelentős problémát jelez, amely adatvesztéshez vezethet a tárolóban. Így a terheléskezelés nemcsak a folyamatok elindításáról, hanem azok leállításáról, valamint az idő előtti (tévedésből származó) indítás megakadályozásáról is szól.

A szolgáltatási réteg működéséhez egy speciális metaadat -szerkezet jön létre. Ez a terület tárolja a betöltési folyamatokról, a betöltött adathalmazokról, a növekmény fenntartásához használt ellenőrzőpontokról (melyik folyamat melyik pontra olvasta be) és a rendszer működéséhez szükséges egyéb szolgáltatási információkat.
Fontos megjegyezni, hogy minden céltábla minden rétegben egy speciális metamezők halmazával van megjelölve, amelyek közül az egyik az ezt a sort frissítő folyamat azonosítója. A lerakaton belüli táblázatok esetében ez a folyamatjelzés lehetővé teszi a változtatások delta következetes kiemelését. Amikor adatokat tölt be az elsődleges adatrétegbe, a helyzet bonyolultabb - a delta -kiosztási algoritmus különböző betöltött objektumok esetén eltérő lehet. De az elfogadott változtatások feldolgozásának logikája és a mag- és kirakatcélokra történő céltáblákba való gurítása sokkal bonyolultabb, mint a színpadra állításnál, ahol minden meglehetősen triviális - könnyű paraméterezni és átgondolni az újrafelhasználható szabványos lépéseket (eljárásokat).

Itt nem azt a feladatot tűzem ki, hogy teljes körűen lefedjem ezt a témát - letöltések szervezése -, csak azokat az ékezeteket emelem ki, amelyekre érdemes odafigyelni.
Ez a megközelítés csak az egyik lehetőség. Elég érzékeny. "Koncepcionális prototípusa" pedig a Toyota szállítószalagja és a just-in-time rendszer volt. Azok. Itt eltávolodunk a széles körben elterjedt paradigmától, amely kizárólag az "éjszakai adatletöltés", és kis adagokban töltjük le a nap folyamán - amint az adatok különböző forrásokban készen állnak: ami jött - letöltötték. Ugyanakkor számos párhuzamos folyamat fut. A friss adatok "forró farka" pedig folyamatosan "villog" - és idővel ki is egyenlít. Ezt a funkciót figyelembe kell vennünk. És ha szükséges, alakítson ki egyéni vitrineket "szeletekkel", ahol már minden holisztikus. Azok. lehetetlen egyszerre elérni a hatékonyságot és a következetességet (integritást). Egyensúlyra van szükségünk - valahol egy dolog fontos, valahol máshol.

Feltétlenül biztosítani kell a naplózási és megfigyelési lehetőségeket. Jó gyakorlat a gépelt események használata, ahol különböző paramétereket állíthat be és testreszabhatja az értesítési rendszert - feliratkozhat bizonyos eseményekre. Mivel nagyon fontos, hogy amikor a rendszergazda beavatkozására van szükség, a lehető leghamarabb tudjon róla, és megkapja az összes szükséges diagnosztikai információt. A naplók felhasználhatók a tények utáni problémák elemzésére is, valamint a rendszerhibák incidenseinek kivizsgálására, beleértve a adat minőség.

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

Miért fontos figyelni az adatmodell tervezésére minden olyan rendszer fejlesztésekor, ahol adatbázis van (és különösen egy raktárban)? Miért nem dobja el az asztalokat bárhová - akár szövegszerkesztőbe is? Miért van szükségünk ezekre a képekre?
Furcsa módon még a tapasztalt fejlesztők is feltesznek ilyen kérdéseket.
Valójában igen, semmi sem akadályozza meg a táblázatok felvázolásában - és azok használatának megkezdésében. Ha ... ha egyidejűleg fejben (!) A fejlesztőnek koherens általános képe van az általa faragott szerkezetről. Mi van, ha több fejlesztő van? Mi van, ha valaki más használja ezeket a táblázatokat? És mi van, ha telik az idő - a személy elhagyja ezt a területet, majd ismét visszatér rá?

Kitalálod modell nélkül? Elvileg lehet. És kitalálni, és "kitalálni a képeket egy papírlapra", és "felmosni - rendezni" az adatokat. De sokkal könnyebb, világosabb és gyorsabb egy kész műtárgy - egy adatmodell - használata. És megérteni a "készülék logikáját" - pl. jó lenne, ha általános játékszabályok lennének.

És a legfontosabb még az sem. A legfontosabb, hogy egy modell megtervezésekor kénytelenek vagyunk (csak lehetőségek nélkül!) A tárgykör alaposabb és mélyebb tanulmányozása, az adateszköz jellemzői és felhasználása különböző üzleti esetekben. És azokat a kérdéseket, amelyeket könnyedén "félretoltunk", mint összetett, "elmosódott" jeleink dobásával, anélkül, hogy pontosan megpróbálnánk tervezés modell - kénytelenek leszünk szállítani és dönteni most, elemzéskor és tervezéskor, és nem később - mikor készítünk jelentéseket, és minden alkalommal gondolkodunk azon, hogy „hogyan csökkenthetjük az összeférhetetlenséget” és „újra feltaláljuk a kereket”.

Ez a megközelítés az egyik olyan mérnöki gyakorlat, amely lehetővé teszi törésgátló rendszerek létrehozását. Mivel egyértelműen elrendezettek, átláthatóak, kényelmesek a fejlesztéshez, és a „törékenységük határai” is azonnal láthatók - pontosabban megbecsülheti a „katasztrófa mértékét”, amikor új követelmények jelennek meg, és az újratervezéshez szükséges időt (ha szükséges).
Így az adatmodell az egyik fő műtermék, amelyet fenn kell tartani a rendszer fejlesztése során. Békés úton minden elemzőnek, fejlesztőnek stb. „Asztalra kell kerülnie”. - mindenki, aki részt vesz a rendszerfejlesztési projektekben.

Az adatmodellek tervezése nagy és különálló téma. A tárolótervezésnek két fő megközelítése létezik.
A megközelítés jól működik a kernel számára Entitás-kapcsolat - ha normalizált (3NF) modellt építenek a tárgykör, vagy inkább annak kiválasztott területe tanulmányozása alapján. Ugyanaz a "vállalati modell" játszik itt, amelyet fentebb tárgyaltunk.

A vitrinek tervezésekor alkalmas többdimenziós modell ... Ez a megközelítés jól illeszkedik az üzleti felhasználók megértéséhez - mert ez egy olyan modell, amely egyszerű és kényelmes az emberi észlelés számára - az emberek érthető és ismerős metrika (indikátorok) fogalmakkal és szakaszokkal működnek, amelyek alapján elemzik őket. Ez lehetővé teszi, hogy egyszerűen és egyértelműen felépítse a követelmények gyűjtésének folyamatát - rajzolunk egy sor „szakaszok és mutatók mátrixát”, kommunikálva a különböző osztályok képviselőivel. És akkor egy struktúrába - az „elemzési modellbe” - hozzuk: 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.

Ezután nagyon könnyű elmenni a fizikai modellhez, optimalizáló elemeket hozzáadva, figyelembe véve a DBMS sajátosságait. Például az Oracle esetében ez particionálás, indexek halmaza stb. A Vertica esetében más technikákat alkalmaznak - válogatás, szegmentálás, tagolás.
Ezenkívül speciális denormalizációra is szükség lehet - amikor szándékosan vezetünk be redundanciát az adatokba, aminek köszönhetően javítjuk a lekérdezési teljesítményt, ugyanakkor bonyolítjuk az adatok frissítését (mivel a redundanciát figyelembe kell venni és fenn kell tartani az adatok betöltése során) folyamat). Talán a teljesítmény javítása érdekében további összesített táblákat is létre kell hoznunk, vagy olyan kiegészítő DBMS -szolgáltatásokat kell használnunk, mint a Vertica előrejelzései.

Tehát a raktári adatok modellezésekor valójában számos problémát oldunk meg:

• az alapvető fogalmi (logikai) modell felépítésének feladata - rendszer- és üzleti elemzés - a tárgykör kutatása, a részletekbe való belemerülés, valamint az "élő adatok" árnyalatainak és üzleti felhasználásának figyelembe vétele;
• az elemzési modell - majd a koncepcionális (logikai) kirakatmodell felépítésének feladata;
• a fizikai modellek építésének feladata az adatok redundanciájának kezelése, optimalizálás, figyelembe véve a DBMS sajátosságait a lekérdezésekhez és az adatok betöltéséhez.

A fogalmi modellek kidolgozása során előfordulhat, hogy nem vesszük figyelembe egy adott DBMS sajátosságait, amelyhez adatbázisstruktúrát tervezünk. Ezenkívül egy koncepcionális modell segítségével több fizikai modellt is létrehozhatunk - különböző DBMS -ekhez.

Összefoglaljuk.

• Az adatmodell nem „szép képek” gyűjteménye, és a tervezési folyamat nem a rajzolási folyamat. A modell tükrözi a területről való megértésünket. Az összeállításának folyamata pedig annak tanulmányozása és kutatása. Ez elpazarolt idő. És egyáltalán nem "rajzolni és festeni".
• Az adatmodell egy tervezési műtárgy, az információ strukturált cseréjének módja a csapat tagjai között. Ehhez mindenkinek világosnak kell lennie (ezt a jelölés és a magyarázat biztosítja), és rendelkezésre kell állnia (közzé kell tenni).
• Az adatmodell nem egyszer jön létre és lefagy, hanem a rendszerfejlesztés során jön létre és fejlődik. Fejlesztésének szabályait mi magunk határozzuk meg. És megváltoztathatjuk őket, ha látjuk - hogyan kell ezt jobban, könnyebben és hatékonyabban csinálni.
• Az adatmodell (fizikai) lehetővé teszi az optimalizálásra irányuló legjobb gyakorlatok összevonását és kiaknázását - azaz használja azokat a technikákat, amelyek már működtek ehhez a DBMS -hez.

Adattárház projektek jellemzői

Vessünk egy pillantást azon projektek jellemzőire, amelyek keretében a vállalat adattárházakat épít és fejleszt. És nézzük őket az építészeti szempont hatása szempontjából. Miért fontos, hogy az ilyen projektek építészetet építsenek, és a kezdetektől fogva? És az átgondolt architektúra jelenléte 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 a folyamat kiszámíthatóbbá tételét.

Az adattárház egyedi szoftver

Az adattárház mindig "egyedi fejlesztés", nem pedig dobozos megoldás. Igen, vannak iparág-specifikus BI-alkalmazások, amelyek tartalmaznak referenciaadat-modellt, előre konfigurált ETL-folyamatokat a közös forrásokból (például ERP-rendszerek), szabványos BI-panelek és jelentések halmazát. 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ókkal, és soha nem láttam ilyen történetet. Mindig vannak árnyalatok, amelyek a vállalat egyedi jellemzőihez kapcsolódnak - mind az üzleti, mind az informatikai környezethez. Ezért abban a reményben, hogy az architektúrát a megoldást szállító "szállító" biztosítja, kissé meggondolatlan. Az ilyen rendszerek felépítése gyakran „érlelődik” a szervezeten belül. Vagy a kivitelező cég szakemberei alkotják, amely a projekt fő végrehajtója.

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

Az adattárház számos forrásrendszerből tölt be és dolgoz fel információkat. És ahhoz, hogy "baráti kapcsolatokat" tartson velük, rendkívül óvatosnak kell lenni velük. Különösen minimálisra kell csökkenteni a forrásrendszerek terhelését, figyelembe kell venni a "rendelkezésre állás és nem elérhetőség" ablakokat, ki kell választani az interakciós felületeket, figyelembe véve azok architektúráját stb. Ekkor a tároló a lehető leghamarabb és a szükséges gyakorisággal tudja felvenni az adatokat. Ellenkező esetben "átültetik" a biztonsági áramkörbe, amely nem a legtöbb működési frekvencián frissül.
Ezenkívül figyelembe kell venni az "emberi tényezőt". Az integráció nem csak a gépek kölcsönhatásáról szól. Ez az emberek közötti kommunikáció is.

Az Adattárház egy együttműködési projekt

Egy nagyvállalatnál ilyen rendszert ritkán tud csak egy csapat megvalósítani. Általában több csapat dolgozik itt, amelyek mindegyike megold egy adott problémát.

Az architektúrának lehetővé kell tennie a párhuzamos munkájuk megszervezését, miközben meg kell őriznie integritását, és el kell kerülnie, hogy ugyanazok a funkciók különböző helyeken, különböző személyek részéről megkettőződjenek. A felesleges erőfeszítések mellett az ilyen párhuzamosság később adatok eltéréséhez vezethet.

Ezen túlmenően, amikor ennyi ember és csapat, gyakran szétszórtan vesz részt a rendszerfejlesztés folyamatában, elkerülhetetlenül felmerül a kérdés: hogyan lehet kommunikációt és információs interakciót kialakítani közöttük. Minél szabványosabb és érthetőbb megközelítéseket és gyakorlatokat alkalmaznak, annál könnyebb, kényelmesebb és hatékonyabb az ilyen munka megszervezése. És többek között érdemes elgondolkodni a "működő műtermékek" összetételén, amelyek között az adatraktárak # 1 adatmodellek (lásd az előző részt).

Az adattárház élettartama hosszabb, mint más rendszereké

Tisztázandó, hogy az állítás igaz egy "élő", működő, kulcsfontosságú forrásokkal integrált tárolóra, amely történelmi adatokat tartalmaz, és információs és elemzési szolgáltatásokat nyújt a vállalat számos részlegének.

Milyen okom van azt hinni?
Először is, a tároló építése nagyon erőforrás-igényes folyamat: a berendezések tényleges költségei, a szükséges technológiai szoftverek és fejlesztések engedélyei mellett a vállalat szinte minden rendszere és részlege is részt vesz ebben. Nagyon merész ötlet megismételni ezt az egész folyamatot a semmiből.

Másodszor, ha a tároló megfelelő architektúrával rendelkezik, akkor könnyen túlélheti a forrásrendszerek változásait, az új követelmények megjelenését a végfelhasználóktól és az adatmennyiségek növekedését.
Ha az architektúra helyes, az információáramlás átlátható, akkor egy ilyen rendszer hosszú ideig fejleszthető anélkül, hogy fennállna annak a kockázata, hogy a hatás értékelésének nehézségei miatt változtatások során elakad egy helyzetben.

Fokozatos iteratív fejlődés

Az utolsó dolog, amit az Ügyfél szeretne, ha belekeveredne a tároló történetébe, az, hogy egy vagy két évre befagyasztja a követelményeit, amíg egy teljes vállalati adatmodellt meg nem terveznek, az összes forrást nem kapcsolják össze stb.

Az ügyfelek szemében az adattárház gyakran abszolút szörnyetegnek tűnik - a rendszer feladatai, céljai és fejlesztési horizontja olyan terjedelmes. És az ügyfél gyakran attól tart, hogy "a költségvetésének rovására" az informatikai részleg megoldja néhány "saját problémáját". És ismét szembe kell néznünk az emberek közötti interakció kérdésével, valamint azzal a képességgel, hogy nyugodtan megfogalmazzuk álláspontunkat és tárgyaljunk.

Az illetékes építészeti megközelítések lehetővé teszik a rendszer iteratív fejlesztését, a funkcionalitás fokozatos növelését, anélkül, hogy több évig "fejlesztésbe" kezdenének, mielőtt eredményt adnának.

Bár meg kell jegyezni, hogy "csodák nem történnek meg" - és a "kezdet" is időt vesz igénybe. A tárolók esetében meglehetősen nagy lehet - mivel ezek nagy mennyiségű adatról van szó, ezek történelmi adatok - a régi időszakokra, amikor az információfeldolgozás szabályai eltérhetnek a jelenlegitől. Ezért elegendő időbe telik az elemző munka, a forrásrendszerekkel való interakció és számos "próba és hiba", beleértve a valós adatok terhelési tesztjét is.

Adattárházak - "többprojektes történet"

Nehéz egyetlen üzleti ügyfelet kiemelni egy adattárház számára. És úgy vélik (nem ok nélkül), hogy a raktárépítési projekt sikerének kulcstényezője a vállalat vezetésének - közvetlenül az első személynek - a támogatása.
Raktárt ritkán építenek és fejlesztenek egyetlen projekt részeként. Az adatok konszolidációjára és elemzésére általában különböző igények vannak, mögöttük 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 egy ilyen szó alkalmazható egy ilyen fiatal iparágra, mint az IT) és meglehetősen konzervatív. Ennek ellenére a fejlődés nem áll meg - és azok a korlátok, amelyek korábban a drága és lassú lemezek, a drága memória stb. - most eltávolították. Ugyanakkor elérkezett az idő néhány építészeti megközelítés felülvizsgálatára. Ezenkívül ez vonatkozik mind a technológiai platformokra, mind az ezeken alapuló alkalmazott rendszerek architektúrájára.

Itt fontos az egyensúly megteremtése - és az erőforrások és a tárolt információk viszonylag „zöld” megközelítésének fenntartása. Ellenkező esetben nagyon gyorsan félig strukturált "szemétdomb" -á alakíthatja a tárolót, amelyben, ha sikerül kitalálni, akkor elég sok erőfeszítéssel.
Igen, több lehetőségünk van, de ez nem jelenti azt, hogy meg kell tagadnunk az összes felhalmozott és idővel bevált gyakorlatot, amelyek egyértelműek, hogyan és miért kell használni, és "engedni kell minden rossz hírnek", csak a ködös kísértet vezetésével az "újításokról".
Az egyensúly megtartása azt jelenti, hogy új módszereket és megközelítéseket alkalmazunk ott, ahol új lehetőségeket nyitnak meg, de ugyanakkor a régóta bevált módszereket is használnak - a nem törölt sürgős problémák megoldására.
Mit tehetünk az alkalmazásmegoldások fejlesztőjeként és tervezőiként? Először is, ismerni és megérteni azoknak a platformoknak a technológiai változásait, amelyeken dolgozunk, képességeiket, jellemzőiket és alkalmazásuk határait.

Tekintsük a DBMS -t, mint a tárolás legfontosabb és legfontosabb technológiai platformját.
Az utóbbi időben a kezdetben "univerzálisként" létrehozott relációs adatbázisok egyértelműen a specializáció felé terelődtek. A vezető gyártók hosszú ideje különféle lehetőségeket bocsátanak ki - különböző osztályú alkalmazásokhoz (OLTP, DSS és DWH). Ezenkívül további lehetőségek jelennek meg a szöveggel, geoadatokkal stb.

De ezzel még nem volt vége - olyan termékek kezdtek megjelenni, amelyek kezdetben egy bizonyos feladatosztályra koncentráltak, azaz speciális DBMS. Használhatják vagy nem a relációs modellt. Fontos, hogy kezdetben nem csak "üzleti információk" tárolására és feldolgozására "általánosan", hanem konkrét feladatokra "élezik".

Nyilvánvaló, hogy a központosítás és a specializáció két egymást kiegészítő irányzat, amelyek időszakosan helyettesítik egymást, biztosítva a fejlődést és az egyensúlyt. Valamint az evolúciós (fokozatos) fokozatos fejlődés és a kardinális változások. Például a 90 -es években Michael Stonebreaker volt a Generation III Database Manifesto egyik szerzője, amely világosan kifejezte azt a gondolatot, 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 tesz közzé, amelyekben meghirdeti a DBMS világában egy új korszak kezdetének előfeltételeit - pontosan szakterületük alapján.
Arra összpontosít, hogy a közös univerzális DBMS-ek "egy méretben" architektúrára épülnek, amely nem veszi figyelembe sem a hardverplatformok változását, sem az alkalmazások osztályokra osztását, amelyekhez optimálisabb megoldás, mint az egyetemes követelmények megvalósítása.
És ezzel az elképzeléssel összhangban számos projektet kezd fejleszteni. Az egyik - a C -Store - egy oszlopos DBMS, amelyet a megosztott semmi (SN) architektúrában terveztek, eredetileg kifejezetten az adattárházak osztályának rendszereihez. Ezt a terméket tovább értékesítették HP Vertica néven.

Úgy tűnik, most az adattárházak fejlesztésének témája új fejlesztési szakaszba csúszott. Új technológiák, megközelítések és eszközök jelennek meg. Tanulmányozásuk, tesztelésük és intelligens alkalmazásuk lehetővé teszi számunkra, hogy valóban érdekes és hasznos megoldásokat hozzunk létre. És vigye őket a megvalósításba, élvezve, hogy fejlesztéseit a valós munkában használják fel és hasznosak.

Epilógus

A cikk elkészítésekor elsősorban az adattárházakkal közvetlenül dolgozó építészekre, elemzőkre és fejlesztőkre próbáltam koncentrálni. De kiderült, hogy óhatatlanul „kicsit szélesebbre vitte a témát” - és más olvasói kategóriák estek a látómezőbe. Néhány pont ellentmondásosnak tűnik, néhány nem világos, néhány nyilvánvaló. Az emberek különbözőek - különböző háttérrel, háttérrel és beosztással.
Például tipikus menedzseri kérdések: "mikor kell építészeket felvenni?", "Mikor érdemes építészetet csinálni?" hangzás számunkra (fejlesztők, tervezők) meglehetősen furcsa, mert számunkra a rendszer felépítése megjelenik a születésével - nem számít, hogy tisztában vagyunk -e vele vagy sem. És még ha az építésznek nincs is formális szerepe a projektben, a normális fejlesztő mindig „magában foglalja a saját belső építészét”.

Nagyjából mindegy, hogy ki látja el pontosan az építész szerepét - fontos, hogy valaki hasonló kérdéseket tegyen fel, és vizsgálja meg a válaszokat. Ha az építész egyértelműen kiemelt, ez csak azt jelenti, hogy elsősorban ő a felelős a rendszerért és annak fejlesztéséért.
Miért tartottam relevánsnak a "törésgátlás" témát ebben a témában?

"A törésgátlás egyedisége az, hogy lehetővé teszi számunkra, hogy az ismeretlennel dolgozzunk, tegyünk valamit olyan körülmények között, amikor nem értjük, mit csinálunk, és hogy sikereket érjünk el."/ Nassim N.Taleb /

Ezért a válság és a nagyfokú bizonytalanság nem mentség az építészet hiányára, hanem olyan tényezők, amelyek megerősítik annak igényét.

Zaitsev S.L., Ph.D.

Ismétlődő csoportok

Az ismétlődő csoportok olyan attribútumok, amelyekhez az entitás egyetlen példányának több értéke is lehet. Például egy személynek több készsége is lehet. Ha az üzleti követelményeket illetően ismernünk kell a képzettségi szintet mindegyiknél, és minden személynek csak két készsége lehet, akkor létrehozhatjuk az ábrán látható entitást. 1.6. Itt az entitás EGY SZEMÉLY két attribútummal a készségek és készségszint tárolására.

Rizs. 1.6. Ez a példa ismétlődő csoportokat használ.

A csoportok ismétlésével az a probléma, hogy nem tudhatjuk pontosan, hogy egy személy hány készséggel rendelkezik. A való életben van, akinek van egy készsége, van, akinek több, és van, akinek még nincs. Az 1.7. Ábra az első normál formára redukált modellt mutatja. Vegye figyelembe a hozzáadottakat A készség azonosítója hogy mindegyik egyedileg azonosítja KÉSZSÉG.

Rizs. 1.7. A modell az első normál formára redukálva.

Egy tény egy helyen

Ha ugyanaz az attribútum több entitásban is jelen van, és nem idegen kulcs, akkor ez az attribútum redundánsnak minősül. A logikai modell nem tartalmazhat redundáns adatokat.

A redundancia további helyet igényel, de bár a memória hatékonysága fontos, az igazi probléma máshol rejlik. Fölösleges a redundáns adatok szinkronizálásának biztosítása, és mindig fennáll az ütköző értékek kockázata.

Az előző példában KÉSZSÉG attól függ Személyazonosítóés onnan A készség azonosítója. Ez azt jelenti, hogy nem lesz KÉSZSÉG amíg meg nem jelenik EGY SZEMÉLY, rendelkezik ezzel a készséggel. Ez megnehezíti a készségnév megváltoztatását is. Minden egyes bejegyzést meg kell találni a készség nevével, és meg kell változtatni minden olyan személynél, aki rendelkezik ezzel a készséggel.

Az 1.8. Ábra a modellt normál formában mutatja. Vegye figyelembe, hogy a hozzáadott entitás KÉSZSÉG, és az attribútum CÍM a készség átkerül ebbe az entitásba. A képzettségi szint a kereszteződésben maradt SZEMÉLYEK és KÉSZSÉG.

Rizs. 1.8. A második normál formában az ismétlődő csoport egy másik entitásba kerül. Ez rugalmasságot biztosít a szükséges számú készség hozzáadásához és a képesség nevének vagy készségleírásának egy helyen történő megváltoztatásához.

Minden attribútum a kulcstól függ

Az entitás minden attribútumának az adott entitás elsődleges kulcsától kell függnie. Az előző példában Iskola neveés Földrajzi terület táblázatban szerepel EGY SZEMÉLY de ne írja le az illetőt. A harmadik normál forma eléréséhez át kell helyeznie az attribútumokat az entitásba, ahol azok a kulttól függenek. 1.9. a modellt a harmadik normál formában mutatja.

Rizs. 1.9. Harmadik normál formában Iskola neveés Földrajzi régió entitásba kerül, ahol értékeik a kulttól függenek.

Sok-sok kapcsolat

Kapcsolat sok-sok tükrözik a környező világ valóságát. Vegye figyelembe, hogy az 1.9. Ábrán sok-sok kapcsolat van SZEMÉLYESés ISKOLA... A hozzáállás pontosan tükrözi azt a tényt, hogy EGY SZEMÉLY sokban tanulhat ISKOLÁKés benne ISKOLA sokat tanulhat SZEMÉLY. A negyedik normál forma eléréséhez egy asszociatív entitás jön létre, amely kiküszöböli a monogy-sok kapcsolatot, azáltal, hogy külön bejegyzést generál az iskola és a személy egyedi kombinációihoz. Az 1.10. Ábra a modellt mutatja negyedik normál formában.

Rizs. 1.10. Negyedik normál formában monogó-sok kapcsolat között SZEMÉLYESés ISKOLA egy asszociatív entitás bevezetésével oldható meg, amelyben minden egyes kombinációhoz külön bejegyzést rendelnek ISKOLÁKés SZEMÉLYEK.

A normál formák formai meghatározása

A normál formák alábbi definíciói ijesztőnek tűnhetnek. Gondoljon rájuk egyszerűen a normalizálás elérésére szolgáló képletekként. A normál formák a relációs algebrán alapulnak, és matematikai transzformációkként értelmezhetők. Bár ez a könyv nem foglalkozik a normál formák részletes tárgyalásával, a modellezőket arra ösztönzik, hogy mélyebben vizsgálják meg a témát.

Egy adott R relációban az Y attribútum funkcionálisan függ az X attribútumtól. Szimbolikus formában RX -> RY (olvasható úgy, hogy "RX funkcionálisan meghatározza az RY -t") - akkor és csak akkor, ha az X minden értéke pontosan egyhez kapcsolódik Y értéke R -ben (bármikor). Az X és Y attribútumok összetettek lehetnek (Dátum: CJ. Introduction to Database Systems. 6. kiadás. Ed. Williams: 1999, 848 pp.).

Az R reláció akkor és csak akkor felel meg az első normál formának (1NF), ha a hozzá tartozó összes tartomány csak atomértékeket tartalmaz (Dátum, uo.).

Az R reláció akkor és csak akkor felel meg a második normál formának (2NF), ha az 1NF-nek felel meg, és minden nem kulcsjellemző teljesen függ az elsődleges kulcstól (Dátum, uo.).

Az R reláció akkor és csak akkor felel meg a harmadik normál formának (3NF), ha megfelel a 2NF-nek, és minden nem-kulcs attribútum nem függ átmenetileg az elsődleges kulcstól (Dátum, uo.).

Az R összefüggés akkor és csak akkor felel meg Boyes-Codd normálformának (BCNF), ha minden determináns jelöltként használható kulcsként.

JEGYZET Az alábbiakban röviden ismertetjük a Date definícióiban használt rövidítéseket.

Az MVD (többértékű függőség) többértékű függőség. Csak három vagy több attribútummal rendelkező entitásoknál használható. Többértékű függőség esetén az attribútum értéke csak az elsődleges kulcs egy részétől függ.

FD (funkcionális függőség) - funkcionális függőség. Funkcionális függőség esetén az attribútum értéke egy másik attribútum értékétől függ, amely nem része az elsődleges kulcsnak.

A JD (join dependency) csatlakozásfüggőség. Szakszervezeti függőségben az anyavállalat elsődleges kulcsa legalább a harmadik szintű leszármazottakra vezethető vissza, miközben megtartja azt a képességet, hogy az eredeti kulccsal használható legyen az unióban.

Az arány akkor és csak akkor felel meg a negyedik normálformának (4NF), ha R -ben van MVD, például A®®B. Ebben az esetben az összes R attribútum funkcionálisan függ az A -tól. Más szóval, R -ben csak a K®X alakú függőségek (FD vagy MVD) vannak (vagyis az X attribútum funkcionális függősége a jelölttől) kulcsként használja K). Ennek megfelelően R megfelel a 4NF követelményeinek, ha megfelel a BCNF -nek, és minden MVD valójában FD (dátum, uo.).

Az ötödik normálformánál az R reláció kielégíti az uniófüggést (JD) * (X, Y,…, Z), és csak akkor, ha R egyenértékű az X -re, Y -re, Z -re vetített vetületeivel, ahol X, Y, ..., Z az R attribútumhalmaz részhalmaza.

Számos más normál űrlap létezik a bonyolult adattípusokhoz és konkrét helyzetekhez, amelyek kívül esnek a vita keretein. Minden modellfejlesztési rajongó szeretne más normál formákat is megtanulni.

Üzleti normál űrlapok

Clive Finklestein (An Introduction to Information Engineering: From Strategic Planning to Information Systems. Reading, Massachusetts: Addison-Wesley, 1989) című könyvében más megközelítést alkalmazott a normalizáláshoz. Meghatározza az üzleti normál formákat az ilyen formákra való kényszerítés szempontjából. Sok modellező intuitívabbnak és pragmatikusabbnak tartja ezt a megközelítést.

Az első üzleti normál űrlap (1BNF) az ismétlődő csoportokat egy másik entitáshoz viszi ki. Ez az entitás saját nevét és elsődleges (összetett) kulcstulajdonságait kapja az eredeti entitástól és annak ismétlődő csoportjától.

A második üzleti normál űrlap (2BNF) az elsődleges kulcstól részben függő attribútumokat távolítja el egy másik entitáshoz. Ennek az entitásnak az elsődleges (összetett) kulcsa annak az entitásnak az elsődleges kulcsa, amelyben eredetileg található, valamint további kulcsok, amelyektől az attribútum teljes mértékben függ.

A harmadik üzleti normál forma (3BNF) az elsődleges kulcstól független attribútumokat átveszi egy másik entitásba, ahol teljesen függenek az entitás elsődleges kulcsától.

A negyedik üzleti normál forma (4BNF) olyan attribútumokat vesz fel, amelyek az elsődleges kulcs értékétől függenek, vagy opcionálisak egy másodlagos entitás számára, ahol teljes mértékben az elsődleges kulcs értékétől függenek, vagy ahol (szükségszerűen) jelen kell lenniük entitás.

Az ötödik üzleti normál forma (5BNF) strukturális entitásként jelenik meg, ha rekurzív vagy más függőség van a másodlagos entitás példányai között, vagy ha rekurzív függőség létezik az elsődleges entitás példányai között.

Befejezett logikai adatmodell

A befejezett logikai modellnek meg kell felelnie a harmadik üzleti normál űrlap követelményeinek, és tartalmaznia kell az összes entitást, attribútumot és kapcsolatot, amelyek szükségesek az adatokkal kapcsolatos adatszolgáltatási követelmények és üzleti szabályok alátámasztásához.

Minden entitásnak neveket kell tartalmaznia, amelyek leírják tartalmukat, és világos, tömör, teljes leírással vagy meghatározással kell rendelkezniük. A jövőbeli bejegyzés egy kezdeti iránymutatást fog tartalmazni az entitásnevek és leírások helyes kialakítására vonatkozóan.

Az entitásoknak teljes attribútumkészlettel kell rendelkezniük, hogy az egyes entitásokkal kapcsolatos minden tény megjeleníthető legyen az attribútumaival. Minden attribútumnak rendelkeznie kell a jelentését tükröző névvel, logikai adattípussal, valamint világos, rövid, teljes leírással vagy definícióval. Egy későbbi blogbejegyzésben megvizsgáljuk az attribútumnevek és -leírások megfelelő formázására vonatkozó kezdeti irányelveket.

A kapcsolatoknak tartalmazniuk kell egy verbális konstrukciót, amely leírja az entitások közötti kapcsolatot, valamint olyan jellemzőket, mint a pluralitás, a létezés szükségessége vagy a kapcsolat hiányának lehetősége.

JEGYZET Pluralitás kapcsolat leírja az eredeti entitás egy példányához társítható másodlagos entitáspéldányok maximális számát.A lét szükségessége vagytávollét lehetősége kapcsolat a másodlagos entitás azon példányainak minimális számának meghatározására szolgál, amelyek az eredeti entitás egy példányához társíthatók.

Fizikai adatmodell

Miután elkészült egy teljes és megfelelő logikai modell, készen áll arra, hogy döntést hozzon a megvalósítási platform kiválasztásáról. A platform kiválasztása az adatok felhasználásának követelményeitől és a vállalat architektúrájának kialakításának stratégiai elveitől függ. A platform kiválasztása összetett kérdés, amely túlmutat e könyv keretein.

Az ERwin-ben a fizikai modell egy valós adatbázis grafikus ábrázolása. A fizikai adatbázis táblákból, oszlopokból és kapcsolatokból fog állni. A fizikai modell a végrehajtáshoz kiválasztott platformtól és az adatok felhasználásának követelményeitől függ. Az IMS fizikai modellje nagyon különbözik a Sybase modelljétől. Az OLAP jelentések fizikai modellje más lesz, mint az OLTP (online tranzakciófeldolgozás) modellje.

Az adatmodellező és adatbázis -adminisztrátor (DBA) a logikai modellt, a használati követelményeket és a vállalati architektúra házirendjét használja egy fizikai adatmodell kifejlesztéséhez. A teljesítmény javítása érdekében denormalizálhatja a fizikai modellt, és létrehozhat nézeteket a használati követelmények támogatására. A következő szakaszok részletezik a nézetek denormalizálásának és létrehozásának folyamatát.

Ez a szakasz áttekintést nyújt a fizikai modell felépítésének folyamatáról, az adathasználati követelmények gyűjtéséről, a fizikai modell összetevőinek meghatározásáról és a fordított tervezésről. A következő publikációkban ezekkel a kérdésekkel foglalkozunk részletesebben.

Adathasználati követelmények gyűjtése

Általában az adathasználati követelményeket az interjúk és a munkamenetek elején korán gyűjti össze. Ugyanakkor a követelményeknek a lehető legteljesebb mértékben meg kell határozniuk az adatok felhasználó általi felhasználását. A fizikai modell felületes hozzáállása és hiányosságai nem tervezett költségekhez és a projektek végrehajtásának késedelméhez vezethetnek. A használat követelményei a következők:

Hozzáférési és teljesítménykövetelmények

Térfogati jellemzők (a tárolni kívánt adatmennyiség becslése), amelyek lehetővé teszik a rendszergazda számára az adatbázis fizikai térfogatának ábrázolását

Annak a felhasználónak a becslése, akinek párhuzamos hozzáférésre van szüksége az adatokhoz, hogy segítsen az adatbázis elfogadható teljesítményszintű kialakításában

Összesített, összefoglaló és egyéb számított vagy származtatott adatok, amelyek a tartós adatstruktúrákban való tárolás jelöltjeinek tekinthetők

Jelentésekre és szabványos lekérdezésekre vonatkozó követelmények, amelyek segítik az adatbázis -adminisztrátort az indexek felépítésében

Nézetek (állandó vagy virtuális), amelyek segítik a felhasználót az adatok összesítésében vagy szűrési műveleteiben.

Az elnök, a titkár és a felhasználók mellett a modellezőnek, az adatbázis -adminisztrátornak és az adatbázis -építésznek is részt kell vennie a használati követelmények munkamenetében. Meg kell vitatni a felhasználó korábbi adatigényeit. Az adatok megőrzésének időtartama jelentősen befolyásolja az adatbázis méretét. A régebbi adatokat gyakran általánosított formában tárolják, az atomi adatokat archiválják vagy törlik.

A felhasználóknak példákat kell hozniuk a kérésekre és jelentésekre az ülésen. A jelentéseket szigorúan meg kell határozni, és tartalmazniuk kell az összesítő és összefoglaló mezőkhöz használt atomértékeket.

Fizikai adatmodell összetevői

A fizikai adatmodell összetevői táblázatok, oszlopok és kapcsolatok. A logikai modell entitások valószínűleg táblákká válnak a fizikai modellben. A logikai attribútumok oszlopokká válnak. A logikai kapcsolatok a kapcsolatok integritásának korlátai lesznek. Néhány logikai kapcsolat nem valósítható meg fizikai adatbázisban.

Visszafejtés

Ha egy logikai modell nem áll rendelkezésre, szükségessé válik a modell újratelepítése a meglévő adatbázisból. Az ERwin -ben ezt a folyamatot fordított tervezésnek nevezik. A fordított tervezés többféleképpen is elvégezhető. A modellező felfedezheti az adatbázis adatstruktúráit, és vizuális modellezési környezetben újból létrehozhatja a táblázatokat. Importálhatja az adatmeghatározási nyelvet (DDL) egy olyan eszközbe, amely támogatja a fordított tervezést (például Erwin). Az olyan fejlett eszközök, mint az ERwin, olyan funkciókat tartalmaznak, amelyek ODBC kommunikációt biztosítanak egy meglévő adatbázissal, hogy modellt hozzanak létre az adatstruktúrák közvetlen olvasásával. A fordított tervezést az ERwinnel részletesen tárgyaljuk egy következő bejegyzésben.

A vállalati funkcionális határok használata

A modellező logikai modelljének felépítésekor fontos gondoskodni arról, hogy az új modell összhangban legyen a vállalati modellel. A vállalati funkcionális határok használata az adatok modellezését jelenti egy vállalaton belül. Az adatok felhasználásának módja egy vállalatnál gyorsabban változik, mint maga az adat. Minden logikai modellben az adatokat holisztikus módon kell bemutatni, függetlenül az általuk támogatott üzleti területtől. Az entitásoknak, attribútumoknak és kapcsolatoknak meg kell határozniuk az üzleti szabályokat vállalati szinten.

JEGYZET Néhány kollégám ezeket a vállalati funkcionális határokat valós modellezésnek nevezi. A valós modellezés arra ösztönzi a modellezőt, hogy az információkat a ténylegesen velejáró kapcsolatok és kapcsolatok alapján tekintse meg.

A vállalati funkcionális határok használata a megfelelően felépített adatmodellhez biztosítja az alapot tetszőleges számú folyamat és alkalmazás információs igényeinek kielégítéséhez, ami lehetővé teszi a vállalat számára, hogy hatékonyabban kiaknázza egyik legértékesebb eszközét - az információt.

Mi az a vállalati adatmodell?

Vállalati adatmodell (EDM) olyan entitásokat, attribútumokat és kapcsolatokat tartalmaz, amelyek egy vállalat információs igényeit képviselik. Az EDM -et általában a témakörök szerint kategorizálják, amelyek az adott üzleti igények támogatásával kapcsolatos entitáscsoportokat képviselik. Egyes témakörök lefedhetnek bizonyos üzleti funkciókat, például a szerződéskezelést, míg mások olyan termékeket vagy szolgáltatásokat leíró szervezeteket.

Minden logikai modellnek meg kell felelnie a vállalati adatmodell meglévő tartományának. Ha a logikai modell nem felel meg ennek a követelménynek, akkor hozzá kell adni egy tartománymodellt. Ez az összehasonlítás biztosítja, hogy a vállalati modell javul vagy kiigazításra kerül, és minden logikai modellezési erőfeszítés összehangolódik a vállalaton belül.

EDM tartalmazza azokat az egyedi entitásokat is, amelyek meghatározzák a kulcs attribútumok értéktartományát. Ezeknek az entitásoknak nincsenek szüleik, és függetlenek. Független entitásokat gyakran használnak a kapcsolatok integritásának fenntartására. Ezeket az entitásokat több különböző névvel azonosítják, például kódtáblázatok, referenciatáblázatok, típus- vagy osztályozási táblázatok. A "vállalati üzleti objektum" kifejezést fogjuk használni. A vállalati üzleti objektum olyan entitás, amely minden más entitástól független attribútumérték -készletet tartalmaz. A vállalati üzleti objektumokat következetesen kell használni a vállalaton belül.

Vállalati adatmodell kiépítése bővítéssel

Vannak olyan szervezetek, ahol a vállalati modellt egyetlen összehangolt erőfeszítés eredményeként az elejétől a végéig építették ki. Másrészt a legtöbb szervezet a méretezéssel meglehetősen teljes vállalati modelleket hoz létre.

A felépítés azt jelenti, hogy valamit szekvenciálisan, rétegenként építünk, akárcsak az osztriga gyöngyöt termeszt. Minden létrehozott adatmodell hozzájárul az EDM kialakításához. Az EDM ilyen módon történő felépítése további modellezési lépéseket igényel új adatstruktúrák és tartományok hozzáadásához vagy a meglévő adatstruktúrák bővítéséhez. Ez lehetővé teszi a vállalati adatmodell felépítését a részletek kiegészítésével, iteratív hozzáadásával.

Modellezési módszertani koncepció

Számos vizuális adatmodellezési módszer létezik. Az ERwin kettőt támogat:

IDEF1X (Integration Definition for Information Modeling - az információs modellek integrált leírása).

IE (Information Engineering).

Az IDEF1X jó módszertan, és jelölésének használata széles körben elterjedt

Az információs modellek integrált leírása

Az IDEF1X egy strukturált adatmodellezési módszer, amely kiterjeszti a FIPS (Federal Information Processing Standards) szabványként elfogadott IDEF1 módszert. Az IDEF1X egy rendkívül strukturált modellezési konstrukciót használ, és olyan adatmodellt eredményez, amely megköveteli az adatok fizikai jellegének megértését, mielőtt az ilyen információkat elérhetővé tennék.

Az IDEF1X merev szerkezete arra kényszeríti a modellezőt, hogy olyan jellemzőket rendeljen az entitásokhoz, amelyek esetleg nem felelnek meg a környező világ valóságának. Például az IDEF1X megköveteli, hogy minden entitás altípus kizárólagos legyen. Ez ahhoz vezet, hogy egy személy nem lehet egyszerre ügyfél és alkalmazott. Míg a valódi gyakorlat mást mond nekünk.

Információtechnika

Clive Finklesteint gyakran nevezik az információtechnika atyjának, bár hasonló fogalmakat James Martin is megosztott vele (Martin, James. Managing the Database Environment. Upper Saddle River, New Jersey: Prentice Hall, 1983.). Az információtechnológia üzleti alapú megközelítést alkalmaz az információkezeléshez, és más jelölést használ az üzleti szabályok megjelenítésére. Az IE kiterjeszti és fejleszti a Peter Chen által javasolt ER módszertan jelölését és alapfogalmait.

Az IE biztosítja az információs követelmények támogatásához szükséges infrastruktúrát azáltal, hogy integrálja a vállalati stratégiai tervezést a fejlesztés alatt álló információs rendszerekkel. Ez az integráció lehetővé teszi az információs erőforrások kezelésének szorosabb igazítását a vállalat hosszú távú stratégiai kilátásaival. Ez az üzleti alapú megközelítés sok modellezőt arra késztetett, hogy az IE mellett más módszereket válasszanak, amelyek általában a rövid távú fejlesztési kihívásokra összpontosítanak.

Az IE olyan műveletsort javasol, amely arra készteti a vállalatot, hogy azonosítsa az adatgyűjtéshez és kezeléshez szükséges összes információszükségletét, valamint az információs objektumok közötti kapcsolatokat. Ennek eredményeképpen az információs követelmények egyértelműen a menedzsment irányelvei alapján vannak megfogalmazva, és közvetlenül lefordíthatók egy olyan vezetői információs rendszerre, amely támogatja a stratégiai információs igényeket.

Következtetés

Az ERwin -hez hasonló adatmodellező eszköz használatának megértése csak a probléma része. Ezenkívül meg kell értenie, hogy mikor oldják meg az adatmodellezési feladatokat, és hogyan gyűjtik össze az adatmodellben megjelenítendő információs követelményeket és üzleti szabályokat. A munkamenetek lebonyolítása a legkedvezőbb környezetet biztosítja az információszükségletek összegyűjtéséhez olyan környezetben, amely magában foglalja a tartomány szakértőit, a felhasználókat és az informatikai szakembereket.

A jó adatmodell felépítése megköveteli a munkamenetek és interjúk során összegyűjtött információs követelmények és üzleti szabályok elemzését és kutatását. A kapott adatmodellt, ha lehetséges, össze kell hasonlítani a vállalati modellel annak biztosítása érdekében, hogy ne ütközzen a meglévő objektummodellekkel, és tartalmazza az összes szükséges objektumot.

Az adatmodell logikai és fizikai modellekből áll, amelyek információs követelményeket és üzleti szabályokat képviselnek. A logikai modellt a harmadik normál formára kell csökkenteni. A harmadik normál forma korlátozza, hozzáteszi, frissíti és eltávolítja az adatszerkezeti anomáliákat, hogy támogassa az "egy tény egy helyen" elvet. Az összegyűjtött információs követelményeket és üzleti szabályokat elemezni és kutatni kell. Össze kell hasonlítani őket a vállalati modellel annak biztosítása érdekében, hogy ne ütközzenek a meglévő objektummodellekkel, és tartalmazzák az összes szükséges objektumot.

Az ERwin -ben az adatmodell logikai és fizikai modelleket is tartalmaz. Az ERwin megvalósítja az ER megközelítést, és lehetővé teszi logikai és fizikai modellobjektumok létrehozását az információs követelmények és az üzleti szabályok megjelenítésére. A logikai modellobjektumok közé tartoznak az entitások, attribútumok és kapcsolatok. A fizikai modellobjektumok táblázatokat, oszlopokat és a kapcsolatok integritására vonatkozó korlátozásokat tartalmaznak.

A következő kiadványok egyike az entitások azonosításával, az entitás típusok meghatározásával, az entitásnevek és leírások kiválasztásával, valamint néhány technikával foglalkozik az entitások használatával kapcsolatos leggyakoribb modellezési hibák elkerülése érdekében.

Az entitásoknak teljes attribútumkészlettel kell rendelkezniük, hogy az egyes entitásokkal kapcsolatos minden tény megjeleníthető legyen az attribútumaival. Minden attribútumnak rendelkeznie kell a jelentését tükröző névvel, logikai adattípussal, valamint világos, rövid, teljes leírással vagy definícióval. Egy későbbi blogbejegyzésben megvizsgáljuk az attribútumnevek és -leírások megfelelő formázására vonatkozó kezdeti irányelveket. A kapcsolatoknak tartalmazniuk kell egy verbális konstrukciót, amely leírja az entitások közötti kapcsolatot, valamint olyan jellemzőket, mint a pluralitás, a létezés szükségessége vagy a kapcsolat hiányának lehetősége.

JEGYZET Pluralitás kapcsolat leírja az eredeti entitás egy példányához társítható másodlagos entitáspéldányok maximális számát.A lét szükségessége vagy a távollét lehetősége kapcsolat a másodlagos entitás azon példányainak minimális számának meghatározására szolgál, amelyek az eredeti példányhoz társíthatók

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 letöltésre kész komplex fizikai adatmodellek és az üzleti tevékenységi területekre vonatkozó üzleti elemzési jelentések lehetővé teszik a vállalat információs összetevőjének egységesítését, és jelentősen felgyorsítják az üzleti folyamatok végrehajtását. A megoldási sablonok 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 projekt átfutási idejé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ányspecifikus, integrált és logikailag strukturált nézet az összes olyan információról, amelynek a vállalati adattárházban kell lennie, hogy válaszoljon mind a stratégiai, mind a taktikai üzleti kérdésekre. A modellek fő célja az adattérben való tájékozódás megkönnyítése és az üzleti fejlődés szempontjából fontos részletek kiemelése. Modern körülmények között, egy sikeres vállalkozáshoz feltétlenül szükséges, hogy világosan megértsük a különböző összetevők közötti összefüggéseket, és jó elképzelésünk legyen a szervezet összképéről. Az összes részlet és kapcsolat modellek segítségével történő azonosítása lehetővé teszi a vállalat munkájának megszervezéséhez szükséges idő és eszközök leghatékonyabb felhasználását.

Az adatmodellek absztrakt modellek, amelyek leírják az adatok megjelenítését és elérését. Az adatmodellek egy adott területen határozzák meg az adatelemeket és a köztük lévő kapcsolatokat. Az adatmodell olyan navigációs eszköz az üzleti és informatikai szakemberek számára, amely egy meghatározott szimbólum- és szóhalmazt használ, hogy pontosan megmagyarázza a valós információk egy adott osztályát. Ez lehetővé teszi a szervezeten belüli jobb kommunikációt, és ezáltal rugalmasabb és stabilabb alkalmazási környezetet teremt.

Példa a „GIS a kormányzat és az önkormányzat számára” modellre.

Ma stratégiailag fontos, hogy a szoftver- és szolgáltatók gyorsan tudnak reagálni a technológiai újításokkal, az állami korlátozások megszüntetésével és az ellátási láncok összetettségével kapcsolatos iparági változásokra. Az üzleti modell változásaival együtt növekszik a vállalat működésé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 a rájuk vonatkozó funkcionális és üzleti követelmények folyamatosan változnak.

Az iparági adatmodellek célja, hogy megkönnyítsék és optimalizálják ezt a folyamatot, az informatikai megközelítés modern szintre történő átvitelében.

Ipari adatmodellek a cégtőlEsri

Az Esri ArcGIS adatmodellek munkasablonok a térinformatikai projektekben való felhasználáshoz és a különböző alkalmazási területek adatszerkezeteinek létrehozásához. Az adatmodell -építés magában foglalja a koncepcionális terv, a logikai és a fizikai struktúra létrehozását, amely felhasználható személyes vagy vállalati geoadatbázis felépítéséhez. Az ArcGIS eszközöket kínál az adatbázis -séma létrehozásához és kezeléséhez, az adatmodell -sablonokat pedig arra használják, hogy gyorsan elindítsanak egy térinformatikai projektet számos alkalmazásban és iparágban. Az Esri jelentős időt töltött a felhasználói közösséggel, hogy kifejlesszen egy sor sablont, amelyek gyorsan elindíthatják a vállalati geoadatbázis tervezését. Ezeket a projekteket a support.esri.com/datamodels címen írják le és dokumentálják. Az alábbiakban, ezen a webhelyen való megjelenésük sorrendjében az Esri ipari modelljeinek szemantikai fordítása található:

• Címnyilvántartás
• Mezőgazdaság
• Meteorológia
• Alapvető térbeli adatok
• Biológiai sokféleség
• Az épületek belső tere
• Üvegházhatású gázok elszámolása
• Az adminisztratív határok fenntartása
• Katonai létesítmény. Hírszerző szolgálat
• Energia (beleértve az új ArcGIS MultiSpeak protokollt)
• Ökológiai szerkezetek
• Vészhelyzetek Minisztériuma. Tűzoltóság
• Erdei kataszter
• Erdészet
• Geológia
• Nemzeti szintű GIS (e-gov)
• Talajvíz és szennyvíz
• Egészségügyi ellátás
• Régészet és emlékhelyek megőrzése
• nemzetbiztonság
• Hidrológia
• Nemzetközi Vízrajzi Szervezet (IHO). S-57 formátum ENC-hez
• Öntözés
• Földhivatal
• Önkormányzat
• Tengeri navigáció
• Állami kataszter
• Olaj- és gázszerkezetek
• Csővezetékek
• Raszteres tárolás
• Bathimetria, tengerfenék -dombormű
• Távközlés
• Szállítás
• Vízellátás, csatornázás, lakás és kommunális szolgáltatások

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;
• ipari szakértők részvételével jött létre;
• a különböző termékek és technológiák közötti információ interakció biztosítására tervezték;
• ne mondjon ellent más szabványoknak és előírásoknak;
• befejezett projektekben használják szerte a világon;
• úgy vannak kialakítva, hogy az információkkal dolgozzanak a létrehozott rendszer teljes életciklusa során, és ne maga a projekt;
• bővíthető az ügyfél igényei szerint anélkül, hogy elveszítené a kompatibilitást más projektekkel és / vagy modellekkel;
• további anyagok és példák kíséretében;
• különféle ipari vállalatok útmutatásaiban és műszaki anyagaiban használják;
• a résztvevők nagy közössége, míg a közösséghez való hozzáférés mindenki számára nyitott;
• az utóbbi években publikációkban nagyszámú hivatkozás adatmodellekre.

Az Esri egy független testületek szakértői csoportjának tagja, amely különféle ipari modelleket ajánl, például PODS (Pipeline Open Data Standards - nyílt szabvány az olaj- és gázipar számára; a PODS jelenleg Esri PODS Esri Spatial 5.1.1 geoadatbázisként valósul meg. ) vagy az ArcGIS for Aviation geodatabá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 megfelelnek a meglévő ipari szabványoknak, mint például az S-57 és az ArcGIS for Maritime (tengeri és tengerparti jellemzők), valamint olyan modellek, amelyek az Esri Professional Services által végzett munkából készültek, és de facto szabványok. a megfelelő területet. Például a GIS for Nation and Local Government befolyásolta az NSDI és az INSPIRE szabványokat, a Hydro and Groundwater (hidrológia és talajvíz) pedig nagymértékben használatos a szabadon elérhető professzionális ArcHydro csomagban és kereskedelmi termékekben. Meg kell jegyezni, hogy az Esri támogatja az olyan de-facto szabványokat is, mint az NHDI. Minden javasolt adatmodell dokumentálva van, és használatra kész a vállalati IT -folyamatokban. A modellekhez tartozó anyagok a következők:

• Entitások kapcsolatainak UML diagramjai;
• adatstruktúrák, tartományok, könyvtárak;
• kész geodatabase sablonok ArcGIS GDB formátumban;
• mintaadatok és mintaalkalmazások;
• példák adatbetöltő szkriptekre, példák elemző segédprogramokra;
• referenciakönyvek a javasolt adatstruktúráról.

Az Esri könyvek formájában foglalja össze az építőipari modellekben szerzett tapasztalatait, és lokalizálja a megjelent anyagokat. A következő könyveket honosította meg és tette közzé az Esri CIS:

• Geospatial Service Oriented Architecture (SOA);
• Geodatabázisok tervezése szállításhoz;
• Vállalati földrajzi információs rendszerek;
• GIS: új energia az elektromos és gázipari vállalkozások számára;
• Olaj és gáz digitális térképen;
• Világunk modellezése. Esri Geodatabase Design Guide;
• A GIS -re gondolva. GIS tervezés: Kézikönyv a vezetők számára;
• Földrajzi információs rendszerek. Alapok;
• GIS adminisztratív és gazdasági irányításhoz;
• Web GIS. Elvek és alkalmazások;
• Rendszertervezési stratégiák, 26. kiadás;
• Az ArcReview magazin 68 száma a vállalatok és a térinformatikai rendszerek felhasználóinak kiadványaival;
• ... és sok más tematikus jegyzet és kiadvány.

Például a könyv " Világunk modellezése ..."A (fordítás) átfogó útmutató és referencia a térinformatikai adatmodellezéshez általában, és különösen a geoadatbázis adatmodellhez. A könyv bemutatja, hogyan lehet megfelelő adatmodellezési döntéseket hozni, olyan döntéseket hozni, amelyek a térinformatikai projekt minden vonatkozásában részt vesznek, az adatbázis -tervezéstől az adatokon és adatgyűjtésen át a térbeli elemzésig és megjelenítésig hálózatokat, integrálja a műholdképeket a földrajzi elemzés és megjelenítés folyamatába, és készítsen 3D -s modelleket a térinformatikai adatokból. Könyv " Geodatabázisok tervezése szállításhoz"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: Új energia az elektromos és gázipari vállalkozások számára"Valós példák segítségével bemutatja, hogy a vállalati térinformatika milyen előnyökkel járhat az energiaszolgáltató számára, beleértve az olyan szempontokat, mint az ügyfélszolgálat, a hálózati műveletek és más üzleti folyamatok.

Néhány könyv, lefordítva és eredetileg, oroszul, az Esri CIS és a DATA +kiadásában. Foglalkoznak mind a térinformatikai technológiával kapcsolatos fogalmi kérdésekkel, mind pedig a GIS modellezésének és bevezetésének számos alkalmazott vonatkozásával, különböző méretű és célú.

Az ipari modellek alkalmazását a BISDM (Building Interior Space Data Model, az épület belső térének információs modellje) 3.0 példájával fogjuk megvizsgálni. A BISDM egy általánosabb BIM (Building Information Model) modell kifejlesztése, és épületek és építmények tervezésében, építésében, üzemeltetésében és leszerelésében való használatra készült. A GIS szoftverben használatos, lehetővé teszi a geoadatok hatékony cseréjét más platformokkal és interakciót velük. Az FM feladatok általános csoportjára utal (a szervezet infrastruktúrájának kezelése). Soroljuk fel a BISDM modell fő előnyeit, amelyek használata lehetővé teszi:

• szervezze meg az információcserét heterogén környezetben, egységes szabályok szerint;
• a BIM koncepció és az építési projektmenedzsment ajánlott szabályainak "fizikai" megvalósítása;
• a GIS segítségével egyetlen tárolót fenntartani az épület teljes életciklusa során (a tervezéstől a leszerelésig);
• koordinálja a projektben dolgozó 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 az építés költségeiről és időzítéséről (4D és 5D adatok);
• figyelemmel kíséri a projekt előrehaladását;
• biztosítja az épület magas színvonalú működését, beleértve a karbantartást és a javítást;
• részévé válik a vagyonkezelési rendszernek, beleértve a helyhasználat hatékonyságának elemzését (lízing, raktár, munkavállalói menedzsment);
• kiszámítja és kezeli az épület energiahatékonysági céljait;
• szimulálja az emberi áramlások mozgását.

A BISDM meghatározza a térbeli adatokkal való munkavégzés szabályait az épület belső helyiségeinek szintjén, ideértve a rendeltetést és felhasználást, a lefektetett kommunikációt, a telepített berendezéseket, a javítások és karbantartások elszámolását, a naplózási eseményeket és a vállalati egyéb eszközökkel való kapcsolatokat. 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 a geodatabázis (geodatabase) szintű modellezésére az összes fizikai elem térbeli és logikai kapcsolatairól, amelyek mind az épületet, mind annak belső helyiségeit alkotják. A BISDM elveinek követése jelentősen leegyszerűsíti a más rendszerekkel való integráció feladatait. Az első szakasz általában a CAD integráció. Ezután az épület üzemeltetése során adatcserét alkalmaznak ERP és EAM rendszerekkel (SAP, TRIRIGA, Maximo stb.).

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

A BISDM használata esetén a létesítmény vevője / tulajdonosa teljes körű információcserét kap az objektum létrehozásának ötletétől a teljes projekt kifejlesztéséig, az építés irányításáig és a fogadásig a dátummal kapcsolatos információk a létesítmény üzembe helyezésének időpontjáig, a paraméterek ellenőrzése az üzemeltetés során, sőt a létesítmény rekonstrukciója vagy leszerelése során. A BISDM paradigmát követve a térinformatika és a segítségével létrehozott geo-adatbázis a kapcsolódó rendszerek közös adattárává válik. A GDB gyakran harmadik fél rendszerei által létrehozott és üzemeltetett adatokat tartalmaz. Ezt figyelembe kell venni a létrehozott rendszer architektúrájának tervezésekor.

Egy bizonyos szakaszban az információ halmozott "kritikus tömege" lehetővé teszi, hogy új minőségi szintre lépjen. Például egy új épület tervezési szakaszának befejezése után lehetőség nyílik a 3D felmérési modellek automatikus megjelenítésére a GIS -ben, a telepített berendezések listájának összeállításához, a lefektetendő közművek kilométer -számításának kiszámításához, számos ellenőrzés elvégzéséhez és akár a projekt költségének előzetes pénzügyi becslése.

Ismételten megjegyezzük, hogy a BISDM és az ArcGIS együttes használatakor lehetővé válik a 3D modellek automatikus felépítése a felhalmozott adatokból, mivel a geoadatbázis tartalmazza az objektum teljes leírását, beleértve a z-koordinátákat, a talajtagságot, az elemkapcsolatok típusait. , felszerelés módszerei, anyag, rendelkezésre álló utak a személyzet mozgása, az egyes elemek funkcionális célja stb. stb. Meg kell jegyezni, hogy az összes tervezési anyag kezdeti importálása után a BISDM GDB -be további információra van szükség:

• tárgyak és berendezések 3D modelljeinek elhelyezése a kijelölt helyeken;
• információk gyűjtése az anyagok költségeiről, valamint azok lerakásának és telepítésének eljárásáról;
• a permeabilitás szabályozása a beépített nem szabványos berendezés méretei szerint.

Az ArcGIS használata miatt egyszerűbb további 3D objektumok és hivatkozások importálása külső forrásokból, 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 iparban használt összes formátum támogatott, beleértve az IFC, az AutoCAD Revit, a Bentlye Microstation szolgáltatásokat.

Ipari adatmodellek az IBM -től

Az IBM tárhelykezelési eszközöket és modelleket kínál számos üzleti terület számára:

• IBM Banking and Financial Markets Data Warehouse (pénzügy)
• IBM banki adattárház
• IBM banki folyamat- és szolgáltatási modellek
• IBM Health Plan Data Model (egészségügy)
• IBM biztosítási információraktár (biztosítás)
• IBM biztosítási folyamat és szolgáltatási modellek
• IBM Retail Data Warehouse (kiskereskedelem)
• IBM Telecommunications Data Warehouse (távközlés)
• InfoSphere Warehouse Pack:
  - a Customer Insight számára (az ügyfelek megértéséhez)
  - Piaci és Kampány Insight (a vállalat és a piac megértéséhez)
  - Supply Chain Insight (a beszállítók megértéséhez).

Például a modell IBMBanki tevékenységésPénzügyiPiacokAdatRaktár célja a bankszektor sajátos problémáinak kezelése az adatok tekintetében, és IBMBanki tevékenységFolyamatésSzolgáltatásModellek- a folyamatok és a SOA (Service Oriented Architecture) szempontjából. A távközlési ipar számára modelleket mutatnak be IBMInformációKeretrendszer (IFW)és IBMTávközlésAdatRaktár (TDW)... Segítenek jelentősen felgyorsítani az elemzési rendszerek létrehozásának folyamatát, valamint csökkentik az üzleti intelligencia alkalmazások fejlesztésével, a vállalati adatkezeléssel és az adattárházak szervezésével kapcsolatos kockázatokat, figyelembe véve a távközlési ipar sajátosságait. Az IBM TDW képességei a távközlési piac teljes spektrumát lefedik - az internetszolgáltatóktól és a vezetékes és vezeték nélküli telefonszolgáltatásokat, adatátvitelt és multimédiás tartalmakat kínáló kábelhálózat -üzemeltetőktől a telefon-, műholdas, távolsági és nemzetközi kommunikációs szolgáltatásokat nyújtó multinacionális vállalatokig. valamint a szervezetek globális hálózatai. 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.

Egy eszköz, az úgynevezett InfoSphere Warehouse Pack for Customer Insight strukturált és könnyen telepíthető üzleti tartalmat biztosít egyre több üzleti projekthez és iparághoz, beleértve a banki, biztosítási, pénzügyi, egészségbiztosítási, távközlési, kiskereskedelmi és forgalmazási szolgáltatásokat. Üzleti felhasználóknak InfoSphere Warehouse Pack a piacon és a kampányban elősegíti a piacelemzési tevékenységek és a marketingkampányok hatékonyságának maximalizálását az üzlet sajátosságainak fejlesztése és figyelembe vétele révén. Használva InfoSphere Warehouse Pack for Supply Chains Insight a szervezetek képesek az ellátási lánc működésével kapcsolatos aktuális információk fogadására.

Esri pozíciója az IBM megoldás -architektúrán belül.

Különösen figyelemre méltó a segédprogramok és segédprogramok IBM megközelítése. A fogyasztók növekvő igényeinek kielégítésére a közműveknek rugalmasabb architektúrára van szükségük, mint a ma használatosaknak, valamint iparági szabványos objektummodellre van szükségük az információ szabad áramlásának megkönnyítésére. Ez növelni fogja a közművek kommunikációs képességeit, lehetővé teszi a költséghatékonyabb interoperabilitást, és jobb láthatóságot biztosít az új rendszerek számára az összes szükséges erőforráshoz, függetlenül attól, hogy hol találhatók a szervezeten belül. Ennek a megközelítésnek az alapja a SOA (Service Oriented Architecture), egy összetevőmodell, amely feltérképezi a különböző alkalmazások részlegeinek és szolgáltatásainak funkcióit, amelyek újra felhasználhatók. Az ilyen komponensek "szolgáltatásai" merev kötés nélkül cserélnek adatokat interfészeken keresztül, elrejtve a felhasználó elől a mögöttük lévő rendszerek összes komplexitását. Ebben a módban a vállalatok könnyen hozzáadhatnak új alkalmazásokat, függetlenül a szoftver gyártójától, operációs rendszerétől, programozási nyelvétől vagy a szoftver egyéb jellemzőitől. A SOA alapján a koncepció megvalósul BIZTONSÁGOS ( Solution Architecture for Energy), lehetővé teszi a közműcég számára, hogy szabványokon alapuló, holisztikus képet kapjon infrastruktúrájáról.

Esri ArcGIS® egy globálisan elismert szoftverplatform a földrajzi információs rendszerekhez (GIS), amely villamosenergia-, gázátviteli, elosztó- és 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 drámai módon kiterjeszti az IBM SAFE architektúrát azáltal, hogy biztosítja az intelligens energiavállalat kezeléséhez szükséges eszközöket, alkalmazásokat, munkafolyamatokat, elemzéseket és információintegrációs képességeket. Az ArcGIS az IBM SAFE keretein belül lehetővé teszi, hogy különböző forrásokból információkat kapjon az infrastrukturális létesítményekről, eszközökről, ügyfelekről és alkalmazottakról, pontos adatokkal a tartózkodási helyükről, valamint létrehozhat, tárolhat és feldolgozhat georeferált információkat a vállalati eszközökről (támaszok, csővezetékek, vezetékek) , transzformátorok, kábelcsatornák stb.). A SAFE infrastruktúrán belüli ArcGIS dinamikusan összekapcsolja az alapvető üzleti alkalmazásokat a GIS, a SCADA és az ügyfélszolgálati rendszerek adatainak kombinálásával olyan külső információkkal, mint a forgalom intenzitása, az időjárási körülmények vagy a műholdas képek. A segédprogramok ezt a kombinált információt különféle célokra használják, az S.O.R. (az üzemeltetési környezet összképe) a helyszíni szemle, karbantartás, hálózati elemzés és tervezés során.

Egy közüzemi vállalat információs összetevői több szint segítségével modellezhetők, amelyek a legalacsonyabb fizikai szinttől a legmagasabb, legösszetettebb üzleti logikai szintig terjednek. Ezek a rétegek integrálhatók, hogy megfeleljenek az olyan tipikus ipari követelményeknek, mint az automatikus mérési naplózás és a felügyeleti ellenőrzés és adatgyűjtés (SCADA). A SAFE architektúra kiépítésével a közművek jelentős lépéseket tesznek az egész iparágra kiterjedő nyílt objektummodell népszerűsítése érdekében, a Common Information Model (CIM) for Energy and Utilities számára. Ez a modell biztosítja a szükséges keretet ahhoz, hogy sok vállalkozás a szolgáltatásorientált architektúra felé mozduljon el, mivel ösztönzi az adatok és objektumok strukturálására szolgáló nyílt szabványok használatát. Annak a ténynek köszönhetően, hogy minden rendszer ugyanazokat az objektumokat használja, az azonos objektumok különböző megvalósításaihoz kapcsolódó zűrzavar és rugalmatlanság minimálisra csökken. Így az ügyfél -objektum és más fontos üzleti objektumok meghatározása egységes lesz a tápegység minden rendszerében. Most a CIM segítségével a szolgáltatók és a szolgáltatásfogyasztók közös adatstruktúrát oszthatnak meg, ami megkönnyíti a drága üzleti összetevők kiszervezését, mivel a CIM közös bázist hoz létre az információcsere felépítésére.

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 integrálja 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 úgy találta, hogy az integráció jelentős akadályt jelent az új alkalmazások elfogadása előtt. Éppen ellenkezőleg, az adatintegráció megvalósítása kézzelfogható jövedelmet és nagyobb hatékonyságot hoz a vállalatnak.

Egy jól felépített modell egyedileg azonosítja az adatok jelentését, ami ebben az esetben strukturált adat (szemben a strukturálatlan adatokkal, mint például egy kép, bináris fájl vagy szöveg, ahol a jelentés kétértelmű is lehet). A leghatékonyabb ipari modellek azok a professzionális gyártók, mint az Esri és az IBM. Modelljeik magas hozamot érnek el a jelentős részletesség és pontosság miatt. Általában sok adatattribútumot tartalmaznak. Ezenkívül mind az Esri, mind az IBM széleskörű modellezési tapasztalattal rendelkezik, és jól ismeri az építőipar-specifikus modelleket.

DB architektúra

A KMD séma az adatmodell felépítésének leírása a rendszergazda szempontjából.

Az AMD séma egy belső vagy fizikai modell leírása. Itt tárolják az adathordozón lévő adatok fizikai helyének leírását. A séma közvetlen jelzéseket tárol az adatok memóriában való elhelyezéséről (kötetek, lemezek).

A KMD séma leírja az adatok, rekordok és mezők szerkezetét.

Minden DBMS három fő adatmodelltípust támogat:

1. Hierarchikus modell. Feltételez valamilyen gyökérbevitelt. Az ágak a gyökerekből származnak.

Nem minden objektum van leírva kényelmesen ilyen módon. A hierarchiában nincsenek linkek, és nagy az információ -redundancia.

2. Hálózati modell. Lehetővé teszi a kapcsolatok összes bonyolultságának helyes megjelenítését.

A modell alkalmas a hivatkozások külső környezetből származó adatokkal való ábrázolására, de kevésbé kényelmes az adatbázisban való leíráshoz, ami további munkához vezet a felhasználó számára a linkeken keresztüli navigáció tanulmányozásához.

3. A relációs modell. A kapcsolat matematikai kifejezésén alapul - reláció, de egyszerűen egy táblázat. Például téglalap alakú kétdimenziós.

A relációs adatstruktúrát az 1960 -as évek végén számos kutató fejlesztette ki, akik közül a legjelentősebb hozzájárulást az IBM munkatársa, Edgar Codd adta. A relációs megközelítéssel az adatokat kétdimenziós táblázatok formájában mutatják be - ez a legtermészetesebb az emberek számára. Ugyanakkor az adatfeldolgozáshoz Codd a halmazelmélet - unió, metszéspont, különbség, derékszögű szorzat - alkalmazását javasolta.

Adattípus- ennek a fogalomnak ugyanaz a jelentése, mint a programozási nyelveknek (azaz az adattípus határozza meg a belső ábrázolást a számítógép memóriájában és az adatpéldány tárolásának módját, valamint az értékpéldányokat és az érvényes adatműveletek halmaza). Valamennyi meglévő modern adatbázis támogatja a speciális adattípusokat, amelyek egész típusú adatok, tört lebegőpontos karakterek, karakterek és karakterláncok, naptári dátumok tárolására szolgálnak. Sok adatbázis -kiszolgáló más típusokat is megvalósít, például az Interbase -kiszolgáló speciális adattípussal rendelkezik a bináris információk nagy tömbjeinek (BLOB) tárolására.

Tartomány Egy egyszerű adattípus lehetséges értékkészlete, bizonyos programozási nyelveken hasonlít egy adattípusra. A tartományt két elem határozza meg - egy adattípus és egy logikai kifejezés, amelyet az adatokra alkalmaznak. Ha ez a kifejezés igaznak minősül, akkor az adatpéldány a tartományhoz tartozik.

Hozzáállás Ez egy különleges típusú kétdimenziós asztal, amely fejlécből és törzsből áll.

Cím Az attribútumok rögzített halmaza, amelyek mindegyike meghatározott tartományon belül van meghatározva, és egy az egyben megfelel az attribútumok és a meghatározó tartományok között.

Az attribútumok mindegyike saját tartományában van definiálva. A tartomány az egész adattípus, és a logikai feltétel n> 0. A fejléc idővel változatlan, ellentétben a kapcsolat törzsével. Kapcsolati szerv Gyűjtemény tuples, amelyek mindegyike egy attribútum-érték pár.

A kapcsolat ereje a sorszámainak száma, és hozzáállás foka- az attribútumok száma.

Az arány mértéke egy adott aránynál állandó, míg az arány teljesítménye idővel változik. A kapcsolat erejét bíboros számnak is nevezik.

A fenti fogalmak elméleti jellegűek, és a relációs DBMS nyelvi eszközeinek és szoftverrendszereinek fejlesztésében használatosak. A mindennapi munkában ezek informális megfelelőit használják:

hozzáállás - asztal;

tulajdonság - oszlop vagy mező;

tuple - rekord vagy karakterlánc.

Így az arány mértéke a táblázat oszlopainak száma, a bíboros szám pedig a sorok száma.

Mivel a reláció halmaz, és a klasszikus halmazelméletben definíció szerint egy halmaz nem tartalmazhat egybeeső elemeket, egy reláció nem rendelkezhet két azonos sorral. Ezért egy adott kapcsolat esetében mindig van egy attribútumhalmaz, amely egyedileg azonosítja a tuple -t. Ezt az attribútumkészletet ún kulcs.

A kulcsnak meg kell felelnie a következő követelményeknek:

· Egyedinek kell lennie;

· Minimálisnak kell lennie, vagyis bármely attribútum eltávolítása a kulcsból az egyediség megsértéséhez vezet.

Általában a kulcsban lévő attribútumok száma kevesebb, mint a kapcsolat foka, azonban végső megoldásként a kulcs tartalmazhatja az összes attribútumot, mivel az összes attribútum kombinációja kielégíti az egyediség feltételét. Általában egy kapcsolatnak több kulcsa van. A kapcsolat összes kulcsa közül (ezeket "lehetséges kulcsoknak" is nevezik) egyet választunk elsődleges kulcs... Választáskor elsődleges kulcsáltalában a legkevesebb attribútummal rendelkező kulcsot részesítik előnyben. Szintén nem praktikus hosszú karakterláncú kulcsokat használni.

A gyakorlatban gyakran egy speciális numerikus attribútumot használnak elsődleges kulcsként - egy automatikusan növekvő nullát, amelynek értékét egy trigger (egy trigger egy speciális eljárás, amelyet az adatbázis módosításakor hívnak meg) vagy speciális a DBMS motorban meghatározott eszközök.

Az ebben a fejezetben leírt alapfogalmak nem specifikusak egy adott adatbázis -megvalósításra, de mindegyikre közösek. Így ezek a fogalmak egy bizonyos általános modell alapját képezik, amelyet relációs adatmodellnek neveznek.

A relációs megközelítés alapítója, Date megállapította, hogy a relációs modell három részből áll:

· Szerkezeti;

· Manipulatív;

· Holisztikus.

A modell szerkezeti részében a relációkat rögzítik, mint a relációs modellben használt egyetlen adatstruktúrát.

A manipulációs részben a relációs bázisok manipulálásának két alapvető mechanizmusa van rögzítve - a relációs algebra és a relációs számítás.

A szerves rész egy bizonyos mechanizmus, amely biztosítja az adatok roncsolhatatlanságát. Az integrált rész két alapvető követelményt tartalmaz a relációs adatbázisok integritására - az entitás integritását és a hivatkozási integritást.

Követelmény entitás integritása az, hogy bármely reláció minden sorát meg kell különböztetni a reláció bármely más sorától, vagyis más szavakkal, minden relációnak rendelkeznie kell elsődleges kulccsal. Ennek a követelménynek teljesülnie kell, ha a kapcsolat alapvető tulajdonságai teljesülnek.

Az adatmanipulációs nyelven, valamint a lekérdezési nyelven a relációk algebrájának nevezett matematikai apparátust hajtják végre, a következő műveletekhez:

1. Szabványos műveletek: - metszéspont, - unió, \ - különbség, X - derékszögű szorzat.

2. Specifikus: vetítés, korlátozás, kapcsolat, osztás.

a. Unió.

ShD SHM EI NR

R 1 (cikkszám, anyagszám, mértékegységek, fogyasztási ráta)

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

Meg kell találni

Az R 1 és R 2 halmazok rögzítését feltételezzük. Ebben a műveletben a fokozat megőrződik, és az eredményhalmaz számszerűsége

b. Útkereszteződés.

Jelölje ki a megfelelő sorokat.

c. Különbség.

Távolítsa el az R 1 -ből azokat a sorokat, amelyek egybeesnek az R 2 -vel.

d. Dekartéziánus termék.

Ez az, ahol a sorokat összefűzik.

Egy halmaz minden sora összefűződik a másik sorával.

Két készletet adnak meg:

A derékszögű termék a következő:

Ebben az esetben az S-fok egyenlő, és, azaz 12 sort és 5 oszlopot kap.

A vállalati adatbázis a vállalati információs rendszer központi összeköttetése, és lehetővé teszi, hogy egyetlen információs teret hozzon létre a vállalat számára. Vállalati adatbázisok

Ossza meg munkáját a közösségi médiában

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

V. TÉMA. VÁLLALATI ADATBÁZISOK

V .1. Adatok szervezése vállalati rendszerekben. Vállalati adatbázisok.

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

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

V .1. AZ ADATOK SZERVEZÉSE VÁLLALATI RENDSZEREKBEN. VÁLLALATI ADATBÁZISOK

Vállalati bázis Az adatok a vállalati információs rendszer központi láncszeme, és lehetővé teszik, hogy egyetlen információs teret hozzon létre a vállalat számára. Vállalati adatbázisok (1.1. Ábra).

Az adatbázisok különböző definíciókkal rendelkeznek.

Az adatbázis alatt (DB) megérteni egy logikailag összekapcsolt információhalmazt úgy, hogy egyetlen adathalmazt képezzen a számítógép memóriaeszközeiben. Ez a készlet az automatizált vezérlőrendszerek, adatfeldolgozó rendszerek, információs és számítástechnikai rendszerek működési folyamatában megoldott feladatok kiinduló adataként működik.

Az adatbázis kifejezés összefoglalható, mint a logikailag kapcsolódó, megosztásra szánt adatok gyűjteménye.

Az adatbázis alatt alatt olyan minimális redundanciával együtt tárolt adathalmazt értünk, amely lehetővé teszi azok optimális felhasználását egy vagy több alkalmazáshoz.

Az adatbázisok létrehozásának célja mint adattárolási formák olyan adatrendszer kiépítése, amely nem függ az elfogadott algoritmusoktól (szoftverektől), az alkalmazott technikai eszközöktől, az adatok fizikai helyétől a számítógépben. Az adatbázis többcélú felhasználást feltételez (több felhasználó, sokféle dokumentum és egy felhasználó kérése).

Alapvető követelmények az adatbázisokhoz:

• Az adatok bemutatásának teljessége. Az adatbázisban szereplő adatoknak megfelelően kell képviselniük az objektumra vonatkozó összes információt, és elegendőnek kell lenniük az ODS -hez.
• Az adatbázis integritása. Az adatokat menteni kell az ODS -ek feldolgozása során, és minden olyan helyzetben, amely a munka során felmerül.
• Az adatstruktúra rugalmassága. Az adatbázisnak lehetővé kell tennie az adatstruktúrák megváltoztatását anélkül, hogy sértené integritását és teljességét a külső feltételek változásakor.
• Megvalósíthatóság. Ez azt jelenti, hogy objektíven kell ábrázolni a különböző tárgyakat, tulajdonságaikat és kapcsolataikat.
• Elérhetőség. Biztosítani kell az adatokhoz való hozzáférés korlátozását.
• Redundancia. Az adatbázisnak minimális redundanciával kell rendelkeznie az objektumok adatainak ábrázolásában.

A tudást úgy értjük tények, minták és heurisztikus szabályok összessége, amelyek felhasználhatók a probléma megoldására.

Tudásbázis (KB)  adatbázisokat és a döntéshozóktól kapott szabályokat használtak. A tudásbázis a szakértői rendszerek eleme.

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

Fizikai adatok - a számítógép memóriájában tárolt adatokról van szó.

Logikai adatábrázolás a fizikai adatok egyéni nézetének felel meg. A különbség az adatok fizikai és megfelelő logikai ábrázolása között az, hogy az utóbbi néhány fontos kapcsolatot tükröz a fizikai adatok között.

A vállalati adatbázis alatt megérteni egy adatbázist, amely így vagy úgy egyesíti az összes szükséges adatot és tudást az automatizált szervezetről. A vállalati információs rendszerekben olyan fogalom, mintintegrált adatbázisok, amelyben az egyszeri bevitel és az információk ismételt felhasználásának elve valósul meg.

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

A vállalati adatbázisok összpontosított (központosított) és terjeszteni.

Csomósított (központosított) adatbázis egy adatbázis, amelynek adatai fizikailag egy számítógép tárolóeszközeiben vannak tárolva. Ábrán. Az 1.2 bemutatja a különböző platformok adatbázisaihoz való hozzáférésre szolgáló szerveralkalmazások diagramját.

1.2. Ábra A rendszer heterogén központosított adatbázis

Az információfeldolgozás központosítása lehetővé tette a hagyományos fájlrendszerek olyan hátrányainak kiküszöbölését, mint az inkoherencia, következetlenség és az adatok redundanciája. Az adatbázisok növekedésével, és különösen, ha földrajzilag szétszórt szervezetekben használják, problémák merülnek fel. Például a távközlési hálózat csomópontjában található koncentrált adatbázisok esetében, amelyek segítségével 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;
• Nagy forgalom a hálózaton;
• Alacsony megbízhatóság;
• Gyenge összteljesítmény.

Bár a frissítések során könnyebb biztosítani az adatok biztonságát, integritását és következetességét egy központosított adatbázisban, ezek a problémák bizonyos nehézségeket okoznak. Ezekre a problémákra lehetséges megoldásként az adatok decentralizációját javasolják. A decentralizáció eléri:

• A feldolgozás nagyobb fokú egyidejűsége a terheléselosztás miatt;
• A terepi adatok felhasználásának javítása távoli (távoli) lekérdezések végrehajtásakor;
• Alacsonyabb költségek;
• A helyi adatbázisok egyszerű kezelése.

A hálózat létrehozásának költségei, amelyek csomópontjaiban munkaállomások (kis számítógépek) találhatók, sokkal alacsonyabbak, mint egy hasonló rendszer létrehozása egy nagy számítógép használatával. Az 1.3. Ábra egy elosztott adatbázis logikai diagramját mutatja.

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

Adjuk meg az elosztott adatbázis következő definícióját.

Elosztott adatbázis - az információhálózat különböző csomópontjaiban tárolt és logikailag összekapcsolt információk, fájlok (kapcsolatok) gyűjteménye, amely egyetlen adathalmazt alkot (a kommunikáció lehet funkcionális vagy ugyanazon fájl másolatain keresztül). Ez tehát logikusan összekapcsolt, de fizikailag több, ugyanazon számítógépes hálózat részét képező gépen elhelyezkedő adatbázisok összessége.

Az elosztott adatbázis legfontosabb teljesítménykövetelményei a következők:

• Skálázhatóság;
• Kompatibilitás;
• Különféle adatmodellek támogatása;
• Hordozhatóság;
• A hely á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.
• A homogén biztonsági rendszer támogatása.

A helyátláthatóság lehetővé teszi a felhasználók számára, hogy anélkül lépjenek kapcsolatba az adatbázisokkal, hogy bármit is tudnak 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), amelynek végrehajtása során különböző adatbázisok objektumaihoz (táblái vagy nézetei) férnek hozzá. Az elosztott tranzakciók végrehajtásakor az összes érintett adatbázis párhuzamosság -ellenőrzését végzik. 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 egy DBMS -nek kell karbantartaniuk), vagy ugyanazon operációs rendszer környezetében és / vagy azonos típusú számítógépeken kell feldolgozniuk. Például az egyik adatbázis lehet Oracle adatbázis egy SUN OS (UNIX) rendszert futtató SUN gépen, egy második adatbázist egy DB2 adatbázis tárolhat egy IBM 3090 nagyszámítógépen MVS operációs rendszerrel, egy harmadik adatbázist pedig a SQL / DS az IBM nagyszámítógépen is, de a VM operációs rendszerrel. Csak egy feltétel szükséges - minden adatbázissal rendelkező gépnek hozzáférhetőnek kell lennie azon a hálózaton keresztül, amelynek része.

Az elosztott adatbázis fő feladata - adatok hálózaton keresztüli elosztása és hozzáférése. A probléma megoldására a következő módszerek állnak rendelkezésre:

• 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.
• Előfordulhat, hogy a távoli webhelyeken gyakran használt adatok sokszorosulnak. Ezt az eloszlást részben duplikáltnak nevezik.
• Minden adat megismétlődik minden csomóponton. Ezt az eloszlást nevezzük teljesen duplikáltnak.
• Egyes fájlok feloszthatók vízszintesen (a rekordok egy részhalmaza van kiválasztva) vagy függőlegesen (az attribútummezők egy részhalmaza van kiválasztva), míg a kiválasztott részhalmazok különböző csomópontokban tárolódnak a fel nem osztott adatokkal együtt. Ezt az eloszlást splitnek (töredezettnek) nevezik.

Elosztott adatbázis létrehozásakor a fogalmi szinten a következő feladatokat kell megoldania:

• Szükséges, hogy egyetlen fogalmi diagramja legyen a teljes hálózatnak. Ez logikus átláthatóságot biztosít az adatok számára a felhasználó számára, aminek eredményeképpen képes lesz a teljes adatbázis kérésére, külön terminál mögött (úgy tűnik, hogy egy központosított adatbázissal működik).
• Séma szükséges az adatok hálózaton történő megkereséséhez. Ez átláthatóvá teszi az adatok elhelyezését, ennek köszönhetően a felhasználónak nem kell megadnia, hová kell küldeni a kérelmet 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 lehetnek hardverek és szoftverek tekintetében homogének vagy heterogének. A heterogenitás problémája viszonylag könnyen megoldható, ha az elosztott adatbázis hardver szempontjából heterogén, de szoftveresen homogén (a csomópontokban ugyanaz a DBMS). Ha különböző DBMS -eket használnak egy elosztott rendszer csomópontjaiban, akkor szükség van az adatstruktúrák és nyelvek konvertálására szolgáló eszközökre. Ennek átlátható átalakítást kell biztosítania az elosztott adatbázis csomópontjaiban.
• Szükséges a szótárkezelés problémájának megoldása. Ahhoz, hogy mindenféle átláthatóságot biztosítson egy elosztott adatbázisban, olyan programokra van szüksége, amelyek számos szótárat és referenciakönyvet kezelnek.
• Meg kell határoznia a lekérdezések végrehajtásának módszereit egy elosztott adatbázisban. A lekérdezések végrehajtásának módszerei egy elosztott adatbázisban eltérnek a központosított adatbázisokétól, mivel a lekérdezések egyes részeit a megfelelő adatok helyén kell végrehajtani, és a részeredményeket át kell adni más csomópontoknak; ugyanakkor biztosítani kell az összes folyamat koordinációját.
• Meg kell oldani a párhuzamos lekérdezés végrehajtásának problémáját. Egy elosztott adatbázisban kifinomult párhuzamosság -ellenőrzési mechanizmusra van szükség, amelynek különösen biztosítania kell a szinkronizálást az információk frissítésekor, ami biztosítja az adatok konzisztenciáját.
• Az adatok elosztására és elhelyezésére fejlett módszertanra van szükség, beleértve a felosztást is, ez az egyik fő követelmény az elosztott adatbázis számára.

A számítástechnikai rendszerek architektúrájának 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épeket nem numerikus feladatok megoldására használják, mint például dokumentumok és tények tárolása, keresése és átalakítása, valamint objektumokkal való munka. Miután az adatokat a környező világ tárgyainak digitális és grafikus információiként határozták meg, különböző tartalmak ágyazódnak be az adatok fogalmába numerikus és nem numerikus feldolgozásban. A numerikus feldolgozás olyan objektumokat használ, mint a változók, vektorok, mátrixok, többdimenziós tömbök, állandók stb., Míg a nem numerikus feldolgozás olyan objektumokat használ, mint a fájlok, rekordok, mezők, hierarchiák, hálózatok, kapcsolatok stb. közvetlenül az objektumokkal kapcsolatos információkban (például egy adott alkalmazott vagy egy alkalmazottak csoportja), és nem az alkalmazottak aktájában. Az alkalmazottak aktája itt nem indexelhető egy adott személy kiválasztásához; itt a kívánt bejegyzés tartalma érdekesebb. A nagy mennyiségű információt általában nem numerikus feldolgozásnak vetik alá. Különböző alkalmazásokban például a következő műveleteket hajthatja végre ezekkel az adatokkal:

• növelje a vállalat összes alkalmazottjának fizetését;
• kiszámítja a banki kamatot az összes ügyfél számláján;
• módosítsa a raktáron lévő összes áruk listáját;
• megtalálja a szükséges kivonatot a könyvtárban vagy a bibliográfiai információ -lekérdezési rendszerben tárolt összes szövegből;
• jogi dokumentumokat tartalmazó fájlban találja meg a szükséges szerződés leírását;
• böngésszen a szabadalmak leírását tartalmazó összes fájlban, és keresse meg újra a javasolthoz hasonló szabadalmat (ha van ilyen).

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

Az adatbázis -gépek egyre fontosabbak olyan mesterséges intelligencia -koncepciók kutatása és alkalmazása kapcsán, mint a tudásábrázolás, szakértői rendszerek, következtetés, mintafelismerés stb.

Információs tárolók. Ma már sokan elismerik, hogy a legtöbb vállalat már most is 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 különböző generációs DBMS -ekre is. A statisztikák szerint minden szervezet átlagosan 2,5 különböző DBMS -t használ. Nyilvánvalóvá vált, hogy "el kell különíteni" a vállalatok üzleti tevékenységét, vagy inkább az üzletben részt vevő személyeket az adatbázisok technológiai jellemzőitől, hogy a felhasználók egyetlen nézetet kapjanak a vállalati információkról, függetlenül attól, hogy hol tárolják azokat fizikailag. Ez ösztönözte az információ tárolási technológia megjelenését ( Adattárolás, DW).

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

A DW fejlesztésének új fordulója az információs technológiák fejlesztése általánosságban vált lehetővé, különösen a párhuzamos lekérdezésfeldolgozáson alapuló új típusú adatbázisok megjelenése miatt, amelyek viszont a párhuzamos számítógépek területén elért eredményekre támaszkodtak. Létre lett hozva lekérdezéskészítőkintuitív grafikus felülettel, amely megkönnyítette az összetett lekérdezések létrehozását az adatbázishoz. Különféle szoftverekközépső réteg (midleware)kommunikációt biztosítottkülönböző típusú adatbázisok között, és végül nagyot esetttárolóeszközök.

Adatbank jelen lehet a vállalat szerkezetében.

Adatbázis - funkcionális és szervezeti összetevő az automatizált vezérlőrendszerekben és az információs és számítástechnikai rendszerekben, központosított információs támogatást nyújtva egy felhasználói csoportnak vagy a rendszerben megoldott feladatoknak.

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 képező információhalmaz felhalmozása és működőképes működése;
• a feladat vagy felhasználó által megkövetelt adatok kiadásában;
• a tárolt információkhoz való kollektív hozzáférés biztosításában;
• az információs bázisban található információk felhasználásának szükséges kezelésének biztosításában.

Így a modern adatbank egy komplex szoftver és hardver komplexum, amely magában foglal technikai, rendszer- és hálózati eszközöket, adatbázisokat és DBMS -t, különféle célú információ -visszakereső rendszereket.

V .2. DBMS ÉS SZERKEZETI MEGOLDÁSOK A VÁLLALATI RENDSZEREKBEN

Adatbázis és tudásmenedzsment rendszerek

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

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

Az adatbázis -kezelő rendszer hozzáférést biztosít az adatfeldolgozó rendszerekhez az adatbázisokhoz. Mint már említettük, a DBMS -ek fontos szerepet kapnak a vállalati információs rendszerek létrehozásában, és különösen fontos szerepet játszanak a modern hálózati számítógépes technológiákon alapuló elosztott információforrásokat használó információs rendszerek létrehozásában.

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

• Ügyfél / szerver technológia.
• Az adatbázis nyelvek támogatása. aztséma definíciós nyelv DB (SDL - Schema Definition Language),adatmanipulációs nyelv (DML), integrált nyelvek SQL (Structured Queue Language), QDB (Query - By - Example) és QMF (Query Management Facility) ) Egy fejlett perifériás lekérdezési specifikációs és jelentési eszköz DB 2, stb .;
• Közvetlen adatkezelés a külső memóriában.
• RAM -pufferek kezelése.
• Tranzakció menedzsment. OLTP - technológia (On -line Transaction Processing), OLAP - technológia (On-line Analysis Processing) a DW számára.
• Biztosítsa az adatok védelmét és integritását. A rendszer használata csak azon felhasználók számára engedélyezett, akik jogosultak az adatokhoz való hozzáférésre. Amikor a felhasználók műveleteket hajtanak végre az adatokkal, 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 -nek biztosítania kell a fent felsorolt ​​adatbázis -követelmények betartását. Ezenkívül meg kell felelniük a következő elveknek:

• Az adatok függetlensége.
• Sokoldalúság. A DBMS -nek hatékony koncepcionális adatmodell -támogatással kell rendelkeznie 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 hardver fejlesztésével.
• Az adatok redundanciája. A fájlrendszerekkel ellentétben az adatbázisnak egyetlen integrált adatgyűjteménynek kell lennie.
• Adat védelem. A DBMS -nek védelmet kell nyújtania az illetéktelen hozzáférés ellen.
• Az adatok integritása. A DBMS -nek meg kell akadályoznia a felhasználókat az adatbázis feltörésében.
• Egyidejű munka irányítása. A DBMS -nek meg kell védenie az adatbázist a megosztott hozzáférési mód következetlenségeitől. Az adatbázis következetes á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 a különböző adatmodelleket egyetlen logikai és fizikai alapon.
• A DBMS -nek támogatnia kell mind a központosított, mind az elosztott adatbázisokat, és így fontos láncszemmé kell válnia a számítógépes hálózatokban.

Ha a DBMS -t olyan szoftvertermékek osztályának tekintjük, amelyek célja az adatbázisok automatizált rendszerekben történő karbantartása, akkor megkülönböztethetünk két legfontosabb jellemzőt, amelyek meghatározzák a DBMS típusait. Szerintük a DBMS két szempontból tekinthető:

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

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

• DBMS "asztali". Ezek a termékek elsősorban a személyes adatok („asztali” adatok) kezelésére irányulnak. Parancskészleteik vannak a közös adatbázisok megosztására, de kis méretűek (például egy kis iroda). Először is, ez egy DBMS, például Assess, dBASE, Paradox, EohPgo. Miért van rossz az Assess, a dBASE, a Paradox és az EohPgo hozzáférése a vállalati adatokhoz. A lényeg az, hogy nincs egyszerű módja annak, hogy leküzdjük a személyes és vállalati adatok közötti akadályt. És a lényeg nem is az, hogy a személyes adatok (vagy kis irodák) DBMS mechanizmusa az adatok elérésére összpontosít sok átjárón, internetes terméken stb. A probléma az, hogy ezek a mechanizmusok általában a teljes fájlátvitelhez és a villás index támogatásának hiányához kapcsolódnak, ami azt eredményezi, hogy a kiszolgálói sorok gyakorlatilag leállnak a nagy rendszereken.
• Speciális, nagy teljesítményű, többfelhasználós DBMS. Az ilyen DBMS -ekre jellemző a többfelhasználós rendszermag, az adatmanipulációs nyelv és a következő, fejlett többfelhasználós DBMS -ekre jellemző funkciók:
• a puffertár megszervezése;
• a tranzakciós sorok feldolgozására szolgáló rendszer jelenléte;
• a többfelhasználós adatok zárolásának mechanizmusai;
• tranzakciónaplózás;
• hozzáférés -ellenőrzési mechanizmusok elérhetősége.

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

Amikor adatbázisokkal dolgozik, a tranzakciós mechanizmust használja.

Tranzakció Logikus munkaegység.

Tranzakció egy végrehajtott adatmanipulációs utasítások sorozatamint egész(minden vagy semmi) és az adatbázis fordításaegyik holisztikus állapotból a másik holisztikus állapotba.

Egy tranzakciónak négy fontos tulajdonsága van, az úgynevezett ASID tulajdonságok:

• (A) Atomicitás ... A tranzakció atomi műveletként hajtódik végre - vagy a teljes tranzakciót hajtják végre, vagy nem hajtják végre teljesen.
• (C) Következetesség... A tranzakció az adatbázist egy következetes (konzisztens) állapotból egy másik konzisztens (konzisztens) állapotba helyezi át. Egy tranzakción belül megsérthető az adatbázis konzisztenciája.
• (I) Szigetelés ... 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 hajtották volna végre őket).
• (E) Tartósság... Ha a tranzakció befejeződött, akkor a munkájának eredményeit el kell menteni az adatbázisba, még akkor is, ha a következő pillanatban a rendszer összeomlik.

A tranzakció általában automatikusan kezdődik attól a pillanattól kezdve, amikor a felhasználó csatlakozik a DBMS -hez, és addig tart, amíg az alábbi események valamelyike ​​be nem következik:

• Parancs COMMIT WORK kiadva.
• A ROLLBACK WORK parancs kiadásra került.
• A felhasználó levált a DBMS -ről.
• Hiba történt a rendszerben.

A felhasználó számára általában visel atomi karakter... Valójában ez egy összetett felhasználó (alkalmazás) - adatbázis interakciós mechanizmus. A vállalati rendszerszoftver valós idejű tranzakciófeldolgozó motort használ (Online tranzakciófeldolgozó rendszerek, OLTP), különösen a számviteli programok, az ügyfelek megrendeléseinek fogadására és feldolgozására szolgáló szoftverek, pénzügyi alkalmazások sok információt szolgáltatnak. Ezeket a rendszereket nagy mennyiségű adat, bonyolult tranzakciók és intenzív olvasási / írási műveletek kezelésére tervezték (és megfelelően optimalizálták).

Sajnos az OLTP -rendszerek adatbázisaiban elhelyezett információk nem nagyon alkalmasak a hétköznapi felhasználók számára (a táblázatok nagyfokú normalizálása, 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ékek adatait (másolás értelmében) a rendszer a címre küldi tároló raktár, válogatás és ezt követő szállítás a fogyasztóhoz. Az információtechnológiában a raktárak szerepe vaninformáció tárolók.

Információk szállítása a végfelhasználóhoz - valós idejű analitikai adatfeldolgozó rendszerek (On-line analitikai feldolgozás, OLAP)amelyek rendkívül egyszerű hozzáférést biztosítanak az adatokhoz a lekérdezések generálásának és az eredmények elemzésének kényelmes módjaival. Az OLAP rendszerekben egy információs termék értéke növekszik a különböző elemzési és statisztikai feldolgozási módszerek alkalmazása miatt. Ezenkívül ezek a rendszerek optimalizáltak az adatok kinyerésének sebessége, az általánosított információk gyűjtése szempontjából, és a hétköznapi felhasználóknak szólnak (intuitív felületük van). Ha OLTP rendszer olyan egyszerű kérdésekre ad választ, mint "milyen volt az N termék értékesítési szintje az M régióban 199x januárjában?", akkor OLAP rendszerek készen áll a bonyolultabb felhasználói kérésekre, például: "Elemzés készítése az N termék értékesítéséről minden régióban a második negyedéves terv szerint a két előző évhez képest."

Ügyfél / szerver architektúra

A modern rendszerekben elosztott információfeldolgozás, a technológia áll a középpontban kliens / szerver. A rendszerben kliens-szerver architektúraaz adatfeldolgozás fel van osztva az ügyfélszámítógép és a szerver számítógép között, amelyek közötti kommunikáció a hálózaton keresztül történik. Az adatfeldolgozás ezen elkülönítése a funkciók csoportosításán alapul. Általában egy adatbázis -kiszolgáló számítógépet az adatbázis -műveletek végrehajtására szánnak, az ügyfélszámítógép pedig alkalmazásprogramokat futtat. A 2.1. Ábra egy egyszerű kliens-szerver architektúrarendszert mutat be, amely magában foglal egy kiszolgálóként működő számítógépet és egy másik számítógépet, amely ügyfélként működik. Minden gép különböző funkciókat lát el, és saját erőforrásokkal rendelkezik.

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

Rizs. 2.1. Ügyfél-szerver architektúra rendszer

Az ügyfélszámítógép fő funkciója az alkalmazás futtatása (felhasználói felület és megjelenítési logika) és kommunikáció a szerverrel, amikor az alkalmazás ezt igényli.

szerver Olyan objektum (számítógép), amely más objektumoknak kérésre szolgáltatásokat nyújt.

Ahogy a kifejezésből következik, a szerver számítógép fő funkciója az ügyfél igényeinek kiszolgálása. A "Szerver" kifejezés két különböző funkciócsoportra utal: a fájlszerverre és az adatbázis -kiszolgálóra (a továbbiakban ezek a kifejezések a kontextustól függően vagy a meghatározott funkciócsoportokat megvalósító szoftvert, vagy ezzel a szoftverrel rendelkező számítógépeket jelentik). A fájlszervereket nem adatbázis -műveletek végrehajtására tervezték, fő funkciójuk a fájlok megosztása több felhasználó között, azaz sok felhasználó egyidejű hozzáférésének biztosítása a számítógép - fájlszerver fájljaihoz. Egy fájlszerver példája a Novell NetWare operációs rendszere. Az adatbázis -kiszolgáló telepíthető és működtethető fájlkiszolgáló számítógépen. Az Oracle DBMS NLM (Network Loadable Module) formájában kerül végrehajtásra a fájlkiszolgáló NetWare környezetében.

A helyi hálózati szervernek rendelkeznie kell a funkcionális céljának és a hálózat igényeinek megfelelő erőforrásokkal. Ne feledje, hogy a nyílt rendszerek megközelítésére való összpontosítás miatt helyesebb logikai szerverekről beszélni (vagyis olyan erőforrásokról és szoftverekről, amelyek szolgáltatásokat nyújtanak ezen erőforrások felett), amelyek nem feltétlenül találhatók különböző számítógépeken. A nyílt rendszer logikai kiszolgálójának jellemzője, hogy ha a hatékonyság érdekében célszerű áthelyezni a szervert egy különálló számítógépre, akkor ezt meg lehet tenni anélkül, hogy bármilyen módosítást kellene végrehajtania önmagában és az alkalmazásokban is. hogy használják.

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

Elosztott számítástechnika

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

• 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 megszerzését a végfelhasználók számára különböző eszközök használatával.

Sokféle szerver létezik:

• Adatbázis -kiszolgáló;
• Nyomtatószerver;
• Távoli elérésű szerver;
• Faxszerver;
• Web szerver, stb.

Az alapul szolgáló technológia középpontjában a kliens / szerver áll olyan alapvető technológiák, mint:

• Operációs rendszer-technológiák, a nyitott rendszerek interakciójának koncepciója, 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;
• Grafikus felhasználói felület technológiák ( GUI);
• Stb.

A kliens-szerver technológia előnyei:

• Az ügyfél / 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 a 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.
• Végezze el a számítást ott, ahol a leghatékonyabb;
• Hatékony skálázási képesség biztosítása;
• Platformok közötti számítástechnika... A többplatformos számítást egyszerűen úgy határozzák meg, mint a technológiák heterogén számítási környezetben történő megvalósítását. Itt a következő lehetőségeket kell biztosítani:
• Az alkalmazásnak több platformon kell futnia;
• Ugyanazon felülettel és logikával kell rendelkeznie minden platformon;
• Az alkalmazásnak integrálódnia kell a natív működési környezetbe;
• Minden platformon ugyanúgy kell viselkednie;
• Ehhez egyszerű és következetes támogatást kell nyújtani.

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

 Létszámcsökkentés. A leépítés a nagyszámítógépes alkalmazások kis számítógépes platformokra történő átvitele.

• Csökkentett infrastruktúra és hardver költségek. Gazdaságos: Az olcsó számítástechnikai berendezések rendelkezésre állása és a helyi hálózatok növekvő terjedése gazdaságosabbá teszi a kliens-szerver technológiát, mint más adatfeldolgozási technológiák. A berendezések korszerűsíthetők, amint szükség van rá.

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

 Az ügyfél memóriahasználatának csökkentése;

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

• Képesség a multimédiával való munkavégzésre: a mai napig sok multimédiás program készült a számítógéphez. A terminál-gazda konfigurációhoz nincsenek ilyen programok, vagy nagyon drágák.
• Az a képesség, hogy nagy számítási erőforrásokat vonzzon az adatbázis-műveletekhez: mivel az alkalmazásokat ügyfélszámítógépeken hajtják végre, további (a terminál-gazda konfigurációhoz képest) erőforrások, például a központi processzor és az operatív memória számítási erőforrásai.
• Jobb programozói termelékenység: A programozók termelékenységét növeli az olyan eszközök használata, mint az SQL * Forms és a CASE, amelyek lehetővé teszik az alkalmazások gyorsabb fejlesztését, mint a C, PL1 vagy COBOL programozási nyelvek.
• Fokozott végfelhasználói termelékenység: Napjainkban sok végfelhasználó elsajátított olyan rendszereket, mint a Lotus, Paradox, Word Perfect, Harvard Graphics stb.

A kiszolgálóoldali interfész meghatározott és rögzített. Ezért lehetséges meglévő rendszer új ügyfélrészeinek létrehozása (példa az interoperabilitásra a rendszer szintjén).

Rizs. 2.2. Illusztráció az ügyfélhozzáférésről a kiszolgálómegosztáshoz.

Kliens-szerver technológia megvalósítása

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

• adatbázis -kiszolgáló számítógép;
• ügyfélszámítógépek;
• kommunikációs hálózat;
• hálózati szoftver;
• alkalmazás szoftver.

SQL nyelv ... Magas szintű lekérdezési nyelv - SQL (strukturált lekérdezési nyelv ) az adatbázisok, például a YAMD, a YOD és a PNP lekérdezéseinek végrehajtására szolgál, és szabványként elfogadott. Nyelv SQL eredetileg a vállalat szoftvertermékeinek adatnyelvének tekintették IBM és YAMD relációs DBMS SYSTEM R az IBM -től ... A nyelv fontos jellemzője SQL hogy ugyanazt a nyelvet két különböző interfészen keresztül mutatják be, nevezetesen: interaktív felületen és alkalmazásprogramozási felületen keresztül (dinamikus SQL). Dinamikus SQL sok beépített nyelvi funkcióból áll SQL , kifejezetten interaktív alkalmazások készítésére szolgál, ahol az interaktív alkalmazás alatt olyan programot értünk, amely az interaktív terminálon dolgozó végfelhasználó adatbázisához való hozzáférést támogatja. Nyelv SQL biztosítja az adatbázis -adatok meghatározásának, kezelésének é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. Séma felhasználói lekérdezések végrehajtására elosztott adatbázisokban.

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. A külső modelleket gyakran szintaktikai vagy működési modelleknek nevezik, utalva a vezérlés és használat szintaktikai jellegére, mint a felhasználói interakció eszköze az adatbázissal. Az információmodellezésben az absztrakció különböző szintjei vannak, a fogalmi modelltől a fizikai adatmodellig, amelyek befolyásolják a DBMS architektúráját.

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

• Az adatszerkezet, amelyet a felhasználó szemszögéből kell képviselni az adatbázisban.
• Az adatstruktúrán végrehajtott érvényes műveletek. Szükséges, hogy képes legyen dolgozni ezzel a struktúrával különböző NOD és NMD műveletek segítségével. A gazdag szerkezet nem ér semmit, ha nincs módja annak tartalmának manipulálására.
• Integrity Control kényszerek. Az adatmodellt olyan eszközökkel kell ellátni, amelyek megőrzik integritását és védik azt. Példaként vegye figyelembe az alábbi két megkötést:
• Minden részfának rendelkeznie kell forráscsomóponttal. A hierarchikus adatbázisokban nem tárolhat gyermekcsomópontokat forráscsomópont nélkül.
• Ami a relációs adatbázist illeti, nem lehetnek azonos sorok. Egy fájl esetében ez a követelmény megköveteli, hogy minden rekord egyedi legyen.

A DBMS egyik legfontosabb jellemzője az objektumok összekapcsolásának képessége.

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

• Egy-egy (1: 1)... Egy halmaz egyik objektuma társítható egy másik halmaz egyik objektumához.
• Egy-sok (1: M)... Egy halmaz egy objektuma egy másik halmaz sok objektumához társítható.
• Sok-sok (M: N)... Egy halmaz egyik objektuma társítható egy másik halmaz sok objektumához, ugyanakkor egy másik halmaz egyik objektuma az első halmaz számos objektumához.
• Megerősítve ... Egy halmaz egy objektuma sok halmaz objektumához társítható.
• Rekurzív ... Egy adott halmaz egy objektuma összekapcsolható ugyanazon halmaz objektumával.

A következő alapvető 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ÁZISHOZ

A kliens-szerver architektúrán alapuló rendszerek fő problémája az, hogy a nyílt rendszerek koncepciójának megfelelően mobilnak kell lenniük a nyílt rendszerek hardver- és szoftvermegoldásainak lehető legszélesebb osztályában. Még ha a UNIX alapú helyi hálózatokra is korlátozódunk, a különböző hálózatok különböző berendezéseket és kommunikációs protokollokat használnak. Az összes lehetséges protokollt támogató rendszerek létrehozására tett kísérletek a hálózati részletek túlterheléséhez vezetnek a funkcionalitás rovására.

Ennek a problémának még összetettebb aspektusa az a lehetőség, hogy a 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épeknek eltérő címzésük, számábrázolásuk, karakterkódolásuk stb. Ez különösen fontos a magas szintű szerverek esetében: távközlés, számítástechnika, adatbázisok.

A kliens-szerver architektúrán alapuló rendszerek mobilitási problémájának általános megoldása a távoli eljáráshívás (RPC) protokollokat megvalósító szoftvercsomagok használata. Ezekkel az eszközökkel a távoli webhelyen lévő szolgáltatás hívása normál eljáráshívásnak tűnik. Az RPC eszközök, amelyek természetesen minden információt tartalmaznak a helyi hálózati hardver és a hálózati protokollok sajátosságairól, a hívást hálózati interakciók sorozatává alakítják. Í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 meghívásakor az RPC programok kliens adatformátumokat géptől független köztes formátumokká alakítanak át, majd szerver adatformátumokká alakítják át. A válaszparaméterek átadásakor hasonló transzformációkat hajtanak végre.

Egyéb hasonló művek, amelyek érdekelhetik
6914.		Adatbázis fogalma	11,56 KB
	Az adatbázist objektív formában, a bírósági határozatok normatív jogi aktusainak számítási cikkeinek független anyagaiból és más hasonló anyagokból állítják össze, amelyeket úgy rendszereznek, hogy ezek az anyagok megtalálhatók és feldolgozhatók egy elektronikus számítógép segítségével az orosz polgári törvénykönyv Szövetség Art. A bizonyos szabályok szerint szervezett és a számítógép memóriájában karbantartott adatbázis olyan adathalmaz, amely jellemzi néhány ...
8064.		Elosztott adatbázisok	43,66 KB
	Elosztott adatbázisok Az elosztott adatbázis RDB alatt logikailag összekapcsolt megosztott adatok halmazát értjük, amelyek fizikailag vannak elosztva 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ációk jelenlététől vagy hiányától. A rendszernek automatikusan meg kell határoznia az adatfúziós kapcsolat végrehajtásának módszereit, a hálózati csatorna képes megbirkózni az átvitt információ mennyiségével, és a csomópont elegendő feldolgozási képességgel rendelkezik ahhoz, hogy csatlakozzon a táblázatokhoz. Az RDBMS -nek képesnek kell lennie ...
20319.		ADATBÁZISOK ÉS VÉDELEM	102,86 KB
	Az online online adatbázisok a hatvanas évek közepén jelentek meg. A működési adatbázisokon végzett műveleteket terminálok segítségével interaktívan dolgozták fel. Az egyszerű indexszekvenciális rekordszervezetek gyorsan fejlődtek egy hatékonyabb halmazorientált rekordmodellré. Charles Bachmann megkapta a Turing -díjat az Adatbázis Feladatcsoport (DBTG) vezetéséért, amely szabványos nyelvet dolgozott ki az adatok leírására és az adatkezelésre.
5031.		Adatbázis -fejlesztési könyvtár	11,72 MB
	Adatbázis tervezési technológia. Az entitások közötti kapcsolatok meghatározása és adatmodell létrehozása. A modern információs technológia fő elképzelései azon a koncepción alapulnak, amely szerint az adatokat adatbázisokba kell rendezni annak érdekében, 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óigényét. Ezek az adatbázisok az adatbázis -kezelő rendszerek DBMS nevű speciális szoftverrendszerek felügyelete alatt jönnek létre és működnek.
13815.		ADATBÁZIS HIERARCHIKUS MODELL	81,62 KB
	A modern információtechnológia fő elképzelései az adatbázisok koncepcióján alapulnak, amely szerint az információtechnológia alapját az adatbázisokba szervezett adatok képezik, amelyek megfelelően tükrözik egy adott tárgykör állapotát, és a felhasználó számára releváns információkat szolgáltatnak ezen a területen. Fel kell ismerni, 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 széles körű használatához vezetett.
5061.		Poliklinikai adatbázis létrehozása	2,4 MB
	A számítástechnika és az információtechnológia fejlődése lehetőséget biztosított az automatizált információs rendszerek (AIS) létrehozására és széles körű alkalmazására különböző célokra. A gazdasági és műszaki létesítmények kezelésére szolgáló információs rendszereket fejlesztik és hajtják végre
13542.		Földtani információs adatbázisok	20,73 KB
	Az utóbbi időben rohamos ütemben zajlik a számítógépes technológiák és különösen az adatbázisok tudományos szférába való bevezetése. Ez a folyamat sem kerüli meg a geológiát, 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 egyes tárgyaival kapcsolatos információk gyűjteménye a közgazdaságtan, menedzsment, kémia stb. Bármely tárgykörében. Az információs rendszer célja nem csupán az objektumokra vonatkozó adatok tárolása, hanem az adatok manipulálása is , figyelembe véve az objektumok közötti kapcsolatokat. Minden objektumra jellemző tulajdonságok halmaza jellemző, amelyeket attribútumoknak neveznek az adatbázisban.
5240.		A "dékáni hivatal" adatbázis létrehozása	1,57 MB
	Az adatbázis (DB) összekapcsolt adatok halmaza, amelyeket együtt tárolnak a számítógép külső adathordozóin, olyan szervezéssel és minimális redundanciával, amely lehetővé teszi azok optimális használatát egy vagy több alkalmazáshoz

Ipari adatmodellek

A modellek fő célja az adattérben való tájékozódás megkönnyítése és az üzleti fejlődés szempontjából fontos részletek kiemelése. A mai környezetben a sikeres üzlethez elengedhetetlen, hogy világosan megértsük a különböző összetevők közötti kapcsolatokat, és jó elképzelésünk legyen a szervezet összképéről. Az összes részlet és kapcsolat modellek segítségével történő azonosítása lehetővé teszi a vállalat munkájának megszervezéséhez szükséges idő és eszközök leghatékonyabb felhasználását.

Az adatmodellek absztrakt modellek, amelyek leírják az adatok megjelenítését és elérését. Az adatmodellek egy adott területen határozzák meg az adatelemeket és a köztük lévő kapcsolatokat. Az adatmodell olyan navigációs eszköz az üzleti és informatikai szakemberek számára, amely egy meghatározott szimbólum- és szóhalmazt használ, hogy pontosan megmagyarázza a valós információk egy adott osztályát. Ez lehetővé teszi a szervezeten belüli jobb kommunikációt, és ezáltal 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, mint például egy kép, bináris fájl vagy szöveg, ahol a jelentés kétértelmű lehet).

Általában a magasabb (és általánosabb tartalmú) és egy alacsonyabb (részletesebb) modelleket különböztetjük meg. 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 koncepcionális modell tartalmazza azokat a fő fogalmakat vagy tárgyköröket, 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) és ezen osztályok párjai közötti összefüggéseket (azaz kapcsolatokat). Mivel az üzleti modellezés terminológiája még nem teljesen letelepedett, a különböző angol nyelvű forrásokban a fogalmi adatmodelleket nevezhetjük tárgyterületi modellnek (amely lefordítható tartománymodellként) vagy tárgyi vállalati adatmodellnek (tárgyi vállalati adatmodellek) ).

A következő hierarchikus szint az logikai adatmodellek(logikai adatmodellek). Ezeket nevezhetjük vállalati adatmodelleknek vagy üzleti modelleknek is. Ezek a modellek adatstruktúrákat, azok attribútumait és üzleti szabályait tartalmazzák, és a vállalkozás üzleti szempontból használt információit reprezentálják. Egy ilyen modellben az adatok entitások és kapcsolatok formájában szerveződnek. A logikai modell úgy mutatja be az adatokat, hogy az üzleti felhasználók könnyen megértsék. Egy logikai modellben megkülönböztethető az adatszótár - 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 közösen megértsék a modell összes bemeneti és kimeneti adatfolyamát. A modellezés következő, alacsonyabb szintje a logikai modell fizikai megvalósítása speciális szoftverek és technikai platformok használatával.

A logikai modell részletes vállalati üzleti döntést tartalmaz, amely általában egy normalizált modell formájában jelenik meg. A normalizálás olyan folyamat, amely biztosítja, hogy a modell minden adatelemének csak egy értéke legyen, és teljesen és egyedileg függ az elsődleges kulttól. Az adatelemek egyedi azonosításuk szerint csoportokba vannak rendezve. Az adatelemekre vonatkozó üzleti szabályokat teljes mértékben be kell építeni a normalizált modellbe, előzetes érvényesítéssel és érvényesítéssel. Például egy adatelem, például az Ügyfél neve valószínűleg fel lesz osztva keresztnévre és vezetéknévre, és más kapcsolódó adatelemekkel egy elsődleges kulcsú ügyfél -azonosítóval rendelkező Ügyfél -entitásba van csoportosítva.

A logikai adatmodell független az olyan alkalmazási technológiáktól, mint az adatbázisok, hálózati technológiák vagy jelentési eszközök, valamint azok fizikai megvalósításának eszközeitől. Egy szervezetben csak egy vállalati adatmodell lehet. A logikai modellek általában több ezer entitást, kapcsolatot és attribútumot tartalmaznak. Például egy pénzügyi intézmény vagy távközlési vállalat adatmodellje körülbelül 3000 ipari koncepciót tartalmazhat.

Fontos különbséget tenni a logikai és a szemantikai adatmodell között. A logikai adatmodell egy vállalati üzleti megoldást, a szemantikai adatmodell pedig egy alkalmazott üzleti megoldást jelent. Ugyanaz a vállalati logikai adatmodell valósítható meg különböző szemantikai modellek használatával, azaz a szemantikai modellek a fizikai modellekhez közeledő modellezés következő szintjének tekinthetők. Ezenkívül ezek a modellek mindegyike a vállalati adatmodell külön "szeletét" képviseli a különböző alkalmazások követelményeinek megfelelően. Például a vállalati logikai adatmodellben a Client entitás teljesen normalizálódik, az adat mart szemantikai modelljében pedig többdimenziós szerkezetként ábrázolható.

Egy vállalatnak két módja lehet a vállalati logikai adatmodell létrehozására: önállóan felépítheti vagy készen állhat. ipari modell(ipari logikai adatmodell). Ebben az esetben a különbségek csak ugyanazon logikai modell felépítésének különböző megközelítéseit tükrözik. Abban az esetben, ha egy vállalat önállóan fejleszti és valósítja meg saját logikai adatmodelljét, akkor ezt a modellt általában vállalati logikai modellnek nevezik. Ha egy szervezet úgy dönt, hogy professzionális beszállítótól származó kész terméket használ, akkor beszélhetünk iparági logikai adatmodellről. 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 ipari logikai modell egy tartományspecifikus és integrált nézet az összes olyan információról, amelynek a vállalati adattárházban kell lennie, hogy válaszoljon mind a stratégiai, mind a taktikai üzleti kérdésekre. Mint minden más logikai adatmodell, az iparági modell független az alkalmazási döntésektől. Nem tartalmaz származtatott adatokat vagy más számításokat a gyorsabb adatvisszanyerés érdekében. Általában az ilyen modell legtöbb logikai struktúrája jól megtestesül a hatékony fizikai megvalósításban. Az ilyen modelleket számos beszállító dolgozza ki a legkülönfélébb tevékenységi területekre: 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 közösek az iparág számára, és ezért nem jelenthetnek átfogó 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 a definíciók bővítésével. A kész modellek csak kulcsfontosságú adatelemeket tartalmaznak, és a többi elemet hozzá kell adni a megfelelő üzleti objektumokhoz a modell vállalaton belüli telepítése során.

Az ipari logikai adatmodellek jelentős mennyiségű absztrakciót tartalmaznak. Az absztrakciók azt jelentik, hogy hasonló fogalmakat egyesítenek köznevek alatt, mint például Esemény vagy Résztvevő. Ez rugalmasságot és egységességet kölcsönöz az ipari modelleknek. Így az Esemény fogalma minden iparágra alkalmazható.

Steve Hoberman, az üzleti intelligencia szakértője öt tényezőt határoz meg, amelyeket figyelembe kell venni, amikor eldöntik, hogy beszerznek -e egy ipari adatmodellt. Az első a modell elkészítéséhez szükséges idő és pénz. Ha egy szervezetnek gyorsan kell eredményeket elérnie, akkor az iparági modell előnyös lesz. Az iparági modell használata nem biztos, hogy azonnal képet ad a teljes szervezetről, de jelentős időt takaríthat meg. Maga a modellezés helyett időt fog fordítani a meglévő struktúrák összekapcsolására az ipari modellel, és megvitatják, hogyan lehet a legjobban testreszabni a szervezet igényeihez (például, hogy mely definíciókat kell megváltoztatni, és mely adatelemeket kell hozzáadni).

A második tényező a modell megfelelő működéséhez szükséges idő és pénz. Ha a vállalati adatmodell nem része annak a módszertannak, amely lehetővé teszi a pontosságnak való megfelelés és a modern szabványoknak való megfelelés ellenőrzését, akkor egy ilyen modell nagyon gyorsan elavul. Az iparági adatmodell megakadályozhatja ezt a kockázatot, mivel a külső erőforrásokkal naprakészen tartják. Természetesen a szervezeten belül bekövetkező változásokat a vállalatnak magának kell tükröznie a modellben, de az iparági változásokat a szállító 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 minősített 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 osztály tevékenységét. Közülük kevesen rendelkeznek széles körű (vállalati szintű) és mély (osztályokon belüli) ismeretekkel üzletükről. A legtöbb menedzser általában csak egy területet ismer jól. Ezért az általános vállalati kép megszerzéséhez jelentős üzleti erőforrásokra van szükség. Ez növeli az informatikai személyzettel szembeni elvárásokat is. Minél több üzleti erőforrás szükséges egy modell létrehozásához és teszteléséhez, annál tapasztaltabb elemzőknek kell lenniük. Nemcsak tudniuk kell, hogyan szerezzenek információt az üzleti személyzettől, hanem képesnek kell lenniük a közös álláspont megtalálására a vitás területeken, és képesnek kell lenniük arra, hogy ezeket az információkat integráltan mutassák be. A modellt létrehozó személynek (sok esetben ugyanazon elemzőnek) jó modellezési készségekkel kell rendelkeznie. A vállalati logikai modellek felépítése megköveteli a „jövőre vonatkozó” modellezést, és azt a képességet, hogy az összetett üzleti tevékenységeket szó szerint „négyzetekké és vonalakká” alakítsuk át.

Másrészt az iparági modell külső szakértelmet tesz lehetővé. Az iparág-specifikus logikai modellek bevált modellezési módszerek és tapasztalt szakemberekből álló csapatok felhasználásával készülnek, hogy elkerüljék a közös és költséges problémákat, amelyek felmerülhetnek a vállalati adatmodellek szervezeten belüli kidolgozásakor.

A negyedik tényező a meglévő alkalmazásinfrastruktúra és a beszállítói kapcsolatok. Ha egy szervezet már számos eszközt használ ugyanaztól a szállítótól, és kapcsolatot létesített vele, akkor értelmes és az iparági modell szerint érdemes tőle rendelni. Ez a 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 kommunikálnia kell más, azonos területen dolgozó szervezetekkel, akkor az iparági modell nagyon hasznos lehet ebben a helyzetben. Az ugyanazon iparág szervezetei hasonló szerkezeti elemeket és terminológiát használnak. Napjainkban a legtöbb iparágban a vállalatok adatcserére kényszerülnek, hogy sikeresen folytathassák üzleti tevékenységüket.

A leghatékonyabbak a professzionális beszállítók által kínált ipari modellek. Használatuk magas hatékonysága érhető el ezen modellek jelentős részletességének és pontosságának köszönhetően. Általában sok adatattribútumot tartalmaznak. Ezen túlmenően ezeknek a modelleknek az alkotói nemcsak széles körű modellezési tapasztalattal rendelkeznek, hanem jól ismerik az adott iparág modelljeit is.

Az iparági adatmodellek egyetlen, integrált nézetet biztosítanak a vállalatoknak üzleti információikról. Sok vállalat nehezen integrálja 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 úgy találta, hogy az integráció jelentős akadályt jelent az új alkalmazások elfogadása előtt. Éppen ellenkezőleg, az adatintegráció megvalósítása kézzelfogható jövedelmet termel a vállalat számára.

Az iparági adatmodell a meglévő rendszerekhez való kapcsolódáson túl nagy előnyökkel jár az olyan vállalati szintű projektek számára, mint a vállalati erőforrás-tervezés (ERP), a törzsadat-kezelés, az üzleti intelligencia, az adatminőség javítása és az alkalmazottak fejlesztése.

Így az ipari logikai adatmodellek hatékony eszköz az adatok integrálására és a vállalkozás holisztikus szemléletének megszerzésére. A logikai modellek használata 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 logikai adatmodelljének kihasználása vállalati adatmodellként.
2. Claudia Imhoff. Gyorsan nyomon követhető adattárolási és üzleti intelligencia projektek az intelligens adatmodellezés révén

Zaitsev S.L., Ph.D.

Ismétlődő csoportok

Az ismétlődő csoportok olyan attribútumok, amelyekhez az entitás egyetlen példányának több értéke is lehet. Például egy személynek több készsége is lehet. Ha az üzleti követelményeket illetően ismernünk kell a képzettségi szintet mindegyiknél, és minden személynek csak két készsége lehet, akkor létrehozhatjuk az ábrán látható entitást. 1.6. Itt az entitás EGY SZEMÉLY két attribútummal a készségek és készségszint tárolására.

Rizs. 1.6. Ez a példa ismétlődő csoportokat használ.

A csoportok ismétlésével az a probléma, hogy nem tudhatjuk pontosan, hogy egy személy hány készséggel rendelkezik. A való életben van, akinek van egy készsége, van, akinek több, és van, akinek még nincs. Az 1.7. Ábra az első normál formára redukált modellt mutatja. Vegye figyelembe a hozzáadottakat A készség azonosítója hogy mindegyik egyedileg azonosítja KÉSZSÉG.

Rizs. 1.7. A modell az első normál formára redukálva.

Egy tény egy helyen

Ha ugyanaz az attribútum több entitásban is jelen van, és nem idegen kulcs, akkor ez az attribútum redundánsnak minősül. A logikai modell nem tartalmazhat redundáns adatokat.

A redundancia további helyet igényel, de bár a memória hatékonysága fontos, az igazi probléma máshol rejlik. Fölösleges a redundáns adatok szinkronizálásának biztosítása, és mindig fennáll az ütköző értékek kockázata.

Az előző példában KÉSZSÉG attól függ Személyazonosítóés onnan A készség azonosítója. Ez azt jelenti, hogy nem lesz KÉSZSÉG amíg meg nem jelenik EGY SZEMÉLY, rendelkezik ezzel a készséggel. Ez megnehezíti a készségnév megváltoztatását is. Minden egyes bejegyzést meg kell találni a készség nevével, és meg kell változtatni minden olyan személynél, aki rendelkezik ezzel a készséggel.

Az 1.8. Ábra a modellt normál formában mutatja. Vegye figyelembe, hogy a hozzáadott entitás KÉSZSÉG, és az attribútum CÍM a készség átkerül ebbe az entitásba. A képzettségi szint a kereszteződésben maradt SZEMÉLYEK és KÉSZSÉG.

Rizs. 1.8. A második normál formában az ismétlődő csoport egy másik entitásba kerül. Ez rugalmasságot biztosít a szükséges számú készség hozzáadásához és a képesség nevének vagy készségleírásának egy helyen történő megváltoztatásához.

Minden attribútum a kulcstól függ

Az entitás minden attribútumának az adott entitás elsődleges kulcsától kell függnie. Az előző példában Iskola neveés Földrajzi terület táblázatban szerepel EGY SZEMÉLY de ne írja le az illetőt. A harmadik normál forma eléréséhez át kell helyeznie az attribútumokat az entitásba, ahol azok a kulttól függenek. 1.9. a modellt a harmadik normál formában mutatja.

Rizs. 1.9. Harmadik normál formában Iskola neveés Földrajzi régió entitásba kerül, ahol értékeik a kulttól függenek.

Sok-sok kapcsolat

Kapcsolat sok-sok tükrözik a környező világ valóságát. Vegye figyelembe, hogy az 1.9. Ábrán sok-sok kapcsolat van SZEMÉLYESés ISKOLA... A hozzáállás pontosan tükrözi azt a tényt, hogy EGY SZEMÉLY sokban tanulhat ISKOLÁKés benne ISKOLA sokat tanulhat SZEMÉLY. A negyedik normál forma eléréséhez egy asszociatív entitás jön létre, amely kiküszöböli a monogy-sok kapcsolatot, azáltal, hogy külön bejegyzést generál az iskola és a személy egyedi kombinációihoz. Az 1.10. Ábra a modellt mutatja negyedik normál formában.

Rizs. 1.10. Negyedik normál formában monogó-sok kapcsolat között SZEMÉLYESés ISKOLA egy asszociatív entitás bevezetésével oldható meg, amelyben minden egyes kombinációhoz külön bejegyzést rendelnek ISKOLÁKés SZEMÉLYEK.

A normál formák formai meghatározása

A normál formák alábbi definíciói ijesztőnek tűnhetnek. Gondoljon rájuk egyszerűen a normalizálás elérésére szolgáló képletekként. A normál formák a relációs algebrán alapulnak, és matematikai transzformációkként értelmezhetők. Bár ez a könyv nem foglalkozik a normál formák részletes tárgyalásával, a modellezőket arra ösztönzik, hogy mélyebben vizsgálják meg a témát.

Egy adott R relációban az Y attribútum funkcionálisan függ az X attribútumtól. Szimbolikus formában RX -> RY (olvasható úgy, hogy "RX funkcionálisan meghatározza az RY -t") - akkor és csak akkor, ha az X minden értéke pontosan egyhez kapcsolódik Y értéke R -ben (bármikor). Az X és Y attribútumok összetettek lehetnek (Dátum: CJ. Introduction to Database Systems. 6. kiadás. Ed. Williams: 1999, 848 pp.).

Az R reláció akkor és csak akkor felel meg az első normál formának (1NF), ha a hozzá tartozó összes tartomány csak atomértékeket tartalmaz (Dátum, uo.).

Az R reláció akkor és csak akkor felel meg a második normál formának (2NF), ha az 1NF-nek felel meg, és minden nem kulcsjellemző teljesen függ az elsődleges kulcstól (Dátum, uo.).

Az R reláció akkor és csak akkor felel meg a harmadik normál formának (3NF), ha megfelel a 2NF-nek, és minden nem-kulcs attribútum nem függ átmenetileg az elsődleges kulcstól (Dátum, uo.).

Az R összefüggés akkor és csak akkor felel meg Boyes-Codd normálformának (BCNF), ha minden determináns jelöltként használható kulcsként.

JEGYZET Az alábbiakban röviden ismertetjük a Date definícióiban használt rövidítéseket.

Az MVD (többértékű függőség) többértékű függőség. Csak három vagy több attribútummal rendelkező entitásoknál használható. Többértékű függőség esetén az attribútum értéke csak az elsődleges kulcs egy részétől függ.

FD (funkcionális függőség) - funkcionális függőség. Funkcionális függőség esetén az attribútum értéke egy másik attribútum értékétől függ, amely nem része az elsődleges kulcsnak.

A JD (join dependency) csatlakozásfüggőség. Szakszervezeti függőségben az anyavállalat elsődleges kulcsa legalább a harmadik szintű leszármazottakra vezethető vissza, miközben megtartja azt a képességet, hogy az eredeti kulccsal használható legyen az unióban.

Az arány akkor és csak akkor felel meg a negyedik normálformának (4NF), ha R -ben van MVD, például A®®B. Ebben az esetben az összes R attribútum funkcionálisan függ az A -tól. Más szóval, R -ben csak a K®X alakú függőségek (FD vagy MVD) vannak (vagyis az X attribútum funkcionális függősége a jelölttől) kulcsként használja K). Ennek megfelelően R megfelel a 4NF követelményeinek, ha megfelel a BCNF -nek, és minden MVD valójában FD (dátum, uo.).

Az ötödik normálformánál az R reláció kielégíti az uniófüggést (JD) * (X, Y,…, Z), és csak akkor, ha R egyenértékű az X -re, Y -re, Z -re vetített vetületeivel, ahol X, Y, ..., Z az R attribútumhalmaz részhalmaza.

Számos más normál űrlap létezik a bonyolult adattípusokhoz és konkrét helyzetekhez, amelyek kívül esnek a vita keretein. Minden modellfejlesztési rajongó szeretne más normál formákat is megtanulni.

Üzleti normál űrlapok

Clive Finklestein (An Introduction to Information Engineering: From Strategic Planning to Information Systems. Reading, Massachusetts: Addison-Wesley, 1989) című könyvében más megközelítést alkalmazott a normalizáláshoz. Meghatározza az üzleti normál formákat az ilyen formákra való kényszerítés szempontjából. Sok modellező intuitívabbnak és pragmatikusabbnak tartja ezt a megközelítést.

Az első üzleti normál űrlap (1BNF) az ismétlődő csoportokat egy másik entitáshoz viszi ki. Ez az entitás saját nevét és elsődleges (összetett) kulcstulajdonságait kapja az eredeti entitástól és annak ismétlődő csoportjától.

A második üzleti normál űrlap (2BNF) az elsődleges kulcstól részben függő attribútumokat távolítja el egy másik entitáshoz. Ennek az entitásnak az elsődleges (összetett) kulcsa annak az entitásnak az elsődleges kulcsa, amelyben eredetileg található, valamint további kulcsok, amelyektől az attribútum teljes mértékben függ.

A harmadik üzleti normál forma (3BNF) az elsődleges kulcstól független attribútumokat átveszi egy másik entitásba, ahol teljesen függenek az entitás elsődleges kulcsától.

A negyedik üzleti normál forma (4BNF) olyan attribútumokat vesz fel, amelyek az elsődleges kulcs értékétől függenek, vagy opcionálisak egy másodlagos entitás számára, ahol teljes mértékben az elsődleges kulcs értékétől függenek, vagy ahol (szükségszerűen) jelen kell lenniük entitás.

Az ötödik üzleti normál forma (5BNF) strukturális entitásként jelenik meg, ha rekurzív vagy más függőség van a másodlagos entitás példányai között, vagy ha rekurzív függőség létezik az elsődleges entitás példányai között.

Befejezett logikai adatmodell

A befejezett logikai modellnek meg kell felelnie a harmadik üzleti normál űrlap követelményeinek, és tartalmaznia kell az összes entitást, attribútumot és kapcsolatot, amelyek szükségesek az adatokkal kapcsolatos adatszolgáltatási követelmények és üzleti szabályok alátámasztásához.

Minden entitásnak neveket kell tartalmaznia, amelyek leírják tartalmukat, és világos, tömör, teljes leírással vagy meghatározással kell rendelkezniük. A jövőbeli bejegyzés egy kezdeti iránymutatást fog tartalmazni az entitásnevek és leírások helyes kialakítására vonatkozóan.

Az entitásoknak teljes attribútumkészlettel kell rendelkezniük, hogy az egyes entitásokkal kapcsolatos minden tény megjeleníthető legyen az attribútumaival. Minden attribútumnak rendelkeznie kell a jelentését tükröző névvel, logikai adattípussal, valamint világos, rövid, teljes leírással vagy definícióval. Egy későbbi blogbejegyzésben megvizsgáljuk az attribútumnevek és -leírások megfelelő formázására vonatkozó kezdeti irányelveket.

A kapcsolatoknak tartalmazniuk kell egy verbális konstrukciót, amely leírja az entitások közötti kapcsolatot, valamint olyan jellemzőket, mint a pluralitás, a létezés szükségessége vagy a kapcsolat hiányának lehetősége.

JEGYZET Pluralitás kapcsolat leírja az eredeti entitás egy példányához társítható másodlagos entitáspéldányok maximális számát.A lét szükségessége vagytávollét lehetősége kapcsolat a másodlagos entitás azon példányainak minimális számának meghatározására szolgál, amelyek az eredeti entitás egy példányához társíthatók.

Fizikai adatmodell

Miután elkészült egy teljes és megfelelő logikai modell, készen áll arra, hogy döntést hozzon a megvalósítási platform kiválasztásáról. A platform kiválasztása az adatok felhasználásának követelményeitől és a vállalat architektúrájának kialakításának stratégiai elveitől függ. A platform kiválasztása összetett kérdés, amely túlmutat e könyv keretein.

Az ERwin-ben a fizikai modell egy valós adatbázis grafikus ábrázolása. A fizikai adatbázis táblákból, oszlopokból és kapcsolatokból fog állni. A fizikai modell a végrehajtáshoz kiválasztott platformtól és az adatok felhasználásának követelményeitől függ. Az IMS fizikai modellje nagyon különbözik a Sybase modelljétől. Az OLAP jelentések fizikai modellje más lesz, mint az OLTP (online tranzakciófeldolgozás) modellje.

Az adatmodellező és adatbázis -adminisztrátor (DBA) a logikai modellt, a használati követelményeket és a vállalati architektúra házirendjét használja egy fizikai adatmodell kifejlesztéséhez. A teljesítmény javítása érdekében denormalizálhatja a fizikai modellt, és létrehozhat nézeteket a használati követelmények támogatására. A következő szakaszok részletezik a nézetek denormalizálásának és létrehozásának folyamatát.

Ez a szakasz áttekintést nyújt a fizikai modell felépítésének folyamatáról, az adathasználati követelmények gyűjtéséről, a fizikai modell összetevőinek meghatározásáról és a fordított tervezésről. A következő publikációkban ezekkel a kérdésekkel foglalkozunk részletesebben.

Adathasználati követelmények gyűjtése

Általában az adathasználati követelményeket az interjúk és a munkamenetek elején korán gyűjti össze. Ugyanakkor a követelményeknek a lehető legteljesebb mértékben meg kell határozniuk az adatok felhasználó általi felhasználását. A fizikai modell felületes hozzáállása és hiányosságai nem tervezett költségekhez és a projektek végrehajtásának késedelméhez vezethetnek. A használat követelményei a következők:

Hozzáférési és teljesítménykövetelmények

Térfogati jellemzők (a tárolni kívánt adatmennyiség becslése), amelyek lehetővé teszik a rendszergazda számára az adatbázis fizikai térfogatának ábrázolását

Annak a felhasználónak a becslése, akinek párhuzamos hozzáférésre van szüksége az adatokhoz, hogy segítsen az adatbázis elfogadható teljesítményszintű kialakításában

Összesített, összefoglaló és egyéb számított vagy származtatott adatok, amelyek a tartós adatstruktúrákban való tárolás jelöltjeinek tekinthetők

Jelentésekre és szabványos lekérdezésekre vonatkozó követelmények, amelyek segítik az adatbázis -adminisztrátort az indexek felépítésében

Nézetek (állandó vagy virtuális), amelyek segítik a felhasználót az adatok összesítésében vagy szűrési műveleteiben.

Az elnök, a titkár és a felhasználók mellett a modellezőnek, az adatbázis -adminisztrátornak és az adatbázis -építésznek is részt kell vennie a használati követelmények munkamenetében. Meg kell vitatni a felhasználó korábbi adatigényeit. Az adatok megőrzésének időtartama jelentősen befolyásolja az adatbázis méretét. A régebbi adatokat gyakran általánosított formában tárolják, az atomi adatokat archiválják vagy törlik.

A felhasználóknak példákat kell hozniuk a kérésekre és jelentésekre az ülésen. A jelentéseket szigorúan meg kell határozni, és tartalmazniuk kell az összesítő és összefoglaló mezőkhöz használt atomértékeket.

Fizikai adatmodell összetevői

A fizikai adatmodell összetevői táblázatok, oszlopok és kapcsolatok. A logikai modell entitások valószínűleg táblákká válnak a fizikai modellben. A logikai attribútumok oszlopokká válnak. A logikai kapcsolatok a kapcsolatok integritásának korlátai lesznek. Néhány logikai kapcsolat nem valósítható meg fizikai adatbázisban.

Visszafejtés

Ha egy logikai modell nem áll rendelkezésre, szükségessé válik a modell újratelepítése a meglévő adatbázisból. Az ERwin -ben ezt a folyamatot fordított tervezésnek nevezik. A fordított tervezés többféleképpen is elvégezhető. A modellező felfedezheti az adatbázis adatstruktúráit, és vizuális modellezési környezetben újból létrehozhatja a táblázatokat. Importálhatja az adatmeghatározási nyelvet (DDL) egy olyan eszközbe, amely támogatja a fordított tervezést (például Erwin). Az olyan fejlett eszközök, mint az ERwin, olyan funkciókat tartalmaznak, amelyek ODBC kommunikációt biztosítanak egy meglévő adatbázissal, hogy modellt hozzanak létre az adatstruktúrák közvetlen olvasásával. A fordított tervezést az ERwinnel részletesen tárgyaljuk egy következő bejegyzésben.

A vállalati funkcionális határok használata

A modellező logikai modelljének felépítésekor fontos gondoskodni arról, hogy az új modell összhangban legyen a vállalati modellel. A vállalati funkcionális határok használata az adatok modellezését jelenti egy vállalaton belül. Az adatok felhasználásának módja egy vállalatnál gyorsabban változik, mint maga az adat. Minden logikai modellben az adatokat holisztikus módon kell bemutatni, függetlenül az általuk támogatott üzleti területtől. Az entitásoknak, attribútumoknak és kapcsolatoknak meg kell határozniuk az üzleti szabályokat vállalati szinten.

JEGYZET Néhány kollégám ezeket a vállalati funkcionális határokat valós modellezésnek nevezi. A valós modellezés arra ösztönzi a modellezőt, hogy az információkat a ténylegesen velejáró kapcsolatok és kapcsolatok alapján tekintse meg.

A vállalati funkcionális határok használata a megfelelően felépített adatmodellhez biztosítja az alapot tetszőleges számú folyamat és alkalmazás információs igényeinek kielégítéséhez, ami lehetővé teszi a vállalat számára, hogy hatékonyabban kiaknázza egyik legértékesebb eszközét - az információt.

Mi az a vállalati adatmodell?

Vállalati adatmodell (EDM) olyan entitásokat, attribútumokat és kapcsolatokat tartalmaz, amelyek egy vállalat információs igényeit képviselik. Az EDM -et általában a témakörök szerint kategorizálják, amelyek az adott üzleti igények támogatásával kapcsolatos entitáscsoportokat képviselik. Egyes témakörök lefedhetnek bizonyos üzleti funkciókat, például a szerződéskezelést, míg mások olyan termékeket vagy szolgáltatásokat leíró szervezeteket.

Minden logikai modellnek meg kell felelnie a vállalati adatmodell meglévő tartományának. Ha a logikai modell nem felel meg ennek a követelménynek, akkor hozzá kell adni egy tartománymodellt. Ez az összehasonlítás biztosítja, hogy a vállalati modell javul vagy kiigazításra kerül, és minden logikai modellezési erőfeszítés összehangolódik a vállalaton belül.

EDM tartalmazza azokat az egyedi entitásokat is, amelyek meghatározzák a kulcs attribútumok értéktartományát. Ezeknek az entitásoknak nincsenek szüleik, és függetlenek. Független entitásokat gyakran használnak a kapcsolatok integritásának fenntartására. Ezeket az entitásokat több különböző névvel azonosítják, például kódtáblázatok, referenciatáblázatok, típus- vagy osztályozási táblázatok. A "vállalati üzleti objektum" kifejezést fogjuk használni. A vállalati üzleti objektum olyan entitás, amely minden más entitástól független attribútumérték -készletet tartalmaz. A vállalati üzleti objektumokat következetesen kell használni a vállalaton belül.

Vállalati adatmodell kiépítése bővítéssel

Vannak olyan szervezetek, ahol a vállalati modellt egyetlen összehangolt erőfeszítés eredményeként az elejétől a végéig építették ki. Másrészt a legtöbb szervezet a méretezéssel meglehetősen teljes vállalati modelleket hoz létre.

A felépítés azt jelenti, hogy valamit szekvenciálisan, rétegenként építünk, akárcsak az osztriga gyöngyöt termeszt. Minden létrehozott adatmodell hozzájárul az EDM kialakításához. Az EDM ilyen módon történő felépítése további modellezési lépéseket igényel új adatstruktúrák és tartományok hozzáadásához vagy a meglévő adatstruktúrák bővítéséhez. Ez lehetővé teszi a vállalati adatmodell felépítését a részletek kiegészítésével, iteratív hozzáadásával.

Modellezési módszertani koncepció

Számos vizuális adatmodellezési módszer létezik. Az ERwin kettőt támogat:

IDEF1X (Integration Definition for Information Modeling - az információs modellek integrált leírása).

IE (Information Engineering).

Az IDEF1X jó módszertan, és jelölésének használata széles körben elterjedt

Az információs modellek integrált leírása

Az IDEF1X egy strukturált adatmodellezési módszer, amely kiterjeszti a FIPS (Federal Information Processing Standards) szabványként elfogadott IDEF1 módszert. Az IDEF1X egy rendkívül strukturált modellezési konstrukciót használ, és olyan adatmodellt eredményez, amely megköveteli az adatok fizikai jellegének megértését, mielőtt az ilyen információkat elérhetővé tennék.

Az IDEF1X merev szerkezete arra kényszeríti a modellezőt, hogy olyan jellemzőket rendeljen az entitásokhoz, amelyek esetleg nem felelnek meg a környező világ valóságának. Például az IDEF1X megköveteli, hogy minden entitás altípus kizárólagos legyen. Ez ahhoz vezet, hogy egy személy nem lehet egyszerre ügyfél és alkalmazott. Míg a valódi gyakorlat mást mond nekünk.

Információtechnika

Clive Finklesteint gyakran nevezik az információtechnika atyjának, bár hasonló fogalmakat James Martin is megosztott vele (Martin, James. Managing the Database Environment. Upper Saddle River, New Jersey: Prentice Hall, 1983.). Az információtechnológia üzleti alapú megközelítést alkalmaz az információkezeléshez, és más jelölést használ az üzleti szabályok megjelenítésére. Az IE kiterjeszti és fejleszti a Peter Chen által javasolt ER módszertan jelölését és alapfogalmait.

Az IE biztosítja az információs követelmények támogatásához szükséges infrastruktúrát azáltal, hogy integrálja a vállalati stratégiai tervezést a fejlesztés alatt álló információs rendszerekkel. Ez az integráció lehetővé teszi az információs erőforrások kezelésének szorosabb igazítását a vállalat hosszú távú stratégiai kilátásaival. Ez az üzleti alapú megközelítés sok modellezőt arra késztetett, hogy az IE mellett más módszereket válasszanak, amelyek általában a rövid távú fejlesztési kihívásokra összpontosítanak.

Az IE olyan műveletsort javasol, amely arra készteti a vállalatot, hogy azonosítsa az adatgyűjtéshez és kezeléshez szükséges összes információszükségletét, valamint az információs objektumok közötti kapcsolatokat. Ennek eredményeképpen az információs követelmények egyértelműen a menedzsment irányelvei alapján vannak megfogalmazva, és közvetlenül lefordíthatók egy olyan vezetői információs rendszerre, amely támogatja a stratégiai információs igényeket.

Következtetés

Az ERwin -hez hasonló adatmodellező eszköz használatának megértése csak a probléma része. Ezenkívül meg kell értenie, hogy mikor oldják meg az adatmodellezési feladatokat, és hogyan gyűjtik össze az adatmodellben megjelenítendő információs követelményeket és üzleti szabályokat. A munkamenetek lebonyolítása a legkedvezőbb környezetet biztosítja az információszükségletek összegyűjtéséhez olyan környezetben, amely magában foglalja a tartomány szakértőit, a felhasználókat és az informatikai szakembereket.

A jó adatmodell felépítése megköveteli a munkamenetek és interjúk során összegyűjtött információs követelmények és üzleti szabályok elemzését és kutatását. A kapott adatmodellt, ha lehetséges, össze kell hasonlítani a vállalati modellel annak biztosítása érdekében, hogy ne ütközzen a meglévő objektummodellekkel, és tartalmazza az összes szükséges objektumot.

Az adatmodell logikai és fizikai modellekből áll, amelyek információs követelményeket és üzleti szabályokat képviselnek. A logikai modellt a harmadik normál formára kell csökkenteni. A harmadik normál forma korlátozza, hozzáteszi, frissíti és eltávolítja az adatszerkezeti anomáliákat, hogy támogassa az "egy tény egy helyen" elvet. Az összegyűjtött információs követelményeket és üzleti szabályokat elemezni és kutatni kell. Össze kell hasonlítani őket a vállalati modellel annak biztosítása érdekében, hogy ne ütközzenek a meglévő objektummodellekkel, és tartalmazzák az összes szükséges objektumot.

Az ERwin -ben az adatmodell logikai és fizikai modelleket is tartalmaz. Az ERwin megvalósítja az ER megközelítést, és lehetővé teszi logikai és fizikai modellobjektumok létrehozását az információs követelmények és az üzleti szabályok megjelenítésére. A logikai modellobjektumok közé tartoznak az entitások, attribútumok és kapcsolatok. A fizikai modellobjektumok táblázatokat, oszlopokat és a kapcsolatok integritására vonatkozó korlátozásokat tartalmaznak.

A következő kiadványok egyike az entitások azonosításával, az entitás típusok meghatározásával, az entitásnevek és leírások kiválasztásával, valamint néhány technikával foglalkozik az entitások használatával kapcsolatos leggyakoribb modellezési hibák elkerülése érdekében.

Az entitásoknak teljes attribútumkészlettel kell rendelkezniük, hogy az egyes entitásokkal kapcsolatos minden tény megjeleníthető legyen az attribútumaival. Minden attribútumnak rendelkeznie kell a jelentését tükröző névvel, logikai adattípussal, valamint világos, rövid, teljes leírással vagy definícióval. Egy későbbi blogbejegyzésben megvizsgáljuk az attribútumnevek és -leírások megfelelő formázására vonatkozó kezdeti irányelveket. A kapcsolatoknak tartalmazniuk kell egy verbális konstrukciót, amely leírja az entitások közötti kapcsolatot, valamint olyan jellemzőket, mint a pluralitás, a létezés szükségessége vagy a kapcsolat hiányának lehetősége.

JEGYZET Pluralitás kapcsolat leírja az eredeti entitás egy példányához társítható másodlagos entitáspéldányok maximális számát.A lét szükségessége vagy a távollét lehetősége kapcsolat a másodlagos entitás azon példányainak minimális számának meghatározására szolgál, amelyek az eredeti példányhoz társíthatók

Küldje el jó munkáját a tudásbázis egyszerű. Használja az alábbi űrlapot

Azok a hallgatók, végzős hallgatók, fiatal tudósok, akik a tudásbázist használják tanulmányaik során és munkájuk során, nagyon hálásak lesznek Önnek.

közzétett http://www.allbest.ru/

• 1. Relációs adatmodell
• 1.1 A relációs adatmodell. Alapvető definíciók
• 1.2 A kapcsolatokkal kapcsolatos műveletek
• 2. Vállalati információs rendszerek
• Bibliográfia

1. Relációs adatmodell

1.1 A relációs adatmodell. Alapvető definíciók

A matematikai tudományágakban az "asztal" fogalma megfelel a "reláció" (reláció) fogalmának. A táblázat a valós világ egy objektumát tükrözi - egy entitást, és minden sora az entitás egy konkrét példányát tükrözi. Minden oszlopnak egyedi neve van a táblázatban. A karakterláncoknak nincs nevük, sorrendjük nincs meghatározva, és a számuk logikailag nincs korlátozva. A relációs adatmodell egyik fő előnye a homogenitás (a táblázat minden sora azonos formátumú). A felhasználó dönti el, hogy az adott entitások homogének -e. Ez megoldja a modell alkalmasságának problémáját.

Alapfogalmak:

* A kapcsolat egy kétdimenziós táblázat, amely bizonyos adatokat tartalmaz.

* Entitás - bármilyen jellegű objektum, amelynek adatait az adatbázis tárolja. Az attribútumok olyan tulajdonságok, amelyek egy entitást (oszlopokat) jellemeznek.

* A kapcsolat mértéke az oszlopok száma.

* Kapcsolati séma - az attribútumnevek listája, például MUNKAVÁLLALÓ (szám, teljes név, születési év, beosztás, osztály).

* Tartomány - egy reláció (adattípus) attribútumainak értékei.

* A tuple egy táblázat sora.

* Kardinalitás (kardinalitás) - a táblázat sorainak száma.

* Az elsődleges kulcs egy attribútum, amely egyedileg azonosítja a kapcsolat sorait. A több attribútumból álló elsődleges kulcsot összetett elsődleges kulcsnak nevezik. Az elsődleges kulcs nem lehet teljesen vagy részben üres (null). Az elsődleges kulcsként használható kulcsokat potenciális vagy alternatív kulcsoknak nevezzük.

* Az idegen kulcs az egyik tábla attribútuma (i), amely egy másik tábla elsődleges kulcsa lehet. Hivatkozik egy másik tábla elsődleges kulcsára.

A normalizálás olyan folyamat, amelynek célja az adatbázisban található információk redundanciájának csökkentése. Magán az adatokon kívül különböző nevek, objektumnevek és kifejezések is normalizálhatók az adatbázisban.

A nem normalizált adatbázis egy vagy több különböző táblázatban tartalmaz információkat; ez azt a benyomást kelti, hogy az adatok egy adott táblázatba való felvétele nem nyilvánvaló okok miatt következik be. Ez az állapot negatívan befolyásolhatja az adatbiztonságot, a lemezterület racionális használatát, a lekérdezés végrehajtásának sebességét, az adatbázis frissítésének hatékonyságát, és ami talán a legfontosabb, a tárolt információk integritását. A normalizálás előtti adatbázis olyan szerkezet, amelyet logikailag nem bontottak fel kezelhetőbb, kisebb táblákra.

A normál forma egyfajta mutatója az adatbázis normalizálásának szintjének vagy mélységének. Az adatbázis normalizálási szintje megfelel annak a normál formának, amelyben található.

1.2 A kapcsolatokkal kapcsolatos műveletek

Ahhoz, hogy a táblázatot az első normál formába (1NF) vigye, két szabályt kell követnie:

1. Atomicitás vagy oszthatatlanság. Minden oszlopnak tartalmaznia kell egy oszthatatlan értéket.

2. A táblázat nem tartalmazhat ismétlődő oszlopokat vagy adatcsoportokat.

Például, ha egy táblázat egy mezőben tartalmazza a személy teljes címét (utca, város, irányítószám), akkor nem felel meg az 1NF szabályainak, mivel különböző értékeket tartalmaz egy oszlopban, ami megsértés lenne az atomi szabályról. Vagy ha az adatbázis adatokat tartalmaz a filmekről, és tartalmazza az aktor1, színész2, színész3 oszlopokat, akkor az sem felel meg a szabályoknak, mivel az adatok megismétlődnek.

A normalizálást az adatbázis szerkezetének 1NF kompatibilitással való ellenőrzésével kell kezdeni. Minden nem oszlopos oszlopot fel kell osztani alkotó oszlopaira. Ha a táblázatban ismétlődő oszlopok vannak, akkor külön táblázatot kell kiválasztaniuk.

Ahhoz, hogy a táblázat az első normál formába kerüljön, a következőket kell tennie:

* Keresse meg az összes olyan mezőt, amely többrészes információkat tartalmaz.

* Az alkatrészekre bontható adatokat külön mezőkben kell elhelyezni.

* Helyezze át az ismétlődő adatokat egy külön táblázatba.

* Ellenőrizze, hogy minden táblázat megfelel -e az első normál űrlap feltételeinek.

Ahhoz, hogy a táblákat a második normál formába (2NF) vigye, a tábláknak már 1NF -ben kell lenniük. A normalizálást sorrendben kell elvégezni.

Most, a második normál formában, a feltételnek teljesülnie kell - minden olyan oszlopnak, amely nem kulcs (beleértve az idegeneket is), az elsődleges kulttól kell függnie. Jellemzően ezek az oszlopok, amelyek értékei függetlenek a kulttól, könnyen azonosíthatók. Ha az oszlopban található adatok nem kapcsolódnak a sort leíró kulcshoz, akkor azokat külön táblázatba kell szétválasztani. Az elsődleges kulcsot vissza kell adni a régi táblázatba.

Ahhoz, hogy az alapot a második normál formába hozza, a következőket kell tennie:

* Azonosítsa azokat az oszlopokat, amelyek nem függenek közvetlenül a táblázat elsődleges kulcsától.

* Hozza létre a szükséges mezőket a felhasználói és fórumtáblákban, válasszon a meglévő mezők közül, vagy hozzon létre elsődleges kulcsokat újakból.

* Minden táblához saját elsődleges kulcsra van szükség

* Hozzon létre idegen kulcsokat, és jelölje ki kapcsolataikat a táblázatok között. A 2NF -re történő normalizálás utolsó lépése az idegen kulcsok kiosztása lesz a kapcsolódó táblákkal való kommunikációhoz. Az egyik tábla elsődleges kulcsának idegen kulcsnak kell lennie a másikban.

Tippek:

A séma 2NF -re való átalakításának másik módja a táblázatok közötti kapcsolatok vizsgálata. Ideális esetben hozzon létre minden egy-sok kapcsolatot. A sok-sok kapcsolat átszervezést igényel.

Egy megfelelően normalizált táblázat soha nem tartalmaz duplikált sorokat (két vagy több sor, amelyek értékei nem kulcsok és ugyanazokat az adatokat tartalmazzák).

Az adatbázis harmadik normál formában lesz, ha második normál formává alakítják át, és minden nem kulcsos oszlop független egymástól. Ha eddig megfelelően követi a normalizálási folyamatot, előfordulhat, hogy nem lesz kérdés a 3NF -re való konvertálásról. Tudnia kell, hogy a 3NF megsérti, ha az egyik oszlopban lévő érték megváltoztatása a másik oszlopban történő módosítást igényli.

Ahhoz, hogy az alapot a harmadik normál formába hozza, szüksége van:

* Határozza meg, hogy mely táblák mely mezői kölcsönösen függenek egymástól, azaz mezők, amelyek jobban függenek egymástól, mint a sor egészétől.

* Hozzon létre megfelelő táblázatokat. Ha az 1. lépésben problémás oszlop található, hozzon létre hozzá osztott táblákat.

* Elsődleges kulcsok létrehozása vagy kiosztása. Minden táblázatnak tartalmaznia kell egy elsődleges kulcsot.

* Hozza létre a szükséges idegen kulcsokat, amelyek a kapcsolatok bármelyikét képezik.

A negyedik normál formában további szabály, hogy ki kell zárni a többértékű függőségeket. Más szóval, a táblázat minden sorának függetlennek kell lennie egymástól. Néhány X sor jelenléte nem jelenti azt, hogy az Y sor is szerepel valahol ebben a táblázatban.

2. Vállalati információs rendszerek

relációs modell adatrendszer

A rendszer (a görög systema -ból - egy egész, részekből álló vegyület) olyan elemek gyűjteménye, amelyek kölcsönhatásba lépnek egymással, bizonyos integritást, egységet alkotva. Íme néhány fogalom, amelyet gyakran használnak egy rendszer jellemzésére.

1. Rendszerelem - a rendszer azon része, amelynek meghatározott funkcionális célja van. A rendszerek összetett elemeit, amelyek egyszerűbb, összekapcsolt elemekből állnak, gyakran alrendszereknek nevezik.

2. A rendszer szervezése - a belső rendezettség, a rendszerelemek kölcsönhatásának következetessége, amely különösen abban nyilvánul meg, hogy korlátozza az elemek állapotának változatosságát a rendszeren belül.

3. A rendszer felépítése - a rendszer elemeinek összetétele, rendje és kölcsönhatásának elvei, amelyek meghatározzák a rendszer alapvető tulajdonságait. Ha a rendszer egyes elemei különböző szinteken helyezkednek el, és az elemek közötti belső kapcsolatok csak a magasabb és az alacsonyabb szintek között szerveződnek, és fordítva, akkor a rendszer hierarchikus felépítéséről beszélünk. A tisztán hierarchikus struktúrák gyakorlatilag ritkák, ezért némileg kibővítve ezt a fogalmat, a hierarchikus struktúrát általában olyan struktúráknak kell tekinteni, ahol más kapcsolatok mellett a hierarchikus kapcsolatok elsődleges fontosságúak.

4. Rendszer architektúra - a felhasználó számára elengedhetetlen rendszertulajdonságok halmaza.

5. A rendszer integritása - a rendszer tulajdonságainak alapvető redukálhatatlansága az egyes elemek tulajdonságainak összegével (tulajdonságok megjelenése), és ugyanakkor az egyes elemek tulajdonságainak helyétől és függőségétől való függése funkció a rendszeren belül.

Az információs rendszer az eszközök, módszerek és személyzet egymással összekapcsolt halmaza, amelyet az információk tárolására, feldolgozására és kiadására használnak a kitűzött cél elérése érdekében. "

Az "Információról, informatizálásról és információvédelemről" szövetségi törvény a következő meghatározást tartalmazza:

"Az információs rendszer szervezetileg elrendelt dokumentumok (dokumentumtömbök) és információs technológiák összessége, beleértve az információs folyamatokat megvalósító számítógépes technológia és kommunikáció használatát"

Skálaosztályozás

Nagyságrendileg az információs rendszereket a következő csoportokra osztják:

* egyedülálló;

* csoport;

* vállalati.

A vállalati információs rendszer egy skálázható rendszer, amelyet a nagy- és középvállalkozások mindenféle gazdasági tevékenységének integrált automatizálására terveztek, beleértve az egységes irányítást igénylő vállalatok csoportjából álló vállalatokat is.

A vállalati információs rendszer tekinthető olyan rendszernek, amely a vállalkozás divízióinak több mint 80% -át automatizálja.

A közelmúltban számos, az információs technológiák gazdasági objektumok kezelésében való felhasználásával foglalkozó kiadványban gyakran használják a "vállalati információs rendszerek" kifejezést, amely bennük a gazdasági objektumok tényleges automatizált információs rendszereire vonatkozik.

Az automatizált információs rendszer (AIS) a különböző típusú támogatások, valamint a számviteli és elemzési információk feldolgozásának automatizálására szolgáló szakemberek kombinációja. A támogatástípusok általában összetételükben homogének a különböző rendszerekre, ami lehetővé teszi a rendszerek kompatibilitásának elvének megvalósítását működésük során. Az AIS komplex rendszerként történő tanulmányozása során ki kell emelni az egyes részeket és elemeket, és figyelembe kell venni azok használatának jellemzőit a létrehozás és a működés szakaszában.

A vállalati információs rendszerek a munkacsoportok rendszereinek evolúciója, nagyvállalatokra összpontosítanak, és támogathatják a földrajzilag szétszórt csomópontokat vagy hálózatokat. Alapvetően többszintű hierarchikus struktúrával rendelkeznek. Az ilyen rendszereket kliens-szerver architektúra jellemzi, kiszolgálók specializálódásával vagy többszintű architektúrával. Az ilyen rendszerek fejlesztésekor ugyanazok az adatbázis -kiszolgálók használhatók, mint a csoportos információs rendszerek fejlesztésekor. A nagy információs rendszerekben azonban a leggyakoribb kiszolgálók az Oracle, a DB2 és a Microsoft SQL Server.

A csoportos és vállalati rendszerek esetében jelentősen megnövelik a működés megbízhatóságára és az adatbiztonságra vonatkozó követelményeket. Ezeket a tulajdonságokat az adatbázis -kiszolgálók adat-, referencia- és tranzakciós integritás -támogatása támogatja.

Hatály szerinti osztályozás

Alkalmazási körük szerint az információs rendszereket általában négy csoportra osztják:

* tranzakciófeldolgozó rendszerek;

* döntéshozatali rendszerek;

* információs és referenciarendszerek;

* irodai információs rendszerek.

Bibliográfia

1. Agalcov, V.P. Adatbázis. 2 kötetben V. 2. Elosztott és távoli adatbázisok: Tankönyv / V.P. Agalcov. - M.: ID FÓRUM, NITS INFRA-M, 2013.

2. Golitsyna, O. L. Adatbázisok: Tankönyv / O.L. Golitsyna, N.V. Maksimov, I. I. Popov. - M.: Fórum, 2012.

3. Karpova, I.P. Adatbázisok: Tankönyv / I.P. Karpov. - SPb.: Péter, 2013.

4. Kirillov, V.V. Bevezetés a relációs adatbázisokba Bevezetés a relációs adatbázisokba. Kirillov, G.Yu. Gromov. - SPb.: BHV-Petersburg, 2012.

5. Pirogov, V.Yu. Információs rendszerek és adatbázisok: szervezés és kialakítás: Tankönyv / V.Yu. Pirogov. - SPb.: BHV-Petersburg, 2009.

6. G.N. Fedorov. Információs rendszerek. - M.: Akadémia, 2013.

7. A.E. Satunina, L.A. Sysoeva. A vállalkozás vállalati információs rendszerének projektmenedzsmentje. - M.: Pénzügy és statisztika, Infra-M, 2009.

Közzétéve: Allbest.ru

...

Hasonló dokumentumok

Az adatmodellek típusainak lényege és jellemzői: hierarchikus, hálózati és relációs. A relációs adatmodell alapfogalmai. Attribútumok, adatbázis -kapcsolati séma. Adatintegritási feltételek. A táblázatok közötti kapcsolatok. Az adatmodell általános megértése.

kurzus hozzáadva 2011.01.29


Vállalati információs rendszerek és adatbázisok, azok használata az üzleti tevékenység javítására és hibakeresésére. A vállalati információs rendszerek osztályozása. OLTP osztályú információs rendszerek. Gyors analitikai feldolgozás.

szakdolgozat, hozzáadva 2011.01.19


Adatbázisok kétdimenziós fájlokkal és relációs adatbázis-kezelő rendszerekkel (DBMS). Adatbázis létrehozása és lekérdezések feldolgozása DBMS segítségével. Az adatbázisok fő típusai. A relációs adatbázisok alapfogalmai. A kapcsolatok alapvető tulajdonságai.

kivonat, hozzáadva 2010.12.20


Adatbázis rendszer fogalma. A relációs modell és jellemzői. Integritás a relációs modellben. Relációs algebra. Adatbázis tervezési problémák. A kapcsolatok normális formái. Adatbázis tervezése az entitás-kapcsolat módszerrel. ER diagramok. SQL nyelv.

előadás tanfolyam, hozzáadva 2008.03.10


Az adatbázisban tárolt adatok meghatározott logikai felépítése. Alapvető adatmodellek. A relációs adatmodell elemei. Példa idegen kulcsok használatára. A relációs adatmodell kapcsolatának alapvető követelményei.

előadás hozzáadva: 2013.10.14


Adatbázisok és használatuk a számítástechnikában. A hálózati adatmodell jellemzői és alapvető konstruktív egysége. Hierarchikus modell, a tárgyterület objektumai. Relációs modell, annak láthatósága, adatok táblázatos megjelenítése.

absztrakt, hozzáadva 2011.12.19


A Microsoft Access adatbázis -kezelő rendszer típusai és funkciói. Hierarchikus, hálózati, relációs modell adatbázisok leírására. Egy adatbázis tábla alapfogalmai. Az adatbázis -objektumok, alapvető űrlapok létrehozásának jellemzői. Hozzáférés az Internethez az Access szolgáltatásban.

teszt, hozzáadva 2011.08.01


Modern adatbázis -kezelő rendszerek (DBMS). A hierarchikus adatmodell elemzése. Relációs adatmodell. A reláció utáni adatmodell, mint kiterjesztett relációs modell, amely megszünteti a táblarekordokban tárolt adatok oszthatatlanságának korlátozását.

tudományos munka, hozzáadva 2010.08.06


Adatmodellek az adatbázis -kezelésben. Fogalmi adatmodellek. Az adatbázisok szerepe az információs rendszerekben. Relációs adatmodell. A tárgykör meghatározása. Adatbázis modell építése a "Háziállatok" információs rendszerhez.

szakdolgozat, hozzáadva 2011.04.19


Az Access információs modellje, mint egy valós objektum vagy rendszer egyszerűsített helyettesítője. Az adatszervezést és a köztük lévő kapcsolatokat meghatározó alapvető struktúrák; az adatszervezés relációs típusa. Példa egy adózási adatbázisra.

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 letöltésre kész komplex fizikai adatmodellek és az üzleti tevékenységi területekre vonatkozó üzleti elemzési jelentések lehetővé teszik a vállalat információs összetevőjének egységesítését, és jelentősen felgyorsítják az üzleti folyamatok végrehajtását. A megoldási sablonok 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 projekt átfutási idejé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ányspecifikus, integrált és logikailag strukturált nézet az összes olyan információról, amelynek a vállalati adattárházban kell lennie, hogy válaszoljon mind a stratégiai, mind a taktikai üzleti kérdésekre. A modellek fő célja az adattérben való tájékozódás megkönnyítése és az üzleti fejlődés szempontjából fontos részletek kiemelése. Modern körülmények között, egy sikeres vállalkozáshoz feltétlenül szükséges, hogy világosan megértsük a különböző összetevők közötti összefüggéseket, és jó elképzelésünk legyen a szervezet összképéről. Az összes részlet és kapcsolat modellek segítségével történő azonosítása lehetővé teszi a vállalat munkájának megszervezéséhez szükséges idő és eszközök leghatékonyabb felhasználását.

Az adatmodellek absztrakt modellek, amelyek leírják az adatok megjelenítését és elérését. Az adatmodellek egy adott területen határozzák meg az adatelemeket és a köztük lévő kapcsolatokat. Az adatmodell olyan navigációs eszköz az üzleti és informatikai szakemberek számára, amely egy meghatározott szimbólum- és szóhalmazt használ, hogy pontosan megmagyarázza a valós információk egy adott osztályát. Ez lehetővé teszi a szervezeten belüli jobb kommunikációt, és ezáltal rugalmasabb és stabilabb alkalmazási környezetet teremt.

Példa a „GIS a kormányzat és az önkormányzat számára” modellre.

Ma stratégiailag fontos, hogy a szoftver- és szolgáltatók gyorsan tudnak reagálni a technológiai újításokkal, az állami korlátozások megszüntetésével és az ellátási láncok összetettségével kapcsolatos iparági változásokra. Az üzleti modell változásaival együtt növekszik a vállalat működésé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 a rájuk vonatkozó funkcionális és üzleti követelmények folyamatosan változnak.

Az iparági adatmodellek célja, hogy megkönnyítsék és optimalizálják ezt a folyamatot, az informatikai megközelítés modern szintre történő átvitelében.

Ipari adatmodellek a cégtőlEsri

Az Esri ArcGIS adatmodellek munkasablonok a térinformatikai projektekben való felhasználáshoz és a különböző alkalmazási területek adatszerkezeteinek létrehozásához. Az adatmodell -építés magában foglalja a koncepcionális terv, a logikai és a fizikai struktúra létrehozását, amely felhasználható személyes vagy vállalati geoadatbázis felépítéséhez. Az ArcGIS eszközöket kínál az adatbázis -séma létrehozásához és kezeléséhez, az adatmodell -sablonokat pedig arra használják, hogy gyorsan elindítsanak egy térinformatikai projektet számos alkalmazásban és iparágban. Az Esri jelentős időt töltött a felhasználói közösséggel, hogy kifejlesszen egy sor sablont, amelyek gyorsan elindíthatják a vállalati geoadatbázis tervezését. Ezeket a projekteket a support.esri.com/datamodels címen írják le és dokumentálják. Az alábbiakban, ezen a webhelyen való megjelenésük sorrendjében az Esri ipari modelljeinek szemantikai fordítása található:

• Címnyilvántartás
• Mezőgazdaság
• Meteorológia
• Alapvető térbeli adatok
• Biológiai sokféleség
• Az épületek belső tere
• Üvegházhatású gázok elszámolása
• Az adminisztratív határok fenntartása
• Katonai létesítmény. Hírszerző szolgálat
• Energia (beleértve az új ArcGIS MultiSpeak protokollt)
• Ökológiai szerkezetek
• Vészhelyzetek Minisztériuma. Tűzoltóság
• Erdei kataszter
• Erdészet
• Geológia
• Nemzeti szintű GIS (e-gov)
• Talajvíz és szennyvíz
• Egészségügyi ellátás
• Régészet és emlékhelyek megőrzése
• nemzetbiztonság
• Hidrológia
• Nemzetközi Vízrajzi Szervezet (IHO). S-57 formátum ENC-hez
• Öntözés
• Földhivatal
• Önkormányzat
• Tengeri navigáció
• Állami kataszter
• Olaj- és gázszerkezetek
• Csővezetékek
• Raszteres tárolás
• Bathimetria, tengerfenék -dombormű
• Távközlés
• Szállítás
• Vízellátás, csatornázás, lakás és kommunális szolgáltatások

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;
• ipari szakértők részvételével jött létre;
• a különböző termékek és technológiák közötti információ interakció biztosítására tervezték;
• ne mondjon ellent más szabványoknak és előírásoknak;
• befejezett projektekben használják szerte a világon;
• úgy vannak kialakítva, hogy az információkkal dolgozzanak a létrehozott rendszer teljes életciklusa során, és ne maga a projekt;
• bővíthető az ügyfél igényei szerint anélkül, hogy elveszítené a kompatibilitást más projektekkel és / vagy modellekkel;
• további anyagok és példák kíséretében;
• különféle ipari vállalatok útmutatásaiban és műszaki anyagaiban használják;
• a résztvevők nagy közössége, míg a közösséghez való hozzáférés mindenki számára nyitott;
• az utóbbi években publikációkban nagyszámú hivatkozás adatmodellekre.

Az Esri egy független testületek szakértői csoportjának tagja, amely különféle ipari modelleket ajánl, például PODS (Pipeline Open Data Standards - nyílt szabvány az olaj- és gázipar számára; a PODS jelenleg Esri PODS Esri Spatial 5.1.1 geoadatbázisként valósul meg. ) vagy az ArcGIS for Aviation geodatabá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 megfelelnek a meglévő ipari szabványoknak, mint például az S-57 és az ArcGIS for Maritime (tengeri és tengerparti jellemzők), valamint olyan modellek, amelyek az Esri Professional Services által végzett munkából készültek, és de facto szabványok. a megfelelő területet. Például a GIS for Nation and Local Government befolyásolta az NSDI és az INSPIRE szabványokat, a Hydro and Groundwater (hidrológia és talajvíz) pedig nagymértékben használatos a szabadon elérhető professzionális ArcHydro csomagban és kereskedelmi termékekben. Meg kell jegyezni, hogy az Esri támogatja az olyan de-facto szabványokat is, mint az NHDI. Minden javasolt adatmodell dokumentálva van, és használatra kész a vállalati IT -folyamatokban. A modellekhez tartozó anyagok a következők:

• Entitások kapcsolatainak UML diagramjai;
• adatstruktúrák, tartományok, könyvtárak;
• kész geodatabase sablonok ArcGIS GDB formátumban;
• mintaadatok és mintaalkalmazások;
• példák adatbetöltő szkriptekre, példák elemző segédprogramokra;
• referenciakönyvek a javasolt adatstruktúráról.

Az Esri könyvek formájában foglalja össze az építőipari modellekben szerzett tapasztalatait, és lokalizálja a megjelent anyagokat. A következő könyveket honosította meg és tette közzé az Esri CIS:

• Geospatial Service Oriented Architecture (SOA);
• Geodatabázisok tervezése szállításhoz;
• Vállalati földrajzi információs rendszerek;
• GIS: új energia az elektromos és gázipari vállalkozások számára;
• Olaj és gáz digitális térképen;
• Világunk modellezése. Esri Geodatabase Design Guide;
• A GIS -re gondolva. GIS tervezés: Kézikönyv a vezetők számára;
• Földrajzi információs rendszerek. Alapok;
• GIS adminisztratív és gazdasági irányításhoz;
• Web GIS. Elvek és alkalmazások;
• Rendszertervezési stratégiák, 26. kiadás;
• Az ArcReview magazin 68 száma a vállalatok és a térinformatikai rendszerek felhasználóinak kiadványaival;
• ... és sok más tematikus jegyzet és kiadvány.

Például a könyv " Világunk modellezése ..."A (fordítás) átfogó útmutató és referencia a térinformatikai adatmodellezéshez általában, és különösen a geoadatbázis adatmodellhez. A könyv bemutatja, hogyan lehet megfelelő adatmodellezési döntéseket hozni, olyan döntéseket hozni, amelyek a térinformatikai projekt minden vonatkozásában részt vesznek, az adatbázis -tervezéstől az adatokon és adatgyűjtésen át a térbeli elemzésig és megjelenítésig hálózatokat, integrálja a műholdképeket a földrajzi elemzés és megjelenítés folyamatába, és készítsen 3D -s modelleket a térinformatikai adatokból. Könyv " Geodatabázisok tervezése szállításhoz"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: Új energia az elektromos és gázipari vállalkozások számára"Valós példák segítségével bemutatja, hogy a vállalati térinformatika milyen előnyökkel járhat az energiaszolgáltató számára, beleértve az olyan szempontokat, mint az ügyfélszolgálat, a hálózati műveletek és más üzleti folyamatok.

Néhány könyv, lefordítva és eredetileg, oroszul, az Esri CIS és a DATA +kiadásában. Foglalkoznak mind a térinformatikai technológiával kapcsolatos fogalmi kérdésekkel, mind pedig a GIS modellezésének és bevezetésének számos alkalmazott vonatkozásával, különböző méretű és célú.

Az ipari modellek alkalmazását a BISDM (Building Interior Space Data Model, az épület belső térének információs modellje) 3.0 példájával fogjuk megvizsgálni. A BISDM egy általánosabb BIM (Building Information Model) modell kifejlesztése, és épületek és építmények tervezésében, építésében, üzemeltetésében és leszerelésében való használatra készült. A GIS szoftverben használatos, lehetővé teszi a geoadatok hatékony cseréjét más platformokkal és interakciót velük. Az FM feladatok általános csoportjára utal (a szervezet infrastruktúrájának kezelése). Soroljuk fel a BISDM modell fő előnyeit, amelyek használata lehetővé teszi:

• szervezze meg az információcserét heterogén környezetben, egységes szabályok szerint;
• a BIM koncepció és az építési projektmenedzsment ajánlott szabályainak "fizikai" megvalósítása;
• a GIS segítségével egyetlen tárolót fenntartani az épület teljes életciklusa során (a tervezéstől a leszerelésig);
• koordinálja a projektben dolgozó 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 az építés költségeiről és időzítéséről (4D és 5D adatok);
• figyelemmel kíséri a projekt előrehaladását;
• biztosítja az épület magas színvonalú működését, beleértve a karbantartást és a javítást;
• részévé válik a vagyonkezelési rendszernek, beleértve a helyhasználat hatékonyságának elemzését (lízing, raktár, munkavállalói menedzsment);
• kiszámítja és kezeli az épület energiahatékonysági céljait;
• szimulálja az emberi áramlások mozgását.

A BISDM meghatározza a térbeli adatokkal való munkavégzés szabályait az épület belső helyiségeinek szintjén, ideértve a rendeltetést és felhasználást, a lefektetett kommunikációt, a telepített berendezéseket, a javítások és karbantartások elszámolását, a naplózási eseményeket és a vállalati egyéb eszközökkel való kapcsolatokat. 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 a geodatabázis (geodatabase) szintű modellezésére az összes fizikai elem térbeli és logikai kapcsolatairól, amelyek mind az épületet, mind annak belső helyiségeit alkotják. A BISDM elveinek követése jelentősen leegyszerűsíti a más rendszerekkel való integráció feladatait. Az első szakasz általában a CAD integráció. Ezután az épület üzemeltetése során adatcserét alkalmaznak ERP és EAM rendszerekkel (SAP, TRIRIGA, Maximo stb.).

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

A BISDM használata esetén a létesítmény vevője / tulajdonosa teljes körű információcserét kap az objektum létrehozásának ötletétől a teljes projekt kifejlesztéséig, az építés irányításáig és a fogadásig a dátummal kapcsolatos információk a létesítmény üzembe helyezésének időpontjáig, a paraméterek ellenőrzése az üzemeltetés során, sőt a létesítmény rekonstrukciója vagy leszerelése során. A BISDM paradigmát követve a térinformatika és a segítségével létrehozott geo-adatbázis a kapcsolódó rendszerek közös adattárává válik. A GDB gyakran harmadik fél rendszerei által létrehozott és üzemeltetett adatokat tartalmaz. Ezt figyelembe kell venni a létrehozott rendszer architektúrájának tervezésekor.

Egy bizonyos szakaszban az információ halmozott "kritikus tömege" lehetővé teszi, hogy új minőségi szintre lépjen. Például egy új épület tervezési szakaszának befejezése után lehetőség nyílik a 3D felmérési modellek automatikus megjelenítésére a GIS -ben, a telepített berendezések listájának összeállításához, a lefektetendő közművek kilométer -számításának kiszámításához, számos ellenőrzés elvégzéséhez és akár a projekt költségének előzetes pénzügyi becslése.

Ismételten megjegyezzük, hogy a BISDM és az ArcGIS együttes használatakor lehetővé válik a 3D modellek automatikus felépítése a felhalmozott adatokból, mivel a geoadatbázis tartalmazza az objektum teljes leírását, beleértve a z-koordinátákat, a talajtagságot, az elemkapcsolatok típusait. , felszerelés módszerei, anyag, rendelkezésre álló utak a személyzet mozgása, az egyes elemek funkcionális célja stb. stb. Meg kell jegyezni, hogy az összes tervezési anyag kezdeti importálása után a BISDM GDB -be további információra van szükség:

• tárgyak és berendezések 3D modelljeinek elhelyezése a kijelölt helyeken;
• információk gyűjtése az anyagok költségeiről, valamint azok lerakásának és telepítésének eljárásáról;
• a permeabilitás szabályozása a beépített nem szabványos berendezés méretei szerint.

Az ArcGIS használata miatt egyszerűbb további 3D objektumok és hivatkozások importálása külső forrásokból, 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 iparban használt összes formátum támogatott, beleértve az IFC, az AutoCAD Revit, a Bentlye Microstation szolgáltatásokat.

Ipari adatmodellek az IBM -től

Az IBM tárhelykezelési eszközöket és modelleket kínál számos üzleti terület számára:

• IBM Banking and Financial Markets Data Warehouse (pénzügy)
• IBM banki adattárház
• IBM banki folyamat- és szolgáltatási modellek
• IBM Health Plan Data Model (egészségügy)
• IBM biztosítási információraktár (biztosítás)
• IBM biztosítási folyamat és szolgáltatási modellek
• IBM Retail Data Warehouse (kiskereskedelem)
• IBM Telecommunications Data Warehouse (távközlés)
• InfoSphere Warehouse Pack:
  - a Customer Insight számára (az ügyfelek megértéséhez)
  - Piaci és Kampány Insight (a vállalat és a piac megértéséhez)
  - Supply Chain Insight (a beszállítók megértéséhez).

Például a modell IBMBanki tevékenységésPénzügyiPiacokAdatRaktár célja a bankszektor sajátos problémáinak kezelése az adatok tekintetében, és IBMBanki tevékenységFolyamatésSzolgáltatásModellek- a folyamatok és a SOA (Service Oriented Architecture) szempontjából. A távközlési ipar számára modelleket mutatnak be IBMInformációKeretrendszer (IFW)és IBMTávközlésAdatRaktár (TDW)... Segítenek jelentősen felgyorsítani az elemzési rendszerek létrehozásának folyamatát, valamint csökkentik az üzleti intelligencia alkalmazások fejlesztésével, a vállalati adatkezeléssel és az adattárházak szervezésével kapcsolatos kockázatokat, figyelembe véve a távközlési ipar sajátosságait. Az IBM TDW képességei a távközlési piac teljes spektrumát lefedik - az internetszolgáltatóktól és a vezetékes és vezeték nélküli telefonszolgáltatásokat, adatátvitelt és multimédiás tartalmakat kínáló kábelhálózat -üzemeltetőktől a telefon-, műholdas, távolsági és nemzetközi kommunikációs szolgáltatásokat nyújtó multinacionális vállalatokig. valamint a szervezetek globális hálózatai. 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.

Egy eszköz, az úgynevezett InfoSphere Warehouse Pack for Customer Insight strukturált és könnyen telepíthető üzleti tartalmat biztosít egyre több üzleti projekthez és iparághoz, beleértve a banki, biztosítási, pénzügyi, egészségbiztosítási, távközlési, kiskereskedelmi és forgalmazási szolgáltatásokat. Üzleti felhasználóknak InfoSphere Warehouse Pack a piacon és a kampányban elősegíti a piacelemzési tevékenységek és a marketingkampányok hatékonyságának maximalizálását az üzlet sajátosságainak fejlesztése és figyelembe vétele révén. Használva InfoSphere Warehouse Pack for Supply Chains Insight a szervezetek képesek az ellátási lánc működésével kapcsolatos aktuális információk fogadására.

Esri pozíciója az IBM megoldás -architektúrán belül.

Különösen figyelemre méltó a segédprogramok és segédprogramok IBM megközelítése. A fogyasztók növekvő igényeinek kielégítésére a közműveknek rugalmasabb architektúrára van szükségük, mint a ma használatosaknak, valamint iparági szabványos objektummodellre van szükségük az információ szabad áramlásának megkönnyítésére. Ez növelni fogja a közművek kommunikációs képességeit, lehetővé teszi a költséghatékonyabb interoperabilitást, és jobb láthatóságot biztosít az új rendszerek számára az összes szükséges erőforráshoz, függetlenül attól, hogy hol találhatók a szervezeten belül. Ennek a megközelítésnek az alapja a SOA (Service Oriented Architecture), egy összetevőmodell, amely feltérképezi a különböző alkalmazások részlegeinek és szolgáltatásainak funkcióit, amelyek újra felhasználhatók. Az ilyen komponensek "szolgáltatásai" merev kötés nélkül cserélnek adatokat interfészeken keresztül, elrejtve a felhasználó elől a mögöttük lévő rendszerek összes komplexitását. Ebben a módban a vállalatok könnyen hozzáadhatnak új alkalmazásokat, függetlenül a szoftver gyártójától, operációs rendszerétől, programozási nyelvétől vagy a szoftver egyéb jellemzőitől. A SOA alapján a koncepció megvalósul BIZTONSÁGOS ( Solution Architecture for Energy), lehetővé teszi a közműcég számára, hogy szabványokon alapuló, holisztikus képet kapjon infrastruktúrájáról.

Esri ArcGIS® egy globálisan elismert szoftverplatform a földrajzi információs rendszerekhez (GIS), amely villamosenergia-, gázátviteli, elosztó- és 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 drámai módon kiterjeszti az IBM SAFE architektúrát azáltal, hogy biztosítja az intelligens energiavállalat kezeléséhez szükséges eszközöket, alkalmazásokat, munkafolyamatokat, elemzéseket és információintegrációs képességeket. Az ArcGIS az IBM SAFE keretein belül lehetővé teszi, hogy különböző forrásokból információkat kapjon az infrastrukturális létesítményekről, eszközökről, ügyfelekről és alkalmazottakról, pontos adatokkal a tartózkodási helyükről, valamint létrehozhat, tárolhat és feldolgozhat georeferált információkat a vállalati eszközökről (támaszok, csővezetékek, vezetékek) , transzformátorok, kábelcsatornák stb.). A SAFE infrastruktúrán belüli ArcGIS dinamikusan összekapcsolja az alapvető üzleti alkalmazásokat a GIS, a SCADA és az ügyfélszolgálati rendszerek adatainak kombinálásával olyan külső információkkal, mint a forgalom intenzitása, az időjárási körülmények vagy a műholdas képek. A segédprogramok ezt a kombinált információt különféle célokra használják, az S.O.R. (az üzemeltetési környezet összképe) a helyszíni szemle, karbantartás, hálózati elemzés és tervezés során.

Egy közüzemi vállalat információs összetevői több szint segítségével modellezhetők, amelyek a legalacsonyabb fizikai szinttől a legmagasabb, legösszetettebb üzleti logikai szintig terjednek. Ezek a rétegek integrálhatók, hogy megfeleljenek az olyan tipikus ipari követelményeknek, mint az automatikus mérési naplózás és a felügyeleti ellenőrzés és adatgyűjtés (SCADA). A SAFE architektúra kiépítésével a közművek jelentős lépéseket tesznek az egész iparágra kiterjedő nyílt objektummodell népszerűsítése érdekében, a Common Information Model (CIM) for Energy and Utilities számára. Ez a modell biztosítja a szükséges keretet ahhoz, hogy sok vállalkozás a szolgáltatásorientált architektúra felé mozduljon el, mivel ösztönzi az adatok és objektumok strukturálására szolgáló nyílt szabványok használatát. Annak a ténynek köszönhetően, hogy minden rendszer ugyanazokat az objektumokat használja, az azonos objektumok különböző megvalósításaihoz kapcsolódó zűrzavar és rugalmatlanság minimálisra csökken. Így az ügyfél -objektum és más fontos üzleti objektumok meghatározása egységes lesz a tápegység minden rendszerében. Most a CIM segítségével a szolgáltatók és a szolgáltatásfogyasztók közös adatstruktúrát oszthatnak meg, ami megkönnyíti a drága üzleti összetevők kiszervezését, mivel a CIM közös bázist hoz létre az információcsere felépítésére.

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 integrálja 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 úgy találta, hogy az integráció jelentős akadályt jelent az új alkalmazások elfogadása előtt. Éppen ellenkezőleg, az adatintegráció megvalósítása kézzelfogható jövedelmet és nagyobb hatékonyságot hoz a vállalatnak.

Egy jól felépített modell egyedileg azonosítja az adatok jelentését, ami ebben az esetben strukturált adat (szemben a strukturálatlan adatokkal, mint például egy kép, bináris fájl vagy szöveg, ahol a jelentés kétértelmű is lehet). A leghatékonyabb ipari modellek azok a professzionális gyártók, mint az Esri és az IBM. Modelljeik magas hozamot érnek el a jelentős részletesség és pontosság miatt. Általában sok adatattribútumot tartalmaznak. Ezenkívül mind az Esri, mind az IBM széleskörű modellezési tapasztalattal rendelkezik, és jól ismeri az építőipar-specifikus modelleket.