Zaitsev S.L., kandidát fyzikálních a matematických věd

Opakující se skupiny

Duplicitní skupiny jsou atributy, pro které může mít jedna instance entity více než jednu hodnotu. Například člověk může mít 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á osoba může mít pouze dvě dovednosti, můžeme vytvořit entitu zobrazenou na obr. 1.6. Tady je entita OSOBAse dvěma atributy pro ukládání dovedností a úrovně dovedností pro každého.

Obr. 1.6. Tento příklad používá opakující se skupiny.

Problém opakujících se skupin spočívá v tom, že nemůžeme přesně vědět, kolik dovedností může mít člověk. 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 redukovaný na první normální formu. Všimněte si přidaných ID dovednosti které každý jedinečně identifikuje DOVEDNOST.

Obr. 1.7. Model snížen na první normální formu.

Jeden fakt na jednom místě

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

Redundance vyžaduje další prostor, ale i když je důležitá efektivita paměti, skutečný problém je jiný. Zajištění synchronizace nadbytečných dat je režie a vždy riskujete konfliktní hodnoty.

V předchozím příkladu DOVEDNOSTzáleží na ID osobya od ID dovednosti.To znamená, že nebudete mít DOVEDNOSTdokud se neobjeví OSOBA,vlastnit tuto dovednost. To také ztěžuje změnu názvu dovednosti. Je nutné najít každou položku s názvem dovednosti a změnit ji pro každou osobu, která má tuto dovednost.

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

Obr. 1.8. Ve druhé normální formě je opakující se skupina přesunuta do jiné entity. To poskytuje flexibilitu pro přidání požadovaného počtu dovedností a změnu názvu dovednosti nebo popisu 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 dané entity. V předchozím příkladu Školní jménoa Zeměpisná oblastv tabulce OSOBAale nepopisujte 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ě.

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

Vztahy mnoho k mnoha

Vztahy mnoho k mnohaodrážejí realitu okolního světa. Všimněte si, že na obrázku 1.9 je mezi mnoha vztah OSOBNÍa ŠKOLA... Postoj přesně odráží skutečnost, že OSOBAmůže studovat v mnoha ŠKOLYa v ŠKOLAse může hodně naučit OSOBA.K dosažení čtvrté normální formy je vytvořena asociativní entita, která eliminuje vztah monogy k mnoha generováním samostatného záznamu pro každou jedinečnou kombinaci školy a osoby. Obrázek 1.10 ukazuje model ve čtvrté normální formě.

Obr. 1.10. Ve čtvrté normální formě je vztah monogo-to-many OSOBNÍ a ŠKOLAvyřešen zavedením asociativní entity, ve které je pro každou jedinečnou kombinaci alokována samostatná položka ŠKOLY a OSOBY.

Formální definice normálních forem

Následující definice normálních forem se mohou zdát sklič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. Ačkoli tato kniha není věnována podrobné diskusi o normálních formách, modelářům se doporučuje, aby se na toto téma podívali hlouběji.

V daném vztahu R závisí atribut Y funkčně na atributu X. V symbolické formě RX -\u003e RY (čte se jako „RX funkčně definuje RY“) - právě tehdy, když je každá hodnota X v R spojena s přesně jednou hodnotou Y v R (kdykoli). Atributy X a Y mohou být složené (Date CJ. Introduction to Database Systems. 6. vydání. Ed. Williams: 1999, 848 s.).

Relace R odpovídá první normální formě (1NF) právě tehdy, pokud všechny její domény obsahují pouze atomové hodnoty (Date, tamtéž).

Relace R odpovídá druhé normální formě (2NF) právě tehdy, pokud odpovídá 1NF a každý neklíčový atribut je zcela závislý na primárním klíči (Date, tamtéž).

Relace R odpovídá třetí normální formě (3NF) právě tehdy, pokud odpovídá 2NF a každý neklíčový atribut nezávisí tranzitivně na primárním klíči (Date, tamtéž).

Vztah R odpovídá Boyes-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 uvedeno stručné vysvětlení některých zkratek použitých v definicích Date.

MVD (multi-valued dependency) is a multi-valued dependency. 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 (funkční závislost) - 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) is a join dependency. V závislosti na sjednocení je primární klíč nadřazené entity vysledován zpět alespoň k potomkům třetí úrovně, při zachování schopnosti být použit v sjednocení původním klíčem.

Poměr odpovídá čtvrté normální formě (4NF) tehdy a jen tehdy, když je v R MVD, například A®®B. Navíc všechny atributy R funkčně závisí na A. Jinými slovy, R obsahuje 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). Proto R splňuje požadavky 4NF, pokud splňuje BCNF a všechny MVD jsou ve skutečnosti FD (Date, tamtéž).

Pro pátou normální formu splňuje vztah R unijní závislost (JD) * (X, Y, ..., Z) právě tehdy, když R je ekvivalentní jeho projekcím na X, Y, ..., Z, kde X, Y,. .., Z je podmnožina množiny atributů R.

Existuje mnoho dalších běžných forem pro složité datové typy a konkrétní situace, které přesahují rámec této diskuse. Každý nadšenec modelu by se rád naučil i jiné normální formy.

Normální obchodní formy

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

První normální obchodní forma (1BNF) převezme duplicitní skupiny do jiné entity. Tato entita získává svůj vlastní název a primární (složené) klíčové atributy z původní entity a její opakující se skupiny.

Druhá normální obchodní forma (2BNF) přebírá atributy, které jsou částečně závislé na primárním klíči jiné entitě. Primární (složený) klíč této entity je primární klíč entity, ve které byl původně umístěn, spolu s dalšími klíči, na kterých atribut zcela závisí.

Třetí obchodní normální forma (3BNF) přebírá 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.

Čtvrtá normální obchodní forma (4BNF) přebírá 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í (nutně) být v dané entitě přítomny.

Pátý normální obchodní formulář (5BNF) se jeví 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

Vyplněný logický model musí splňovat požadavky třetí normální obchodní formy a musí zahrnovat všechny entity, atributy a vztahy potřebné k podpoře požadavků na data a obchodních pravidel souvisejících s daty.

Všechny entity musí mít názvy, které popisují jejich obsah, a musí mít jasný, výstižný, úplný popis nebo definici. Budoucí příspěvek bude pokrývat počáteční sadu pokynů pro správné vytváření názvů a popisů entit.

Entity musí mít úplnou sadu atributů, aby každá skutečnost o každé entitě mohla být reprezentována jejími atributy. Každý atribut musí mít název, který odráží jeho význam, logický datový typ a jasný, krátký, úplný popis nebo definici. V budoucím příspěvku na blogu se podíváme na počáteční sadu pokynů pro správné formátování názvů a popisů atributů.

Vztahy by měly zahrnovat slovesnou konstrukci, která popisuje vztah mezi entitami, spolu s charakteristikami, jako je pluralita, nutnost existence nebo možnost absence vztahu.

POZNÁMKA Množství relace popisuje maximální počet instancí sekundární entity, které lze přidružit k instanci původní entity.Nutnost existence nebomožnost absence vztah se používá k určení minimálního počtu instancí sekundární entity, které lze přidružit k instanci původní entity.

Fyzický datový model

Jakmile vytvoříte úplný a adekvátní logický model, jste připraveni se rozhodnout pro výběr implementační platformy. Volba platformy závisí na požadavcích na využití dat a strategických principech utváření architektury společnosti. Výběr platformy je složitý problém mimo rozsah této knihy.

V ERwin je fyzický model grafickým znázorněním databáze v reálném světě. Fyzická databáze bude sestávat z tabulek, sloupců a vztahů. Fyzický model závisí na platformě zvolené pro implementaci a požadavcích na používání dat. Fyzický model pro IMS se bude velmi lišit od modelu pro Sybase. Fyzický model pro zprávy OLAP bude vypadat jinak než model pro OLTP (online zpracování transakcí).

Modelář dat a správce databáze (DBA) používají k vývoji fyzického datového modelu logický model, požadavky na použití a zásady podnikové architektury. Fyzický model můžete denormalizovat, abyste zlepšili výkon, a vytvářet pohledy na podporu požadavků na použití. Následující části podrobně popisují proces denormalizace a vytváření pohledů.

Tato část poskytuje přehled procesu vytváření fyzického modelu, shromažďování požadavků na využití dat, definování komponent fyzického modelu a poskytování zpětného inženýrství. Následující publikace se těmito otázkami zabývají podrobněji.

Shromažďování požadavků na využití dat

Požadavky na využití dat obvykle shromažďujete na začátku rozhovorů a pracovních sezení. V takovém případě by požadavky měly co nejvíce definovat použití údajů uživatelem. Povrchní přístup a mezery ve fyzickém modelu mohou vést k neplánovaným nákladům a zpoždění při realizaci projektu. Požadavky na použití zahrnují:

Přístupové a výkonnostní požadavky

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

Odhad počtu uživatelů, kteří potřebují souběžný přístup k datům, aby vám pomohli navrhnout databázi pro přijatelné úrovně výkonu

Agregáty, otočné čepy a další vypočítaná nebo odvozená data, která lze považovat za kandidáty na ukládání v trvalých datových strukturách

Požadavky na hlášení a standardní dotazy, které administrátorovi databáze pomohou sestavit indexy

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

Kromě předsedy, sekretářky a uživatelů se relace požadavků na použití musí účastnit modelář, správce databáze a architekt databáze. Měly by se prodiskutovat požadavky uživatele na historické údaje. Doba, po kterou jsou data uchována, má významný dopad na velikost databáze. Starší data se často ukládají v zobecněné podobě a atomická data se archivují nebo odstraňují.

Uživatelé by si měli na relaci přivést příklady požadavků a zpráv. Hlášení musí být přesně definována a musí obsahovat atomové hodnoty použité pro všechna pole souhrnu a souhrnu.

Komponenty fyzického datového modelu

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

Reverzní inženýrství

Pokud logický model není k dispozici, je nutné znovu vytvořit model z existující databáze. ERwin tento proces nazývá reverzní inženýrství. Zpětné 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í. Můžete importovat jazyk definic dat (DDL) do nástroje, který podporuje reverzní inženýrství (například Erwin). Pokročilé nástroje, jako je ERwin, zahrnují funkce, které poskytují komunikaci ODBC s existující databází a vytvářejí model přímým čtením datových struktur. Reverzní inženýrství s ERwin bude podrobně probráno v budoucím příspěvku.

Používání podnikových funkčních hranic

Při vytváření logického modelu pro modeláře je důležité zajistit, aby nový model byl v souladu s podnikovým modelem. Používání podnikových funkčních hranic znamená modelování dat z hlediska pojmů používaných ve společnosti. Způsob, jakým se data používají ve společnosti, se mění rychleji než samotná data. V každém logickém modelu musí být data prezentována holistickým způsobem bez ohledu na obchodní doménu, kterou podporuje. Entity, atributy a vztahy musí definovat obchodní pravidla na podnikové úrovni.

POZNÁMKA Někteří moji kolegové označují tyto firemní funkční hranice jako modelování v reálném světě. Modelování v reálném světě vybízí modeláře, aby zobrazoval informace, pokud jde o jejich skutečně inherentní vztahy a vztahy.

Použití podnikových funkčních hranic pro datový model, který je konstruován vhodným způsobem, poskytuje základ pro podporu informačních potřeb jakéhokoli počtu procesů a aplikací, což společnosti umožňuje efektivněji využívat jednu ze svých nejcennějších aktiv, informací.

Co je Enterprise Data Model?

Podnikový datový model (EDM)obsahuje entity, atributy a vztahy, které představují informační potřeby společnosti. EDM je obvykle kategorizováno podle oborových oblastí, které představují skupiny subjektů souvisejících s podporou konkrétních obchodních potřeb. Některé tematické oblasti mohou zahrnovat specifické obchodní funkce, jako je správa smluv, zatímco jiné mohou zahrnovat entity, 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 nesplňuje tento požadavek, musí být k němu přidán doménový model. Toto srovnání zajišťuje, že se korporační model zdokonalí nebo upraví a že všechny logické snahy o modelování budou v rámci korporace koordinovány.

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

Budování podnikového datového modelu růstem

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

Budování znamená stavět něco postupně, vrstvu po vrstvě, stejně jako ústřice roste perlou. Každý vytvořený datový model poskytuje příspěvek k 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. Díky tomu je možné vybudovat podnikový datový model rozšířením a opakovaným přidáváním úrovní podrobností a vylepšení.

Koncept metodiky modelování

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

IDEF1X (Integration Definition for Information Modeling - an integrated description of information models).

IE (Informační inženýrství).

IDEF1X je dobrá metodika a použití jeho notace je velmi rozšířené

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 používá vysoce strukturovanou sadu typů modelování konstruktů a vede k datovému modelu, který vyžaduje pochopení fyzické povahy dat, než mohou být tyto informace zpřístupněny.

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

Informační inženýrství

Clive Finklestein je často označován jako otec informačního inženýrství, ačkoli podobné koncepty s ním sdílel James Martin (Martin, James. Správa prostředí databáze. Upper Saddle River, New Jersey: Prentice Hall, 1983.). Informační inženýrství využívá ke správě informací obchodní přístup a pro vyjádření obchodních pravidel používá jinou notaci. IE slouží jako rozšíření a vývoj notace a základních konceptů metodiky ER navržené Peterem Chenem.

IE poskytuje infrastrukturu pro podporu informačních požadavků integrací podnikového strategického plánování s informačními systémy, které jsou vyvíjeny. Tato integrace umožňuje užší sladění správy informačních zdrojů s dlouhodobými strategickými vyhlídkami společnosti. Tento přístup založený na podnikání vedl mnoho modelářů k tomu, aby si vybrali IE před jinými metodikami, které se obvykle zaměřují na výzvy krátkodobého rozvoje.

IE navrhuje sled akcí, které vedou společnost k identifikaci všech jejích informačních potřeb pro sběr a správu dat a identifikaci vztahů mezi informačními objekty. Výsledkem je, že požadavky na informace jsou jasně formulovány na základě směrnic o řízení a mohou být přímo převedeny do informačního systému pro správu, který bude podporovat strategické informační potřeby.

Závěr

Porozumění tomu, jak používat nástroj pro modelování dat, jako je ERwin, je jen částí problému. Kromě toho musíte pochopit, kdy se řeší úlohy modelování dat a jak se shromažďují požadavky na informace a obchodní pravidla, která by měla být v datovém modelu zastoupena. Vedení pracovních relací poskytuje nejpříznivější prostředí pro shromažďování požadavků na informace v prostředí, které zahrnuje odborníky na doménu, uživatele a profesionály v oblasti informačních technologií.

