Tento článok sa zaoberá architektúrou údajov. Čo sa má riadiť, keď je postavený, aké prístupy pracujú - a prečo.

"Rozprávka je lož - áno v ňom hint ..."

Dajte dedko ... Skladovanie. A klenba je veľká. Ale naozaj som nevedel, ako to bolo usporiadané. A začal svoju recenziu svojho dedka. Volal som dedko babička, vnučku, mačku a myš pre rodinnú radu. A táto téma je Polvit: "Máme úložisko. Údaje zo všetkých systémov kŕdľov, tabuľky sú zjavne neviditeľné. Používatelia hlásili svoju vlastnú cestu. Zdá sa, že je to všetko dobré - žijú áno žijú. Áno, len jeden smútok - nikto nevie, ako je usporiadaný. Disky si vyžaduje zrejme neviditeľné - nebojujte! A potom sú stále používatelia chodiť ku mne s sťažnosťami odlišného: správa zamrzne, potom sú údaje zastarané. A je to úplne problémy - prichádzame so správami pre kráľa-otec a čísla sa medzi sebou nebránia. Ani hodinu - kráľ je akceptovaný - nie zbúrať hlavy, ani ku mne. Tak som sa rozhodol zhromaždiť a konzultovať: čo budeme robiť? ".

Pozrel sa na jeho pohľad na stretnutie a pýta sa:
- Tu ste, babička viete, ako je to usporiadané naše úložisko?
- Nie, dedko, neviem. A ako môžem niečo vedieť? Vyhral tam, čo ho odvážni línia strážia! Niektorí presvedčia čo! Nechoďte. Išiel som si ich stráviť, koláče uväznení. A jedli koláče, fúzy bol vymazaný a povedal: "Prečo ste prišli, babička? Aký je sklad? Hovoríte - Aká správa, ktorú potrebujete - urobíme to! Ste hlavné koláče častejšie prinášajú! Bolí vám chutné. "
- A vy, obľúbené vnučky, viete, ako je usporiadané naše úložisko?
- Nie, dedko, neviem. Dal mi nejakým prístupom. Pripojil som sa, pozerám sa - a tam sú zrejme neviditeľné pre stoly. Av schémach sú odlišné tvrdohlavé. Rozptýlenie očí ... Najprv som sa zmätil. A potom vyzeral - niektoré z nich sú prázdne, iné sú naplnené, ale len polovica. A údaje sú podobné, zdá sa, že sa zdalo. Niet divu, že disky nebojujú, s takýmou redundanciou!
- No, ty, mačka, čo hovoríte o úložisku, naše? Je v ňom niečo dobré?
- Áno, ako nehovoriac, dedko - poviem. Snažil som sa extenzovať pilot v samostatnom Schire z pilota - malý šok. S cieľom pochopiť, čo je obchod pre náš štát prospešný - aké produkty sú dobré pre obchodníkov, tieto pocty sú vyplácané - Treasury sa dopĺňa. A ktorá - z ruky je zlá. A stal som sa z uskladnenia týchto údajov, aby som si vybral. Sú vybrané fakty. A začal sa snažiť porovnať ich proti produktom. A čo, starý otec, videl som - produkty, zdá sa, že sú rovnaké, ale pozeráte sa na dosky - inak! Dostal som ich potom česali ich scallop. Chesl-chesl - a viedli k určitej jednotnosti, pohladu oka. Ale čoskoro som bol označovaný - na druhý deň som spustil moje skripty nádherné dáta v okne obchodu na aktualizáciu - a všetko odišlo so mnou! "Ako to?" "Myslím," vnučka bude rozrušená - dnes by sme museli ukázať náš pilot ministrovi. Ako ideme - s takýmito údajmi?
- Áno, smutné príbehy, mačka, povedzte. No, ty, myš-noruska, naozaj sa snažil zistiť o úložisku? Máte dievčatko, whisky, spoločenské! Čo nám poviete?
- Áno, ako, starý otec, neskúšajte - samozrejme, som pokojná myš a väčšia výzva. Spýtal sa niekoho vnučky modelu CAT z údajov nášho štátneho úložiska na prijímanie. A mačka, samozrejme, prišla ku mne - na vás, hovorí, myš, všetka nádej! No, dobrý skutok pre dobrých ľudí (a mačky) nerobia? Išiel som na hrad, kde hlava modelu údajov úložiska v bezpečných kožach. A schováva sa. Bolo čakanie, keď zistí, že model z trezora. Iba vyšiel na kávu - skočím sa na stôl. Pozerám sa na model - nič nechápem! Ako to? Nepoznávam naše skladovanie! Máme tabuľky tisíce nenápadných, dát sú irrepressible! A tu - všetky mierne áno krásne ... Pozrel sa na tento model - a späť na bezpečné odstránenie.
- Áno, celkom podivné veci, ty, myš, povedal.
Myslel pevne dedko.
- Čo mám robiť, moji priatelia? Koniec koncov, s takýmto úložiskom nebudete dlhodobo žiť ... Užívatelia čoskoro - úplne trpezlivosť stratí.

Bez ohľadu na to, čo náš dedko rozhodne z rozprávky - vybudovať nové uskladnenie alebo sa pokúsiť o opáliť existujúce - je potrebné čerpať závery pred "Rolling rukávov" znova.
Budeme odložiť v smere organizačných aspektov - ako je nebezpečenstvo koncentrácie odborných znalostí v úzkej uzavretej skupine, nedostatok kontrolných procesov a zabezpečiť transparentnosť architektúry systému použitej v podniku atď.
Dnes by som sa chcel zamerať na budovanie špecifickej architektúry systému (alebo systémových skupín) - dátové sklady. Čo potrebujete na udržanie pozornosti v zameraní na prvé miesto, keď je organizácia postavená na vytvorenie takéhoto komplexného a pozoruhodného systému ako skladovanie.

Debrík

Nikto z nás, ktorý pracuje na tvorbe a vývoji akéhokoľvek systému, nechce to byť "čas", alebo rozhodnutie, že "ochotný" za rok alebo dva, pretože Nebude schopný splniť požiadavky a očakávania od zákazníkov a podnikania. Bez ohľadu na to, aký silný je valca v smere "flexibilných metodík", teraz je človek oveľa príjemnejší cítiť "Majster", ktorý robí husle ako remeselník, ktorý plaschers palice pre jednorazové bubny.
Náš zámer znie prirodzené: robiť systémy, dobrá kvalita a vysokokvalitná, ktorá nebude vyžadovať pravidelné "Nightwort so súborom", pre ktoré nebudeme ohaniť pred koncovými užívateľmi a ktorý nebude vyzerať ako "čierna skrinka" všetky "neinifikované" nasledovníci.

Ak chcete začať, urobíme zoznam typických problémov, ktoré pravidelne čelíme, pracujeme s uskladnením. Len zapíšem, čo je - zatiaľ čo bez pokusu o zefektívnenie a formalizáciu.

1. V zásade máme dobré skladovanie: ak sa nedotýkate, potom všetko funguje. TRUE, hneď ako chcete urobiť zmenu - "Miestne collaps" začína.
2. Údaje sa dajú stiahnuť denne, podľa predpisov v rámci veľkého procesu, do 8 hodín. A to nám vyhovuje. Ale ak náhle zlyhá - vyžaduje manuálnu intervenciu. A potom všetko môže pracovať nepredvídateľne dlhé, pretože V procese sa bude vyžadovať účasť osoby.
3. Realizované uvoľnenie - čakať na problémy.
4. Niektorí jeden zdroj nemohol zaplatiť údaje včas - všetky procesy čakajú.
5. Integrita údajov kontroluje databázu - preto naše procesy spadajú s chybou, keď je zlomený.
6. V jednej všeobecnej schéme máme veľmi veľké stoly na skladovanie - 2000. A 3000 viac v mnohých iných systémoch. Už sme si mysleli, ako sú usporiadaní a aký dôvod sa objavil. Preto je pre nás ťažké znovu použiť. A mnohé úlohy sa musia znova rozhodnúť. Vzhľadom k tomu, že je ľahšie a rýchlejšie (ako sa vysporiadať s "v kóde niekoho iného"). V dôsledku toho máme nezrovnalosti a duplicitné funkcie.
7. Očakávame, že zdroj dáta dáta. Ukazuje sa však, že to nie je. V dôsledku toho trávime veľa času na zosúladenie vašich záverečných správ. A veľmi sa im to podarilo. Máme dokonca dobre zavedený proces. Je pravda, že si vyžaduje čas. Ale používatelia sa používajú na ...
8. Užívateľ nie vždy dôveruje našim správam a vyžaduje odôvodnenie jedného alebo iného čísla. V niektorých prípadoch má pravdu, ale v niektorých nie. Ale sme veľmi ťažké ich ospravedlniť, pretože Nemáme prostriedky "prostredníctvom analýzy" (alebo dátovej línie).
9. Mohli by sme prilákať ďalších vývojárov. Máme však problém - ako ich zahrnieme do práce? Ako najúčinnejšie spolupracovať?
10. Ako postupne rozvíjať systém, bez toho, aby som sa dostal do vývoja "systémového jadra" za celý rok?
11. Dátový sklad je spojený s firemným modelom. Ale presne vieme (videl XYZ v banke), že model môže byť postavený nekonečne dlhý čas (v banke XYZ, šesť mesiacov išlo a diskutovalo podnikateľské subjekty bez akéhokoľvek pohybu). A prečo je vôbec? Alebo možno, lepšie bez neho, ak toľko problémov s ním? Možno to môže nejakým spôsobom generovať?
12. Rozhodli sme sa udržať model. Ale ako systémovo vyvinúť model údajov? Potrebujeme "pravidlá hry" a čo môžu byť? Čo nám to dá? A čo keď sa budeme s modelom mýlime?
13. Mali by sme udržať údaje, alebo históriu ich zmien, ak "podnikania nie je potrebné"? Nechcel by som "skladovať odpad" a komplikovať používanie týchto údajov pre skutočné úlohy. Mali by sa skladovať príbeh? Čo sa stane? Ako sa s časom pracuje?
14. Musím sa pokúsiť zjednotiť údaje na ukladanie, ak máme systém riadenia NSI? Ak je MDM, to znamená, že teraz je celý problém s master dát vyriešených?
15. Čoskoro budeme nahradení kľúčovými účtovnými systémami. Ak by bol dátový sklad pripravený na zmenu zdroja? Ako to dosiahnuť?
16. Potrebujeme metadátu? Čo to porozumieme? Kde presne môžu byť použité? Ako môžem implementovať? Potrebujete ich uložiť "na jednom mieste"?
17. Naši zákazníci sú veľmi stabilné v ich požiadavkách a túžbach - neustále sa menia. Máme vo všeobecnosti veľmi dynamické podnikanie. Aj keď niečo robíme - toto sa už stáva zbytočným. Ako to robíme, aby sme čo najrýchlejšie vydali výsledok - ako horúce koláče?
18. Používatelia vyžadujú efektívnosť. Ale často nemôžeme spustiť naše základné zavádzacie procesy, pretože Vloží zdroj zdrojov (zle ovplyvňuje výkonnosť) - preto zavesíme ďalšie dátové toky - čo bude vyzdvihnúť bod - čo potrebujeme. TRUE, UZNAČUJE MOŽNOSTI. A potom vyhodíme časť údajov. Okrem toho bude problém konvergencie. Ale v žiadnom prípade ...

To sa už veľa ukázalo. Ale toto nie je kompletný zoznam - je ľahké pridať a rozvíjať. Nebudeme ho skrývať na stole a zavesiť na prominentné miesto - držanie týchto otázok v oblasti pozornosti v procese práce.
Našou úlohou je vyvinúť komplexné riešenie ako výsledok.

Antibúrka

Pri pohľade na našom zozname môžete urobiť jeden záver. Nie je ťažké vytvoriť druh "databázy pre vykazovanie", hodiť údaje tam alebo dokonca vybudovať niektoré procesy aktualizácie regulačných údajov. Systém sa začne nejako žiť, používatelia sa objavujú, a s nimi záväzky a SLA, vzniknú nové požiadavky, sú spojené ďalšie zdroje, metodiky sa zmenia - toto všetko by sa malo brať do úvahy v procese vývoja.

Po určitom čase je obraz nasledovný:
"Tu je sklad. A to funguje, ak sa ho nedotýka. Problémy vznikajú, keď musíme niečo zmeniť. "

Zmena v nás, vplyv, ktorý nemôžeme vyhodnotiť a pochopiť (pretože na začiatku nespustili takéto nástroje do systému) - a aby sa neohrozili, nedotýkame sa, čo je, a robíme ďalšie rozšírenie na boku A ešte jeden a viac - otočenie nášho rozhodnutia slums, alebo ako sa hovorí v Latinskej Amerike, "Faverla", kde sa obávajú aj polícia.
Tam je pocit straty kontroly nad vlastným systémom, chaosom. Vyžaduje sa viac a viac rúk na podporu existujúcich procesov a riešiť problémy. A zmeny sa všetko zložitejšie. Inými slovami, systém sa stáva nestabilným stresom, non-adaptive zmenám. A okrem toho existuje silná závislosť od znakov, ktoré "poznajú farmater", pretože neexistujú žiadne "karty".

Takáto vlastnosť objektu je kolaps pod vplyvom chaosu, náhodné udalosti a otrasov - Nicholas Nicholas Talek hovory krehkosť . A tiež predstavuje opačný koncept: antibúrka – keď subjekt nezničí zo stresu a náhodnosti, ale dostáva z neho priame výhody. ("Antibrupost. Ako profitovať z chaosu")
Inak môže byť nazývaný prispôsobivosť alebo odolnosť voči zmene .

Čo to v tejto súvislosti znamená? Aké sú "zdroje chaosu" pre IT systémy? A čo to znamená "profitovať z chaosu" z hľadiska IT architektúry?
Prvá myšlienka, ktorá príde na myseľ, sú zmeny, ktoré pochádzajú von. Aký je externý svet pre systém? Najmä. Samozrejme, v prvom rade - zmeny z zdrojov údajov pre úložisko:

• zmena formátov prichádzajúcich údajov;
• výmena niektorých zdrojových systémov údajov iným;
• zmena pravidiel / platforiem integrácie systémov;
• zmena interpretácií dát (formáty sú uložené, logika práce s údajmi sa mení);
• zmena modelu údajov Ak je integrácia vykonaná na úrovni údajov (analýza protokolov súborov databázových transakcií);
• zvýšenie objemov údajov - doteraz boli dáta v zdrojovom systéme trochu, a zaťaženie bolo malé - bolo možné ich zdvihnúť tak ako tak, ľubovoľne s ťažkým dotazom, dátami a zaťažením sa zvýšili - teraz existujú prísne obmedzenia;
• atď.

Zdrojové systémy, informácie a jej štruktúra, typ integračnej interakcie, ako aj logika práce s údajmi možno zmeniť. Každý systém implementuje svoj dátový model a prístupy k práci s nimi, ktoré spĺňajú ciele a ciele systému. A ako keby zjednotil sektorové modely a referenčné postupy - všetko rovnaké, nuansy sa nevyhnutne vykazujú. (A okrem toho, proces zjednotenia priemyslu z rôznych dôvodov nie je veľmi pohybujúci.)
Podnikové práce s firemnými dátami - prítomnosť a kontrolu informačnej architektúry, jediného sémantického modelu, manažmentu master dát (MDM) mierne uľahčuje úlohu konsolidácie údajov do úložiska, ale nevylučujú jej potrebu.

Žiadne menej kritické zmeny iniciujú spotrebitelia úložiska (zmena požiadaviek):

• predtým zostaviť dátový prehľad, stačilo pripojiť ďalšie polia alebo nový zdroj údajov;
• predtým implementované techniky spracovania údajov sú zastarané - je potrebné recyklovať algoritmy a všetko, čo ovplyvňuje;
• skôr, bola splnená všetka aktuálna hodnota atribútu adresára na informačnom paneli - teraz trvá hodnotu, ktorá je v súčasnosti relevantná v čase analyzovanej skutočnosti / udalosti;
• požiadavka na hĺbku histórie skladovania, ktorá nebola predtým - na ukladanie údajov nie je 2 roky a za 10 rokov;
• predtým bolo dosť údajov ako "na konci dňa / obdobia" - teraz je potrebné status údajov "v priebehu jedného dňa", alebo v čase konkrétnej udalosti (napríklad rozhodnutie o a Žiadosť o úvere - pre Bazilej II);
• predtým sme boli spokojní s hlásením o údajoch na včerajšie (T-1) alebo neskôr, teraz potrebujeme T0;
• atď.

A integračné interakcie so zdrojovými systémami a požiadavky od spotrebiteľov skladovacích údajov - ide o externé faktory pre dátový sklad: niektoré zdrojové systémy sú nahradené inými, množstvá dát rastú, prichádzajúce formáty údajov sa menia, používateľské požiadavky sa menia , atď. A toto všetko je typické externé zmeny, na ktorých je náš systém naše skladovanie - by mal byť pripravený. S správnou architektúrou by nemali zabiť systém.

Ale to nie je všetko.
Keď už hovoríme o variabilite, najprv si zapamätame externé faktory. Koniec koncov, vo vnútri môžeme všetci kontrolovať, zdá sa to pre nás, že? Áno a nie. Áno, väčšina faktorov, že mimo zóny vplyvu sú externé. Ale je tu aj "vnútorná entropia". A je to kvôli jeho prítomnosti, niekedy sa musíme vrátiť "do bodu 0". Najprv spustite hru.
V živote máme často tendenciu začať od nuly. Prečo máme to zvláštne? A je to zlé?
Aplikované na to. Pre samotný systém - môže to byť veľmi dobré - schopnosť revidovať individuálne riešenia. Zvlášť, keď to dokážeme urobiť lokálne. Refaktoring je proces odvíjania "webu", ktorý pravidelne vzniká v procese vývoja systému. Návrat "na začiatok" môže byť užitočný. Ale má cenu.
S príslušným riadením architektúry táto cena klesá - a proces samotného systému systému sa stáva kontrolovanejší a transparentnejší. Jednoduchý príklad: Ak je pozorovaný princíp modulárnosti - môžete prepísať samostatný modul, nedotknutý na externých rozhraniach. A to nemôže byť vykonané s monolitickou štruktúrou.

Anti-librspuppiness systému je určená architektúrou, ktorá je v ňom položená. A je to táto vlastnosť, ktorá ju robí adaptívnym.
Keď hovoríme adaptívna architektúra - Myslíme na to, že systém je schopný prispôsobiť sa zmenám, a nie vôbec, že \u200b\u200bsa neustále meníme samotnú architektúru. Naopak, stabilnejšia a stabilná architektúra, menej požiadaviek, ktoré znamenajú jeho revíziu - adaptívny systém.

Okamžite vyššia cena bude mať riešenia zahŕňajúce revíziu celej celej architektúry. A za ich prijatie musíte mať veľmi dobré dôvody. Takýto dôvod môže napríklad vyžadovať požiadavku, ktorá nemôže byť realizovaná v rámci existujúcej architektúry. Potom hovoria - požiadavka, ktorá ovplyvňuje architektúru.
Takže potrebujeme poznať svoje "hraniciach Anti farmy". Architektúra nie je vyvinutá "vo vákuu" - spolieha sa na aktuálne požiadavky, očakávania. A ak je situácia zásadne sa mení - musíme pochopiť, že sme išli nad rámec limitov súčasnej architektúry - a musíme ho prehodnotiť, vyvinúť iné riešenie - a premýšľať nad prechodovými cestami.
Napríklad sme boli stanovené v úložisku, ktoré potrebujeme, budeme vždy na konci dňa, budeme robiť dáta k dátumu každý deň podľa štandardných systémových rozhraní (prostredníctvom súboru reprezentácií). Potom požiadavky na potrebu získať údaje neboli na konci dňa pochádzajú z jednotky riadenia rizík, ale v čase rozhodnutia o poskytovaní úverov. Nemusíte sa pokúsiť "ťahať nie napnuté" - stačí rozpoznať túto skutočnosť - čím skôr, tým lepšie. A začnite pracovať s prístupom, ktorý nám umožní problém vyriešiť.
Existuje veľmi tenká linka - ak berieme do úvahy iba "požiadavky v momente" a nebudeme vyzerať niekoľko krokov dopredu (a niekoľko rokov dopredu), potom zvýšime riziko, že by sme mali čeliť požiadavke, ktorá ovplyvňuje aj architektúru Neskoro - a cena našich zmien bude veľmi vysoká. Pozrite sa trochu dopredu - v hranice nášho horizontu - nikto nebol škodlivý.

Príklad systému z "Storage Fairy Tale" je príkladom veľmi jazdeckého systému postaveného na krehkých prístupoch k dizajnu. A ak sa to stane - zničenie je pomerne rýchlo, je to pre túto triedu systémov.
Prečo to môžem povedať? Téma archívov nie je nová. Prístupy a inžinierske praktiky, ktoré boli vyvinuté počas tohto času, boli zaslané na toto - zachovanie životaschopnosti systému.
Jednoduchý príklad: Jedným z najčastejších dôvodov zlyhania projektov úložného priestoru "On Vznet" je pokusom o vytvorenie úložiska cez zdroje systémov, ktoré sú vo vývoji, bez koordinácie integračných rozhraní - pokus o vyzdvihnutie údajov priamo z tabuliek. V dôsledku toho sme išli do vývoja - počas tejto doby sa zmenila zdrojová databáza - a nakladací prúd v skladovaní sú neúplné. Redo niečo neskoro. A ak neboli ohromení, robia niekoľko vrstiev stolov vo vnútri úložiska - potom všetko môže byť vyhodené a začať znova. To je len jeden príklad a jeden z jednoduchých osôb.

Kritérium krehkého a anti-farmy je jednoduché. Hlavným sudcom je čas. Ak je systém odohraný testom času, a ukazuje svoju "vitalitu" a "nešťastie" - má vlastnosť anti-librukness.
Ak pri navrhovaní systému, vezmeme do úvahy protibovbiteľnosť ako požiadavka - to bude obhajovať, aby sme mohli používať takéto prístupy k budovaniu svojej architektúry, ktorá bude systém viac adaptívny a "chaosu mimo", a "chaos vnútri ". A konečne bude systém mať dlhší život.
Nikto z nás nechce urobiť "obrys". A nemusíte oklamať, že je to nemožné iným spôsobom. Pozrite sa na niekoľko krokov vpred - to je normálne pre človeka kedykoľvek, najmä v kríze.

Čo je to dátový sklad a prečo ho postavíme

Článok určený na skladovaciu architektúru naznačuje, že čitateľ nie je si vedomý toho, čo je, ale má tiež nejaké skúsenosti s takýmito systémami. Avšak, považoval som to za potrebné urobiť - vrátiť sa do pôvodu, na začiatok cesty, pretože Je to tam, že sa nachádza vývoj "podpory".

Ako ľudia dospeli k skutočnosti, že je potrebný dátový sklad? A ako sa líšia od len "veľmi veľkej databázy"?
Dávno, keď sa jednoducho žilo vo svetle "obchodných systémov na spracovanie údajov", neexistovali žiadne oddelenie IT systémov takýmto triedam ako frontálne OLTP systémy, back-office DSS, systémy na spracovanie textu, dátové sklady atď.
Bol to čas, keď bol Michael Stongbreaker vytvorený prvé relačné DBMS INGRES.
A to bol čas, keď éra osobných počítačov striekala do počítačového priemyslu a navždy obrátil všetky myšlienky tejto komunity IT.

Potom sa dalo ľahko splniť firemné aplikácie napísané na základe databázy desktopovej triedy - ako je Clipper, DBASE a FOXPRO. A trh klient-server aplikácií a DBMS len získal hybnosť. Zdá sa, že jeden po druhom sa objavili databázové servery, ktoré pre dlhú dobu zaberajú svoj výklenok v IT priestor - Oracle, DB2 atď.
A termín "databázová aplikácia" bola distribuovaná. Čo zahŕňala takúto aplikáciu? Zjednodušené - niektoré vstupné formuláre, prostredníctvom ktorých by užívatelia mohli súčasne zadať informácie, niektoré výpočty, ktoré boli spustené "na tlačidle" alebo "na harmonograme", ako aj niektoré správy, ktoré by mohli byť vidieť na obrazovke alebo uložiť ako súbory a odoslať na tlač .
"Nič zvláštne nie je obvyklá aplikácia, len tam je databáza," preto si všimol jedného z mojich mentorov v ranom štádiu cesty zamestnania. "Je niečo zvláštne?" - Potom som si myslel.

Ak vyzeráte, potom je tu ešte funkcia. Keďže užívatelia rastú, objem prichádzajúcich informácií, ako sa zaťaženie systému zvyšuje - svojich dizajnérskych vývojárov, aby sa udržala rýchlosť na prijateľnej úrovni ísť na niektoré "triky". Prvým prvkom je separácia monolitického "obchodného systému spracovania údajov" o účtovnej aplikácii, ktorá podporuje používateľov v on-line režime, a samostatne prideľuje žiadosť o dáta spracovania dávok a podávanie správ oddelene. Každá z týchto aplikácií má svoju vlastnú databázu a je dokonca umiestnená na samostatnú inštanciu databázového servera s rôznymi nastaveniami pre inú znak na zaťaženie - OLTP a DSS. A medzi nimi čerpá dátové toky.

Je to všetko? Zdá sa, že problém je vyriešený. Čo sa stane ďalej?
A potom spoločnosti rastú, ich informačné potreby sa množia. Počet interakcií s vonkajším svetom rastie. A nakoniec nie je jedna veľká aplikácia, ktorá plne automatizuje všetky procesy, ale niekoľko rôznych, od rôznych výrobcov. Počet systémov vytvárajúcich informácie - Zdrojové systémy v spoločnosti sa zvyšuje. Skôr alebo neskôr, potreba vidieť a porovnať informácie získané z rôznych systémov. Takže spoločnosť má dátový sklad - nová trieda systémov.
Všeobecne akceptovaná definícia tejto triedy systémov znie takto.

Dátový sklad (alebo dátový sklad) - objektovo orientovaná informácia databáza špeciálne navrhnutá a navrhnutá na prípravu správ a obchodnej analýzy s cieľom podporiť rozhodovanie v organizácii

Touto cestou, konsolidácia Údaje z rôznych systémov, schopnosť pozrieť sa na ne s niektorým "jedným" (zjednoteným) spôsobom je jednou z kľúčových vlastností databázy triedy. To je dôvod, prečo sa to skladovali počas vývoja IT systémov.

Kľúčové vlastnosti dátových skladov

Pozrime sa viac. Aké kľúčové funkcie majú tieto systémy? Čo odlišuje dátový sklad z iných IT systémov podniku?

Po prvé, je to veľké zväzky. Veľmi veľký. VLDB. - Tak sa týka takýchto systémov vedúcich predajcov, keď poskytujú odporúčania týkajúce sa používania ich výrobkov. Zo všetkých systémov spoločnosti sa tieto dátové stádo k tejto veľkej databáze a sú tam uložené "navždy a nezmenené," ako píšete v učebniciach (v praxi, život je ťažší).

Po druhé, je to historické údaje - "Corporate Memory" - tzv. Data Sklady. Z hľadiska práce s časom v úložisku je všetko úplne zaujímavé. V účtovných systémoch sú údaje v súčasnosti v súčasnosti. Potom užívateľ vykonáva určitú operáciu - a údaje sa aktualizujú. V tomto prípade sa nemusí zachovať história zmien - závisí od praxe účtovníctva. Vezmite si napríklad zostatok na bankovom účte. Môžeme mať záujem o aktuálny zostatok na "NOW", na konci dňa alebo v čase určitej udalosti (napríklad v čase výpočtu bodovacích bodov). Ak sa prvé dve vyriešili celkom jednoducho, potom pre posledné, s najväčšou pravdepodobnosťou, bude potrebné osobitné úsilie. Užívateľ pracujúci s úložiskom sa môže obrátiť na posledné obdobia, porovnať ich s prúdom atď. Ide o tieto možnosti spojené s časom, ktorý výrazne rozlišuje dátové sklady z účtovných systémov - získanie stavu údajov v rôznych bodoch časovej osi - do určitej hĺbky v minulosti.

Po tretie, to je konsolidácia a zjednotenie údajov . Aby bolo možné ich spoločnú analýzu, musíte ich priniesť do všeobecného typu - unified Data Model , Zodpovedajte fakty s jednotnými referenčnými knihami. Môže existovať niekoľko aspektov a ťažkostí. Predovšetkým - koncepčný - Podľa toho istého obdobia, rôzni ľudia z rôznych divízií môžu pochopiť rôzne veci. A naopak - zavolať niečo iné, čo je v podstate to isté. Ako poskytnúť "jediný vzhľad" a zároveň zachovať špecifiká vízie konkrétnej skupiny používateľov?

Po štvrté, to funguje kvalita údajov . V procese zaťaženia údajov v úložisku sú vyčistené, všeobecné transformácie a transformácie. Spoločné transformácie sa musia vykonať na jednom mieste - a ďalšie použitie na vybudovanie rôznych správ. Tým sa vyhnúť nezrovnalosti, ktoré spôsobujú toľko podráždenia medzi podnikateľskými užívateľmi - najmä sprievodca, na ktorý sa "na stole" vynáša z rôznych oddelení, ktoré nie sú konvergované. Nízka kvalita dát vedie k chybám a nezrovnalostiam v správach, ktorých dôsledkom je zníženie úrovne user Trust Celý systém, na celú analytickú službu ako celku.

Architektonický koncept

Každý, kto narazil na úložisko, bolo s najväčšou pravdepodobnosťou pozorovaná určitá "vrstvená štruktúra" - pretože Je to táto architektonická paradigma, ktorá prešla pre systémy tejto triedy. A nie je to náhodou. Skladovacie vrstvy môžu byť vnímané ako samostatné zložky systému - s ich úlohami, zóny zodpovednosti, "pravidlá hry".
Úroveň architektúra je prostriedkom na boj proti zložitosti systému - každá následná úroveň sa odstraňuje z ťažkostí vnútornej implementácie predchádzajúceho. Tento prístup vám umožňuje vybrať rovnaký typ úloh a ich vyriešiť jednotne, nie vymýšľať zakaždým, keď "bicykel" od nuly.
Schematický koncepčný architektonický systém je uvedený na obrázku. Toto je zjednodušená schéma, ktorá odráža len kľúčovú myšlienku - koncepcia, ale bez "anatomických detailov", ktorá vznikla s hlbšou prácou častí.

Ako je uvedené v diagrame, koncepčne sa uvoľní nasledujúce vrstvy. Tri hlavné vrstvy, ktoré obsahujú oblasť ukladania dát (určená maľovaným obdĺžnikom) a na zaťaženie dát (podmienečne zobrazené šípkami rovnakej farby). Rovnako ako pomocná - servisná vrstva, ktorá však zohráva veľmi dôležitú väzbovú úlohu - riadenie zaťaženia dát a kontrolu kvality.

Primárna dátová vrstva - vrstva primárnych údajov (alebo stýkavý alebo operačná vrstva ) - Navrhnuté na prevzatie zo zdrojových systémov a udržiavať primárne informácie, bez transformácií - v kvalite zdrojov a podpory úplnej histórie zmien.
Úlohu tejto vrstvy - Abstraktné následné skladovacie vrstvy z fyzického zariadenia dátových zdrojov, spôsobov zberu a spôsobov prideľovania zmeny delty.

Jadrová dátová vrstva - skladovacie jadro - centrálna zložka systému, ktorá rozlišuje úložisko pred jednoduchým "platformou pre integráciu dávky", alebo "veľkú výpis údajov", pretože jeho hlavnou úlohou je konsolidácia údajov Z rôznych zdrojov, ktoré prinášajú do jednotných štruktúr, kľúčov. Je to pri načítaní v jadre, hlavná práca sa vykonáva s kvalitou údajov a všeobecnou transformáciou, ktorá môže byť dosť zložitá.
Úlohu tejto vrstvy - odvodnenie svojich spotrebiteľov z funkcií logického zariadenia údajov z údajov a potrebu porovnávania údajov z rôznych systémov, zabezpečiť integritu a kvalitu údajov.

