Vytvoření jednotného podnikového datového skladu. Vytvořte model datového skladu založený na podnikovém datovém modelu. Průmyslové datové modely

Zaitsev S.L., Ph.D.

Opakující se skupiny

Opakující se skupiny jsou atributy, pro které může mít jedna instance entity více než jednu hodnotu. Osoba může mít například více než jednu dovednost. Pokud z hlediska obchodních požadavků potřebujeme znát úroveň dovedností pro každého a každý člověk může mít pouze dvě dovednosti, můžeme vytvořit entitu znázorněnou na Obr. 1.6. Zde je entita OSOBA se dvěma atributy pro uložení dovedností a úrovní dovedností pro každou z nich.

Rýže. 1.6. Tento příklad používá opakující se skupiny.

Problém s opakujícími se skupinami je ten, že nemůžeme přesně vědět, kolik dovedností člověk může mít. Ve skutečném životě mají někteří lidé jednu dovednost, někteří několik a někteří ještě žádnou. Obrázek 1.7 ukazuje model zmenšený do první normální formy. Všimněte si přidaného ID dovednosti , která každého jednoznačně definuje DOVEDNOST.

Rýže. 1.7. Model zredukován do první normální podoby.

Jeden fakt na jednom místě

Pokud je stejný atribut přítomen ve více než jedné entitě a nejde o cizí klíč, je tento atribut považován za nadbytečný. Logický model by neměl obsahovat redundantní data.

Redundance vyžaduje další prostor, ale zatímco efektivita paměti je důležitá, skutečný problém je jinde. Zaručená synchronizace nadbytečných dat je spojena s režií a vždy se vystavujete riziku konfliktních hodnot.

V předchozím příkladu DOVEDNOST záleží na ID osoby a od ID dovednosti. To znamená, že nebudete mít DOVEDNOST dokud se neobjeví OSOBA, mít tuto dovednost. Také to ztěžuje změnu názvu dovednosti. Musíte najít každý záznam názvu dovednosti a změnit jej pro každou osobu, která tuto dovednost vlastní.

Obrázek 1.8 ukazuje model ve druhé normální formě. Všimněte si, že entita byla přidána DOVEDNOST a atribut TITUL dovednost přenesená na tuto entitu. Úroveň dovedností zůstala, respektive na křižovatce OSOBY a DOVEDNOSTI.

Rýže. 1.8. Ve druhé normální formě je opakující se skupina přesunuta do jiné entity. To poskytuje flexibilitu přidat tolik dovedností, kolik je potřeba, a změnit název dovednosti nebo popis dovednosti na jednom místě.

Každý atribut závisí na klíči

Každý atribut entity musí záviset na primárním klíči této entity. V předchozím příkladu Školní jméno a Zeměpisná oblast přítomný v tabulce OSOBA ale nepopisuj osobu. Chcete-li dosáhnout třetí normální formy, musíte přesunout atributy do entity, kde budou záviset na klíči. Obrázek 1.9. ukazuje model ve třetí normální formě.

Rýže. 1.9. Ve třetí normální formě Školní jméno a Zeměpisná oblast přesunuty do entity, kde jejich hodnoty závisí na klíči.

Mnoho k mnoha vztahům

Vztah mnoho-k-mnoho odrážejí realitu prostředí. Všimněte si, že na obrázku 1.9 je mezi nimi vztah mnoho k mnoha OSOBA a ŠKOLA. Poměr přesně odráží skutečnost, že OSOBA může studovat v mnoha ŠKOLY a dovnitř ŠKOLA se může hodně naučit OSOBA. K dosažení čtvrté normální formy je vytvořena asociativní entita, která eliminuje vztah monogie-to-many generováním samostatné položky pro každou jedinečnou kombinaci školy a osoby. Obrázek 1.10 ukazuje model ve čtvrté normální formě.

Rýže. 1.10. Ve čtvrté normální formě, vztah monogie-to-many mezi OSOBA a ŠKOLA vyřešeno zavedením asociativní entity, ve které je pro každou jedinečnou kombinaci přiřazen samostatný záznam ŠKOLY a OSOBY.

Formální definice normálních forem

Následující definice normálních forem se mohou zdát zastrašující. Představte si je jednoduše jako vzorce pro dosažení normalizace. Normální formy jsou založeny na relační algebře a lze je interpretovat jako matematické transformace. Přestože tato kniha nepokrývá podrobnou diskusi o normálních formách, modelářům se doporučuje, aby se do tématu ponořili hlouběji.

V daném vztahu R je atribut Y funkčně závislý na atributu X. Symbolicky, RX -> RY (čteno jako "RX funkčně definuje RY") právě tehdy, když každá hodnota X v R je spojena s přesně jednou hodnotou Y v R ( kdykoliv). Atributy X a Y mohou být složené (Date K.J. Introduction to Database Systems. 6. vydání. Ed. Williams: 1999, 848 s.).

Relace R je v první normální formě (1NF) právě tehdy, když všechny jeho domény obsahují pouze atomární hodnoty (Datum, tamtéž).

Relace R je ve druhé normální formě (2NF) právě tehdy, když je v 1NF a každý neklíčový atribut je plně závislý na primárním klíči (Datum, ibid.).

Relace R je ve třetí normální formě (3NF) právě tehdy, když je v 2NF a každý neklíčový atribut není tranzitivně závislý na primárním klíči (Datum, tamtéž).

Vztah R je v Boyce-Coddově normální formě (BCNF) právě tehdy, když je každý determinant kandidátem na použití jako klíč.

POZNÁMKA Níže je stručné vysvětlení některých zkratek používaných v definicích Date.

MVD (multi-valued dependency) - vícehodnotová závislost. Používá se pouze pro entity se třemi nebo více atributy. Ve vícehodnotové závislosti závisí hodnota atributu pouze na části primárního klíče.

FD (functional dependency) - funkční závislost. Ve funkční závislosti závisí hodnota atributu na hodnotě jiného atributu, který není součástí primárního klíče.

JD (join dependency) - spojitá závislost. V závislosti na spojení je primární klíč nadřazené entity sledovatelný alespoň k potomkům třetí úrovně, přičemž si zachovává možnost použití v původním spojení klíčů.

Vztah je ve čtvrté normální formě (4NF) právě tehdy, když je v R MVD, jako je A®®B. V tomto případě jsou všechny atributy R funkčně závislé na A. Jinými slovy, v R existují pouze závislosti (FD nebo MVD) formy K®X (tj. funkční závislost atributu X na kandidátovi pro použití). jako klíč K). V souladu s tím R splňuje požadavky 4NF, pokud vyhovuje BCNF a všechna MVD jsou ve skutečnosti FD (Datum, ibid.).

Pro pátou normální formu splňuje relace R sjednocovací relaci (JD)*(X, Y, …, Z) právě tehdy, když R je ekvivalentní svým projekcím na X, Y,..., Z, kde X, Y,. .., Z podmnožiny množiny atributů R.

Existuje mnoho dalších normálních formulářů pro komplexní datové typy a specifické situace, které přesahují rámec naší diskuse. Každý nadšenec do vývoje modelů by rád prozkoumal další normální formy.

Obchodní normální formuláře

Ve své knize Clive Finklestein (Finklestein Cl. An Introduction to Information Engineering: From Strategic Planning to Information Systems. Reading, Massachusetts: Addison-Wesley, 1989) zaujal odlišný přístup k normalizaci. Definuje běžné formy podnikání z hlediska redukce na tyto formy. Mnoho modelářů považuje tento přístup za intuitivnější a pragmatičtější.

První obchodní normální formulář (1BNF) mapuje opakující se skupiny na jinou entitu. Tato entita získá svůj vlastní název a primární (složené) klíčové atributy z původní entity a její opakující se skupiny.

Second Business Normal Form (2BNF) mapuje atributy, které částečně závisí na primárním klíči, na jinou entitu. Primární (složený) klíč této entity je primární klíč entity, ve které původně sídlila, spolu s dalšími klíči, na kterých je atribut zcela závislý.

Třetí obchodní normální forma (3BNF) přesouvá atributy, které nejsou závislé na primárním klíči, do jiné entity, kde jsou zcela závislé na primárním klíči této entity.

Fourth Business Normal Form (4BNF) mapuje atributy, které závisí na hodnotě primárního klíče nebo jsou volitelné pro sekundární entitu, kde zcela závisí na hodnotě primárního klíče, nebo kde musí být (povinně) přítomny v dané entitě. .

Fifth Business Normal Form (5BNF) se objevuje jako strukturální entita, pokud existuje rekurzivní nebo jiná závislost mezi instancemi sekundární entity nebo pokud existuje rekurzivní závislost mezi instancemi její primární entity.

Dokončený logický datový model

Dokončený logický model musí splňovat požadavky třetí obchodní normální formy a zahrnovat všechny entity, atributy a vztahy nezbytné k podpoře požadavků na data a obchodních pravidel spojených s daty.

Všechny entity musí mít názvy, které popisují obsah, a jasný, stručný, úplný popis nebo definici. V jedné z následujících publikací bude zvažována počáteční sada doporučení pro správné tvoření názvů a popisů entit.

Vztahy by měly obsahovat slovesnou konstrukci, která popisuje vztah mezi entitami, spolu s charakteristikami, jako je pluralita, potřeba existence nebo možnost neexistence vztahu.

POZNÁMKA Množství vztahy popisují maximální počet instancí sekundární entity, které lze přidružit k instanci původní entity.Potřeba existence nebomožnost nepřítomnosti vztah se používá k definování minimálního počtu instancí sekundární entity, které mohou být spojeny s instancí původní entity.

Fyzický datový model

Po vytvoření kompletního a adekvátního logického modelu jste připraveni učinit rozhodnutí o volbě implementační platformy. Volba platformy závisí na požadavcích na využití dat a strategických principech architektury organizace. Výběr platformy je komplexní problém, který přesahuje rámec této knihy.

V ERwin je fyzický model grafickou reprezentací skutečné databáze. Fyzická databáze se bude skládat z tabulek, sloupců a vztahů. Fyzický model závisí na platformě zvolené pro implementaci a požadavcích na využití dat. Fyzický model pro IMS se bude velmi lišit od stejného modelu pro Sybase. Fyzický model pro sestavy OLAP bude vypadat jinak než model pro OLTP (Online Transaction Processing).

Datový modelář a správce databáze (DBA) používají k vývoji fyzického datového modelu logický model, požadavky na použití a strategické principy podnikové architektury. Fyzikální model můžete denormalizovat, abyste zlepšili výkon, a vytvořit pohledy pro podporu požadavků na použití. Následující části podrobně popisují proces denormalizace a vytváření pohledu.

Tato část poskytuje přehled procesu vytváření fyzického modelu, shromažďování požadavků na používání dat, definování komponent fyzického modelu a reverzní inženýrství. Tyto problémy budou podrobněji popsány v budoucích publikacích.

Sběr požadavků na využití dat

Požadavky na využití dat obvykle shromažďujete brzy během pohovorů a pracovních setkání. Požadavky by zároveň měly co nejúplněji definovat používání dat uživatelem. Povrchní přístup a mezery ve fyzickém modelu mohou vést k neplánovaným nákladům a zpozdit projekt. Požadavky na použití zahrnují:

Požadavky na přístup a výkon

Objemové charakteristiky (odhad množství dat k uložení), které umožňují správci reprezentovat fyzický objem databáze

Odhad počtu uživatelů, kteří potřebují přistupovat k datům souběžně, což vám pomůže navrhnout databázi na přijatelnou úroveň výkonu

Souhrn, souhrn a další vypočítaná nebo odvozená data, která mohou být považována za kandidáty pro uložení v trvalých datových strukturách

Požadavky na generování sestav a standardních dotazů, které pomohou správci databáze vytvářet indexy

Pohledy (trvalé nebo virtuální), které uživateli pomohou při provádění operací slučování nebo filtrování dat.

Kromě předsedy, tajemníka a uživatelů by relace požadavků na použití měla zahrnovat modeláře, správce databáze a architekta databáze. Měly by být prodiskutovány požadavky uživatelů na historická data. Doba, po kterou jsou data uložena, má významný dopad na velikost databáze. Často jsou starší data uložena v agregované formě a atomická data jsou archivována nebo mazána.

Uživatelé by si měli na relaci přinést vzorové dotazy a sestavy. Zprávy musí být přesně definovány a musí obsahovat atomické hodnoty použité pro všechna souhrnná a souhrnná pole.

Komponenty fyzického datového modelu

Komponenty fyzického datového modelu jsou tabulky, sloupce a vztahy. Entity v logickém modelu se pravděpodobně stanou tabulkami ve fyzickém modelu. Booleovské atributy se stanou sloupci. Logické vztahy se stanou omezeními integrity vztahů. Některé logické vztahy nelze implementovat ve fyzické databázi.

reverzní inženýrství

Když logický model není k dispozici, je nutné znovu vytvořit model ze stávající databáze. U ERwin se tento proces nazývá reverzní inženýrství. Reverzní inženýrství lze provést několika způsoby. Modelář může prozkoumat datové struktury v databázi a znovu vytvořit tabulky v prostředí vizuálního modelování. Jazyk definice dat (DDL) můžete importovat do nástroje, který podporuje reverzní inženýrství (např. Erwin). Pokročilé nástroje, jako je ERwin, zahrnují funkce, které poskytují ODBC komunikaci s existující databází pro vytvoření modelu přímým čtením datových struktur. Reverzní inženýrství pomocí ERwin bude podrobně diskutováno v budoucí publikaci.

Použití firemních funkčních hranic

Při vytváření logického modelu je pro modeláře důležité zajistit, aby nový model odpovídal podnikovému modelu. Použití firemních funkčních hranic znamená modelování dat v termínech používaných v rámci korporace. Způsob, jakým jsou data v korporaci využívána, se mění rychleji než data samotná. V každém logickém modelu musí být data reprezentována holisticky, bez ohledu na obchodní doménu, kterou podporuje. Entity, atributy a vztahy by měly definovat obchodní pravidla na podnikové úrovni.

POZNÁMKA Někteří z mých kolegů označují tyto podnikové funkční hranice jako modelování v reálném světě. Modelování v reálném světě povzbuzuje modeláře, aby prohlížel informace z hlediska jejich reálných vztahů a vztahů.

Použití podnikových funkčních hranic pro správně sestavený datový model poskytuje rámec pro podporu informačních potřeb libovolného počtu procesů a aplikací, což umožňuje korporaci efektivněji využívat jedno ze svých nejcennějších aktiv, informace.

Co je podnikový datový model?

Enterprise Data Model (EDM) obsahuje entity, atributy a vztahy, které představují informační potřeby korporace. EDM se obvykle dělí na tematické oblasti, které představují skupiny subjektů souvisejících s podporou specifických obchodních potřeb. Některé předmětové oblasti mohou pokrývat specifické obchodní funkce, jako je správa smluv, jiné mohou seskupovat subjekty, které popisují produkty nebo služby.

Každý logický model musí odpovídat existující doméně podnikového datového modelu. Pokud logický model tento požadavek nesplňuje, je třeba k němu přidat model, který definuje předmětnou oblast. Toto srovnání zajišťuje, že je korporátní model vylepšen nebo upraven a veškeré úsilí o logické modelování je koordinováno v rámci korporace.

EDM zahrnuje také konkrétní entity, které definují rozsah hodnot pro klíčové atributy. Tyto entity nemají rodiče a jsou definovány jako nezávislé. K udržení integrity vztahů se často používají nezávislé entity. Tyto entity jsou identifikovány několika různými názvy, jako jsou tabulky kódů, tabulky odkazů, tabulky typů nebo klasifikační tabulky. Budeme používat termín „firemní předmět podnikání“. Podnikový obchodní objekt je entita, která obsahuje sadu hodnot atributů, které jsou nezávislé na jakékoli jiné entitě. Podnikové obchodní objekty v rámci korporace by měly být používány konzistentně.

Vytvoření podnikového datového modelu pomocí škálování

Existují organizace, kde byl firemní model od začátku do konce vybudován jako výsledek jediného soustředěného úsilí. Na druhou stranu většina organizací buduje poměrně kompletní podnikové modely budováním.

Růst znamená budovat něco postupně, vrstvu po vrstvě, stejně jako ústřice roste perla. Každý vytvořený datový model poskytuje vstup pro vytvoření EDM. Budování EDM tímto způsobem vyžaduje další kroky modelování pro přidání nových datových struktur a domén nebo rozšíření stávajících datových struktur. To umožňuje vytvořit podnikový datový model vytvářením, opakovaným přidáváním úrovní detailů a zpřesňování.

Pojem metodologie modelování

Existuje několik metod pro modelování vizuálních dat. ERwin podporuje dva:

IDEF1X (Definice integrace pro informační modelování - integrovaný popis informačních modelů).

IE (Information Engineering - informační inženýrství).

IDEF1X je dobrá metodika a její zápis je široce používán

Integrovaný popis informačních modelů

IDEF1X je vysoce strukturovaná metodika modelování dat, která rozšiřuje metodologii IDEF1 přijatou jako standard FIPS (Federal Information Processing Standards). IDEF1X využívá vysoce strukturovanou sadu typů modelovacích konstrukcí a vede k datovému modelu, který vyžaduje pochopení fyzické podstaty dat, než mohou být takové informace zpřístupněny.

Pevná struktura IDEF1X nutí modeláře přiřazovat entitám charakteristiky, které nemusí odpovídat realitě okolního světa. Například IDEF1X vyžaduje, aby všechny podtypy entit byly výhradní. To vede k tomu, že člověk nemůže být zároveň klientem i zaměstnancem. Zatímco skutečná praxe nám říká opak.

Informační inženýrství

Clive Finklestein je často označován za otce informačního inženýrství, ačkoli s ním James Martin sdílel podobné koncepty (Martin, James. Managing the Database Environment. Upper Saddle River, New Jersey: Prentice Hall, 1983.). Informační inženýrství používá ke správě informací obchodní přístup a k reprezentaci obchodních pravidel používá jinou notaci. IE slouží jako rozšíření a rozvoj zápisu a základních konceptů metodiky ER navržené Peterem Chenem.

IE poskytuje infrastrukturu pro podporu požadavků na informace integrací podnikového strategického plánování s vyvíjenými informačními systémy. Taková integrace umožňuje těsněji propojit správu informačních zdrojů s dlouhodobými strategickými perspektivami společnosti. Tento obchodní přístup vede mnoho modelářů k tomu, aby zvolili IE před jinými metodikami, které se primárně zaměřují na řešení problémů okamžitého vývoje.

IE poskytuje pracovní postup, který vede společnost k identifikaci všech jejích informačních potřeb ke shromažďování a správě dat a identifikaci vztahů mezi informačními objekty. V důsledku toho jsou požadavky na informace formulovány na základě manažerských směrnic a lze je přímo převést do manažerského informačního systému, který bude podporovat strategické informační potřeby.

Závěr

Pochopení toho, jak používat nástroj pro modelování dat, jako je ERwin, je pouze částí problému. Kromě toho musíte rozumět tomu, kdy se provádějí úlohy datového modelování a jak se shromažďují požadavky na informace a obchodní pravidla, aby byly reprezentovány v datovém modelu. Vedení pracovních setkání poskytuje nejpříznivější podmínky pro shromažďování požadavků na informace v prostředí, které zahrnuje odborníky na předmět, uživatele a specialisty na informační technologie.

Vytvoření dobrého datového modelu vyžaduje analýzu a průzkum požadavků na informace a obchodních pravidel shromážděných během pracovních setkání a pohovorů. Výsledný datový model by měl být pokud možno porovnán s podnikovým modelem, aby bylo zajištěno, že nebude v konfliktu s existujícími objektovými modely a bude obsahovat všechny požadované objekty.

Datový model se skládá z logických a fyzických modelů reprezentujících informační požadavky a obchodní pravidla. Logický model je třeba zredukovat na třetí normální formu. Třetí normální formulář omezuje, přidává, aktualizuje a odstraňuje anomálie datové struktury, aby podpořil princip „jeden fakt, jedno místo“. Shromážděné požadavky na informace a obchodní pravidla by měly být analyzovány a prozkoumány. Je třeba je porovnat s podnikovým modelem, aby bylo zajištěno, že nebudou v konfliktu s existujícími objektovými modely a že budou obsahovat všechny požadované objekty.

V ERwin datový model zahrnuje logické i fyzické modely. ERwin implementuje přístup ER a umožňuje vám vytvářet objekty logického a fyzického modelu, které reprezentují požadavky na informace a obchodní pravidla. Objekty logického modelu zahrnují entity, atributy a vztahy. Objekty fyzického modelu zahrnují tabulky, sloupce a omezení integrity vztahů.

V jedné z následujících publikací se budeme zabývat otázkami identifikace entit, určováním typů entit, výběrem názvů a popisů entit a také některými triky, jak se vyhnout nejběžnějším chybám modelování souvisejícím s používáním entit.

Entity musí mít úplnou sadu atributů, aby každý fakt o každé entitě mohl být reprezentován jejími atributy. Každý atribut musí mít název, který odráží jeho hodnoty, booleovský datový typ a jasný, krátký, úplný popis nebo definici. V jedné z následujících publikací se budeme zabývat počáteční sadou doporučení pro správné tvoření názvů a popisů atributů. Vztahy by měly obsahovat slovesnou konstrukci, která popisuje vztah mezi entitami, spolu s charakteristikami, jako je pluralita, potřeba existence nebo možnost neexistence vztahu.

POZNÁMKA Množství vztahy popisují maximální počet instancí sekundární entity, které lze přidružit k instanci původní entity.Nutnost existence nebo možnost nepřítomnosti vztah se používá k určení minimálního počtu instancí sekundární entity, které mohou být spojeny s instancí původní

Chcete-li prodat, musíte rozumět tomu, co prodáváte.

Pojďme si definovat terminologii a pojmy. ( Datový sklad) není systém klíčových ukazatelů výkonnosti (KPI, KPI), nejedná se o rozsáhlou databázi, nejedná se o analytickou nástroj OLAP, nejedná se o inteligentní systém, který umožňuje extrahovat nová data a získávat statistické závislosti, nejedná se o systém jednotného NSI - toto není CD, pokud o něm mluvíme v kontextu jediné položky.

Enterprise Data Warehouse – jedná se o speciálně organizované datové pole podniku (organizace), zpracované a uložené v jediném hardwarovém a softwarovém komplexu, které poskytuje rychlý přístup k provozním a historickým informacím, multidimenzionální analýzu dat (KPI pro různá měření), získávání prognóz a statistik v kontextu dohodnutých regulačních referenčních informací (NSI).

Potenciální zákazníci pro firemní datový sklad a co získají?

Jak identifikovat potenciální firemní klienty, kteří potřebují datový sklad?

V první řadě by mnoho informací mělo vzniknout v každodenní činnosti firmy. Mohou to být telefonní hovory, finanční transakce, stížnosti/recenze zákazníků, požadavky zákazníků na odeslání, informace ze špionážních satelitů atd. V zásadě cokoliv, hlavní je, že dat je hodně.
Potenciální klient by měl mít touhu tyto informace vidět a analyzovat. Zároveň by doba analýzy měla být poměrně rozsáhlá - od jednoho dne nebo dokonce hodiny až po analýzu několika let.
Klient musí mít normálně fungující infrastrukturu (nesmí být žádné servery připojené kroucenou dvojlinkou nebo USB portem). Pokud klient nemá infrastrukturu, potřebuje ji prodat.

Jaké výhody získá klient z implementace podnikového datového skladu?

Objevuje se jednotný systém ukládání informací pro podniková data, ve kterém se používá jedna referenční informace.
Je zde možnost provést komplexní analýzu podniku. Například: kteří klienti jsou nejziskovější a nejziskovější; jakou službu, kteří klienti jsou nejžádanější, jaké jsou nejčastější reklamace a v jakých regionech atd.
Je možné provádět analýzu pomocí historických dat. Operační systémy (automatizace každodenních obchodních procesů) to často neumožňují, prostě nemají dostatek místa pro uložení historie a sílu provádět analýzy.
Je možné propojit a analyzovat informace dříve uložené v různých informačních systémech. Například provozní data různých poboček jsou uložena ve fakturačních systémech od různých vývojářů. Po implementaci datového skladu je možné je analyzovat společně v jedné zprávě.
Je možné analyzovat a křížit různé typy dat. Například peníze a provoz, počet zaměstnanců a počet zamítnutí nebo reklamací atd.
Existuje základ pro lepší kalkulaci nákladů na služby – na základě informací z podnikového datového skladu je možné získat adekvátnější data pro přirozené distribuční základny.

Co je firemní datový sklad

Jaké komponenty tvoří podnikový datový sklad z technického hlediska?

Komponenty firemní datový sklad podniky