Budování dobrého datového modelu vyžaduje analýzu a zkoumání požadavků na informace a obchodních pravidel shromážděných během pracovních sezení a pohovorů. Výsledný datový model by měl být porovnán s podnikovým modelem, pokud je to možné, aby bylo zajištěno, že nebude v rozporu s existujícími modely objektů a zahrnuje všechny požadované objekty.

Datový model se skládá z logických a fyzických modelů, které představují požadavky na informace a obchodní pravidla. Logický model by měl být redukován na třetí normální formu. Třetí normální forma omezuje, přidává, aktualizuje a odstraňuje anomálie datové struktury, aby podporovala zásadu „jeden fakt na jednom místě“. Shromážděné požadavky na informace a obchodní pravidla by měly být analyzovány a prozkoumány. Musí být porovnány s podnikovým modelem, aby se zajistilo, že nebudou v rozporu s existujícími modely objektů a zahrnou všechny požadované objekty.

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

Jedna z následujících publikací se bude zabývat otázkami identifikace entit, definováním typů entit, výběrem názvů entit a popisy, jakož i některými technikami, jak se vyhnout nejčastějším chybám modelování spojeným s použitím entit.

Entity musí mít úplnou sadu atributů, aby každá skutečnost o každé entitě mohla být reprezentována jejími atributy. Každý atribut musí mít název, který odráží jeho význam, logický datový typ a jasný, krátký, úplný popis nebo definici. V budoucím příspěvku na blogu se podíváme na počáteční sadu pokynů pro správné formátování názvů a popisů atributů. Vztahy by měly zahrnovat slovesnou konstrukci, která popisuje vztah mezi entitami, spolu s charakteristikami, jako je pluralita, nutnost existence nebo možnost absence vztahu.

POZNÁMKA Množství relace popisuje maximální počet instancí sekundární entity, které lze přidružit k instanci původní entity.Nutnost existence nebo možnost absence vztah slouží k určení minimálního počtu instancí sekundární entity, které lze přidružit k instanci originálu

Zdá se, že nyní téma vývoje datového skladu vklouzlo do nové fáze vývoje. Objevují se nové technologie, přístupy a nástroje. Jejich studium, testování a inteligentní aplikace nám umožňují vytvářet opravdu zajímavá a užitečná řešení. A přiveďte je k implementaci a užívejte si skutečnosti, že váš vývoj je používán ve skutečné práci a je užitečný.

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 nevyhnutelně „vzala téma trochu širší“ - a další kategorie čtenářů spadaly do zorného pole. Některé body se budou zdát kontroverzní, některé nejsou jasné, jiné jsou zřejmé. Lidé jsou různí - s různým pozadím, pozadím a pozicemi.
Například typické manažerské otázky jsou „kdy najmout architekty?“, „Kdy dělat architekturu?“, „Architektura - nebylo by to příliš drahé?“ zvuk pro nás (vývojáře, designéry) poněkud zvláštní, protože pro nás se architektura systému objevuje s jeho zrozením - nezáleží na tom, zda si to uvědomujeme nebo ne. A i když v projektu neexistuje formální role architekta, normální vývojář vždy „zahrnuje svého vlastního interního architekta“.

Celkově nezáleží na tom, kdo přesně vykonává roli architekta - je důležité, aby někdo kládl podobné otázky a zkoumal odpovědi. Pokud je architekt jasně vyčleněn, znamená to jen to, že je primárně zodpovědný za systém a jeho vývoj.
Proč považuji téma „antifragility“ za relevantní pro toto téma?

„Jedinečnost antifragility spočívá 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 děláme, a dosáhnout úspěchu.“ / Nassim N.Taleb /

Krize a vysoká míra nejistoty proto nejsou omluvou pro absenci architektury, ale faktory, které zvyšují její potřebu.

Štítky: Přidat štítky

5.1. Organizace dat v podnikových informačních systémech.

Pokud vezmeme v úvahu CIS na nejjednodušší úrovni, lze říci, že obsahuje podnikovou počítačovou (výpočetní) síť a specializovaný aplikační balíček (PPP) pro řešení problémů v dané oblasti. Na druhé straně PPP i počítačová síť předpokládají použití informačních údajů o stavu a vývoji jimi řízených a řízených systémů. Historicky se CIS skládá ze samostatných rozvětvených subsystémů jednotlivých podniků, vzájemně propojených a často představujících hierarchický systém. Je přirozené předpokládat, že tyto subsystémy mají jak své vlastní zdroje, tak svá vlastní úložiště pro související data. Spojením do jediného systému vyvstávají otázky týkající se společného správného používání dat geograficky umístěných na různých místech jejich úložiště. V důsledku toho potřebuje pro úspěšné řízení produkční asociace vybavené EIS spolehlivý systém pro sběr, ukládání a zpracování dat. Jinými slovy potřebujete jednotnou informační infrastrukturu, která splňuje strategické projekty BI (Business Intelligence) nebo integrovanou databázi pro ukládání a používání dat. Hlavním cílem datové integrace je získat jednotný a úplný obraz o stavu podnikových obchodních dat. Samotná integrace je složitý proces, na jehož základě je vhodné vyčlenit:

Technologie,

Produkty,

Aplikace.

MetodyJsou přístupy k integraci dat.

Technologie Jsou procesy, které implementují určité metody integrace dat.

produkty Jsou komerční řešení, která podporují jednu nebo druhou technologii integrace dat.

Aplikace - jedná se o hotová technická řešení dodávaná vývojáři podle přání zákazníků - zákazníků.

V závislosti na složitosti podnikových informačních systémů a úlohách, které mají řešit, je organizace dat v nich poněkud odlišná. Zejména v CIS, jehož cílem je zajistit efektivní řízení obchodních procesů jednotlivých poboček i korporace jako celku, se obvykle hovoří o přítomnosti podnikových databází. V podnikových informačních systémech používaných na nejvyšších úrovních řízení a většinou spojených s procesy operační analýzy a rozhodování, v procesu plánování, návrhu a předpovědi odlišné typy činnosti správy používají terminologii datového skladu. Je třeba poznamenat, že fráze integrované úložištěje vlastní oběma.

5.2. Firemní databáze a požadavky na ně

Jako celosystémové integrované úložiště dat je podniková databáze navržena tak, aby poskytovala informace pro efektivní správu všech obchodních procesů a divizí společnosti. Integrace dat umožňuje vytvoření nové struktury, která organicky zahrnuje data z databází jednotlivých samostatných divizí, proto by taková struktura měla poskytovat určité požadavky:

Jednoduché a uživatelsky přívětivé zadávání dat do databáze,

Ukládání dat způsobem, který nepovede k nadměrnému růstu dat,

Přístup k obecným informacím zaměstnanců všech divizí společnosti s povinnou podmínkou rozlišení přístupových práv,

Rychlé vyhledání a získání požadovaných informací,

Třídění a filtrování požadovaných dat,

Seskupení dat se stejným názvem,

Průběžné a závěrečné výpočty nad poli,

Převod a jasnost výstupních dat,

Škálovatelnost,

· Ochrana proti náhodným selháním, nenávratné ztrátě dat a neoprávněnému přístupu.

Kromě toho je při integraci izolovaných (distribuovaných) databází do jedné podnikové databáze důležité zajistit schopnost pracovat s databází tak, aby s ní uživatel pracoval, jako kdyby nebyla distribuována.

Vytvoření integrované podnikové databáze je možné různými způsoby, z nichž hlavní jsou:

Konsolidace,

Federalizace,

· Šíření.

5.3. Charakteristika řešení podnikové integrace databáze

Konsolidace.Pod konsolidace obvykle znamená přidání dat se stejným názvem. Podobný termín je široce používán v bankovním sektoru, kde se vytváří roční konsolidovaná rozvaha, která umožňuje prezentovat všechna aktiva a pasiva mateřské banky společně s jejími pobočkami.

Pokud jde o společnost, při použití této metody se data kopírují a shromažďují z primárních databází (DB - Slave) integrací do jednoho úložiště (DB - Master). Jako takové úložiště je zpravidla vybrán server ústřední (hlavní) kanceláře (obrázek 5.1).

Obrázek 5.1. Metoda konsolidace dat

Data v databázi - Master se používá pro vykazování, analýzu, vývoj a rozhodování, stejně jako zdroj dat pro ostatní pobočky společnosti.

Nejběžnějšími technologiemi pro podporu těchto rozhodnutí během konsolidace jsou následující technologie:

· Extrahovat, transformovat a načíst - ETL (Extract Transform Load);

· Správa obsahu společnosti - ECM (Enterprise Content Management).

Výhody metody konsolidace jsou:

1. Schopnost provádět transformaci (restrukturalizace, sladění, čištění a / nebo agregace) významného množství dat v procesu jejich přenosu z primárních systémů do konečných úložišť pomocí technologie ETL,

2. Schopnost spravovat nestrukturovaná datadokumenty, zprávy a stránky díky technologickým řešením ECM.

Pro práci s konsolidovanou databází CIS, speciální obchodní aplikace,které vám umožňují vytvářet dotazy k databázovým datům, zprávám a na jejich základě provádět analýzu dat.

Nevýhodou integrace prostřednictvím konsolidace je neschopnost aktualizovat konsolidovaná data v umístění integrovaného úložiště synchronizovaně s aktualizacemi dat v primárních systémech kvůli konfliktům synchronizace, které vznikají.

Mezi aktualizací dat v primárních systémech a konečným umístěním úložiště je časový odstup.

Toto zpoždění se může pohybovat od několika sekund do několika hodin nebo dokonce dnů.

Federalizace.Pod federalizaceobvykle znamená spojení. Podobný termín se často používá v politice při uspořádání státních hranic (například Německo, Rusko, USA).

Proces federalizace dat v podnikové databázi je vytvoření virtuálního (zdánlivého) obrázku, který kombinuje několik primárních datových souborů do jednoho virtuálního celku (viz obrázek 5.2). Samotná federace dat je o získávání dat z primárních systémů na základě externích požadavků. Práce podnikové databáze integrované podle federální metody je řízena federalizační procesor.

Obr. Metoda federalizace dat

Při vyžádání dat ve virtuální databázi vygeneruje jakákoli obchodní aplikace požadavek na virtuální obrázek. Federační procesor na základě tohoto požadavku extrahuje data z příslušných primárních systémů, integruje je v souladu s virtuálním obrázkem a doručí výsledek obchodní aplikaci, která požadavek vygenerovala. V tomto případě se provedou všechny potřebné transformace dat, když jsou extrahovány z primárních systémů.

Podporu federovaného přístupu k integraci dat poskytuje technologie Enterprise Information Integration (E I I), což v překladu znamená - integrace podnikových informací.

Funkce federovaného řešení je, že federalizační procesor používá metadata(znalosti), které zahrnují údaje o složení a charakteristikách virtuálního obrazu, o množství dat, sémantických vztazích mezi nimi a přístupových cestách k nim, což pomáhá federovanému řešení optimalizovat přístup k primárním systémům.

Hlavní výhody federovaného přístupu jsou:

Možnost přístupu k aktuálním datům bez vytvoření další nové databáze,

Účelnost aplikace po akvizici nebo fúzi společností,

Nenahraditelný v případech, kdy z bezpečnostních důvodů existují licenční omezení kopírování dat z primárních systémů,

V případě potřeby s využitím vysoké autonomie místních divizí korporace a flexibility centralizované kontroly nad jejich činností,

· Vysoký stupeň užitečnosti pro velké nadnárodní korporace.

Nevýhody tohoto přístupu zahrnují:

Snížený výkon kvůli dodatečným nákladům na přístup k více zdrojům dat,

Federalizace je nejvhodnější pro získávání malého množství dat,

· Vysoké požadavky na kvalitu primárních údajů.

Šíření.Pod šířeníobvykle se týká územního přenosu rozmnožených objektů. Šíření dat označuje šíření primárních databází a jejich přesun z jednoho místa do druhého. Při implementaci této metody obchodní aplikace provozovat online a přesouvat data do cílů na základě konkrétních událostí. U tohoto technického řešení je důležité aktualizovat data, která jsou možná v synchronních nebo asynchronních režimech. Synchronní režim předpokládá, že k aktualizacím v primárním i cílovém systému dojde během stejné fyzické transakce.

Příklady technologií, které podporují implementaci metody šíření dat, jsou:

Integrace podnikových aplikací EAI - Enterprise Application Integration,

· Replikace podnikových dat EDR - Enterprise Data Replication.

Zobecněná struktura implementace metody šíření dat je znázorněna na obrázku 5.3.

Obrázek 5.3. Metoda šíření údajů

Charakteristickým rysem metody distribuce dat je zaručené dodání dat do cílového systému s minimálním zpožděním blízkým reálnému času.

Kombinace technologií integrace (EAI) a replikace (EDR) poskytuje řadu výhod v podobě následujících výhod:

· Vysoký výkon,

· Schopnost restrukturalizovat a vyčistit data,

· Vyrovnání zátěže vytvořením záloh a obnovou dat.

Hybridní přístup.Realita ekonomické činnosti je taková, že neexistují dva stejné podniky, natož dvě stejné korporace. Tato okolnost zanechává stopy v procesu vytváření a plnění podnikového informačního systému. To platí úplně i pro metody integrace dat v databázích. Z tohoto důvodu mnoho systémů CIS používá ve svých aplikacích pro integraci dat takzvanou integraci dat. hybridnípřístup, který zahrnuje více metod integrace současně, příkladem jsou technologie, které poskytují konzistentní obraz informací o zákaznících:

Integrace zákaznických dat v systémech CDI - Customer Data Integration,

· Integrace údajů o zákaznících do modulů CRM - Customer Relations Management.

Zejména lze implementační přístup CDI provést různými způsoby.

Nejjednodušším způsobem je vytvořit konsolidovanou databázi zákazníků, která obsahuje data z primárních systémů. V tomto případě lze zpoždění informací regulovat pomocí různých konsolidačních režimů: provozních nebo dávkových, v závislosti na frekvenci aktualizace těchto informací.

Druhým způsobem je federace dat, když je virtuální obchodní prezentace údaje o zákaznících obsažené v primárních systémech. Soubor metadat může obsahovat obecné klíčové prvky, které lze použít k propojení informací o zákaznících.

Obecná (například podrobnosti) zákaznická data lze tedy sloučit jako nejstatičtější data. A dynamičtější data (například informace o objednávce) lze federalizovat.