Data Mart Layer - Analytické Showcases - Zložka, ktorej hlavnou funkciou je previesť dáta na štruktúry, vhodné analyzovať (ak BI pracuje s ukážkami - potom je to zvyčajne dimenzionálny model), alebo podľa požiadaviek spotrebného systému.
Spravidla sa uvádzajú predstavenia z jadra - ako spoľahlivý a overovaný zdroj - t.j. Použite službu tohto komponentu, aby ste mohli priviesť údaje do jednej formy. Zavoláme takéto prípady zobrazenia pravidelný . V niektorých prípadoch môžu showcase brať dáta priamo zo steidzhin - prevádzkových primárnych údajov (v zdrojových klávesoch). Takýto prístup sa zvyčajne používa pre miestne úlohy, kde sa vyžaduje konsolidácia údajov z rôznych systémov a kde je účinnosť potrebná viac ako kvalita údajov. Takéto predstavenia sa nazývajú operatívny . Niektoré analytické ukazovatele môžu mať veľmi zložité výpočtové techniky. Preto pre takéto triviálne výpočty a transformácie vytvárajú takzvaný takzvaný sekundárne predstavenia .
Windows Windows - príprava údajov podľa špecifických požiadaviek na spotrebiteľov - BI platformy, skupiny užívateľov alebo externého systému.

Vyššie opísané vrstvy pozostávajú z konštantnej skladovania, ako aj softvérového modulu sťahovania a transformácie údajov. Takéto oddelenie na vrstvách a oblastiach je logické. Fyzicky, implementácia týchto komponentov môže byť iná - môžete dokonca používať rôzne platformy na ukladanie alebo konverziu údajov na rôznych vrstvách, ak je efektívnejšie.
Skladovacia plocha obsahuje technické (tlmivé tabuľky), ktoré sa používajú v procese transformácie údajov a ÚlohyKu ktorému je spotrebiteľský komponent. Pravidlo dobrého tónu je "kryt" cieľových tabuliek podľa názorov. To uľahčuje následnú podporu a rozvoj systému. Údaje v cieľových tabuľkách všetkých troch vrstiev sú označené špeciálnymi technickými oblasťami (meta atribúty), ktoré slúžia na zabezpečenie procesov zaťaženia údajov, ako aj možnosť informačného auditu dátových tokov v úložisku.

Taktiež prideľujte špeciálny komponent (alebo súbor komponentov), \u200b\u200bktorý poskytuje servisné funkcie pre všetky vrstvy. Jedným z kľúčových úloh je kontrolná funkcia - poskytnúť "jednotné pravidlá hry" pre celý systém ako celok, takže právo používať rôzne možnosti na implementáciu každej z vrstiev opísaných vyššie - vr. Použite rôzne údaje o načítaní dát a technológie spracovania údajov, rôzne platformy na skladovanie atď. Zavoláme to servisná vrstva . Neobsahuje obchodné údaje, ale má svoje skladovacie štruktúry - obsahuje oblasť metaúdajov, ako aj oblasť pre prácu s kvalitou údajov (a prípadne inými štruktúrami - v závislosti od funkcií pridelených).

Takéto jasné oddelenie systému do jednotlivých zložiek výrazne zvyšuje kontrolovateľnosť vývoja systému:

• zložitá zložitosť úlohy je znížená, ktorá je nastavená na vývojára funkčnosti konkrétneho komponentu (nemalo by to súčasne vyriešiť problémy integrácie s externými systémami a vyrábať postupy čistenia údajov a premýšľajte o optimálnej prezentácii údajov pre spotrebiteľov ) - Úloha je ľahšie rozložená, hodnotiť a vykonávať malé dodanie;
• môžete sa pripojiť k práci rôznych interpretov (a dokonca aj tímy alebo dodávateľov) - pretože Tento prístup vám umožňuje efektívne rovnobežné problémy, čo znižuje ich vzájomný vplyv na seba;
• prítomnosť pretrvávajúceho steyjingu vám umožňuje rýchlo pripojiť zdroje údajov bez navrhovania celého jadra alebo ukážky pre celú oblasť predmetu, a potom postupne držať zostávajúce vrstvy podľa priorít (a údaje budú už v úložisku - prístupné podľa systému Analytici, ktoré výrazne uľahčia úlohy následného vývoja úložiska);
• prítomnosť jadra umožňuje všetkým údajom s kvalitou dát (ako aj možných misií a chýb) skryť pred displejmi az koncového používateľa, a čo je najdôležitejšie - pomocou tohto komponentu ako jeden zdroj dát pre prezentácie, vy sa môže vyhnúť problémom s konvergenciou dát v dôsledku implementácie všeobecných algoritmov na jednom mieste;
• výber showcases vám umožňuje zohľadniť rozdiely a špecifiká chápania údajov, ktoré môžu mať užívatelia z rôznych oddelení, a ich návrhy na požiadavku BI umožňuje nielen vydávať agregované údaje, ale zabezpečiť overenie spoľahlivosti údajov Poskytovanie možností vrtania na primárne ukazovatele;
• prítomnosť servisnej vrstvy umožňuje vykonávať prostredníctvom analýzy dát (dátová línia), použite zjednotené nástroje auditu údajov, všeobecné prístupy k prideľovaniu zmeny delty, ktorá pracuje s kvalitou údajov, na stiahnutie, nástroje na monitorovanie a diagnostiku chýb, urýchľuje rozlíšenie problémov.

Tento prístup k rozkladu tiež robí systém odolnejší voči zmene (v porovnaní s "monolitickým dizajnom") - poskytuje jeho protivládnosť:

• zmeny zo systémových systémov sa prejavujú na Stujming - v jadre, v jadre sa modifikujú len tie toky, ktoré ovplyvňujú tieto tabuľky steward, účinok na ukážku je minimálny alebo neprítomný;
• zmeny v požiadavkách na spotrebiteľov sa vykonávajú z väčšej časti na oknách (ak nevyžaduje ďalšie informácie, ktoré ešte nie sú v úložisku).

Ďalej pôjdeme cez každú z vyššie uvedených komponentov a pozrite sa na ne trochu viac.

Základný systém

Začnime "od stredu" - jadro systému alebo strednej vrstvy. Na označenú ako jadrová vrstva. Kernel pôsobí ako konsolidácia dát - prinášajú jednotné štruktúry, adresáre, kľúče. Tu je hlavná práca s kvalitou dát - čistenie, transformácia, zjednotenie.

Prítomnosť tejto zložky umožňuje znovu použiť dátové toky, ktoré transformujú primárne údaje získané zo zdrojových systémov do jedného formátu, podľa všeobecných pravidiel a algoritmov a neopakujú implementáciu rovnakej funkčnej skupiny samostatne pre každú aplikáciu, ktorá Okrem neefektívneho využívania zdrojov môže znamenať aj divergenciu údajov.
Jadro údajov sa vykonáva v údajovom modeli, vo všeobecnosti okrem modelov zdrojových systémov a formátov a spotrebiteľských štruktúr.

Skladovací základný model a firemný dátový model

Hlavnou úlohou priemernej skladovacej vrstvy je stabilita. Preto je hlavný dôraz na dátovom modeli. Je zvyčajný nazvaný "firemný dátový model". Bohužiaľ, určité halo mýtus a postrehy sa vyvinuli okolo neho, ktoré niekedy vedú k opusteniu svojej výstavby vôbec a márne.

Mýtus 1. Corporate Data Model je obrovský model pozostávajúci z tisícov entít (tabuľky).
Vlastne. V akejkoľvek oblasti, v ktorejkoľvek obchodnej oblasti, v akejkoľvek obchodnej doméne, v údajoch akejkoľvek spoločnosti, aj tie najťažšie, hlavné subjekty sú trochu - 20-30.

Mýtus 2. Nie je potrebné rozvíjať žiadny "môj model" - kúpiť sektorový referenčný model - a robíme všetko podľa neho. Trávime peniaze - ale dostaneme garantovaný výsledok.
Vlastne. Referenčné modely môžu byť naozaj veľmi užitočné, pretože Obsahujú modelovanie priemyselných skúseností v tejto oblasti. Z nich sa môžete učiť nápady, prístupy, postupy pomenovania. Skontrolujte "hĺbku pokrytia" regiónu, aby ste nechýbali niečo dôležité. Môžeme však sotva používať taký model "z krabice" - ako je. Toto je rovnaký mýtus, ako je nákup ERP systému (alebo CRM) a jeho zavedenie bez akéhokoľvek "syrov-to-yourself". Hodnota takýchto modelov sa narodí v ich prispôsobení sa realite tohto podniku, je to táto spoločnosť.

Mýtus 3. Vývoj modelu jadra skladovania môže trvať mnoho mesiacov a v tomto čase bude projekt skutočne zmrazený. Okrem toho si vyžaduje bláznivý počet stretnutí a účasť mnohých ľudí.
Vlastne. Skladovací model môže byť vyvinutý spolu s uskladnením iteratívne, v častiach. "Expanzné body" alebo "zástrčka" sú nastavené pre neopustné oblasti - t.j. Uplatňujú sa niektoré "univerzálne návrhy". Zároveň je potrebné poznať opatrenia tak, aby super-univerzálna vec nefungovala zo 4 tabuliek, čo je ťažké "dať údaje" a (ešte ťažšie), aby si to. A ktorý je nesmierne optimálne pracovať, pokiaľ ide o výkon.

Je čas na rozvoj modelu. Ale toto nie je čas strávený na "cresbe entity" - tentoraz potrebný na analýzu oblasti predmetu, pochopenie údajov. To je dôvod, prečo sú v tomto procese, analytici veľmi úzko zapojení a sú zapojení rôznych obchodných expertov. A selektívne je to bod. A nie organizovaním stretnutí s účasťou šialeného počtu ľudí, poštových strát obrovských dotazníkov atď.
Kvalitná obchodná a systémová analýza - toto je to, čo je kľúčové pri výstavbe modelu jadra. Potrebujete veľa vecí na pochopenie: kde (v ktorých systémov) sú údaje generované, pretože sú usporiadané, v ktorých obchodné procesy, ktoré obiehajú atď. Kvalitatívna analýza ešte nebola poškodená jediný systém. Naopak - problémy vznikajú z "bielych miest" v našom porozumení.

Vývoj dátového modelu nie je procesom vynálezu a vymyslieť niečo nové. V skutočnosti existuje dátový model v spoločnosti. A proces jeho dizajnu je skôr podobný "vykopávkam". Model je úhľadne a opatrne odstránený z "pôdy" firemných dát a je spojený so štruktúrovanou formou.

Mýtus 4. V našej spoločnosti je spoločnosť tak dynamická, a všetko sa tak rýchlo mení, že je zbytočné, že model - vydrží skôr, ako sme zaviesť túto časť systému do prevádzky.
Vlastne. Pripomeňme, že kľúčovým faktorom jadra je stabilita. A predovšetkým modelové topológie. Prečo? Pretože je to táto zložka, ktorá je centrálna a má vplyv na všetko ostatné. Stabilita je požiadavkami modelu jadra. Ak sa model stane príliš rýchlo - to znamená, že je nesprávne navrhnutý. Pre jeho vývoj nie sú vybraté prístupy a "pravidlá hry". A tiež to je otázka vysoko kvalitnej analýzy. Kľúčové esencie firemného modelu sa menia veľmi zriedkavo.
Ale ak prídeme na myseľ, aby spoločnosť predala, cukráreň, namiesto "produktov" adresára, aby sa "Candy", "koláče" a "koláče". Keď sa pizza objaví v zozname tovaru - áno, budete musieť zadať veľa nových tabuliek. A to je len otázka prístupu.

Mýtus 5. Vytvorenie korporátneho modelu je veľmi vážna, komplexná a zodpovedná vec. A strašne urobiť chybu.
Vlastne. Model jadra by mal byť stabilný, ale stále nie "obsadený v kovu". Podobne ako akékoľvek iné dizajnové riešenia, jej štruktúra môže byť preskúmaná a upravená. Len na to nemusíte zabudnúť. Ale to neznamená vôbec, že \u200b\u200b"nemôžete dýchať". A to neznamená, že dočasné riešenia a "zástrčky" sú neprijateľné, čo by malo byť naplánované na spracovanie.

Mýtus 6. Ak máme zdroj údajov - napríklad systém NSI (alebo systém manažérskeho dát je MDM), potom musí byť dobrým spôsobom, ako dodržiavať firemný model (najmä ak bol nedávno navrhnutý, a nie majú čas stať sa "mimochodom", "tradície" a obrysy). Ukazuje sa, že pre túto príležitosť - nepotrebujeme model jadra?
Vlastne. ÁNO, V tomto prípade je výstavba modelu jadra skladu veľmi uľahčená - pretože Sledujeme hotový koncepčný vrcholový model. Nie je však vôbec vylúčená. Prečo? Vzhľadom k tomu, že pri budovaní modelu konkrétneho systému, niektoré z ich vlastných pravidiel platia - aké typy tabuliek sa používajú (pre každú jednotku), ako sa uchovávajú údaje, s ktorou zrnitosť na udržanie príbehu, ktoré metria (technické oblasti používať) , atď.

Okrem toho, bez akéhokoľvek nádherného a komplexného systému NSI a MDM, ktoré máme - spravidla, tam bude nuansy spojené s existenciou miestnych referenčných kníh "o tej istej veci" v iných účtovných systémoch. A tento problém, chceme to, alebo nie - budete musieť rozhodnúť o úložisku - po tom všetkom, hlásenie a analytik tu zbierať.

Primárna dátová vrstva (alebo historicky inscenácia alebo prevádzková vrstva)

Je označená ako primárna dátová vrstva. Úloha tohto komponentu: integrácia so zdrojovými systémami, nakladanie a ukladanie primárnych údajov, ako aj predbežné čistenie dát - overovanie v súlade s pravidlami formát-logického riadenia zaznamenaného v "Zmluve o rozhraní rozhrania" so zdrojom.
Okrem toho táto zložka rieši veľmi dôležitú úlohu pre úložisko - prideľovanie "skutočnej zmene delta" - bez ohľadu na to, či zdroj umožňuje sledovať zmeny v údajoch alebo nie a ako (podľa ktorého kritéria môžu byť "ulovené") . Akonáhle údaje klesli do Stujingu - pre všetky ostatné vrstvy, problém delty je už pochopený - kvôli označovaniu podľa meta atribútov.

Údaje v tejto vrstve sú uložené v štruktúrach čo najbližšie k zdrojovému systému - na uloženie primárnych údajov čo najbližšie k ich nedotknutému vzhľadu. Ďalším názvom tejto zložky je "prevádzková vrstva".
Prečo nielen použiť vytvorený termín "staging"? Faktom je, že skôr, na "EPOCH veľkých údajov a VLDB", miesto na disku bolo veľmi drahé - a často primárne údaje, ak pretrvávajú, potom obmedzený časový interval. A často sa volá meno "staging" klesnutý Buffer.
Teraz technológie vystúpili dopredu - a môžeme si dovoliť nielen na udržanie všetkých primárnych údajov, ale historizovať ich s mierou zrnitosti, ktorá je možná. To neznamená, že by sme nemali kontrolovať rast údajov a nerušíme potrebu kontrolovať životný cyklus informácií optimalizáciou nákladov na ukladanie údajov v závislosti od "teploty" použitia - t.j. Nájdením "studených dát", ktoré sú menej v dopyte, pre lacnejšie skladovacie nosiče a platformy.

Čo nám dáva "historicky umiestnený steidzhin":

• schopnosť byť mýli sa (v štruktúrach, v algoritách transformácie, v granularite histórie) - s plne historizovanými primárnymi údajmi v zóne prístupnosti pre úložisko, môžeme vždy obnoviť reštart našich tabuliek;
• príležitosť si myslieť - nemôžeme sa ponáhľať so štúdiou veľkého fragmentu jadra v tejto iterácii rozvoja úložiska, pretože V našom Stajingu bude v každom prípade, a s hladkým dočasným horizontom (bod "počítania histórie" bude jeden);
• schopnosť analyzovať - \u200b\u200bbudeme držať aj tie údaje, ktoré už nie sú v zdroji - mohli sa tam stratiť, choďte do archívu atď. - Zostávame aj na analýzu;
• schopnosť informačného auditu - vďaka najpravdepodobnejším primárnym informáciám, potom môžeme pochopiť - ako sme pracovali na stiahnutí, že sme nakoniec dostali také čísla (pre to musíte mať označovanie podľa meta atribútov a zodpovedajúce metaúdaje, na ktorých na stiahnutie Práce sú riešené na servisnej vrstve).

Aké ťažkosti môžu vzniknúť pri budovaní "Historized Steidzhinburg":

• bolo by vhodné stanoviť požiadavky na transakčnú integritu tejto vrstvy, ale prax ukazuje, že je ťažké dosiahnuť (to znamená, že v tejto oblasti nezaručujeme referenčnú integritu materských a detských stolov) - vystupuje integrita o následných vrstvách;
• táto vrstva obsahuje veľmi veľké objemy (najviac objemné na úložisku - napriek nadbytočnosti analytických štruktúr) - a musíte byť schopní zvládnuť také zväzky - oba z hľadiska download a z hľadiska Žiadosti (inak môžete vážne degradovať výkon celého úložiska).

Čo ešte môžem povedať o tejto vrstve.
Po prvé, ak sa presunieme z paradigmy "Proces-Loading Process" - potom pre nás už nebudú fungovať pravidlo "Caravan prichádza s rýchlosťou poslednej ťavy", presnejšie, odmietneme princíp "karavanu" a pokračovať na princíp "Dopravník": Urobil údaje zo zdroja - vložili do svojej vrstvy - pripravená na ďalšiu časť. Znamená to, že
1) Nečakame, kým sa nedosiahne spracovanie na iných vrstvách;
2) Nie sme závislí od harmonogramu udeľovania inými systémami.
Jednoducho povedané, vložíme do plánu zavádzacieho procesu, ktorý berie dáta z jedného zdroja prostredníctvom určitého spôsobu pripojenia, kontroluje, vyberie delta - a dá údaje do tabuľky úloh Statedy. A to je to.

Po druhé, tieto procesy, ako možno vidieť, sú veľmi jednoduché - môžete povedať triviálne, pokiaľ ide o logiku. A to znamená - môžu byť veľmi dobre optimalizované a parametrizované, znižujú zaťaženie na našom systéme a urýchliť proces spojovacích zdrojov (vývojový čas).
Ak sa chcete stať, musíte veľmi dobre poznať funkcie technologických vlastností platformy, na ktorých táto zložka funguje - a potom môžete urobiť veľmi efektívny nástroj.

Vrstva analytických obchodov

Vrstva Data Mart je zodpovedná za prípravu a poskytovanie týchto koncových užívateľov - ľudí alebo systémov. Na tejto úrovni sú požiadavky spotrebiteľa maximálne zohľadnené - logické (koncepčné) a fyzické. Služba musí poskytnúť presne to, čo je potrebné - už nie menej.

Ak je spotrebiteľ externý systém, potom spravidla určuje tie dátové štruktúry, ktoré potrebujú a predpisy pre informačný plot. Dobrý prístup sa považuje za taký, v ktorom je samotný spotrebiteľ zodpovedný za správny dátový plot. Údaje o úložisku pripravené, vytvorili showcase, za predpokladu, že možnosť inkrementálneho zastrašovania údajov (označenie meta-atribútmi pre následné pridelenie zmeny delty) a ďalšie kontroly systému a spotrebiteľov a je zodpovedný za to, ako používa túto showcase. Existujú však vlastnosti: keď systém nemá aktívnu zložku pre zber údajov - potrebujete buď externý komponent, ktorý vykoná integrujúcu funkciu, alebo skladovanie bude vykonávať ako "integračné platformy" - a poskytne správnu prírastkovú prepravu údajov nižšie - mimo archívu. Mnoho nuances sa vyskočí a pravidlá interakcie rozhrania by mali byť premýšľané a zrozumiteľné pre obe strany (ako vždy - pokiaľ ide o integráciu). Na podobné zobrazenie ukazuje, spravidla sa aplikuje regulačná čistenie / archivácia údajov (je zriedka nevyhnutné, že tieto "tranzitné údaje" sú uložené na dlhú dobu).

Najvyššia hodnota z hľadiska analytických úloh je "pre ľudí" - presnejšie pre nástroje bi, s ktorými pracujú.
Existuje však kategória "vysoko pokročilých užívateľov" - analytici, výskumníci údajov - ktoré nie sú potrebné ani nástroje BI ani regulačné procesy plnenia externých špecializovaných systémov. Vyžadujú niektoré "spoločné obchodné okná" a "jeho pieskovisko", kde môžu vytvoriť tabuľky a transformácie podľa vlastného uváženia. V tomto prípade je zodpovednosťou skladovania zabezpečiť, aby tieto spoločné relácie vypĺňali dodržiavanie predpisov.
Takéto spotrebitelia možno rozdeliť ako nástroje na banské dát - Hlboká analýza údajov. Takéto nástroje majú vlastné požiadavky na prípravu údajov a odborníci pre výskum údajov tiež pracujú aj s nimi. Pre skladovacie zariadenie sa úloha zníži - opäť na podporu služby na načítanie niektorých zobrazení dohodnutého formátu.

Späť na Windows Analytical Shop. V tejto dátovej vrstve sú zaujímavé z hľadiska vývojárov dizajnérov skladovania.
Podľa môjho názoru, najlepší prístup k dizajnu dátových predstaví, testovaných v čase, ktorý je teraz "ostrý" podľa takmer všetkých platforiem BI je prístup Ralph Kimball. Je slávny rozmerové modelovanie - Multidimenzionálne modelovanie. Na tejto téme je veľa publikácií. Napríklad hlavné pravidlá možno nájsť v publikácii Margi Ross. A samozrejme, možno odporučiť od guru multidimenzionálneho modelovania. Ďalší užitočný zdroj - "Kimballa tipy"
Multidimenzionálny prístup k vytvoreniu relácií je popísaný a pracujúci rovnako - obaja z "evanjelistov metódy" a od popredných predajcov softvéru, ktorý nemá zmysel tu nejako, je vždy výhodné zastaviť na ňom - Zdroj je vždy uprednostňovaný.

Chcel by som urobiť len jeden prízvuk. "Reporting a analytics" je iný. Existujú "Ťažké reporting" - predobjednané správy, ktoré sú vytvorené ako súbory a dodávajú používateľov pomocou poskytovaných dodacích kanálov. A existujú informačné panely - BI Dashboards. V podstate je to webová aplikácia. A v čase odozvy týchto aplikácií sú uvedené rovnaké požiadavky ako pre akúkoľvek inú webovú aplikáciu. To znamená, že normálny čas aktualizácie BI-Panel je sekundy, nie za minútu. Je dôležité si zapamätať pri vývoji riešenia. Ako to dosiahnuť? Štandardná metóda optimalizácie: Pozrite sa, čo je čas odozvy a to, čo môžeme ovplyvniť. Čo je najviac času tráviť čas? Na fyzickom (disku) databáze čítania, prenos dát cez sieť. Ako znížiť rozsah čítania a prenášaných údajov pre jednu požiadavku? Odpoveď je zrejmá a jednoduchá: je potrebné buď agregátu, alebo aplikovať filter do veľkých tabuľkových tabuliek, ktoré sa zúčastňujú na dotaze, a vylúčiť pripojenie veľkých tabuliek (prístup k tabuľkám aktuálnych skutočností by mal prejsť iba meraniami).

Čo je bi? Čo je to vhodné? Prečo je multidimenzionálny model?
BI Umožňuje užívateľovi vykonávať takzvané "nevolené požiadavky". Čo to znamená? To znamená, že presne nepoznáme žiadosť vopred presne, ale vieme, aké ukazovatele v tom, čo si užívateľ môže požiadať. Užívateľ vytvára takúto požiadavku výberom zodpovedajúcich filtrov BI. A úloha developera Bi a dizajnéra showcase je poskytnúť takú logiku aplikácie, aby sa údaje boli buď filtrované, alebo agregované, neumožňujú situáciu, keď sa údaje vyžadujú príliš veľa - a aplikácia "Hung". Zvyčajne začínajú agregovanými číslami, ďalej prehĺbenie na podrobnejšie údaje, ale súčasne inštaluje požadované filtre.

Nie je to vždy dosť na to, aby ste jednoducho postavili "správnu hviezdu" - a získajte pohodlnú štruktúru pre BI. Niekedy to bude mať niekde aplikovať denormalizáciu (pri pohľade v rovnakom čase, pretože bude mať vplyv na stiahnutie), a niekde vykonať sekundárne predstavenia a agregáty. Niekde pridajte indexy alebo projekcie (v závislosti od DBMS).

Tak, podľa "vzoriek a chýb", je možné získať štruktúru optimálne pre BI -, ktorý bude v súlade s funkciami oboch DBMS aj BI-platforiem, ako aj požiadavky na údaje o prezentácii údajov.
Ak berieme údaje z "jadrá", potom takéto spracovanie showcase bude lokálne v prírode, bez toho, aby ovplyvnil komplexné spracovanie primárnych údajov získaných priamo zo zdrojových systémov - len "posunutím" údajov do pohodlného formátu pre bi. A môžeme si dovoliť, aby sme to robili mnohokrát rôznymi spôsobmi, v súlade s rôznymi požiadavkami. Na jadre dáta je oveľa jednoduchšie a rýchlejšie ako zozbieranie z "primárnej" (štruktúry a pravidlá, ako vieme, môže byť "plávať").

Servisná vrstva

Servisná vrstva (- Servisná vrstva) je zodpovedná za implementáciu spoločných (služobných) funkcií, ktoré možno použiť na spracovanie údajov v rôznych skladovacích vrstvách - riadenie download, riadenie kvality údajov, problémy s diagnostikou a monitorovaním, atď.
Prítomnosť tejto úrovne poskytuje transparentnosť a štruktútu dátových tokov v úložisku.

Táto vrstva obsahuje dve skladovacie priestory:

• plocha metaúdajov sa používa na mechanizmus nakladania dát;
• oblasť kvality údajov - vykonávať off-line kontroly kvality údajov (t.j. tie, ktoré nie sú integrované priamo do procesov ETL).

Môžete si vytvoriť proces riadenia sťahovania inak. Jedným z možných prístupov je: Rozdeľujeme všetky súbory skladovacích stolov na moduloch. Modul môže obsahovať tabuľky iba jednej vrstvy. Tabuľky, ktoré sú súčasťou každého modulu, sú naložené v samostatnom procese. Zavolajme to riadiaci proces . Spustenie procesu kontroly je umiestnený na jeho harmonograme. Orgáty riadiaceho procesu hovoria atómové procesy, z ktorých každý z nich sťahuje jednu cieľovú tabuľku, a tiež obsahuje niektoré spoločné kroky.
Je zrejmé, že stačí jednoducho rozdeliť tabuľky inscenáciu na moduloch - podľa zdrojových systémov, alebo skôr ich pripojovacími bodmi. Ale pre jadro to je už ťažšie robiť - pretože Musíme zabezpečiť integritu údajov, čo znamená, že musíte zohľadniť závislosti. Tí. Zosúlaď sa objaví, že sa musia vyriešiť. A existujú rôzne metódy pre ich povolenie.

Dôležitým bodom v riadení na prevzatie je vývoj jedného prístupu k spracovaniu chýb. Chyby sú klasifikované z hľadiska kritickosti. Ak sa vyskytne kritická chyba, proces sa musí zastaviť, a čo najrýchlejšie, pretože Jeho vznik hovorí o významnom probléme, ktorý môže viesť k poškodeniu v úložisku. Správa sťahovania je teda nie je len začiatkom procesov, ale aj ich zastávka, ako aj prevencia neskorého spustenia (omylom).

Pre servisnú vrstvu sa vytvorí špeciálna štruktúra metaúdajov. V tejto oblasti, informácie o zavádzacích procesoch, prevzatých dátových súpravách, kontrolných bodoch, ktoré sa používajú na udržanie prírastku (ktorý proces, ku ktorému čítanie bodu) a ďalšie informácie o službách potrebných na funkciu systému sú potrebné pre funkciu systému.
Je dôležité si uvedomiť, že všetky cieľové tabuľky vo všetkých vrstvách sú označené špeciálnou sadou meta-polí, z ktorých jedna je identifikátor procesu, ktorý je aktualizovaný, je reťazec. Pre tabuľky vo vnútri uskladnenia vám tento proces označenia umožňuje používať jednotný spôsob následnej identifikácie zmeny delty. Pri načítaní dát vo vrstve primárnych údajov je zložitejšie - algoritmus pre výber delty pre rôzne objekty na prevzatie môže byť odlišné. Ale logika spracovania prijatých zmien a ich náprotivku na cieľových tabuľkách pre jadro a showcases sú oveľa zložitejšie ako pre stepinné, kde je všetko dosť triviálne - je ľahké parametrizovať a premýšľať o štandardných krokoch (postupoch).

Túto tému neuvádzam, aby som túto tému úplne zvýraznila - organizácia na stiahnutie je len stanovením akcentov, do ktorých by sa mala venovať pozornosť.
Daný prístup je len jednou z možností. Je dosť adaptívny. A jeho "koncepčný prototyp" bol dopravník Toyota a systém "presne počas" (just-in-time). Tí. Odchádzame v rozsiahlej paradigme tu výhradne "nočné stiahnutie" a počas dňa načítate malé časti - pretože údaje sú pripravené v rôznych zdrojoch: čo prišlo a nahrali. Zároveň pracujeme s mnohými paralelnými procesmi. "Horúci chvost" čerstvých dát bude neustále "blikať" - a po chvíli zarovnanie. Musíme zohľadniť takúto funkciu. A ak je to potrebné, vytvorte vlastné obchodné okná "Cuts", kde je všetko je už holistické. Tí. Nie je možné súčasne dosiahnuť účinnosť aj konzistenciu (integritu). Potrebujeme rovnováhu - jedna vec je niekde dôležitá niekde inde.

Je mimoriadne dôležité poskytnúť nástroje žurnalovania a monitorovania. Dobrá prax je použitie napísaných udalostí, kde môžete nastaviť rôzne parametre a nakonfigurovať systém notifikácie, aby ste sa prihlásili na určité udalosti. Pretože Je veľmi dôležité, aby sa vyžadovalo zásah správcu systému - sa o tom dozvedel čo najskôr a dostal všetky potrebné diagnostické informácie. Časopisy môžu byť tiež použité na analýzu problémov "post-fakty", ako aj vyšetrovať incidenty poruchy výkonu systému, vrátane. Kvalita údajov.

Návrh a údržba skladovacích údajov modelov

Prečo pri vývoji akéhokoľvek systému, kde je databáza zapojená (av úložisku - najmä), je dôležité venovať pozornosť dizajnu dátových modelov? Prečo nie zvoliť súbor tabuliek, kdekoľvek - aspoň v textovom editore? Prečo potrebujeme "tieto obrázky"?
Podivné, takéto otázky dokonca dali skúsených vývojárov.
Vlastne, áno, nič nezabráni naklám na skica - a začať ich používať. Ak ... zatiaľ čo v hlave (!) Developer má tenký celkový obraz štruktúry, ktorý je. A čo keď sú vývojári trochu? A čo ak tieto tabuľky používajú niekoho iného? A čo keď časy prechádza - osoba opustí túto oblasť, a potom sa k nemu vráti?

Je možné riešiť bez modelu? V zásade môžete. A zistiť, a "kurva obrázky na kus papiera" a "chôdze - usadiť" údaje. Je však oveľa jednoduchšie, presnejšie a rýchlejšie používať hotový artefakt dátového modelu. A tiež pochopiť "logiku jeho zariadenia" - t.j. Bolo by pekné mať všeobecné pravidlá hry.

A čo je najdôležitejšie, ani to. Najdôležitejšou vecou je, že pri navrhovaní modelu sme nútení (len bez možností!) Ľahšie a hlboko naučiť predmet oblasti, funkcie dátového zariadenia a ich použitie v rôznych obchodných prípadoch. A tie otázky, ktoré by sme boli ľahko "presunuté" ako zložité, "zakalené", hádzanie našich značiek, bez toho, aby sa snažil dizajn Model - teraz budeme nútení dať a rozhodnúť sa teraz, pri analýze a navrhovaní a neskôr - keď budujeme správy a premýšľame o tom, ako urobiť nekompatibilný "a zakaždým" vymyslieť bicykel ".

Takýto prístup je jedným z tých inžinierskych praktík, ktoré vám umožňujú vytvárať anti-roky. Vzhľadom k tomu, že sú jasne usporiadané, transparentné, vhodné pre rozvoj, a okamžite viditeľné ich "hraniciach nestability" - môžete presnejšie oceniť "katastrofa", keď nové požiadavky a čas potrebný na redesign (ak je to potrebné).
Dátový model je teda jedným z hlavných artefaktov, ktoré by sa mali udržiavať v procese vývoja systému. Dobrým spôsobom by to malo byť "na stole" každej analytiky, vývojára atď. - Všetci, ktorí sa zúčastňujú na projektoch vývoja projektov.