Klient má vždy operační systémy - zdroje dat pro firemní datový sklad. Jedná se např. o účetnictví, fakturaci, bankovnictví atp. systémy.
Použitím Aplikace ETL(software, který umožňuje extrahovat, transformovat a načítat data), data ze zdrojových systémů vstupují do databáze datového skladu. Jako nástroj ETL lze použít: Informatica Power Center, IBM DataStage, Oracle Data Integrator, Oracle WareHouse Builder. Existují také produkty jiných prodejců, ale na ruském trhu téměř nejsou zastoupeny.
Sám databáze podnikové úložiště není svou strukturou abstraktní (soubor tabulek, polí v nich a vztahů mezi tabulkami), ale je vytvořeno na základě datové modely. Naprostá většina databází používá buď Oracle nebo Teradata.
Datový model je popis všech entit, databázových objektů podnikového datového skladu a zahrnuje: koncepční datový model, logický datový model a fyzický databázový model . Na úrovni konceptuálního modelu jsou definovány entity a vztahy mezi nimi. Na úrovni logického modelu jsou entity rozděleny do oblastí podnikání, je jim uveden podrobný a úplný popis a jsou předepsány vztahy. Při vývoji fyzického databázového modelu je určena celá struktura databáze – od tabulek a polí v nich až po oddíly a indexy. Datové modelyIBM, SAP a Oracle dnes zásobují trh, ale nákup datového modelu neznamená automatické vybudování správného podnikového obchodu.Datový model Toto není krabicový produkt. Je potřeba ji upravit tak, aby vyhovovala potřebám konkrétního klienta.
Dále již s využitím dat z podnikového datového skladu, oblastí analýzy, reportingu a datové trhy. Následně mohou uživatelé nezávisle vytvářet potřebné reporty a provádět vícerozměrné analýzy. Jako analytické nástroje se používají především Business Objects, Oracle Discoverer, IBM AlphaBlocks a další produkty.

Jak vypadají komponenty podnikového datového skladu (datový model, ETL procesy, datové tržiště)

Uveďme si názorné příklady datového modelu, implementace ETL procesu, formy podpory pro jednotná referenční data, data marts.

Logický modeldata.
Definuje entity, jejich atributy a vztahy mezi nimi.

ETL procesodstranění duplicit ve zdrojových datech

Formulář pro zadávání dat pro vytvoření jednoho adresáře

datový trhve formě tabulkové zprávy

datový trhs grafikou a barvou
výstup dat podle dané podmínky

datový trhs rozvrhem

Související software a hardware

Především se kromě samotných služeb pro vývoj podnikového datového skladu prodávají také licence jak na serverový software (OS, databáze, aplikační server atd.), tak na klientské stránky (antivirové nástroje ochrany a zabezpečení) .

Je možné, že stávající servery klienta nejsou navrženy pro nasazení datového skladu. Je potřeba na ně vznést požadavky a prodat hardware potenciálnímu klientovi.

Kromě samotných serverů jsou k ukládání značného množství informací potřeba i disková pole.

Potenciální klient, který má v úmyslu vybudovat podnikový datový sklad, ne vždy rozumí tomu, jak zajistí redundanci. Stávající zálohovací systémy klienta často nejsou schopny současně připojit k záloze objemy dat od 20-30 TB.

Specialisté a uživatelé klienta zpravidla vyžadují školení.

Kovtun M.V. srpna 2010

Odeslat svou dobrou práci do znalostní báze je jednoduché. Použijte níže uvedený formulář

Studenti, postgraduální studenti, mladí vědci, kteří využívají znalostní základnu při svém studiu a práci, vám budou velmi vděční.

Vloženo na http://www.allbest.ru/

1. Relační datový model

1.1 Relační datový model. Základní definice
1.2 Operace se vztahy

2. Firemní informační systémy
Bibliografie

1. Relační datový model

1.1 Relační datový model. Základní definice

V matematických disciplínách pojem „tabulka“ odpovídá pojmu „vztah“ (relace). Tabulka odráží objekt reálného světa – entitu, a každý její řádek odráží konkrétní instanci entity. Každý sloupec má pro tabulku jedinečný název. Řetězce nemají názvy, jejich pořadí není definováno a jejich počet není logicky omezen. Jednou z hlavních výhod relačního datového modelu je homogenita (každý řádek tabulky má jeden formát). O tom, zda mají odpovídající entity homogenitu, rozhoduje sám uživatel. Tím je problém vhodnosti modelu vyřešen.

Základní pojmy:

* Relace je dvourozměrná tabulka obsahující nějaká data.

* Entita - objekt jakékoli povahy, o kterém jsou data uložena v databázi. Atributy - vlastnosti, které charakterizují entitu (sloupce).

* Stupeň vztahu - počet sloupců.

* Schéma vztahu - seznam jmen atributů, například ZAMĚSTNANEC (č., celé jméno, rok narození, pozice, oddělení).

* Doména - sada hodnot atributů vztahu (datový typ).

* Tuple - řádek tabulky.

* Mohutnost (mocnost) - počet řádků v tabulce.

* Primární klíč je atribut, který jednoznačně identifikuje řádky ve vztahu. Primární klíč s více atributy se nazývá složený klíč. Primární klíč nemůže být zcela nebo částečně prázdný (má hodnotu null). Klíče, které lze použít jako primární klíče, se nazývají kandidátní nebo alternativní klíče.

* Cizí klíč je atribut(y) jedné tabulky, který může sloužit jako primární klíč jiné tabulky. Je odkazem na primární klíč jiné tabulky.

Normalizace je proces zaměřený na snížení redundance informací v databázi. Kromě samotných dat lze v databázi normalizovat také různé názvy, názvy objektů a výrazy.

Nenormalizovaná databáze obsahuje informace v jedné nebo více různých tabulkách; to vytváří dojem, že zahrnutí dat do konkrétní tabulky není způsobeno žádnými zjevnými důvody. Tento stav věcí může mít negativní dopad na bezpečnost dat, správu místa na disku, rychlost dotazování, efektivitu aktualizace databáze a možná nejdůležitější je integrita uložených informací. Databáze před normalizací je struktura, která dosud nebyla logicky rozčleněna do lépe ovladatelných menších tabulek.

Normální forma je druh indikátoru úrovně nebo hloubky normalizace databáze. Úroveň normalizace databáze odpovídá normální formě, ve které se nachází.

1.2 Operace se vztahy

Chcete-li převést tabulku do první normální formy (1NF), je třeba dodržovat dvě pravidla:

1. Atomicita nebo nedělitelnost. Každý sloupec musí obsahovat jednu nedělitelnou hodnotu.

2. Tabulka by neměla obsahovat opakující se sloupce nebo datové skupiny.

Pokud například tabulka obsahuje v jednom poli úplnou adresu osoby (ulice, město, PSČ), nebude v souladu s pravidly 1NF, protože bude obsahovat různé hodnoty v jednom sloupci, který bude porušení pravidla atomicity. Nebo pokud databáze obsahuje data o filmech a má sloupce herec1, herec2, herec3, také nebude splňovat pravidla, protože se budou data opakovat.

Normalizace by měla začít kontrolou kompatibility struktury databáze s 1NF. Všechny sloupce, které nejsou atomární, musí být rozděleny na jednotlivé sloupce. Pokud má tabulka duplicitní sloupce, je třeba alokovat samostatnou tabulku.

Chcete-li převést tabulku do prvního normálního tvaru:

* Najděte všechna pole, která obsahují více informací.

* Údaje, které lze rozdělit na jednotlivé části, musí být umístěny v samostatných polích.

* Přesunout duplicitní data do samostatné tabulky.

* Zkontrolujte, zda všechny tabulky vyhovují podmínkám prvního normálního formuláře.

Pro převod tabulek do druhé normální formy (2NF) musí být výsledné tabulky již v 1NF. Normalizace musí být provedena v pořádku.

Nyní, ve druhé normální formě, musí být splněna podmínka - každý sloupec, který není klíčem (včetně cizích), musí záviset na primárním klíči. Tyto sloupce, které mají hodnoty, které nezávisí na klíči, lze obvykle snadno identifikovat. Pokud data obsažená ve sloupci nesouvisí s klíčem, který popisuje řádek, měla by být rozdělena do vlastní samostatné tabulky. Primární klíč musí být vrácen do staré tabulky.

Chcete-li převést základnu na druhou normální formu:

* Identifikujte všechny sloupce, které nejsou přímo závislé na primárním klíči této tabulky.

* Vytvořte potřebná pole v tabulkách uživatelů a fór, vyberte ze stávajících polí nebo vytvořte primární klíče z nových.

* Každá tabulka potřebuje svůj vlastní primární klíč

* Vytvářejte cizí klíče a označujte jejich vztahy mezi tabulkami. Posledním krokem normalizace na 2NF bude přidělení cizích klíčů pro asociaci s přidruženými tabulkami. Primární klíč jedné tabulky musí být cizím klíčem jiné tabulky.

Tipy:

Dalším způsobem, jak vytvořit schéma 2NF, je podívat se na vztahy mezi tabulkami. Ideální možností je vytvořit všechny vztahy one-to-many. Vztahy mnoho k mnoha je třeba restrukturalizovat.

Správně normalizovaná tabulka nikdy nebude mít duplicitní řádky (dva nebo více řádků, jejichž hodnoty nejsou klíče a obsahují stejná data).

Databáze bude ve třetí normální formě, pokud je přetypována do druhé normální formy a každý neklíčový sloupec je na sobě nezávislý. Pokud je proces normalizace dodržován správně až do tohoto bodu, nemusí být se snížením na 3NF žádné problémy. Měli byste si být vědomi toho, že 3NF je porušeno, pokud změna hodnoty v jednom sloupci vyžaduje změnu v jiném sloupci.

Chcete-li převést základ na třetí normální formu:

* Určete, ve kterých polích kterých tabulek existuje vzájemná závislost, tzn. pole, která na sobě závisí více než na řadě jako celku.

* Vytvořte příslušné tabulky. Pokud je v kroku 1 problematický sloupec, vytvořte pro něj samostatné tabulky.

* Vytvořte nebo přidělte primární klíče. Každá tabulka musí mít primární klíč.

* Vytvořte potřebné cizí klíče, které tvoří jakýkoli ze vztahů.

Ve čtvrté normální formě je dalším pravidlem vyloučení vícehodnotových závislostí. Jinými slovy, všechny řádky tabulky musí být na sobě nezávislé. Přítomnost nějakého řádku X by neměla znamenat, že řádek Y je také někde v této tabulce.

2. Podnikové informační systémy

datový systém relačního modelu

Systém (z řeckého systema - celek, spojení tvořené částmi) je soubor prvků vzájemně se ovlivňujících, tvořících určitou celistvost, jednotu. Zde jsou některé pojmy, které se často používají k charakterizaci systému.

1. Prvek systému -- část systému, která má konkrétní funkční účel. Složité prvky systémů, sestávající z jednodušších vzájemně propojených prvků, se často nazývají subsystémy.

2. Organizace systému - vnitřní řád, důslednost v interakci prvků systému, která se projevuje zejména omezováním různorodosti stavů prvků uvnitř systému.

3. Struktura systému - složení, pořadí a principy vzájemného působení prvků systému, které určují základní vlastnosti systému. Pokud jsou jednotlivé prvky systému odděleny různými úrovněmi a vnitřní vazby mezi prvky jsou organizovány pouze od vyšších úrovní k nižším a naopak, pak hovoří o hierarchické struktuře systému. Čistě hierarchické struktury jsou prakticky vzácné, proto, když tento pojem poněkud rozšíříme, pod hierarchickou strukturou se obvykle rozumějí takové struktury, kde mají, kromě jiných spojení, prvořadý význam právě hierarchická spojení.

4. Architektura systému -- soubor vlastností systému, které jsou pro uživatele zásadní.

5. Integrita systému - zásadní neredukovatelnost vlastností systému na součet vlastností jeho jednotlivých prvků (vznik vlastností) a zároveň závislost vlastností každého prvku na jeho místo a funkci v systému.

Informační systém je propojený soubor prostředků, metod a pracovníků sloužících k ukládání, zpracování a vydávání informací za účelem dosažení cíle“

Federální zákon „o informacích, informatizaci a ochraně informací“ poskytuje následující definici:

„Informační systém je organizačně uspořádaný soubor dokumentů (souborů dokumentů) a informačních technologií, včetně využití výpočetní techniky a komunikačních nástrojů, které realizují informační procesy“

Klasifikace stupnice

Podle měřítka se informační systémy dělí do následujících skupin:

* svobodný;

* skupina;

* firemní.

Podnikový informační systém je škálovatelný systém určený pro komplexní automatizaci všech typů ekonomických činností velkých a středních podniků, včetně korporací tvořených skupinou společností, které vyžadují jednotné řízení.

Za podnikový informační systém lze považovat systém, který automatizuje více než 80 % divizí společnosti.

V poslední době se v mnoha publikacích věnujících se využití informačních technologií při správě ekonomických objektů často používá pojem „podnikové informační systémy“, který označuje skutečné automatizované informační systémy ekonomických objektů.

Automatizovaný informační systém (AIS) je kombinací různých typů podpory a specialistů určených k automatizaci zpracování účetních a analytických informací. Typy podpor z hlediska složení jsou pro různé systémy zpravidla homogenní, což umožňuje realizovat princip kompatibility systémů v průběhu jejich provozu. V procesu studia AIS jako komplexního systému je nutné vyčlenit jednotlivé části a prvky a zvážit vlastnosti jejich použití ve fázích tvorby a provozu.

Podnikové informační systémy jsou evolucí systémů pro pracovní skupiny, jsou zaměřeny na velké společnosti a mohou podporovat geograficky rozptýlené uzly nebo sítě. V zásadě mají hierarchickou strukturu několika úrovní. Takové systémy se vyznačují architekturou klient-server se specializací serverů nebo víceúrovňovou architekturou. Při vývoji takových systémů lze použít stejné databázové servery jako při vývoji skupinových informačních systémů. Ve velkých informačních systémech jsou však nejpoužívanější servery Oracle, DB2 a Microsoft SQL Server.

U skupinových a podnikových systémů se výrazně zvyšují požadavky na spolehlivost provozu a bezpečnost dat. Tyto vlastnosti jsou poskytovány udržováním integrity dat, odkazů a transakcí na databázových serverech.

Klasifikace podle rozsahu

Podle rozsahu informačních systémů se obvykle dělí do čtyř skupin:

* systémy zpracování transakcí;

* systémy rozhodování;

* informační a referenční systémy;

* kancelářské informační systémy.

Bibliografie

1. Agaltsov, V.P. Databáze. Ve 2 svazcích V. 2. Distribuované a vzdálené databáze: Učebnice / V.P. Agalcov. - M.: ID FORUM, SIC INFRA-M, 2013.

2. Golitsyna, O.L. Databáze: Učebnice / O.L. Golitsyna, N.V. Maksimov, I.I. Popov. - M.: Fórum, 2012.

3. Karpová, I.P. Databáze: Učebnice / I.P. Karpov. - Petrohrad: Petr, 2013.

4. Kirillov, V.V. Úvod do relačních databází Úvod do relačních databází / V.V. Kirillov, G.Yu. Gromov. - Petrohrad: BHV-Petersburg, 2012.

5. Pirogov, V.Yu. Informační systémy a databáze: organizace a design: Učebnice / V.Yu. Pirogov. - Petrohrad: BHV-Petersburg, 2009.

6. G.N. Fedorov. Informační systémy. - M.: Akademie, 2013.

7. A.E. Satunina, L.A. Sysoev. Projektové řízení podnikového informačního systému podniku. - M.: Finance a statistika, Infra-M, 2009.

Hostováno na Allbest.ru

...

Podobné dokumenty

Podstata a charakteristika typů datových modelů: hierarchické, síťové a relační. Základní pojmy relačního datového modelu. Atributy, schéma vztahu databáze. Podmínky integrity dat. Vztahy mezi tabulkami. Obecné představy o datovém modelu.

semestrální práce, přidáno 29.01.2011

Podnikové informační systémy a databáze, jejich využití pro zlepšování a odlaďování obchodu. Klasifikace podnikových informačních systémů. Informační systémy třídy OLTP. Operativně analytické zpracování.

semestrální práce, přidáno 19.01.2011

Databáze s dvourozměrnými soubory a systémy pro správu relačních databází (DBMS). Vytvoření databáze a zpracování dotazů na ně pomocí DBMS. Základní typy databází. Základní pojmy relačních databází. Základní vlastnosti vztahů.

abstrakt, přidáno 20.12.2010

Pojem databázový systém. Relační model a jeho charakteristiky. Integrita v relačním modelu. Relační algebra. Problémy s návrhem databáze. normální formy vztahu. Návrh databáze metodou entitního vztahu. ER diagramy. jazyk SQL.

průběh přednášek, přidáno 03.10.2008

Specifická logická struktura dat, která jsou uložena v databázi. Základní datové modely. Prvky relačního datového modelu. Příklad použití cizích klíčů. Hlavní požadavky na vztahy relačního datového modelu.

prezentace, přidáno 14.10.2013

Databáze a jejich využití ve výpočetní technice. Vlastnosti a základní strukturní jednotka datového modelu sítě. Hierarchický model, doménové objekty. Relační model, jeho viditelnost, prezentace dat v tabulkové formě.

abstrakt, přidáno 19.12.2011

Typy a funkce databázového systému Microsoft Access. Hierarchický, síťový, relační model popisu databáze. Základní pojmy databázové tabulky. Vlastnosti vytváření databázových objektů, základní formuláře. Přístup k internetu v Access.

kontrolní práce, přidáno 01.08.2011

Moderní systémy pro správu databází (DBMS). Analýza hierarchického datového modelu. Relační datový model. Postrelační datový model jako rozšířený relační model, který odstraňuje omezení nedělitelnosti dat uložených v tabulkových záznamech.

vědecká práce, přidáno 06.08.2010

Datové modely ve správě databází. Koncepční datové modely. Role databází v informačních systémech. Relační datový model. Vymezení předmětné oblasti. Vybudování databázového modelu pro informační systém "Pets".

semestrální práce, přidáno 19.04.2011

Informační model v Accessu jako nějaká zjednodušená náhrada za skutečný objekt nebo systém. Základní struktury, které definují organizaci dat a vztahy mezi nimi; relační typ organizace dat. Příklad databáze v oblasti daní.

Zaitsev S.L., Ph.D.

Opakující se skupiny

Rýže. 1.6. Tento příklad používá opakující se skupiny.

Rýže. 1.7. Model zredukován do první normální podoby.

Jeden fakt na jednom místě

Pokud je stejný atribut přítomen ve více než jedné entitě a nejde o cizí klíč, je tento atribut považován za nadbytečný. Logický model by neměl obsahovat redundantní data.

Každý atribut závisí na klíči

Rýže. 1.9. Ve třetí normální formě Školní jméno a Zeměpisná oblast přesunuty do entity, kde jejich hodnoty závisí na klíči.

Mnoho k mnoha vztahům

Formální definice normálních forem

Relace R je v první normální formě (1NF) právě tehdy, když všechny jeho domény obsahují pouze atomární hodnoty (Datum, tamtéž).

Relace R je ve druhé normální formě (2NF) právě tehdy, když je v 1NF a každý neklíčový atribut je plně závislý na primárním klíči (Datum, ibid.).

Relace R je ve třetí normální formě (3NF) právě tehdy, když je v 2NF a každý neklíčový atribut není tranzitivně závislý na primárním klíči (Datum, tamtéž).

Vztah R je v Boyce-Coddově normální formě (BCNF) právě tehdy, když je každý determinant kandidátem na použití jako klíč.

POZNÁMKA Níže je stručné vysvětlení některých zkratek používaných v definicích Date.

FD (functional dependency) - funkční závislost. Ve funkční závislosti závisí hodnota atributu na hodnotě jiného atributu, který není součástí primárního klíče.

Obchodní normální formuláře

Třetí obchodní normální forma (3BNF) přesouvá atributy, které nejsou závislé na primárním klíči, do jiné entity, kde jsou zcela závislé na primárním klíči této entity.

Dokončený logický datový model

Vztahy by měly obsahovat slovesnou konstrukci, která popisuje vztah mezi entitami, spolu s charakteristikami, jako je pluralita, potřeba existence nebo možnost neexistence vztahu.

Fyzický datový model

Sběr požadavků na využití dat

Požadavky na přístup a výkon

Objemové charakteristiky (odhad množství dat k uložení), které umožňují správci reprezentovat fyzický objem databáze

Odhad počtu uživatelů, kteří potřebují přistupovat k datům souběžně, což vám pomůže navrhnout databázi na přijatelnou úroveň výkonu

Souhrn, souhrn a další vypočítaná nebo odvozená data, která mohou být považována za kandidáty pro uložení v trvalých datových strukturách

Požadavky na generování sestav a standardních dotazů, které pomohou správci databáze vytvářet indexy

Pohledy (trvalé nebo virtuální), které uživateli pomohou při provádění operací slučování nebo filtrování dat.

Uživatelé by si měli na relaci přinést vzorové dotazy a sestavy. Zprávy musí být přesně definovány a musí obsahovat atomické hodnoty použité pro všechna souhrnná a souhrnná pole.

Komponenty fyzického datového modelu

reverzní inženýrství

Použití firemních funkčních hranic

Co je podnikový datový model?

Vytvoření podnikového datového modelu pomocí škálování

Pojem metodologie modelování

Existuje několik metod pro modelování vizuálních dat. ERwin podporuje dva:

IDEF1X (Definice integrace pro informační modelování - integrovaný popis informačních modelů).

IE (Information Engineering - informační inženýrství).

IDEF1X je dobrá metodika a její zápis je široce používán

Integrovaný popis informačních modelů

Informační inženýrství

Závěr

IT profesionálové stále častěji obracejí svou pozornost k řešením správy dat založeným na průmyslových standardních datových modelech a šablonách obchodních rozhodnutí. Složité modely fyzických dat připravené k načtení a reporty business intelligence pro konkrétní oblasti činnosti umožňují sjednotit informační složku podniku a výrazně urychlit provádění obchodních procesů. Šablony řešení umožňují poskytovatelům služeb využít sílu nestandardních informací skrytých ve stávajících systémech, a tím snížit časové plány, náklady a rizika projektů. Například skutečné projekty ukazují, že datový model a šablony obchodních rozhodnutí mohou snížit vývojové úsilí o 50 %.

Odvětvový logický model je doménově specifický, integrovaný a logicky strukturovaný pohled na všechny informace, které by měly být ve firemním datovém skladu, aby odpovídaly strategické i taktické obchodní otázky. Hlavním účelem modelů je usnadnit orientaci v datovém prostoru a pomoci při zvýraznění detailů, které jsou důležité pro rozvoj podnikání. V dnešním podnikatelském prostředí je naprosto nezbytné mít jasnou představu o vztazích mezi různými složkami a dobře porozumět celkovému obrazu organizace. Identifikace všech detailů a vztahů pomocí modelů umožňuje co nejefektivnější využití času a nástrojů pro organizaci práce firmy.

Datové modely jsou abstraktní modely, které popisují, jak jsou data reprezentována a jak se k nim přistupuje. Datové modely definují datové prvky a vztahy mezi nimi v dané oblasti. Datový model je navigační nástroj pro obchodní i IT profesionály, který používá specifickou sadu symbolů a slov k přesnému vysvětlení konkrétní třídy skutečných informací. To zlepšuje komunikaci v rámci organizace a vytváří tak flexibilnější a stabilnější aplikační prostředí.

Příklad modelu GIS pro úřady a místní samosprávu.

Dnes je strategicky důležité, aby poskytovatelé softwaru a služeb byli schopni rychle reagovat na změny v odvětví spojené s technologickými inovacemi, odstraňováním vládních omezení a složitostí dodavatelských řetězců. Spolu se změnami v obchodním modelu roste i složitost a náklady na informační technologie nezbytné pro podporu aktivit společnosti. Správa dat je obtížná zejména v prostředí, kde se podnikové informační systémy a jejich funkční a obchodní požadavky neustále mění.

Aby se tento proces usnadnil a optimalizoval, při převádění přístupu IT na moderní úroveň se používají průmyslové datové modely.

Odvětvové datové modely od společnostiEsri

Datové modely pro platformu Esri ArcGIS jsou pracovní šablony pro použití v projektech GIS a vytváření datových struktur pro různé aplikační oblasti. Sestavení datového modelu zahrnuje vytvoření koncepčního návrhu, logické struktury a fyzické struktury, které lze následně použít k vytvoření osobní nebo podnikové geodatabáze. ArcGIS poskytuje nástroje pro vytváření a správu databázového schématu a šablony datových modelů se používají k rychlému spuštění projektu GIS v různých aplikacích a odvětvích. Společnost Esri spolu s komunitou uživatelů strávila značné množství času vývojem řady šablon, které vám mohou pomoci rychle začít navrhovat podnikovou geodatabázi. Tyto projekty jsou popsány a zdokumentovány na adrese support.esri.com/datamodels. Níže, v pořadí, v jakém se objevují na tomto webu, jsou sémantické překlady názvů průmyslových modelů Esri:

Registr adres
Zemědělství
Meteorologie
Základní prostorová data
Biodiverzita
Vnitřní prostor budov
Účetnictví skleníkových plynů
Údržba administrativních hranic
Vojenské zřízení. Zpravodajská služba
Energie (včetně nového protokolu ArcGIS MultiSpeak)
Ekologické stavby
Ministerstvo pro mimořádné situace. požární ochrana
Katastr lesa
Lesnictví
Geologie
GIS na národní úrovni (e-gov)
Podzemní a odpadní vody
zdravotní péče
Archeologie a ochrana památných míst
národní bezpečnost
Hydrologie
Mezinárodní hydrografická organizace (IHO). Formát S-57 pro ENC
Zavlažování
Katastr nemovitostí
obecní samospráva
Námořní navigace
Státní katastr
Ropné a plynové struktury
Potrubí
Rastrové obchody
Bathymetrie, topografie mořského dna
Telekomunikace
Doprava
Instalatérství, kanalizace, inženýrské sítě

Tyto modely obsahují všechny potřebné vlastnosti průmyslového standardu, jmenovitě:

jsou volně dostupné;
nejsou vázány na technologii „vybraného“ výrobce;
vytvořené jako výsledek realizace skutečných projektů;
vytvořené za účasti odborníků z oboru;
navrženy tak, aby poskytovaly informační interakci mezi různými produkty a technologiemi;
nejsou v rozporu s jinými normami a regulačními dokumenty;
používá se v realizovaných projektech po celém světě;
jsou navrženy tak, aby pracovaly s informacemi po celou dobu životního cyklu vytvářeného systému, a nikoli s projektem samotným;
rozšiřitelné podle potřeb zákazníka bez ztráty kompatibility s jinými projekty a/nebo modely;
doplněné dalšími materiály a příklady;
používá se ve směrnicích a technických materiálech různých průmyslových podniků;
velká komunita účastníků, přičemž přístup do komunity je otevřený všem;
velké množství odkazů na datové modely v publikacích v posledních letech.

Esri je součástí expertní skupiny nezávislých orgánů, které doporučují různé průmyslové modely k použití, jako jsou PODS (Pipeline Open Data Standards - otevřený standard pro ropný a plynárenský průmysl; v současné době probíhá implementace PODS jako Esri PODS Esri Spatial 5.1.1 geodatabase) nebo geodatabase (GDB) od ArcGIS for Aviation, která bere v úvahu doporučení ICAO a FAA, stejně jako standard pro výměnu navigačních dat AIXM 5.0. Kromě toho existují doporučené modely, které přísně dodržují stávající průmyslové standardy, jako je S-57 a ArcGIS for Maritime (námořní a pobřežní prvky), a také modely vytvořené z práce Esri Professional Services, které jsou „de facto“ normy v příslušných oblastech. Například GIS pro národ a místní samosprávu ovlivnily standardy NSDI a INSPIRE, zatímco Hydro a Groundwater jsou hojně využívány ve volně dostupném profesionálním balíčku ArcHydro a komerčních produktech třetích firem. Je třeba poznamenat, že Esri také podporuje „de facto“ standardy, jako je NHDI. Všechny navrhované datové modely jsou zdokumentovány a připraveny k použití v podnikových IT procesech. Mezi doprovodné materiály k modelům patří:

UML diagramy vztahů entit;
datové struktury, domény, adresáře;
hotové šablony geodatabází ve formátu ArcGIS GDB;
ukázková data a ukázkové aplikace;
příklady skriptů načítání dat, příklady analytických nástrojů;
referenční knihy o navrhované datové struktuře.

Esri shrnuje své zkušenosti s modely stavebnictví ve formě knih a lokalizuje publikované materiály. Esri CIS lokalizovala a vydala následující knihy:

Geospatial Service Oriented Architecture (SOA);
Navrhování geodatabází pro dopravu;
Firemní geoinformační systémy;
GIS: nová energie elektrických a plynárenských podniků;
Ropa a plyn na digitální mapě;
Modelování našeho světa. Průvodce návrhem geodatabáze Esri;
Přemýšlím o GIS. Plánování GIS: příručka pro manažery;
Geografické informační systémy. Základy;
GIS pro administrativní a ekonomické řízení;
Webový GIS. Principy a aplikace;
Systems Design Strategies, 26. vydání;
68 čísel časopisu ArcReview s publikacemi firem a uživatelů GIS systémů;
... a mnoho dalších tematických poznámek a publikací.

Například kniha Modelování našeho světa..."(překlad) je komplexním průvodcem a referenčním průvodcem pro modelování dat GIS obecně a datový model geodatabáze konkrétně. Kniha ukazuje, jak dělat správná rozhodnutí v oblasti datového modelování, rozhodnutí, která jsou součástí každého aspektu projektu GIS: od návrhu databázových dat a sběru dat po prostorovou analýzu a vizualizaci Podrobně popisuje, jak navrhnout geografickou databázi vhodnou pro daný projekt, nastavit funkčnost databáze bez programování, řídit workflow ve složitých projektech, modelovat různé síťové struktury, jako je řeka, doprava nebo elektrických sítí, integrovat data ze satelitních snímků do geografické analýzy a mapování a vytvářet 3D datové modely GIS. Navrhování geodatabází pro dopravu"obsahuje metodické přístupy, které byly testovány na velkém množství projektů a plně vyhovují právním požadavkům Evropy a Spojených států, jakož i mezinárodním standardům. A v knize " GIS: nová energie elektrických a plynárenských podniků Na příkladech z reálného světa ukazuje výhody, které podnikový GIS může přinést dodavateli energie, včetně aspektů, jako je zákaznický servis, provoz sítě a další obchodní procesy.

Některé knihy, přeložené a původní, vydané v ruštině nakladatelstvími Esri CIS a DATA+. Pokrývají jak koncepční problémy související s technologií GIS, tak mnoho aplikovaných aspektů modelování a zavádění GIS různých měřítek a účelů.

Jako příklad uvážíme použití průmyslových modelů využívajících datový model BISDM (Building Interior Space Data Model) verze 3.0. BISDM je vývojem obecnějšího modelu BIM (Building Information Model, building information model) a je určen pro použití při projektování, výstavbě, provozu a vyřazování budov a staveb z provozu. Používá se v softwaru GIS a umožňuje vám efektivně vyměňovat geodata s jinými platformami a komunikovat s nimi. Odkazuje na obecnou skupinu úkolů FM (řízení infrastruktury organizace). Uvádíme hlavní výhody modelu BISDM, jehož použití umožňuje:

organizovat výměnu informací v heterogenním prostředí podle jednotných pravidel;
získat „fyzické“ ztělesnění konceptu BIM a doporučená pravidla pro řízení stavebního projektu;
udržovat jediné úložiště pomocí nástrojů GIS během celého životního cyklu budovy (od návrhu až po vyřazení z provozu);
koordinovat práci různých specialistů na projektu;
vizualizovat plánovaný harmonogram a fáze výstavby pro všechny účastníky;
uveďte předběžný odhad nákladů a doby výstavby (4D a 5D data);
kontrolovat průběh projektu;
zajistit kvalitní provoz budovy včetně údržby a oprav;
stát se součástí systému správy majetku, včetně funkcí analýzy efektivity využití prostor (pronájem, skladovací prostory, řízení zaměstnanců);
vypočítat a řídit energetickou účinnost budovy;
simulovat pohyb lidských toků.

BISDM definuje pravidla pro práci s prostorovými daty na úrovni vnitřních prostor v budově, včetně účelu a druhů využití, položených komunikací, instalovaných zařízení, účtování oprav a údržby, evidování incidentů, vztahů s dalším majetkem společnosti. Model pomáhá vytvářet jednotné úložiště geografických a negeografických dat. Zkušenosti předních světových společností byly využity k izolaci entit a modelování na úrovni GDB (geodatabáze) prostorových a logických vztahů všech fyzických prvků, které tvoří jak budovu samotnou, tak její interiér. Dodržování principů BISDM umožňuje výrazně zjednodušit úkoly integrace s jinými systémy. V první fázi se obvykle jedná o integraci s CAD. Při provozu budovy je pak využívána výměna dat se systémy ERP a EAM (SAP, TRIRIGA, Maximo atd.).

Vizualizace konstrukčních prvků BISDM pomocí ArcGIS.

V případě použití BISDM obdrží zákazník / vlastník zařízení kompletní výměnu informací od myšlenky vytvoření zařízení až po vypracování kompletního projektu, kontrolu stavby se získáním až -informace o datu do doby uvedení zařízení do provozu, kontrola parametrů za provozu, a to i při rekonstrukci nebo vyřazení zařízení z provozu. Podle paradigmatu BISDM se GIS a GDB vytvořené s jeho pomocí stávají společným úložištěm dat pro související systémy. V GDB jsou často data vytvořená a provozovaná systémy třetích stran. To je třeba vzít v úvahu při návrhu architektury vytvářeného systému.

V určité fázi vám nahromaděné „kritické množství“ informací umožňuje posunout se na novou kvalitativní úroveň. Například po dokončení projekční fáze novostavby je možné automaticky vizualizovat 3D modely zaměření v GIS, sestavit seznam zařízení k instalaci, vypočítat kilometry pokládky inženýrských sítí, provést řadu ověření a dokonce poskytnout předběžný finanční odhad nákladů na projekt.

Opět platí, že při společném použití BISDM a ArcGIS je možné automaticky vytvářet 3D modely z nashromážděných dat, protože GDB obsahuje kompletní popis objektu, včetně souřadnic z, náležejících k podlaze, typů spojů prvků, vybavení způsoby instalace, materiál, dostupné cesty pohybu personálu, funkční účel každého prvku atd. atd. Je třeba poznamenat, že po počátečním importu všech návrhových materiálů do BISDM GDB je potřeba další obsah pro:

umístění 3D modelů objektů a zařízení na určená místa;
shromažďování informací o nákladech na materiály a postupu při jejich pokládce a instalaci;
kontrola průchodnosti dle rozměrů instalovaného nestandardního zařízení.

Díky použití ArcGIS je import dalších 3D objektů a referenčních knih z externích zdrojů zjednodušen. Modul ArcGIS Data Interoperability umožňuje vytvářet procedury pro import takových dat a jejich správné umístění do modelu. Podporovány jsou všechny formáty používané v tomto odvětví, včetně IFC, AutoCAD Revit, Bentlye Microstation.

Průmyslové datové modely od IBM

IBM poskytuje sadu nástrojů a modelů pro správu úložiště pro různá odvětví:

IBM Banking and Financial Markets Data Warehouse (finance)
IBM Banking Data Warehouse
Modely bankovních procesů a služeb IBM
Datový model IBM Health Plan (zdraví)
IBM Insurance Information Warehouse (pojištění)
IBM pojistný proces a modely služeb
IBM Retail Data Warehouse (maloobchodní prodej)
IBM Telecommunications Data Warehouse (telekomunikace)
InfoSphere Warehouse Pack:
- pro Customer Insight (pro pochopení zákazníků)
- pro Market and Campaign Insight (pro pochopení společnosti a trhu)
- pro Supply Chain Insight (pro pochopení dodavatelů).

Například model IBMbankovníaFinančnítrhyDataSklad navrženy tak, aby řešily specifické výzvy bankovního odvětví, pokud jde o data, a IBMbankovníprocesaServisModelky- z hlediska procesů a SOA (servisně orientovaná architektura). Modely prezentované pro telekomunikační průmysl IBMInformaceRámec(IFW) a IBMTelekomunikaceDatasklad (TDW). Pomáhají výrazně urychlit proces tvorby analytických systémů a také snížit rizika spojená s vývojem aplikací business intelligence, správou podnikových dat a organizací datových skladů s přihlédnutím ke specifikům telekomunikačního průmyslu. Schopnosti IBM TDW pokrývají celé spektrum telekomunikačního trhu – od poskytovatelů internetu a provozovatelů kabelových sítí nabízejících služby kabelové a bezdrátové telefonie, přenos dat a multimediální obsah až po nadnárodní společnosti poskytující telefonní, satelitní, dálkové a mezinárodní komunikační služby. jako organizace globální sítě. Dnes TDW používají velcí i malí poskytovatelé kabelových a bezdrátových služeb po celém světě.

Nástroj volal InfoSphere Warehouse Pack pro Customer Insight je strukturovaný a snadno implementovatelný obchodní obsah pro rostoucí počet obchodních projektů a odvětví, včetně bankovnictví, pojišťovnictví, financí, programů zdravotního pojištění, telekomunikací, maloobchodu a distribuce. Pro firemní uživatele InfoSphere Warehouse Pack pro přehled trhu a kampaní vám pomůže maximalizovat efektivitu informací o trhu a marketingových kampaní prostřednictvím podrobného vývoje a procesu specifického pro daný podnik. Přes InfoSphere Warehouse Pack pro Supply Chain Insight organizace mají možnost získat aktuální informace o operacích dodavatelského řetězce.

Pozice Esri v architektuře řešení IBM.