Hybridní přístup lze navíc rozšířit pomocí metody šíření dat. Například klient využívající služby internetového obchodu mění během služby své podrobnosti. Tyto změny lze odeslat do konsolidované části databáze a odtud šířit do všech primárních systémů obsahujících údaje o zákaznících obchodu.

Vzhledem k výhodám a nevýhodám každé z metod je vhodné kreativně přistupovat k jejich aplikaci a společnému použití.

Například federace dat je užitečná, když náklady na konsolidaci dat převáží obchodní výhody, které konsolidace poskytuje. Přesně taková situace je zejména rychlé zpracování žádostí a příprava zpráv.

Praktické aplikace metody šíření dat jsou velmi rozmanité, a to jak z hlediska výkonu, tak z hlediska schopnosti restrukturalizovat a čistit data.

5.4. Koncept a strukturální řešení datových skladů

Úložiště dat -jedná se o předmětově orientované integrované úložiště informací, které shromažďuje externí a provozní data i data z jiných systémů, na jejichž základě jsou vytvářeny procesy rozhodování a analýzy dat.

Na rozdíl od databází a databází není základem datových skladů interní, ale externí zdroje dat: různé informační systémy, elektronické archivy, veřejné elektronické katalogy, příručky a sbírky.

Koncept datového skladu je založen na dvou hlavních myšlenkách:

1. Integrace podrobných podrobných údajů (popisujících konkrétní fakta, vlastnosti, události atd.) Do jednoho úložiště.

2. Oddělení datových souborů a aplikací používaných pro zpracování a analýzu.

Datový sklad je organizován, když je nutné získat:

Integrace aktuálních a historických datových hodnot,

Kombinace dat z různých zdrojů,

Vytvoření spolehlivé datové platformy pro analytické účely,

Zajištění konzistence dat v celé organizaci,

Usnadnění implementace podnikových datových standardů beze změny stávajících operačních systémů,

· Poskytování širokého historického obrazu a příležitostí pro analýzu vývojových trendů.

Historicky byly datové sklady postaveny na jedno, dvou a třívrstvém designu.

Jednoúrovňové režimy byly původně určeny pro nejjednodušší architektury, které zahrnují funkční DSS, s nedostatečně rozvinutou informační infrastrukturou, když je analýza prováděna pomocí dat z operačních systémů, podle principu: data - prezentační formuláře.

Výhody těchto schémat jsou:

Rychlý přenos dat z operačních systémů do specializovaného systému bez mezilehlých odkazů,

· Minimální náklady v důsledku používání jediné platformy.

Nevýhody:

Úzký kruh vyřešených problémů v důsledku jediného zdroje dat,

· Špatná kvalita dat kvůli nedostatečnému kroku čištění.

Dvouúrovňové schémataposkytnout řetězec: data - data marts - prezentační formuláře. Používají se ve společnostech s velkým počtem nezávislých divizí, které používají své vlastní informační technologie.

Výhody:

Použité vitríny jsou navrženy tak, aby odpovídaly na konkrétní sadu otázek,

· Je možné optimalizovat data v datových tržištích, což zvyšuje výkon.

Nevýhody:

Potíže se zajištěním konzistence dat kvůli jejich vícenásobnému opakování ve výlohách,

Potenciální potíže s vyplněním výloh velké číslo zdroje dat,

· Vzhledem k nedostatečné konsolidaci dat na podnikové úrovni neexistuje jednotný obraz podnikání.

Vývoj vývoje vedl k tomu, že stavbu plnohodnotného datového skladu pro moderní podnikové systémy začala provádět společnost třívrstvá architektura (viz obrázek 5.4).

Na prvníúroveň obsahuje řadu nahrávacích systémů, které jsou zdroji dat. Takovými systémy mohou být systémy plánování podnikových zdrojů (ERP - Enterprise Resource Planning), referenční (provozní) systémy, externí zdroje nebo systémy dodávající data od informačních agentur atd.

Na druhýúroveň obsahuje centrální úložiště, kde se shromažďují data ze všech zdrojů první úrovně, a také provozní datový sklad, který je navržen tak, aby vykonával dvě funkce:

Sklad je zdrojem analytických informací používaných pro provozní řízení,

· V provozním skladu jsou připravována data pro následné načtení do centrálního skladu. Příprava dat znamená provádění kontrol a transformace dat v souvislosti s různými předpisy pro příjem dat z první úrovně.

Třetíúroveň je sbírka datových trhů specifických pro doménu.

Datové trhy - jedná se o relativně malé funkčně zaměřené pohony, jejichž obsah přispívá k řešení analytických úkolů jednotlivých divizí společnosti. Ve skutečnosti jsou datové tržiště podmnožinami dat ze skladu. Koncoví uživatelé mají zároveň možnost přístupu k podrobným údajům o skladu v případě, že v obchodě není dostatek dat, a také k získání ucelenějšího obrazu o stavu podnikání.

Obrázek 5.4. Architektura datového skladu

Hlavní technologické operace těchto organizovaných datových skladů jsou:

· Načítánídata je proces přenosu dat z heterogenních zdrojů do provozního skladu,

· Proměnadata je modifikace dat na základě zvláštních pravidel s jejich následným přenosem do centrálního úložiště,

· Čištěnídata je eliminace duplikace dat pocházejících z různých zdrojů,

· Aktualizacedata je propagace aktualizace dat na původní data základních tabulek a odvozená data uložená ve skladu.

Výhody:

· Plnění výloh je zjednodušeno díky použití jediného zdroje očištěných dat,

Datové trhy jsou synchronizovány s firemním obchodním obrázkem, což usnadňuje rozšíření centrálního úložiště a přidání datových trhů,

· Zaručený výkon.

Nevýhody:

Redundance dat vedoucí ke zvýšeným technologickým požadavkům datové úložiště,

5. 5. Systémy správy databází a technologie pro přístup k datům v CIS

Systém pro správu databází (DBMS) je sada jazykových a softwarových nástrojů určených k vytváření, údržbě a sdílení databáze jedním nebo více uživateli.

V současné době jsou nejrozšířenější DBMS postavené na základě relačního datového modelu popsaného přísným matematickým aparátem teorie vztahů.

Vlastností systému DBMS pracujícího v podnikovém informačním systému je skutečnost, že musí spravovat databáze umístěné na médiích distribuovaných v prostoru.

V zájmu zabránění další duplikaci nebo kopírování dat v CIS je hlavní důraz kladen na princip vzdáleného zpracování dat. Databáze v CIS obsahují data, která mnoho uživatelů potřebuje. Získání simultánního přístupu několika uživatelů k databázi je možné při instalaci do lokální počítačové sítě DBMS, která pracuje s uživateli a s jednou databází.

Hlavními technologickými řešeními pro víceuživatelskou práci s databázemi jsou technologie souborů / serverů a klient / server. Nejvhodnější možností z těchto technologií jsou klient / server v CIS organizovanými specializovanými systémy pro zpracování distribuovaných databází. V tomto případě se správa distribuovaných databází provádí takovým způsobem, že data nejsou distribuována na logické, ale na fyzické úrovni a samotná databáze je považována za jeden „superobvod“. V distribuované databázi jsou administrativní funkce distribuovány mezi integrovaným správcem databáze a místními správci databáze. Integrovaný správce databáze sleduje diferenciaci přístupu různých uživatelů do databáze a zajišťuje integritu a bezpečnost dat, jakož i ochranu dat před jejich současnou korekcí několika uživateli. Kontrola přístupu se provádí v souladu s právy udělenými jednotlivým uživatelům v síťovém operačním systému.

Charakteristickým rysem programů vytvořených pomocí DBMS pro práci se vzdálenými a distribuovanými podnikovými databázemi je použití otevřeného rozhraní pro přístup k datům - ODBC (Open Data Base Connectivity). Všechny funkce pro přenos dat jsou přiřazeny rozhraní ODBC, které je spojovacím můstkem mezi integrovanou databází DBMS a klientskými aplikacemi DBMS. Současně může klientský DBMS interagovat nejen se svými lokálními databázemi, ale také s daty umístěnými v integrované databázi. Klient má schopnost odesílat požadavky do integrované databáze DBMS, přijímat údaje o nich a odesílat vlastní aktualizovaná data.

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 prostředí je pro úspěšné podnikání bezpodmínečně nutné mít jasné pochopení vazeb mezi různými složkami a dobré porozumění celkovému obrazu organizace. Identifikace všech detailů a vztahů pomocí modelů umožňuje nejefektivnější využití času a nástrojů pro organizaci práce společnosti.

Datové modely jsou abstraktní modely, které popisují způsob prezentace a přístupu k datům. Datové modely definují datové položky a vztahy mezi nimi v konkrétní oblasti. Datový model je navigační nástroj pro podnikové i IT profesionály, který používá konkrétní sadu symbolů a slov k přesnému vysvětlení konkrétní třídy skutečných informací. To umožňuje lepší komunikaci v rámci organizace a vytváří tak flexibilnější a stabilnější prostředí aplikace.

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 například obrázek, binární soubor nebo text, kde může být význam nejednoznačný).

Zpravidla se rozlišují modely vyšší úrovně (a obecnější z hlediska obsahu) a nižší (respektive podrobnější). Horní úroveň modelování je tzv koncepční datové modely (koncepční datové modely), které poskytují nejobecnější obraz o fungování podniku nebo organizace. Koncepční model zahrnuje hlavní koncepty nebo tematické oblasti, které jsou kritické pro fungování organizace; jejich počet obvykle nepřesahuje 12-15. Takový model popisuje třídy entit, které jsou důležité 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í definitivně ustálená, lze koncepční datové modely v různých zdrojích v anglickém jazyce nazývat také model předmětové oblasti (což lze přeložit jako doménové modely) nebo předmětový podnikový datový model (předmětové podnikové datové modely).

Další hierarchická úroveň je logické datové modely (logické datové modely). Mohou se také nazývat podnikové datové modely nebo obchodní modely. Tyto modely obsahují datové struktury, jejich atributy a obchodní pravidla a představují informace, které podnik používá 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ý podnikovým uživatelům usnadňuje pochopení. V logickém modelu lze rozlišit datový slovník - seznam všech entit s jejich přesnými definicemi, který umožňuje různým kategoriím uživatelů společné porozumění všem vstupním a informačním výstupním proudům modelu. Další nižší úrovní modelování je 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 podobu normalizovaného modelu. Normalizace je proces, který zajišťuje, že každá datová položka v modelu má pouze jednu hodnotu a je zcela a jednoznačně závislá na primárním klíči. Datové položky jsou uspořádány do skupin podle jejich jedinečné identifikace. Obchodní pravidla upravující datové položky musí být plně začleněna do normalizovaného modelu s předchozím ověřením a ověřením. Například datová položka, jako je jméno zákazníka, bude pravděpodobně rozdělena na křestní jméno a příjmení a seskupena s dalšími souvisejícími datovými položkami do entity zákazníka 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íťové technologie nebo nástroje pro podávání zpráv, a na prostředcích jejich fyzické implementace. V organizaci může být pouze jeden Enterprise Data 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 přibližně 3000 průmyslový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í a sémantický datový model představuje aplikované obchodní řešení. Stejný podnikový logický datový model lze implementovat pomocí různých sémantických modelů, tj. sémantické modely lze považovat za další úroveň modelování blížící se fyzickým modelům. Každý z těchto modelů bude navíc představovat samostatný „výřez“ podnikového datového modelu v souladu s požadavky různých aplikací. Například v korporátním logickém datovém modelu bude entita Client zcela normalizována a v sémantickém modelu pro datový trh může být reprezentována jako multidimenzionální struktura.

Společnost může mít dva způsoby, jak vytvořit podnikový logický datový model: sestavit jej samostatně nebo použít hotový. průmyslový model (průmyslový logický datový model). V tomto případě rozdíly v pojmech 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, 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í. Průmyslový logický model je doménově specifický a integrovaný pohled na všechny informace, které musí být umístěny v podnikovém datovém skladu, aby bylo možné odpovědět na strategické i taktické obchodní otázky. Stejně jako u jiných logických datových modelů je průmyslový model nezávislý na aplikačních rozhodnutích. Nezahrnuje ani odvozená data ani jiné výpočty pro rychlejší načítání dat. Většina logických struktur takového modelu je zpravidla dobře zakomponována do jeho účinné fyzické implementace. Takové modely jsou vyvíjeny mnoha dodavateli pro širokou škálu oblastí činnosti: finance, výroba, cestovní ruch, zdravotnictví, pojišťovnictví atd.

Průmyslový logický datový model obsahuje informace, které jsou pro toto odvětví společné, a proto nemůže být pro společnost komplexním řešením. Většina společností musí model rozšířit v průměru o 25% přidáním datových položek a rozšířením definic. Out-of-the-box modely obsahují pouze klíčové datové prvky a zbytek prvků musí být přidán do odpovídajících obchodních objektů během instalace modelu ve společnosti.

Průmyslové logické datové modely obsahují značné množství abstrakce. Abstrakce znamenají spojení podobných konceptů pod běžnými názvy, jako je Událost nebo Účastník. To zvyšuje flexibilitu průmyslových modelů a činí je jednotnějšími. Koncept Události je tedy použitelný ve všech průmyslových odvětvích.

Specialista na obchodní inteligenci Steve Hoberman identifikuje pět faktorů, které je třeba vzít v úvahu při rozhodování, zda získat průmyslový datový model. První je čas a peníze potřebné k sestavení modelu. Pokud organizace potřebuje rychle dosáhnout výsledků, pak bude průmyslový model přínosný. Použití průmyslového modelu nemusí okamžitě poskytnout obraz o celé organizaci, ale může ušetřit značné množství času. Místo samotného modelování bude čas věnován propojení existujících struktur s průmyslovým modelem a diskusi o tom, jak jej nejlépe přizpůsobit potřebám organizace (například jaké definice by měly být změněny a které datové položky by měly být přidány).

Druhým faktorem je čas a peníze potřebné k udržení modelu v dobrém funkčním stavu. Pokud podnikový datový model není součástí metodiky, která umožňuje sledovat dodržování jeho přesnosti a dodržování moderních standardů, stane se takový model velmi rychle zastaralým. Průmyslový datový model může tomuto riziku zabránit, protože je udržován v aktuálním stavu s externími prostředky. Změny, které v organizaci probíhají, by se samozřejmě měly v modelu promítnout do samotné společnosti, ale změny v odvětví budou v modelu reprodukovány jejím dodavatelem.