Projektové dátové modely je samostatná, veľmi rozsiahla téma. Pri navrhovaní skladov sa používajú dva hlavné prístupy.
Pre jadro je prístup dobrý "Essence-komunikácia" - Ak je normalizovaný (3NF) model postavený na základe presne štúdiu oblasti predmetu, alebo skôr zvolená plocha. Tu rovnaký "firemný model" hrá, ktorý bol diskutovaný vyššie.

Pri navrhovaní analytických relácií multidimenzionálny model . Tento prístup pôjde dobre na pochopenie podnikateľov - pretože Ide o model, jednoduchý a pohodlný pre ľudské vnímanie - ľudia pracujú s zrozumiteľným a známym pojmom metriky (ukazovatele) a rezov, pre ktoré sú analyzované. A to vám umožní jednoducho a jasne vybudovať proces zberu požiadaviek - nakreslíme súbor "matice škrtov a ukazovateľov", komunikujeme so zástupcami rôznych divízií. A potom sa znížime na jednu štruktúru - "Analysis Model": Vytvárame "pneumatiku meraní" a určujeme fakty, ktoré sú na nich definované. Pozdĺž cesty pracujeme na hierarchiách a pravidlách agregácie.

Ďalej je veľmi ľahké ísť do fyzického modelu, pridanie prvkov optimalizácie, pričom sa zohľadní vlastnosti DBMS. Napríklad, pre Oracle, bude to rozdelenie, súbor indexov atď. Pre Vertica sa použijú iné techniky - triedenie, segmentácia, rozdelenie.
Môže byť tiež potrebná špeciálna denormalizácia - keď sme zámerne vykonávať nadbytočnosť do údajov, vďaka ktorej zlepšujeme rýchlosť požiadaviek, ale zároveň komplikuje aktualizáciu údajov (pretože redundancia bude potrebné zohľadniť a udržiavať počas zaťaženia údajov proces). Je možné, aby sa zlepšila rýchlosť, budeme tiež musieť vytvoriť ďalšie agregované tabuľky, alebo použiť takéto ďalšie schopnosti DBMS ako projekcia vo Vertica.

Takže pri modelovaní údajov o skladovaní, vyriešime niekoľko úloh:

• Úloha konceptu koncepčného (logického) modelu jadra - systémovej a obchodnej analýzy - štúdie predmetnej oblasti, prehĺbenie detailov a účtovanie nuansy "životných údajov" a ich využívanie v podnikaní;
• Úloha vybudovania analytického modelu - a ďalšieho koncepčného (logického) modelu showcases;
• Úlohou budovania fyzických modelov je kontrolovať nadbytočnosť údajov, optimalizáciu, pričom sa zohľadnia vlastnosti DBMS pre dotazy a načítanie dát.

Pri vývoji koncepčných modelov nemusíme brať do úvahy vlastnosti konkrétnych DBMS, pre ktoré navrhujeme štruktúru databázy. Okrem toho môžeme použiť jeden koncepčný model na vytvorenie niekoľkých fyzických - pre rôzne DBMS.

Sumarizujeme.

• Dátový model nie je súbor "krásnych obrázkov" a proces jeho dizajnu nie je proces ich kreslenia. Model odráža naše chápanie oblasti predmetu. A proces jeho prípravy je proces jeho štúdie a výskumu. Čas. A nie vôbec "kresliť a maľovať".
• Dátový model je projektový artefakt, metóda zdieľania informácií v štruktúrovanej forme medzi členmi tímu. Na tento účel je potrebné chápať všetko (to je zabezpečené podľa notácie a vysvetlenia) a je k dispozícii (publikované).
• Dátový model nie je vytvorený raz a zmrazený, ale je vytvorený a vyvinutý v procese rozvoja systému. Obyme sa pýtame na pravidlá pre jeho rozvoj. A môžeme ich zmeniť, ak vidíme - ako to lepšie, jednoduchšie, efektívnejšie.
• Dátový model (fyzický) vám umožňuje konsolidovať a používať súbor osvedčených postupov zameraných na optimalizáciu - t.j. Použite tieto techniky, ktoré už pracovali pre toto DBMS.

Vlastnosti projektov dátových skladov

Dajte nám prebývať na vlastnostiach projektov, v ktorých sú vybudované zariadenia na ukladanie údajov. A pozrime sa na nich z hľadiska vplyvu architektonického aspektu. Prečo je dôležité vybudovať architektúru takýchto projektov a od samého začiatku. A je prítomnosť dobre premyslenej architektúry, ktorá poskytuje flexibilitu projektu dátového skladu, umožňuje vám efektívne rozdeliť prácu medzi výkonnými umelcami a je tiež jednoduchšie predpovedať výsledok a urobiť proces predvídateľnejším .

Dátový sklad je zvyk

Dátový sklad je vždy "vývojový vývoj", a nie boxerské riešenie. Áno, existujú sektorové BI aplikácie, ktoré obsahujú referenčný model dát, preponované procesy ETL zo spoločných zdrojov (napríklad ERP systémov), súbor typických BI panelov a správ. Ale v praxi je skladovanie extrémne zriedkavo zavedené - ako "box". Pracujem s úložiskami asi 10 rokov a nikdy nevidela takú históriu. Vždy vyskujte svoje nuansy spojené s jedinečnými vlastnosťami spoločnosti - obchodné aj krajiny. Preto sa dúfa, že architektúra poskytne "dodávateľ", ktorý poskytuje riešenie trochu vyskočí. Architektúra takýchto systémov často "dozrieva" v rámci samotnej organizácie. Buď tvorená špecialistami Dodávateľskej spoločnosti, ktorá je hlavným umelcom projektu.

Dátový sklad je integračný projekt.

Dátové sklady na stiahnutie a spracováva informácie z mnohých zdrojových systémov. A aby sa s nimi udržali "priateľské vzťahy", musíte im byť veľmi opatrní. Vrátane, je potrebné minimalizovať zaťaženie systému zdrojov, vziať do úvahy "prístupnosť a nedostupnosť", vyberte rozhrania interakcie, pričom zohľadní ich architektúra atď. Potom úložisko bude mať schopnosť prijať dáta čo najskôr a s požadovanou frekvenciou. V opačnom prípade budete "transplantovaný" na rezervný obrys, ktorý nie je aktualizovaný s najvýznamnejšou periodicitou.
Okrem toho je potrebné vziať do úvahy "ľudský faktor". Integrácia nie je len interakciou strojov. Toto sú tiež komunikácie medzi ľuďmi.

Dátový sklad je kolektívny projekt.

Vo veľkej spoločnosti je takýto systém zriedka vykonaný silkami výlučne jediného príkazu. V pravidle tu pracuje niekoľko tímov, z ktorých každý rieši určitú úlohu.

Architektúra by mala poskytnúť schopnosť organizovať svoju paralelnú prácu a zároveň udržiavať jej integritu a zabrániť duplicite rovnakého funkčného na rôznych miestach, rôznym ľuďom. Okrem zbytočnej práce môže takáto duplikácia následne viesť k nezrovnalostiam v údajoch.

Okrem toho, keď je takýto mnoho ľudí a tímov a tímov zapojený do systému rozvoja systému, často otázka, ako budovať komunikáciu a informačnú interakciu medzi nimi. Čím štandardnejšie a zrozumiteľné prístupy a postupy sa používajú - to jednoduchšie je vhodnejšie a efektívnejšie vytvoriť takúto prácu. A vrátane to stojí za to premýšľať o zložení "pracovníkov artefaktov", medzi ktorými sú dátové modely pre dátové sklady č. 1 (pozri predchádzajúcu časť).

Dátový sklad má dlhšiu životnosť v porovnaní s inými systémami.

Budem objasniť - vyhlásenie je pravdivé pre "Živé", pracovné skladovanie, integrované s kľúčovými zdrojmi s historickými údajmi a poskytovaním informácií a analytických služieb mnohými divíziami spoločnosti.

Aké sú moje základy, aby ste predpokladali?
Po prvé, budovanie úložiska je veľmi nákladový proces: Okrem nákladov na vybavenie, licencie na potrebný technologický softvér a rozvoj, takmer všetky systémy a divízie spoločnosti sú tiež zapojené. Opakujte celý proces od nuly znova - to je veľmi tučný otvor.

Po druhé, ak má skladovanie správnu architektúru, môže ľahko prežiť a zmeniť zdrojové systémy a vznik nových požiadaviek od koncových užívateľov a rast objemu dát.
Ak je architektúra správna, informačné toky sú transparentné - potom takýto systém môže byť vyvinuté dostatočne vyvinuté na to, aby sa vyvinulo bez rizika v situácii Slory, keď sa zmení z dôvodu ťažkostí s posúdením vplyvu.

Postupný iteratívny rozvoj

Posledná vec, ktorú by som chcel, aby zákazník, ktorý im bol uvarený v histórii s uskladnením, je zmraziť svoje požiadavky na rok alebo iný, kým úplný model firemných dát je navrhnutý, všetky zdroje sú spojené v plnej výške atď.

Dátový sklad v očiach zákazníkov často vyzerá ako absolútne monštrum - taký objem úloh, ciele a horizont systému rozvoja systému. A často sa zákazník obáva, že "Vzhľadom k jeho rozpočtu" bude jednotka IT vyriešená niektorými "jeho úlohami". A opäť sme čelia otázke interakcie medzi ľuďmi a schopnosťou pokojne vyjadriť svoju pozíciu a rokovať.

Príslušné architektonické prístupy umožňujú rozvíjať systém iteratívne, postupne zvyšovať funkčnosť, bez toho, aby sa dosiahol do "vývoja" niekoľko rokov pred začatím výsledku.

Aj keď treba poznamenať, že "zázraky sa nestane" - a čas na "štart" tiež potrebujú čas. Pre skladovanie je dosť veľké - pretože tieto sú veľké množstvá údajov, to sú historické údaje za starých období, keď sa pravidlá spracovania informácií môžu líšiť od súčasných. Preto si vyžaduje dostatok času na analytické spracovanie, interakciu so zdrojovými systémami a radom "vzoriek a chýb", vrátane záťažových testov reálnych dát.

Dátový sklad - Multi-Project Story

Pre dátový sklad je ťažké zdôrazniť jedného obchodného zákazníka. A predpokladá sa, že (nie bez rozumu), že kľúčovým faktorom úspechu projektu výstavby úložiska je podpora vedenia spoločnosti - priamo prvá osoba.
Úložisko je zriedka postavené a vyvinuté v rámci jedného projektu. Tam je spravidla rôzne potreby pre konsolidáciu údajov a analytics, majú rôznymi zákazníkmi a skupinami užívateľov. Z tohto dôvodu, archív sa často vyvíja v niekoľkých projektoch paralelného behu.

Rovnováha inovácií a osvedčených rozhodnutí

Napriek tomu, že téma úložiska je veľmi "staroveká" (ak je takéto slovo uplatniteľné pre takýto mladý priemysel, ako to) a celkom konzervatívne. Avšak, pokrok nepretržite - a tie obmedzenia, ktoré predtým existovali z dôvodu drahých a pomalých diskov, drahých pamäte atď. - Teraz odstránené. Zároveň je čas revidovať niektoré architektonické prístupy. Okrem toho to odkazuje na technologické platformy a architektúru aplikovaných systémov, ktoré sú na nich založené.

Je dôležité zachovať rovnováhu - a udržať dostatok prístupu k ekologickým prístupom k zdrojom a uloženým informáciám. V opačnom prípade môžete veľmi rýchlo otočiť úložisko do nízko odolného "odpadu", v ktorom, ak sa dá chápať, potom pomerne veľké úsilie.
Áno, máme viac príležitostí, ale to neznamená, že je potrebné popierať všetky problémové a osvedčené praktiky, ktoré sú jasné, ako a prečo používať, a "začať vo všetkých hroboch" len poháňané inováciami hmlého ducha ".
Dodržiavajte rovnováhu - to znamená použiť nové metódy a prístupy, kde otvárajú nové príležitosti, ale zároveň používajú staré osvedčené - na vyriešenie urgentných úloh, ktoré nikto nezruší.
Čo môžeme robiť ako vývojári a dizajnérov aplikovaných riešení? Po prvé, poznať a pochopiť technologické zmeny v platformách, na ktorých pracujeme, ich schopnosti, funkcie a hranice aplikácie.

Pozrime sa na DBMS - ako najkritickejšiu a dôležitú technologickú platformu.
Nedávno sa databázy vymazania vytvorené pôvodne ako "univerzálne", v smere špecializácie. Dlhé popredné predajcovia produkujú rôzne možnosti - pre rôzne aplikácie triedy (OLTP, DSS & DWH). Okrem toho sa zdá, že ďalšie príležitosti pracujú s textom, geo-dátmi atď.

To však nie je obmedzené na to, výrobky boli pôvodne zamerané na určitú triedu úloh - t.j. Špecializované DBMS. Môžu použiť relačný model a nesmú. Je dôležité, aby boli pôvodne "ostré" nielen na ukladanie a spracovanie "obchodných informácií" vo všeobecnosti, ale za určitých úloh.

Zdá sa, že centralizácia a špecializácia sú dva komplementárne trendy, ktoré si pravidelne nahrádzajú, zabezpečujú rozvoj a rovnováhu. Ako aj evolučné (postupné) postupné vývojové a kardinálne zmeny. Takže v 90. rokoch bol Michael Stunbreaker jedným z autorov generácie databázy Manifestá III, v ktorej sa myšlienka jasne znelo, že svet nepotrebuje ďalšiu revolúciu vo svetových databázach. Avšak, po 10 rokoch, zverejňuje prácu, v ktorej sú predpoklady za začiatok novej éry vo svete DBMS práve na základe ich špecializácie.
Zameriava sa na skutočnosť, že spoločné univerzálne DBMS sú postavené na "bezrozmernej" architektúre, ktorá neberie do úvahy žiadne zmeny v hardvérových platformách, ani oddelenie aplikácií do tried, pre ktoré môžete prísť s optimálnym riešením, než si uvedomiť Univerzálne požiadavky.
A začína rozvíjať množstvo projektov v súlade s touto myšlienkou. Jedným z nich je C-Store - stĺpec DBMS navrhnuté v zdieľanej Nič architektúre (SN), pôvodne vytvorené špeciálne pre systémy triedy Skladovania dát. Ďalej tento produkt dostal komerčný vývoj ako HP Vertica.

Zdá sa, že teraz je témou vývoja dátového skladovania sér na nové kolo vývoja. Zobrazia sa nové technológie, prístupy a nástroje. Ich štúdia, schválenie a primerané použitie nám umožňuje vytvoriť naozaj zaujímavé a užitočné riešenia. A priviesť ich do úvodu, teší sa, že váš vývoj sa používa v reálnej práci a prospechu.

Epilóg

Pri príprave tohto článku som sa snažil najprv navigovať na architektoch, analytikoch a vývojároch, ktorí priamo pracujú s dátovými skladmi. Ukázalo sa však, že nevyhnutne "prevzal tému trochu širšie" - a iné kategórie čitateľov narazili na pohľad. Niektoré chvíle sa zdajú byť kontroverzné, niektoré nie sú jasné, niektoré sú zrejmé. Ľudia sú odlišní - s rôznymi skúsenosťami, bekground a pozíciou.
Napríklad typické otázky manažérov - "Kedy prilákať architektov?", "Keď sa musíte zaoberať architektúrou?", "Architektúra by to nebolo príliš drahé?" Znie to pre nás (vývojári, dizajnéri) sú celkom podivné, pretože pre nás sa architektúra systému objaví s jej narodením - nezáleží na tom, ale uvedomujeme si to, alebo nie. A aj keď v projekte neexistuje formálna úloha architekt, normálny vývojár vždy "zahŕňa svoj vnútorný architekt."

Podľa veľkého účtu nezáleží na tom, kto presne pôsobí ako architekt - je dôležité, aby niekto kladie tieto otázky a preskúma odpovede na ne. Ak je architekt jasne pridelený - to znamená, že zodpovednosť za systém a jej rozvoj, predovšetkým on.
Prečo som hľadal tému "Anti-Libbility" relevantnú voči tejto téme?

"Jedinečnosť proti statku je, že nám umožňuje pracovať s neznámami, urobte niečo v podmienkach, keď nechápeme, čo presne robíme, - a hľadať úspech" / Nasim N. Tabuľka /

Preto kríza a vysoký stupeň neistoty nie je ospravedlnenie pre nedostatok architektúry, ale faktory, ktoré zvyšujú jeho potrebu.

Zaitsev S.L., K.F.-M.N.

Opakovacie skupiny

Opakovacie skupiny sú atribúty, pre ktoré môže mať jediná inštancia subjektu viac ako jednu hodnotu. Napríklad osoba môže mať viac ako jednu zručnosť. Ak, pokiaľ ide o obchodné požiadavky, potrebujeme poznať úroveň vlastníctva zručnosti pre každého, a každý človek môže mať len dve zručnosti, môžeme vytvoriť podstatu znázornenú na obr. 1.6. Tu je v podstate prítomný OSOBAs dvoma atribútmi na ukladanie zručností a úrovne zručností pre každého.

Obr. 1.6. Tento príklad používa opakované skupiny.

Problém opakovaných skupín je, že presne nemôžeme vedieť, koľko zručností môže mať osobu. V reálnom živote majú niektorí ľudia jednu zručnosť, niektoré majú niekoľko, a niektorí ešte nie. Obrázok 1.7 ukazuje model uvedený v prvej normálnej forme. Venovať pozornosť pridaniu Identifikátor zručností ktoré jednoznačne určujú Zručnosti.

Obr. 1.7. Model uvedený na prvú normálnu formu.

Jedna skutočnosť na jednom mieste

Ak je rovnaký atribút prítomný vo viac ako jednej entite a nie je externým kľúčom, potom sa tento atribút považuje za prebytok. Logický model by nemal obsahovať redundantné údaje.

Redundancia vyžaduje dodatočný priestor, aj keď je dôležitý účinnosť používania pamäte, skutočný problém je iný. Zaručená synchronizácia redundantných údajov vyžaduje nad hlavou a vždy pracujete v riziku hodnoty konfliktu.

V predchádzajúcom príklade Zručnosťzáleží na Identifikátor osobya od Identifikátor.To znamená, že sa nezobrazí Zručnosťkým sa nezobrazí OSOBA,vlastniť túto zručnosť. Taktiež komplikuje zmenu v mene zručnosti. Je potrebné nájsť každý záznam s názvom zručnosti a zmeniť ho pre každého človeka, ktorý vlastní túto zručnosť.

Obrázok 1.8 zobrazuje model v druhej normálnej forme. Všimnite si, že je pridaná podstata. Zručnosťa atribút NÁZOVzručnosti sa presťahoval k tejto entite. Úroveň zručností zostala na križovatke Osoby a zručnosti.

Obr. 1.8. V druhej normálnej forme sa opakujúca skupina vloží do inej entity. To poskytuje flexibilitu pri pridávaní požadovaného množstva zručností a zmení meno zručnosti alebo opis zručnosti na jednom mieste.

Každý atribút závisí od kľúča

Každý atribút entity by mal závisieť od primárneho kľúča tohto subjektu. V predchádzajúcom príklade Meno školya Geografická oblasťprítomný v tabuľke OSOBAAle neopisujte osobu. Aby ste dosiahli tretiu normálnu formu, musíte posunúť atribúty v podstate, kde budú závisieť od kľúča. Obrázok 1.9. Zobrazuje model v tretej normálnej forme.

Obr. 1.9. V tretej normálnej forme Meno školy a Geografická oblasť prevedené do podstaty, kde ich hodnoty závisia od kľúča.

Mnoho-mnoho vzťahov

Vzťah mnoho-spoluodrážajú realitu okolitého sveta. Upozorňujeme, že na obrázku 1.9 existuje pomer mnohých-to-mnohých Osobaa Škola. Postoj presne odráža skutočnosť, že OSOBAsa môže učiť v mnohých Školské školya B. Školasa môže naučiť veľa Osoby.Asociatívna podstata je vytvorená na dosiahnutie štvrtej normálnej formy, ktorá eliminuje vzťah monogy-to-mnohých z dôvodu vytvorenia samostatného vstupu pre každú jedinečnú kombináciu školy a osoby. Obrázok 1.10 zobrazuje model vo štvrtej normálnej forme.

Obr. 1.10. Vo štvrtej normálnej forme sa vzťah medzi monogátom-spolu-mnohými Osoba a Školaje povolené zavedením asociatívneho subjektu, v ktorom je pre každú jedinečnú kombináciu pridelené samostatný záznam. Školské školy a Osoby.

Formálne definície normálnych formulárov

Nasledujúce definície normálnych foriem sa môžu zdať zastrašujúce. Zvážte ich jednoducho ako vzorce na dosiahnutie normalizácie. Normálne formy sú založené na relačnom algebre a môžu byť interpretované ako matematické transformácie. Hoci táto kniha nie je venovaná podrobnej diskusii o normálnych formách, modely vývojári sa odporúča podrobnejšie študovať túto otázku.

V zadanom pomere závisí atribút Y funkčne závisí od atribútu x. V znakovom formulári RX -\u003e RY (čítať ako "RX funkčne definuje RY") - v tom, a len vtedy, ak je každá hodnota x v R je spojená striktne s jednou hodnotou y r (v každom konkrétnom čase). Atribúty X a Y môžu byť kompozitné (Dátum K. J. Úvod do databázových systémov. 6. vydanie. Ed. Williams: 1999, 848 p.)

Pomer R zodpovedá prvej normálnej forme (1NF), ak a len ak všetky domény patriace do nej obsahujú iba atómové hodnoty (diéta, ibid).

Pomer krysu zodpovedá druhej normálnej forme (2NF), ak a len ak zodpovedá 1NF, a každý pevný atribút úplne závisí od primárneho kľúča (diéta, ibid).

Pomer R zodpovedá tretej normálnej forme (3NF), ak a len vtedy, ak zodpovedá 2NF, a každý neutrálny atribút nie je závisieť od primárneho kľúča (dátum, ibid).

Pomer R zodpovedá normálnej forme chlapcov-CODD (BCNF), ak je len vtedy, ak je každý determinant kandidát na použitie ako kľúč.

POZNÁMKA Nižšie je stručné vysvetlenie niektorých skratiek používaných v definíciách dátumu.

MVD (viacúčená závislosť) - Viacnásobná závislosť. Používa len pre subjekty s tromi a ďalšími atribútmi. S viacnásobnými závislosťami, hodnota atribútu závisí len na časti primárneho kľúča.

FD (funkčná závislosť) - funkčná závislosť. S funkčnou závislosťou, hodnota atribútu závisí od hodnoty iného atribútu, ktorý nie je súčasťou primárneho kľúča.

JD (pripojiť závislosť) - závislosť na zjednotenie. So závislosťou Únie môže byť primárny kľúč materskej jednotky vysledovať na potomkov aspoň tretiu úroveň, pričom sa zachová schopnosť používať v Únii zdrojovým kľúčom.

Pomer zodpovedá štvrtej normálnej forme (4NF), ak a len vtedy, ak sú napríklad MVD, napríklad A®®B. V tomto prípade všetky atribúty r funkčne závisia od A. Inými slovami, je prítomná iba závislosť (FD alebo MVD) formy K®X (tj funkčná závislosť x atribútu z kandidáta na použitie ako K) . V súlade s tým, R spĺňa požiadavky 4NF, ak zodpovedá BCNF a všetky MVD je vlastne FD (Diéta, ibid.).

Pre piaty normálnu formu, pomer R spĺňa závislosti kombinácie (JD) * (x, y, ..., z), ak je R je ekvivalentná svojimi projekciami na X, Y, ..., Z , kde x, y, .., Z podskupiny súborov atribútov R.

Existuje mnoho ďalších normálnych foriem pre komplexné typy údajov a špecifické situácie, ktoré presahujú našu diskusiu. Každý nadšenec modelov je žiaduci na štúdium iných normálnych foriem.

Obchodné normálne formuláre

Vo vašej knihe, Clive Finklestein (Finklestein Cl. Úvod do informačného inžinierstva: od strategického plánovania na informačné systémy. Čítanie, Massachusetts: Addison-Wesley, 1989) Aplikoval iný prístup k normalizácii. Definuje obchodné normálne formuláre, pokiaľ ide o prinášanie týchto formulárov. Mnohé vývojári modelov považujú tento prístup intuitívne jasnejší a pragmatický.

Prvá normálna forma podnikania (1BNF) robí opakované skupiny iným subjektom. Tento subjekt dostane vlastné meno a primárne (kompozitné) kľúčové atribúty z počiatočnej podstaty a jeho opakujúcej sa skupiny.

Druhá obchodná forma (2BNF) robí atribúty, ktoré čiastočne závisia od primárneho kľúča k inej entite. Primárny (kompozitný) Kľúčom kľúča tohto subjektu je primárnym kľúčom esencie, v ktorom bola pôvodne umiestnená, spolu s ďalšími kľúčmi, z ktorých atribút závisí úplne.

Tretia obchodná štandardná forma (3BNF) robí atribúty, ktoré sú nezávislé od primárneho kľúča, iným subjektom, kde sú úplne závislé od primárneho kľúča tohto subjektu.

Štvrtý obchodný formulár (4BNF) robí atribúty, ktoré závisia od hodnoty primárneho kľúča alebo sú voliteľné, do sekundárnej podstaty, kde sú úplne závislé od primárnej kľúčovej hodnoty alebo kde by mali byť prítomné v tomto subjeku .

Piaty podniková normálna forma (5BNF) sa prejavuje ako štrukturálna podstata, ak existuje rekurzívna alebo iná závislosť medzi kópiami sekundárneho subjektu, alebo ak existuje rekurzívna závislosť medzi inštanciami jeho primárnej podstaty.

Dokončený model Logic Data

Dokončený logický model musí spĺňať požiadavky tretej obchodnej formy a zahŕňajú všetky subjekty, atribúty a komunikácie potrebné na podporu požiadaviek na údaje a obchodné pravidlá spojené s údajmi.

Všetky subjekty musia mať mená popisujúce obsah a čistý, krátky, úplný opis alebo definíciu. Jedna z nasledujúcich publikácií zváži pôvodný súbor odporúčaní pre správnu tvorbu mien a opisov subjektov.

Essences musia mať kompletnú sadu atribútov, takže každá skutočnosť vo vzťahu k každému subjektu môže byť reprezentovaná jeho atribútmi. Každý atribút musí mať názov odrážajúce jeho hodnoty, logický typ údajov a jasný, krátky, úplný opis alebo definíciu. V jednom z nasledujúcich publikácií zvážime zdrojový súbor odporúčaní pre správnu tvorbu mien a opisov atribútov.

Komunikácia by mala zahŕňať slovesný dizajn, ktorý opisuje vzťah medzi subjektmi, spolu s takýmito vlastnosťami ako multiplicity, potreba existencie alebo možnosť nedostatku komunikácie.

POZNÁMKA Násobný Komunikácia opisuje maximálny počet kópií sekundárneho subjektu, ktorý môže byť spojený s inštanciou pôvodného subjektu.Potreba existencie alebomožnosť neprítomnosti Komunikácia slúži na určenie minimálneho počtu kópií sekundárneho subjektu, ktorý môže byť spojený s inštanciou počiatočného subjektu.

Model fyzického dát

Po vytvorení kompletného a primeraného logického modelu ste pripravení rozhodnúť o výbere implementačnej platformy. Výber platformy závisí od požiadaviek na využívanie údajov a strategických zásad pre tvorbu architektúry spoločnosti. Voľba platformy je náročný problém, ktorý presahuje rámec tejto knihy.

V Erwin je fyzickým modelom grafickým znázornením skutočne implementovanej databázy. Fyzická databáza bude pozostávať z tabuliek, stĺpcov a pripojení. Fyzický model závisí od platformy vybranej na implementáciu a požiadavky na používanie údajov. Fyzický model IMS sa bude vážne líšiť od rovnakého modelu pre SYBASE. Fyzický model pre správy OLAP bude vyzerať inak ako model pre OLTP (operačné spracovanie transakcií).

Dátový model Developer a administrátor databáz (administrátor databázy DBA) Použite logický model, požiadavky zákazníkov a strategické princípy pre vytvorenie architektúry spoločnosti na vytvorenie fyzického dátového modelu. Môžete denormalizovať fyzický model na zlepšenie výkonu a vytvoriť zobrazenia na podporu vlastných požiadaviek. V nasledujúcich častiach sa proces denormalizácie a tvorby prezentácie považuje za podrobnejšie.

Táto časť poskytuje prehľad procesu budovania fyzického modelu, zberu údajov o dátach sa udeľuje stanovenie zložiek fyzického modelu a reverzného dizajnu. V nasledujúcich publikáciách sú tieto otázky zahrnuté podrobnejšie.

Vyberanie požiadaviek na údaje

Zvyčajne zbierate požiadavky na používanie údajov v skorých štádiách počas rozhovorov a pracovných stretnutí. Súčasne by sa požiadavky najviac určili používanie údajov užívateľom. Povrchový postoj a lakuna vo fyzickom modeli môže viesť k neplánovaným nákladom a oneskorenia načasovania realizácie projektu. Požiadavky na použitie zahŕňajú:

Požiadavky na prístup a výkonnosť

Volumenické charakteristiky (hodnotenie množstva údajov, ktoré sa majú uložiť), ktoré umožňujú správcovi predložiť fyzickú databázu

Posúdenie počtu používateľov, ktorí potrebujú súčasný prístup k údajom, ktoré vám pomôžu navrhnúť databázu, pričom zohľadní prijateľnú úroveň výkonu

Celkové, súhrnné a iné vypočítané alebo derivátové údaje, ktoré možno považovať za kandidátov na skladovanie v dlhodobých dátových štruktúrach

Požiadavky na vytvorenie správ a štandardných dotazov, ktoré pomáhajú správcovi databázy, aby vytvorili indexy

Prezentácie (dlhodobé alebo virtuálne), ktoré pomôžu užívateľovi pri vykonávaní operácií kombinovania alebo filtrovania údajov.

Okrem predsedu, tajomníka a používateľov v relácii o požiadavkách na používanie, vývojár modelu, administrátora databázy a databázový architekt. Diskusia musí podliehať užívateľovi historické údaje. Trvanie časového obdobia, počas ktorého sú údaje uložené, má významný vplyv na veľkosť databázy. Staršie údaje sa často uchovávajú vo všeobecnosti a atómové údaje sú archivované alebo odstránené.

Používatelia by mali priviesť s vami na príklady relácií požiadaviek a správ. Správy musia byť prísne definované a mali by obsahovať atómové hodnoty používané pre všetky celkové a súhrnné polia.

Komponenty modelu fyzického dát

Komponenty fyzikálneho dátového modelu sú tabuľky, stĺpy a vzťahy. Podstatou logického modelu sa pravdepodobne stane tabuľkami vo fyzickom modeli. Logické atribúty sa stanú stĺpcami. Logické vzťahy sa stanú obmedzením integrity vzťahov. Niektoré logické vzťah nie je možné implementovať vo fyzickej databáze.

Reverzný dizajn

Keď logický model nie je k dispozícii, je potrebné obnoviť model z existujúcej databázy. V Erwine sa tento proces nazýva reverzný dizajn. Reverzný dizajn môže byť vykonaný niekoľkými spôsobmi. Vývojár modelu môže preskúmať dátové štruktúry v databáze a obnoviť tabuľky v prostredí vizuálnej simulácie. Jazyk popisu dát môžete importovať (jazyk DDL - DATA DIFIKÁLY) na nástroj, ktorý podporuje reverzný dizajn (napríklad Erwin). Vyvinuté nástroje, ako napríklad Erwin, zahŕňajú funkcie, ktoré poskytujú komunikáciu prostredníctvom ODBC s existujúcou databázou, na vytvorenie modelu pomocou priamych dátových štruktúr. Reverzný dizajn pomocou ERWIN bude podrobne diskutovaný v jednej z nasledujúcich publikácií.

Použitie firemných funkčných hraníc

Pri budovaní logického modelu pre model developera, je dôležité zabezpečiť, aby nový model zodpovedá spoločnosti Corporate. Využívanie firemných funkčných hraníc znamená modelovanie údajov, ktoré sa používajú v rámci spoločnosti. Spôsob použitia údajov v spoločnosti sa líši rýchlejšie ako samotné údaje. V každom logickom modeli by sa údaje mali prezentovať integritu bez ohľadu na oblasť predmetu podnikania, ktorú podporuje. Essencie, atribúty a vzťahy by mali definovať obchodné pravidlá na úrovni korporácie.

POZNÁMKA Niektorí z mojich kolegov nazývajú tieto firemné funkčné hranice v reálnom svete modelovania. Modelovanie reálneho sveta povzbudzuje vývojára modelu, aby zvážila informácie z hľadiska vzťahov a vzťahov, ktoré v ňom skutočne neodmyslite.