Za zmínku stojí zejména přístup IBM k utilitám a utilitním společnostem. Aby uspokojily rostoucí požadavky zákazníků, potřebují energetické společnosti flexibilnější architekturu, než kterou používají dnes, a také průmyslový standardní objektový model pro usnadnění volné výměny informací. To zlepší komunikační schopnosti energetických společností, umožní jim komunikovat efektivněji a umožní novým systémům lepší přehled o všech požadovaných zdrojích bez ohledu na to, kde se v rámci organizace nacházejí. Základem tohoto přístupu je SOA (Service Oriented Architecture), komponentní model, který vytváří soulad mezi funkcemi oddělení a službami různých aplikací, které lze znovu použít. „Služby“ těchto komponent komunikují prostřednictvím rozhraní bez pevných vazeb a skrývají před uživatelem plnou složitost systémů za nimi. V tomto režimu mohou podniky snadno přidávat nové aplikace bez ohledu na dodavatele softwaru, operační systém, programovací jazyk nebo jiné vnitřní vlastnosti softwaru. Koncept je implementován na bázi SOA BEZPEČNÝ ( Solution Architecture for Energy umožňuje odvětví veřejných služeb získat holistický pohled na jejich infrastrukturu založený na standardech.

Esri ArcGIS® je celosvětově uznávaná softwarová platforma pro geografické informační systémy (GIS), která poskytuje tvorbu a správu digitálních aktiv sítí elektrické energie, přenosu plynu, distribuce a telekomunikací. ArcGIS umožňuje provádět nejúplnější inventarizaci komponentů elektrické distribuční sítě s přihlédnutím k jejich prostorovému umístění. ArcGIS výrazně rozšiřuje architekturu IBM SAFE tím, že poskytuje nástroje, aplikace, pracovní postupy, analýzy a informační a integrační schopnosti potřebné pro správu inteligentní sítě. ArcGIS v rámci IBM SAFE vám umožňuje získávat informace z různých zdrojů o objektech infrastruktury, majetku, zákaznících a zaměstnancích s přesnými údaji o jejich umístění a také vytvářet, ukládat a zpracovávat georeferenční informace o podnikových aktivech (pilíře, potrubí, dráty, transformátory, kabelové kanály atd.). ArcGIS v rámci infrastruktury SAFE umožňuje dynamicky kombinovat klíčové podnikové aplikace kombinací dat z GIS, SCADA a systémů zákaznických služeb s externími informacemi, jako je provoz, počasí nebo satelitní snímky. Utility používají tyto kombinované informace pro různé účely, od C.O.R. (celkový obraz provozního prostředí) až po inspekce na místě, údržbu, analýzu sítě a plánování.

Informační komponenty podniku zásobování energií lze modelovat pomocí několika úrovní, které sahají od nejnižší – fyzické – po nejvyšší, nejsložitější úroveň logiky obchodních procesů. Tyto vrstvy lze integrovat tak, aby splňovaly typické průmyslové požadavky, jako je automatizované protokolování měření a dohledové řízení a řízení sběru dat (SCADA). Vybudováním architektury SAFE dělají energetické společnosti významné kroky v prosazování modelu otevřených objektů v celém odvětví nazývaného Common Information Model (CIM) pro energetiku a veřejné služby. Tento model poskytuje nezbytný základ pro posun mnoha podniků k architektuře orientované na služby, protože podporuje používání otevřených standardů pro strukturování dat a objektů. Tím, že všechny systémy používají stejné objekty, se zmatek a nepružnost související s různými implementacemi stejných objektů sníží na minimum. Dojde tak ke sjednocení definice objektu „zákazník“ a dalších důležitých obchodních objektů ve všech systémech energetické společnosti. Díky CIM mohou nyní poskytovatelé služeb a spotřebitelé služeb sdílet společnou datovou strukturu, což usnadňuje outsourcing nákladných obchodních komponent, protože CIM vytváří společnou základnu, na které lze stavět sdílení informací.

Závěr

Komplexní průmyslové datové modely poskytují společnostem jednotný integrovaný pohled na jejich obchodní informace. Pro mnoho společností je obtížné integrovat svá data, ačkoli to je nezbytným předpokladem pro většinu celopodnikových projektů. Podle studie The Data Warehousing Institute (TDWI) více než 69 % dotázaných organizací zjistilo, že integrace je významnou překážkou pro přijetí nových aplikací. Naopak implementace datové integrace přináší společnosti hmatatelné příjmy a zvýšení efektivity.

Dobře sestavený model jednoznačně definuje význam dat, což jsou v tomto případě strukturovaná data (na rozdíl od nestrukturovaných dat, jako je obrázek, binární soubor nebo text, kde může být hodnota nejednoznačná). Nejúčinnější průmyslové modely nabízejí profesionální prodejci, včetně Esri a IBM. Vysoká návratnost z používání jejich modelů je dosažena díky jejich značné úrovni detailů a přesnosti. Obvykle obsahují mnoho datových atributů. Navíc odborníci z Esri a IBM mají nejen rozsáhlé zkušenosti s modelováním, ale také se dobře orientují ve vytváření modelů pro konkrétní odvětví.

Architektura databáze

CMD schéma je popis struktury datového modelu z pohledu správce.

Schéma AMD je popis interního nebo fyzického modelu. Ukládá popis fyzického umístění dat na médiu. Schéma ukládá přímé údaje o umístění dat v paměti (svazky, disky).

Schéma CMD popisuje strukturu dat, záznamů a polí.

Všechny DBMS podporují tři hlavní typy datových modelů:

1. Hierarchický model. Předpokládá nějaký kořenový záznam. Větve pocházejí z kořenů.

Ne všechny objekty jsou takto vhodně popsány. V hierarchii neexistují žádné vazby a charakteristická je velká redundance informací.

2. Síťový model. Umožňuje správně zobrazit všechny složitosti vztahů.

Model je vhodný pro reprezentaci odkazů s daty z externího prostředí, ale méně vhodný pro popis v databázi, což vede k další práci pro uživatele se studiem navigace přes odkazy.

3. Relační model. Vychází z matematického pojmu Relation - vztah, ale jednoduše - tabulka. Například obdélníkový dvourozměrný.

Struktura relačních dat byla vyvinuta na konci 60. let řadou výzkumníků, z nichž nejvýznamnější přispěl zaměstnanec IBM Edgar Codd. U relačního přístupu jsou data prezentována ve formě dvourozměrných tabulek - pro člověka nejpřirozenějších. Codd zároveň pro zpracování dat navrhl použít aparát teorie množin - sjednocení, průnik, rozdíl, kartézský součin.

Datový typ- tento pojem má stejný význam jako v programovacích jazycích (tj. datový typ určuje vnitřní reprezentaci v paměti počítače a způsob uložení datové instance, stejně jako množinu hodnot, které datová instance může přijmout a sadu platných datových operací). Všechny stávající moderní databáze podporují speciální typy dat navržených pro ukládání dat typu celé číslo, zlomek s pohyblivou řádovou čárkou, znaky a řetězce, kalendářní data. Mnoho databázových serverů implementuje jiné typy, například server Interbase má speciální datový typ pro ukládání velkých binárních informačních polí (BLOB).

Doména je potenciální množina hodnot jednoduchého datového typu, je podobná datovému podtypu v některých programovacích jazycích. Doména je definována dvěma prvky – datovým typem a booleovským výrazem, který je aplikován na data. Pokud se tento výraz vyhodnotí jako true, pak instance dat patří do domény.

přístup je dvourozměrná tabulka speciálního druhu, skládající se z hlavičky a těla.

záhlaví je pevná sada atributů, z nichž každý je definován v nějaké doméně, a mezi atributy a definujícími doménami existuje vzájemná shoda.

Každý atribut je definován ve své vlastní doméně. Doména je celočíselný datový typ a booleovská podmínka je n>0. Nadpis je na rozdíl od těla vztahu nadčasový. Tělo vztahu- je sbírka n-tice, z nichž každý je párem atribut-hodnota.

Silou vztahu je počet jeho n-tic a stupeň postoje je počet atributů.

Míra poměru je konstantní hodnota pro daný poměr, zatímco síla poměru se mění s časem. Mocnina poměru se také nazývá kardinální číslo.

Výše uvedené pojmy jsou teoretické a používají se při vývoji jazykových nástrojů a softwarových systémů pro relační DBMS. V každodenní práci se místo toho používají jejich neformální ekvivalenty:

přístup - stůl;

atribut - sloupec nebo pole;

n-tice - záznam nebo řádek.

Stupeň vztahu je tedy počet sloupců v tabulce a kardinální číslo je počet řádků.

Protože relace je množina a v klasické teorii množin podle definice množina nemůže obsahovat odpovídající prvky, relace nemůže mít dvě identické n-tice. Pro daný vztah tedy vždy existuje sada atributů, které n-tici jednoznačně identifikují. Tato sada atributů se nazývá klíč.

Klíč musí splňovat následující požadavky:

musí být jedinečné;

· musí být minimální, to znamená, že odstranění jakéhokoli atributu z klíče vede k porušení jedinečnosti.

Počet atributů v klíči je zpravidla menší než stupeň vztahu, v extrémních případech však může klíč obsahovat všechny atributy, protože kombinace všech atributů splňuje podmínku jedinečnosti. Vztah má obvykle více klíčů. Ze všech klíčů vztahu (nazývaných také "možné klíče") je jeden vybrán jako primární klíč. Při výběru primární klíč přednost se obvykle dává klíči s nejmenším počtem atributů. Je také nevhodné používat klíče s dlouhými řetězcovými hodnotami.

V praxi se často jako primární klíč používá speciální číselný atribut - automaticky se zvyšující nula, jejíž hodnotu může generovat trigger (spouštěč je speciální procedura, která se volá při provádění změn v databázi) popř. speciálními prostředky definovanými v mechanismu DBMS.

Pojmy popsané v této kapitole nejsou specifické pro žádnou konkrétní implementaci databáze, ale jsou společné pro všechny z nich. Tyto pojmy jsou tedy základem určitého obecného modelu, který se nazývá relační datový model.

Zakladatel relačního přístupu Date stanovil, že relační model se skládá ze tří částí:

strukturální;

· manipulativní;

holistický.

Vztahy jsou pevné ve strukturální části modelu jako jediná datová struktura použitá v relačním modelu.

V manipulační části jsou pevně stanoveny dva základní mechanismy pro manipulaci s relačními databázemi - relační algebra a relační kalkul.

Nedílnou součástí je chápán určitý mechanismus pro zajištění nezničitelnosti dat. Část integrity zahrnuje dva základní požadavky na integritu pro relační databáze – integritu entity a referenční integritu.

Požadavek integrita entity je, že každá n-tice jakékoli relace musí být odlišná od jakékoli jiné n-tice této relace, to znamená, jinými slovy, každá relace musí mít primární klíč. Tento požadavek musí být splněn, pokud jsou splněny základní vlastnosti vztahu.

V jazyce pro manipulaci s daty, stejně jako v dotazovacím jazyce, se provádí matematický aparát zvaný algebra vztahů, pro který jsou definovány následující akce:

1. Standardní operace: - průnik, - sjednocení, \ - rozdíl, X - kartézský součin.

2. Specifické: projekce, omezení, spojení, rozdělení.

A. Sdružení.

SD SHM EI HP

R 1 (kód dílu, kód materiálu, měrné jednotky, spotřeba)

R 2 (SHD, SHM, EI, HP)

Je potřeba najít

Má se připojit k množinám R 1 a R 2 . Při této operaci je zachován stupeň a mohutnost výsledné množiny

b. průsečík.

Zvýrazněte odpovídající čáry.

C. Rozdíl.

Vyloučit z R 1 n-tice, které odpovídají R 2 .

d. Kartézský součin.

Zde jsou zřetězeny n-tice.

Každá řada jedné sady je zřetězena s každou řadou druhé sady.

Jsou dány dvě sady:

Kartézský součin má následující tvar:

V tomto případě je S-stupeň, a, tzn. získáte 12 řádků a 5 sloupců.

Podniková databáze je centrálním článkem podnikového informačního systému a umožňuje vytvořit jednotný podnikový informační prostor. Firemní databáze

Sdílejte práci na sociálních sítích

Pokud by vám tato práce nevyhovovala, dole na stránce je seznam podobných prací. Můžete také použít tlačítko vyhledávání

TÉMA V FIREMNÍ DATABÁZE

PROTI .jeden. Organizace dat v podnikových systémech. Firemní databáze.

PROTI .2. DBMS a strukturální řešení v podnikových systémech.

V.3. Internetové / intranetové technologie a řešení pro přístup k podnikové databázi.

PROTI .jeden. ORGANIZACE DAT VE FIREMNÍCH SYSTÉMECH. FIREMNÍ DATABÁZE

Firemní základna data jsou centrálním článkem podnikového informačního systému a umožňují vytvořit jednotný informační prostor podniku. Podnikové databáze (obrázek 1.1).

Existují různé definice databází.

Pod databází (DB) rozumět souboru informací logicky souvisejících takovým způsobem, že tvoří jediný soubor dat uložených v paměťových zařízeních počítače. Tento soubor slouží jako výchozí data úloh řešených v procesu fungování automatizovaných systémů řízení, systémů zpracování dat, informačních a výpočetních systémů.

Pojem databáze můžete stručně formulovat jako soubor logicky souvisejících dat určených ke sdílení.

Pod databází se týká souboru dat uložených společně s minimální redundancí, takže je lze optimálně použít pro jednu nebo více aplikací.

Účel tvorby databází jako forma ukládání dat budování datového systému, který není závislý na přijatých algoritmech (softwaru), použitých technických prostředcích, fyzickém umístění dat v počítači. Databáze předpokládá víceúčelové využití (více uživatelů, mnoho forem dokumentů a dotazů jednoho uživatele).

Základní požadavky na databázi:

Úplnost prezentace dat. Data v databázi by měla adekvátně reprezentovat všechny informace o objektu a měla by být dostatečná pro ODS.
Integrita databáze. Údaje musí být zachovány během zpracování jejich ODS a ve všech situacích, které nastanou v průběhu práce.
Flexibilita datové struktury. Databáze by měla umožňovat změnu datových struktur bez narušení její integrity a úplnosti, když se změní vnější podmínky.
Realizovatelnost. To znamená, že musí existovat objektivní znázornění různých objektů, jejich vlastností a vztahů.
Dostupnost. Je nutné zajistit diferenciaci přístupu k datům.
nadbytek. Databáze by měla mít minimální redundanci při reprezentaci dat o jakémkoli objektu.

Poznání je pochopeno soubor faktů, vzorů a heuristických pravidel, pomocí kterých můžete problém vyřešit.

Znalostní báze (KB)  sbírka používaných databází a pravidel získaných od osob s rozhodovací pravomocí. Znalostní báze je prvkem expertních systémů.

by se mělo rozlišovat různé způsoby prezentace dat.

Fyzická data – Jedná se o data uložená v paměti počítače.

Logická reprezentace dat odpovídá uživatelské reprezentaci fyzických dat. Rozdíl mezi fyzickou a odpovídající logickou reprezentací dat spočívá v tom, že tato logická reprezentace odráží některé důležité vztahy mezi fyzickými daty.

Pod firemní databází rozumět databázi, která v té či oné podobě spojuje všechna potřebná data a znalosti o automatizované organizaci. V podnikových informačních systémech je takový koncept jakointegrované databáze, ve kterém je implementován princip jediného zadání a vícenásobného použití informací.

Rýže. 1.1. Struktura interakce útvarů s informačními zdroji korporace.

Firemní databáze jsou koncentrovaný (centralizované) a distribuovány.

Koncentrovaná (centralizovaná) databáze je databáze, jejíž data jsou fyzicky uložena v úložných zařízeních jednoho počítače. Na Obr. 1.2 ukazuje schéma serverové aplikace pro přístup k databázím na různých platformách.

Obr.1.2. Schéma heterogenního centralizovaná databáze

Centralizace zpracování informací umožnila odstranit takové nedostatky tradičních souborových systémů, jako je nekoherence, nekonzistence a redundance dat. S růstem databází a zejména při použití v geograficky rozptýlených organizacích však nastávají problémy. Například u koncentrovaných databází umístěných v uzlu telekomunikační sítě, přes které různá oddělení organizace přistupují k datům, se s nárůstem objemu informací a počtu transakcí objevují následující potíže:

Velký tok výměny dat;
Vysoký síťový provoz;
Nízká spolehlivost;
Nízký celkový výkon.

Ačkoli je snazší zajistit bezpečnost, integritu a konzistenci informací během aktualizací v koncentrované databázi, tyto problémy způsobují určité potíže. Jako možné řešení těchto problémů je navržena decentralizace dat. Decentralizace přináší:

Vyšší stupeň simultánnosti zpracování díky sdílení zátěže;
Zlepšení využití dat v terénu při provádění vzdálených (vzdálených) dotazů;
nižší náklady;
Snadná správa lokálních databází.

Náklady na vytvoření sítě s pracovními stanicemi (malými počítači) v jejích uzlech jsou mnohem nižší než náklady na vytvoření podobného systému pomocí sálového počítače. Obrázek 1.3 ukazuje logické schéma distribuované databáze.

Obr.1.3. Distribuovaná firemní databáze.

Uvádíme následující definici distribuované databáze.

Distribuovaná databáze - jedná se o soubor informací, souborů (relací) uložených v různých uzlech informační sítě a logicky propojených tak, aby tvořily jeden soubor dat (propojení může být funkční nebo prostřednictvím kopií stejného souboru). Jedná se tedy o soubor databází, které jsou logicky propojeny, ale fyzicky umístěny na více strojích, které jsou součástí stejné počítačové sítě.

Nejdůležitější požadavky na vlastnosti distribuované databáze jsou následující:

Škálovatelnost;
Kompatibilita;
Podpora různých datových modelů;
přenosnost;
Transparentnost umístění;
Autonomie uzlů distribuované databáze (Site Autonomy);
Zpracování distribuovaných požadavků;
Provádění distribuovaných transakcí.
Podpora homogenního bezpečnostního systému.

Transparentnost umístění umožňuje uživatelům pracovat s databázemi, aniž by věděli cokoli o své poloze. Autonomie uzlů distribuované databáze znamená, že každou databázi lze udržovat nezávisle na ostatních. Distribuovaný dotaz je dotaz (příkaz SQL), během kterého dochází k přístupu k objektům (tabulkám nebo pohledům) různých databází. Při provádění distribuovaných transakcí je kontrola souběžnosti vykonávána nad všemi zúčastněnými databázemi. Oracle7 používá technologii dvoufázového přenosu informací k provádění distribuovaných transakcí.

Databáze, které tvoří distribuovanou databázi, nemusí být homogenní (tj. nemusí být provozovány stejným DBMS) ani nemusí běžet na stejném prostředí operačního systému a/nebo na stejném typu počítačů. Například jedna databáze může být databáze Oracle na počítači SUN se systémem SUN OS (UNIX), druhá databáze může být provozována DB2 DBMS na sálovém počítači IBM 3090 s operačním systémem MVS a třetí databáze může být provozována SQL/DS DBMS také na sálových počítačích IBM, ale s operačním systémem VM. Povinná je pouze jedna podmínka - všechny stroje s databázemi musí být přístupné přes síť, které jsou součástí.

Hlavní úkol distribuované databáze – distribuce dat po síti a poskytování přístupu k nim. Tento problém lze vyřešit následujícími způsoby:

Každý uzel ukládá a používá vlastní sadu dat, která je k dispozici pro vzdálené dotazy. Tato distribuce je rozdělena.
Některá data, která se často používají na vzdálených místech, mohou být duplicitní. Taková distribuce se nazývá částečně duplikovaná.
Všechna data jsou duplikována v každém uzlu. Taková distribuce se nazývá plně redundantní.
Některé soubory lze rozdělit horizontálně (je vybrána podmnožina záznamů) nebo vertikálně (je vybrána podmnožina polí atributů), zatímco rozdělené podmnožiny jsou uloženy v různých uzlech spolu s nerozdělenými daty. Takové rozdělení se nazývá split (fragmentované).

Při vytváření distribuované databáze na koncepční úrovni musíte vyřešit následující úkoly:

Je nutné mít jednotné koncepční schéma pro celou síť. Uživateli to poskytne logickou transparentnost dat, díky čemuž bude moci vytvořit požadavek na celou databázi na samostatném terminálu (funguje jakoby s centralizovanou databází).
K vyhledání dat v síti je potřeba schéma. To zajistí transparentnost umístění dat, takže uživatel nebude muset specifikovat, kam má předat žádost, aby získal požadovaná data.
Je nutné vyřešit problém heterogenity distribuovaných databází. Distribuované databáze mohou být homogenní nebo heterogenní z hlediska hardwaru a softwaru. Problém heterogenity je poměrně snadno řešitelný, pokud je distribuovaná databáze heterogenní z hlediska hardwaru, ale homogenní z hlediska softwaru (stejné DBMS v uzlech). Pokud se v uzlech distribuovaného systému používají různé DBMS, jsou zapotřebí prostředky pro převod datových struktur a jazyků. To by mělo zajistit transparentnost transformace v uzlech distribuované databáze.
Je potřeba vyřešit problém se správou slovníků. Pro zajištění všech druhů transparentnosti v distribuované databázi jsou zapotřebí programy, které spravují četné slovníky a referenční knihy.
Je nutné definovat metody pro provádění dotazů v distribuované databázi. Metody provádění dotazů v distribuované databázi se liší od podobných metod v centralizovaných databázích, protože jednotlivé části dotazů musí být vykonány v místě odpovídajících dat a dílčí výsledky musí být přenášeny do dalších uzlů; zároveň by měla být zajištěna koordinace všech procesů.
Je potřeba vyřešit problém paralelního provádění dotazů. V distribuované databázi je potřeba složitý mechanismus pro řízení souběžného zpracování, který musí zejména zajistit synchronizaci při aktualizaci informací, která zaručí konzistenci dat.
Potřeba vyvinuté metodiky pro distribuci a umístění dat, včetně rozdělení, je jedním z hlavních požadavků na distribuovanou databázi.

Jednou z aktivně se rozvíjejících nových oblastí architektury počítačových systémů, která je mocným nástrojem pro zpracování nenumerických informací, jsou databázové stroje. Databázové stroje slouží k řešení nenumerických úloh, jako je ukládání, vyhledávání a transformace dokumentů a faktů, práce s objekty. V návaznosti na definici dat jako digitální a grafické informace o objektech okolního světa je do pojmu data v numerickém a nenumerickém zpracování zasazen odlišný obsah. Numerické zpracování využívá objekty, jako jsou proměnné, vektory, matice, vícerozměrná pole, konstanty atd., zatímco nenumerické zpracování využívá objekty, jako jsou soubory, záznamy, pole, hierarchie, sítě, vztahy atd. numerické zpracování se týká přímo informací o objektech (například konkrétního zaměstnance nebo skupiny zaměstnanců), nikoli samotného souboru zaměstnanců. Neindexuje soubor zaměstnance za účelem výběru konkrétní osoby; zde se více zajímá o obsah požadovaného záznamu. Obrovské objemy informací jsou obvykle podrobeny nenumerickému zpracování. V různých aplikacích lze s těmito daty provádět takové operace, například:

zvýšit platy všech zaměstnanců společnosti;
vypočítat bankovní úroky na účtech všech zákazníků;
provádět změny v seznamu veškerého zboží na skladě;
najít požadovaný abstrakt ze všech textů uložených v knihovně nebo v systému vyhledávání bibliografických informací;
najít popis požadované smlouvy v souboru obsahujícím právní dokumenty;
zobrazit všechny soubory obsahující popisy patentů a najít patent (pokud existuje) podobný tomu, který byl znovu navržen.

Implementovat databázový stroj, paralelní a asociativní architektury jako alternativa k jednoprocesorovýmvon Neumannstruktura, která vám umožní pracovat s velkým množstvím informací v reálném čase.

Databázové stroje nabývají na významu v souvislosti s výzkumem a aplikací konceptů umělé inteligence, jako je reprezentace znalostí, expertní systémy, inference, rozpoznávání vzorů atd.

Úložiště informací. Dnes mnozí uznávají, že většina společností již provozuje několik databází a pro úspěšnou práci s informacemi jsou zapotřebí nejen různé typy databází, ale různé generace DBMS. Podle statistik každá organizace používá v průměru 2,5 různých DBMS. Potřeba „izolovat“ podnikání společností, nebo spíše lidí zapojených do tohoto podnikání, od technologických vlastností databází, poskytnout uživatelům jediný pohled na podnikové informace bez ohledu na to, kde jsou fyzicky uloženy, se stala zřejmou. . To podnítilo vznik technologie informačních skladů ( Datové sklady, DW).

Hlavním cílem DW je vytvoření jediné logické reprezentace dat obsažených v různých typech databází, nebo jinými slovy, jediného podnikového datového modelu.

Nové kolo vývoje DW bylo možné díky zdokonalování informačních technologií obecně, zejména vzniku nových typů databází založených na paralelním zpracování dotazů, které zase spoléhaly na pokrok v oblasti paralelních počítačů. Byly vytvořeny tvůrci dotazůs intuitivním grafickým rozhraním, které usnadnilo vytváření složitých databázových dotazů. Různý softwaremiddlewareposkytnutá komunikacemezi různými typy databázía nakonec prudce klesla cenazařízení pro ukládání informací.

Databanka může být přítomna ve struktuře korporace.

Databáze - funkční a organizační složka v automatizovaných řídicích systémech a informačních a výpočetních systémech, která zajišťuje centralizovanou informační podporu pro skupinu uživatelů nebo soubor úloh řešených v systému.

Databáze je považován za informační a referenční systém, jehož hlavním účelem je:

při shromažďování a udržování v provozuschopném stavu souboru informací tvořících informační základnu celého automatizovaného systému nebo určitého souboru v něm řešených úloh;
při vydávání údajů požadovaných úkolem nebo uživatelem;
při poskytování kolektivního přístupu k uloženým informacím;
při zajišťování potřebného řízení využívání informací obsažených v infobázi.

Moderní databanka je tedy komplexní softwarový a hardwarový komplex, který zahrnuje technické, systémové a síťové nástroje, databáze a DBMS, systémy vyhledávání informací pro různé účely.

PROTI .2. DBMS A STRUKTURÁLNÍ ŘEŠENÍ VE FIREMNÍCH SYSTÉMECH

Databáze a systémy pro správu znalostí

Důležitou součástí moderních informačních systémů jsou systémy pro správu databází (DBMS).

DBMS - soubor softwarových a jazykových nástrojů určených k vytváření, údržbě a používání databází.

Systém správy databází poskytuje systémům pro zpracování dat přístup k databázím. Jak již bylo uvedeno, důležitou roli DBMS získává při tvorbě podnikových informačních systémů a zvláště významnou roli při tvorbě informačních systémů využívajících distribuované informační zdroje založené na moderních síťových počítačových technologiích.

Hlavním rysem moderních DBMS je, že moderní DBMS podporují takové technologie, jako jsou:

technologie klient/server.
Podpora databázových jazyků. Tentojazyk pro definici schématu DB (SDL - Schema Definition Language),jazyk pro manipulaci s daty (DML - Data Manipulation Language), integrované jazyky SQL (Structured Queue Language), QDB (Query - By - Example) a QMF (Query Management Facility ) je pokročilý periferní nástroj pro specifikaci dotazů a generování sestav pro DB 2 atd.;
Přímá správa dat v externí paměti.
Správa vyrovnávací paměti.
Řízení transakcí. technologie OLTP (On-line zpracování transakcí), OLAP - technika (Zpracování analýzy online) pro DW.
Zajistěte ochranu a integritu dat. Používání systému je povoleno pouze uživatelům, kteří mají právo přístupu k datům. Když uživatelé provádějí operace s daty, je zachována konzistence uložených dat (integrita). To je důležité v podnikových víceuživatelských informačních systémech.
Žurnalistika.

Moderní DBMS musí splňovat požadavky na databáze uvedené výše. Kromě toho musí splňovat následující zásady:

Datová nezávislost.
Všestrannost. DBMS musí mít výkonnou podporu pro koncepční datový model, aby zobrazoval vlastní logické pohledy.
Kompatibilita. DBMS musí zůstat funkční s vývojem softwaru a hardwaru.
Redundance dat. Na rozdíl od souborových systémů musí být databáze jedinou sadou integrovaných dat.
Ochrana dat. DBMS musí poskytovat ochranu proti neoprávněnému přístupu.
Integrita dat. DBMS musí uživatelům zabránit v manipulaci s databází.
Řízení souběžné práce. DBMS musí chránit databázi před nekonzistencemi v režimu sdíleného přístupu. Aby byl zajištěn konzistentní stav databáze, musí být všechny požadavky uživatelů (transakce) prováděny v určitém pořadí.
DBMS musí být univerzální. Měl by podporovat různé datové modely na jediném logickém a fyzickém základě.
DBMS by měl podporovat centralizované i distribuované databáze a stát se tak důležitým článkem v počítačových sítích.

Když vezmeme v úvahu DBMS jako třídu softwarových produktů zaměřených na údržbu databází v automatizovaných systémech, můžeme rozlišit dvě nejvýznamnější vlastnosti, které určují typy DBMS. Podle nich lze DBMS posuzovat ze dvou hledisek:

jejich schopnosti ve vztahu k distribuovaným (podnikovým) databázím;
jejich vztah k typu datového modelu implementovaného v DBMS.

Ve vztahu k podnikovým (distribuovaným) databázím lze konvenčně rozlišovat následující typy DBMS:

DBMS „desktop“. Tyto produkty jsou primárně zaměřeny na práci s osobními údaji (desktop data). Mají sady příkazů pro sdílení společných databází, ale jsou malé velikosti (typ malé kanceláře). Především je to DBMS jako Access, dBASE, Paradox, ExPro. Proč Access, dBASE, Paradox, ExPro mají špatný přístup k firemním datům. Faktem je, že neexistuje snadný způsob, jak překonat bariéru mezi osobními a firemními daty. A nejde ani o to, že mechanismus DBMS osobních údajů (nebo malé kanceláře) je zaměřen na přístup k datům prostřednictvím mnoha bran, produktů bran atd. Problém je v tom, že tyto mechanismy obvykle zahrnují úplné přenosy souborů a nedostatek rozsáhlé podpory indexů, což má za následek fronty na server, které ve velkých systémech prakticky zastavují.
Specializovaný vysoce výkonný víceuživatelský DBMS. Takové DBMS se vyznačují přítomností jádra systému pro více uživatelů, jazyka pro manipulaci s daty a následujících funkcí, které jsou typické pro vyvinuté systémy DBMS pro více uživatelů:
organizování rezervního fondu;
přítomnost systému pro zpracování transakčních front;
přítomnost mechanismů pro blokování dat pro více uživatelů;
protokolování transakcí;
dostupnost mechanismů kontroly přístupu.

Jedná se o DBMS jako Oracle, DВ2, SQL/Server, Informix, Sybase, ADABAS, Titanium a další poskytují široké služby pro zpracování podnikových databází.

Při práci s databázemi se využívá mechanismus transakcí.

transakce je logická jednotka práce.

transakce je sekvence příkazů pro manipulaci s daty, která se provádíjako jeden(vše nebo nic) a překlad databázez jednoho integrálního stavu do jiného integrálního stavu.

Transakce má čtyři důležité vlastnosti, známé jako vlastnosti ASID:

(A) Atomicita . Transakce je provedena jako atomická operace – buď se provede celá transakce, nebo se celá transakce neprovede.
(C) Konzistence. Transakce přesune databázi z jednoho konzistentního (konzistentního) stavu do jiného konzistentního (konzistentního) stavu. V rámci transakce může být narušena konzistence databáze.
(I) Izolace . Transakce různých uživatelů by se neměly vzájemně rušit (například jako kdyby byly prováděny přísně střídavě).
(D) Trvanlivost. Pokud je transakce dokončena, výsledky její práce by měly být uloženy v databázi, i když systém v příštím okamžiku spadne.

Transakce se obvykle spustí automaticky od okamžiku, kdy se uživatel připojí k DBMS, a pokračuje, dokud nenastane jedna z následujících událostí:

Byl vydán příkaz COMMIT WORK (pro potvrzení transakce).
Byl vydán příkaz ROLLBACK WORK.
Uživatel se odpojil od DBMS.
Došlo k selhání systému.

Pro uživatele, ona nosí obvykle atomový charakter. Ve skutečnosti se jedná o komplexní mechanismus interakce mezi uživatelem (aplikací) a databází. Software podnikových systémů používá motor pro zpracování transakcí v reálném čase (Online systémy pro zpracování transakcí, OLTP), zejména účetní programy, software pro příjem a zpracování klientských aplikací, finanční aplikace, produkují mnoho informací. Tyto systémy jsou navrženy (a vhodně optimalizovány) pro zpracování velkého množství dat, komplexní transakce a intenzivní operace čtení/zápisu.

Bohužel informace umístěné v databázích systémů OLTP nejsou příliš vhodné pro použití běžnými uživateli (kvůli vysokému stupni normalizace tabulek, specifickým formátům prezentace dat a dalším faktorům). Data z různých informačních kanálů jsou tedy odesílána (ve smyslu kopírování) do skladovací sklad, třídění a následné doručení spotřebiteli. V informačních technologiích hrají roli skladyúložiště informací.

Doručování informací koncovému uživateli - jsou zapojeny systémy analytického zpracování dat v reálném čase (Online analytické zpracování, OLAP), které poskytují extrémně snadný přístup k datům prostřednictvím pohodlných nástrojů pro generování dotazů a analýzu výsledků. V systémech OLAP se hodnota informačního produktu zvyšuje pomocí různých metod analýzy a statistického zpracování. Tyto systémy jsou navíc optimalizovány z hlediska rychlosti extrakce dat, sběru zobecněných informací a jsou zaměřeny na běžné uživatele (mají intuitivní rozhraní). Li systém OLTP dává odpovědi na jednoduché otázky typu „jaká byla úroveň prodeje produktu N v regionu M v lednu 199x?“, pak OLAP systémy jsou připraveny na složitější požadavky uživatelů, např.: "Uveďte analýzu prodeje produktu N za všechny regiony podle plánu na 2. čtvrtletí oproti předchozím dvěma letům."

Architektura klient/server

V moderních systémech distribuované zpracování informacítechnologie se dostává do popředí zájmu klient-server. V systému architektury klient-serverzpracování dat je rozděleno mezi klientský počítač a serverový počítač, přičemž komunikace mezi nimi probíhá po síti. Toto oddělení procesů zpracování dat je založeno na seskupování funkcí. Počítač databázového serveru je obvykle vyhrazen k provádění databázových operací, zatímco klientský počítač spouští aplikační programy. Obrázek 2.1 ukazuje jednoduchý systém architektury klient-server, který zahrnuje počítač fungující jako server a další počítač fungující jako jeho klient. Každý stroj plní různé funkce a má své vlastní zdroje.

		Databáze
Serverový počítač
Síť
PC kompatibilní s IBM	PC kompatibilní s IBM	PC kompatibilní s IBM
		Aplikace

Rýže. 2.1. Systém architektury klient-server

Hlavní funkcí klientského počítače je spouštět aplikaci (uživatelské rozhraní a prezentační logika) a komunikovat se serverem, když to aplikace vyžaduje.

server - Jedná se o objekt (počítač), který poskytuje služby jiným objektům na jejich žádost.

Jak termín napovídá, hlavní funkcí serverového počítače je sloužit potřebám klienta. Pojem "server" se používá k označení dvou různých skupin funkcí: souborového serveru a databázového serveru (dále tyto pojmy znamenají v závislosti na kontextu buď software, který implementuje tyto skupiny funkcí, nebo počítače s tímto softwarem. ). Souborové servery nejsou určeny k provádění databázových operací, jejich hlavní funkcí je sdílení souborů mezi více uživateli, tzn. poskytování současného přístupu mnoha uživatelů k souborům na počítači - souborovém serveru. Příkladem souborového serveru je operační systém Novell NetWare. Databázový server lze nainstalovat a spustit na počítači souborového serveru. Oracle DBMS ve formě NLM (Network Loadable Module) běží v prostředí NetWare na souborovém serveru.

Server místní sítě musí mít prostředky, které odpovídají jeho funkčnímu účelu a potřebám sítě. Všimněte si, že vzhledem k orientaci na přístup k otevřeným systémům je správnější hovořit o logických serverech (myšleno souborem prostředků a softwarových nástrojů, které poskytují služby nad těmito prostředky), které se nemusí nutně nacházet na různých počítačích. Charakteristickým rysem logického serveru v otevřeném systému je, že pokud je z důvodu efektivity účelné server přesunout na samostatný počítač, lze to provést bez nutnosti jakýchkoli úprav, a to jak jeho samotného, tak aplikace. programy, které jej používají.

Jedním z důležitých požadavků serveru je, že operační systém, ve kterém je databázový server hostován, musí být víceúlohový (a pokud možno, ale ne nezbytně, víceuživatelský). Například Oracle DBMS nainstalovaný na osobním počítači s operačním systémem MS-DOS (nebo PC-DOS), který nesplňuje požadavek na multitasking, nelze použít jako databázový server. A stejný Oracle DBMS nainstalovaný na počítači s multitaskingovým (i když ne víceuživatelským) operačním systémem OS / 2 může být databázovým serverem. Mnoho různých operačních systémů UNIX, MVS, VM a některé další operační systémy jsou multitaskingové i víceuživatelské.

Distribuovaná výpočetní technika

Termín „distribuované výpočty“ se často používá k označení dvou různých, i když komplementárních, konceptů:

Distribuovaná databáze;
Distribuované zpracování dat.

Aplikace těchto konceptů umožňuje organizovat přístup k informacím uloženým na několika strojích pro koncové uživatele různými prostředky.

Existuje mnoho typů serverů:

databázový server;
tiskový server;
Server pro vzdálený přístup;
Faxový server;
Webový server atd.

V jádru technologie klient/server Existují takové základní technologie, jako jsou:

Technologie operačních systémů, koncept interakce otevřených systémů, tvorba objektově orientovaných prostředí pro fungování programů;
Telekomunikační technologie;
Síťové technologie;
Technologie grafického uživatelského rozhraní ( GUI);
Atd.

Výhody technologie klient-server:

Technologie klient/server umožňuje výpočty v heterogenních výpočetních prostředích. Nezávislost na platformě: Přístup k heterogenním síťovým prostředím, která zahrnují různé typy počítačů s různými operačními systémy.
Nezávislost na zdrojích dat: přístup k informacím z heterogenních databází. Příklady takových systémů jsou DB2, SQL/DS, Oracle, Sybase.
Rovnováha zatížení mezi klientem a serverem.
Provádění výpočtů tam, kde se to děje nejefektivněji;
Poskytuje efektivní schopnost škálování;
Multiplatformní výpočetní technika. Cross-platform computing je definován jednoduše jako implementace technologií v heterogenních výpočetních prostředích. Zde by měly být uvedeny následující možnosti:
Aplikace musí běžet na více platformách;
Na všech platformách by měl mít stejné rozhraní a logiku práce;
Aplikace se musí integrovat s nativním operačním prostředím;
Mělo by se chovat stejně na všech platformách;
Mělo by mít jednoduchou a konzistentní podporu.

 Distribuovaná výpočetní technika. Distribuované výpočty zahrnují rozdělení práce mezi několik počítačů (ačkoli distribuované výpočty jsou širší pojem).

 Downscaling. Downscaling je převod aplikací pro sálové počítače na malé počítačové platformy.

Snižte náklady na infrastrukturu a hardware. Nákladově efektivní: Dostupnost levného výpočetního hardwaru a rostoucí rozšíření lokálních sítí činí technologii klient-server nákladově efektivnější než jiné technologie zpracování dat. Vybavení lze upgradovat podle potřeby.

 Snížení celkové doby provádění aplikace;

 Snížené využití paměti klienta;

 Snížení síťového provozu.

Schopnost pracovat s multimédii: K dnešnímu dni byla vytvořena spousta programů pro práci s multimédii pro PC. Buď takové programy pro konfiguraci terminál-hostitel neexistují, nebo jsou velmi drahé.
Schopnost využívat více výpočetních zdrojů pro databázové operace: protože aplikace běží na klientských počítačích, uvolňují se na serverovém počítači další zdroje (ve srovnání s konfigurací terminál-hostitel) pro databázové operace, jako je CPU a operační zdroje.
Zvýšená produktivita programátorů: Produktivita programátorů se zvyšuje používáním nástrojů, jako jsou SQL*Forms a CASE, k rychlejšímu vývoji aplikací než programovací jazyky jako C, PL1 nebo COBOL.
Zvýšení produktivity koncových uživatelů: Dnes mnoho koncových uživatelů přijalo systémy jako Lotus, Paradox, Word Perfect, Harvard Graphics a tak dále.

Back-end rozhraní je definováno a opraveno. Proto je možné vytvářet nové klientské části stávajícího systému (příklad interoperability na systémové úrovni).

Rýže. 2.2. Ilustrace klientského přístupu ke sdílené složce serveru.

Jak implementovat technologii klient-server

Instalace systému založeného na technologii klient-server a schopného distribuovaného zpracování dat je diskutována níže. Je vyžadován následující počítačový hardware a software:

počítač databázového serveru;
klientské počítače;
komunikační síť;
Síťový software;
aplikační software.

jazyk SQL . Dotazovací jazyk vysoké úrovně - SQL (Structured Query Language ) se používá k implementaci dotazů do databází, jako jsou NMD, NDL a PJD, a byl přijat jako standard. Jazyk SQL byl původně přijat jako datový jazyk softwarových produktů firmy IBM a YMD relačního DBMS SYSTEM R od IBM . Důležitá vlastnost jazyka SQL spočívá v tom, že stejný jazyk je reprezentován prostřednictvím dvou různých rozhraní, a to: prostřednictvím interaktivního rozhraní a prostřednictvím rozhraní pro programování aplikací (dynamic SQL). Dynamické SQL se skládá z mnoha vestavěných jazykových funkcí SQL , poskytovaný speciálně pro vytváření interaktivních aplikací, kde interaktivní aplikace je program, který je napsán pro podporu přístupu k databázi koncovým uživatelem běžícím na interaktivním terminálu. Jazyk SQL poskytuje funkce definování, manipulace a správy databázových dat a je pro uživatele transparentní z pohledu implementované DBMS.

Rýže. 2.3. Schéma pro provádění požadavků uživatelů na distribuované databáze.

Vnitřní struktura databází je dána použitými datovými modely. Konceptuální model má více abstrakčních schopností a bohatší sémantiku než externí modely. Externí modely se často nazývají syntaktické nebo operační modely, které odkazují na syntaktický charakter správy a aplikace jako prostředku interakce uživatele s databází. V informačním modelování existují různé úrovně abstrakce, od úrovně konceptuálního modelu po úroveň fyzického datového modelu, které ovlivňují architekturu DBMS.

Datový model se skládá ze tří komponent:

Datová struktura, která bude reprezentovat databázi z pohledu uživatele.
Platné operace, které mají být provedeny s datovou strukturou. S touto strukturou je nutné umět pracovat pomocí různých DDL a NML operací. Bohatá struktura je bezcenná, pokud nemůžete manipulovat s jejím obsahem.
Omezení pro kontrolu integrity. Datový model musí být opatřen prostředky pro zachování jeho integrity a jeho ochranu. Jako příklad zvažte následující dvě omezení:
Každý podstrom musí mít zdrojový uzel. Hierarchické databáze nemohou ukládat podřízené uzly bez nadřazeného uzlu.
Ve vztahu k relační databázi nemohou existovat identické n-tice. U souboru tento požadavek vyžaduje, aby všechny záznamy byly jedinečné.

Jednou z nejdůležitějších vlastností DBMS je schopnost propojovat objekty.

Mezi objekty existují následující typy vazeb:

Jeden na jednoho (1:1). Jeden objekt jedné množiny může být spojen s jedním objektem jiné množiny.
One-to-Many (1:M). Jeden objekt jedné množiny může souviset s mnoha objekty jiné množiny.
Many-to-Many (M:N). Jeden objekt jedné množiny může být spojen s mnoha objekty jiné množiny, ale zároveň může být jeden objekt jiné množiny spojen s mnoha objekty první množiny.
rozvětvený . Jeden objekt jedné množiny může být spojen s objekty mnoha množin.
Rekurzivní . Jeden objekt dané množiny může být spojen s objektem stejné množiny.

Existují následující hlavní datové modely:

Relační datový model.
Hierarchický datový model.
Neúplný datový model sítě.
Datový model CODASYL.
Rozšířený datový model sítě.

V.3. INTERNET / INTRANET TECHNOLOGIE A ŘEŠENÍ PRO PŘÍSTUP K FIREMNÍ DATABÁZI

Hlavním problémem systémů založených na architektuře „klient-server“ je to, že v souladu s koncepcí otevřených systémů se od nich požaduje mobilní v co nejširší třídě hardwarových a softwarových řešení otevřených systémů. I když se omezíme na místní sítě založené na UNIXu, různé sítě používají různá zařízení a komunikační protokoly. Snaha vytvořit systémy podporující všechny možné protokoly vede k jejich přetížení síťovými detaily na úkor funkčnosti.

Ještě složitější aspekt tohoto problému souvisí s možností použití různých reprezentací dat v různých uzlech heterogenní lokální sítě. Různé počítače mohou mít různé adresování, reprezentaci čísel, kódování znaků atd. To je zvláště důležité pro servery na vysoké úrovni: telekomunikace, výpočetní technika, databáze.

Běžným řešením problému mobility systémů založených na architektuře "klient-server" je spoléhat se na softwarové balíčky, které implementují protokoly vzdáleného volání procedur (RPC - Remote Procedure Call). Pomocí těchto nástrojů vypadá volání služby na vzdáleném hostiteli jako normální volání procedury. Nástroje RPC, které samozřejmě obsahují všechny informace o specifikách vybavení místní sítě a síťových protokolech, převádějí volání do sekvence síťových interakcí. Specifika síťového prostředí a protokolů jsou tedy před programátorem aplikací skryta.

Když je volána vzdálená procedura, programy RPC převedou datové formáty klienta na střední formáty nezávislé na počítači a poté převedou na formáty dat serveru. Při předávání parametrů odezvy se provádějí podobné transformace.

Další související díla, která by vás mohla zajímat.vshm>
6914.		Koncept databáze	11,56 kB
	Databáze je souborem nezávislých materiálů prezentovaných v objektivní formě článků výpočtu normativních aktů soudních rozhodnutí a dalších podobných materiálů systematizovaných tak, že tyto materiály lze vyhledat a zpracovat pomocí elektronického počítače Občanský zákoník Ruské federace Umění. Databáze organizovaná podle určitých pravidel a udržovaná v paměti počítače, soubor dat charakterizující aktuální stav některých ...
8064.		Distribuované databáze	43,66 kB
	Distribuované databáze Distribuovaná databáze RDB je soubor logicky propojených sdílených dat, která jsou fyzicky distribuována přes různé uzly počítačové sítě. Přístup k datům by neměl záviset na přítomnosti nebo nepřítomnosti replik dat. Systém by měl automaticky určit metody pro provádění spojení dat, síťové spojení schopné zpracovat množství přenášených informací a uzel, který má dostatečný výpočetní výkon pro spojení tabulek. RDBMS musí být schopen...
20319.		DATABÁZE A JEJICH OCHRANA	102,86 kB
	Online online databáze se objevily v polovině 60. let. Operace na provozních databázích byly zpracovávány interaktivně pomocí terminálů. Jednoduchá indexově sekvenční organizace záznamů se rychle vyvinula do výkonnějšího modelu záznamu orientovaného na sady. Charles Bachmann obdržel Turingovu cenu za vedení práce Data Base Task Group (DBTG), která vyvinula standardní jazyk pro popis dat a manipulaci s nimi.
5031.		Knihovna vývoje databáze	11,72 MB
	Technologie návrhu databáze. Definování vztahů mezi entitami a vytvoření datového modelu. Hlavní myšlenky moderních informačních technologií jsou založeny na koncepci, že data by měla být organizována do databází, aby adekvátně odrážela měnící se reálný svět a vyhovovala informačním potřebám uživatelů. Tyto databáze jsou vytvářeny a provozovány pod kontrolou speciálních softwarových systémů nazývaných DBMS databázové systémy.
13815.		HIERARCHICKÝ DATABÁZOVÝ MODEL	81,62 kB
	Hlavní myšlenky moderních informačních technologií vycházejí z konceptu databází, podle kterého jsou základem informačních technologií data organizovaná v databázích, které adekvátně odrážejí stav konkrétní tematické oblasti a poskytují uživateli relevantní informace v této tematické oblasti. Je třeba uznat, že data jsou...
14095.		Vývoj databáze knihoven	11,72 MB
	Nárůst objemu a strukturní složitosti uložených dat, rozšíření okruhu uživatelů informačních systémů vedly k širokému používání nejpohodlnějších a relativně snadno pochopitelných relačních (tabulkových) DBMS.
5061.		Vytvoření databáze polikliniky	2,4 MB
	Rozvoj výpočetní techniky a informačních technologií poskytl příležitosti pro vytvoření a široké využití automatizovaných informačních systémů (AIS) pro různé účely. Jsou vyvíjeny a implementovány informační systémy pro řízení ekonomických a technických zařízení
13542.		Databáze geologických informací	20,73 kB
	Zavádění počítačových technologií a zejména databází do vědecké sféry probíhá v poslední době rychlým tempem. Tento proces neobchází ani geologii, neboť právě v přírodních vědách je potřeba uchovávat a zpracovávat velké množství informací.
9100.		Databáze. Základní pojmy	26,28 kB
	Databáze je soubor informací o konkrétních objektech reálného světa v libovolné oblasti, ekonomii, managementu, chemii atd. Účelem informačního systému není pouze ukládat data o objektech, ale také s těmito daty manipulovat, pořizovat vzít v úvahu vztahy mezi objekty. Každý objekt je charakterizován nějakou sadou vlastností dat, které se v databázi nazývají atributy.
5240.		Vytvoření databáze "děkanát univerzity"	1,57 MB
	Databáze (DB) je soubor vzájemně propojených dat uložených společně na externích paměťových médiích počítače s takovou organizací a minimální redundancí, která umožňuje jejich optimální využití pro jednu nebo více aplikací.

Průmyslové datové modely

Hlavním účelem modelů je usnadnit orientaci v datovém prostoru a pomoci při zvýraznění detailů, které jsou důležité pro rozvoj podnikání. V dnešním podnikatelském prostředí je naprosto nezbytné mít jasnou představu o vztazích mezi různými složkami a dobře porozumět celkovému obrazu organizace. Identifikace všech detailů a vztahů pomocí modelů umožňuje co nejefektivnější využití času a nástrojů pro organizaci práce firmy.

Datový model jednoznačně definuje význam dat, kterými jsou v tomto případě strukturovaná data (na rozdíl od nestrukturovaných dat, jako je obrázek, binární soubor nebo text, kde může být hodnota nejednoznačná).

Zpravidla se rozlišují modely vyšší úrovně (a obsahově obecnější) a nižší úrovně (respektive podrobnější). Horní úrovní modelování je tzv koncepční datové modely(koncepční datové modely), které podávají nejobecnější obraz o fungování podniku nebo organizace. Koncepční model zahrnuje hlavní pojmy nebo předmětové oblasti, které jsou kritické pro fungování organizace; obvykle jejich počet nepřesahuje 12-15. Takový model popisuje třídy entit důležitých pro organizaci (obchodní objekty), jejich charakteristiky (atributy) a asociace mezi dvojicemi těchto tříd (tj. vztahy). Vzhledem k tomu, že terminologie v obchodním modelování ještě není zcela ustálena, lze v různých anglicky psaných zdrojích koncepční datové modely nazývat také model předmětové oblasti (což lze přeložit jako modely předmětové oblasti) nebo předmětový podnikový datový model (předmětové firemní datové modely). ).