Třetím faktorem jsou zkušenosti s hodnocením a modelováním rizik. Vytvoření podnikového datového modelu vyžaduje kvalifikované zdroje jak od obchodního personálu, tak od zaměstnanců IT. Manažeři si zpravidla dobře uvědomují buď práci organizace jako celku, nebo činnosti konkrétního oddělení. Jen málo z nich má jak široké (celofiremní), tak hluboké (v rámci oddělení) znalosti svého podnikání. Většina manažerů obvykle dobře zná jen jednu oblast. Proto, abychom získali obecný podnikový obraz, jsou zapotřebí významné obchodní zdroje. To také zvyšuje požadavky na IT pracovníky. Čím více obchodních zdrojů je potřeba k sestavení a testování modelu, tím zkušenější analytici musí být. Musí nejen vědět, jak získat informace od zaměstnanců obchodu, ale musí být také schopni najít společnou řeč ve sporných oblastech a být schopni předložit všechny tyto informace integrovaným způsobem. Osoba vytvářející model (v mnoha případech stejný analytik) musí mít dobré modelovací schopnosti. Vytváření modelů podnikové logiky vyžaduje modelování „pro budoucnost“ a schopnost doslova převádět složité podnikání „na čtverce a čáry“.

Na druhé straně průmyslový model umožňuje externí odborné znalosti. Logické modely specifické pro dané odvětví jsou vytvářeny pomocí osvědčených metodik modelování a týmů zkušených odborníků, aby se zabránilo běžným a nákladným problémům, které mohou nastat při vývoji podnikových datových modelů v organizaci.

Čtvrtým faktorem je stávající aplikační infrastruktura a vztahy s dodavateli. Pokud organizace již používá mnoho nástrojů od stejného dodavatele a má s ním navázané vztahy, pak má smysl si od něj objednat průmyslový model. Tento model bude moci volně pracovat s dalšími produkty od stejného dodavatele.

Pátým faktorem je výměna informací v rámci odvětví. Pokud společnost potřebuje komunikovat s jinými organizacemi pracujícími ve stejné oblasti, může být v této situaci velmi užitečný průmyslový 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 vyměňovat si údaje, aby mohly úspěšně podnikat.

Nejúčinnější jsou průmyslové modely nabízené profesionálními dodavateli. Vysoká účinnost jejich použití je dosažena díky značné míře podrobností a přesnosti těchto modelů. Obvykle obsahují mnoho datových atributů. Tvůrci těchto modelů navíc mají nejen rozsáhlé zkušenosti s modelováním, ale také se dobře orientují v budování modelů pro konkrétní odvětví.

Průmyslové datové modely poskytují společnostem jediný integrovaný pohled na jejich obchodní informace. Mnoho společností považuje za obtížné integrovat svá data, i když je to předpokladem pro většinu celopodnikových projektů. Podle studie Data Warehousing Institute (TDWI) více než 69% dotazovaných organizací shledalo integraci jako významnou překážku přijetí nových aplikací. Naopak implementace datové integrace generuje pro společnost hmatatelný příjem.

Průmyslový datový model kromě propojení se stávajícími systémy poskytuje velké výhody pro celopodnikové projekty, jako je Enterprise Resource Planning (ERP), správa hlavních dat, business inteligence, zlepšování kvality dat a rozvoj zaměstnanců.

Průmyslové logické datové modely jsou tedy účinným nástrojem pro integraci dat a získání holistického pohledu na podnikání. Použití logických modelů se jeví jako nezbytný krok k vytvoření podnikových datových skladů.

Publikace

1. Steve Hoberman. Využití průmyslového logického datového modelu jako vašeho podnikového datového modelu.
2. Claudia Imhoff. Fast-Tracking Data Warehousing & Business Intelligence Projects via Intelligent Data Modeling

Firemní databáze je ústředním článkem podnikového informačního systému a umožňuje vám vytvořit jednotný informační prostor pro společnost. Firemní databáze

Sdílejte svou práci na sociálních médiích

Pokud vám tato práce nevyhovovala, ve spodní části stránky je seznam podobných prací. Můžete také použít tlačítko Hledat

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 podniková řešení pro přístup do databáze.

PROTI .jeden. ORGANIZACE ÚDAJŮ V FIREMNÍCH SYSTÉMECH. FIREMNÍ DATABÁZE

Firemní základna data jsou ústředním článkem podnikového informačního systému a umožňují vám vytvořit jednotný informační prostor pro společnost. Firemní databáze (obrázek 1.1).

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

Pod databází (DB) rozumět souboru informací logicky propojených takovým způsobem, aby tvořily jedinou sadu dat uložených v paměťových zařízeních počítače. Tato sada funguje jako počáteční data úkolů řešených v procesu fungování automatizovaných řídicích systémů, systémů zpracování dat, informačních a výpočetních systémů.

Termín databáze lze stručně formulovat jako soubor logicky souvisejících dat určených ke sdílení.

Pod databází se rozumí soubor dat uložených společně s takovou minimální redundancí, která umožňuje jejich optimální využití pro jednu nebo více aplikací.

Účel vytváření databází jako formy ukládání dat konstrukce datového systému, který nezávisí na přijatých algoritmech (software), 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é použití (několik uživatelů, mnoho forem dokumentů a požadavků jednoho uživatele).

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

• Úplnost prezentace údajů. Data v databázi by měla adekvátně představovat všechny informace o objektu a měla by být dostatečná pro ODS.
• Integrita databáze. Data musí být uložena při zpracování jejich ODS a v jakýchkoli situacích, které nastanou během práce.
• Flexibilita datové struktury. Při změně vnějších podmínek by databáze měla umožňovat změnu datových struktur bez narušení její integrity a úplnosti.
• Proveditelnost. To znamená, že musí existovat objektivní znázornění různých objektů, jejich vlastností a vztahů.
• Dostupnost. Je nutné zajistit rozlišení přístupu k údajům.
• Nadbytek. Databáze by měla mít minimální redundanci při reprezentaci dat o jakémkoli objektu.

Znalosti znamenají soubor faktů, vzorů a heuristických pravidel, která lze použít k vyřešení problému.

Znalostní databáze (KB)  soubor databází a použitých pravidel získaných od osob s rozhodovací pravomocí. Znalostní základna je součástí expertních systémů.

Rozlišovat různé způsoby prezentace údajů.

Fyzická data - jsou to data uložená v paměti počítače.

Logická reprezentace dat odpovídá vlastnímu pohledu na fyzická data. Rozdíl mezi fyzickými a odpovídajícími logickými reprezentacemi dat spočívá v tom, že tyto odrážejí některé důležité vztahy mezi fyzickými daty.

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

Postava: 1.1. Struktura interakce oddělení s informačními zdroji společnosti.

Firemní databáze jsou soustředěný (centralizované) a distribuovány.

Soustředěná (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 představuje diagram serverové aplikace pro přístup k databázím na různých platformách.

Obrázek 1.2. Heterogenní schéma centralizovaná databáze

Centralizace zpracování informací umožnila eliminovat takové nevýhody tradičních souborových systémů, jako je nesoudržnost dat, nekonzistence a redundance. Jak však databáze rostou, a to zejména při použití v geograficky rozptýlených organizacích, nastávají problémy. Například u koncentrovaných databází umístěných v uzlu telekomunikační sítě, pomocí nichž různá oddělení organizace získávají přístup k datům, s růstem objemu informací a počtu transakcí, vznikají následující potíže:

• Velký tok výměny dat;
• Vysoký provoz v síti;
• Nízká spolehlivost;
• Špatný celkový výkon.

I když je snazší zajistit zabezpečení, integritu a konzistenci informací během aktualizací v koncentrované databázi, tyto problémy představují určité výzvy. Tak jako možné řešení u těchto problémů se navrhuje decentralizace dat. Decentralizace dosahuje:

• Vyšší stupeň simultánnosti zpracování díky vyrovnávání 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 místních databází.

Náklady na vytvoření sítě, v uzlech kterých jsou umístěny pracovní stanice (malé počítače), jsou mnohem nižší než náklady na vytvoření podobného systému pomocí velkého počítače. Obrázek 1.3 ukazuje logické schéma distribuované databáze.

Obrázek 1.3. Databáze distribuovaných společností.

Pojďme uvést následující definici distribuované databáze.

Distribuovaná databáze - je to soubor informací, souborů (relací) uložených v různých uzlech informační síť a logicky připojeny takovým způsobem, aby vytvořily jednu sadu dat (připojení může být funkční nebo prostřednictvím kopií stejného souboru). Jedná se tedy o soubor databází propojených logicky, ale fyzicky umístěných na několika počítačích, které jsou součástí stejné počítačové sítě.

Nejdůležitější požadavky na výkon distribuované databáze jsou:

• Škálovatelnost;
• Kompatibilita;
• Podpěra, podpora různé modely data;
• Přenosnost;
• Průhlednost umístění;
• Autonomie distribuovaných databázových uzlů (Site Autonomy);
• Distribuované zpracování požadavků;
• Provádění distribuovaných transakcí.
• Podpora homogenního bezpečnostního systému.

Průhlednost umístění umožňuje uživatelům komunikovat s databázemi, aniž by věděli cokoli o jejich umístění. Autonomie uzlů v distribuované databázi 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 se přistupuje k objektům (tabulkám nebo pohledům) různých databází. Při provádění distribuovaných transakcí se provádí řízení souběžnosti všech zúčastněných databází. Oracle7 používá k provádění distribuovaných transakcí technologii dvoufázového přenosu informací.

Databáze, které tvoří distribuovanou databázi, nemusí být homogenní (tj. Musí být udržovány jedním DBMS) nebo zpracovávány v prostředí stejného operačního systému a / nebo v počítačích stejného typu. Například jednou databází 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 hostována databází DB2 na sálovém počítači IBM 3090 s operačním systémem MVS a třetí databázi lze provozovat pomocí SQL / DS také na mainframe IBM, ale s operačním systémem VM. Je vyžadována 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 ní. Tento problém lze vyřešit následujícími způsoby:

• Každý uzel ukládá a používá vlastní datovou sadu, která je k dispozici pro vzdálené dotazy. Toto rozdělení je rozděleno.
• Některá data často používaná na vzdálených webech mohou být duplikována. Tato distribuce se nazývá částečně duplikovaná.
• Všechna data jsou duplikována v každém uzlu. Tato distribuce se nazývá plně duplikovaná.
• Některé soubory lze rozdělit horizontálně (je vybrána podmnožina záznamů) nebo svisle (je vybrána podmnožina polí atributů), zatímco vybrané podmnožiny jsou uloženy v různých uzlech spolu s nerozdělenými daty. Tato distribuce se nazývá rozdělená (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 jediný koncepční diagram celé sítě. To uživateli poskytne logickou transparentnost dat, v důsledku čehož bude schopen vytvořit požadavek na celou databázi, která bude za samostatným terminálem (zdá se, že funguje s centralizovanou databází).
• K vyhledání dat v síti je potřeba schéma. To zajistí transparentnost umístění dat, díky čemuž uživatel nemusí specifikovat, kam má poslat požadavek, aby získal požadovaná data.
• Je nutné vyřešit problém heterogenity distribuovaných databází. Distribuované databáze mohou být z hlediska hardwaru a softwaru homogenní nebo heterogenní. Problém heterogenity je relativně snadné vyřešit, pokud je distribuovaná databáze heterogenní ve smyslu hardwaru, ale homogenní ve smyslu softwaru (stejný DBMS v uzlech). Pokud se v uzlech distribuovaného systému používají různé DBMS, jsou vyžadovány prostředky pro transformaci datových struktur a jazyků. To by mělo zajistit transparentnost transformace napříč uzly distribuované databáze.
• Je třeba řešit problém správy slovníku. K zajištění všech druhů transparentnosti v distribuované databázi potřebujete programy, které spravují více slovníků a referenčních knih.
• Musíte definovat metody pro provádění dotazů v distribuované databázi. Metody pro provádění dotazů v distribuované databázi se liší od metod v centralizovaných databázích, protože jednotlivé části dotazů je třeba provádět v místě odpovídajících dat a částečné výsledky je třeba předávat dalším uzlům; zároveň musí být zajištěna koordinace všech procesů.
• Je nutné vyřešit problém paralelního provádění dotazu. V distribuované databázi je zapotřebí sofistikovaný mechanismus řízení souběžnosti, který zejména musí zajistit synchronizaci během aktualizací informací, což zajišťuje konzistenci dat.
• Vyvinutá metodika 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 výpočetních systémů, která je výkonným nástrojem pro zpracování nečíselných informací, jsou databázové stroje... Databázové stroje se používají k řešení nečíselných úkolů, jako je ukládání, vyhledávání a transformace dokumentů a faktů a práce s objekty. V návaznosti na definici dat jako digitálních a grafických informací o objektech okolního světa je do koncepce dat v numerickém i nečíselném zpracování vložen odlišný obsah. Numerické zpracování používá objekty, jako jsou proměnné, vektory, matice, vícerozměrná pole, konstanty atd., Zatímco nečíselné zpracování používá objekty, jako jsou soubory, záznamy, pole, hierarchie, sítě, vztahy atd. nečíselné zpracování se zajímá přímo o informace o objektech (například o konkrétním zaměstnanci nebo skupině zaměstnanců), nikoli o soubor zaměstnanců jako takových. Soubor zaměstnanců zde není indexován za účelem výběru konkrétní osoby; zde je obsah požadovaného záznamu zajímavější. Velké množství informací je obvykle podrobeno nečíselnému zpracování. V různých aplikacích můžete s těmito daty provádět například následující operace:

• zvýšit plat všem zaměstnancům společnosti;
• vypočítat bankovní úroky na účtech všech klientů;
• provádět změny v seznamu veškerého zboží na skladě;
• vyhledat požadovaný abstrakt ze všech textů uložených v knihovně nebo v systému vyhledávání bibliografických informací;
• vyhledejte popis požadované smlouvy ve složce obsahující právní dokumenty;
• procházejte všechny soubory obsahující popisy patentů a znovu vyhledejte patent (pokud existuje) podobný navrhovanému.

Implementovat databázový stroj, paralelní a asociativní architektura jako alternativa k jednoprocesoruvon Neumann struktura, která umožňuje pracovat s velkým množstvím informací v reálném čase.

Databázové stroje získávají na důležitosti ve vztahu k výzkumu a aplikaci konceptů umělá inteligence, jako je reprezentace znalostí, expertní systémy, závěry, rozpoznávání vzorů atd.

Informační úložiště. Dnes mnozí připouštějí, že již nyní většina společností provozuje několik databází a pro úspěšnou práci s informacemi jsou vyžadovány nejen různé typy databází, ale i různé generace DBMS. Podle statistik každá organizace používá průměrně 2,5 různých DBMS. Ukázalo se, že je třeba „izolovat“ podnikání společností, respektive osob 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. To stimulovalo vznik technologie pro ukládání informací (Datové sklady, DW).

Hlavním účelem DW je vytvoření jediné logické prezentace 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 zdokonalení informačních technologií obecně, zejména díky vzniku nových typů databází založených na zpracování paralelních dotazů, které se 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é usnadňuje vytváření složitých databázových dotazů. Různé softwarestřední vrstva (midleware) za předpokladu komunikacemezi různými typy databázía nakonec prudce pokleslpaměťová zařízení.

Struktura společnosti může obsahovat databanku.

Databáze - funkční a organizační složka v automatizované systémy systémy pro správu a informace, které poskytují centralizovanou informační podporu pro skupinu uživatelů nebo soubor úkolů ř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 hromadění a udržování funkčního stavu souboru informací, které tvoří informační základnu celého automatizovaného systému nebo určité sady úkolů v něm řešených;
• při vydávání údajů požadovaných úkolem nebo uživatelem;
• při poskytování hromadného přístupu k uloženým informacím;
• při zajišťování nezbytného řízení využívání informací obsažených v informační základně.

Moderní databanka je tedy komplexním softwarovým a hardwarovým komplexem, 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í v podnikových systémech

Systémy pro správu databází a 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 přístup k systémům zpracování dat do databází. Jak již bylo uvedeno, DBMS získávají důležitou roli při vytváření podnikových informačních systémů a obzvláště důležitou roli při vytváření informačních systémů pomocí distribuovaných informační zdrojezaložené na moderních síťových počítačových technologiích.

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

• Technologie klient / server.
• Podpora jazyků databáze. tojazyk definice schématu DB (SDL - Schema Definition Language),data Manipulation Language (DML), integrované jazykySQL (Structured Queue Language), QDB (Query - By - Example) a QMF (Query Management Facility) ) Je pokročilá specifikace periferních dotazů a nástroj pro podávání zpráv proDB 2 atd .;
• Přímá správa dat v externí paměti.
• Správa vyrovnávacích pamětí RAM.
• Správa transakcí. OLTP - technologie (On-line zpracování transakcí), OLAP -technologie (Zpracování on-line analýzy)pro DW.
• Zajistěte ochranu a integritu dat. Používání systému je povoleno pouze uživatelům, kteří mají právo na přístup k údajů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 informačních systémech pro více uživatelů.
• Journalizace.

Moderní systém DBMS musí zajistit, aby byly splněny výše uvedené požadavky na databázi. Kromě toho musí dodržovat následující zásady:

• Nezávislost na datech.
• Všestrannost. DBMS musí mít výkonnou podporu koncepčních datových modelů pro zobrazování vlastních logických pohledů.
• Kompatibilita. Systém DBMS musí zůstat v provozu s vývojem softwaru a hardwaru.
• Redundance dat. Na rozdíl od souborových systémů musí být databáze jedinou kolekcí integrovaných dat.
• Ochrana dat. Systém DBMS musí poskytovat ochranu před neoprávněným přístupem.
• Integrita dat. DBMS musí zabránit uživatelům v rozbití databáze.
• Řízení souběžné práce. DBMS musí chránit databázi před nesrovnalostmi 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) provedeny v určitém pořadí.
• DBMS musí být univerzální. Mělo by podporovat různé datové modely na jednom logickém a fyzickém základě.
• DBMS musí 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ší funkce, které určují typy DBMS. Podle nich lze na systém DBMS pohlížet 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 běž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“). Mají sady příkazů pro sdílení běžných databází, ale malé velikosti (jako malá kancelář). Nejprve je to DBMS jako Assess, dBASE, Paradox, EohPgo. Proč Assess, dBASE, Paradox, EohPgo mají špatný přístup k podnikovým datům. Jde o to, že neexistuje snadný způsob, jak překonat bariéru mezi osobními a firemními údaji. Nejde ani o to, že mechanismus osobních údajů DBMS (nebo malých kanceláří) je zaměřen na přístup k datům prostřednictvím mnoha bran, produktů pro síťovou komunikaci atd. Problém je v tom, že tyto mechanismy jsou obvykle spojeny s úplnými přenosy souborů a nedostatkem podpory vidlicového indexu, což vede k tomu, že se fronty serverů ve velkých systémech prakticky zastaví.
• Specializovaný vysoce výkonný víceuživatelský DBMS. Takové DBMS se vyznačují přítomností jádra víceuživatelského systému, jazykem pro manipulaci s daty a následujícími funkcemi typickými pro rozvinuté víceuživatelské DBMS:
• organizace rezervního fondu;
• přítomnost systému pro zpracování front transakcí;
• přítomnost mechanismů pro uzamčení dat více uživatelů;
• protokolování transakcí;
• dostupnost mechanismů kontroly přístupu.