Používanie firemných funkčných hraníc pre dátový model, ktorý je postavený podľa toho, poskytuje základ pre podporu informačných potrieb akéhokoľvek počtu procesov a aplikácií, čo umožňuje efektívne využívať jeden z jeho najcennejších aktív - informácií.

Čo je firemný dátový model?

Corporate Data Model (EDM - Enterprise Data Model)obsahuje esencie, atribúty a vzťahy, ktoré predstavujú informačné potreby spoločnosti. EDM je zvyčajne rozdelený do dodržiavania predmetov, ktoré predstavujú skupiny subjektov patriacich k podpore špecifických obchodných potrieb. Niektoré predmety môžu pokryť takéto špecifické obchodné funkcie ako riadenie zmlúv, iné - kombinované subjekty opisujúce výrobky alebo služby.

Každý logický model musí spĺňať existujúcu oblasť predmetu modelu firemného dátového modelu. Ak logický model nie je v súlade s touto požiadavkou, mal by sa k nemu pridať model určujúci predmet oblasti. Toto porovnanie zabezpečuje, že model firemného modelu sa zlepšil alebo upraví a v rámci spoločnosti sú koordinované všetky úsilie na logickom modelovaní.

EDM.zahŕňa aj špecifické subjekty, ktoré určujú rozsah definície hodnôt pre kľúčové atribúty. Tieto subjekty nemajú rodičov a sú definované ako nezávislé. Nezávislé subjekty sa často používajú na udržanie integrity vzťahu. Tieto subjekty sú identifikované niekoľkými rôznymi názvami, ako sú kódové tabuľky, referenčné tabuľky, tabuľky typu alebo klasifikačné tabuľky. Budeme používať termín "firemný obchodný objekt". Podnikateľský objekt je subjekt, ktorý obsahuje súbor hodnôt atribútov, ktoré nezávisia od iného subjektu. Podnikové obchodné objekty v rámci korporácie by sa mali používať jednotne.

Budovanie firemného dátového modelu rozšírením

Existujú organizácie, v ktorých bol firemný model od začiatku skončiť, bol postavený v dôsledku jednotného dohodnutého úsilia. Na druhej strane väčšina organizácií vytvára pomerne kompletné firemné modely zvýšením.

Budova znamená stavbu niečo dôsledne, vrstva za vrstvou, rovnako ako ustrice rastie perlu. Každý vytvorený dátový model zabezpečuje príspevok k tvorbe EDM. Budovanie EDM v tejto metóde si vyžaduje ďalšie modelové akcie na pridanie nových dátových štruktúr a predmetových oblastí alebo rozšíriť existujúce dátové štruktúry. To umožňuje vybudovať firemný dátový model budovou, iteratívne pridávanie úrovní detailu a rafinovanie.

Koncepcia metodiky modelovania

Existuje niekoľko metodík pre modelovanie vizuálneho dát. Erwin podporuje dve:

IDEF1X (Definícia integrácie pre modelovanie informácií je integrovaný opis informačných modelov).

IE (Informačné inžinierstvo - Informačné inžinierstvo).

IDEF1X - Dobrá metodika a používanie jej notácie je rozšírená

Integrovaný opis informačných modelov

IDEF1x- vysoko štruktúrovaná metodika modelovania dát, ktorá rozširuje metodiku IDEF1 prijatého ako štandard FIPS (Federálne štandardy spracovania informácií sú štandardy spracovania federálnych informácií). IDEF1x využíva striktne štruktúrovaný súbor typov typov modelových návrhov a vedie k dátovému modelu, ktorý si vyžaduje pochopenie fyzickej povahy údajov predtým, ako môžu byť takéto informácie prístupné.

Tvrdá štruktúra IDEF1x núti vývojára modelu, aby predpísal subjekty vlastností, ktoré nemusia byť zodpovedné za reality sveta. Napríklad IDEF1x vyžaduje, aby všetky podtypy subjektov boli exkluzívne. To vedie k tomu, že osoba nemôže byť súčasne klientom a zamestnancom. Kým nám skutočná prax hovorí iná.

Informačné inžinierstvo

Clive Finkleshtein sa často označuje ako otec informačného inžinierstva, aj keď podobné koncepty spolu s ním a James Martin (Martin, James. Riadenie databázového prostredia. Horné sedlo River, New Jersey: Prentice Hall, 1983.). Informačné inžinierstvo využíva prístup k riadeniu podniku na riadenie informácií a uplatňuje inú zápis na predloženie obchodných pravidiel. IE slúži ako expanzia a rozvoj notácie a základných pojmov metodiky ER navrhla Peter Chen.

IE poskytuje infraštruktúru podpory informácií integráciou firemného strategického plánovania s informačnými systémami. Takáto integrácia vám umožňuje viac spájať správu informačných zdrojov s dlhodobými strategickými perspektívami korporácie. Tento prístup zaslaný požiadavkám podniku vedie mnoho modelov vývojárov na výber, tj namiesto iných metodík, ktoré sa zameriavajú najmä na riešenie úloh hybnosti.

IE ponúka postupnosť činností, ktoré vedú k korpoácii definovať všetky svoje informačné potreby na zhromažďovanie a správu údajov a identifikovať prepojenia medzi informačnými zariadeniami. Výsledkom je, že požiadavky na informácie sú jasne formulované na základe smerníc o riadení a môžu byť priamo preložené do informačného systému riadenia, ktorý bude podporovať strategické informačné potreby.

Záver

Pochopenie toho, ako používať nástroj modelovania dát podobný erwin je len časť problému. Okrem toho musíte pochopiť, keď sú riešené úlohy modelovania dát a ako sa zhromažďujú požiadavky na informačné a obchodné pravidlá, ktoré musia byť uvedené v modeli údajov. Vedúci pracovné stretnutia poskytuje najpriaznivejšie podmienky pre zber informácií o informáciách v médiu vrátane odborníkov z oblasti, používateľov a špecialistov v oblasti informačných technológií.

Na vybudovanie dobrého dátového modelu sa vyžaduje požiadavky na analýzu a výskum informácií a obchodných pravidiel zozbieraných počas pracovných stretnutí a rozhovorov. Výsledný dátový model sa musí porovnať s firemným modelom, ak je to možné, aby sa zabezpečilo, že nie je v rozpore s existujúcimi modelmi objektov a zahŕňa všetky potrebné objekty.

Dátový model sa skladá z logických a fyzických modelov zobrazujúcich informačné a obchodné pravidlá. Logický model musí byť uvedený tretej normálnej forme. Tretie normálne limity formulárov pridáva, aktualizuje a odstraňuje abnormálne dátové štruktúry na podporu "jednej skutočnosti na jednom mieste". Zozbierané požiadavky na informačné a obchodné pravidlá sa musia analyzovať a skúmať. Musia byť porovnané s firemným modelom, aby sa zabezpečilo, že nie sú v rozpore s existujúcimi modelmi objektov a zahŕňajú všetky potrebné objekty.

Dátový model ERWIN obsahuje logické aj fyzické modely. Erwin implementuje prístup ER a umožňuje vytvárať logické a fyzikálne modely objekty na prezentáciu požiadaviek na informácie a obchodné pravidlá. Logické modelové objekty zahŕňajú entity, atribúty a vzťahy. Objekty fyzického modelu zahŕňajú tabuľky, stĺpce a obmedzenia týkajúce sa integrity vzťahov.

V jednom z nasledujúcich publikácií, otázky identifikácie subjektov, identifikovať typy entít, výber subjektov a opisov, ako aj niektoré techniky, ktoré sa vyhýbajú najbežnejším chybám modelovania spojených s používaním subjektov.

Essences musia mať kompletnú sadu atribútov, takže každá skutočnosť vo vzťahu k každému subjektu môže byť reprezentovaná jeho atribútmi. Každý atribút musí mať názov odrážajúce jeho hodnoty, logický typ údajov a jasný, krátky, úplný opis alebo definíciu. V jednom z nasledujúcich publikácií zvážime zdrojový súbor odporúčaní pre správnu tvorbu mien a opisov atribútov. Komunikácia by mala zahŕňať slovesný dizajn, ktorý opisuje vzťah medzi subjektmi, spolu s takýmito vlastnosťami ako multiplicity, potreba existencie alebo možnosť nedostatku komunikácie.

POZNÁMKA Násobný komunikácia opisuje maximálny počet kópií sekundárneho subjektu, ktorý môže byť spojený s inštanciou pôvodného subjektu.Potreba existencie alebo neprítomnosti komunikácia slúži na určenie minimálneho počtu kópií sekundárneho subjektu, ktorý môže byť spojený s inštanciou originálu

Špecialisti sa čoraz viac snažia o svoju pozornosť riešením správy dát založených na štandardných sektorových dátových modeloch a šablónach obchodných riešení. Pripravené komplexné komplexné fyzikálne dátové modely a správy obchodných analytikov pre špecifické oblasti činnosti nám umožňujú zjednotiť informácie o činnostiach podniku a výrazne urýchliť implementáciu obchodných procesov. Rozhodovanie Šablóny umožňujú poskytovateľom služieb používať neštandardné informačné možnosti ukryté v existujúcich systémoch, čím sa znižujú projekty, náklady a riziká. S reálnymi projektmi ukazujú napríklad, že vzory dátového modelu a obchodných riešení môžu znížiť objem nákladov práce pre rozvoj o 50%.

Sektorový logický model je objektovo orientovaná, integrovaná a logicky štruktúrovaná prezentácia všetkých informácií, ktoré by mali byť v podnikovej dátovej skladu získať odpovede na strategické aj taktické obchodné otázky. Hlavným účelom modelov je uľahčiť orientáciu v dátovom priestore a pomoc pri prideľovaní častí dôležitých pre rozvoj podnikania. V moderných podmienkach, aby úspešne vykonávať podnikať, je absolútne nevyhnutné mať jasné pochopenie vzťahu medzi rôznymi komponentmi a je dobré si predstavovať celkový obraz organizácie. Identifikácia všetkých častí a pripojení pomocou modelov vám umožňuje najefektívnejšie využívať čas a nástroje na organizáciu práce spoločnosti.

Pod dátovými modelmi, abstraktné modely opisujúce, ako sa porozumejú reprezentovať dát a prístup k nim. Dátové modely definujú dátové prvky a prepojenia medzi nimi v konkrétnej oblasti. Dátový model je navigačným nástrojom pre podnikanie a pre IT profesionálov, ktorý používa špecifický súbor znakov a slov, aby presne vysvetlila určitú triedu reálnych informácií. To vám umožní zlepšiť vzájomné porozumenie v rámci organizácie, a teda vytvoriť flexibilnejšie a stabilné prostredie pre aplikácie.

Príkladom modelu GIS pre orgány a miestne samosprávy.

Dnes sú poskytovatelia softvéru a služieb strategicky dôležité, aby mohli rýchlo reagovať na zmeny v priemysle súvisiace s technologickými novinkami, stiahnutím štátnych obmedzení a komplikácií dodávateľských reťazcov. Spolu so zmenami v obchodnom modeli rastie zložitosť a náklady na informačné technológie potrebné na podporu aktivít spoločnosti. Najmä riadenie údajov je ťažké v prostredí, kde sa neustále menia firemné informačné systémy, ako aj funkčné a obchodné požiadavky.

Pomoc úľavu a optimalizovať tento proces, v preklade IT prístupu k modernej úrovni, sú určené modely sektorových údajov.

Priemyselné dátové modely od spoločnostiESRI.

Dátové modely pre platformu ESRI ARCGIS prevádzkujú šablóny pre použitie v projektoch GIS a vytvárajú dátové štruktúry pre rôzne oblasti aplikácií. Tvorba dátového modelu zahŕňa vytvorenie koncepčného dizajnu, logickej a fyzickej štruktúry, ktorá sa potom môže použiť na vytvorenie osobnej alebo firemnej geodatabázy. ARCGIS poskytuje nástroje na vytváranie a správu databázovej schémy a šablóny dátového modelu sa používajú na rýchle spustenie projektu GIS pre rôzne aplikácie a priemyselné odvetvia. Špeciaisti ESRI spolu s komunitou používateľov strávili značné množstvo času na vytvorenie radu šablón, ktoré môžu poskytnúť možnosť rýchleho začiatku navrhovania geodatabázy podniku. Tieto projekty sú opísané a zdokumentované na webovej stránke Support.esri.com/datamodels. Nižšie, v poradí podľa ich zmienky na tejto stránke je prezentovaný zmysluplným prekladom mená sektorových modelov ESRI:

• Adresa Registry
• poľnohospodárstvo
• Meteorológia
• Základné priestorové údaje
• Biodiverzita
• Interiérové \u200b\u200bbudovy
• Účtovníctvo pre skleníkové plyny
• Katedra administratívnych hraníc
• Ozbrojené sily. Spravodajská služba
• Energie (vrátane nového protokolu ARCGIS Multispeak)
• Environmentálne štruktúry
• Ministerstvo núdzových situácií Ohnisko
• Lesná katastra
• Lesníctvo
• Geológia
• Národná úroveň GIS (E-GOV)
• Podzemné a odpadové vody
• Zdravie
• Archeológia a ochrana pamätných miest
• Národná bezpečnosť
• Hydrológia
• Medzinárodná hydrografická organizácia (IHO). S-57 Formát pre ENC
• Zavlažovanie
• Územný register
• Obecná vláda
• Námorná navigácia
• Štátny kataster
• Olejové a plynové konštrukcie
• Potrubia
• Rastrový sklad
• BYTYMETRY, OZNÁMENIE OBCHODU PRODUKU
• Telekomunikácie
• Preprava
• Zásobovanie vodou, kanalizácie, bývanie a komunálne služby

Tieto modely obsahujú všetky potrebné známky priemyselného štandardu, a to:

• sú voľne prístupný;
• nemajú viazanie na "obľúbený" technológie výrobcu;
• v dôsledku realizácie reálnych projektov;
• s účasťou sektorových špecialistov;
• sú určené na poskytovanie interakcie informácií medzi rôznymi produktmi a technológiami;
• neporupujte iné normy a regulačné dokumenty;
• používané v implementovaných projektoch po celom svete;
• sú určené na prácu s informáciami o celom životnom cykle systému, ktorý je vytvorený, a nie samotný projekt;
• expandovateľné potreby zákazníkov bez straty kompatibility s inými projektmi a / alebo modelmi;
• sprevádzané ďalšími materiálmi a príkladmi;
• používané v metodických pokynoch a technických materiáloch rôznych priemyselných podnikov;
• veľká komunita účastníkov pri prístupe k komunite je otvorená pre všetkých;
• veľký počet odkazov na dátové modely v publikáciách v posledných rokoch.

Špecialisti ESRI sú zahrnuté v expertnej skupine nezávislých orgánov, ktorí odporúčajú používať rôzne sektorové modely, ako sú napríklad struky (potrubia otvorené dátové štandardy - otvorený štandard pre ropný a plynárenský priemysel; v súčasnosti existuje implementácia Pods ako geodatabáza ESRI PODS ESRI 5.1.1) Alebo základňa Geodatabase (BGD) z ARCGIS pre leteckú dopravu, ktorá zohľadňuje odporúčania ICAO a FAA, ako aj štandard výmeny údajov EXM 5.0 navigácie. Okrem toho existujú odporúčané modely, striktne relevantné pre existujúce sektorové normy, ako sú S-57 a ARCGI pre námorné (námorné a pobrežné objekty), ako aj modely vytvorené výsledkami dokončených odborných služieb ESRI a sú "de facto" normy vo vhodných oblastiach. Napríklad GIS pre národ a miestnu vládu ("GIS pre štátne orgány a miestne vlády") ovplyvnilo normy NSDI a inšpirujúce normy a vodnú a podzemnú vodu (hydrológia a podzemná voda) sa aktívne používajú vo voľnom cenovo dostupnom Archydro Professional balíku a komerčných produktov. Tretia Firmy. Treba poznamenať, že ESRI podporuje a "de-facto" normy, ako napríklad NHDI. Všetky navrhované dátové modely sú zdokumentované a pripravené na použitie v IT procesoch podniku. Sprievodné materiály pre modely zahŕňajú:

• UML diagramy vzťahov entity;
• dátové štruktúry, domény, referenčné knihy;
• ready Geodatabase šablóny vo formáte ARCGIS GDB;
• príklady údajov a príklady aplikácií;
• príklady dát načítavania skriptov, príklady analytických nástrojov;
• odkazy podľa navrhovanej dátovej štruktúry.

ESRI sumarizuje svoje skúsenosti so stavebnými priemyselnými modelmi vo forme kníh a lokalizuje publikované materiály. Spoločnosť ESRI CIS je lokalizovaná a boli zverejnené nasledujúce knihy:

• Geopriestorová architektúra orientovaná na služby (SAO);
• Návrh Geodatabáz na prepravu;
• Firemné geoinformačné systémy;
• GIS: Nová energia elektrických a plynových podnikov;
• Olej a plyn na digitálnej mape;
• Modelovanie nášho sveta. Riadenie ESRI na dizajne geodatabázy;
• Premýšľať o GIS. Plánovanie GIS: Príručka pre manažérov;
• Geografické informačné systémy. Základy;
• GIS pre administratívne a hospodárske riadenie;
• Web GIS. Zásady a aplikácia;
• Stratégie dizajnu systému, 26. vydanie;
• 68 Otázky časopisu Arcreview s publikáciami spoločností a systémov GIS;
• ... a mnoho ďalších tematických poznámok a publikácií.

Napríklad kniha " Modelovanie nášho sveta ..."(Preklad) je komplexný sprievodca a sprievodca pre modelovanie údajov v GIS vo všeobecnosti a najmä na dátovom modeli Geodatabázy. Kniha ukazuje, ako generovať správne riešenia modelovania dát, riešenia, ktoré sa zúčastňujú na každom aspekte GIS Projekt: Od návrhu základných údajov a zberu údajov do priestorovej analýzy a vizuálnej reprezentácie. Je podrobne opísaný, ako navrhnúť geografickú databázu, zodpovedajúci projekt, nakonfigurujte funkčnosť databázy bez programovania, kontrolovať prúd práce Komplexné projekty simuláciu rôznych sieťových štruktúr, ako je rieka, dopravu alebo elektrické siete, implementujú údaje do procesu geografickej analýzy a displeja, ako aj vytvoriť 3D dátové modely GIS. kniha " Design GeodataBases pre dopravu"Obsahuje metodické prístupy testované na veľké množstvo projektov a plne relevantné pre legislatívne požiadavky Európy a Spojených štátov, ako aj medzinárodných noriem. A v knihe" GIS: Nová energia elektrických a plynárenských podnikov"S použitím skutočných príkladov, výhody, ktoré spoločnosť Corporate GIS môže poskytnúť spoločnosť dodávateľovi energiu, vrátane aspektov, ako je zákaznícky servis, sieťová operácia a iné obchodné procesy.

Niektoré z kníh, prekladu a originálnych problémov publikovaných v ruštine ESRI CIS a dáta +. Sú ovplyvnené oboch koncepčných otázok súvisiacich s technológiou GIS a mnoho aplikovaných aspektov modelovania a nasadenia GIS iného stupnice a cieľa.

Uplatňovanie sektorových modelov zvážte v príklade bisdmového dátového modelu (budovanie interiérového vesmírneho dátového modelu, informačný model vnútorného priestoru budovy) verzia 3.0. BISDM je vývoj všeobecnejšieho modelu BIM (budovanie informačného modelu, informačného modelu budovy) a je určený na použitie v úlohách projektovania, výstavby, prevádzky a záveru z prevádzky budov a štruktúr. Používa sa v GIS, umožňuje efektívne vymeniť geodan s inými platformami a komunikovať s nimi. Vzťahuje sa na všeobecnú skupinu úloh FM (organizácia infraštruktúry organizácie). Uvádzame hlavné výhody modelu bisdm, ktorého použitie umožňuje:

• organizovať výmenu informácií v heterogénnom prostredí podľa jednotných predpisov;
• získajte "Fyzikálne" uskutočnenie koncepcie BIM a odporúčané pravidlá pre výstavbu stavebného projektu;
• udržujte jedno skladovacie zariadenie v celom životnom cykle budovy (z projektu k výstupu z prevádzky);
• koordinovať prácu rôznych odborníkov v projekte;
• vizualizovať položený kalendár plán a fázy výstavby pre všetkých účastníkov;
• uveďte predbežné posúdenie nákladov a lehôt (4D a 5D údajov);
• monitorovať pokrok projektu;
• zabezpečiť kvalitnú prevádzku budovy vrátane údržby a opravy;
• staňte sa súčasťou systému riadenia aktív, vrátane funkcií analýzy efektívnosti oblastí používania (prenájom, sklad, riadenie zamestnancov);
• vykonávať výpočet a riadenie úloh energetickej účinnosti budovy;
• upravte pohyb ľudských prúdov.

BISDM definuje pravidlá pre prácu s priestorovými údajmi na úrovni vnútorných priestorov v budove, vrátane účelu a použitia používania, položených komunikácií, inštalovaných zariadení, opravy opravy a údržby, ťažby incidentov, vzťahov s inými aktívami Spoločnosť. Model pomáha vytvoriť jedno skladovanie geografických a geografických údajov. Skúsenosti s poprednými globálnymi spoločnosťami boli použité na pridelenie subjektov a modelovanie na úrovni BGD (Geodatabase Base) priestorových a logických vzťahov všetkých fyzických prvkov, ktoré tvoria samotnú budovu a jeho vnútorné priestory. Po zásadách BISDM umožňuje výrazne zjednodušiť integračné úlohy s inými systémami. V prvej fáze to zvyčajne integruje s CAD. Potom sa počas prevádzky budovy výmena údajov používa s ERP a EAM Systems (SAP, TRIRIGA, MAXIMO, atď.).

Vizualizácia bisdm konštrukčných prvkov ARCGIS.

V prípade použitia BISDM, vlastník zákazníka / objektov prijíma prostredníctvom výmeny informácií z myšlienky vytvorenia objektu pred vývojom plnej projektu, monitorovanie výstavby s príslušnými informáciami do času uvedenia do prevádzky, kontroly parametrov počas prevádzky, \\ t A dokonca počas rekonštrukcie alebo výstupu objektu z prevádzky. Po BISDM paradigme, GIS a BGD, ktorý vytvoril, sa stáva spoločným ukladaním dát pre súvisiace systémy. Údaje vytvorené a prevádzkované systémami tretích strán často sú v BGD. Toto sa musí zohľadniť pri navrhovaní architektúry vytvoreného systému.

V určitom štádiu vám akumulované "kritické hmotnosti" vám umožní ísť na novú úroveň kvality. Napríklad na konci štádia návrhu novej budovy, v GIS je možné automaticky vizualizovať prehľad 3D modely, vypracovať zoznam inštalovaných zariadení, vypočítať kilometer inžinierskych sietí spevnených, vykonávať sériu overovania a dokonca poskytujú predbežný finančný odhad nákladov na projekt.

Opäť poznamenávame, keď používate BISDM a ARCGI, je možné automaticky vytvoriť 3D modely podľa nahromadených údajov, pretože BGD obsahuje kompletný opis objektu, vrátane súradníc Z-koordinátov, patriacich do povodní, typov prvkov spojenia, vybavenie Metódy inštalácie, materiál, cestovný personál, funkčný účel každého prvku atď. atď. Je potrebné zvážiť, že po počiatočnom dovoze všetkých konštrukčných materiálov v BISDM BGD existuje potreba dodatočných informácií o:

• prosostanovka na určených miestach 3D modelov objektov a zariadení;
• zhromažďovanie informácií o hodnote materiálov a poradie ich znášky a inštalácie;
• kontrola prepuzdnosti na rozmery inštalovaného neštandardného vybavenia.

Vzhľadom na použitie ARCGIS je zjednodušený dovoz ďalších 3D objektov a referenčných kníh z externých zdrojov, pretože Modul interoperability ARCGIS vám umožňuje vytvárať postupy na import podobných údajov a ich správne umiestnenie vnútri modelu. Všetky formáty používané v tomto odvetví sú podporované, vrátane IFC, AutoCAD Revit, Behale MicroStation.

Priemyselné dátové modely z IBM

IBM poskytuje súbor nástrojov a modelov kontroly údajov pre rôzne oblasti činnosti:

• Dátový sklad bankových a finančných trhov (financie)
• IBM Banking Data Warehouse
• IBM Bankový proces a servisné modely
• IBM Health Plan Data Model (Healthcare)
• IBM Insurance Information Sklad (Poistenie)
• IBM Insurance procesu a servisné modely
• IBM Retail Data Warehouse (maloobchod)
• IBM Telekomunikačný sklad (Telekomunikácie)
• Balenie infosféry:
  - Pre prehľad zákazníka (pre porozumenie zákazníka)
  - Pre trh a kampaň vhľad (na pochopenie spoločnosti a trhu)
  - Prehľad dodávateľského reťazca (pre porozumenie dodávateľov).

Napríklad model IBM.Bankovníctvoa.Finančné.Trhy.Údaje.Sklad. Určené na riešenie špecifických problémov bankového priemyslu z hľadiska údajov a IBM.BankovníctvoProces.a.Služby.Modely. - Z hľadiska procesov a SOA (architektúra orientovaná na službu). Telekomunikačný priemysel predstavuje modely IBM.InformácieRámec (IFW) a IBM.TelekomunikácieÚdaje.Sklad (TDW). Pomáhajú výrazne urýchliť proces vytvárania analytických systémov, ako aj znížiť riziká spojené s rozvojom žiadostí o analýzu podnikov, riadením firemných údajov a organizovaním dátových skladov, pričom sa zohľadnia špecifiká telekomunikačného priemyslu. Možnosti IBM TDW pokrývajú celú škálu trhu telekomunikačných služieb - od poskytovateľov internetových služieb a prevádzkovateľov káblových sietí, ktoré ponúkajú káblové a bezdrôtové telefónne služby, prenos dát a multimediálny obsah, na nadnárodné spoločnosti, ktoré poskytujú telefón, satelit, intercity a medzinárodné služby Ako organizácie globálne siete. Doteraz je TDW používaný veľkými a menšími poskytovateľmi služieb káblovej a bezdrôtovej komunikácie na celom svete.

Nástroj Balenie skladu Infosféra pre prehľad zákazníka Je to štruktúrovaný a ľahko implementovaný obchodný obsah pre rastúci počet obchodných projektov a priemyselných odvetví vrátane bankovníctva, poisťovní, financií, zdravotného poistenia, telekomunikácií, maloobchodu a distribúcie. Pre užívateľov podnikateľov Infosféra Skladový balíček pre trh a kampaň Insight Pomáha maximalizovať účinnosť opatrení na analýzu trhových a marketingových kampaní z dôvodu krok za krokom procesu rozvoja a zohľadnenia špecifiká podniku. Cez Balenie infosféry Pack pre vhľad dodávateľského reťazca Organizácie majú schopnosť získať aktuálne informácie o operáciách dodávateľského reťazca.

Umiestnenie ESRI v architektúre IBM Solutions.

Osobitná pozornosť je venovaná prístupu IBM pre podniky s elektrinou a bývanie a verejnoprospešné podniky. S cieľom uspokojiť rastúce požiadavky na spotrebiteľov sa požaduje flexibilnejšia architektúra v porovnaní s aktuálne používaným dnes, ako aj štandardným modelom sektorového objektu, ktorý zjednodušuje bezplatnú výmenu informácií. To zvýši komunikačné príležitosti energetických spoločností, ktoré poskytujú interakciu v ekonomickejšom režime a poskytne nové systémy s najlepšou viditeľnosťou všetkých potrebných zdrojov bez ohľadu na to, kde sa nachádzajú v rámci organizácie. Základom tohto prístupu slúži ako (architektúra orientovaná na službu), model komponentu, ktorý stanovuje korešpondenciu medzi funkciami divízií a služieb rôznych aplikácií, ktoré možno opakovane používať. "Služby" týchto komponentov vymieňajú dátami prostredníctvom rozhraní bez tvrdej väzby, skrýva sa od užívateľa zložitosť systémov stojacich za nimi. V takomto režime môžu podniky ľahko pridať nové aplikácie bez ohľadu na poskytovateľa softvéru, operačný systém, programovací jazyk alebo iné vnútorné charakteristiky softvéru. Na základe Implementovaného konceptu SAO Bezpečné (Architektúra riešenia pre energiu), umožňuje elektrickým priemyslom spoločnosti získať holistickú prezentáciu svojej infraštruktúry na základe noriem.

ESRI ARCGIS® - Svetový softvérová platforma pre GeO-Informačné systémy (GIS), ktorý poskytuje vytvorenie a riadenie digitálnych aktív elektrickej energie, prenosu, distribúcie plynu a telekomunikačných sietí. Arcgis vám umožňuje vykonávať najkomplexnejšiu inventúru komponentov elektrickej rozvodnej siete, pričom sa zohľadní ich priestorové miesto. ARCGIS výrazne rozširuje bezpečnú architektúru IBM, poskytuje nástroje, aplikácie, pracovné postupy, analytické a informačné a integračné schopnosti potrebné na riadenie intelektuálneho energetického podniku. ARCGIS IBM SAFE Umožňuje dostávať informácie o infraštruktúre, aktívach, zákazníkov a zamestnancov s presnými údajmi na ich umiestnení z rôznych zdrojov, ako aj vytvoriť, ukladať a zvládnuť geografické informácie o podnikových aktív (podpora, potrubia, drôty, transformátory, kábel kanalizácie atď.). Arcgis vnútri bezpečnej infraštruktúry vám umožňuje dynamicky kombinovať hlavné obchodné aplikácie, ktoré kombinujú údaje z GIS, SCADA a Service Service Service s externými informáciami, ako je intenzita dopravy, poveternostné podmienky alebo satelitné obrazy. Energetické podniky používajú také kombinované informácie na rôzne účely, od S.O.R. (Celkový obraz prevádzkovej situácie) pred kontrolou objektov, údržby, analýzy a plánovania siete.

Informačné komponenty napájacieho podniku môžu byť simulované pomocou niekoľkých úrovní, ktoré sú zaradené z najvyšších - fyzických - na hornú, najkomplexnejšiu úroveň logiky obchodných procesov. Tieto úrovne môžu byť integrované, aby sa zabezpečilo dodržiavanie typických sektorových požiadaviek, napríklad s automatizovaným registráciou merania a riadenie riadenia riadiaceho systému a zber údajov (SCADA). Po vybudovaní bezpečnej architektúry výroba energie spoločnosti poskytujú významné kroky na podporu zabezpečeného modelu otvoreného objektu s názvom "Všeobecný informačný model pre energetické spoločnosti" (CIMFY a Utilities). Tento model poskytuje potrebnú základňu na podporu viacerých podnikov na architektúru orientovanú na služby, pretože podporuje používanie otvorených noriem na štruktúrovanie údajov a objektov. Vzhľadom na skutočnosť, že všetky systémy používajú rovnaké objekty, zmätenosť a neevantnosť spojená s rôznymi implementáciami rovnakých objektov sa zníži na minimum. Definícia objektu "klienta" a ďalších dôležitých obchodných objektov bude teda zjednotená vo všetkých systémoch podniku dodávok energie. Teraz, používanie CIM, dodávateľov a spotrebiteľov služieb môžu využiť spoločnú dátovú štruktúru, uľahčujúcu produkciu nákladných obchodných komponentov na outsourcing, pretože CIM nastaví spoločnú základňu, na ktorej môžete vybudovať výmenu informácií.

Záver

Komplexné sektorové dátové modely poskytujú spoločnosti s jedinou integrovanou prezentáciou ich obchodných informácií. Mnohé spoločnosti nie sú ľahké integrovať svoje údaje, hoci to je nevyhnutným predpokladom pre väčšinu všeobecných firemných projektov. Podľa štúdie Ústavu dátových skladov (TDWI), viac ako 69% zisťovaných organizácií zistilo, že integrácia je významnou prekážkou pri implementácii nových aplikácií. Naopak, implementácia integrácie údajov prináša hmatateľný príjem a zvýšenie efektívnosti.

Správne konštruovaný model určite určuje hodnotu údajov, ktoré sú v tomto prípade, sú štruktúrované údaje (na rozdiel od neštruktúrovaných údajov, ako je napríklad obrázok, binárny súbor alebo text, kde hodnota môže byť nejednoznačná). Najefektívnejšie sektorové modely ponúkané profesionálnymi dodávateľmi (dodávateľmi), vrátane ESRI a IBM. Vysoké výnosy z používania ich modelov sa dosiahne z dôvodu významnej úrovne ich detailu a presnosti. Zvyčajne obsahujú mnoho dátových atribútov. Okrem toho, ESRI a IBM špecialisti majú nielen rozsiahle skúsenosti s modelovaním, ale fungujú aj dobre v stavebných modeloch pre konkrétny priemysel.