Další hierarchická úroveň je logické datové modely(logické datové modely). Mohou být také označovány jako podnikové datové modely nebo obchodní modely. Tyto modely obsahují datové struktury, jejich atributy a obchodní pravidla a představují informace používané podnikem z obchodního hlediska. V takovém modelu jsou data organizována ve formě entit a vztahů mezi nimi. Logický model představuje data způsobem, který je snadno srozumitelný pro podnikové uživatele. V logickém modelu lze alokovat datový slovník - seznam všech entit s jejich přesnými definicemi, což umožňuje různým kategoriím uživatelů mít společné chápání všech vstupních a informačních výstupních toků modelu. Další, nižší úrovní modelování je již fyzická implementace logického modelu pomocí specifických softwarových nástrojů a technických platforem.

Logický model obsahuje podrobné podnikové obchodní rozhodnutí, které má obvykle formu normalizovaného modelu. Normalizace je proces, který zajišťuje, že každý datový prvek v modelu má pouze jednu hodnotu a je zcela a jednoznačně závislý na primárním klíči. Datové prvky jsou organizovány do skupin podle jejich jednoznačné identifikace. Obchodní pravidla, která řídí datové prvky, musí být plně zahrnuta do normalizovaného modelu s předběžnou kontrolou jejich platnosti a správnosti. Například datový prvek, jako je Jméno zákazníka, by byl s největší pravděpodobností rozdělen na Křestní jméno a Příjmení a seskupen s dalšími relevantními datovými prvky do entity Zákazník s primárním klíčem ID zákazníka.

Logický datový model je nezávislý na aplikačních technologiích, jako jsou databáze, sítě nebo reportovací nástroje a jejich fyzické implementaci. Organizace může mít pouze jeden podnikový datový model. Logické modely obvykle zahrnují tisíce entit, vztahů a atributů. Například datový model pro finanční instituci nebo telekomunikační společnost může obsahovat asi 3000 oborových konceptů.

Je důležité rozlišovat mezi logickým a sémantickým datovým modelem. Logický datový model představuje podnikové obchodní řešení, zatímco sémantický datový model představuje aplikované podnikové řešení. Stejný podnikový logický datový model lze implementovat pomocí různých sémantických modelů, tzn. sémantické modely lze považovat za další úroveň modelování přibližující se fyzickým modelům. Každý z těchto modelů bude navíc představovat samostatný „výsek“ podnikového datového modelu v souladu s požadavky různých aplikací. Například v podnikovém logickém datovém modelu bude entita Klient zcela normalizována a v sémantickém modelu pro datový trh může být reprezentována jako vícerozměrná struktura.

Společnost může mít dva způsoby, jak vytvořit podnikový logický datový model: vytvořit si jej sami nebo použít hotový průmyslový model(odvětvový logický datový model). V tomto případě rozdíly v termínech odrážejí pouze různé přístupy k budování stejného logického modelu. V případě, že společnost samostatně vyvíjí a implementuje svůj vlastní logický datový model, pak se takový model zpravidla nazývá jednoduše podnikový logický model. Pokud se organizace rozhodne použít hotový produkt profesionálního dodavatele, pak můžeme hovořit o průmyslovém logickém datovém modelu. Poslední jmenovaný je hotový logický datový model, který s vysokou mírou přesnosti odráží fungování konkrétního odvětví. Odvětvový logický model je doménově specifický a integrovaný pohled na všechny informace, které musí být v podnikovém datovém skladu k zodpovězení strategických i taktických obchodních otázek. Stejně jako jakýkoli jiný logický datový model není průmyslový model závislý na aplikačních řešeních. Nezahrnuje ani odvozená data nebo jiné výpočty pro rychlejší načítání dat. Většina logických struktur takového modelu zpravidla nachází dobré ztělesnění v efektivní fyzické implementaci. Takové modely vyvíjí mnoho prodejců pro širokou škálu oblastí: finance, výroba, cestovní ruch, zdravotnictví, pojišťovnictví atd.

Odvětvový logický datový model obsahuje informace, které jsou běžné pro dané odvětví, a proto nemohou být úplným řešením pro společnost. Většina společností musí zvýšit model v průměru o 25 % přidáním datových prvků a rozšířením definic. Hotové modely obsahují pouze klíčové datové prvky a zbytek prvků je nutné přidat do příslušných obchodních objektů během instalace modelu ve firmě.

Odvětvové logické datové modely obsahují značný počet abstrakcí. Abstrakce se týká spojení podobných pojmů pod běžnými názvy, jako je událost nebo účastník. To dodává průmyslovým modelům flexibilitu a činí je jednotnějšími. Koncept Event je tedy použitelný ve všech odvětvích.

Expert na Business Intelligence Steve Hoberman nastiňuje pět faktorů, které je třeba vzít v úvahu při rozhodování, zda koupit průmyslový datový model. Prvním je čas a zdroje potřebné k sestavení modelu. Pokud organizace potřebuje dosahovat výsledků rychle, pak průmyslový model poskytne výhodu. Použití odvětvového modelu nemusí okamžitě poskytnout obrázek o celé organizaci, ale může ušetřit značné množství času. Namísto skutečného modelování bude čas věnovat propojování existujících struktur s průmyslovým modelem a také diskuzi o tom, jak jej nejlépe přizpůsobit potřebám organizace (například které definice by se měly změnit a které datové prvky by měly být přidány).

Druhým faktorem je čas a peníze potřebné k udržení modelu v chodu. Pokud model podnikových dat není součástí metodiky, která jej udržuje přesný a aktuální, pak model velmi rychle zastará. Odvětvový datový model může tomuto riziku zabránit, protože je udržován v aktuálním stavu pomocí externích zdrojů. Samozřejmě, že změny, ke kterým dochází v rámci organizace, musí být reflektovány v modelu samotnou společností, ale průmyslové změny budou v modelu reprodukovány jejím dodavatelem.

Třetím faktorem jsou zkušenosti s hodnocením rizik a modelováním. Vytvoření podnikového datového modelu vyžaduje kvalifikované zdroje jak z řad obchodních společností, tak pracovníků IT. Manažeři zpravidla dobře znají buď práci organizace jako celku, nebo činnosti konkrétního oddělení. Jen málo z nich má o svém podnikání široké (celopodnikové) i hluboké (jednotkové) znalosti. Většina manažerů obvykle dobře zná pouze jednu oblast. Proto, abychom získali celopodnikový obrázek, jsou zapotřebí značné obchodní zdroje. To také zvyšuje požadavky na IT pracovníky. Čím více obchodních zdrojů je zapotřebí k vytvoření a testování modelu, tím zkušenější musí být analytici. Musí nejen vědět, jak získat informace od obchodního personálu, ale také umět najít společnou řeč v kontroverzních oblastech a umět všechny tyto informace prezentovat uceleným způsobem. Ten, kdo vytváří model (v mnoha případech je to stejný analytik), musí mít dobré modelovací schopnosti. Vytváření modelů podnikové logiky vyžaduje modelování „pro budoucnost“ a schopnost převést složité podnikání na doslova „čtverce a čáry“.

Na druhou stranu průmyslový model umožňuje využít zkušenosti specialistů třetích stran. Odvětvové logické modely využívají osvědčené modelovací metodologie a týmy zkušených profesionálů, aby se vyhnuly běžným a nákladným problémům, které mohou nastat při vývoji podnikových datových modelů v rámci organizace.

Čtvrtým faktorem je stávající infrastruktura aplikací a vztahy s dodavateli. Pokud organizace již používá mnoho nástrojů od stejného dodavatele a navázala s nimi vztahy, pak má smysl objednat si odvětvový model také u nich. Takový model bude moci volně spolupracovat s jinými produkty stejného dodavatele.

Pátým faktorem je vnitroodvětvová výměna informací. Pokud společnost potřebuje sdílet data s jinými organizacemi působícími ve stejném oboru, pak může být v této situaci velmi nápomocný oborový model. Organizace ve stejném odvětví používají podobné strukturální komponenty a terminologii. V dnešní době jsou ve většině průmyslových odvětví společnosti nuceny sdílet data, aby mohly úspěšně provozovat své podnikání.

Odvětvové modely nabízené profesionálními prodejci jsou nejúčinnější. Vysoká efektivita jejich použití je dosažena díky značné míře detailů a přesnosti těchto modelů. Obvykle obsahují mnoho datových atributů. Kromě toho mají tvůrci těchto modelů nejen rozsáhlé modelářské zkušenosti, ale také se dobře orientují ve stavbě modelů pro konkrétní odvětví.

Odvětvové datové modely poskytují společnostem jediný integrovaný pohled na jejich obchodní informace. Pro mnoho společností je obtížné integrovat svá data, ačkoli to je nezbytným předpokladem pro většinu celopodnikových projektů. Podle studie The Data Warehousing Institute (TDWI) více než 69 % dotázaných organizací zjistilo, že integrace je významnou překážkou pro přijetí nových aplikací. Naopak implementace datové integrace přináší společnosti významný příjem.

Odvětvový datový model, kromě propojení se stávajícími systémy, poskytuje velké výhody pro celopodnikové projekty, jako je plánování podnikových zdrojů (ERP), správa kmenových dat, business intelligence, zlepšování kvality dat a rozvoj zaměstnanců.