Jedná se o DBMS jako Oracle, DB2, SQL / Server, Informix, Sybase, ADABAS, Titanium a další poskytují širokou službu pro zpracování podnikových databází.

Při práci s databázemi se používá transakční mechanismus.

Transakce Je logickou jednotkou práce.

Transakce je posloupnost provedených příkazů pro manipulaci s datyjako celek (vše nebo nic) a překlad databázez jednoho celostního stavu do jiného celostního stavu.

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

• (A) Atomicita ... Transakce se provádí jako atomická operace - buď se provede celá transakce, nebo se neprovede úplně.
• (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 dojít k porušení konzistence databáze.
• (I) Izolace ... Transakce různých uživatelů by se neměly vzájemně rušit (například jako by byly prováděny striktně postupně).
• (E) Trvanlivost... Pokud je transakce dokončena, měly by být výsledky její práce uloženy v databázi, i když v příštím okamžiku dojde k selhání systému.

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

• Byl vydán příkaz ZAPOJIT PRÁCI.
• Byl vydán příkaz ROLLBACK WORK.
• Uživatel byl odpojen od systému DBMS.
• Došlo k selhání systému.

Pro uživatele obvykle nosí atomový znak... Ve skutečnosti se jedná o složitý mechanismus interakce uživatel (aplikace) - databáze. Software podnikových systémů používá stroj pro zpracování transakcí v reálném čase (On-line systémy pro zpracování transakcí, OLTP), zejména účetní software, software pro příjem a zpracování objednávek klientů, finanční aplikace, produkují mnoho informací. Tyto systémy jsou navrženy (a vhodně optimalizovány) pro zpracování velkého množství dat, složitých transakcí a intenzivních operací čtení a zápisu.

Informace umístěné v databázích systémů OLTP nejsou bohužel pro běžné uživatele příliš vhodné (kvůli vysoké míře normalizace tabulek, specifickým formátům prezentace dat a dalším faktorům). Proto jsou data z různých informačních kanálů odesílána (ve smyslu kopírování) do sklad, třídění a následné dodání spotřebiteli. V informačních technologiích hraje roli skladůinformační úložiště.

Dodání informací koncovému uživateli - systémy zpracování analytických dat v reálném čase (On-line analytické zpracování, OLAP)které poskytují extrémně snadný přístup k datům prostřednictvím pohodlných způsobů generování dotazů a analýzy výsledků. V systémech OLAP se hodnota informačního produktu zvyšuje díky použití 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í). LiSystém OLTP dává odpovědi na jednoduché otázky typu „jaká byla úroveň prodeje produktu N v regionu M v lednu 199x?“, potéOLAP systémy připraven na složitější požadavky uživatelů, například: „Poskytnout analýzu prodeje produktu N ve všech regionech podle plánu na druhé čtvrtletí ve srovnání s dvěma předchozími roky.“

Architektura klient / server

V moderních systémech distribuované zpracování informací, technologie se dostává do centra pozornostiklient-server. V systému architektura klient-server zpracová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í zpracování dat je založeno na seskupení funkcí. Počítač databázového serveru je obvykle určen k provádění databázových operací a 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č jednající jako jeho klient. Každý stroj plní různé funkce a má své vlastní zdroje.

		Databáze
Počítač serveru
Síť
PC kompatibilní s IBM	PC kompatibilní s IBM	PC kompatibilní s IBM
		Aplikace

Postava: 2.1. Systém architektury klient-server

Hlavní funkcí klientského počítače je spuštění aplikace (uživatelské rozhraní a logika prezentace) a komunikace se serverem, pokud to aplikace vyžaduje.

Server - je objekt (počítač), který poskytuje služby jiným objektům na jejich žádost.

Jak vyplývá ze samotného termínu, hlavní funkcí serverového počítače je sloužit potřebám klienta. Termín „Server“ se používá pro označení dvou různých skupin funkcí: souborový server a databázový server (dále tyto výrazy znamenají v závislosti na kontextu buď software, který implementuje zadané skupiny funkcí, nebo počítače s tímto softwarem). Souborové servery nejsou určeny k provádění operací s databázemi, jejich hlavní funkcí je sdílení souborů mezi několika uživateli, tj. zajiště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 NetWare společnosti Novell. Databázový server lze instalovat a provozovat na počítači souborového serveru. Oracle DBMS ve formě NLM (Network Loadable Module) se provádí v prostředí NetWare na souborovém serveru.

Server místní sítě musí mít prostředky odpovídající jeho funkčnosti a potřebám sítě. Všimněte si, že v souvislosti se zaměřením na přístup otevřených systémů je správnější hovořit o logických serverech (což znamená soubor prostředků a softwaru poskytujících služby přes tyto zdroje), které nemusí být nutně umístěny na různé počítače... Funkce logického serveru v otevřeném systému spočívá v tom, že pokud je z důvodu efektivity vhodné přesunout server na samostatný počítač, lze to provést bez nutnosti jakýchkoli úprav, a to jak sebe, tak i aplikací, které jej používají.

Jedním z důležitých požadavků na server je, že operační systém hostující databázový server musí být multitasking (a nejlépe, ale ne nutně, víceuživatelský). Například Oracle DBMS nainstalovaný v osobním počítači s operačním systémem MS-DOS (nebo PC-DOS), který nesplňuje požadavek multitaskingu, nelze použít jako databázový server. A stejná databáze Oracle nainstalovaná v počítači s multitaskingovým (i když nikoli víceuživatelským) operačním systémem OS / 2 může být databázovým serverem. Mnoho příchutí systémů UNIX, MVS, VM a některých dalších operačních systémů je multitasking i více uživatelů.

Distribuované výpočty

Termín „distribuované výpočty“ se často používá k označení dvou různých, i když doplňkový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 více strojích pro koncové uživatele pomocí různých prostředků.

Existuje mnoho typů serverů:

• Databázový server;
• Tiskový server;
• Server pro vzdálený přístup;
• Faxový server;
• Webový server atd.

Srdcem základní technologie je klient / server jsou takové základní technologie jako:

• Technologie operačních systémů, koncept interakce otevřených systémů, vytváření 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 provádět 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.
• Proveďte výpočet tam, kde je to nejúčinnější;
• Poskytují efektivní škálovatelnost;
• Meziplatformové výpočty... Cross-platform computing je jednoduše definován jako implementace technologií v heterogenních výpočetních prostředích. Zde by měly být poskytnuty následující možnosti:
• Aplikace musí běžet na více platformách;
• Mělo by mít stejné rozhraní a logiku na všech platformách;
• 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ěla by být poskytována s jednoduchou a důslednou podporou.

 Distribuované výpočty. Distribuované výpočty zahrnují distribuci práce mezi několik počítačů (ačkoli distribuovaný výpočet je širší pojem).

 Zmenšování. Oddělení je přenos sálových aplikací na malé počítačové platformy.

• Snížené náklady na infrastrukturu a hardware. Ekonomické: Díky dostupnosti levného výpočetního vybavení a rostoucímu šíření lokálních sítí je technologie klient-server ekonomičtější než jiné technologie zpracování dat. Zařízení lze upgradovat, jakmile to bude potřeba.

 Zkrácená celková doba spuštění aplikace;

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

 Snižování síťového provozu.

• Schopnost pracovat s multimédii: k dnešnímu dni bylo pro PC vytvořeno mnoho multimediálních programů. Pro konfiguraci terminálu a hostitele neexistují žádné takové programy, nebo jsou velmi drahé.
• Schopnost přilákat velké výpočetní zdroje pro databázové operace: protože aplikace běží na klientských počítačích, jsou pro databázové operace uvolněny další (ve srovnání s konfigurací terminálového hostitele) prostředky na serveru, jako jsou výpočetní prostředky CPU a provozní Paměť.
• Vyšší produktivita programátoru: Produktivita programátora se zvyšuje pomocí nástrojů, jako jsou SQL * Forms a CASE, které vám umožňují vyvíjet aplikace rychleji než programovací jazyky jako C, PL1 nebo COBOL.
• Zvýšená produktivita koncového uživatele: Mnoho koncových uživatelů již nyní zvládlo systémy jako Lotus, Paradox, Word Perfect, Harvard Graphics atd.

Rozhraní na straně serveru je definováno a opraveno. Proto je možné vytvořit nové klientské části existujícího systému (příklad interoperability na úrovni systému).

Postava: 2.2. Ilustrace přístupu klienta ke sdílené položce na serveru.

Jak implementovat technologii klient-server

Následující diskuse pojednává o instalaci systému založeného na technologii klient-server a schopného provádět distribuované zpracování dat. 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 ... Jazyk dotazů na vysoké úrovni -SQL (jazyk strukturovaných dotazů ) slouží k implementaci dotazů do databází, jako jsou YAMD, YOD a PNP, a je přijat jako standard. JazykSQL byl původně přijat jako datový jazyk softwarových produktů společnostiIBM a YAMD relační DBMSSYSTEM R od IBM ... Důležitá vlastnost jazykaSQL je, že stejný jazyk je prezentován prostřednictvím dvou různých rozhraní, a to: prostřednictvím interaktivního rozhraní a prostřednictvím aplikačního programovacího rozhraní (dynamickýSQL). Dynamické SQL se skládá z mnoha vestavěných jazykových funkcíSQL , poskytovaný speciálně pro konstrukci interaktivních aplikací, kde se interaktivní aplikací rozumí program, který je napsán na podporu přístupu do databáze koncového uživatele pracujícího na interaktivním terminálu. JazykSQL poskytuje funkce definování, manipulace a správy databázových dat a je pro uživatele transparentní z hlediska implementovaného DBMS.