Architektúra DB

Schéma CMD je popis štruktúry dátového modelu z hľadiska administrátora.

Systém NMD je popis vnútorného alebo fyzického modelu. Tu je popis fyzického umiestnenia údajov o médiách. Schéma ukladá priame pokyny na umiestnenie údajov do pamäte (objemy, disky).

Schéma CMD popisuje dátovú štruktúru, záznamy a polia.

Všetky DBMS podporujú tri hlavné typy dátových modelov:

1. Hierarchický model. Predpokladá sa, že niektoré koreňové záznamy. Zo koreňov idú pobočky.

Nie všetky objekty sú pohodlne opísané týmto spôsobom. V hierarchii nie sú žiadne pripojenia a vyznačuje sa veľkou nadbytočnosťou informácií.

2. Sieťový model. Umožňuje správne zobraziť všetku zložitosť vzťahov.

Model je vhodný pre prezentáciu odkazov s údajmi vonkajšieho prostredia, ale menej vhodné pre opis v databáze, čo vedie k dodatočnej práci používateľa, aby študoval navigáciu pre vzťahy.

3. Relačný model. Základ je založený na matematickom termíne - pomer a jednoducho stôl. Napríklad obdĺžnikové dvojrozmerné.

Štruktúra relačnej dátovej dát bola vyvinutá na konci 60. rokov v blízkosti výskumných pracovníkov, z ktorej najvýznamnejší príspevok bol vykonaný IBM zamestnanca Edgar CODD. S relačným prístupom sú údaje prezentované vo forme dvojrozmerných tabuliek - najprirodzenejšie pre ľudí. Zároveň pre spracovanie dát kódex navrhol používať zariadenie nastavovacej teórie - združenie, križovatku, rozdiel, karteziánsku prácu.

Dátový typ - Tento koncept má rovnaký význam ako v programovacích jazykoch (tj typ údajov určuje internú reprezentáciu v pamäti počítača a spôsob ukladania inštancie dát, ako aj súbor hodnôt, ktoré inštancia údajov a súbor prípustných dátových transakcií). Všetky existujúce moderné databázy podporujú špeciálne typy údajov, ktoré sú určené na uloženie dát typu celého čísla, frakčné plávajúce miesto, symboly a reťazce, dátumy kalendára. Mnohé databázové servery tiež implementujú iné typy, napríklad InterBase Server má špeciálny typ údajov pre ukladanie veľkých binárnych informačných polí (BLOB).

Doména - Toto je potenciálny súbor hodnôt jednoduchého dát, má podobnosti s podtypou údajov v niektorých programovacích jazykoch. Doména je určená dvoma prvkami - typ údajov a logický výraz, ktorý sa vzťahuje na údaje. Ak je výsledok tohto výrazu rovný hodnoty "pravdy", inštancia údajov patrí do domény.

Postoj - Ide o dvojrozmernú tabuľku špeciálneho typu pozostávajúceho z hlavičky a tela.

Titul - Toto je pevná sada atribútov, z ktorých každý je definovaný na nejakom druhu domény, a medzi atribútmi a definujúcimi domén je vzájomne jednoznačné dodržiavanie.

Každý z atribútov je definovaný na jeho doméne. Doména je typ údajov "celé" a logický stav - n\u003e 0. Názov je v čase nezmenený, na rozdiel od tela vzťahu. Vzťahy na telo - Toto je kombinácia násobnýKaždý z nich je pár "atribút - hodnota".

Silový vzťah nazývaný číslo jeho nôh a stupeň vzťahu - počet atribútov.

Stupeň vzťahu je pre tento pomer hodnoty konštantnej, zatiaľ čo výkon vzťahu sa časom mení. Kapacita vzťahu sa nazýva aj základné číslo.

Vyššie uvedené koncepty sú teoretické a používané vo vývoji jazykových nástrojov a softvérových systémov relačného DBMS. V každodennej práci sa namiesto toho používajú ich neformálne ekvivalenty:

postoj - tabuľka;

atribút - stĺpec alebo pole;

zásielka - nahrávanie alebo reťazec.

Stupeň vzťahu je teda počet stĺpcov v tabuľke a kardinálne číslo je počet riadkov.

Keďže postoj je nastavený, a v klasickej teórii sady podľa definície, súbor nemôže obsahovať zhodné prvky, potom vzťah nemôže byť dva identické tresle. Preto pre tento vzťah vždy existuje súbor atribútov, jednoznačne identifikuje motorca. Takáto sada atribútov sa nazýva kľúč.

Kľúč musí spĺňať tieto požiadavky:

· Musí byť jedinečný;

· Musí byť minimálny, to znamená, že odstránenie akéhokoľvek atribútu z kľúčov vedie k porušeniu jedinečnosti.

Spravidla je počet atribútov v kľúčovom kľúči menší ako pomer stupňa, avšak v extrémnom prípade môže kľúč obsahovať všetky atribúty, pretože kombinácia všetkých atribútov spĺňa podmienku jedinečnosti. Zvyčajne má postoj niekoľko kľúčov. Zo všetkých kľúčov vzťahu (sa tiež nazývajú "možné klávesy"), je zvolený ako primárny kľúč. Pri výbere primárny kľúčvýhodné je zvyčajne kľúča s najmenším počtom atribútov. Je nepraktické aj pomocou kľúčov s dlhými hodnotami reťazca.

V praxi sa špeciálny numerický atribút často používa ako primárny kľúč - auto-mikroketate nole, ktorej hodnota môže byť generovaná spúšťačom (spúšť je špeciálny postup, ktorý je spôsobený v čase vykonania zmien v databáze) alebo Špeciálne prostriedky definované v mechanizme DBMS.

Základné koncepty opísané v tejto kapitole sa nevzťahujú na žiadnu konkrétnu implementáciu databázy a sú pre nich spoločné. Tieto koncepty sú teda základom určitého všeobecného modelu, ktorý sa nazýva model relačného dát.

Zakladateľ dátumu relačného prístupu zistil, že relačný model pozostáva z troch častí:

· Štrukturálne;

· Manipulácia;

· Holistický.

V štrukturálnej časti modelu sa vzťahuje vzťahy ako jediná dátová štruktúra použitá v relačnom modeli.

Dva základné mechanizmy na manipuláciu relačných báz sa zaznamenávajú do manipulačnej časti - relačnej algebry a relačnom počte.

Pod neoddeliteľnou súčasťou sa rozumie určitý mechanizmus na zabezpečenie zničených údajov. Holistická časť obsahuje dve hlavné požiadavky na integritu relačných databáz - integrity subjektov a integrity na prepojeniach.

Dopyt integrity Je to, že akékoľvek n-hunvy akéhokoľvek vzťahu by sa mali odlíšiť od akejkoľvek inej vinárne tohto vzťahu, to znamená, inými slovami, akýkoľvek postoj musí mať primárny kľúč. Táto požiadavka by sa mala vykonať, ak sa vykonávajú základné vlastnosti vzťahu.

V jazyku manipulácie s údajmi, ako aj v jazyku dotazov jazyka sa vykonáva matematické zariadenie, nazývané vzťah algebra, pre určené nasledujúce akcie:

1. Štandardné operácie: - križovatka, - združenie, rozdiel, X - Cartesovo Práca.

2. Špecifické: projekcia, obmedzenie, zlúčenina, rozdelenie.

a. Združenie.

SD SM EI HP

R1 (SiFREs diely, materiál šifry, jednotky merania, prietok)

R 2 (SD, SM, EI, HP)

Potrebné nájsť

Predpokladá sa, že pripojte sady R1 a R2. V tejto operácii sa uchovávacia stupňa a výkon výsledného súboru

b. Prechod.

Pridelenie zhodných línií.

c. Rozdiel.

Výnimka z R1-tupu sa zhoduje s R2.

d. Karteziánskej práce.

Tu je koncertné tresle.

Každý riadok jednej sady je zreťazedá s každým riadkom druhej.

Uvádzajú sa dve súbory:

Kartézska práca má nasledujúci formulár:

V tomto prípade je S-stupeň rovnaký, a t.j. Ukáže 12 riadkov a 5 stĺpcov.

Korporátna databáza je centrálnym odkazom spoločnosti firemný informačný systém a umožňuje vytvoriť jeden informačný priestor spoločnosti. Firemné databázy

Zdieľajte prácu na sociálnych sieťach

Ak táto práca nevyvoláva v dolnej časti stránky, existuje zoznam podobných prác. Môžete tiež použiť tlačidlo vyhľadávania.

TOPIC V. Firemné databázy

V. .one. Údaje organizácie v podnikových systémoch. Firemné databázy.

V. .2. DBMS a konštrukčné riešenia v podnikových systémoch.

V .3. Internet / Intranet Technology a firemné prístupové riešenia databáz.

V. .one. Údaje organizácie v podnikových systémoch. Firemné databázy

Firemná základňa Údaje sú centrálnym odkazom firemného informačného systému a umožňuje vám vytvoriť jednotný informačný priestor spoločnosti. Firemné databázy (obr. 1.1).

Existujú rôzne definície databázy.

V databáze (databáza) Pochopiť kombináciu informácií logicky súvisiacich takým spôsobom, aby zostavil zjednotený súbor údajov uložených v pamäťových zariadeniach výpočtového stroja. Táto sada pôsobí ako zdrojové údaje o úlohách riešených počas prevádzky automatizovaných riadiacich systémov, systémov spracovania údajov, informačných a počítačových systémov.

Je možné, že termín databáza stručne formulovať ako súbor logicky súvisiacich údajov určených na zdieľanie.

V databáze Kombinácia údajov uložených spolu s takou minimálnou redundanciou, ktorá im umožňuje používať optimálny spôsob jednej alebo viacerých aplikácií.

Účel vytvárania databáz Ako formulár na ukladanie údajov Budovanie dátového systému, ktorý nezávisí od prijatých algoritmov (softvér), ktoré používajú technické prostriedky, fyzické umiestnenie údajov v počítači. Databáza zahŕňa viacúčelové použitie (viac užívateľov, mnoho foriem dokumentov a žiadostí o jedného používateľa).

Základné požiadavky na databázy:

• Plnosť prezentácie údajov. Údaje v databáze by mali primerane predložiť všetky informácie o objekte a mali by stačiť na SOD.
• Integrity databázy. Údaje by sa mali zachovať pri spracovaní ich sódy av akýchkoľvek situáciách, ktoré vznikajú počas práce.
• Flexibilitu dátovej štruktúry. Databáza by mala umožniť zmenu dátových štruktúr bez rušenia jeho integrity a úplnosti pri zmene vonkajších podmienok.
• Realizovateľnosť. To znamená, že musí existovať objektívne zastúpenie rôznych objektov, ich vlastností a vzťahov.
• Dostupnosť. Je potrebné zabezpečiť rozlišovanie prístupu k údajom.
• Nadbytok. Databáza musí mať minimálnu redundanciu údajov predstavujúcich akýkoľvek objekt.

Pochopenie vedomostí Kombinácia faktov, vzorov a heuristických pravidiel, s pomocou ktorej môžete túto úlohu vyriešiť.

Knowledge Base (BZ)  Súbor databáz a pravidlá používaných od činiteľov rozhodovania. Knowledge Base je prvok odborných systémov.

Mal by sa rozlíšiť rôzne metódy prezentácie údajov.

Fyzické údaje - toto sú údaje uložené v pamäti počítača.

Logický pohľad na údaje vyhovuje prezentácii fyzických údajov. Rozdiel medzi fyzickým a vhodným logickým zastúpením údajov je, že druhý odráža niektoré dôležité vzťahy medzi fyzickými údajmi.

Pod spoločnosťou Corporate Database Pochopiť databázu, ktorá kombinuje všetky potrebné údaje a znalosti automatizovanej organizácie v jednej forme alebo inej. V podnikových informačných systémoch, najviac koncentrovaný výraz našiel takú vec akointegrované databázy, v ktorom sa implementuje princíp jednorazového vstupu a viacnásobného používania informácií.

Obr. 1.1. Štruktúra interakcie divízií s informačnými zdrojmi spoločnosti.

Firemné databázy sú zameraný (centralizovaný) a distribuovaný.

Koncentrovaná (centralizovaná) databáza - Toto je databáza, ktorá je fyzicky uložená v skladovacích zariadeniach jedného výpočtového stroja. Na obr. 1.2 predstavuje diagram aplikácie servera na prístup k databázam v rôznych platformách.

Obr.1.2. Systém heterogénny Centralizovaná databáza

Centralizácia spracovania informácií umožnila odstrániť nevýhody tradičných súborových systémov, ako je neúplnosť, nekonzistentnosť a nadbytočnosť údajov. Ako sa však databázy zvýšia a najmä ak sa používajú v geograficky rozdelených organizáciách, zobrazia sa problémy. Napríklad pre koncentrované databázy umiestnené v uzle telekomunikačnej siete, s ktorým rôzne jednotky organizácie dostávajú prístup k údajom, s nárastom množstva informácií a počtu transakcií, vznikajú tieto ťažkosti: \\ t

• Veľký výmenný prúd dát;
• Vysoká návštevnosť v sieti;
• Nízka spoľahlivosť;
• Nízka celková výkonnosť.

Hoci koncentrovaná základňa je ľahšia na zabezpečenie bezpečnosti, integrity a konzistentnosti informácií počas aktualizácií, uvedené problémy vytvárajú určité ťažkosti. Ako možné riešenie týchto problémov sa navrhuje decentralizácia údajov. Keď dosiahla decentralizácia:

• Vyšší stupeň spracovania simultánnosti v dôsledku distribúcie zaťaženia;
• Zlepšenie používania údajov na zemi pri vykonávaní vzdialených (vzdialených) požiadaviek;
• Menšie náklady;
• Jednoduché riadenie miestnych základov.

Náklady na sieť, v uzloch, ktorých sú pracovné stanice (malé počítače), sú oveľa nižšie ako náklady na vytvorenie podobného systému pomocou veľkého počítača. Obrázok 1.3 zobrazuje logický diagram distribuovanej databázy.

Obr.1.3. Distributed Corporation Database.

Uveďte nasledujúcu definíciu distribuovanej databázy.

Distribuovaná databáza - tento súbor informácií, súborov (vzťahy) uložených v rôznych uzloch informačnej siete a logicky prepojené takým spôsobom, aby predstavovali jeden súbor údajov (komunikácia môže byť funkčná alebo prostredníctvom kópií toho istého súboru). Toto je teda súbor databáz súvisiacich s nimi logicky, ale fyzicky umiestnené na niekoľkých strojoch zahrnutých v jednej počítačovej sieti.

Najdôležitejšie požiadavky na charakteristiky distribuovanej databázy sú nasledovné:

• Škálovateľnosť;
• Kompatibilita;
• Podpora rôznych dátových modelov;
• Prenosnosť;
• Umiestnenie transparentnosti;
• Autonómia distribuovaných databázových uzlov (autonómia lokality);
• Spracovanie distribuovaných dotazov;
• Vykonávať distribuované transakcie.
• Podpora homogénny bezpečnostný systém.

Transparentnosť umiestnenia umožňuje používateľom pracovať s databázami, bez toho, aby vedeli niečo o svojej polohe. Autonómia uzlov distribuovanej databázy znamená, že každá základňa sa môže vyskytnúť nezávisle od iných. Distribuovaný dotaz je taká žiadosť (SQL-návrh), pri vykonávaní prístupu k objektom (tabuľky alebo názory) rôznych databáz. Pri vykonávaní distribuovaných transakcií sa vykonáva kontrola súbežnosti (kontrola súbežnosti) všetkých zainteresovaných databáz. ORACLE7 využíva dvojfázovú technológiu informačných technológií na vykonávanie distribuovaných transakcií.

Databázy, ktoré tvoria distribuovanú databázu, by nemali byť nevyhnutne homogénne (t.j. jedna databáza sa vykonáva) alebo spracovaná v prostredí rovnakého operačného systému a / alebo na počítačoch rovnakého typu. Jednou z databázy môže byť databáza Oracle na slnečnom počítači s operačným systémom Sun OS (UNIX), druhá databáza DB2 na mainframe IBM 3090 s operačným systémom MVS a SQL / DS DBMS Udržujte tretí databázový mainframe IBM, ale s operačným systémom VM. Uistite sa, že len jeden stav - všetky stroje s databázami musia byť dostupné cez sieť, na ktorú vstupujú.

Hlavná úloha distribuovanej databázy - Distribúcia údajov cez sieť a poskytnúť prístup k nemu. Existujú tieto spôsoby, ako tento problém vyriešiť:

• Každý uzol je uložený a jeho vlastný súbor údajov sa používa pre vzdialené požiadavky. Táto distribúcia je rozdelená.
• Niektoré údaje často používané na vzdialených uzloch môžu byť duplikované. Táto distribúcia sa nazýva čiastočne dabovaná.
• Všetky údaje sú v každom uzle duplikované. Táto distribúcia sa nazýva úplne dabovaná.
• Niektoré súbory môžu byť štiepené horizontálne (podmnožina vstupov) alebo vertikálne (podmnožina atribútov) sa prideľujú, zatiaľ čo vybrané podmnožiny sú uložené v rôznych uzloch spolu s nevyriešenými údajmi. Táto distribúcia sa nazýva Split (fragmentovaný).

Pri vytváraní distribuovanej databázy na koncepčnej úrovni sa musia vyriešiť nasledujúce úlohy:

• Je potrebné mať jednu koncepčnú schému celej siete. Tým sa zabezpečí logická transparentnosť údajov pre užívateľa, v dôsledku čoho bude môcť vytvoriť žiadosť o celú databázu, za samostatným terminálom (pracuje s centralizovanou databázou).
• Vyžaduje sa diagram, ktorá určuje umiestnenie údajov v sieti. Tým sa zabezpečí transparentnosť umiestnenia dát, vďaka ktorej užívateľ nemusí určiť, kde na postúpenie požiadavky na získanie požadovaných údajov.
• Je potrebné vyriešiť problém nehomogenity distribuovaných databáz. Distribuované základne môžu byť homogénne a nehomogénne v zmysle hardvéru a softvéru. Problémom heterogenity je pomerne ľahko vyriešený, ak je distribuovaná databáza nehomogénna v zmysle hardvéru, ale uniformy v zmysle softvéru (identické DBMS v uzloch). Ak sa v uzloch distribuovaného systému používajú rôzne DBMS, sú potrebné prostriedky konverzie dátových štruktúr a jazykov. To by malo zabezpečiť transparentnosť konverzie v uzloch distribuovanej databázy.
• Je potrebné vyriešiť problém slovníkov. Aby ste zabezpečili všetky druhy transparentnosti v distribuovanej databáze, sú potrebné programy, ktoré spravujú početné slovníky a referenčné knihy.
• Je potrebné definovať metódy vykonávania dotazov v distribuovanej databáze. Metódy vykonávania dotazov v distribuovanej databáze sa líšia od podobných metód v centralizovaných základniach, pretože jednotlivé časti žiadostí sa musia vykonať na mieste príslušných údajov a prenášajú čiastočné výsledky do iných uzlov; Zároveň by sa mali koordinovať všetky procesy.
• Je potrebné vyriešiť problém paralelného vykonávania dotazov. V distribuovanej báze je potrebný komplexný mechanizmus simultánneho spracovania, ktorý by mal najmä poskytnúť synchronizáciu počas aktualizácií informácií, čo zaručuje konzistenciu údajov.
• Je potrebná vyvinutá metodika distribúcie a umiestnenia údajov, vrátane rozdelenia, je jednou zo základných požiadaviek na distribuovanú databázu.

K jednému z aktívne vyvíjanie nových smerov architektúry počítačových systémov, ktoré sú výkonnými prostriedkami neformatívneho spracovania informácií, sú databázové stroje. Databázové stroje sa používajú na riešenie neokálnych úloh, ako je napríklad skladovanie, vyhľadávanie a transformácia dokumentov a faktov, práce s objektmi. Po definovaní údajov ako digitálnych a grafických informácií o objektoch okolitého sveta v koncepcii údajov s numerickým a nečíseným spracovaním investovali. S numerickým spracovaním, objektmi, ako sú premenné, vektory, matrice, multidimenzionálne polia, konštanty, a tak ďalej, zatiaľ čo s mimoriadnym spracovateľským objektom môžu byť súbory, záznamy, polia, hierarchie, siete, vzťahy atď. Neusklajú sa priamo Informácie o objektoch (napríklad konkrétneho zamestnanca alebo skupiny zamestnancov), a nie súbor zamestnancov ako taký. Súbor zamestnancov nie je indexovaný na výber konkrétnej osoby; Tu viac zaujímavostí obsahu požadovaného vstupu. Non-manipulácia zvyčajne prechádza obrovským množstvom informácií. V rôznych aplikáciách nad týmito údajmi sa takéto operácie môžu vykonávať:

• zvýšiť plat všetkým zamestnancom spoločnosti;
• vypočítať úroky z účtov všetkých zákazníkov;
• vykonať zmeny v zozname všetkých tovarov na sklade;
• nájdite požadovaný abstrakt všetkých textov uložených v knižnici alebo v systéme bibliografického informačného a vyhľadávacieho systému;
• nájdite popis požadovanej zmluvy v súbore obsahujúcich právne dokumenty;
• zobrazenie všetkých súborov obsahujúcich patentové popisy a nájdite patent (ak existuje), podobne ako znova navrhnúť.

Implementovať databázový stroj, paralelný a asociatívny Architektúra ako alternatíva k jednému procesorufonnamanovskaya Štruktúra, ktorá vám umožní pracovať s veľkými množstvami informácií v reálnom čase.

Databázové stroje sú dôležité v súvislosti so štúdiou a aplikáciou koncepcií umelej inteligencie, ako je prezentácia vedomostí, odborných systémov, logického záveru, rozpoznávania obrázkov atď.

Informačné sklady. Dnes mnohí rozpoznajú, že mnohé databázy sú už prevádzkované vo väčšine spoločností a pre úspešnú prácu s informáciami, nielen rôzne databázy, ale rôzne generácie DBMS. Podľa štatistík sa v každej organizácii používa priemer 2,5 rôznych DBMS. Stalo sa zrejmou potrebou "izolovať" obchodné spoločnosti alebo skôr, ľudia zaoberajúce sa týmto podnikaním z technologických znakov databáz, poskytujú užívateľom jediný pohľad na firemné informácie bez ohľadu na to, kde je fyzicky uskladnený. Stimulovala vznik technológie ukladania informácií (Dátové skladovanie, DW).

Hlavným cieľom DW - vytvorenie jediného logického zastúpenia údajov obsiahnutých rôznymi spôsobmi, alebo inými slovami, jednotný model firemných údajov.

Nové kolo rozvoja DW sa stalo možné z dôvodu zlepšenia informačných technológií vo všeobecnosti, najmä vznik nových typov databáz založených na paralelnom spracovaní žiadostí, ktoré sa zase spoliehali na úspechy v oblasti paralelných počítačov. Boli vytvorené Žiadosť Program dizajnérov S intuitívnym grafickým rozhraním, ktoré umožnilo ľahko vytvoriť komplexné požiadavky do databázy. Rozmanitýmedziľahlá vrstva (sileware) KOMUNIKÁCIAmedzi rôznymi databázami typuA konečne lacnejšie cheffeda ostroinformačné pamäťové zariadenia.

Data Bank môže byť prítomná v štruktúre spoločnosti.

Databáza - Funkčná a organizačná zložka v automatizovaných riadiacich systémoch a informačných a počítačových systémoch, ktoré vykonávajú centralizovanú informačnú podporu užívateľského tímu alebo súbor úloh vyriešených v systéme.

Databáza zvážte ako informačný a referenčný systém, ktorého hlavným účelom pozostáva z: \\ t

• v akumulácii a údržbe v pracovnom stave súboru informácií, ktoré tvoria informačnú základňu celého automatizovaného systému alebo súbor úloh vyriešených;
• pri vydávaní požadovanej úlohy alebo používateľských údajov;
• pri poskytovaní kolektívneho prístupu k uloženým informáciám;
• zabezpečenie potrebného riadenia používania informácií obsiahnutých v informačnej báze.

Moderná dátová banka je teda komplexný softvér a technický komplex, ktorý zahŕňa technické, systémové a sieťové prostriedky, databázy a DBMS, informačné a vyhľadávacie systémy na rôzne účely.

V. .2. DBMS a konštrukčné riešenia v podnikových systémoch

Systémy databázových a znalostí

Dôležitou zložkou moderných informačných systémov je systémy správy databáz (DBMS).

Dbms - Komplex softvérových a jazykových prostriedkov určených na vytvorenie, udržiavanie a používanie databáz.

Systém správy databázy poskytuje prístup k systémom spracovania údajov do databáz. Ako je uvedené, dôležitá úloha DBMS získava pri vytváraní firemných informačných systémov a obzvlášť dôležitú úlohu pri vytváraní informačných systémov pomocou distribuovaných informačných zdrojov, na základe modernej sieťovej počítačovej technológie.

Hlavným rysom moderných DBMS je, že moderné DBMS podporuje takéto technológie ako:

• Technológia klienta / servera.
• Podporné databázové jazyky. na tojazyk definície schémy Bd (Jazyk definície SDL - schémy),jazyk manipulácie s údajmi (jazyk manipulácie DML), integrované jazykySQL (štruktúrovaný jazyk frontu), QDB (dotaz - podľa - príklad) a QMF (zariadenie na správu dotazov ) - Vyvinutá špecifikácia periférnych požiadaviek a generáciu správyDb 2 atď.;
• Priama správa dát v externej pamäti.
• Riadenie nárazníkov RAM.
• Riadenie transakcií. OLTP - Technológia (On -Lline spracovanie transakcií), OLAP -technológia (Na spracovanie analýzy)pre DW.
• Zabezpečiť ochranu a integritu údajov. Použitie systému je povolené len používateľom oprávneným na prístup k údajom. Pri vykonávaní používateľov s operáciami na údajoch je podporovaná konzistencia uložených údajov (integrity). To je dôležité v oblasti firemných multiplayerových informačných systémov.
• Jornalizácia.

Moderné DBMS by mali zabezpečiť vyššie uvedené požiadavky na databázy. Okrem toho musia spĺňať tieto zásady:

• Nezávislosť.
• Univerzálnosť. DBMS musia mať výkonné nástroje na podporu koncepčného dátového modelu na zobrazenie vlastných logických znázornení.
• Kompatibilita. DBMS by mali udržiavať výkon vo vývoji softvéru a hardvéru.
• Nevýhoda údajov. Na rozdiel od súborových systémov musí byť databáza jediný súbor integrovaných údajov.
• Ochrana dát. DBMS musia poskytovať ochranu pred neoprávneným prístupom.
• Integrita údajov. DBMS by mali zabrániť porušeniu databázy používateľmi.
• Riadenie simultánnej práce. DBMS musia zabrániť databáze z nesúladu v režime kolektívneho prístupu. Aby sa zabezpečil dohodnutý stav základne, musia byť všetky požiadavky používateľa (transakcie) vykonané v určitom poradí.
• DBMS musia byť univerzálne. Musí udržiavať rôzne dátové modely na jednom logickom a fyzickom základe.
• DBMS musia podporovať centralizované aj distribuované databázy, a tak sa stanú dôležitým prepojením počítačových sietí.

Vzhľadom na DBMS ako triedu softvérových softvérových produktov v automatizovaných databázových systémoch sa dá rozlišovať dve najvýznamnejšie funkcie, ktoré definujú typy DBMS. Podľa nich je možné DBMS zobraziť z dvoch hľadísk:

• ich schopnosti vo vzťahu k distribuovaným (korporátnym) základniach;
• ich vzťah k typu dátového modelu implementovaného v DBMS.

V súvislosti s firemnými (distribuovanými) databázami možno rozlíšiť nasledujúce typy DBMS:

• DBMS "Desktop". Tieto výrobky sú primárne zamerané na prácu s osobnými údajmi (údaje "Desktop"). Majú sady tímov na zdieľanie spoločných databáz, ale malé (ako malá kancelária). Po prvé, to je DBMS typu aktív, DWA, Ragadokh, Eochrgo. Prečo Asssess, Dwaja, Ragadoch, Eochrgo majú neuspokojivý prístup k firemným údajom. Faktom je, že nie je jednoduchý spôsob, ako prekonať prekážku medzi osobnými a firemnými údajmi. A podstata nie je ani to, že mechanizmus DBMS osobných údajov (alebo malých kancelárií) je zameraný na prístup k údajom prostredníctvom mnohých brán, firewallových produktov atď. Problém je v tom, že tieto mechanizmy sú zvyčajne spojené s plným prenosom súborov a nedostatok podpory rozvetveného indexu, v dôsledku toho, ktoré fronty na server takmer zastaví vo veľkých systémoch.
• Špecializované vysoko výkonné multiplayer DBMS. Takéto DBMS sa vyznačujú prítomnosťou multi-užívateľského jadra systému, jazykom manipulácie s jazykom a nasledujúcimi funkciami, ktoré sú charakteristické pre vyvinuté Multiplayer DBMS:
• organizačná vyrovnávacia schránka;
• prítomnosť systému spracovania transakčných frontov;
• prítomnosť mechanizmov blokovania multiplayerových údajov;
• vedenie protokolu transakcií;
• prítomnosť prístupových mechanizmov.

Jedná sa o Oracle Type DBMS, DB2, SQL / SERVER, INFORMIX, SYBASE, ADABAS, TITANIUM A OTÁZKA POSKYTUJÚCE SLUŽBY NA SPRACOVANIE PROSTRIEDKA PODNIKU.

Pri práci s databázami sa používa mechanizmus transakcií.

Transakcia - Toto je logická jednotka práce.

Transakcia - Toto je postupnosť vykonávania manipulačných operátorovako celok (všetko alebo nič) a prekladá databázuz jedného holistického stavu do iného holistického stavu.

Transakcia má štyri dôležité vlastnosti známe ako vlastnosti ASID:

• A) atómici . Transakcia sa vykonáva ako atómová operácia - buď celá transakcia sa vykonáva úplne, alebo nie je úplne implementovaná.
• C) konzistentnosť. Transakcia prekladá databázu z jednej dohodnutej (holistickej) stav na iný súhlas (holistický) stav. Vo vnútri transakcie môže konzistencia databázy porušovať.
• (A) izolácia . Transakcie s rôznymi užívateľmi by nemali zasahovať do seba (napríklad, akoby boli vykonané striktne zase).
• E) trvanlivosť. Ak sa transakcia vykoná, výsledky jeho prevádzky musia byť uložené v databáze, aj keď systém zlyhá v nasledujúcom momente.

Transakcia sa zvyčajne začína automaticky od okamihu pripojenia používateľa na DBMS a pokračuje, kým nedokáže jedna z nasledujúcich udalostí:

• Bol pripojený príkaz Comml Commit (Zabezpečenie transakcie).
• Príkaz Rollback je podaný (Roll späť transakciu).
• Z DBMS bolo oddelenie používateľa.
• Bolo zlyhanie systému.

Pre užívateľa zvyčajne nosí atómová povaha. V skutočnosti je to komplexný mechanizmus interakcie používateľa (aplikácia) - databáza. Softvérové \u200b\u200bfiremné systémy používajú transakčný mechanizmus transakcie v reálnom čase (Systémy na spracovanie on-linetrancy, OLTP), Najmä účtovné programy, príjem softvéru a spracovanie klientskych aplikácií, finančné aplikácie, produkujú veľa informácií. Tieto systémy sa vypočítajú (a primerane optimalizované) na spracovanie veľkých množstiev údajov, vykonávajúcich komplexné transakcie a intenzívne operácie čítania / zápisu.

Bohužiaľ, informácie zverejnené v databázach OLTP systémov sú vhodné na používanie bežných používateľov (vzhľadom na vysoký stupeň normalizácie tabuliek, špecifických formátov prezentácie údajov a ďalších faktorov). Preto sú odoslané údaje z rôznych informačných dopravníkov (v zmysle kopírovaných) skladový sklad, triedenie a následné dodanie spotrebiteľa. V informačných technológiách hrá úloha skladovinformačné sklady.