Odvětvové logické datové modely jsou tedy účinným nástrojem pro integraci dat a získání holistického obrazu o podnikání. Využití logických modelů se jeví jako nezbytný krok k vytvoření firemních datových skladů.

Publikace

Steve Hoberman. Využití průmyslového logického datového modelu jako vašeho podnikového datového modelu
Claudia Imhoffová. Fast-Tracking Data Warehousing & Business Intelligence projekty prostřednictvím inteligentního datového modelování

Tento článek se zaměří na architekturu datových skladů. Čím se při jeho budování řídit, jaké přístupy fungují – a proč.

"Pohádka je lež - ale je v ní náznak..."

Dědeček zasadil ... sklad. A skladiště rostlo a rostlo. Jen jsem pořádně nevěděl, jak to funguje. A dědeček začal s recenzí. Dědeček zavolal babičku, vnučku, kočku a myš na rodinnou radu. A říká následující téma: „Naše úložiště se rozrostlo. Data ze všech systémů se hrnou, tabulky jsou viditelné i neviditelné. Uživatelé připravují své zprávy. Zdá se, že je vše v pořádku – žít a žít. Ano, jen jeden smutek – nikdo neví, jak to funguje. Vyžaduje to disky zdánlivě-neviditelně - nebudete mít dost! A pak jsou uživatelé, kteří za mnou chodí s různými stížnostmi: buď zpráva zamrzne, nebo jsou data zastaralá. A někdy je to docela katastrofa - přicházíme se zprávami k carovi-otci, ale čísla spolu nesouhlasí. Ještě není ani hodina - král se bude zlobit - pak si hlavu nebourej - ani mně, ani tobě. Tak jsem se rozhodl vás shromáždit a poradit se: co budeme dělat?

Pohlédl na shromáždění a zeptal se:
- Tady máš, babičko, víš, jak máme zařízený sklad?
- Ne, dědečku, já nevím. A jak to mám vědět? Támhle, jací stateční hoši ho hlídají! Nějaké kníry! Nezvyšuj se. Šel jsem je nějak navštívit, upekl koláče. A snědli koláče, utřeli si kníry a řekli: „Proč jsi přišla, babičko? Jaké je vaše úložiště? Řeknete nám, jaký druh zprávy potřebujete - uděláme to za vás! Hlavně nosíš koláče častěji! Bolestně chutnají skvěle.“
- A ty, má milovaná vnučko, víš, jak je naše skladiště uspořádáno?
- Ne, dědečku, já nevím. Dal mi k tomu nějaký přístup. Připojil jsem se, koukám - a jsou tam tabulky - zřejmě neviditelné. A různá schémata jsou skryta. Oči se rozšiřují.... Nejprve jsem byl zmatený. A pak jsem se podíval pozorně – některé jsou prázdné, jiné zaplněné, ale jen z poloviny. Zdá se také, že data se opakují. Není divu, že se nemůžete zásobit disky s takovou redundancí!
- No, ty, kočko, co můžeš říct o našem skladu? Je v tom něco dobrého?
- Ano, jak to neříct, dědečku - řeknu. Na přání své vnučky jsem zkusil vyrobit pilotní pilot v samostatném schématu - malé vitrínce. Abychom pochopili, jaký druh obchodu je pro náš stát prospěšný – jaké produkty jsou pro obchodníky dobré, platí hold – doplňuje se pokladna. A které jsou špatné. A začal jsem sbírat data z tohoto úložiště. Shromážděná fakta. A začal se je snažit porovnávat s produkty. A co, dědečku, viděl jsem - produkty se zdají být stejné, ale podíváte se na znaky - jsou jiné! Začal jsem je pak česat hřebenem své vnučky. Škrábal, škrábal – a vedl k určité uniformitě, laskání oka. Ale brzy jsem se zaradoval - druhý den jsem spustil své skripty, abych aktualizoval nádherná data v okně - a všechno šlo pryč! "Jak to?" - Myslím, - rozčílí se vnučka - dnes by bylo potřeba ukázat našeho pilota ministrovi. Jak na to - s takovými údaji?
- Ano, smutné příběhy, kočko, vyprávěj. No, ty, myško, opravdu jsi se nepokoušela zjistit něco o trezoru? Jsi živá, šikovná, společenská dívka! co nám řekneš?
- Ano, jak, dědečku, nezkoušej - samozřejmě, jsem tichá myš, ale mrštná. Nějakým způsobem vnučka kočky požádala datový model našeho státního úložiště, aby ji získal. A kočka samozřejmě přišla ke mně - na tebe, říká myš, všechna naděje! No, jaký dobrý skutek dobří lidé (a kočky) neudělají? Šel jsem na hrad, kde vedoucí úložiště ukrývá datový model v trezoru. A schoval se. Čekal jsem, až vytáhne ten model z trezoru. Jakmile šel na kávu – vyskočila jsem na stůl. Dívám se na model - ničemu nerozumím! Jak to? Neznám náš trezor! Máme nespočetné tisíce tabulek, dat - neunavitelné proudy! A tady - všechno je harmonické a krásné ... Podíval se na tento model - a uložil ho zpět do trezoru.
- Ano, velmi zvláštní věci, řekl jsi nám, myš.
Děda usilovně přemýšlel.
Co budeme dělat, přátelé? Koneckonců, s takovým úložištěm nebudete dlouho žít ... Uživatelé brzy ztratí trpělivost.

Ať už se náš dědeček z pohádky rozhodne jakkoli – postavit nový sklad nebo se pokusit oživit ten stávající – musíme vyvodit závěry, než si znovu „vyhrneme rukávy“.
Ponechme stranou organizační aspekty – jako je nebezpečí zaměření odbornosti do nějaké úzké uzavřené skupiny, chybějící kontrolní procesy a zajištění transparentnosti architektury systémů používaných v podniku atp.
Dnes bych se rád zaměřil na budování architektury konkrétního systému (nebo skupiny systémů) – datových skladů. Na co je potřeba se zaměřit především, když organizace začíná budovat tak složitý a nákladný systém, jakým je úložiště.

Debriefing

Nikdo z nás, kteří pracujeme na tvorbě a vývoji jakéhokoli systému, nechce, aby to byl „provizorní dům“ nebo řešení, které za rok nebo dva „uvadne“, protože. nebude schopen splnit požadavky a očekávání zákazníků a obchodu. Bez ohledu na to, jak silný je dnes posun k „flexibilním metodologiím“, pro člověka je mnohem příjemnější cítit se jako „mistr“, který vyrábí housle, než jako řemeslník, který vyřezává hole na jednorázové bubny.
Náš záměr zní přirozeně: dělat systémy solidní a kvalitní, které po nás nebudou vyžadovat pravidelné „noční bdění s pilníkem“, za které se nebudeme stydět před koncovými uživateli a které nebudou vypadat jako „černá skříňka“ všem „nezasvěceným“ následovníkům.

Nejprve si uveďme typické problémy, se kterými se při práci s úložišti pravidelně setkáváme. Pojďme si jen napsat, co máme – zatím bez snahy o zefektivnění a formalizaci.

V zásadě máme dobré úložiště: pokud se ho nedotknete, vše funguje. Pravda, jakmile je nutná změna, začnou „místní kolapsy“.
Data se načítají denně, dle předpisů, v rámci jednoho velkého procesu, do 8 hodin. A nám to vyhovuje. Pokud však náhle dojde k poruše, vyžaduje to ruční zásah. A vše pak může dlouho nepředvídatelně fungovat, protože. v procesu je nutná lidská účast.
Rolled release – očekávejte problémy.
Nějaký zdroj nemohl dát data včas - všechny procesy čekají.
Integrita dat je řízena databází – naše procesy tedy havarují, když je narušena.
Máme velmi velké úložiště - 2000 tabulek v jednom společném schématu. A 3000 dalších v mnoha dalších schématech. Už moc netušíme, jak jsou uspořádány a z jakého důvodu se objevily. Proto pro nás může být obtížné něco znovu použít. A mnoho problémů se musí znovu vyřešit. Protože je to jednodušší a rychlejší (než rozumět „v cizím kódu“). V důsledku toho máme nesrovnalosti a duplicitní funkce.
Očekáváme, že zdroj poskytne kvalitní data. Jenže se ukazuje, že tomu tak není. V důsledku toho trávíme spoustu času sesouhlasením našich závěrečných zpráv. A byli v tom velmi úspěšní. Dokonce máme zjednodušený proces. Pravda, chce to čas. Uživatelé jsou ale zvyklí...
Uživatel ne vždy důvěřuje našim zprávám a vyžaduje zdůvodnění konkrétního čísla. V některých případech má pravdu a v jiných se mýlí. Je pro nás ale velmi obtížné je doložit, protože neposkytujeme prostředky "end-to-end analýzy" (nebo datové linie).
Mohli bychom přivést další vývojáře. Ale máme problém – jak je proměnit v práci? Jaký je nejúčinnější způsob paralelizace práce?
Jak systém vyvíjet postupně, aniž byste se museli věnovat vývoji „jádra systému“ celý rok?
Datový sklad je spojen s firemním modelem. S jistotou ale víme (viděli jsme to v bance XYZ), že model je možné stavět donekonečna (v bance XYZ jsme půl roku obcházeli a diskutovali o podnikatelských subjektech, bez jakéhokoliv pohybu). Proč vůbec je? Nebo je to možná lepší bez ní, když je s ní tolik problémů? Možná to nějak vygenerovat?
Rozhodli jsme se vést model. Jak ale systematicky rozvíjet datový model skladu? Potřebujeme „pravidla hry“ a jaká mohou být? co nám to dá? Co když uděláme chybu s modelem?
Máme ukládat data, případně historii jejich změn, když je „podnik nepotřebuje“? Nerad bych „skladoval odpadky“ a komplikoval použití těchto dat pro reálné úkoly. Měl by trezor uchovávat historii? Jaké to je? Jak úložiště funguje v průběhu času?
Je nutné zkoušet sjednotit data v úložišti, pokud máme systém správy NSI? Pokud existuje MDM, znamená to, že nyní je celý problém kmenových dat vyřešen?
Očekává se, že brzy nahradíme klíčové účetní systémy. Mělo by být úložiště dat připraveno na změnu zdroje? Jak toho dosáhnout?
Potřebujeme metadata? Co tím máme chápat? Kde přesně je lze použít? Jak to lze implementovat? Je potřeba je mít „na jednom místě“?
Naši zákazníci jsou extrémně labilní ve svých požadavcích a přáních – neustále se něco mění. Obecně je naše podnikání velmi dynamické. Zatímco něco děláme, stává se to již zbytečným. Jak se můžeme ujistit, že výsledky dosáhneme co nejrychleji – jako horké koláče?
Uživatelé požadují rychlost. Ale nemůžeme spouštět naše hlavní spouštěcí procesy často, protože to zatěžuje zdrojové systémy (má špatný vliv na výkon) - proto zavěšujeme další datové toky - což bodově vezme - to, co potřebujeme. Pravda, ukazuje se, že hodně toků. A pak vyhodíme některá data. Kromě toho bude problém s konvergencí. Ale jinak to nejde...

Stalo se toho už docela hodně. Ale toto není úplný seznam - je snadné jej doplnit a rozvíjet. Neschováme ho na stůl, ale pověsíme na nápadné místo – tyto záležitosti udržíme v centru naší pozornosti v procesu práce.
Naším úkolem je ve výsledku vyvinout komplexní řešení.

antikřehkost

Při pohledu na náš seznam lze vyvodit jeden závěr. Není těžké vytvořit jakousi „databázi pro reporting“, hodit tam data, nebo dokonce vybudovat nějaké rutinní procesy aktualizace dat. Systém začíná nějak žít, objevují se uživatelé a s nimi povinnosti a SLA, vznikají nové požadavky, připojují se další zdroje, mění se metodiky – s tím vším je třeba počítat v procesu vývoje.

Po nějaké době je obrázek následující:
„Tady je trezor. A funguje to, když se toho nedotknete. Problémy nastávají, když musíme něco změnit.“

Přichází k nám změna, jejíž dopad nejsme schopni vyhodnotit a pochopit (protože jsme takové nástroje do systému původně nedali) - a abychom neriskovali, nesaháme na to, co je, ale děláme ještě jeden přístavba na straně a ještě jedna a další - naše rozhodnutí se mění ve slumy, nebo jak se říká v Latinské Americe, "favelas", kam se bojí jít i policie.
Dostavuje se pocit ztráty kontroly nad vlastním systémem, chaos. K udržení stávajících procesů a řešení problémů je zapotřebí stále více rukou. A dělat změny je stále těžší. Jinými slovy, systém se stává nestabilním vůči namáhání, nepřizpůsobivý změnám. A kromě toho existuje silná závislost na postavách, které "znají fairway", protože nikdo nemá "kartu".

Touto vlastností předmětu je kolaps pod vlivem chaosu, náhodných událostí a otřesů – říká Nassim Nicholas Taleb křehkost . Zavádí také opačný koncept: antikřehkost – kdy objekt není zničen stresem a nehodami, ale získává z něj přímý užitek. ("Antifragilita. Jak těžit z chaosu")
Jinak se to dá nazvat přizpůsobivost nebo odolnost vůči změně .

Co to v tomto kontextu znamená? Jaké jsou „zdroje chaosu“ pro IT systémy? A co znamená „vydělávat na chaosu“ z hlediska IT architektury?
První myšlenka, která vás napadne, jsou změny, které přicházejí zvenčí. Co je pro systém vnější svět? Zejména pro skladování. Samozřejmě za prvé - změny ze zdrojů dat pro sklad:

změna formátů příchozích dat;
nahrazení některých systémů zdrojů dat jinými;
změna pravidel/platforem pro systémovou integraci;
změna interpretace dat (ukládají se formáty, mění se logika práce s daty);
změna datového modelu, pokud je integrace provedena na úrovni dat (analýza souborů protokolu transakcí databáze);
růst objemů dat - zatímco ve zdrojovém systému bylo málo dat a zatížení bylo malé - bylo možné je vzít kdykoli, s libovolně velkým požadavkem narostla data a zatížení - nyní jsou přísná omezení;
atd.

Měnit se mohou samotné zdrojové systémy, skladba informace a její struktura, typ integrační interakce, ale i samotná logika práce s daty. Každý systém implementuje svůj vlastní datový model a přístupy k práci s nimi, které splňují cíle a záměry systému. A bez ohledu na to, jak moc se snaží sjednotit průmyslové modely a referenční postupy, nuance se stejně nevyhnutelně objeví. (A kromě toho samotný proces sjednocování průmyslu se z různých důvodů příliš neposouvá.)
Kultura práce s firemními daty - přítomnost a kontrola informační architektury, jednotný sémantický model, systémy správy hlavních dat (MDM) poněkud usnadňují úkol konsolidace dat ve skladu, ale nevylučují jeho nutnost.

Neméně důležité změny jsou iniciovány spotřebiteli úložiště (změny požadavků):

dříve bylo k sestavení sestavy dostatek dat – nyní bylo nutné připojit další pole nebo nový zdroj dat;
dříve implementované metody zpracování dat jsou zastaralé - je třeba přepracovat algoritmy a vše, co to ovlivňuje;
Dříve byli všichni spokojeni s aktuální hodnotou atributu slovníku na informačním panelu - nyní je vyžadována hodnota, která je relevantní v době výskytu analyzované skutečnosti / události;
byl požadavek na hloubku historie ukládání dat, která tu dříve nebyla - ukládat data ne na 2 roky, ale na 10 let;
dříve byl dostatek dat ke stavu „konec dne / období“ - nyní je potřeba stav dat „vnitrodenní“, nebo v době určité události (například rozhodování o žádosti o úvěr – pro Basilej II);
dříve jsme byli spokojeni s reportováním dat za včerejšek (T-1) nebo později, nyní potřebujeme T0;
atd.

Jak integrační interakce se zdrojovými systémy, tak požadavky spotřebitelů dat úložiště jsou externími faktory pro datový sklad: jeden zdrojový systém nahrazuje jiný, objemy dat rostou, formáty příchozích dat se mění, požadavky uživatelů se mění atd. A to všechno jsou typické externí změny, na které musí být náš systém – naše úložiště – připraven. Se správnou architekturou by neměli zabíjet systém.

Ale to není vše.
Když už mluvíme o variabilitě, nejprve si vybavíme vnější faktory. Koneckonců, uvnitř můžeme ovládat všechno, zdá se nám, že? Ano i ne. Ano, většina faktorů, které jsou mimo zónu vlivu, jsou vnější. Existuje však také „vnitřní entropie“. A právě kvůli jeho přítomnosti se občas potřebujeme vrátit „do bodu 0“. Spusťte hru znovu.
V životě máme často tendenci začínat od nuly. Proč k tomu máme sklon? A je to tak špatné?
Aplikováno na IT. Pro samotný systém – to může být velmi dobré – schopnost přehodnotit jednotlivá rozhodnutí. Zvlášť, když to umíme lokálně. Refaktoring je proces rozplétání „pavučiny“, který se periodicky objevuje v procesu vývoje systému. Návrat „na začátek“ může být užitečný. Ale má to cenu.
Při správné správě architektury se tato cena snižuje – a samotný proces vývoje systému se stává kontrolovatelnějším a transparentnějším. Jednoduchý příklad: při dodržení principu modularity je možné přepsat samostatný modul bez ovlivnění externích rozhraní. A to nelze provést s monolitickou konstrukcí.

Antifragility systému je dána jeho architekturou. A právě díky této vlastnosti je adaptivní.
Když mluvíme o adaptivní architektura- máme na mysli, že se systém dokáže přizpůsobit změnám, a už vůbec ne to, že neustále měníme samotnou architekturu. Naopak, čím stabilnější a stabilnější architektura, čím méně požadavků na její revizi, tím je systém přizpůsobivější.

Řešení, která vyžadují revizi celé architektury, budou mít mnohem vyšší cenu. A pro jejich přijetí musíte mít velmi dobré důvody. Takovým důvodem může být například požadavek, který nelze v rámci současné architektury implementovat. Pak říkají – byl požadavek, který ovlivňuje architekturu.
Proto také potřebujeme znát naše „limity antifragility“. Architektura se nevyvíjí „ve vzduchoprázdnu“ – vychází ze současných požadavků a očekávání. A pokud se situace zásadně změní - musíme pochopit, že jsme překročili současnou architekturu - a musíme ji revidovat, vyvinout jiné řešení - a přemýšlet o přechodových cestách.
Například jsme se zavázali, že data budeme potřebovat vždy na konci dne ve skladu, sběr dat budeme provádět denně pomocí standardních systémových rozhraní (prostřednictvím sady pohledů). Z oddělení řízení rizik pak přišly požadavky na nutnost přijímat data ne na konci dne, ale v době rozhodování o půjčce. Není třeba se snažit „natahovat nenatažené“ – jen je potřeba tento fakt uznat – čím dříve, tím lépe. A začít pracovat na přístupu, který nám umožní problém vyřešit.
Je zde velmi tenká hranice – pokud vezmeme v úvahu pouze „aktuální požadavky“ a nedíváme se na několik kroků dopředu (a několik let dopředu), zvyšujeme riziko, že se s požadavkem ovlivňujícím architekturu setkáme příliš pozdě – a náklady na naši změnu budou velmi vysoké. Pohled trochu dopředu – v rámci hranic našeho horizontu – ještě nikdy nikomu neuškodil.

Příklad systému z „úložné pohádky“ je jen příkladem velmi vratkého systému postaveného na křehkých designových přístupech. A pokud k tomu dojde, dojde u této konkrétní třídy systémů ke zničení poměrně rychle.
Proč to můžu říct? Téma skladování není nové. Přístupy a inženýrské postupy, které byly během této doby vyvinuty, byly zaměřeny právě na toto – zachování životaschopnosti systému.
Vezměme si jednoduchý příklad, jedním z nejčastějších důvodů, proč projekty takeoff storage selžou, je, když se pokoušejí vybudovat úložiště nad zdrojovými systémy ve vývoji bez odpovídajících integračních rozhraní – ve snaze získat data přímo z tabulek. V důsledku toho přešly do vývoje – během této doby se zdrojová databáze změnila – a streamy stahování v úložišti přestaly fungovat. Je příliš pozdě něco předělávat. A pokud jste se nezajistili vytvořením několika vrstev stolů uvnitř úložiště, můžete vše zahodit a začít znovu. Toto je jen jeden příklad a jeden z nejjednodušších.

Talebovo kritérium pro křehkost a antikřehkost je jednoduché. Hlavním rozhodčím je čas. Pokud systém obstojí ve zkoušce času a ukáže svou „přežití“ a „nezničitelnost“ – má vlastnost antifragility.
Pokud při navrhování systému vezmeme v úvahu antifragility jako požadavek, pak nás to povzbudí k tomu, abychom použili takové přístupy k budování jeho architektury, díky nimž se systém lépe přizpůsobí jak „chaosu zvenčí“, tak „chaosu zevnitř“. ." A nakonec bude mít systém delší životnost.
Nikdo z nás nechce dělat „dočasné“. A nedělejte si iluze, že teď to jinak nejde. Dívat se o pár kroků dopředu je pro člověka normální kdykoli, zvláště v době krize.

Co je to datový sklad a proč jej budujeme

Článek o architektuře úložiště předpokládá, že čtenář nejen ví, co to je, ale má s takovými systémy i určité zkušenosti. Přesto jsem to považoval za nutné udělat – vrátit se k počátkům, na začátek cesty, protože. právě tam se nachází „opěrný bod“ rozvoje.

Jak lidé přišli na to, že jsou potřeba datové sklady? A jak se liší od pouhé „velmi velké databáze“?
Kdysi dávno, kdy na světě byly jednoduše „systémy pro zpracování obchodních dat“, neexistovalo žádné rozdělení IT systémů do takových tříd, jako jsou front-end oltp systémy, back-office dss, systémy pro zpracování textových dat, datové sklady atd. .
To byla doba, kdy Michael Stonebreaker vytvořil první relační DBMS Ingres.
A to byla doba, kdy éra osobních počítačů vtrhla do počítačového průmyslu jako vichřice a navždy obrátila všechny nápady tehdejší IT komunity.

Pak už bylo snadné najít podnikové aplikace napsané na bázi DBMS třídy desktopů – jako jsou Clipper, dBase a FoxPro. A trh aplikací typu klient-server a DBMS jen nabíral na síle. Jeden po druhém se objevovaly databázové servery, které by na dlouhou dobu obsadily své místo v IT prostoru - Oracle, DB2 atd.
A termín „databázová aplikace“ koloval. Co taková aplikace obsahovala? Zjednodušené - některé vstupní formuláře, pomocí kterých mohli uživatelé současně zadávat informace, některé výpočty, které byly spuštěny „na tlačítko“ nebo „podle plánu“, a také některé zprávy, které bylo možné vidět na obrazovce nebo uložit jako soubory a odeslat k zapečetění .
"Nic zvláštního - jen jednoduchá aplikace, jen databáze," poznamenal jeden z mých prvních mentorů. "Není to nic zvláštního?" - Myslel jsem tehdy.

Pokud se podíváte pozorně, stále existují funkce. S růstem uživatelů se zvyšuje objem příchozích informací, se zvyšujícím se zatížením systému jeho vývojáři-konstruktéři, aby udrželi výkon na přijatelné úrovni, jdou na nějaké „triky“. Tou úplně první je rozdělení monolitického „systému pro zpracování obchodních dat“ na účetní aplikaci podporující práci uživatelů v on-line režimu a samostatnou aplikaci pro dávkové zpracování a reporting dat. Každá z těchto aplikací má svou vlastní databázi a je dokonce hostována na samostatné instanci databázového serveru s různým nastavením pro různé typy zátěže – OLTP a DSS. A mezi nimi se budují datové toky.

To je všechno? Zdálo by se, že problém je vyřešen. Co se stane dál?
A pak firmy rostou, jejich informační potřeby se násobí. Roste také počet interakcí s vnějším světem. A ve výsledku neexistuje jedna velká aplikace, která plně automatizuje všechny procesy, ale několik různých, od různých výrobců. Systémů, které generují informace - systémy zdrojů dat ve firmě přibývá. A dříve nebo později bude potřeba vidět a porovnávat informace získané z různých systémů. Tak se ve společnosti objevuje Data Warehousing, nová třída systémů.
Obecně přijímaná definice této třídy systémů je následující.

Datový sklad (nebo Datový sklad)– doménově specifická informační databáze, speciálně navržená a určená pro přípravu reportů a obchodních analýz za účelem podpory rozhodování v organizaci

Takto, konsolidace data z různých systémů, schopnost nahlížet na ně určitým „jednotným“ (jednotným) způsobem je jednou z klíčových vlastností systémů třídy ukládání dat. To je důvod, proč úložiště vzniklo během vývoje IT systémů.