Postava: 2.3. Schéma provádění dotazů uživatelů do distribuovaných databází.

Vnitřní struktura databází je dána použitými datovými modely. Konceptuální model má větší abstrakční schopnosti a bohatší sémantiku než externí modely. Externí modely jsou často označovány jako syntaktické nebo provozní modely, odkazující na syntaktickou povahu kontroly a použití jako prostředek interakce uživatele s databází. V Informačním modelování existují různé úrovně abstrakce, od koncepčního modelu po fyzický datový model, které ovlivňují architekturu DBMS.

Datový model má tři komponenty:

• Datová struktura, která má být představována z pohledu uživatele databáze.
• Platné operace prováděné s datovou strukturou. Je nutné umět s touto strukturou pracovat pomocí různých NOD a NMD operací. Bohatá struktura je bezcenná, pokud neexistuje způsob, jak manipulovat s jejím obsahem.
• Omezení kontroly integrity. Datový model by měl být vybaven prostředky k udržení jeho integrity a jeho ochraně. 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 zdrojového uzlu.
• Pokud jde o relační databázi, nemohou existovat stejné n-tice. U souboru vyžaduje tento požadavek jedinečnost všech záznamů.

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

Mezi objekty existují následující typy odkazů:

• Jeden na jednoho (1: 1)... Jeden objekt jedné sady může být spojen s jedním objektem jiné sady.
• Jeden na mnoho (1: M)... Jeden objekt jedné sady může být spojen s mnoha objekty jiné sady.
• Mnoho na mnoho (M: N)... Jeden objekt jedné sady může být spojen s mnoha objekty jiné sady, ale jeden objekt jiné sady může být spojen s mnoha objekty první sady.
• Rozvětvený ... Jeden objekt jedné sady lze přiřadit k objektům mnoha sad.
• Rekurzivní ... Jeden objekt dané množiny může být propojen objektem stejné množiny.

Existují následující základní datové modely:

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

V .3. TECHNOLOGIE INTERNET / INTRANET A FIREMNÍ ŘEŠENÍ O PŘÍSTUPU K DATABÁZE

Hlavním problémem systémů založených na architektuře klient-server je, že v souladu s konceptem otevřených systémů musí být 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 lokální počítačové sítě založené na UNIX, různé sítě používají různá zařízení a komunikační protokoly. Pokusy o vytvoření systémů, které podporují všechny možné protokoly, vedou k jejich přetížení podrobnostmi sítě na úkor funkčnosti.

Ještě složitější aspekt tohoto problému je spojen s možností použití různých reprezentací dat v různých uzlech heterogenní místní 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 v systémech založených na architektuře klient-server je spoléhat se na softwarové balíčky, které implementují protokoly RPC (Remote Procedure Call). S těmito nástroji vypadá volání služby na vzdáleném místě jako normální volání procedury. Nástroje RPC, které přirozeně obsahují všechny informace o specifikách hardwaru místní sítě a síťových protokolech, převádí volání na posloupnost síťových interakcí. Specifika síťového prostředí a protokolů jsou tak před aplikačním programátorem skryta.

Když je volána vzdálená procedura, programy RPC převádějí formáty dat klienta na zprostředkující formáty nezávislé na stroji a poté převádějí na formáty dat serveru. Při předávání parametrů odezvy se provádějí podobné transformace.

Další podobná díla, která by vás mohla zajímat
6914.		Koncept databáze	11,56 KB
	Databáze je prezentována v objektivní podobě, soubor nezávislých materiálů článků výpočtů normativních aktů soudních rozhodnutí a dalších podobných materiálů systematizovaných tak, aby tyto materiály mohly být vyhledávány a zpracovávány pomocí elektronického počítačového občanského zákoníku Ruské federace čl. Databáze organizovaná v souladu s určitými pravidly a udržovaná v paměti počítače je soubor dat charakterizujících aktuální stav některých ...
8064.		Distribuované databáze	43,66 KB
	Distribuované databáze Pod distribuovaná základna Data RDB se chápou jako sada logicky propojených sdílených dat, která jsou fyzicky distribuována po různých uzlech 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čovat metody pro provádění spojení fúze dat, síťový kanál schopný zpracovávat objem přenášených informací a uzel s dostatečným výkonem zpracování pro připojení 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 operačních databázích byly interaktivně zpracovávány pomocí terminálů. Organizace jednoduchého indexového sekvenčního záznamu se rychle vyvinuly v výkonnější model záznamu orientovaný na sadu. Charles Bachmann obdržel Turingovu cenu za vedení skupiny Data Base Task Group (DBTG), která vyvinula standardní jazyk pro popis a manipulaci s daty.
5031.		Knihovna pro rozvoj databáze	11,72 MB
	Technologie návrhu databáze. Určení vztahů mezi entitami a vytvoření datového modelu. Hlavní myšlenky moderní informační technologie vycházejí z konceptu, podle něhož by data měla být organizována do databází, aby adekvátně odrážela měnící se skutečný svět a uspokojovala informační potřeby uživatelů. Tyto databáze jsou vytvářeny a fungují pod kontrolou speciálních softwarových systémů nazývaných systémy správy databází DBMS.
13815.		HIERARCHICKÝ MODEL DATABÁZE	81,62 KB
	Hlavní myšlenky moderní informační technologie vycházejí z konceptu databází, podle nichž základem informační technologie jsou data organizovaná v databázích, která adekvátně odrážejí stav konkrétní oblasti předmětu a poskytují uživateli relevantní informace v této oblasti. Je třeba si uvědomit, že data jsou ...
14095.		Vývoj databází knihoven	11,72 MB
	Zvýšení objemu a strukturální složitosti uložených dat, rozšíření okruhu uživatelů informačních systémů vedlo k širokému používání nejpohodlnějšího a relativně snadno pochopitelného relačního (tabulkového) DBMS.
5061.		Vytvoření databáze kliniky	2,4 MB
	Rozvoj výpočetní techniky a informační technologie poskytl příležitosti pro vytvoření a široké využití automatizovaných informačních systémů (AIS) pro různé účely. Informační systémy pro správu ekonomických a technických zařízení jsou vyvíjeny a implementovány
13542.		Geologické informační databáze	20,73 KB
	V poslední době rychle postupuje zavádění počítačových technologií a zejména databází do vědecké oblasti. Tento proces neobchází ani geologii, protože 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 jakékoli oblasti ekonomiky, managementu, chemie atd. Účelem informačního systému je nejen ukládat data o objektech, ale také s nimi manipulovat, s přihlédnutím ke spojením mezi objekty. Každý objekt je charakterizován sadou dat vlastností, které se v databázi nazývají atributy.
5240.		Vytvoření databáze "Děkanát"	1,57 MB
	Databáze (DB) je sada vzájemně propojených dat uložených společně na externím úložném médiu počítače s takovou organizací a minimální redundancí, která umožňuje jejich optimální využití pro jednu nebo několik aplikací

Účel přednášky

Po prostudování materiálu této přednášky budete vědět:

• co podnikový datový model ;
• jak převést podnikový datový model do modelu datového skladu;
• základní prvky podnikový datový model ;
• podnikové datové modely prezentační vrstvy ;
• algoritmus pro transformaci podnikového datového modelu na model vícerozměrného datového skladu ;

a naučit se:

• vyvíjet modely datových skladů na základě podnikový datový model organizace;
• navrhnout hvězdné schéma pomocí nástrojů CASE;
• tabulky oddílů vícerozměrný model pomocí nástrojů CASE.

Podnikový datový model

Úvod

Jádrem každého HD je jeho datový model. Bez datového modelu bude velmi obtížné uspořádat data v HD. Vývojáři HD by proto měli věnovat čas a úsilí vývoji takového modelu. Vývoj modelu HD spadá na bedra návrháře HD.

Ve srovnání s návrhem systémů OLTP má metodika návrhu CD řadu charakteristických rysů spojených s orientací datových struktur úložiště k řešení problémů analýzy a informační podpory rozhodovacího procesu. Datový model HD by měl poskytnout efektivní řešení přesně těchto problémů.

Výchozím bodem při návrhu CD může být tzv podnikový datový model (podnikový datový model nebo podnikový datový model, EDM), který je vytvořen v procesu navrhování systémů OLTP organizace. Při navrhování podnikový datový model obvykle se pokusí vytvořit datovou strukturu založenou na obchodních operacích, která by shromažďovala a syntetizovala všechny informační potřeby organizace.

Takto, podnikový datový model obsahuje informace potřebné k sestavení modelu CD. Proto v první fázi, pokud takový model v organizaci existuje, návrhář HD může zahájit návrh HD řešením problému transformace podnikový datový model do HD modelu.

Podnikový datový model

Jak vyřešit problém transformace podnikový datový model do HD modelu? Chcete-li tento problém vyřešit, musíte mít tento model, tj. podnikový datový model by měl být postaven a zdokumentováno... A musíte to pochopit co z tohoto modelu a tak jako by se měl transformovat na model HD.

Pojďme si vyjasnit koncept z pohledu designéra CD podnikový datový model. Pod podnikový datový model pochopit vrstvený strukturovaný popis domén organizace, datové struktury domén, obchodní procesy a obchodní postupy, toky dat organizace, stavové diagramy, matice datových procesů a další modelové reprezentace, které se používají v činnostech organizace. V širším slova smyslu tedy podnikový datový model je soubor modelů různých úrovní, které charakterizují (model na nějaké abstraktní úrovni) činnosti organizace, tj. obsah korporátní model přímo závisí na tom, jaké modelové konstrukce byly do dané organizace zahrnuty.

Hlavní prvky podnikový datový model jsou:

• popis tematických oblastí organizace (definice oblastí činnosti);
• vztahy mezi výše definovanými tematickými oblastmi;
• informační datový model (model ERD nebo model „entity-relationship“);
• popis pro každou oblast:
  • klíče entit;
  • atributy entity;
  • podtypy a supertypy;
  • vztahy mezi entitami;
  • atributy seskupení;
  • vztahy mezi tematickými oblastmi;
• funkční model nebo model obchodního procesu;
• diagramy toku dat;
• stavové diagramy;
• jiné modely.

Takto, podnikový datový model obsahuje entity, atributy a vztahy, které představují informační potřeby organizace. Na obr. 16.1 ukazuje hlavní prvky podnikový datový model.

Úrovně prezentace podnikového datového modelu

Podnikový datový model se dělí podle oborů, které představují skupiny subjektů souvisejících s podporou konkrétních obchodních potřeb. Některé tematické oblasti mohou zahrnovat konkrétní obchodní funkce, jako je správa smluv, zatímco jiné mohou zahrnovat entity, které popisují produkty nebo služby.

Každý logický model musí odpovídat existující doméně podnikový datový model... Pokud logický model tento požadavek nesplňuje, je nutné k němu přidat doménový model.

Podnikový datový model má obvykle několik úrovní prezentace. Ve skutečnosti vysoká úroveň (vysoká úroveň) podnikový datový model je zde popis hlavních tematických oblastí organizace a jejich vztahů na úrovni entit. Na obr. 16.2 je úryvek podnikový datový model nejvyšší úroveň.

Postava: 16.2.

Schéma zobrazené na obrázku představuje čtyři tematické oblasti: „Kupující“ ( Zákazník), "Skóre" ( účet), "Objednat" ( Objednat) a „Produkt“ ( Produkt). Zpravidla pouze na nejvyšší úrovni pohledu modelu přímé spojení mezi tematickými oblastmi, které například zaznamenávají následující skutečnost: kupující zaplatí fakturu za objednávku zboží. Podrobnosti a nepřímé vztahy na této úrovni korporátní model nezobrazeno.

Na další, střední úroveň (střední úroveň) podnikový datový model jsou zobrazeny podrobné informace o objektech tematických oblastí, tj. klávesy a atributy entity, jejich vztahy, podtypy a supertypy atd. Pro každou doménu modelu nejvyšší úrovně existuje jeden model střední úrovně. Na obr. 16.3 ukazuje střední úroveň prezentace korporátní model pro fragment předmětové oblasti „Objednávka“.

Obr. 16.3 je vidět, že předmětná oblast „Objednávka“ ( Objednat) zahrnuje několik entit definovaných prostřednictvím jejich atributů a vztahů mezi nimi. Představený model umožňuje odpovědět na otázky, jako je datum objednávky, kdo objednávku provedl, kdo objednávku odeslal, kdo objednávku přijal a řada dalších. Z výše uvedeného diagramu je patrné, že v této organizaci existují dva typy objednávek - objednávky na povýšení ( Commersial) a maloobchodní objednávky ( Maloobchodní).

všimněte si, že podnikový datový model může představovat různé aspekty činnosti organizace as různou mírou podrobnosti a úplnosti. Li korporátní model představuje všechny aspekty činnosti organizace, je také nazýván datový model organizace (podnikový datový model).

Z pohledu HD designu je to důležitý faktor při rozhodování o vytvoření HD modelu z podnikový datový model je stát úplnost podnikový datový model.

Firemní datový model organizace se vyznačuje vývojem, tj. neustále se vyvíjí a zlepšuje. Některé tematické oblasti podnikový datový model mohou být dobře vyvinuté, pro některé práce ještě možná nezačaly. Pokud v části nebyl zpracován fragment předmětné oblasti podnikový datový model, pak neexistuje žádný způsob, jak tento model použít jako výchozí bod pro návrh CD.

Stupeň dokončení korporátní model lze v designu CD srovnat následujícím způsobem. Vzhledem k tomu, že proces vývoje HD je obvykle rozdělen v čase do posloupnosti fází, lze proces jeho návrhu synchronizovat s proces dokončení vývoj jednotlivých fragmentů podnikový datový model organizace.

Na nejnižší prezentační vrstva podnikového datového modelu informace o fyzických vlastnostech databázových objektů odpovídajících logický datový model střední prezentační vrstva podnikového datového modelu.

IT profesionálové stále více obracejí 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í. Připraveno ke stažení komplexních fyzických datových modelů a zpráv Business Intelligence pro konkrétní oblasti činnosti vám umožní 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žívat sílu nestandardních informací skrytých ve stávajících systémech, čímž snižují dobu realizace projektu, náklady a rizika. Například projekty z reálného světa ukazují, že šablony datových modelů a obchodních rozhodnutí mohou snížit vývojové úsilí o 50%.