DODANIE INFORMÁCIÍ K Koncovému používateľovi - sú zapojené do systémov analytických systémov na spracovanie údajov v reálnom čase (On-line analytické spracovanie, OLAP)ktoré poskytujú výnimočne ľahký prístup k údajom z vhodných nástrojov na generovanie požiadaviek a analýzy výsledkov. V systéme OLAP sa hodnota informačného produktu zvyšuje využitím rôznych metód analýzy a štatistického spracovania. Okrem toho sú tieto systémy optimalizované z hľadiska rýchlosti ťažby dát, zhromažďovanie generalizovaných informácií a sú orientované na bežných používateľov (majú intuitívne rozhranie). AkSystém OLTP dáva odpovede na jednoduché otázky ako "Aká bola úroveň predaja tovaru n v regióne M v januári 199h?",Systém OLAP Pripravený na zložitejšie požiadavky používateľa, napríklad: "Uveďte analýzu predaja tovaru N pre všetky regióny podľa plánu na druhý štvrťrok v porovnaní s týmito dvoma predchádzajúcimi rokmi."

Architektúra klienta / server

V moderných systémoch distribuované spracovanie informácií, centrálne miesto je obsadené technológiouklientsky server. V systéme architektúra klientský server Spracovanie dát je rozdelené medzi klientskym počítačom a počítačovým serverom, spojenie medzi ktorým sa vyskytuje cez sieť. Toto rozdelenie procesov spracovania údajov je založené na skupinových funkciách. Dátový počítač je spravidla pridelený na vykonávanie operácií s databázami a počítačový klient vykoná aplikačné programy. Obrázok 2.1 zobrazuje jednoduchý systém architektúry klient-server, ktorý zahŕňa počítač, ktorý pôsobí ako server, a ďalší počítač, ktorý pôsobí ako jeho klient. Každý stroj vykonáva rôzne funkcie a má svoje vlastné zdroje.

		Databáza
Počítačový server.
Čistý
Kompatibilný PC IBM	Kompatibilný PC IBM	Kompatibilný PC IBM
		Žiadosti

Obr. 2.1. Architektúra servera klienta

Hlavnou funkciou klientskeho počítača je vykonať aplikáciu (užívateľské rozhranie a logika prezentácie) a komunikuje so serverom, keď to vyžaduje aplikáciu.

Server (Server) - Toto je objekt (počítač), ktorý poskytuje služby iným objektom na ich požiadavkách.

Ako nasleduje z hľadiska, hlavnou funkciou serverového počítača je udržiavať potreby zákazníkov. Termín "Server" sa používa na označenie dvoch rôznych skupín funkcií: súborový server a databázový server (týmto termíny znamená v závislosti od kontextu alebo softvéru, ktorý implementuje špecifikované skupiny funkcií alebo počítačov s týmto softvérom). Servery súborových serverov nie sú určené na vykonávanie operácií s databázami, ich hlavnou funkciou - oddelenie súborov medzi viacerými používateľmi, t.j. Poskytovanie súčasného prístupu mnohých používateľov do súborov na počítači - súborový server. Príkladom servera je operačný systém Nevell Netware. Databázový server môže byť nainštalovaný a aktivovaný na počítači - súborový server. Oracle DBMS vo forme NLM (sieťové zaťažené modul) sa vykonáva v prostredí NetWare na súborovom serveri.

Miestny sieťový server musí mať zdroje zodpovedajúce jej funkčnému účelu a sieťovým potrebám. Všimnite si, že v súvislosti s orientáciou na prístup otvorených systémov je vhodnejší hovoriť o logických serveroch (čo znamená súbor zdrojov a softvéru poskytujúcich služby nad týmito zdrojmi), ktoré nie sú nevyhnutne na rôznych počítačoch. Funkcia logického servera v otvorenom systéme je, že ak je server odporúča prejsť na samostatný počítač pre efektívnosť efektívnosti, môže sa vykonať bez potreby akéhokoľvek rafinovanosti, a to tak vlastné aj používanie svojich aplikačných programov.

Jedným z dôležitých požiadaviek na server je, že operačný systém, v ktorom sa nachádza databázový server, by mal byť multitasking (a, výhodne, ale nie nevyhnutne multiplayer). Napríklad Oracle DBMS nainštalovaný na osobnom počítači s operačným systémom MS-DOS (alebo PC-DOS), ktorý nespĺňa požiadavku multitaskingu, nie je možné použiť ako databázový server. A rovnaké Oracle DBMS nainštalované na počítači s multi-tasking (aj keď nie multiplayer) OS / 2 operačný systém môže byť databázovým serverom. Mnohé odrody UNIX, MVS, VM Systems a niektoré ďalšie operačné systémy sú multitasking a multiplayer.

Distribuované výpočty

Termín "distribuované výpočty" sa často používa na označenie dvoch rôznych, aj keď doplnkové koncepty:

• Distribuovaná databáza;
• Distribuované spracovanie údajov.

Aplikácia týchto konceptov umožňuje organizovať prístup k informáciám uloženým na niekoľkých strojoch, pre koncových používateľov pomocou rôznych prostriedkov.

Existuje mnoho typov serverov:

• Databázový server;
• Tlačový server;
• Server vzdialeného prístupu;
• Faxový server;
• Webový server atď.

Na základe základného technologického klienta / servera Tieto základné technológie ležia ako:

• Operačné systémové technológie, koncepcia interakcie otvorených systémov, vytvorenie objektovo orientovaných programov fungovania programov;
• Telekomunikačné technológie;
• Sieťové technológie;
• Technológia grafického používateľského rozhrania (Gui);
• Atď.

Výhody technológie klient-server:

• Technologický klient / server umožňuje výpočty na nehomogénnych výpočtových prostrediach. Nezávislosť platformy: Prístup k heterogénnemu sieťovému médiu, ktorý zahŕňa počítače rôznych typov s rôznymi operačnými systémami.
• Nezávislosť od zdrojov údajov: Prístup k informáciám heterogénnych databáz. Príklady takýchto systémov - DB2, SQL / DS, ORACLE, SYBASE.
• Zostatok načítania klienta a servera.
• Vykonávanie výpočtov, kde sa to deje najefektívnejšie;
• Poskytnúť schopnosť efektívneho škálovania;
• Interplatformové výpočty. Interplatformné výpočty sa jednoducho určujú ako implementácia technológií v nehomogénnych výpočtových prostrediach. Treba tu poskytovať nasledujúce znaky:
• Žiadosť sa musí vykonať na niekoľkých platformách;
• Na všetkých platformách musí mať rovnaké rozhranie a logiku práce;
• Žiadosť sa musí integrovať s natívnym prevádzkovým prostredím;
• Mala by sa správať rovnako na všetkých platformách;
• Pre neho by sa mala poskytnúť jednoduchá a koordinovaná podpora.

 Distribuované výpočty. Distribuované výpočty zabezpečujú distribúciu práce medzi niekoľkými výpočtovými strojmi (hoci distribuované výpočty sú širší koncept).

 Nesúhlasím. Výboj - Prenos aplikácií pre veľké počítače na malé počítačové platformy.

• Zníženie nákladov na infraštruktúru a hardvér. Efektívnosť: dostupnosť nízkonákladových počítačových zariadení a rastúcim distribúciou miestnych sietí robí technológiu klient-server ekonomickejšie ako iné technológie spracovania údajov. Zariadenie môže byť aktualizované čo najskôr.

 Zníženie celkového času vykonávania žiadosti;

 Zníženie používania pamäte klienta;

 Znížená sieťová prevádzka.

• Schopnosť pracovať s multimédiou: K dnešnému dňu, bolo vytvorených veľa pracovných programov s multimédiou pre PC. Takéto programy pre konfiguračného terminálu-hostiteľa alebo nie, alebo sú veľmi drahé.
• Schopnosť prilákať veľké výpočtové zdroje pre databázové operácie: Keďže aplikácie sú vykonané na klientskych počítačoch, na počítačovom serveri pre operácie s databázami, ďalšie zdroje, ako napríklad výpočtové zdroje centrálneho procesora a prevádzkových zdrojov, sú vydané na klientovi Počítače. Pamäť.
• Vyššia produktivita programátorov: Produktivita programátorov sa zvyšuje využívaním finančných prostriedkov, ako sú formy SQL * a CASE: Umožňujú vám vyvíjať aplikácie rýchlejšie ako takéto programovacie jazyky ako C, PL1 alebo COBOL.
• Zvýšená produktivita užívateľov: V súčasnosti mnohí koncových užívateľov zvládli systémy, ako je Lotus, Paradox, Perfektné slovo, Harvard Graphics atď.

Rozhranie servera je definované a pevné. Preto je možné vytvoriť nové klientske časti existujúceho systému (príklad interoperability na úrovni systému).

Obr. 2.2. Ilustrácia prístupu zákazníka na Zdieľaný zdroj servera.

Ako implementovať technológiu klienta-server

Nasledujúci text je diskutovaný inštaláciou systému založeného na technológii klient-server a schopný robiť distribuované spracovanie údajov. Ďalšie počítačové vybavenie a softvér:

• počítačový databázový server;
• zákaznícke počítače;
• komunikačná sieť;
• sieťový softvér;
• aplikačný softvér.

Jazyk SQL . Jazyk dotazu na vysokej úrovni -SQL (Štruktúrovaný jazyk dotazu Používa sa na implementáciu dotazov na databázy, ako napríklad NMIDS, Jaode a nohavice a prijaté ako štandard. JazykSql Pôvodne prijatý ako dátový jazyk softvérových produktov spoločnostiIBM. a NMD Relational DBMSIBM systém r . Dôležitou črtou jazykaSql Je to, že rovnaký jazyk je reprezentovaný prostredníctvom dvoch rôznych rozhraní, a to: prostredníctvom interaktívneho rozhrania a cez aplikačné programovacie rozhranie (dynamickéSQL). Dynamic SQL pozostáva z rôznych vstavaných jazykových schopnostíSql Konkrétne na konštrukciu interaktívnych aplikácií, kde interaktívna aplikácia znamená program, ktorý je zapísaný na podporu databázy databázy koncového používateľa, ktorá pracuje na interaktívnom termináli. JazykSql Poskytuje funkcie určovania, manipulácie a správu databázových dát a je pre používateľa transparentné z hľadiska implementovaných DBMS.

Obr. 2.3. Diagram vykonania požiadaviek používateľov na distribuované databázy.

Vnútorná štruktúra databáz definuje použité dátové modely. Koncepčný model má veľké abstrakčné schopnosti a bohatšie sémantiky v porovnaní s externými modelmi. Externé modely sa často nazývajú syntaktické alebo prevádzkové modely, čo znamená syntaktický charakter riadenia a aplikácie ako interakcie používateľa s databázou. V modelovaní informácií existujú rôzne úrovne abstrakcie, na úrovni koncepčného modelu na úroveň fyzického dátového modelu ovplyvňujúceho architektúru DBMS.

Dátový model sa skladá z troch zložiek:

• Štruktúra dát pre prezentáciu z pohľadu používateľa do databázy.
• Prípustné operácie vykonávané na štruktúre dát. Je potrebné mať schopnosť pracovať s touto štruktúrou pomocou rôznych operácií Jaode a NMID. Bohatá štruktúra nepotrebuje nič, ak nie je možné ovládať jeho obsah.
• Obmedzenia kontroly integrity. Dátový model musí byť vybavený prostriedkami na udržanie jeho integrity a ochranu. Ako príklad zvážte nasledujúce dva obmedzenia:
• Každý podstrom musí mať zdrojový uzol. V hierarchických databázach nie je možné uložiť generované uzly bez zdroja uzla.
• Pokiaľ ide o relačnú databázu, môžu existovať žiadne identické nite. Pre súbor si táto požiadavka vyžaduje jedinečnosť všetkých záznamov.

Jednou z najdôležitejších charakteristík DBMS je schopnosť spájať objekty.

Existujú tieto typy odkazov medzi objektmi:

• Jedno-to-one (1: 1). Jeden objekt jednej sady môže byť spojený s jedným predmetom inej sady.
• Jedno-to-mnoho (1: m). Jeden objekt jednej sady môže byť spojený s mnohými objektmi inej sady.
• Mnoho-ko-mnoho (m: n). Jeden objekt jednej sady môže byť spojený s mnohými objektmi inej sady, ale zároveň jeden objekt iného súboru môže byť spojený s mnohými objektmi prvého množstva.
• Rozvetvený . Jeden objekt jednej súpravy môže byť spojený s objektmi mnohých súborov.
• Rekurzívny . Jeden objekt tejto súpravy môže byť spojený s objektom rovnakej sady.

Existujú tieto hlavné modely údajov:

• Model relačného dát.
• Hierarchický dátový model.
• Neúplné údaje o sieťovom modeli.
• Model CODASYYL DATA.
• Rozšírený model údajov o sieti.

V .3. Internet / Intranet Technology A firemné prístupové riešenia databáz

Hlavným problémom systémov založených na architektúre klienta-server je, že v súlade s koncepciou otvorených systémov sa vyžaduje mobilita v čo najširšej triede hardvérových softvérových riešení otvorených systémov. Aj keď sa obmedzíte na miestne siete orientované na UNIX, v rôznych sieťach sa uplatňujú rôzne siete a komunikačné protokoly. Pokusy o vytváranie systémov, ktoré podporujú všetky možné protokoly, vedie k ich preťaženiu siete podrobnosti o úkor funkčnosti.

Ešte ťažší aspekt tohto problému je spojený s možnosťou použitia rôznych prezentácií údajov v rôznych uzloch nerovnomernej lokálnej siete. V rôznych počítačoch môže existovať rôzne adresovanie, zobrazenie čísel, kódovanie symbolov atď. To je zvlášť dôležité pre servery na vysokej úrovni: telekomunikačné, výpočtové, databázy.

Všeobecné riešenie problému mobility systémov založených na architektúre klienta-server je podpora pre softvérové \u200b\u200bbalíčky, ktoré implementujú protokoly volania vzdialeného postupu (RPC - diaľkový postup). Pri použití takýchto nástrojov, prístup k službe v diaľkovom uzle vyzerá ako normálny hovor. RPC, v ktorom, prirodzene, obsahuje všetky informácie o špecifikách vybavenia miestnych sieťových a sieťových protokolov, prekladá hovor na sekvenciu sieťovej interakcie. Špecifiká sieťového prostredia a protokolov sú teda skryté z aplikačného programu.

Pri volaní diaľkového zákroku program RPC produkuje formáty dát klient na medziprodukty strojovo nezávislých formátov a potom previesť na serverové formáty údajov. Pri vysielaní parametrov odozvy sa vykonávajú podobné transformácie.

Iné podobné práce, ktoré vás môžu zaujímať. ISHM\u003e
6914.		Koncepcia databázy	11,56 kB.
	Databáza je prezentovaná v objekte vytvoriť súbor nezávislých materiálov predmetov zúčtovania predpisov súdnych rozhodnutí a iných podobných materiálov systematizovaných takým spôsobom, že tieto materiály možno nájsť a spracovať pomocou Elektronického občianskeho zákonníka s počítačom Ruskej federácie Umenie. Databáza je organizovaná v súlade s definovanými pravidlami a podporovaný v pamäti počítača súbor údajov charakterizujúcich aktuálny stav niektorých ...
8064.		Distribuované databázy	43,66 kB.
	Distribuované databázy v rámci distribuovanej databázy databázy RBD znamená súbor logicky prepojených rozdelených údajov, ktoré sú fyzicky distribuované cez rôzne uzly počítačovej siete. Prístup k údajom by nemal závisieť od prítomnosti alebo neprítomnosti repliky údajov. Systém musí automaticky určiť metódy vykonania pripojenia pripojenia pripojenie pripojenia sieťového kanála schopného vyrovnať sa s objemom prenášaných informácií a uzla, ktorý má dostatok výpočtovej energie na pripojenie tabuliek. Surbd musí byť schopný ...
20319.		Databázy a ich ochrana	102.86 kB.
	Operačné siete databázy sa objavili v polovici 60. rokov. Operačné operácie operačných databáz boli spracované v interaktívnom režime pomocou terminálov. Jednoduché index-sekvenčné záznamy záznamov rýchlo vyvinuté do silnejšieho sady záznamov orientovaných na súbory. Pre správu skupiny úloh Data Base (DBTG), ktorá vyvinula štandardný jazyk opisu údajov a manipuláciu s dátou, Charles Bakhman dostal cenu turavcov.
5031.		Knižnica vývoja databázy	11.72 MB.
	Technológia databázy. Definovanie prepojení medzi subjektmi a vytvorením dátového modelu. Hlavné myšlienky moderných informačných technológií sú založené na koncepte, podľa ktorého by sa údaje mali organizovať v databáze, aby primerane zobrazovali meniaci sa reálny svet a spĺňali informačné potreby používateľov. Tieto databázy sú vytvorené a fungujúce pod kontrolou špeciálnych softvérových komplexov s názvom DBMS Database Management Systems.
13815.		Hierarchický databázový model	81.62 kB.
	Hlavné myšlienky moderných informačných technológií sú založené na databázových konceptoch, podľa ktorých základom informačných technológií sú údaje zorganizované v databázach primerane odrážajú stav konkrétnej oblasti a poskytuje používateľom aktuálne informácie v tejto oblasti. Je potrebné uznať skutočnosť, že údaje sú ...
14095.		Vývoj databázy knižnice	11.72 MB.
	Zvýšenie objemu a štrukturálnej zložitosti uložených údajov, rozšírenie kruhu používateľov informačných systémov viedlo k rozšírenému najpohodlnejšiemu a relatívne jednoduchému pochopeniu relačného (tabuľky) DBMS.
5061.		Vytvorenie polylinickej databázy	2.4 MB.
	Rozvoj výpočtových zariadení a informačných technológií poskytol príležitosti na vytváranie a široko aplikovať automatizované informačné systémy (AIS) rôznych účelov. Informačné systémy pre riadenie a technické objekty sa vyvíjajú a implementujú
13542.		Geologická informačná databáza	20.73 KB.
	Nedávno sa počítačové technológie zavádzajú široké tempo a najmä databázy do vedeckej sféry. Tento proces nefunguje bočnú stranu a geológiu, pretože je v prírodných vedy, je potrebné uskladniť a spracovanie veľkého množstva informácií.
9100.		Databázy. Základné pojmy	26,28 kB.
	Databáza je súborom informácií o špecifických objektoch reálneho sveta v akejkoľvek oblasti ekonomiky riadenia chémie atď. Účelom informačného systému nie je len ukladať údaje o objektoch, ale aj manipulovať s týmito údajmi vzťah medzi objektmi. Každý objekt je charakterizovaný akoukoľvek sadou vlastností, ktoré sa nazývajú atribúty v databáze.
5240.		Vytvorenie databázy "Dean of University"	1,57 MB.
	Databáza (databáza) je súbor vzájomne prepojených uložených na externých dátových pamäťových médiách, ak existuje takáto organizácia a minimálna redundancia, ktorá im umožňuje používať optimálnym spôsobom pre jednu alebo viac aplikácií.

Priemyselné dátové modely

Hlavným účelom modelov je uľahčiť orientáciu v dátovom priestore a pomoc pri prideľovaní častí dôležitých pre rozvoj podnikania. V moderných podmienkach, aby úspešne vykonávať podnikať, je absolútne nevyhnutné mať jasné pochopenie vzťahu medzi rôznymi komponentmi a je dobré si predstavovať celkový obraz organizácie. Identifikácia všetkých častí a pripojení pomocou modelov vám umožňuje najefektívnejšie využívať čas a nástroje na organizáciu práce spoločnosti.

Pod dátovými modelmi, abstraktné modely opisujúce, ako sa porozumejú reprezentovať dát a prístup k nim. Dátové modely definujú dátové prvky a prepojenia medzi nimi v konkrétnej oblasti. Dátový model je navigačným nástrojom pre podnikanie a pre IT profesionálov, ktorý používa špecifický súbor znakov a slov, aby presne vysvetlila určitú triedu reálnych informácií. To vám umožní zlepšiť vzájomné porozumenie v rámci organizácie, a teda vytvoriť flexibilnejšie a stabilné prostredie pre aplikácie.

Dátový model jednoznačne určuje hodnotu údajov, ktoré sú v tomto prípade štruktúrované údaje (na rozdiel od neštruktúrovaných údajov, ako je napríklad obrázok, binárny súbor alebo text, kde hodnota môže byť nejednoznačná).

Modely na vysokej úrovni (a všeobecnejšie obsah) a nižšie (podrobnejšie) sú spravidla zvýraznené. Najvyššia úroveň modelovania je tzv. koncepčné dátové modely (Koncepčné dátové modely), ktoré dávajú všeobecný obraz o fungovaní podniku alebo organizácie. Koncepčný model zahŕňa základné pojmy alebo predmety, kritické pre fungovanie organizácie; Zvyčajne ich počet nepresahuje 12-15. Tento model opisuje triedy subjektov dôležité pre organizáciu (obchodné objekty), ich vlastnosti (atribúty) a združenia medzi pármi týchto tried (t.j. komunikácie). Vzhľadom k tomu, v obchodnom modelovaní terminológie, koncepčné dátové modely môžu byť tiež nazývané model predmetovej oblasti v rôznych anglicky hovoriacich zdrojoch (ktoré môžu byť preložené ako model predmetových oblastí) alebo predmetový podnikový dátový model (predmet firemných dátových modelov).

Ďalšia hierarchická úroveň je logický dátový model (Logické dátové modely). Môžu sa tiež nazývať firemné dátové modely alebo obchodné modely. Tieto modely obsahujú dátové štruktúry, ich atribúty a obchodné pravidlá a predstavujú informácie používané podnikom, z hľadiska obchodného hľadiska. V takomto modeli sa údaje organizujú vo forme subjektov a pripojení medzi nimi. Logický model predstavuje údaje takým spôsobom, aby boli podniky ľahko vnímané. V logickom modeli je možné vybrať dátový slovník - zoznam všetkých subjektov s ich presnými definíciami, ktoré umožňujú rôzne kategórie používateľov majú všeobecné chápanie všetkých vstupných a informačných výstupných prúdov modelu. Ďalšia, nižšia úroveň modelovania je fyzická implementácia logického modelu pomocou špecifických softvérových a technických platforiem.

Logický model obsahuje podrobné firemné obchodné riešenie, ktoré zvyčajne má formu normalizovaného modelu. Normalizácia je proces, ktorý zaisťuje, že každý dátový prvok v modeli má iba jednu hodnotu a úplne a jednoznačne závisí od primárneho kľúča. Dátové prvky sú organizované v skupinách podľa ich jedinečnej identifikácie. Obchodné pravidlá Controlling Data Prvky musia byť plne zahrnuté do normalizovaného modelu s predbežným overením ich presnosti a správnosti. Napríklad takýto dátový prvok ako názov klienta bude pravdepodobne rozdelený na meno a priezvisko a zoskupené s inými relevantnými dátovými prvkami do podstaty klienta s primárnym kľúčovým identifikátorom klienta.

Logický dátový model nezávisí od aplikačných technológií, ako sú databázy, sieťové technológie alebo nástroje na podávanie správ, az ich fyzickej implementácie. V organizácii môže byť len jeden firemný dátový model. Logické modely zvyčajne zahŕňajú tisíce subjektov, pripojení a atribútov. Napríklad dátový model pre finančnú organizáciu alebo telekomunikačnú spoločnosť môže obsahovať približne 3000 koncepcií priemyslu.

Je dôležité rozlišovať medzi logickým a sémantickým dátovým modelom. Model logického dát predstavuje firemné obchodné riešenie a sémantickým obchodným riešením. Rovnaký model firemnej logiky dát môže byť implementovaný pomocou rôznych sémantických modelov, t.j. Sémantické modely možno považovať za ďalšiu úroveň modelovania, ktorá sa približuje fyzickým modelom. Zároveň každý z týchto modelov predstavuje samostatný "rez" modelu firemného dát v súlade s požiadavkami rôznych aplikácií. Napríklad v modeli firemného logického dátového modelu, podstata klienta bude plne normalizovaná a v sémantickom modeli pre dátové prezentácie môžu byť zastúpené ako multidimenzionálna štruktúra.

Spoločnosť môže mať dva spôsoby, ako vytvoriť firemný logický model dát: vybudovať sami alebo využiť sektorový model Priemyselný logický dátový model). V tomto prípade rozdiely v zmysle odrážajú iba rôzne prístupy k výstavbe toho istého logického modelu. V prípade, že spoločnosť samostatne vyvíja a implementuje svoj vlastný logický dátový model, potom takýto model je spravidla nazývaný len firemný logický model. Ak sa organizácia rozhodne využiť hotový produkt profesionálneho dodávateľa, potom môžeme hovoriť o sektorovom logickom dátovom modeli. Ten je hotový logický dátový model s vysokým stupňom presnosti, ktorá odráža fungovanie určitého priemyslu. Sektorový logický model je objektovo orientovaný a integrovaný typ všetkých informácií, ktoré by mali byť v podnikovej dátovej skladu získať odpovede na strategické aj taktické obchodné otázky. Rovnako ako akýkoľvek iný logický dátový model, sektorový model nezávisí od aplikovaných riešení. Nezahŕňa tiež odvodené údaje alebo iné výpočty pre rýchlejšiu extrakciu dát. Väčšina logických štruktúr takéhoto modelu spravidla nájde dobré uskutočnenie vo svojej účinnej fyzickej implementácii. Takéto modely vyvíjajú mnohí dodávatelia pre širokú škálu oblastí činnosti: finančná sféra, výroba, cestovný ruch, zdravie, poistenie atď.

Sektorový logický dátový model obsahuje informácie spoločné pre priemysel, a preto nemôže byť pre spoločnosť vyčerpávajúce riešenie. Väčšina spoločností musí zvýšiť model v priemere o 25% pridaním dátových prvkov a definícií expanzie. Dokončené modely obsahujú iba kľúčové dátové prvky a zostávajúce položky musia byť pridané do príslušných obchodných objektov počas inštalácie modelu v spoločnosti.

Modely logických údajov o priemysle obsahujú značné množstvo abstrakcií. Pod odbermi existuje kombinácia podobných konceptov vo všeobecných menách, ako je udalosť alebo účastník. To pridáva sektorové modely flexibility a robí z nich viac zjednotených. Koncepcia udalostí sa teda vzťahuje na všetky priemyselné odvetvia.

Špecialista Business Intelligence Specialist Steve Hoberman (Steve Hoberman) zdôrazňuje päť faktorov, ktoré je potrebné vziať do úvahy pri riešení otázky získania sektorového dátového modelu. Prvým je čas a prostriedky potrebné na vytvorenie modelu. Ak organizácie musia rýchlo dosiahnuť výsledky, sektorový model poskytne výhodu. Použitie sektorového modelu nemôže okamžite poskytnúť obraz celej organizácie, ale môže ušetriť značné množstvo času. Namiesto samotného modelovania bude čas strávený na záväzné existujúce štruktúry s sektorovým modelom, ako aj na diskusiu o tom, ako je lepšie ho konfigurovať pre potreby organizácie (napríklad, ktoré definície by sa mali zmeniť, a čo by sa mali zmeniť Dátové prvky sa pridajú).

Druhým faktorom je čas a prostriedky potrebné na udržanie modelu v pracovnom stave. Ak model firemného dát nie je súčasťou metodiky, ktorá vám umožní monitorovať dodržiavanie jeho presnosti a dodržiavania moderných noriem, potom takýto model je veľmi rýchlo posadnutý. Sektorový dátový model môže zabrániť riziku takéhoto vývoja, pretože je podporovaný v aktualizovanom stave z dôvodu externých zdrojov. Samozrejme, že zmeny vyskytujúce sa vnútri organizácie by sa mali odrážať v modeli samotným spoločnosťou, ale zmeny priemyslu budú reprodukované vo svojom modeli dodávateľa.

Tretí faktor - skúsenosti s hodnotením rizík a modelovania. Vytvorenie korporátneho dátového modelu si vyžaduje kvalifikované zdroje z obchodného a IT-personálu. Spravidla manažéri vedia dobre alebo organizáciu organizácie ako celku, alebo aktivity konkrétneho oddelenia. Iba niekoľko z nich má širokú (na stupnici celej spoločnosti) a hlboko (v rámci divízií) vedomostí o ich podnikaní. Väčšina manažérov zvyčajne pozná len jednu oblasť. Preto, aby sa získal všeobecný firemný obraz, sú potrebné základné obchodné zdroje. Toto zvýšenie a požiadavky pre IT personál. Čím viac obchodných zdrojov je potrebné na vytvorenie a testovanie modelu, tým skúsenejšími analytikmi by mali byť. Mali by nielen vedieť, ako získať informácie od obchodného personálu, ale tiež byť schopný nájsť spoločný pohľad v kontroverzných oblastiach a byť schopný reprezentovať všetky tieto informácie v integrovanom formulári. Ten, kto sa zaoberá vytvorením modelu (v mnohých prípadoch je to ten istý analytik), musí mať dobré modelové zručnosti. Vytvorenie firemných logických modelov vyžaduje modelovanie "pre budúcnosť" a schopnosť konvertovať zložité podnikanie v literálnom zmysle "v štvorcov a riadkoch".

Na druhej strane, sektorový model vám umožňuje využiť skúsenosti špecialistov tretích strán. Pri vytváraní priemyselných logických modelov sa používajú osvedčené metodiky modelovania a tímy skúsených odborníkov, aby sa zabránilo spoločným a nákladným problémom, ktoré môžu vzniknúť pri vývoji firemných dátových modelov v rámci samotnej organizácie.

Štvrtým faktorom je existujúcou infraštruktúrou aplikácií a spojení s dodávateľmi. Ak organizácia už používa veľa nástrojov toho istého dodávateľa a založilo s ním väzby, dáva zmysel a sektorový model na objednávku od neho. Takýto model bude môcť slobodne pracovať s inými produktmi toho istého dodávateľa.

Piaty faktor - Vstupná výmena informácií. Ak spoločnosti musia vymieňať údaje s inými organizáciami, ktoré pracujú v tej istej oblasti, potom sektorový model môže byť veľmi užitočný v tejto situácii. Organizácie v rámci toho istého priemyslu používajú podobné štrukturálne zložky a terminológiu. V súčasnosti je väčšina priemyselných odvetví nútená výmenu údajov pre úspešné podnikanie.

Najúčinnejšie priemyselné modely ponúkané profesionálnymi dodávateľmi. Vysoká účinnosť ich použitia sa dosiahne z dôvodu významnej úrovne detailu a presnosti týchto modelov. Zvyčajne obsahujú mnoho dátových atribútov. Okrem toho tvorcovia týchto modelov majú nielen rozsiahle skúsenosti s modelovaním, ale aj dobre prevedené v stavebných modeloch pre konkrétny priemysel.

Modely údajov o priemysle poskytujú spoločnosti s jedinou integrovanou prezentáciou ich obchodných informácií. Mnohé spoločnosti nie sú ľahké integrovať svoje údaje, hoci to je nevyhnutným predpokladom pre väčšinu všeobecných firemných projektov. Podľa štúdie Ústavu dátových skladov (TDWI), viac ako 69% zisťovaných organizácií zistilo, že integrácia je významnou prekážkou pri implementácii nových aplikácií. Naopak, implementácia integrácie údajov prináša hmatateľný príjem.

Sektorový dátový model, okrem odkazov s existujúcimi systémami, poskytuje veľké výhody pri implementácii všeobecných firemných projektov, ako sú plánovanie podnikových zdrojov, hlavné údaje, obchodný analytik, zlepšovanie kvality údajov a profesionálny rozvoj zamestnancov.

Sektorové logické dátové modely sú teda účinným nástrojom na integráciu dát a holistický obchodný obraz. Zdá sa, že používanie logických modelov je potrebné na spôsobe vytvárania firemných dátových skladov.

Publikácie

1. Steve Hobermanman. Používanie modelu logického dátového priemyslu ako firemného modelu (využívanie modelu logického dátového priemyslu ako model Enterprise Data).
2. Claudia Imhoff (Claudia Imhoff). Operačné vytváranie dátového skladovania a vykonávanie projektov Business Intelligence s využitím modelovania údajov (Rýchly sledovanie dátových skladov a business intelligence Projekty prostredníctvom inteligentného modelovania údajov)

Zaitsev S.L., K.F.-M.N.

Opakovacie skupiny

Opakovacie skupiny sú atribúty, pre ktoré môže mať jediná inštancia subjektu viac ako jednu hodnotu. Napríklad osoba môže mať viac ako jednu zručnosť. Ak, pokiaľ ide o obchodné požiadavky, potrebujeme poznať úroveň vlastníctva zručnosti pre každého, a každý človek môže mať len dve zručnosti, môžeme vytvoriť podstatu znázornenú na obr. 1.6. Tu je v podstate prítomný OSOBAs dvoma atribútmi na ukladanie zručností a úrovne zručností pre každého.

Obr. 1.6. Tento príklad používa opakované skupiny.

Problém opakovaných skupín je, že presne nemôžeme vedieť, koľko zručností môže mať osobu. V reálnom živote majú niektorí ľudia jednu zručnosť, niektoré majú niekoľko, a niektorí ešte nie. Obrázok 1.7 ukazuje model uvedený v prvej normálnej forme. Venovať pozornosť pridaniu Identifikátor zručností ktoré jednoznačne určujú Zručnosti.