Klíčové vlastnosti datových skladů

Pojďme se na to podívat podrobněji. Jaké jsou klíčové vlastnosti těchto systémů? Čím se datové sklady liší od jiných podnikových IT systémů?

Za prvé, jde o velké objemy. Velmi velký. VLDB - takto nazývají tyto systémy přední prodejci, když dávají svá doporučení k použití jejich produktů. Ze všech firemních systémů proudí data do této velké databáze a jsou tam uložena „navždy a beze změny“, jak se říká v učebnicích (v praxi se ukazuje, že život je složitější).

Za druhé jsou to historická data − "firemní paměť" - tzv. datové sklady. Z hlediska práce s časem ve skladu je vše docela zajímavé. V účetních systémech jsou v tuto chvíli relevantní data. Poté uživatel provede nějakou operaci – a data se aktualizují. Zároveň nemusí být zachována historie změn – záleží na účetní praxi. Vezměte si například zůstatek na bankovním účtu. Může nás zajímat aktuální zůstatek „nyní“, na konci dne nebo v době nějaké události (například v době, kdy se počítá skóre). Pokud jsou první dva vyřešeny docela jednoduše, pak to bude pravděpodobně vyžadovat zvláštní úsilí. Při práci s úložištěm může uživatel přistupovat k minulým obdobím, porovnávat je s aktuálním a podobně. Právě tyto časově související schopnosti výrazně odlišují datové sklady od účetních systémů – získávání stavu dat v různých bodech časové osy – do určité hloubky v minulosti.

Za třetí, toto konsolidace a sjednocení dat . Aby byla možná jejich společná analýza, je nutné je uvést do společné podoby - jednotný datový model , porovnejte fakta s jednotnými referenčními knihami. Zde může být několik aspektů a obtíží. Především - pojmový – pod stejným pojmem mohou různí lidé z různých oddělení rozumět různým věcem. A naopak – jinak nazývat něco, co je v podstatě totéž. Jak zajistit „jednotný pohled“, a přitom zachovat specifika vize konkrétní skupiny uživatelů?

Za čtvrté je to práce s datová kvalita . V procesu načítání dat do úložiště jsou vyčištěna, jsou prováděny obecné transformace a transformace. Obecné transformace musí být provedeny na jednom místě – a poté použity k vytvoření různých sestav. Vyhnete se tak nesrovnalostem, které způsobují tolik podráždění pro podnikové uživatele – zejména pro management, který se ke stolu dostává s čísly z různých oddělení, která spolu nesouhlasí. Špatná kvalita dat vede k chybám a nesrovnalostem v reportech, jejichž důsledkem je snížení úrovně uživatelská důvěra k celému systému, k celé analytické službě jako celku.

architektonický koncept

Každý, kdo na úložiště narazil, s největší pravděpodobností pozoroval nějakou „vrstvenou strukturu“ – protože. je to architektonické paradigma, které zakořenilo systémy této třídy. A ani náhodou. Úložné vrstvy lze vnímat jako samostatné součásti systému – s vlastními úkoly, oblastmi odpovědnosti, „pravidly hry“.
Vrstvená architektura je prostředkem, jak se vypořádat se složitostí systému – každá následující vrstva je abstrahována od složitostí vnitřní implementace té předchozí. Tento přístup vám umožňuje identifikovat úkoly stejného typu a řešit je jednotným způsobem, aniž byste museli pokaždé znovu vymýšlet „kolo“.
Schematické koncepční architektonické schéma je znázorněno na obrázku. Jedná se o zjednodušený diagram, který odráží pouze klíčovou myšlenku – koncept, avšak bez „anatomických detailů“, které vyvstanou při hlubším studiu detailů.

Jak je znázorněno na obrázku, koncepčně vyberte následující vrstvy. Tři hlavní vrstvy, které obsahují oblast pro ukládání dat (označená vyplněným obdélníkem) a software pro načítání dat (podmíněně znázorněna šipkami stejné barvy). Stejně jako pomocná - servisní vrstva, která však hraje velmi důležitou spojovací roli - řízení načítání dat a kontrola kvality.

Primary Data Layer – primární datová vrstva (nebo inscenování , nebo operační vrstva ) - je navržen pro načtení ze zdrojových systémů a uložení primárních informací, bez transformací - v původní kvalitě a s podporou kompletní historie změn.
Úkolem této vrstvy– abstrahovat následné úložné vrstvy z fyzického zařízení zdrojů dat, metod sběru dat a metod pro extrakci delty změn.

Core Data Layer – jádro úložiště - centrální komponenta systému, která odlišuje úložiště od pouhé „platformy dávkové integrace“ nebo „velkého datového výpisu“, protože jeho hlavní rolí je konsolidace dat z různých zdrojů, redukce na jednotné struktury, klíče. Právě při načítání do jádra se provádí hlavní práce s kvalitou dat a obecnými transformacemi, což může být poměrně složité.
Úkolem této vrstvy- abstrahovat své spotřebitele od zvláštností logické struktury zdrojů dat a potřeby porovnávat data z různých systémů, zajistit integritu a kvalitu dat.

Data Mart Layer - analytické vitríny - komponenta, jejíž hlavní funkcí je převádět data do struktur vhodných pro analýzu (pokud BI pracuje s výklady, pak se obvykle jedná o rozměrový model), nebo podle požadavků spotřebitelského systému.
Data marts zpravidla přebírají data z jádra - jako spolehlivý a ověřený zdroj - tzn. využít službu této komponenty k přenesení dat do jednoho formuláře. Takovým oknům budeme říkat pravidelný . V některých případech mohou výklady přebírat data přímo ze stagingu – pracovat s primárními daty (ve zdrojových klíčích). Tento přístup se zpravidla používá pro lokální úlohy, kde není vyžadována konsolidace dat z různých systémů a kde je potřeba více efektivity než kvalita dat. Takové displeje se nazývají provozní . Některé analytické ukazatele mohou mít velmi složité metody výpočtu. Proto pro takovéto netriviální výpočty a transformace, tzv sekundární vitríny .
Úloha vrstvy obchodu– příprava dat dle požadavků konkrétního spotřebitele – BI platformy, skupiny uživatelů nebo externího systému.

Výše popsané vrstvy se skládají z oblasti trvalého úložiště dat a také ze softwarového modulu pro načítání a transformaci dat. Toto rozdělení do vrstev a oblastí je logické. Fyzická implementace těchto komponent může být různá – můžete dokonce použít různé platformy k ukládání nebo transformaci dat na různých vrstvách, pokud je to efektivnější.
Úložné prostory obsahují technické (bufferové tabulky), které se používají v procesu transformace dat a cílové tabulky, ke kterým má přístup spotřebitelská komponenta. Je dobrým zvykem „pokrýt“ cílové tabulky pohledy. To usnadňuje následnou údržbu a rozvoj systému. Data v cílových tabulkách všech tří vrstev jsou označena speciálními technickými poli (metaatributy), které slouží k zajištění procesů načítání dat a také k umožnění informačního auditu datových toků v úložišti.

Rozlišuje se také speciální komponenta (nebo sada komponent), která zajišťuje servisní funkce pro všechny vrstvy. Jedním z jeho klíčových úkolů – kontrolní funkce – je poskytovat „jediná pravidla hry“ pro celý systém jako celek, přičemž je ponecháno právo používat různé možnosti implementace každé z výše popsaných vrstev – vč. používat různé technologie pro načítání a zpracování dat, různé úložné platformy atd. Zavolejme mu servisní vrstva (Service Layer) . Neobsahuje obchodní data, ale má vlastní struktury úložiště - obsahuje oblast metadat, dále oblast pro práci s kvalitou dat (a případně další struktury, podle funkcí, které jsou jí přiřazeny).

Takto jasné rozdělení systému na samostatné komponenty výrazně zvyšuje ovladatelnost vývoje systému:

snižuje se složitost úkolu, který je zadán vývojáři funkčnosti konkrétní komponenty (nemusí současně řešit integrační problémy s externími systémy a promýšlet postupy čištění dat a přemýšlet o optimální prezentaci dat pro spotřebitelé) - úkol je snazší rozložit, vyhodnotit a provést malou dodávku;
do práce můžete zapojit různé umělce (a dokonce i týmy nebo dodavatele) – protože tento přístup umožňuje efektivně paralelizovat úkoly a omezit jejich vzájemný vliv;
přítomnost perzistentního stagingu umožňuje rychle propojit datové zdroje bez navrhování celého jádra nebo vitrín pro celou tematickou oblast a následně postupně budovat zbytek vrstev podle priorit (navíc data již budou v úložišti - k dispozici na systémové analytiky, což výrazně usnadní úkoly následného rozvoje úložiště);
přítomnost jádra umožňuje skrýt veškerou práci s kvalitou dat (stejně jako případná nedopatření a chyby) před výlohami i před koncovým uživatelem, a co je nejdůležitější, použitím této komponenty jako jediného zdroje dat pro výlohy se můžete vyhnout problémům s konvergencí dat díky implementaci společných algoritmů na jednom místě;
zvýraznění výkladních skříní vám umožňuje vzít v úvahu rozdíly a specifika chápání dat, která mohou mít uživatelé různých oddělení, a jejich navrhování pro požadavky BI vám umožňuje nejen vydávat agregovaná čísla, ale také zajistit spolehlivost dat tím, že poskytuje příležitosti k rozbalení k primárním ukazatelům;
přítomnost servisní vrstvy umožňuje provádět komplexní analýzu dat (data lineage), používat jednotné nástroje pro audit dat, běžné přístupy ke zdůraznění rozdílu změn, práci s kvalitou dat, správu zátěže, monitorování chyb a diagnostické nástroje a urychluje řešení problémů.

Tento přístup k rozkladu také činí systém odolnějším vůči změnám (ve srovnání s "monolitickou strukturou") - zajišťuje jeho antifragility:

změny ze zdrojových systémů se zpracovávají při stagingu - v jádře se upravují pouze vlákna, která jsou ovlivněna těmito stagingovými tabulkami, vliv na výklady je minimální nebo chybí;
změny požadavků zákazníků jsou zpracovávány většinou ve výlohách (pokud to nevyžaduje další informace, které již na skladě nejsou).

Dále si projdeme každou z výše uvedených součástí a podíváme se na ně trochu podrobněji.

Jádro systému

Začněme „od středu“ – jádro systému neboli střední vrstva. Není označeno jako Core Layer. Jádro plní roli konsolidace dat – redukce na jednotlivé struktury, adresáře, klíče. Zde se provádí hlavní práce s kvalitou dat - čištění, transformace, sjednocení.

Přítomnost této komponenty vám umožňuje znovu použít datové toky, které transformují primární data přijatá ze zdrojových systémů do jediného formátu podle společných pravidel a algoritmů, spíše než opakovat implementaci stejné funkce samostatně pro každou aplikaci, která kromě neefektivní využívání zdrojů, může také vést k nesrovnalostem v datech.
Úložné jádro je implementováno v datovém modelu, v obecném případě odlišném jak od modelů zdrojových systémů, tak od formátů a struktur spotřebitelů.

Model úložiště a podnikový datový model

Hlavním úkolem střední úložné vrstvy je stabilita. Proto je zde hlavní důraz kladen na datový model. Bývá označován jako „podnikový datový model“. Bohužel se kolem něj vytvořilo jisté haló mýtů a absurdit, které někdy vedou k úplnému opuštění jeho konstrukce, ale marně.

mýtus 1. Podnikový datový model je obrovský model skládající se z tisíců entit (tabulek).
Vlastně. V jakékoli předmětové oblasti, v jakékoli obchodní doméně, v datech jakékoli společnosti, i té nejsložitější, existuje několik základních subjektů - 20-30.

mýtus 2 Není potřeba vyvíjet žádný „vlastní model“ – kupujeme oborový referenční model – a vše děláme podle něj. Utrácíme peníze – ale výsledek je zaručený.
Vlastně. Referenční modely mohou být opravdu velmi užitečné, protože. obsahují průmyslové zkušenosti s modelováním této oblasti. Z nich můžete čerpat nápady, přístupy, postupy pojmenování. Zkontrolujte si „hloubku pokrytí“ oblasti, ať vám neunikne něco důležitého. Ale je nepravděpodobné, že bychom mohli použít takový model "z krabice" - tak, jak je. Jde o stejný mýtus jako například nákup ERP systému (nebo CRM) a jeho implementace bez jakéhokoli „kroucení pro sebe“. Hodnota těchto modelů se rodí v jejich přizpůsobení realitě tohoto konkrétního podnikání, této konkrétní společnosti.

mýtus 3. Vývoj modelu úložného jádra může trvat mnoho měsíců, během kterých bude projekt skutečně zmrazen. Navíc to vyžaduje šílené množství schůzek a účast mnoha lidí.
Vlastně. Model úložiště lze vyvíjet iterativně, kousek po kousku, spolu s úložištěm. Pro nekryté plochy se umisťují "prodlužovací body" nebo "pahýly" - tzn. uplatňují se některé „univerzální konstrukce“. Zároveň musíte vědět, kdy přestat, abyste nedostali superuniverzální věc o 4 tabulkách, do kterých je těžké jak data „vložit“, tak (ještě obtížnější) je získat. A což je z hlediska výkonu extrémně neoptimální.

Vývoj modelu zabere čas. Ale to není čas strávený na „kreslení entit“ - to je čas potřebný k analýze předmětné oblasti, pochopení toho, jak jsou data strukturována. To je důvod, proč jsou do tohoto procesu velmi úzce zapojeni analytici a také různí obchodní experti. A to se děje selektivně. A ne organizováním schůzek se šíleným počtem lidí, zasíláním obrovských dotazníků atd.
Kvalitní podniková a systémová analýza je klíčem k vybudování modelu jádra úložiště. Musíte pochopit spoustu věcí: kde (v jakých systémech) se data generují, jak jsou uspořádána, v jakých obchodních procesech kolují atd. Kvalitativní analýza nikdy žádnému systému neuškodila. Naopak, problémy vyvstávají z „prázdných míst“ v našem chápání.

Vývoj datového modelu není proces vymýšlení a vymýšlení něčeho nového. Ve skutečnosti datový model ve společnosti již existuje. A proces jeho navrhování připomíná spíše „vykopávky“. Model je jemně a pečlivě vyveden na světlo z „půdy“ firemních dat a oděn do strukturované podoby.

mýtus 4. V naší firmě je byznys tak dynamický a vše se mění tak rychle, že je pro nás zbytečné dělat model - zastará, než tuto část systému zprovozníme.
Vlastně. Připomeňme, že klíčovým faktorem jádra je stabilita. A především topologie modelu. Proč? Protože právě tato složka je ústřední a ovlivňuje vše ostatní. Požadavkem na model jádra je také stabilita. Pokud model zastará příliš rychle, pak je nesprávně navržen. Pro jeho vývoj byly zvoleny špatné přístupy a „pravidla hry“. Je to také otázka kvalitativní analýzy. Klíčové entity podnikového modelu se mění velmi zřídka.
Ale pokud nás napadne udělat pro společnost, která prodává, řekněme, cukrovinky, místo adresáře „Produkty“ vyrábět „Sladkosti“, „Dorty“ a „Pies“. Když se pak v seznamu zboží objeví pizza - ano, budete muset zadat spoustu nových tabulek. A je to jen o přístupu.

mýtus 5. Vytvoření firemního modelu je velmi seriózní, komplexní a zodpovědná záležitost. A je děsivé udělat chybu.
Vlastně. Základní model, i když by měl být stabilní, stále není „odlitý do kovu“. Stejně jako u jiných návrhových rozhodnutí může být jeho struktura přezkoumána a upravena. Jen na tuto její vlastnost nezapomeňte. To ale vůbec neznamená, že na něj „nedýcháte“. A to neznamená, že dočasná řešení a „pahýly“, které by měly být naplánovány ke zpracování, jsou nepřijatelná.

mýtus 6. Pokud máme zdroj dat - například systém NSI (nebo systém správy hlavních dat - MDM), pak by měl v dobrém slova smyslu korespondovat s firemním modelem (zejména pokud byl nedávno navržen a nestihl pořídit „vedlejší účinky“, „tradice“ a dočasné stavby). Ukazuje se, že pro tento případ - nepotřebujeme model jádra?
Vlastně. Ano, v tomto případě je stavba modelu úložného jádra značně usnadněna – protože řídíme se špičkovým hotovým koncepčním modelem. Ale vyloučeno to vůbec není. Proč? Protože při sestavování modelu určitého systému platí určitá pravidla – jaké typy tabulek použít (pro každou entitu), jak verze dat, s jakou granularitou uchovávat historii, jaké metaatributy (technická pole použít) atd. .

Kromě toho, bez ohledu na to, jak úžasný a komplexní systém NSI a MDM máme, zpravidla budou existovat nuance spojené s existencí místních adresářů „přibližně stejných“ v jiných účetních systémech. A tento problém, ať se nám to líbí nebo ne, bude muset vyřešit na úložišti, protože zde se shromažďují reporting a analýzy.

Primární datová vrstva (nebo historizovatelná pracovní nebo provozní vrstva)

Na něm je označena jako primární datová vrstva. Role této komponenty: integrace se zdrojovými systémy, načítání a ukládání primárních dat a také předběžné čištění dat – kontrola dodržování pravidel formátově logické kontroly, pevně stanovených v „dohodě o interakčním rozhraní“ se zdrojem.
Kromě toho tato komponenta řeší velmi důležitý úkol pro úložiště - zvýraznění "skutečné delty změn" - bez ohledu na to, zda vám zdroj umožňuje sledovat změny v datech nebo ne a jak (podle jakého kritéria je lze "chytit" ). Jakmile se data dostala do stagingu, je již problematika delta výběru pro všechny ostatní vrstvy jasná díky označení metaatributy.

Data v této vrstvě jsou uložena ve strukturách, které jsou co nejblíže zdrojovému systému – aby primární data zůstala co nejblíže jejich původní podobě. Jiný název pro tuto komponentu je "operační vrstva".
Proč nepoužít zavedený termín „inscenace“? Faktem je, že dříve, před „érou velkých dat a VLDB“, byl diskový prostor velmi drahý – a primární data, pokud byla uložena, byla často jen po omezenou dobu. A často se říká „inscenování“. čistitelné vyrovnávací paměť.
Nyní technologie pokročila vpřed – a my si můžeme dovolit nejen ukládat všechna primární data, ale také je historizovat s takovou mírou granularity, jaká je jen možná. Neznamená to, že bychom neměli kontrolovat růst dat a neodstraňuje nutnost řídit životní cyklus informací optimalizací nákladů na ukládání dat v závislosti na „teplotě“ používání – tzn. přesun „studených dat“, která jsou méně žádaná, na levnější média a úložné platformy.

Co nám dává přítomnost „historické inscenace“:

možnost dělat chyby (ve strukturách, v transformačních algoritmech, v granularitě vedení historie) - díky kompletně historizovaným primárním datům v zóně dostupnosti úložiště můžeme vždy znovu načíst naše tabulky;
příležitost k zamyšlení – v této iteraci vývoje úložiště si můžeme dát na čas s vývojem velkého fragmentu jádra, protože v našem nastudování každopádně budou a se sudým časovým horizontem (bude zde jedno „výchozí místo dějin“);
možnost analýzy - uložíme i ta data, která již ve zdroji nejsou - mohla by se tam přepsat, přejít do archivu atp. – u nás zůstávají k dispozici pro analýzu;
možnost informačního auditu - díky nejpodrobnějším primárním informacím pak budeme schopni přijít na to, jak nám stahování fungovalo, že jsme se nakonec dostali k takovým číslům (k tomu je potřeba mít označené i metaatributy a odpovídající metadata, na kterých stahování funguje – o tom se rozhoduje na vrstvě služeb).

Jaké potíže mohou nastat při konstrukci „historické inscenace“:

bylo by vhodné nastavit požadavky na transakční integritu této vrstvy, ale praxe ukazuje, že toho je obtížné dosáhnout (to znamená, že v této oblasti nezaručujeme referenční integritu nadřazených a podřízených tabulek) - k zarovnání integrity dochází při následných vrstvy;
tato vrstva obsahuje velmi velké objemy (největší v úložišti - přes veškerou redundanci analytických struktur) - a s takovými objemy musíte umět zacházet - jak z hlediska načítání, tak z hlediska dotazů (jinak můžete vážně degradovat výkon celého úložiště).

Co jiného lze o této vrstvě říci.
Za prvé, pokud se vzdálíme od paradigmatu „procesů načítání end-to-end“, pak už pro nás „karavana jede rychlostí posledního velblouda“ nefunguje, nebo spíše opustíme princip „karavany“ a přepneme na principu „dopravníku“: vzali jsme data ze zdroje – vložili je do vaší vrstvy – připraveni převzít další část. Znamená to, že
1) nečekáme na zpracování na jiných vrstvách;
2) nejsme závislí na harmonogramu poskytování dat jinými systémy.
Jednoduše řečeno, naplánujeme proces načítání, který vezme data z jednoho zdroje prostřednictvím specifické metody připojení k němu, zkontroluje, extrahuje delta – a vloží data do pracovních cílových tabulek. A to je vše.

Za druhé, tyto procesy jsou zjevně uspořádány velmi jednoduše - dalo by se říci triviálně, z hlediska logiky. A to znamená, že je lze velmi dobře optimalizovat a parametrizovat, čímž se snižuje zátěž našeho systému a zrychluje se proces připojování zdrojů (doba vývoje).
Aby k tomu došlo, musíte velmi dobře znát technologické vlastnosti platformy, na které tato komponenta funguje – a pak můžete vyrobit velmi efektivní nástroj.

Vrstva analytických vitrín

Storefront layer ( Data mart layer ) je zodpovědná za přípravu a poskytování dat koncovým uživatelům – lidem nebo systémům. Na této úrovni jsou v maximální možné míře zohledňovány požadavky spotřebitele – jak logické (pojmové), tak fyzické. Služba by měla poskytovat přesně to, co je potřeba – nic více, nic méně.

Pokud je spotřebitelem externí systém, pak zpravidla diktuje datové struktury, které potřebuje, a pravidla pro sběr informací. Dobrý přístup je takový, kdy za správný sběr dat odpovídá spotřebitel. Datový sklad připravil, vytvořil výlohu, poskytl možnost inkrementálního sběru dat (označení metaatributy pro následný výběr delta změn) a spotřebitelský systém pak spravuje a odpovídá za to, jak tuto výlohu využívá. Jsou tu ale zvláštnosti: když systém nemá aktivní komponentu pro sběr dat, je potřeba buď externí komponenta, která bude plnit integrační funkci, nebo bude úložiště fungovat jako „integrační platforma“ a zajistí správné načítání přírůstkových dat dále – mimo úložiště. Objevuje se zde mnoho nuancí a pravidla interakce rozhraní by měly být promyšleny a pochopeny oběma stranami (nicméně jako vždy, pokud jde o integraci). U takových výloh se zpravidla provádí rutinní čištění/archivace dat (zřídkakdy je nutné, aby tato „přepravní data“ byla uchovávána po dlouhou dobu).

Největší význam z hlediska analytických úloh mají výkladní skříně „pro lidi“ – přesněji řečeno pro BI nástroje, se kterými pracují.
Existuje však kategorie „obzvláště pokročilých uživatelů“ – analytici, datoví vědci – kteří nepotřebují ani nástroje BI, ani rutinní procesy pro plnění externích specializovaných systémů. Potřebují jakousi „společnou výlohu“ a „vlastní pískoviště“, kde mohou vytvářet tabulky a transformace podle svého uvážení. V tomto případě je odpovědností úložiště zajistit, aby tyto společné datové tržiště byly naplněny v souladu s předpisy.
Samostatně můžeme vyčlenit takové spotřebitele, jako jsou nástroje Data Mining - hloubková analýza dat. Tyto nástroje mají své vlastní požadavky na přípravu dat a používají je také datoví vědci. Pro úložiště se úkol redukuje - opět na podporu služby pro stahování určitých vitrín dohodnutého formátu.

Vraťme se však k analytickým výkladům. Právě ty jsou v této datové vrstvě zajímavé z pohledu designérů úložišť.
Podle mého názoru je nejlepším časem prověřeným přístupem k navrhování datových tržišť, na který jsou nyní „naostřeny“ téměř všechny platformy BI, přístup Ralpha Kimballa. Je znám pod jménem rozměrové modelování – vícerozměrné modelování. Na toto téma existuje velké množství publikací. Základní pravidla najdete například v publikaci. A samozřejmě můžete doporučit od guru multivariačního modelování. Dalším užitečným zdrojem jsou Kimball's Tips.
Multidimenzionální přístup k vytváření výkladních skříní byl popsán a zpracován tak dobře – jak evangelisty metod, tak předními dodavateli softwaru –, že nemá smysl se zde podrobně zabývat – vždy je upřednostňován původní zdroj.