Průmyslový logický model je doménově specifické, integrované a logicky strukturované zobrazení všech informací, které musí být uloženy v podnikovém datovém skladu, aby mohly odpovídat na 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 moderních podmínkách je pro úspěšné podnikání nutné mít jasnou představu o souvislostech mezi různými složkami a mít dobrou představu o celkovém obrazu organizace. Identifikace všech detailů a vztahů pomocí modelů umožňuje nejefektivnější využití času a nástrojů pro organizaci práce společnosti.

Datové modely jsou abstraktní modely, které popisují způsob prezentace a přístupu k datům. Datové modely definují datové položky a vztahy mezi nimi v konkrétní oblasti. Datový model je navigační nástroj pro podnikové i IT profesionály, který používá konkrétní sadu symbolů a slov k přesnému vysvětlení konkrétní třídy skutečných informací. To umožňuje lepší komunikaci v rámci organizace a vytváří tak flexibilnější a stabilnější prostředí aplikace.

Příklad modelu GIS pro vládu a místní vládu.

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, odstraněním vládních omezení a složitostí dodavatelských řetězců. Spolu se změnami v obchodním modelu se zvyšuje složitost a náklady na informační technologie potřebné k podpoře činnosti společnosti. Správa dat je obzvláště obtížná v prostředí, kde se podnikové informační systémy a funkční a obchodní požadavky na ně neustále mění.

Průmyslové datové modely jsou navrženy tak, aby pomohly usnadnit a zefektivnit tento proces a posunout přístup IT na moderní úroveň.

Průmyslové datové modely od společnostiEsri

Datové modely Esri ArcGIS jsou pracovní šablony pro použití v projektech GIS a pro vytváření datových struktur pro různé oblasti aplikací. Formování datového modelu zahrnuje vytvoření koncepčního designu, logické a fyzické struktury, kterou lze poté 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 průmyslových odvětvích. Esri strávil značné množství času s komunitou uživatelů, aby vytvořil řadu šablon, které mohou poskytnout rychlý start do návrhu podnikové geodatabáze. 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, je sémantický překlad 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ů
• Zachování administrativních hranic
• Vojenské zařízení. Zpravodajská služba
• Energie (včetně nového protokolu ArcGIS MultiSpeak)
• Ekologické struktury
• Ministerstvo pro mimořádné situace. Hasiči
• Lesní katastr
• Lesnictví
• Geologie
• Národní GIS (e-gov)
• Podzemní a odpadní voda
• 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í
• Městská správa
• Námořní navigace
• Státní katastr
• Ropné a plynové struktury
• Potrubí
• Rastrové úložiště
• Batymetrie, reliéf mořského dna
• Telekomunikace
• Doprava
• Zásobování vodou, kanalizace, bydlení a komunální služby

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

• jsou volně dostupné;
• nejsou vázány na technologii „vybraného“ výrobce;
• vytvořené v důsledku realizace skutečných projektů;
• vytvořené za účasti průmyslových odborníků;
• jsou navrženy tak, aby poskytovaly informační interakci mezi různými produkty a technologiemi;
• neodporují jiným normám a předpisům;
• používá se v dokončených projektech po celém světě;
• jsou navrženy pro práci s informacemi během celého životního cyklu vytvářeného systému, nikoli samotného projektu;
• rozšiřitelné podle potřeb zákazníka bez ztráty kompatibility s jinými projekty a / nebo modely;
• doprovázeno dalšími materiály a příklady;
• používané v pokynech a technických materiálech různých průmyslových společností;
• velká komunita účastníků, zatímco 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í skupiny odborníků nezávislých orgánů, které doporučují různé průmyslové modely, například PODS (Pipeline Open Data Standards for the oil and gas industry; PODS is currently being implemented as an Esri PODS Esri Spatial 5.1.1 geodatabase) or geodatabáze (GDB) od společnosti ArcGIS pro letectví, která zohledňuje doporučení ICAO a FAA, jakož i standard výměny 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 jsou S-57 a ArcGIS pro námořní (námořní a pobřežní prvky), stejně jako modely vytvořené z práce provedené Esri Professional Services a jsou de facto standardy v odpovídajících plocha. Například GIS pro národ a místní vládu ovlivnil standardy NSDI a INSPIRE a vodní a podzemní voda (hydrologie a podzemní voda) se hojně používají ve volně dostupných profesionálních sadách a komerčních produktech ArcHydro. třetí strany. Je třeba poznamenat, že Esri také podporuje de-facto standardy, jako je NHDI. Všechny navrhované datové modely jsou dokumentovány a připraveny k použití v podnikových procesech IT. Doprovodné materiály pro modely zahrnují:

• UML diagramy vztahů mezi entitami;
• 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ů pro načítání dat, příklady analytických nástrojů;
• referenční knihy o navrhované datové struktuře.

Esri shrnuje své zkušenosti s tvorbou průmyslových modelů do knih a lokalizuje publikované materiály. Následující knihy byly lokalizovány a publikovány společností Esri CIS:

• Architektura orientovaná na geoprostorové služby (SOA);
• Navrhování geodatabáz pro dopravu;
• Podnikové geografické informační systémy;
• GIS: nová energie pro elektrické a plynárenské podniky;
• Ropa a plyn na digitální mapě;
• Modelování našeho světa. Průvodce designem geodatabáze Esri;
• Přemýšlím o GIS. Plánování GIS: průvodce pro manažery;
• Geografické informační systémy. Základy;
• GIS pro administrativní a ekonomické řízení;
• Webový GIS. Zásady a aplikace;
• Systems Design Strategies, 26. vydání;
• 68 čísel časopisu ArcReview s publikacemi společností 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 ...„(translation) is a overall guide and reference for GIS data modeling in general, and a geodatabase data model specially. Kniha ukazuje, jak přijít se správnými rozhodnutími pro modelování dat, rozhodnutími, která jsou zahrnuta v každém aspektu projektu GIS, od návrhu databáze po sběr dat a dat do prostorové analýzy a vizualizace Podrobně popisuje, jak navrhnout geografickou databázi vhodnou pro projekt, konfigurovat funkčnost databáze bez programování, řídit pracovní tok v komplexních projektech, modelovat různé síťové struktury, jako jsou říční, dopravní nebo elektrické sítě, integrovat satelitní snímky do procesu geografické analýzy a zobrazení a vytvářet 3D modely dat GIS. Navrhování geodatabáz pro dopravu„obsahuje metodické přístupy, které byly testovány na velkém počtu projektů a plně vyhovují legislativním požadavkům Evropy a Spojených států i mezinárodním standardům. A v knize“ GIS: Nová energie pro elektrické a plynové elektrárny„Na příkladech z reálného světa ukazuje výhody, které může podnikový GIS přinést dodavateli energie, včetně aspektů, jako jsou zákaznické služby, síťové operace a další obchodní procesy.

Některé knihy, přeložené a původní, vydané v ruštině v nakladatelství Esri CIS a DATA +. Zabývají se jak koncepčními problémy souvisejícími s technologií GIS, tak mnoha aplikovanými aspekty modelování a nasazování GIS různých velikostí a účelů.

Uvažujeme o použití průmyslových modelů na příkladu BISDM (datový model vnitřního prostoru budovy, informační model vnitřního prostoru budovy) verze 3.0. BISDM je vývoj obecnějšího modelu BIM (Building Information Model) a je určen k použití při navrhování, konstrukci, provozu a vyřazování budov a konstrukcí z provozu. Používá se v softwaru GIS a umožňuje vám efektivně si vyměňovat geodata s jinými platformami a komunikovat s nimi. Odkazuje na obecnou skupinu úkolů FM (správa infrastruktury organizace). Uveď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ých pravidel pro řízení stavebních projektů;
• udržovat jednotné skladovací zařízení pomocí GIS po celou dobu životnosti budovy (od návrhu po vyřazení z provozu);
• koordinovat práci různých odborníků v projektu;
• vizualizovat plánovaný harmonogram a fáze výstavby pro všechny účastníky;
• poskytnout předběžný odhad nákladů a načasování výstavby (údaje 4D a 5D);
• sledovat postup projektu;
• zajistit kvalitní provoz budovy, včetně údržby a oprav;
• stát se součástí systému správy aktiv, včetně funkcí analýzy efektivity využití prostoru (leasing, sklad, správa zaměstnanců);
• vypočítat a řídit cíle energetické účinnosti 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 typů využití, položených komunikací, instalovaného zařízení, účtování oprav a údržby, událostí v těžbě dřeva, propojení s jinými aktivy 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 použity k izolaci entit a modelování na úrovni geodatabáze (geodatabáze) prostorových a logických vztahů všech fyzických prvků, které tvoří samotnou budovu i její vnitřní prostory. Dodržování zásad BISDM může výrazně zjednodušit úkoly integrace s jinými systémy. První fází je obvykle integrace CAD. Poté se během provozu budovy používá 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 / majitel zařízení end-to-end výměnu informací od myšlenky vytvoření objektu až po vypracování kompletního projektu, kontrolu stavby se získáním relevantních informací v době uvedení zařízení do provozu, kontrolu parametrů během provozu, a dokonce i během rekonstrukce nebo vyřazení zařízení z provozu. Po paradigmatu BISDM se GIS a geografická databáze vytvořená s jeho pomocí staly běžným úložištěm dat pro související systémy. V GDB se často objevují data vytvořená a provozovaná systémy třetích stran. Toto je třeba vzít v úvahu při navrhování architektury vytvářeného systému.

V určité fázi vám nahromaděné „kritické množství“ informací umožňuje přejít na novou kvalitativní úroveň. Například po dokončení fáze návrhu nové budovy je možné automaticky vizualizovat modely 3D průzkumu v GIS, sestavit seznam instalovaného vybavení, vypočítat počet najetých kilometrů inženýrských sítí, které mají být položeny, provést řadu kontrol a dokonce poskytnout předběžný finanční odhad nákladů na projekt.

Opět si všimneme, že když se BISDM a ArcGIS používají společně, je možné automaticky vytvářet 3D modely z nahromaděných dat, protože geodatabáze obsahuje kompletní popis objektu, včetně z-souřadnic, členství v podlaze, typů připojení prvků, metod instalace zařízení, materiálu, dostupných cest pohyby 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 existuje potřeba dalšího informačního obsahu pro:

• umisťování 3D modelů předmětů a zařízení na určená místa;
• shromažďování informací o nákladech na materiály a postupu jejich pokládky a instalace;
• terénní kontrola podle rozměrů instalovaného nestandardního vybavení.

Díky použití ArcGIS je snazší importovat další 3D objekty a reference z externích zdrojů, protože ArcGIS Data Interoperability vám umožňuje vytvářet postupy pro import takových dat a jejich správné umístění v 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é obchodní oblasti:

• IBM Banking and Financial Markets Data Warehouse (finance)
• IBM Banking Data Warehouse
• Procesy bankovnictví IBM a modely služeb
• IBM Health Plan Data Model (zdravotní péče)
• IBM Insurance Information Warehouse (pojištění)
• Procesy pojištění a služby IBM
• IBM Retail Data Warehouse (maloobchod)
• IBM Telecommunications Data Warehouse (telekomunikace)
• {!LANG-8711ed7c9dc7fce2383e0316334ff41f!}
  {!LANG-12286040cadd586f3f94f92b1e3e41c8!}
  {!LANG-eac4a75bed93e6956b0b1a2bd7a7ca51!}
  {!LANG-76424af7a091cb7562b1abbc58797e05!}

{!LANG-7a30eed54dd6ecb84296921d07592f18!} IBM{!LANG-796c6739fa07f3edca6a03b61b20855b!}{!LANG-3e9ddeb7e698a4a5a5ec158ed2df5bf2!}{!LANG-7a6bb5774c5c6232e77d262eae2b3549!}{!LANG-9704cb70bc6adbd32ccaa00e8cfdd810!}{!LANG-8e0421401db22a930150410f6a03bb3f!}{!LANG-d8bf68ab437deb80f62e89bc5e33f283!}{!LANG-cd86323714324f6c45ccbcd1136e6590!} IBM{!LANG-796c6739fa07f3edca6a03b61b20855b!}{!LANG-34a9c6daa63bf06ac35539cfe85074ea!}{!LANG-3e9ddeb7e698a4a5a5ec158ed2df5bf2!}{!LANG-804e75256d494f5b3a7837d5efb8a562!}{!LANG-ed7ef8130e72d06d20ff949acb2fd224!}{!LANG-7b640723844f0988b9d330650d0f5b57!} IBM{!LANG-031b845f225dc2d5f21757dc66d14f4b!}{!LANG-2d7b38a5c4ba944875119ec3a0a20208!}{!LANG-725bc684d391069c165a77b79eab2961!}{!LANG-73365e38bf2b65234d77914e34d9fae0!} IBM{!LANG-cb5723294fc4228707c04c10b4578fa2!}{!LANG-8e0421401db22a930150410f6a03bb3f!}{!LANG-901eb34d02816f603a4700d095432164!}{!LANG-997b94d224a2dcb6e7f82192746b4ba0!}{!LANG-c30ba869c51835e1d9149af3ab103705!}

{!LANG-0353c0216db1ba313c41633689608ca2!} {!LANG-158e98370926ea2faf0fb8c6f8ae7dcc!}{!LANG-cc2644c6ae62f2bc72abbd9bd8a097d6!} {!LANG-5a351004b5a9558345f4de890a9c4ae7!}{!LANG-6b756af2eeec8bda337b84491172e340!} {!LANG-927c5d8c825e19a5b0aae6bcfa3df776!}{!LANG-8616a1a43245d9f73e544ee1c2108c97!}

{!LANG-b670eb7460fbaf54a7b0f4c12332823f!}

{!LANG-01ec679224f044daa1b2ba259fa9324c!} {!LANG-da48f86c99bca67cff2bf5a5ce566627!}{!LANG-81626e5cce71522e2474674f35098443!}

{!LANG-06bea9e322e6e677e3ae7fd7dec2016f!}{!LANG-5e2faf5b8ad2a1c9b45f2a6ccdd03bc6!}

{!LANG-35135152fbe1404f847be0115db4166e!}

Závěr

{!LANG-c79a5260b8c94d6c5bcc0c2f22ab829b!}

{!LANG-c511c3c9e1f360488a13f0660d8b5a6f!}

Účel přednášky

Po prostudování materiálu této přednášky budete vědět:

• co podnikový datový model ;
• jak převést podnikový datový model do modelu datového skladu;
• základní prvky podnikový datový model ;
• podnikové datové modely prezentační vrstvy ;
• algoritmus pro transformaci podnikového datového modelu na model vícerozměrného datového skladu ;

a naučit se:

• vyvíjet modely datových skladů na základě podnikový datový model organizace;
• navrhnout hvězdné schéma pomocí nástrojů CASE;
• tabulky oddílů vícerozměrný model pomocí nástrojů CASE.

Podnikový datový model

Úvod

Jádrem každého HD je jeho datový model. Bez datového modelu bude velmi obtížné uspořádat data v HD. Vývojáři HD by proto měli věnovat čas a úsilí vývoji takového modelu. Vývoj modelu HD spadá na bedra návrháře HD.

Ve srovnání s návrhem systémů OLTP má metodika návrhu CD řadu charakteristických rysů spojených s orientací datových struktur úložiště k řešení problémů analýzy a informační podpory rozhodovacího procesu. Datový model HD by měl poskytnout efektivní řešení přesně těchto problémů.

Výchozím bodem při návrhu CD může být tzv podnikový datový model{!LANG-1289f766e8fdd80734df2f01e01aba61!} podnikový datový model obvykle se pokusí vytvořit datovou strukturu založenou na obchodních operacích, která by shromažďovala a syntetizovala všechny informační potřeby organizace.

Takto, podnikový datový model obsahuje informace potřebné k sestavení modelu CD. Proto v první fázi, pokud takový model v organizaci existuje, návrhář HD může zahájit návrh HD řešením problému transformace podnikový datový model do HD modelu.

Podnikový datový model

Jak vyřešit problém transformace podnikový datový model do HD modelu? Chcete-li tento problém vyřešit, musíte mít tento model, tj. podnikový datový model by měl být postaven a zdokumentováno... A musíte to pochopit co z tohoto modelu a tak jako by se měl transformovat na model HD.

Pojďme si vyjasnit koncept z pohledu designéra CD podnikový datový model. Pod podnikový datový model{!LANG-f3509c2b7e7998d25bc19a8a5488ec4b!} podnikový datový model je soubor modelů různých úrovní, které charakterizují (model na nějaké abstraktní úrovni) činnosti organizace, tj. obsah korporátní model přímo závisí na tom, jaké modelové konstrukce byly do dané organizace zahrnuty.

Hlavní prvky podnikový datový model jsou:

• popis tematických oblastí organizace (definice oblastí činnosti);
• vztahy mezi výše definovanými tematickými oblastmi;
• {!LANG-4d1332bf2368f31617b04d2f3fc9fc7a!}
• popis pro každou oblast:
  • klíče entit;
  • atributy entity;
  • {!LANG-636f2707adbc682214fb017108d4c1bf!}
  • vztahy mezi entitami;
  • atributy seskupení;
  • vztahy mezi tematickými oblastmi;
• funkční model nebo model obchodního procesu;
• diagramy toku dat;
• stavové diagramy;
• jiné modely.

Takto, podnikový datový model{!LANG-9a1ecb1118b6a3eb749787b4f19ae706!} podnikový datový model.

Úrovně prezentace podnikového datového modelu

{!LANG-f5b136d986264e6a319d767cfa0844f5!}{!LANG-8ff35a5b26e8724f12755f86b4e452f9!}

Každý logický model musí odpovídat existující doméně podnikový datový model... Pokud logický model tento požadavek nesplňuje, je nutné k němu přidat doménový model.

{!LANG-f5b136d986264e6a319d767cfa0844f5!}{!LANG-75356179a77370443b16f808fa33363a!} vysoká úroveň (vysoká úroveň) podnikový datový model{!LANG-7b28aa884fe7a2252f5fc49342a486bc!} podnikový datový model nejvyšší úroveň.

Postava: 16.2.

Schéma zobrazené na obrázku představuje čtyři tematické oblasti: „Kupující“ ( Zákazník), "Skóre" ( účet), "Objednat" ( Objednat) a „Produkt“ ( Produkt). Zpravidla pouze na nejvyšší úrovni pohledu modelu přímé spojení mezi tematickými oblastmi, které například zaznamenávají následující skutečnost: kupující zaplatí fakturu za objednávku zboží. Podrobnosti a nepřímé vztahy na této úrovni korporátní model nezobrazeno.

Na další, střední úroveň (střední úroveň) podnikový datový model jsou zobrazeny podrobné informace o objektech tematických oblastí, tj. klávesy a atributy entity{!LANG-cae4983cf33aa29c0a33a0ba465d6747!} korporátní model pro fragment předmětové oblasti „Objednávka“.

{!LANG-685354aa9901dcc6f9217f91d2ec9eca!} Objednat) zahrnuje několik entit definovaných prostřednictvím jejich atributů a vztahů mezi nimi. Představený model umožňuje odpovědět na otázky, jako je datum objednávky, kdo objednávku provedl, kdo objednávku odeslal, kdo objednávku přijal a řada dalších. Z výše uvedeného diagramu je patrné, že v této organizaci existují dva typy objednávek - objednávky na povýšení ( Commersial) a maloobchodní objednávky ( Maloobchodní).

všimněte si, že podnikový datový model může představovat různé aspekty činnosti organizace as různou mírou podrobnosti a úplnosti. Li korporátní model představuje všechny aspekty činnosti organizace, je také nazýván datový model organizace{!LANG-048d9ec1dce397a8affb916412439b38!}

Z pohledu HD designu je to důležitý faktor při rozhodování o vytvoření HD modelu z podnikový datový model je stát úplnost podnikový datový model.

{!LANG-f5b136d986264e6a319d767cfa0844f5!}{!LANG-02ef15588af504b9ae0ffa1b3bd3b3e6!} podnikový datový model mohou být dobře vyvinuté, pro některé práce ještě možná nezačaly. Pokud v části nebyl zpracován fragment předmětné oblasti podnikový datový model, pak neexistuje žádný způsob, jak tento model použít jako výchozí bod pro návrh CD.

Stupeň dokončení korporátní model lze v designu CD srovnat následujícím způsobem. Vzhledem k tomu, že proces vývoje HD je obvykle rozdělen v čase do posloupnosti fází, lze proces jeho návrhu synchronizovat s proces dokončení vývoj jednotlivých fragmentů podnikový datový model organizace.

Na nejnižší prezentační vrstva podnikového datového modelu informace o fyzických vlastnostech databázových objektů odpovídajících logický datový model střední prezentační vrstva podnikového datového modelu.

{!LANG-3333e6b1e9331384b91ff9c440fa1f35!}

{!LANG-c39a297b6426c8a2ab9ebaee59a436dd!}

{!LANG-0681667aacee13ec64d5d0a616b48fe8!} {!LANG-f517578066bfc388290aa7857be71d10!}

• {!LANG-b0e28c9a5cd9b83ad6d4f760a83a5a36!}
• {!LANG-d991cfcb4f29359daae0616fdf51af53!}
• {!LANG-a378ecb07351536d6054069baef8be5d!}
• 2. {!LANG-872e7882066b3cab641486a441682f8f!}
• {!LANG-1ad5aa5905501c7c974d5ec6eb23bf1c!}

{!LANG-aa4b12fd6885ec083bc6c5f2479113bc!}

{!LANG-83466002822c888bc501186d14bf6da0!}

{!LANG-8ba1b8160aec9ecd34d81286649201c8!}

{!LANG-a4d6e6b0a4dfc5830f46bb5d9e6551ce!}

{!LANG-a3ebadea3aad7a911909db545ebaa6d9!}

{!LANG-da175a532f5fe0d3fddb4240338bf627!}

{!LANG-d9cd2a55fc54d80977fd11fe9fe55c6d!}

{!LANG-5e7d00d840a0215c92c4cf3bc9dd32b2!}

{!LANG-b6633fe362b34cca4a2e17fe58fdc66b!}

{!LANG-69b92cc7e081f61ada2251ceed96840b!}

{!LANG-49d04d5f4a5c833b053a3bb2ac470a13!}

{!LANG-6a90820b31ccd07d853db16c797a9f51!}

{!LANG-d22a1fe6bbbbfe05c4a1a96fe40b2dc3!}

{!LANG-972866f8c875bc35cbc67b6e7c1e8aa6!}

{!LANG-df17c9e0f2bcf0d9e71a28b1698f94ed!}

{!LANG-34604a3a93603ac848106782409d6667!}

{!LANG-fb3707efd09446e86377fdfb42c6a4cb!}

{!LANG-2f6c4470ad0c19aa32e4aa8d43163364!}

{!LANG-d40cdd8e39b1a70663da8ab33f207ea6!}

{!LANG-7ea928982eeff54ed19b7ad73c3810ff!}

{!LANG-8b23719b20ad87f64675c8d2a65e28a7!}

{!LANG-352fb6ec398aa7b78eeb25b57ee7e7a8!}

{!LANG-ef6844071ef234a2bfe51d0e7e6caa90!}

{!LANG-5d57281d042a86341e7e13e1f8b06f39!}

{!LANG-3bc00d570a947cbd23805f10b2947811!}

{!LANG-0fa2694bbc71f3175d4594a5e0088cb4!}

{!LANG-80bb1c0b2f89c02707b8610caeb3ff53!}

{!LANG-7403b3d6a00e19f2bf2e46200fb7ab86!}

{!LANG-374269e1292b0c9914a0a618c3111a30!}

{!LANG-f642331168861e5b250cc670018c8fa4!}

{!LANG-8beba4e5b513ab3eb61414e25afb07a2!}

{!LANG-8531b1c53ca98624a49a16bca3a097a6!}

{!LANG-c020ba5e0d8c56df6ab6ea77eb978582!}

{!LANG-05633c745865f6ea2003e982686225aa!}

{!LANG-eb5ea1d03e15dcce3760bca78446e11f!}

{!LANG-e328adc7a12f86825689745bc3f318f8!}

{!LANG-c5ac75001e3a7170a85e5ba6431a21c6!}

{!LANG-ed1f3d0ca6e14ed472b7ea9408a0a5d2!}

{!LANG-b90666afca938faaeb07a4a253c68bab!}

{!LANG-5e36c343df6a80063220a5aed11554d0!}

{!LANG-1f624bbdb7c2be529c5b8b4648fc7aae!}

{!LANG-344d938e71a755c385a2d79bc844391c!}

{!LANG-6e61d656c0d3b346214e6c06bf09ddaa!}

{!LANG-0532b993290df2d91ccfe1bfaabdd031!}

{!LANG-1e252e2adec40791114d00c71b18561c!}

{!LANG-9ca18aec32af3361ad96104a211a7c3e!}

{!LANG-d99b2cac0aa06a5959438682b791773f!}

{!LANG-340fcfc98ae8c4901df12a901adb97e7!}

{!LANG-5dc416bae208e6a2e9082f8f643a31f1!}

{!LANG-d2dd740712a8eeb58cbed342a39f37c9!}

{!LANG-68a1bcc0d7b3f3a9bd2b5cafee053673!}

{!LANG-fd5d3d6edf8afa8d9e5fc368eb6140b3!}

{!LANG-2c8c63736aaebe7bfe706b6537990dba!}

{!LANG-082245e0b16e3379c1fd79db3b509b92!}

{!LANG-d01ef7a71cecc6d4b4ca625bb183360e!}

{!LANG-74a92b8b994caa3e43d699a78f71ac6c!}

{!LANG-c1cba907837c27035f04853157663849!}

{!LANG-9e042c85ce082e810640a65c1e17b4f2!}

{!LANG-de86eaee0ab4364a28952b65a9386a12!}

{!LANG-508cc39de5e9b4443fd36b4193e0f647!}

{!LANG-9dc6a88870a04b836308fda6a2e678aa!}

{!LANG-febbdfebd5878d4afe1a84088e5d7f04!}

{!LANG-99d589b7085ba2e4a7b32645b82cedcf!}

{!LANG-b761eebb2f77e8a1e41d8c8402ab9eff!} {!LANG-417be0c615b6404558e834cacbef3f25!}{!LANG-6264a3c824585d417cc466b7192dbb9e!}

{!LANG-f8b9dbd1c17199fb962cc7e055451cb8!}

{!LANG-811bcf5e132d028b869435eb4ef9fb90!}

{!LANG-79afb6a4ba30184eb7e1d9bee572092f!}

{!LANG-7f8420f3cb25a55f39830439997b8d39!}

{!LANG-eb0c6ecd0efd00209124d0f6cadae755!}

{!LANG-693709c12c34b5defa6f34a53209d6dc!}

{!LANG-c0a5a5fec26eb949ad0f7f22801ba3c1!}

{!LANG-e12a0cd276268f8b0addf9a94acb57b3!}

{!LANG-b9751d0c8b39851642df48339e030187!}

{!LANG-3078450320dd615101afc40f0a82ccd4!}

{!LANG-bafc2d30dce595b9f46f9d6485e2f8a1!}

{!LANG-ae4abe9c1498a53feb05413230f16626!}

{!LANG-a8b80e630a220093702e736bf16aba20!}

{!LANG-32f861f1b35e7b556492148235f3cffa!}

{!LANG-7e2e799205c172d320338f7fdfebee97!}

{!LANG-41b166837d8381c710b52f1ff7bbab8f!}

{!LANG-e4589413a8a7be043b56925a5fed83b1!}

...

{!LANG-2315defc5e8fbf7be03badaab0f522f9!}

{!LANG-e84afb0b8365829a33003ab3023b6aba!}

{!LANG-2bde2f4b07cb26c0c0783e3af2337a9b!}


{!LANG-b3bcfbdbdba6ecc21f55da6b0d3501e0!}

{!LANG-eb7a98640658aef9110e17ed40f430fd!}


{!LANG-41ca2bf1f6fb6a835e1d0b293755e3a3!}

{!LANG-481f3c2f16b860f12fdfa44f70142cb3!}


{!LANG-5ce989c9b48ed31fe04bc3994fc9d917!}

{!LANG-85905362a0165ae373a19f01ef88bcc9!}


{!LANG-9c5c59e48f5ff266a0d5d99b71e43414!}

{!LANG-9842baed3d31dd7b1bdb90356bf14a12!}


{!LANG-ae54a333df78f8040a68420c92fe78e4!}

{!LANG-199faeb261997ea9f2aa3187d3457647!}


{!LANG-af6ff049a5ecf49af92dc6138b89c004!}

{!LANG-b9666305e264ad9c0f6cec0c4344f2ad!}


{!LANG-63f83efbb26b63f310040474f016417d!}

{!LANG-06390cda217927a1a71195ae736c98d8!}


{!LANG-e34592f3258248039d8d15f4484f7610!}

{!LANG-591a1ee818b97a14e4ab2879975443c0!}


{!LANG-8c40e64b1ec72067abf6def4d8265ab8!}