Obr. 1.7. Model uvedený na prvú normálnu formu.

Jedna skutočnosť na jednom mieste

Ak je rovnaký atribút prítomný vo viac ako jednej entite a nie je externým kľúčom, potom sa tento atribút považuje za prebytok. Logický model by nemal obsahovať redundantné údaje.

Redundancia vyžaduje dodatočný priestor, aj keď je dôležitý účinnosť používania pamäte, skutočný problém je iný. Zaručená synchronizácia redundantných údajov vyžaduje nad hlavou a vždy pracujete v riziku hodnoty konfliktu.

V predchádzajúcom príklade Zručnosťzáleží na Identifikátor osobya od Identifikátor.To znamená, že sa nezobrazí Zručnosťkým sa nezobrazí OSOBA,vlastniť túto zručnosť. Taktiež komplikuje zmenu v mene zručnosti. Je potrebné nájsť každý záznam s názvom zručnosti a zmeniť ho pre každého človeka, ktorý vlastní túto zručnosť.

Obrázok 1.8 zobrazuje model v druhej normálnej forme. Všimnite si, že je pridaná podstata. Zručnosťa atribút NÁZOVzručnosti sa presťahoval k tejto entite. Úroveň zručností zostala na križovatke Osoby a zručnosti.

Obr. 1.8. V druhej normálnej forme sa opakujúca skupina vloží do inej entity. To poskytuje flexibilitu pri pridávaní požadovaného množstva zručností a zmení meno zručnosti alebo opis zručnosti na jednom mieste.

Každý atribút závisí od kľúča

Každý atribút entity by mal závisieť od primárneho kľúča tohto subjektu. V predchádzajúcom príklade Meno školya Geografická oblasťprítomný v tabuľke OSOBAAle neopisujte osobu. Aby ste dosiahli tretiu normálnu formu, musíte posunúť atribúty v podstate, kde budú závisieť od kľúča. Obrázok 1.9. Zobrazuje model v tretej normálnej forme.

Obr. 1.9. V tretej normálnej forme Meno školy a Geografická oblasť prevedené do podstaty, kde ich hodnoty závisia od kľúča.

Mnoho-mnoho vzťahov

Vzťah mnoho-spoluodrážajú realitu okolitého sveta. Upozorňujeme, že na obrázku 1.9 existuje pomer mnohých-to-mnohých Osobaa Škola. Postoj presne odráža skutočnosť, že OSOBAsa môže učiť v mnohých Školské školya B. Školasa môže naučiť veľa Osoby.Asociatívna podstata je vytvorená na dosiahnutie štvrtej normálnej formy, ktorá eliminuje vzťah monogy-to-mnohých z dôvodu vytvorenia samostatného vstupu pre každú jedinečnú kombináciu školy a osoby. Obrázok 1.10 zobrazuje model vo štvrtej normálnej forme.

Obr. 1.10. Vo štvrtej normálnej forme sa vzťah medzi monogátom-spolu-mnohými Osoba a Školaje povolené zavedením asociatívneho subjektu, v ktorom je pre každú jedinečnú kombináciu pridelené samostatný záznam. Školské školy a Osoby.

Formálne definície normálnych formulárov

Nasledujúce definície normálnych foriem sa môžu zdať zastrašujúce. Zvážte ich jednoducho ako vzorce na dosiahnutie normalizácie. Normálne formy sú založené na relačnom algebre a môžu byť interpretované ako matematické transformácie. Hoci táto kniha nie je venovaná podrobnej diskusii o normálnych formách, modely vývojári sa odporúča podrobnejšie študovať túto otázku.

V zadanom pomere závisí atribút Y funkčne závisí od atribútu x. V znakovom formulári RX -\u003e RY (čítať ako "RX funkčne definuje RY") - v tom, a len vtedy, ak je každá hodnota x v R je spojená striktne s jednou hodnotou y r (v každom konkrétnom čase). Atribúty X a Y môžu byť kompozitné (Dátum K. J. Úvod do databázových systémov. 6. vydanie. Ed. Williams: 1999, 848 p.)

Pomer R zodpovedá prvej normálnej forme (1NF), ak a len ak všetky domény patriace do nej obsahujú iba atómové hodnoty (diéta, ibid).

Pomer krysu zodpovedá druhej normálnej forme (2NF), ak a len ak zodpovedá 1NF, a každý pevný atribút úplne závisí od primárneho kľúča (diéta, ibid).

Pomer R zodpovedá tretej normálnej forme (3NF), ak a len vtedy, ak zodpovedá 2NF, a každý neutrálny atribút nie je závisieť od primárneho kľúča (dátum, ibid).

Pomer R zodpovedá normálnej forme chlapcov-CODD (BCNF), ak je len vtedy, ak je každý determinant kandidát na použitie ako kľúč.

POZNÁMKA Nižšie je stručné vysvetlenie niektorých skratiek používaných v definíciách dátumu.

MVD (viacúčená závislosť) - Viacnásobná závislosť. Používa len pre subjekty s tromi a ďalšími atribútmi. S viacnásobnými závislosťami, hodnota atribútu závisí len na časti primárneho kľúča.

FD (funkčná závislosť) - funkčná závislosť. S funkčnou závislosťou, hodnota atribútu závisí od hodnoty iného atribútu, ktorý nie je súčasťou primárneho kľúča.

JD (pripojiť závislosť) - závislosť na zjednotenie. So závislosťou Únie môže byť primárny kľúč materskej jednotky vysledovať na potomkov aspoň tretiu úroveň, pričom sa zachová schopnosť používať v Únii zdrojovým kľúčom.

Pomer zodpovedá štvrtej normálnej forme (4NF), ak a len vtedy, ak sú napríklad MVD, napríklad A®®B. V tomto prípade všetky atribúty r funkčne závisia od A. Inými slovami, je prítomná iba závislosť (FD alebo MVD) formy K®X (tj funkčná závislosť x atribútu z kandidáta na použitie ako K) . V súlade s tým, R spĺňa požiadavky 4NF, ak zodpovedá BCNF a všetky MVD je vlastne FD (Diéta, ibid.).

Pre piaty normálnu formu, pomer R spĺňa závislosti kombinácie (JD) * (x, y, ..., z), ak je R je ekvivalentná svojimi projekciami na X, Y, ..., Z , kde x, y, .., Z podskupiny súborov atribútov R.

Existuje mnoho ďalších normálnych foriem pre komplexné typy údajov a špecifické situácie, ktoré presahujú našu diskusiu. Každý nadšenec modelov je žiaduci na štúdium iných normálnych foriem.

Obchodné normálne formuláre

Vo vašej knihe, Clive Finklestein (Finklestein Cl. Úvod do informačného inžinierstva: od strategického plánovania na informačné systémy. Čítanie, Massachusetts: Addison-Wesley, 1989) Aplikoval iný prístup k normalizácii. Definuje obchodné normálne formuláre, pokiaľ ide o prinášanie týchto formulárov. Mnohé vývojári modelov považujú tento prístup intuitívne jasnejší a pragmatický.

Prvá normálna forma podnikania (1BNF) robí opakované skupiny iným subjektom. Tento subjekt dostane vlastné meno a primárne (kompozitné) kľúčové atribúty z počiatočnej podstaty a jeho opakujúcej sa skupiny.

Druhá obchodná forma (2BNF) robí atribúty, ktoré čiastočne závisia od primárneho kľúča k inej entite. Primárny (kompozitný) Kľúčom kľúča tohto subjektu je primárnym kľúčom esencie, v ktorom bola pôvodne umiestnená, spolu s ďalšími kľúčmi, z ktorých atribút závisí úplne.

Tretia obchodná štandardná forma (3BNF) robí atribúty, ktoré sú nezávislé od primárneho kľúča, iným subjektom, kde sú úplne závislé od primárneho kľúča tohto subjektu.

Štvrtý obchodný formulár (4BNF) robí atribúty, ktoré závisia od hodnoty primárneho kľúča alebo sú voliteľné, do sekundárnej podstaty, kde sú úplne závislé od primárnej kľúčovej hodnoty alebo kde by mali byť prítomné v tomto subjeku .

Piaty podniková normálna forma (5BNF) sa prejavuje ako štrukturálna podstata, ak existuje rekurzívna alebo iná závislosť medzi kópiami sekundárneho subjektu, alebo ak existuje rekurzívna závislosť medzi inštanciami jeho primárnej podstaty.

Dokončený model Logic Data

Dokončený logický model musí spĺňať požiadavky tretej obchodnej formy a zahŕňajú všetky subjekty, atribúty a komunikácie potrebné na podporu požiadaviek na údaje a obchodné pravidlá spojené s údajmi.

Všetky subjekty musia mať mená popisujúce obsah a čistý, krátky, úplný opis alebo definíciu. Jedna z nasledujúcich publikácií zváži pôvodný súbor odporúčaní pre správnu tvorbu mien a opisov subjektov.

Essences musia mať kompletnú sadu atribútov, takže každá skutočnosť vo vzťahu k každému subjektu môže byť reprezentovaná jeho atribútmi. Každý atribút musí mať názov odrážajúce jeho hodnoty, logický typ údajov a jasný, krátky, úplný opis alebo definíciu. V jednom z nasledujúcich publikácií zvážime zdrojový súbor odporúčaní pre správnu tvorbu mien a opisov atribútov.

Komunikácia by mala zahŕňať slovesný dizajn, ktorý opisuje vzťah medzi subjektmi, spolu s takýmito vlastnosťami ako multiplicity, potreba existencie alebo možnosť nedostatku komunikácie.

POZNÁMKA Násobný Komunikácia opisuje maximálny počet kópií sekundárneho subjektu, ktorý môže byť spojený s inštanciou pôvodného subjektu.Potreba existencie alebomožnosť neprítomnosti Komunikácia slúži na určenie minimálneho počtu kópií sekundárneho subjektu, ktorý môže byť spojený s inštanciou počiatočného subjektu.

Model fyzického dát

Po vytvorení kompletného a primeraného logického modelu ste pripravení rozhodnúť o výbere implementačnej platformy. Výber platformy závisí od požiadaviek na využívanie údajov a strategických zásad pre tvorbu architektúry spoločnosti. Voľba platformy je náročný problém, ktorý presahuje rámec tejto knihy.

V Erwin je fyzickým modelom grafickým znázornením skutočne implementovanej databázy. Fyzická databáza bude pozostávať z tabuliek, stĺpcov a pripojení. Fyzický model závisí od platformy vybranej na implementáciu a požiadavky na používanie údajov. Fyzický model IMS sa bude vážne líšiť od rovnakého modelu pre SYBASE. Fyzický model pre správy OLAP bude vyzerať inak ako model pre OLTP (operačné spracovanie transakcií).

Dátový model Developer a administrátor databáz (administrátor databázy DBA) Použite logický model, požiadavky zákazníkov a strategické princípy pre vytvorenie architektúry spoločnosti na vytvorenie fyzického dátového modelu. Môžete denormalizovať fyzický model na zlepšenie výkonu a vytvoriť zobrazenia na podporu vlastných požiadaviek. V nasledujúcich častiach sa proces denormalizácie a tvorby prezentácie považuje za podrobnejšie.

Táto časť poskytuje prehľad procesu budovania fyzického modelu, zberu údajov o dátach sa udeľuje stanovenie zložiek fyzického modelu a reverzného dizajnu. V nasledujúcich publikáciách sú tieto otázky zahrnuté podrobnejšie.

Vyberanie požiadaviek na údaje

Zvyčajne zbierate požiadavky na používanie údajov v skorých štádiách počas rozhovorov a pracovných stretnutí. Súčasne by sa požiadavky najviac určili používanie údajov užívateľom. Povrchový postoj a lakuna vo fyzickom modeli môže viesť k neplánovaným nákladom a oneskorenia načasovania realizácie projektu. Požiadavky na použitie zahŕňajú:

Požiadavky na prístup a výkonnosť

Volumenické charakteristiky (hodnotenie množstva údajov, ktoré sa majú uložiť), ktoré umožňujú správcovi predložiť fyzickú databázu

Posúdenie počtu používateľov, ktorí potrebujú súčasný prístup k údajom, ktoré vám pomôžu navrhnúť databázu, pričom zohľadní prijateľnú úroveň výkonu

Celkové, súhrnné a iné vypočítané alebo derivátové údaje, ktoré možno považovať za kandidátov na skladovanie v dlhodobých dátových štruktúrach

Požiadavky na vytvorenie správ a štandardných dotazov, ktoré pomáhajú správcovi databázy, aby vytvorili indexy

Prezentácie (dlhodobé alebo virtuálne), ktoré pomôžu užívateľovi pri vykonávaní operácií kombinovania alebo filtrovania údajov.

Okrem predsedu, tajomníka a používateľov v relácii o požiadavkách na používanie, vývojár modelu, administrátora databázy a databázový architekt. Diskusia musí podliehať užívateľovi historické údaje. Trvanie časového obdobia, počas ktorého sú údaje uložené, má významný vplyv na veľkosť databázy. Staršie údaje sa často uchovávajú vo všeobecnosti a atómové údaje sú archivované alebo odstránené.

Používatelia by mali priviesť s vami na príklady relácií požiadaviek a správ. Správy musia byť prísne definované a mali by obsahovať atómové hodnoty používané pre všetky celkové a súhrnné polia.

Komponenty modelu fyzického dát

Komponenty fyzikálneho dátového modelu sú tabuľky, stĺpy a vzťahy. Podstatou logického modelu sa pravdepodobne stane tabuľkami vo fyzickom modeli. Logické atribúty sa stanú stĺpcami. Logické vzťahy sa stanú obmedzením integrity vzťahov. Niektoré logické vzťah nie je možné implementovať vo fyzickej databáze.

Reverzný dizajn

Keď logický model nie je k dispozícii, je potrebné obnoviť model z existujúcej databázy. V Erwine sa tento proces nazýva reverzný dizajn. Reverzný dizajn môže byť vykonaný niekoľkými spôsobmi. Vývojár modelu môže preskúmať dátové štruktúry v databáze a obnoviť tabuľky v prostredí vizuálnej simulácie. Jazyk popisu dát môžete importovať (jazyk DDL - DATA DIFIKÁLY) na nástroj, ktorý podporuje reverzný dizajn (napríklad Erwin). Vyvinuté nástroje, ako napríklad Erwin, zahŕňajú funkcie, ktoré poskytujú komunikáciu prostredníctvom ODBC s existujúcou databázou, na vytvorenie modelu pomocou priamych dátových štruktúr. Reverzný dizajn pomocou ERWIN bude podrobne diskutovaný v jednej z nasledujúcich publikácií.

Použitie firemných funkčných hraníc

Pri budovaní logického modelu pre model developera, je dôležité zabezpečiť, aby nový model zodpovedá spoločnosti Corporate. Využívanie firemných funkčných hraníc znamená modelovanie údajov, ktoré sa používajú v rámci spoločnosti. Spôsob použitia údajov v spoločnosti sa líši rýchlejšie ako samotné údaje. V každom logickom modeli by sa údaje mali prezentovať integritu bez ohľadu na oblasť predmetu podnikania, ktorú podporuje. Essencie, atribúty a vzťahy by mali definovať obchodné pravidlá na úrovni korporácie.

POZNÁMKA Niektorí z mojich kolegov nazývajú tieto firemné funkčné hranice v reálnom svete modelovania. Modelovanie reálneho sveta povzbudzuje vývojára modelu, aby zvážila informácie z hľadiska vzťahov a vzťahov, ktoré v ňom skutočne neodmyslite.

Používanie firemných funkčných hraníc pre dátový model, ktorý je postavený podľa toho, poskytuje základ pre podporu informačných potrieb akéhokoľvek počtu procesov a aplikácií, čo umožňuje efektívne využívať jeden z jeho najcennejších aktív - informácií.

Čo je firemný dátový model?

Corporate Data Model (EDM - Enterprise Data Model)obsahuje esencie, atribúty a vzťahy, ktoré predstavujú informačné potreby spoločnosti. EDM je zvyčajne rozdelený do dodržiavania predmetov, ktoré predstavujú skupiny subjektov patriacich k podpore špecifických obchodných potrieb. Niektoré predmety môžu pokryť takéto špecifické obchodné funkcie ako riadenie zmlúv, iné - kombinované subjekty opisujúce výrobky alebo služby.

Každý logický model musí spĺňať existujúcu oblasť predmetu modelu firemného dátového modelu. Ak logický model nie je v súlade s touto požiadavkou, mal by sa k nemu pridať model určujúci predmet oblasti. Toto porovnanie zabezpečuje, že model firemného modelu sa zlepšil alebo upraví a v rámci spoločnosti sú koordinované všetky úsilie na logickom modelovaní.

EDM.zahŕňa aj špecifické subjekty, ktoré určujú rozsah definície hodnôt pre kľúčové atribúty. Tieto subjekty nemajú rodičov a sú definované ako nezávislé. Nezávislé subjekty sa často používajú na udržanie integrity vzťahu. Tieto subjekty sú identifikované niekoľkými rôznymi názvami, ako sú kódové tabuľky, referenčné tabuľky, tabuľky typu alebo klasifikačné tabuľky. Budeme používať termín "firemný obchodný objekt". Podnikateľský objekt je subjekt, ktorý obsahuje súbor hodnôt atribútov, ktoré nezávisia od iného subjektu. Podnikové obchodné objekty v rámci korporácie by sa mali používať jednotne.

Budovanie firemného dátového modelu rozšírením

Existujú organizácie, v ktorých bol firemný model od začiatku skončiť, bol postavený v dôsledku jednotného dohodnutého úsilia. Na druhej strane väčšina organizácií vytvára pomerne kompletné firemné modely zvýšením.

Budova znamená stavbu niečo dôsledne, vrstva za vrstvou, rovnako ako ustrice rastie perlu. Každý vytvorený dátový model zabezpečuje príspevok k tvorbe EDM. Budovanie EDM v tejto metóde si vyžaduje ďalšie modelové akcie na pridanie nových dátových štruktúr a predmetových oblastí alebo rozšíriť existujúce dátové štruktúry. To umožňuje vybudovať firemný dátový model budovou, iteratívne pridávanie úrovní detailu a rafinovanie.

Koncepcia metodiky modelovania

Existuje niekoľko metodík pre modelovanie vizuálneho dát. Erwin podporuje dve:

IDEF1X (Definícia integrácie pre modelovanie informácií je integrovaný opis informačných modelov).

IE (Informačné inžinierstvo - Informačné inžinierstvo).

IDEF1X - Dobrá metodika a používanie jej notácie je rozšírená

Integrovaný opis informačných modelov

IDEF1x- vysoko štruktúrovaná metodika modelovania dát, ktorá rozširuje metodiku IDEF1 prijatého ako štandard FIPS (Federálne štandardy spracovania informácií sú štandardy spracovania federálnych informácií). IDEF1x využíva striktne štruktúrovaný súbor typov typov modelových návrhov a vedie k dátovému modelu, ktorý si vyžaduje pochopenie fyzickej povahy údajov predtým, ako môžu byť takéto informácie prístupné.

Tvrdá štruktúra IDEF1x núti vývojára modelu, aby predpísal subjekty vlastností, ktoré nemusia byť zodpovedné za reality sveta. Napríklad IDEF1x vyžaduje, aby všetky podtypy subjektov boli exkluzívne. To vedie k tomu, že osoba nemôže byť súčasne klientom a zamestnancom. Kým nám skutočná prax hovorí iná.

Informačné inžinierstvo

Clive Finkleshtein sa často označuje ako otec informačného inžinierstva, aj keď podobné koncepty spolu s ním a James Martin (Martin, James. Riadenie databázového prostredia. Horné sedlo River, New Jersey: Prentice Hall, 1983.). Informačné inžinierstvo využíva prístup k riadeniu podniku na riadenie informácií a uplatňuje inú zápis na predloženie obchodných pravidiel. IE slúži ako expanzia a rozvoj notácie a základných pojmov metodiky ER navrhla Peter Chen.

IE poskytuje infraštruktúru podpory informácií integráciou firemného strategického plánovania s informačnými systémami. Takáto integrácia vám umožňuje viac spájať správu informačných zdrojov s dlhodobými strategickými perspektívami korporácie. Tento prístup zaslaný požiadavkám podniku vedie mnoho modelov vývojárov na výber, tj namiesto iných metodík, ktoré sa zameriavajú najmä na riešenie úloh hybnosti.

IE ponúka postupnosť činností, ktoré vedú k korpoácii definovať všetky svoje informačné potreby na zhromažďovanie a správu údajov a identifikovať prepojenia medzi informačnými zariadeniami. Výsledkom je, že požiadavky na informácie sú jasne formulované na základe smerníc o riadení a môžu byť priamo preložené do informačného systému riadenia, ktorý bude podporovať strategické informačné potreby.

Záver

Pochopenie toho, ako používať nástroj modelovania dát podobný erwin je len časť problému. Okrem toho musíte pochopiť, keď sú riešené úlohy modelovania dát a ako sa zhromažďujú požiadavky na informačné a obchodné pravidlá, ktoré musia byť uvedené v modeli údajov. Vedúci pracovné stretnutia poskytuje najpriaznivejšie podmienky pre zber informácií o informáciách v médiu vrátane odborníkov z oblasti, používateľov a špecialistov v oblasti informačných technológií.

Na vybudovanie dobrého dátového modelu sa vyžaduje požiadavky na analýzu a výskum informácií a obchodných pravidiel zozbieraných počas pracovných stretnutí a rozhovorov. Výsledný dátový model sa musí porovnať s firemným modelom, ak je to možné, aby sa zabezpečilo, že nie je v rozpore s existujúcimi modelmi objektov a zahŕňa všetky potrebné objekty.

Dátový model sa skladá z logických a fyzických modelov zobrazujúcich informačné a obchodné pravidlá. Logický model musí byť uvedený tretej normálnej forme. Tretie normálne limity formulárov pridáva, aktualizuje a odstraňuje abnormálne dátové štruktúry na podporu "jednej skutočnosti na jednom mieste". Zozbierané požiadavky na informačné a obchodné pravidlá sa musia analyzovať a skúmať. Musia byť porovnané s firemným modelom, aby sa zabezpečilo, že nie sú v rozpore s existujúcimi modelmi objektov a zahŕňajú všetky potrebné objekty.

Dátový model ERWIN obsahuje logické aj fyzické modely. Erwin implementuje prístup ER a umožňuje vytvárať logické a fyzikálne modely objekty na prezentáciu požiadaviek na informácie a obchodné pravidlá. Logické modelové objekty zahŕňajú entity, atribúty a vzťahy. Objekty fyzického modelu zahŕňajú tabuľky, stĺpce a obmedzenia týkajúce sa integrity vzťahov.

V jednom z nasledujúcich publikácií, otázky identifikácie subjektov, identifikovať typy entít, výber subjektov a opisov, ako aj niektoré techniky, ktoré sa vyhýbajú najbežnejším chybám modelovania spojených s používaním subjektov.

Essences musia mať kompletnú sadu atribútov, takže každá skutočnosť vo vzťahu k každému subjektu môže byť reprezentovaná jeho atribútmi. Každý atribút musí mať názov odrážajúce jeho hodnoty, logický typ údajov a jasný, krátky, úplný opis alebo definíciu. V jednom z nasledujúcich publikácií zvážime zdrojový súbor odporúčaní pre správnu tvorbu mien a opisov atribútov. Komunikácia by mala zahŕňať slovesný dizajn, ktorý opisuje vzťah medzi subjektmi, spolu s takýmito vlastnosťami ako multiplicity, potreba existencie alebo možnosť nedostatku komunikácie.

POZNÁMKA Násobný komunikácia opisuje maximálny počet kópií sekundárneho subjektu, ktorý môže byť spojený s inštanciou pôvodného subjektu.Potreba existencie alebo neprítomnosti komunikácia slúži na určenie minimálneho počtu kópií sekundárneho subjektu, ktorý môže byť spojený s inštanciou originálu

Pošlite svoju dobrú prácu v znalostnej báze je jednoduchá. Použite nižšie uvedený formulár

Študenti, absolventi študenti, mladí vedci, ktorí používajú vedomostnú základňu vo svojich štúdiách a práce, budú vám veľmi vďační.

pridané http://www.allbest.ru/

• 1. Relačný dátový model
• 1.1 Model relačného dát. Hlavné definície
• 1.2 Operácie na vzťahy
• 2. Firemné informačné systémy
• Bibliografia

1. Relačný dátový model

1.1 Model relačného dát. Hlavné definície

V matematických disciplínach sa koncepcia "tabuľky" zodpovedá pojmu "vzťah" (vzťah). Tabuľka odráža predmet reálneho sveta - podstatou a každý z jeho reťazca odráža osobitnú inštanciu účtovnej jednotky. Každý stĺpec má jedinečný názov tabuľky. Riadky nie sú mená, poradie ich nasledujúceho nie je definované a číslo je logicky neobmedzené. Jednou zo základných výhod modelu relačného dát je jednotnosť (každý riadok tabuľky má jeden formát). Užívateľ sám rozhoduje o otázke, či zodpovedajúce subjekty majú jednotnosť. To rieši problém vhodnosti modelu.

Základné pojmy:

* Vzťah je dvojrozmerný stôl obsahujúci niektoré údaje.

* Essencia je predmetom akejkoľvek povahy, údaje, na ktorých je uložené v databáze. Atribúty - vlastnosti charakterizujúce esenciu (stĺpce).

* Stupeň vzťahu je počet stĺpcov.

* Riahová schéma - zoznam názvov atribútov, ako je zamestnanec (číslo, celé meno, rok narodenia, pozícia, kancelária).

* Doména - Sada hodnôt atribútov (typ údajov).

* TOP - Stolový reťazec.

* Kartinálnosť (moc) - počet riadkov v tabuľke.

* Primárnym kľúčom je atribút, jedinečný identifikačný riadok vzťahu. Primárny kľúč niekoľkých atribútov sa nazýva kompozitný. Primárny kľúč nemôže byť úplne alebo čiastočne prázdny (mať hodnotu null). Kľúče, ktoré sa dajú použiť ako primárne, sa nazývajú potenciálne alebo alternatívne klávesy.

* Externý kľúč je atribút (atribúty) jednej tabuľky, ktorá môže slúžiť ako primárny kľúč inej tabuľky. Je to odkaz na primárny kľúč inej tabuľky.

Normalizácia je proces zameraný na zníženie nadbytočnosti informácií v databáze. Okrem samotných údajov môžu byť v databáze aj rôzne mená, názvy objektov a výrazov.

Abnormalizovaná databáza obsahuje informácie v jednej alebo viacerých rôznych tabuľkách; To vytvára dojem, že zahrnutie údajov do jednej alebo inej tabuľky nie je spôsobené žiadnymi viditeľnými príčinami. Takýto stav môže mať negatívny vplyv na bezpečnosť údajov, racionálne používanie miesta na disku, rýchlosť realizácie dotazov, efektívnosť aktualizácie databázy a pravdepodobne je najdôležitejšia, integrita uložených informácií. Databáza pred normalizáciou je štruktúra, ktorá sa logicky nie je rozdelená do menších tabuliek.

Normálna forma je druh úrovne alebo hĺbky, normalizácia databázy. Úroveň normalizácie databázy zodpovedá normálnej forme, v ktorej sa nachádza.

1.2 Operácie na vzťahy

Ak chcete dať tabuľku prvej normálnej forme (1NF), musíte nasledovať tieto dve pravidlá:

1. Atomicity alebo nedeliteľnosť. Každý stĺpec musí obsahovať jednu nedeliteľne hodnotu.

2. Tabuľka by nemala obsahovať opakované stĺpce alebo skupiny údajov.

Napríklad, ak tabuľka obsahuje v jednom poli úplná adresa osoby (ulica, mesto, poštové smerovacie číslo), nebude reagovať na 1 nf pravidlá, pretože bude obsahovať rôzne hodnoty v jednom stĺpci, ktorý bude porušením poradia atomicity. Alebo ak databáza obsahuje údaje o filmoch a má stĺpec herec, herec, ACTUAR3, nebude tiež reagovať na pravidlá, pretože to bude mať opakovanie údajov.

Malo by sa začať s databázou štruktúrou pre kompatibilitu s 1NF. Všetky stĺpce, ktoré nie sú atómové, by mali byť rozdelené do ich stĺpcov. Ak sú v tabuľke opakované stĺpy, potom musia zvýrazniť samostatnú tabuľku.

Nasleduje tabuľku do prvej normálnej formy:

* Nájdite všetky polia, ktoré obsahujú viacpodlažné časti informácií.

* Tieto údaje, ktoré možno rozdeliť na komponenty, musia byť prijaté do samostatných polí.

* Dostávajte opakované údaje do samostatnej tabuľky.

* Skontrolujte, či sú všetky tabuľky vhodné pre podmienky prvej normálnej formy.

Ak chcete, aby tabuľky do druhej normálnej formy (2NF), tabuľky citované musia byť už v 1NF. Normalizácia by mala ísť do poriadku.

Teraz, v druhej normálnej forme, musí sa rešpektovať podmienka - akýkoľvek stĺpec, ktorý nie je kľúčom (vrátane externého), by mal závisieť od primárneho kľúča. Typicky sa takéto stĺpce, ktoré majú hodnoty, ktoré nezávisia na kľúč, sú ľahko určené. Ak údaje obsiahnuté v stĺpci nesúvisia s kľúčom, ktorý opisuje reťazec, by mal byť oddelený do ich samostatnej tabuľky. V starej tabuľke je potrebné vrátiť primárny kľúč.

Ak chcete základňu na druhú normálnu formu, je potrebné:

* Určite všetky stĺpce, ktoré nie sú priamo závislé od primárneho tlačidla tejto tabuľky.

* Vytvorte potrebné polia v tabuľkách používateľov a fórach, zvýraznite z existujúcich polí alebo vytvorte z nových primárnych kľúčov.

* Pre každú tabuľku potrebujete svoj primárny kľúč.

* Vytvorte externé klávesy a označte ich vzťah medzi tabuľkami. Koncový krok normalizácie na 2NF bude pridelenie externých tlačidiel komunikovať s pridruženými tabuľkami. Primárny kľúč tej istej tabuľky musí byť externým kľúčom k inému.

Tipy:

Ďalším spôsobom, ako priniesť schému na 2NF, je pozrieť sa na vzťah medzi tabuľkami. Ideálna možnosť je vytvoriť všetok vzťah formulára jeden-to-mnoho. Vzťahy formy mnohých na mnohých potrebujú reštrukturalizáciu.

Normalizovaný riadne tabuľka nikdy nebude mať opakované riadky (dva alebo viac riadkov, ktorých hodnoty nie sú kľúče a obsahujú zhodné údaje).

Databáza bude v treťom normálnom formulári, ak sa zobrazí druhá normálna forma a každý nie je kľúčový stĺpec nezávislý od seba. Ak budete postupovať s procesom normalizácie správne pred týmto bodom, s vedúcim na 3 NFF, nemusí vzniknúť. Je potrebné známe, že 3NF je poškodený, ak zmení hodnotu v jednom stĺpci, bude potrebná zmena v druhom stĺpci.

Ak chcete, aby základňa na tretiu normálnu formu, je potrebné:

* Určite, v ktorých oblasti, z ktorých tabuľky existuje vzájomná závislosť, t.j. Polí, ktoré závisia viac od seba ako z čísla všeobecne.

* Vytvorte vhodné tabuľky. Ak je v kroku 1 problémový stĺpec, vytvorte pre ňu samostatné tabuľky.

* Vytvorte alebo zvýraznite primárne tlačidlá. Každá tabuľka musí mať primárny kľúč.

* Vytvorte potrebné externé tlačidlá, ktoré tvoria ktorýkoľvek vzťah.

Vo štvrtej normálnej forme, dodatočné pravidlo - je potrebné vylúčiť viacvalové závislosti. Inými slovami, všetky riadky tabuľky musia byť navzájom nezávislé. Prítomnosť určitého radu X by nemala znamenať, že R riadok y je tiež niekde v tejto tabuľke.

2. Firemné informačné systémy

dátový systém relačného modelu

Systém (z gréckej systematiky je celé číslo zložené zo zlúčeniny zlúčeniny) je kombinácia prvkov interakcií navzájom tvoriacim určitú integritu, jednotu. Predstavujeme niektoré koncepty, ktoré sa často používajú na charakterizáciu systému.

1. Systémový prvok je súčasťou systému, ktorý má špecifický funkčný účel. Komplexné prvky systémov, zase pozostávajúce z jednoduchších vzájomne prepojených prvkov, sa často nazývajú subsystémy.