Rád bych zdůraznil pouze jeden. „Přehledy a analýzy“ jsou jiné. Existuje „těžký reporting“ – předobjednané reporty, které jsou generovány ve formě souborů a doručovány uživatelům prostřednictvím poskytovaných doručovacích kanálů. A nechybí informační panely – BI dashboardy. V podstatě jsou to webové aplikace. A požadavky na dobu odezvy těchto aplikací jsou stejné jako u jakékoli jiné webové aplikace. To znamená, že běžná doba aktualizace pro panel BI jsou sekundy, nikoli minuty. Na to je důležité pamatovat při navrhování řešení. Jak toho dosáhnout? Standardní metoda optimalizace: podíváme se, z čeho se skládá doba odezvy a co můžeme ovlivnit. Čím trávíš nejvíc času? Pro fyzické (diskové) čtení databáze, pro přenos dat po síti. Jak snížit množství přečtených a přenesených dat na požadavek? Odpověď je zřejmá a jednoduchá: musíte buď agregovat data, nebo použít filtr na velké tabulky faktů, které se účastní dotazu, a vyloučit spojení velkých tabulek (odkazy na tabulky faktů by měly procházet pouze dimenzemi).

K čemu je BI? Jak je to pohodlné? Proč je vícerozměrný model účinný?
BI umožňuje uživateli provádět tzv. „ad hoc dotazy“. Co to znamená? To znamená, že neznáme přesně požadavek předem, ale víme, jaké indikátory ve kterých sekcích může uživatel požadovat. Uživatel vygeneruje takový dotaz výběrem příslušných filtrů BI. A úkolem vývojáře BI a návrháře showcase je zajistit takovou logiku provozu aplikace, aby data byla buď filtrována, nebo agregována, a předešlo se tak situaci, kdy je požadováno příliš mnoho dat a aplikace se „zasekne“. Obvykle začínají agregovanými čísly, pak se ponoří do podrobnějších údajů, ale postupně nastavují potřebné filtry.

Ne vždy stačí jednoduše postavit „správnou hvězdu“ – a získat vhodnou strukturu pro BI. Někdy je potřeba někde použít denormalizaci (při pohledu zpět na to, jak to ovlivní zatížení) a někde vytvořit sekundární výklady a agregáty. Někde přidat indexy nebo projekce (v závislosti na DBMS).

Pomocí „pokusu a omylu“ tedy můžete získat strukturu optimální pro BI – která bude zohledňovat vlastnosti DBMS i platformy BI a také požadavky uživatele na prezentaci dat.
Pokud vezmeme data z „jádra“, pak takové zpracování výkladů bude lokálního charakteru, aniž by to mělo vliv na komplexní zpracování primárních dat přijímaných přímo ze zdrojových systémů – data pouze „posuneme“ do formátu vhodného pro BI. A můžeme si to dovolit dělat mnohokrát, různými způsoby, v souladu s různými požadavky. Je mnohem snazší a rychlejší to udělat na základě dat jádra, než sestavit z „primárního“ (jehož struktura a pravidla, jak víme, mohou také „plavat“).

servisní vrstva

Vrstva služeb ( - Service Layer) je zodpovědná za implementaci společných (servisních) funkcí, které lze použít ke zpracování dat v různých vrstvách úložiště - řízení zátěže, řízení kvality dat, diagnostické a monitorovací nástroje atd.
Přítomnost této úrovně poskytuje transparentnost a strukturované toky dat v úložišti.

Tato vrstva obsahuje dvě oblasti úložiště dat:

oblast metadat - používá se pro mechanismus řízení načítání dat;
oblast kvality dat - zavést off-line kontroly kvality dat (tj. ty, které nejsou zabudovány přímo do ETL procesů).

Proces správy zátěže můžete sestavit různými způsoby. Jedním z možných přístupů je tento: rozdělíme celou sadu tabulek úložiště do modulů. Do modulu lze zahrnout pouze tabulky jedné vrstvy. Tabulky obsažené v každém modulu se načítají jako součást samostatného procesu. Nazvěme to kontrolní proces . Spuštění kontrolního procesu má svůj vlastní harmonogram. Řídicí proces organizuje volání atomických procesů, z nichž každý načítá jednu cílovou tabulku, a také obsahuje některé běžné kroky.
Pochopitelně stačí stagingové tabulky jednoduše rozdělit do modulů – podle zdrojových systémů, respektive jejich přípojných bodů. Ale pro jádro je to již obtížnější - protože. tam musíme zajistit integritu dat, což znamená, že musíme vzít v úvahu závislosti. Tito. dojde ke konfliktům, které je třeba řešit. A existují různé způsoby, jak je vyřešit.

Důležitým bodem ve správě zátěže je vývoj jednotného přístupu k řešení chyb. Chyby jsou klasifikovány podle úrovně kritičnosti. Když dojde ke kritické chybě, proces by se měl zastavit, a to co nejdříve, protože. jeho výskyt naznačuje významný problém, který může vést k poškození dat v úložišti. Management zátěže tedy není jen o spouštění procesů, ale také o jejich zastavení a také o zabránění předčasnému spuštění (omylem).

Pro fungování vrstvy služeb je vytvořena speciální struktura metadat. V této oblasti budou uloženy informace o procesech načítání, načtených sadách dat, kontrolních bodech, které se používají k udržování přírůstku (který proces načetl do kterého bodu) a další servisní informace nezbytné pro fungování systému.
Je důležité si uvědomit, že všechny cílové tabulky ve všech vrstvách jsou označeny speciální sadou meta-polí, z nichž jedno je ID procesu, který aktualizoval tento řetězec. U tabulek v úložišti toto označení procesu umožňuje jednotný způsob následného extrahování delta změn. Při načítání dat do primární datové vrstvy je situace složitější - algoritmus pro extrakci delta pro různé načtené objekty může být odlišný. Na druhou stranu, logika zpracování přijatých změn a jejich nabalování na cílové tabulky pro jádro a výklady je mnohem složitější než u stagingu, kde je vše celkem triviální - je snadné parametrizovat a promyslet znovu použitelné typické kroky ( postupy).

Nedávám si zde za úkol plně pokrýt toto téma - organizace načítání - umisťuji pouze akcenty, které stojí za pozornost.
Výše uvedený přístup je pouze jednou z možností. Je docela přizpůsobivý. A jeho „koncepčním prototypem“ byl dopravník Toyota a systém „just-in-time“. Tito. vzdalujeme se rozšířenému paradigmatu výhradně „nočního načítání dat“ a načítáme po malých částech během dne – protože data jsou připravena v různých zdrojích: co přišlo, to se načetlo. Zároveň nám běží mnoho paralelních procesů. A „horký chvost“ čerstvých dat bude neustále „blikat“ – a po chvíli se vyrovná. Tuto vlastnost musíme vzít v úvahu. A v případě potřeby vytvořit vlastní vitríny "plátky", kde je vše již integrální. Tito. je nemožné dosáhnout zároveň účinnosti a konzistence (integrity). Potřebujeme rovnováhu – někde je důležitá jedna věc, někde jinde.

Je nesmírně důležité poskytnout prostředky pro protokolování a monitorování. Dobrou praxí je použití typovaných událostí, kde lze nastavit různé parametry a nastavit systém upozornění – předplatné určitých událostí. Protože je velmi důležité, aby v případě potřeby zásahu správce systému o tom věděl co nejdříve a získal všechny potřebné diagnostické informace. Protokoly lze také použít pro post-factum analýzu problémů, stejně jako pro vyšetřování incidentů selhání systému, vč. datová kvalita.

Navrhujte a udržujte datové modely skladů

Proč je důležité věnovat pozornost návrhu datových modelů při vývoji jakéhokoli systému, kde se jedná o databázi (a zejména ve skladu)? Proč prostě nevhodit sadu tabulek kamkoli – dokonce i do textového editoru? Proč potřebujeme tyto obrázky?
Kupodivu i zkušení vývojáři kladou takové otázky.
Vlastně ano, nic vám nebrání si tabulky načrtnout – a začít je používat. Pokud ... je-li zároveň v hlavě (!) Vývojář má harmonický celkový obraz struktury, kterou vyřezává. Co když existuje více vývojářů? Ale co když tyto tabulky použije někdo jiný? Ale co když čas uplyne - člověk tuto oblast opustí a pak se do ní znovu vrátí?

Dá se na to přijít bez modelu? V podstatě můžete. A přijít na to a „odhadnout obrázky na kus papíru“ a „zamést – urovnat“ data. Mnohem jednodušší, přehlednější a rychlejší je ale použít již hotový artefakt – datový model. A také pochopit „logiku jeho struktury“ – tzn. Bylo by hezké mít společná pravidla hry.

A to nejdůležitější ani není. Nejdůležitější je, že při návrhu modelu jsme nuceni (prostě bez možností!) studovat blíže a hlouběji předmětnou oblast, vlastnosti datové struktury a jejich využití v různých obchodních případech. A ty otázky, které bychom snadno „odsunuli“ jako složité, „rozmazali“ házením našich znamení, aniž bychom se snažili design model - budeme nuceni nastavit a rozhodnout nyní, během analýzy a návrhu, a ne později - až budeme sestavovat zprávy a pokaždé přemýšlet o tom, „jak snížit nekompatibilitu“ a „objevit kolo“.

Tento přístup je jedním z těch inženýrských postupů, které umožňují vytvářet antifragilní systémy. Vzhledem k tomu, že jsou jasně uspořádané, transparentní, snadno se vyvíjejí a jejich „hranice křehkosti“ jsou okamžitě viditelné, lze přesněji posoudit „rozsah katastrofy“, když se objeví nové požadavky, a čas potřebný k přepracování (v případě potřeby). .
Datový model je tedy jedním z hlavních artefaktů, které musí být během vývoje systému zachovány. V dobrém slova smyslu by to měl mít „na stole“ každý analytik, vývojář atd. – všichni, kdo se podílejí na projektech vývoje systému.

Návrh datových modelů je samostatné, velmi rozsáhlé téma. Existují dva hlavní přístupy k návrhu úložiště.
Tento přístup je pro jádro dobrý "vztah entity" - když je normalizovaný (3NF) model sestaven na základě studia předmětné oblasti, přesněji její vybrané oblasti. Zde hraje stejný „korporátní model“, o kterém jsme hovořili výše.

Při navrhování analytických vitrín vhodné vícerozměrný model . Tento přístup se dobře hodí k porozumění firemním uživatelům. jde o model, který je jednoduchý a pohodlný pro lidské vnímání – lidé pracují se srozumitelnými a známými pojmy metrik (ukazatelů) a sekcí, podle kterých jsou analyzovány. A to nám umožňuje jednoduše a jasně postavit proces shromažďování požadavků - kreslíme sadu "matic řezů a indikátorů", komunikujeme se zástupci různých oddělení. A pak to přeneseme do jedné struktury - „analytický model“: vytvoříme „sběrnici měření“ a určíme fakta, která jsou na nich definována. Zároveň pracujeme na hierarchiích a agregačních pravidlech.

Dále je velmi snadné přejít k fyzickému modelu přidáním optimalizačních prvků s ohledem na vlastnosti DBMS. Například pro Oracle by to bylo rozdělení, sada indexů a tak dále. U Vertica budou použity další techniky – třídění, segmentace, dělení.
Může být také vyžadována speciální denormalizace - když do dat záměrně zavádíme redundanci, díky které zlepšíme výkon dotazů, ale zároveň zkomplikujeme aktualizaci dat (protože redundanci bude potřeba zohlednit a podpořit v procesu načítání dat). Abychom zlepšili výkon, možná budeme muset také vytvořit další agregační tabulky nebo použít takové další funkce DBMS, jako jsou projekce ve Vertica.

Při modelování dat skladu tedy ve skutečnosti řešíme několik problémů:

úkolem je vybudovat koncepční (logický) model jádra - systémová a business analýza - studium předmětné oblasti, prohloubení do detailů a zohlednění nuancí "živých dat" a jejich využití v podnikání;
úkol sestavit analytický model - a poté koncepční (logický) model výkladů;
úkolem budování fyzických modelů je řízení redundance dat, optimalizace zohledňující vlastnosti DBMS pro dotazy a načítání dat.

Při vývoji konceptuálních modelů nemusíme brát v úvahu vlastnosti konkrétního DBMS, pro které navrhujeme strukturu databáze. Navíc můžeme použít jeden koncepční model k vytvoření několika fyzických - pro různé DBMS.

Pojďme si to shrnout.

Datový model není soubor „hezkých obrázků“ a proces jeho navrhování není procesem jejich kreslení. Model odráží naše chápání předmětné oblasti. A proces jeho sestavování je procesem jeho studia a zkoumání. Tady se ztrácí čas. A už vůbec ne „kreslit a vybarvovat“.
Datový model je designový artefakt, způsob, jak strukturovaným způsobem sdílet informace mezi členy týmu. K tomu musí být každému srozumitelný (to zajišťuje zápis a vysvětlení) a přístupný (publikovaný).
Datový model nevzniká jednorázově a zmrazený, ale vzniká a vyvíjí se v procesu vývoje systému. Sami jsme si stanovili pravidla pro jeho rozvoj. A můžeme je změnit, pokud uvidíme, jak je udělat lepší, jednodušší a efektivnější.
Datový model (fyzický) umožňuje konsolidovat a využívat soubor osvědčených postupů zaměřených na optimalizaci – tzn. použijte techniky, které již pro tento DBMS fungovaly.

Vlastnosti projektů datových skladů

Zastavme se u vlastností projektů, v rámci kterých společnost buduje a vyvíjí datové sklady. A podívejme se na ně z pohledu vlivu architektonického hlediska. Proč je důležité stavět architekturu pro takové projekty, a to hned od začátku. A právě přítomnost promyšlené architektury dává projektu datového skladu flexibilitu, umožňuje efektivně rozdělit práci mezi účinkující a také usnadňuje předvídat výsledek a činí proces předvídatelnějším.

Data Warehouse je software na zakázku

Datový sklad je vždy „vývoj na zakázku“, nikoli krabicové řešení. Ano, existují oborově specifické BI aplikace, které zahrnují referenční datový model, předkonfigurované ETL procesy z běžných zdrojů (například ERP systémy), sadu typických BI dashboardů a sestav. Ale v praxi je úložiště zřídka implementováno - jako "krabička". S úložištěm pracuji asi 10 let a nikdy jsem takový příběh neviděl. Vždy existují nuance spojené s jedinečnými rysy společnosti - obchodní i IT prostředí. Je proto poněkud lehkomyslné doufat, že „prodejce“ poskytující řešení poskytne architekturu. Architektura takových systémů často dozrává v rámci samotné organizace. Nebo jej tvoří specialisté zhotovitelské firmy, která je hlavním dodavatelem projektu.

Datový sklad je integrační projekt

Datový sklad načítá a zpracovává informace z mnoha zdrojových systémů. A abyste s nimi udrželi „přátelské vztahy“, musíte s nimi být extrémně opatrní. Mimo jiné je nutné minimalizovat zatížení zdrojových systémů, zohlednit okna „dostupnost a nepřístupnost“, vybrat interakční rozhraní s přihlédnutím k jejich architektuře atd. Poté bude úložiště schopno sbírat data co nejdříve a s požadovanou frekvencí. V opačném případě budete „přeřazeni“ do záložního okruhu, který není aktualizován s nejvyšší provozní frekvencí.
Navíc je třeba vzít v úvahu „lidský faktor“. Integrace není pouze interakce strojů. Je to také komunikace mezi lidmi.

Data Warehouse je týmový projekt

Ve velké společnosti může takový systém zřídka dělat pouze jeden tým. Zpravidla zde pracuje více týmů, z nichž každý řeší konkrétní problém.

Architektura by měla poskytovat možnost organizovat jejich paralelní práci při zachování její integrity a zamezení duplikování stejné funkčnosti na různých místech různými lidmi. Kromě zbytečných mzdových nákladů může takováto duplikace později vést k nesrovnalostem v datech.

Navíc, když je do procesu vývoje systému zapojeno tolik lidí a týmů, často rozptýlených, nevyhnutelně vyvstává otázka: jak mezi nimi vybudovat komunikaci a informační interakci. Čím standardnější a srozumitelnější přístupy a postupy se používají, tím jednodušší, pohodlnější a efektivnější je nastavení takové práce. A včetně stojí za to zamyslet se nad skladbou „pracovních artefaktů“, mezi nimiž pro datové sklady č. 1 jsou datové modely (viz předchozí část).

Datový sklad má oproti jiným systémům delší životnost

Dovolte mi upřesnit – toto tvrzení platí pro „živé“, fungující úložiště, integrované s klíčovými zdroji, vlastnící historická data a poskytující informační a analytické služby mnoha divizím společnosti.

Jaké mám důvody k tomu věřit?
Za prvé, vybudování úložiště je proces velmi náročný na zdroje: kromě skutečných nákladů na vybavení, licence na potřebný technologický software a vývoj se na tom podílejí také téměř všechny systémy a divize společnosti. Zopakovat celý tento proces znovu od nuly je velmi odvážný podnik.

Zadruhé, pokud má úložiště správnou architekturu, pak snadno přežije jak změnu zdrojových systémů, vznik nových požadavků ze strany koncových uživatelů, tak růst objemů dat.
Pokud je architektura správná, informační toky transparentní, lze takový systém vyvíjet dostatečně dlouhou dobu, aniž by hrozilo, že se při provádění změn ocitne v situaci strnulosti kvůli potížím při posuzování dopadu.

Postupný iterativní vývoj

Poslední věc, kterou by si zákazník přál, aby se zapojil do příběhu s úložištěm, je zmrazit své požadavky na rok nebo dva, dokud nebude navržen úplný firemní datový model, všechny zdroje budou plně propojeny atd.

Datový sklad v očích zákazníků často vypadá jako absolutní monstrum - úkoly, cíle a horizont vývoje systému jsou tak objemné. A často se zákazník bojí, že „na úkor svého rozpočtu“ IT oddělení vyřeší nějaké „vlastní úkoly“. A opět jsme postaveni před otázku interakce mezi lidmi a schopnosti v klidu vyjádřit svůj postoj a vyjednávat.

Kompetentní architektonické přístupy vám umožňují vyvíjet systém iterativně, postupně zvyšovat funkčnost, aniž byste museli několik let „vývoj“ přinášet výsledky.

I když nutno podotknout, že „zázraky se nedějí“ – a „start“ také zabere čas. U úložišť to může být dost velké - jelikož se jedná o velké objemy dat, jde o historická data - pro stará období, kdy se pravidla pro zpracování informací mohla lišit od těch současných. Proto je zapotřebí dostatek času na analytický vývoj, interakci se zdrojovými systémy a sérii „pokusů a omylů“, včetně zátěžových testů na reálných datech.

Datové sklady – „příběh více projektů“

Je obtížné vyčlenit jednoho podnikového zákazníka pro datový sklad. A věří se (ne bezdůvodně), že klíčovým faktorem úspěchu projektu úložiště je podpora vedení společnosti – přímo první osoby.
Úložiště se jen zřídka buduje a vyvíjí v rámci jednoho projektu. Zpravidla existují různé potřeby konsolidace a analýzy dat, za nimiž stojí různí zákazníci a skupiny uživatelů. Proto je úložiště často vyvíjeno v rámci několika paralelních projektů.

Rovnováha inovací a osvědčených řešení

Nehledě na to, že téma storage je velmi „starobylé“ (pokud se takové slovo hodí na tak mladé odvětví jako je IT) a dosti konzervativní. Pokrok však nestojí - a omezení, která dříve existovala kvůli drahým a pomalým diskům, drahé paměti atd. - jsou nyní odstraněny. A zároveň je čas přehodnotit některé architektonické přístupy. Navíc to platí jak pro technologické platformy, tak pro architekturu aplikovaných systémů, které jsou na nich založeny.

Zde je důležité najít rovnováhu – a zachovat poměrně „zelený“ přístup ke zdrojům i uloženým informacím. V opačném případě můžete velmi rychle proměnit úložiště v polostrukturované „smetiště“, které, pokud se to podaří roztřídit, bude vyžadovat poměrně velké úsilí.
Ano, máme více příležitostí, ale to neznamená, že musíme popírat všechny časem vyvinuté a prověřené praktiky, u kterých je jasné, jak a proč je používat, a „dopřát si vše vážné“ jen v čele s mlžnými duch „inovací“.
Udržet rovnováhu znamená používat nové metody a přístupy tam, kde otevírají nové příležitosti, ale zároveň používat ty staré osvědčené k řešení naléhavých problémů, které nikdo nezrušil.
Co můžeme dělat jako vývojáři a designéři aplikovaných řešení? Především znát a rozumět technologickým změnám platforem, na kterých pracujeme, jejich možnostem, vlastnostem a limitům aplikace.

Podívejme se na DBMS – jako nejdůležitější a nejdůležitější technologickou platformu pro úložiště.
V poslední době je zřetelný posun relačních databází, původně vytvořených jako „univerzální“, směrem ke specializaci. Přední dodavatelé již dlouhou dobu uvolňují různé možnosti - pro aplikace různých tříd (OLTP, DSS & DWH). Kromě toho existují další možnosti pro práci s textem, geodaty atd.

Věc se ale neomezovala jen na toto – začaly se objevovat produkty, které byly zpočátku zaměřeny na určitou třídu úkolů – tzn. specializované DBMS. Mohou nebo nemusí používat relační model. Důležité je, že jsou zpočátku „naostřeny“ nejen pro ukládání a zpracování „obchodních informací“ obecně, ale pro určité úkoly.

Centralizace a specializace jsou zřejmě dva vzájemně se doplňující trendy, které se pravidelně nahrazují a zajišťují rozvoj a rovnováhu. Stejně jako evoluční (postupný) postupný vývoj a zásadní změny. Michael Stonebreaker byl tedy v 90. letech jedním z autorů Manifestu databáze Generace III, který jasně zněl myšlenkou, že svět nepotřebuje další revoluci ve světě databází. O 10 let později však vydává díla, ve kterých oznamuje předpoklady pro začátek nové éry ve světě DBMS – právě na základě jejich specializace.
Zaměřuje se na skutečnost, že rozšířené univerzální DBMS jsou postaveny na „onesize-fits-all“ architektuře, která nezohledňuje změny hardwarových platforem ani rozdělení aplikací do tříd, pro které můžete přijít s lepším řešením než implementovat univerzální požadavky.
A v souladu s touto myšlenkou začíná vyvíjet řadu projektů. Jedním z nich je C-Store, sloupcový DBMS navržený v architektuře sdíleného nic (SN), původně vytvořený speciálně pro systémy třídy ukládání dat. Tento produkt byl dále uváděn na trh jako HP Vertica.

Zdá se, že nyní téma rozvoje datových skladů sklouzlo do nového kola vývoje. Objevují se nové technologie, přístupy a nástroje. Jejich studium, testování a rozumné uplatnění nám umožňuje vytvářet opravdu zajímavá a užitečná řešení. A přiveďte je k implementaci a vychutnejte si skutečnost, že váš vývoj se používá ve skutečné práci a přináší výhody.

Epilog

Při přípravě tohoto článku jsem se snažil zaměřit především na architekty, analytiky a vývojáře, kteří přímo pracují s datovými sklady. Ukázalo se však, že jsem nevyhnutelně „vzal téma trochu širší“ - a do zorného pole se dostaly další kategorie čtenářů. Některé body se budou zdát kontroverzní, některé nejsou jasné, některé jsou zřejmé. Lidé jsou různí – s různými zkušenostmi, zázemím a postavením.
Typické otázky manažerů jsou například „kdy přilákat architekty?“, „Kdy mám dělat architekturu?“, „Architektura – nebude to příliš drahé?“ zní to pro nás (vývojáře, designéry) poněkud zvláštně, protože pro nás se architektura systému objevuje s jeho zrodem - je jedno, jestli si to uvědomujeme nebo ne. A i když v projektu není žádná formální role architekta, normální developer vždy „zapne svého interního architekta“.

Ve velkém schématu věcí nezáleží na tom, kdo je architekt, důležité je, že si tyto otázky někdo klade a hledá na ně odpovědi. Pokud je architekt jasně vyčleněn, znamená to pouze to, že je primárně zodpovědný za systém a jeho vývoj.
Proč se mi téma „antifragility“ zdálo relevantní ve vztahu k tomuto tématu?

„Jedinečnost antifragility je v tom, že nám umožňuje pracovat s neznámým, dělat něco v podmínkách, kdy nerozumíme tomu, co přesně děláme – a uspět“/Nassim N.Taleb/

Krize a vysoká míra nejistoty proto nejsou omluvou pro nedostatek architektury, ale faktory, které její potřebu posilují.