2. Organizácia systému je vnútorná poriadok, konzistentnosť interakcie prvkov systému, ktorá sa prejavuje najmä pri obmedzovaní rozmanitosti štátov prvkov v rámci systému.

3. Štruktúra systému je zloženie, poriadok a princípy interakcie prvkov systému, ktoré určujú základné vlastnosti systému. Ak sú jednotlivé prvky systému oddelené od rôznych úrovní a vnútorné vzťahy medzi prvkami sú organizované len od nadriadeného na nižšie úrovne a naopak, hovoria o hierarchickej štruktúre systému. Čisté hierarchické štruktúry sú prakticky zriedkavé zriedkavo sa zistili, že trochu rozširujú tento koncept, takéto štruktúry sú zvyčajne chápané pod hierarchickou štruktúrou, kde sú okrem iného dlhodobé hierarchické dlhopisy dominantný význam.

4. Systémová architektúra - súbor vlastností systému, ktoré sú nevyhnutné pre používateľa.

5. Integrita systému je zásadná nesprávna nesprávna nehnuteľnosť systému na súčet vlastností jeho jednotlivých prvkov (hmotstvo nehnuteľností) a zároveň závislosť vlastností každého prvku z jeho miesta a funkcia vnútri systému.

Informačný systém je vzájomne prepojený súbor finančných prostriedkov, metód a personálu používaných na skladovanie, spracovanie a vydávanie informácií v záujme dosiahnutia cieľa "\\ t

Federálny zákon "o informáciách, informatizácii a ochrane informácií" je uvedený v nasledujúcej definícii:

"Informačný systém je organizačne objednaný súbor dokumentov (emisie dokumentov) a informačných technológií vrátane využívania finančných prostriedkov výpočtovej techniky a komunikačných informačných procesov"

Klasifikácia podľa mierky

Na rozsahu informačných systémov sú rozdelené do nasledujúcich skupín:

* slobodný;

* skupina;

* Firemné.

Podnikový informačný systém je škálovateľným systémom určeným na integrovanú automatizáciu všetkých typov ekonomických činností veľkých a stredných podnikov, vrátane spoločností, ktoré sa skladajú zo skupiny spoločností, ktoré vyžadujú jedno riadenie.

Podnikový informačný systém je možné považovať za systém, ktorý automatizuje viac ako 80% podnikových jednotiek.

Nedávno sa v rôznych publikáciách o využívaní informačných technológií pri riadení ekonomických objektov, výraz "firemné informačné systémy" sa často používajú, podľa ktorého sa rozumejú automatizované informačné systémy ekonomických objektov.

Automatizovaný informačný systém (AIS) je kombináciou rôznych druhov kolaterálu, ako aj špecialisti sú určené na automatizáciu spracovania účtovných a analytických informácií. Typy poskytovania v zložení sú zvyčajne homogénne pre rôzne systémy, čo umožňuje implementáciu princípu kompatibility systémov v procese ich prevádzky. V procese štúdia AIS, ako komplexný systém, je potrebné vyzdvihnúť jednotlivé časti a prvky a zvážiť vlastnosti ich používania pri vytváraní a prevádzkových stupňoch.

Firemné informačné systémy sú rozvoj systémov pre pracovné skupiny, sú zamerané na veľké spoločnosti a môžu podporovať geograficky oddelené uzly alebo siete. V podstate majú hierarchickú štruktúru niekoľkých úrovní. Pre takéto systémy je architektúra klient-servera so špecializáciou serverov charakterizovaná alebo viacúrovňová architektúra. Pri vývoji takýchto systémov môžu byť rovnaké databázové servery použité ako vo vývoji skupinových informačných systémov. Vo veľkých informačných systémoch však spoločnosť Oracle, DB2 a Microsoft SQL však získali najväčšiu distribúciu.

Pre skupiny a firemné systémy sa významne zlepšujú požiadavky na spoľahlivosť fungovania a bezpečnosti údajov. Tieto vlastnosti sú poskytované podporou integrity údajov, odkazov a transakcií v databázových serveroch.

Klasifikácia aplikácií

Pokiaľ ide o rozsah pôsobnosti, informačné systémy sú zvyčajne rozdelené do štyroch skupín:

* Systémy spracovania transakcií;

* Rozhodovacie systémy;

* Informačné a referenčné systémy;

* Kancelárske informačné systémy.

Bibliografia

1. AGALTSOV, V.P. Databázy. V 2 tonách. T. 2. Distribuované a vzdialené databázy: Tutorial / V.p. Agaltsov. - M.: ID Fórum, NIC INFRA-M, 2013.

2. Golitsyn, O.L. Databázy: Tutorial / O.L. Golitsyn, N.V. Maksimov, I.I. Popov. - M.: Fórum, 2012.

3. KARPOVA, I.P. Databázy: Návody / I.P. Karpova. - SPB.: Peter, 2013.

4. Kirillov, V.V. Úvod do relačných databáz. V súvislosti s relačnými databázami / v.v. Kirillov, G.YU. Hrom. - SPB.: BHV-Petersburg, 2012.

5. PIROGOV, V.YU. Informačné systémy a databázy: Organizácia a dizajn: Tutorial / V.YU. Koláče. - SPB.: BHV-Petersburg, 2009.

6. G.N. Fedorova. Informačné systémy. - M.: Academy, 2013.

7. A.E. SATININA, L.A. Sysesoeva. Riadenie projektu firemného informačného systému podniku. - M.: Financie a štatistiky, INFRA-M, 2009.

Publikované na Allbest.ru.

...

Podobné dokumenty

Subjekt a charakteristiky dátových modelov: hierarchická, sieť a relačné. Základné pojmy modelu relačného dát. Atribúty, obvod vzťahov s databázami. Podmienky integrity údajov. Komunikácia medzi tabuľkami. Všeobecné predstavy o modeli údajov.

kurz práce, pridané 01/29/2011


Podnikové informačné systémy a databázy, ich použitie na zlepšenie a ladenie podnikania. Klasifikácia firemných informačných systémov. Informačné systémy Trieda OLTP. Prevádzkové analytické spracovanie.

kurz práce, pridané 01/19/2011


Databázy s dvojrozmernými systémami súborov a relačných databáz (DBMS). Vytvorenie žiadostí o databázu a spracovanie s nimi s DBMS. Hlavné typy databáz. Základné pojmy relačných databáz. Základné vlastnosti vzťahov.

abstraktné, pridané 12/20/2010


Koncepcia databázového systému. Relačného modelu a jeho vlastnosti. Integrity v relačnom modeli. Relačnej algebry. Otázky dizajnu databáz. Normálnych foriem vzťahov. Design Database Metóda esence-komunikácie. Er diagramy. Jazyk SQL.

kurz prednášok, pridané 03.10.2008


Špecifická logická štruktúra údajov uložených v databáze. Základné dátové modely. Prvkov modelu relačného dát. Príklad použitia externých tlačidiel. Základné požiadavky na vzťahy s modelom relačného dát.

prezentácia, pridaná 14.10.2013


Databázy a ich použitie pri výpočte. Vlastnosti a základná konštruktívna jednotka údajov o sieťovom modeli. Hierarchický model, objekty oblasti predmetu. Relačiteľný model, jeho viditeľnosť, prezentácia údajov v tabuľkovej forme.

abstraktné, pridané 12/19/2011


Typy a funkcie systému správy databázy Microsoft Access. Hierarchická, sieťová, relačná model popisu databázy. Hlavné pojmy databázovej tabuľky. Vlastnosti tvorby databázových objektov, základných formulárov. Prístup k prístupu k prístupu.

vyšetrenie, pridané 08.01.2011


Moderné systémy správy databáz (DBMS). Analýza hierarchického dátového modelu. Model relačného dát. Držovací model údajov ako rozšírený vzťahový model, ktorý zmierňuje obmedzenie nedelizácie údajov uložených v tabuľkách tabuliek.

vedecká práca, pridané 06.06.2010


Dátový model v oblasti správy databázy. Koncepčné dátové modely. Úloha databáz v informačných systémoch. Model relačného dát. Stanovenie oblasti. Budovanie databázového modelu pre informačný systém "domáce zvieratá".

kurz práce, pridané 04/19/2011


Informačný model v prístupe ako niektorý zjednodušený náhradník skutočného objektu alebo systému. Hlavné štruktúry, ktoré určujú organizovanie údajov a prepojenia medzi nimi; Relačnej variácie organizácie údajov. Príklad databázy v zdaňovaní.

Špecialisti sa čoraz viac snažia o svoju pozornosť riešením správy dát založených na štandardných sektorových dátových modeloch a šablónach obchodných riešení. Pripravené komplexné komplexné fyzikálne dátové modely a správy obchodných analytikov pre špecifické oblasti činnosti nám umožňujú zjednotiť informácie o činnostiach podniku a výrazne urýchliť implementáciu obchodných procesov. Rozhodovanie Šablóny umožňujú poskytovateľom služieb používať neštandardné informačné možnosti ukryté v existujúcich systémoch, čím sa znižujú projekty, náklady a riziká. S reálnymi projektmi ukazujú napríklad, že vzory dátového modelu a obchodných riešení môžu znížiť objem nákladov práce pre rozvoj o 50%.

Sektorový logický model je objektovo orientovaná, integrovaná a logicky štruktúrovaná prezentácia všetkých informácií, ktoré by mali byť v podnikovej dátovej skladu získať odpovede na strategické aj taktické obchodné otázky. Hlavným účelom modelov je uľahčiť orientáciu v dátovom priestore a pomoc pri prideľovaní častí dôležitých pre rozvoj podnikania. V moderných podmienkach, aby úspešne vykonávať podnikať, je absolútne nevyhnutné mať jasné pochopenie vzťahu medzi rôznymi komponentmi a je dobré si predstavovať celkový obraz organizácie. Identifikácia všetkých častí a pripojení pomocou modelov vám umožňuje najefektívnejšie využívať čas a nástroje na organizáciu práce spoločnosti.

Pod dátovými modelmi, abstraktné modely opisujúce, ako sa porozumejú reprezentovať dát a prístup k nim. Dátové modely definujú dátové prvky a prepojenia medzi nimi v konkrétnej oblasti. Dátový model je navigačným nástrojom pre podnikanie a pre IT profesionálov, ktorý používa špecifický súbor znakov a slov, aby presne vysvetlila určitú triedu reálnych informácií. To vám umožní zlepšiť vzájomné porozumenie v rámci organizácie, a teda vytvoriť flexibilnejšie a stabilné prostredie pre aplikácie.

Príkladom modelu GIS pre orgány a miestne samosprávy.

Dnes sú poskytovatelia softvéru a služieb strategicky dôležité, aby mohli rýchlo reagovať na zmeny v priemysle súvisiace s technologickými novinkami, stiahnutím štátnych obmedzení a komplikácií dodávateľských reťazcov. Spolu so zmenami v obchodnom modeli rastie zložitosť a náklady na informačné technológie potrebné na podporu aktivít spoločnosti. Najmä riadenie údajov je ťažké v prostredí, kde sa neustále menia firemné informačné systémy, ako aj funkčné a obchodné požiadavky.

Pomoc úľavu a optimalizovať tento proces, v preklade IT prístupu k modernej úrovni, sú určené modely sektorových údajov.

Priemyselné dátové modely od spoločnostiESRI.

Dátové modely pre platformu ESRI ARCGIS prevádzkujú šablóny pre použitie v projektoch GIS a vytvárajú dátové štruktúry pre rôzne oblasti aplikácií. Tvorba dátového modelu zahŕňa vytvorenie koncepčného dizajnu, logickej a fyzickej štruktúry, ktorá sa potom môže použiť na vytvorenie osobnej alebo firemnej geodatabázy. ARCGIS poskytuje nástroje na vytváranie a správu databázovej schémy a šablóny dátového modelu sa používajú na rýchle spustenie projektu GIS pre rôzne aplikácie a priemyselné odvetvia. Špeciaisti ESRI spolu s komunitou používateľov strávili značné množstvo času na vytvorenie radu šablón, ktoré môžu poskytnúť možnosť rýchleho začiatku navrhovania geodatabázy podniku. Tieto projekty sú opísané a zdokumentované na webovej stránke Support.esri.com/datamodels. Nižšie, v poradí podľa ich zmienky na tejto stránke je prezentovaný zmysluplným prekladom mená sektorových modelov ESRI:

• Adresa Registry
• poľnohospodárstvo
• Meteorológia
• Základné priestorové údaje
• Biodiverzita
• Interiérové \u200b\u200bbudovy
• Účtovníctvo pre skleníkové plyny
• Katedra administratívnych hraníc
• Ozbrojené sily. Spravodajská služba
• Energie (vrátane nového protokolu ARCGIS Multispeak)
• Environmentálne štruktúry
• Ministerstvo núdzových situácií Ohnisko
• Lesná katastra
• Lesníctvo
• Geológia
• Národná úroveň GIS (E-GOV)
• Podzemné a odpadové vody
• Zdravie
• Archeológia a ochrana pamätných miest
• Národná bezpečnosť
• Hydrológia
• Medzinárodná hydrografická organizácia (IHO). S-57 Formát pre ENC
• Zavlažovanie
• Územný register
• Obecná vláda
• Námorná navigácia
• Štátny kataster
• Olejové a plynové konštrukcie
• Potrubia
• Rastrový sklad
• BYTYMETRY, OZNÁMENIE OBCHODU PRODUKU
• Telekomunikácie
• Preprava
• Zásobovanie vodou, kanalizácie, bývanie a komunálne služby

Tieto modely obsahujú všetky potrebné známky priemyselného štandardu, a to:

• sú voľne prístupný;
• nemajú viazanie na "obľúbený" technológie výrobcu;
• v dôsledku realizácie reálnych projektov;
• s účasťou sektorových špecialistov;
• sú určené na poskytovanie interakcie informácií medzi rôznymi produktmi a technológiami;
• neporupujte iné normy a regulačné dokumenty;
• používané v implementovaných projektoch po celom svete;
• sú určené na prácu s informáciami o celom životnom cykle systému, ktorý je vytvorený, a nie samotný projekt;
• expandovateľné potreby zákazníkov bez straty kompatibility s inými projektmi a / alebo modelmi;
• sprevádzané ďalšími materiálmi a príkladmi;
• používané v metodických pokynoch a technických materiáloch rôznych priemyselných podnikov;
• veľká komunita účastníkov pri prístupe k komunite je otvorená pre všetkých;
• veľký počet odkazov na dátové modely v publikáciách v posledných rokoch.

Špecialisti ESRI sú zahrnuté v expertnej skupine nezávislých orgánov, ktorí odporúčajú používať rôzne sektorové modely, ako sú napríklad struky (potrubia otvorené dátové štandardy - otvorený štandard pre ropný a plynárenský priemysel; v súčasnosti existuje implementácia Pods ako geodatabáza ESRI PODS ESRI 5.1.1) Alebo základňa Geodatabase (BGD) z ARCGIS pre leteckú dopravu, ktorá zohľadňuje odporúčania ICAO a FAA, ako aj štandard výmeny údajov EXM 5.0 navigácie. Okrem toho existujú odporúčané modely, striktne relevantné pre existujúce sektorové normy, ako sú S-57 a ARCGI pre námorné (námorné a pobrežné objekty), ako aj modely vytvorené výsledkami dokončených odborných služieb ESRI a sú "de facto" normy vo vhodných oblastiach. Napríklad GIS pre národ a miestnu vládu ("GIS pre štátne orgány a miestne vlády") ovplyvnilo normy NSDI a inšpirujúce normy a vodnú a podzemnú vodu (hydrológia a podzemná voda) sa aktívne používajú vo voľnom cenovo dostupnom Archydro Professional balíku a komerčných produktov. Tretia Firmy. Treba poznamenať, že ESRI podporuje a "de-facto" normy, ako napríklad NHDI. Všetky navrhované dátové modely sú zdokumentované a pripravené na použitie v IT procesoch podniku. Sprievodné materiály pre modely zahŕňajú:

• UML diagramy vzťahov entity;
• dátové štruktúry, domény, referenčné knihy;
• ready Geodatabase šablóny vo formáte ARCGIS GDB;
• príklady údajov a príklady aplikácií;
• príklady dát načítavania skriptov, príklady analytických nástrojov;
• odkazy podľa navrhovanej dátovej štruktúry.

ESRI sumarizuje svoje skúsenosti so stavebnými priemyselnými modelmi vo forme kníh a lokalizuje publikované materiály. Spoločnosť ESRI CIS je lokalizovaná a boli zverejnené nasledujúce knihy:

• Geopriestorová architektúra orientovaná na služby (SAO);
• Návrh Geodatabáz na prepravu;
• Firemné geoinformačné systémy;
• GIS: Nová energia elektrických a plynových podnikov;
• Olej a plyn na digitálnej mape;
• Modelovanie nášho sveta. Riadenie ESRI na dizajne geodatabázy;
• Premýšľať o GIS. Plánovanie GIS: Príručka pre manažérov;
• Geografické informačné systémy. Základy;
• GIS pre administratívne a hospodárske riadenie;
• Web GIS. Zásady a aplikácia;
• Stratégie dizajnu systému, 26. vydanie;
• 68 Otázky časopisu Arcreview s publikáciami spoločností a systémov GIS;
• ... a mnoho ďalších tematických poznámok a publikácií.

Napríklad kniha " Modelovanie nášho sveta ..."(Preklad) je komplexný sprievodca a sprievodca pre modelovanie údajov v GIS vo všeobecnosti a najmä na dátovom modeli Geodatabázy. Kniha ukazuje, ako generovať správne riešenia modelovania dát, riešenia, ktoré sa zúčastňujú na každom aspekte GIS Projekt: Od návrhu základných údajov a zberu údajov do priestorovej analýzy a vizuálnej reprezentácie. Je podrobne opísaný, ako navrhnúť geografickú databázu, zodpovedajúci projekt, nakonfigurujte funkčnosť databázy bez programovania, kontrolovať prúd práce Komplexné projekty simuláciu rôznych sieťových štruktúr, ako je rieka, dopravu alebo elektrické siete, implementujú údaje do procesu geografickej analýzy a displeja, ako aj vytvoriť 3D dátové modely GIS. kniha " Design GeodataBases pre dopravu"Obsahuje metodické prístupy testované na veľké množstvo projektov a plne relevantné pre legislatívne požiadavky Európy a Spojených štátov, ako aj medzinárodných noriem. A v knihe" GIS: Nová energia elektrických a plynárenských podnikov"S použitím skutočných príkladov, výhody, ktoré spoločnosť Corporate GIS môže poskytnúť spoločnosť dodávateľovi energiu, vrátane aspektov, ako je zákaznícky servis, sieťová operácia a iné obchodné procesy.

Niektoré z kníh, prekladu a originálnych problémov publikovaných v ruštine ESRI CIS a dáta +. Sú ovplyvnené oboch koncepčných otázok súvisiacich s technológiou GIS a mnoho aplikovaných aspektov modelovania a nasadenia GIS iného stupnice a cieľa.

Uplatňovanie sektorových modelov zvážte v príklade bisdmového dátového modelu (budovanie interiérového vesmírneho dátového modelu, informačný model vnútorného priestoru budovy) verzia 3.0. BISDM je vývoj všeobecnejšieho modelu BIM (budovanie informačného modelu, informačného modelu budovy) a je určený na použitie v úlohách projektovania, výstavby, prevádzky a záveru z prevádzky budov a štruktúr. Používa sa v GIS, umožňuje efektívne vymeniť geodan s inými platformami a komunikovať s nimi. Vzťahuje sa na všeobecnú skupinu úloh FM (organizácia infraštruktúry organizácie). Uvádzame hlavné výhody modelu bisdm, ktorého použitie umožňuje:

• organizovať výmenu informácií v heterogénnom prostredí podľa jednotných predpisov;
• získajte "Fyzikálne" uskutočnenie koncepcie BIM a odporúčané pravidlá pre výstavbu stavebného projektu;
• udržujte jedno skladovacie zariadenie v celom životnom cykle budovy (z projektu k výstupu z prevádzky);
• koordinovať prácu rôznych odborníkov v projekte;
• vizualizovať položený kalendár plán a fázy výstavby pre všetkých účastníkov;
• uveďte predbežné posúdenie nákladov a lehôt (4D a 5D údajov);
• monitorovať pokrok projektu;
• zabezpečiť kvalitnú prevádzku budovy vrátane údržby a opravy;
• staňte sa súčasťou systému riadenia aktív, vrátane funkcií analýzy efektívnosti oblastí používania (prenájom, sklad, riadenie zamestnancov);
• vykonávať výpočet a riadenie úloh energetickej účinnosti budovy;
• upravte pohyb ľudských prúdov.

BISDM definuje pravidlá pre prácu s priestorovými údajmi na úrovni vnútorných priestorov v budove, vrátane účelu a použitia používania, položených komunikácií, inštalovaných zariadení, opravy opravy a údržby, ťažby incidentov, vzťahov s inými aktívami Spoločnosť. Model pomáha vytvoriť jedno skladovanie geografických a geografických údajov. Skúsenosti s poprednými globálnymi spoločnosťami boli použité na pridelenie subjektov a modelovanie na úrovni BGD (Geodatabase Base) priestorových a logických vzťahov všetkých fyzických prvkov, ktoré tvoria samotnú budovu a jeho vnútorné priestory. Po zásadách BISDM umožňuje výrazne zjednodušiť integračné úlohy s inými systémami. V prvej fáze to zvyčajne integruje s CAD. Potom sa počas prevádzky budovy výmena údajov používa s ERP a EAM Systems (SAP, TRIRIGA, MAXIMO, atď.).

Vizualizácia bisdm konštrukčných prvkov ARCGIS.

V prípade použitia BISDM, vlastník zákazníka / objektov prijíma prostredníctvom výmeny informácií z myšlienky vytvorenia objektu pred vývojom plnej projektu, monitorovanie výstavby s príslušnými informáciami do času uvedenia do prevádzky, kontroly parametrov počas prevádzky, \\ t A dokonca počas rekonštrukcie alebo výstupu objektu z prevádzky. Po BISDM paradigme, GIS a BGD, ktorý vytvoril, sa stáva spoločným ukladaním dát pre súvisiace systémy. Údaje vytvorené a prevádzkované systémami tretích strán často sú v BGD. Toto sa musí zohľadniť pri navrhovaní architektúry vytvoreného systému.

V určitom štádiu vám akumulované "kritické hmotnosti" vám umožní ísť na novú úroveň kvality. Napríklad na konci štádia návrhu novej budovy, v GIS je možné automaticky vizualizovať prehľad 3D modely, vypracovať zoznam inštalovaných zariadení, vypočítať kilometer inžinierskych sietí spevnených, vykonávať sériu overovania a dokonca poskytujú predbežný finančný odhad nákladov na projekt.

Opäť poznamenávame, keď používate BISDM a ARCGI, je možné automaticky vytvoriť 3D modely podľa nahromadených údajov, pretože BGD obsahuje kompletný opis objektu, vrátane súradníc Z-koordinátov, patriacich do povodní, typov prvkov spojenia, vybavenie Metódy inštalácie, materiál, cestovný personál, funkčný účel každého prvku atď. atď. Je potrebné zvážiť, že po počiatočnom dovoze všetkých konštrukčných materiálov v BISDM BGD existuje potreba dodatočných informácií o:

• prosostanovka na určených miestach 3D modelov objektov a zariadení;
• zhromažďovanie informácií o hodnote materiálov a poradie ich znášky a inštalácie;
• kontrola prepuzdnosti na rozmery inštalovaného neštandardného vybavenia.

Vzhľadom na použitie ARCGIS je zjednodušený dovoz ďalších 3D objektov a referenčných kníh z externých zdrojov, pretože Modul interoperability ARCGIS vám umožňuje vytvárať postupy na import podobných údajov a ich správne umiestnenie vnútri modelu. Všetky formáty používané v tomto odvetví sú podporované, vrátane IFC, AutoCAD Revit, Behale MicroStation.

Priemyselné dátové modely z IBM

IBM poskytuje súbor nástrojov a modelov kontroly údajov pre rôzne oblasti činnosti:

• Dátový sklad bankových a finančných trhov (financie)
• IBM Banking Data Warehouse
• IBM Bankový proces a servisné modely
• IBM Health Plan Data Model (Healthcare)
• IBM Insurance Information Sklad (Poistenie)
• IBM Insurance procesu a servisné modely
• IBM Retail Data Warehouse (maloobchod)
• IBM Telekomunikačný sklad (Telekomunikácie)
• Balenie infosféry:
  - Pre prehľad zákazníka (pre porozumenie zákazníka)
  - Pre trh a kampaň vhľad (na pochopenie spoločnosti a trhu)
  - Prehľad dodávateľského reťazca (pre porozumenie dodávateľov).

Napríklad model IBM.Bankovníctvoa.Finančné.Trhy.Údaje.Sklad. Určené na riešenie špecifických problémov bankového priemyslu z hľadiska údajov a IBM.BankovníctvoProces.a.Služby.Modely. - Z hľadiska procesov a SOA (architektúra orientovaná na službu). Telekomunikačný priemysel predstavuje modely IBM.InformácieRámec (IFW) a IBM.TelekomunikácieÚdaje.Sklad (TDW). Pomáhajú výrazne urýchliť proces vytvárania analytických systémov, ako aj znížiť riziká spojené s rozvojom žiadostí o analýzu podnikov, riadením firemných údajov a organizovaním dátových skladov, pričom sa zohľadnia špecifiká telekomunikačného priemyslu. Možnosti IBM TDW pokrývajú celú škálu trhu telekomunikačných služieb - od poskytovateľov internetových služieb a prevádzkovateľov káblových sietí, ktoré ponúkajú káblové a bezdrôtové telefónne služby, prenos dát a multimediálny obsah, na nadnárodné spoločnosti, ktoré poskytujú telefón, satelit, intercity a medzinárodné služby Ako organizácie globálne siete. Doteraz je TDW používaný veľkými a menšími poskytovateľmi služieb káblovej a bezdrôtovej komunikácie na celom svete.

Nástroj Balenie skladu Infosféra pre prehľad zákazníka Je to štruktúrovaný a ľahko implementovaný obchodný obsah pre rastúci počet obchodných projektov a priemyselných odvetví vrátane bankovníctva, poisťovní, financií, zdravotného poistenia, telekomunikácií, maloobchodu a distribúcie. Pre užívateľov podnikateľov Infosféra Skladový balíček pre trh a kampaň Insight Pomáha maximalizovať účinnosť opatrení na analýzu trhových a marketingových kampaní z dôvodu krok za krokom procesu rozvoja a zohľadnenia špecifiká podniku. Cez Balenie infosféry Pack pre vhľad dodávateľského reťazca Organizácie majú schopnosť získať aktuálne informácie o operáciách dodávateľského reťazca.

Umiestnenie ESRI v architektúre IBM Solutions.

Osobitná pozornosť je venovaná prístupu IBM pre podniky s elektrinou a bývanie a verejnoprospešné podniky. S cieľom uspokojiť rastúce požiadavky na spotrebiteľov sa požaduje flexibilnejšia architektúra v porovnaní s aktuálne používaným dnes, ako aj štandardným modelom sektorového objektu, ktorý zjednodušuje bezplatnú výmenu informácií. To zvýši komunikačné príležitosti energetických spoločností, ktoré poskytujú interakciu v ekonomickejšom režime a poskytne nové systémy s najlepšou viditeľnosťou všetkých potrebných zdrojov bez ohľadu na to, kde sa nachádzajú v rámci organizácie. Základom tohto prístupu slúži ako (architektúra orientovaná na službu), model komponentu, ktorý stanovuje korešpondenciu medzi funkciami divízií a služieb rôznych aplikácií, ktoré možno opakovane používať. "Služby" týchto komponentov vymieňajú dátami prostredníctvom rozhraní bez tvrdej väzby, skrýva sa od užívateľa zložitosť systémov stojacich za nimi. V takomto režime môžu podniky ľahko pridať nové aplikácie bez ohľadu na poskytovateľa softvéru, operačný systém, programovací jazyk alebo iné vnútorné charakteristiky softvéru. Na základe Implementovaného konceptu SAO Bezpečné (Architektúra riešenia pre energiu), umožňuje elektrickým priemyslom spoločnosti získať holistickú prezentáciu svojej infraštruktúry na základe noriem.

ESRI ARCGIS® - Svetový softvérová platforma pre GeO-Informačné systémy (GIS), ktorý poskytuje vytvorenie a riadenie digitálnych aktív elektrickej energie, prenosu, distribúcie plynu a telekomunikačných sietí. Arcgis vám umožňuje vykonávať najkomplexnejšiu inventúru komponentov elektrickej rozvodnej siete, pričom sa zohľadní ich priestorové miesto. ARCGIS výrazne rozširuje bezpečnú architektúru IBM, poskytuje nástroje, aplikácie, pracovné postupy, analytické a informačné a integračné schopnosti potrebné na riadenie intelektuálneho energetického podniku. ARCGIS IBM SAFE Umožňuje dostávať informácie o infraštruktúre, aktívach, zákazníkov a zamestnancov s presnými údajmi na ich umiestnení z rôznych zdrojov, ako aj vytvoriť, ukladať a zvládnuť geografické informácie o podnikových aktív (podpora, potrubia, drôty, transformátory, kábel kanalizácie atď.). Arcgis vnútri bezpečnej infraštruktúry vám umožňuje dynamicky kombinovať hlavné obchodné aplikácie, ktoré kombinujú údaje z GIS, SCADA a Service Service Service s externými informáciami, ako je intenzita dopravy, poveternostné podmienky alebo satelitné obrazy. Energetické podniky používajú také kombinované informácie na rôzne účely, od S.O.R. (Celkový obraz prevádzkovej situácie) pred kontrolou objektov, údržby, analýzy a plánovania siete.

Informačné komponenty napájacieho podniku môžu byť simulované pomocou niekoľkých úrovní, ktoré sú zaradené z najvyšších - fyzických - na hornú, najkomplexnejšiu úroveň logiky obchodných procesov. Tieto úrovne môžu byť integrované, aby sa zabezpečilo dodržiavanie typických sektorových požiadaviek, napríklad s automatizovaným registráciou merania a riadenie riadenia riadiaceho systému a zber údajov (SCADA). Po vybudovaní bezpečnej architektúry výroba energie spoločnosti poskytujú významné kroky na podporu zabezpečeného modelu otvoreného objektu s názvom "Všeobecný informačný model pre energetické spoločnosti" (CIMFY a Utilities). Tento model poskytuje potrebnú základňu na podporu viacerých podnikov na architektúru orientovanú na služby, pretože podporuje používanie otvorených noriem na štruktúrovanie údajov a objektov. Vzhľadom na skutočnosť, že všetky systémy používajú rovnaké objekty, zmätenosť a neevantnosť spojená s rôznymi implementáciami rovnakých objektov sa zníži na minimum. Definícia objektu "klienta" a ďalších dôležitých obchodných objektov bude teda zjednotená vo všetkých systémoch podniku dodávok energie. Teraz, používanie CIM, dodávateľov a spotrebiteľov služieb môžu využiť spoločnú dátovú štruktúru, uľahčujúcu produkciu nákladných obchodných komponentov na outsourcing, pretože CIM nastaví spoločnú základňu, na ktorej môžete vybudovať výmenu informácií.

Záver

Komplexné sektorové dátové modely poskytujú spoločnosti s jedinou integrovanou prezentáciou ich obchodných informácií. Mnohé spoločnosti nie sú ľahké integrovať svoje údaje, hoci to je nevyhnutným predpokladom pre väčšinu všeobecných firemných projektov. Podľa štúdie Ústavu dátových skladov (TDWI), viac ako 69% zisťovaných organizácií zistilo, že integrácia je významnou prekážkou pri implementácii nových aplikácií. Naopak, implementácia integrácie údajov prináša hmatateľný príjem a zvýšenie efektívnosti.

Správne konštruovaný model určite určuje hodnotu údajov, ktoré sú v tomto prípade, sú štruktúrované údaje (na rozdiel od neštruktúrovaných údajov, ako je napríklad obrázok, binárny súbor alebo text, kde hodnota môže byť nejednoznačná). Najefektívnejšie sektorové modely ponúkané profesionálnymi dodávateľmi (dodávateľmi), vrátane ESRI a IBM. Vysoké výnosy z používania ich modelov sa dosiahne z dôvodu významnej úrovne ich detailu a presnosti. Zvyčajne obsahujú mnoho dátových atribútov. Okrem toho, ESRI a IBM špecialisti majú nielen rozsiahle skúsenosti s modelovaním, ale fungujú aj dobre v stavebných modeloch pre konkrétny priemysel.