Účely použití databází. Organizace databáze

Úvod

Široké využití systémů zpracování informací v různých oblastech manažerské činnosti, pro řešení složitých ekonomických problémů a provádění vědeckého výzkumu určuje zvýšené požadavky na efektivitu organizace dat v podmínkách kolektivního využití.

Tradiční způsob organizování dat ve formě polí zaměřených na konkrétní úlohy se vyznačuje statickou povahou, rigidní vazbou na odpovídající software, vede k duplicitě při hromadění a ověřování dat, způsobuje značné plýtvání pamětí pro jejich ukládání, častou reorganizaci dat při změna úkolů atd.

Jedním z hlavních způsobů, jak tyto nedostatky překonat, je vytvoření databází, které zajistí udržování dynamického informačního modelu komplexních spravovaných objektů a procesů v systému a kolektivní přístup k němu.

1. Organizace databáze

Databáze (DB) je definována jako soubor vzájemně souvisejících dat charakterizovaných: schopností být použit pro velké množství aplikace; schopnost rychle získat a upravit potřebné informace; minimální redundance informací; nezávislost na aplikačních programech; běžná, kontrolovaná metoda vyhledávání.

Možnost použití Databáze pro mnoho uživatelských aplikací zjednodušuje implementaci složitých dotazů, snižuje redundanci a zvyšuje efektivitu využívání informací v systémech zpracování dat. Minimální redundance a schopnost rychle upravovat udržovat data na stejné úrovni aktualizace. Nezávislost dat a aplikačních programů, které je používají, je hlavní vlastností databáze. Datová nezávislost znamená, že změna dat nemění aplikační programy.

Tradiční forma organizace databáze, která zajišťuje takovou nezávislost, je tříúrovňová struktura: logická datová struktura aplikačního programátora (subschéma); obecná logická, datová struktura (schéma); fyzická datová struktura.

Databázová schémata a podschémata jsou často zobrazována jako diagramy. Na Obr. Obrázek 1 ukazuje obecné schéma logické struktury databáze a dílčích obvodů dvou aplikačních programátorů, kteří mají různé představy o datech. Plné čáry představují spojení v diagramu. Jednoduchá spojení jsou označeny jednou šipkou, vztahy jedna k mnoha jsou označeny dvojitou šipkou. Přerušované čáry představují křížové odkazy. Přítomnost křížových odkazů vám umožňuje vyhnout se opakování záznamů DODAVATEL a SPECIFIKACE - ŠARŽE - PRODUKT v každém záznamu POLOŽKY NÁKUPU.

Vytvoření databáze není jednorázový proces, ale probíhá po celou dobu její existence. Tříúrovňová organizace poskytuje možnost rychle měnit strukturu databáze v kontextu údržby a úprav řídicích systémů a navyšování uživatelských úkolů i v podmínkách zlepšování a rozšiřování hardwaru. Tříúrovňová organizace zajišťuje vzájemnou nezávislost na změnách obecné logické struktury databáze a aplikačních programů (logická datová nezávislost) a možnost měnit fyzické umístění a organizaci dat beze změny obecné logické datové struktury a datových struktur aplikace. programátoři (fyzická nezávislost).

2. Systémy pro správu databází

Použití systémů správy databází (DBMS) umožňuje vyloučit popis dat a podrobné programování správy dat z aplikačních programů. Popisy jsou nahrazeny odkazy na obecnou logickou datovou strukturu a řídicí programování je nahrazeno příkazy pro manipulaci s daty, které jsou vykonávány univerzálním softwarem.

Hlavní funkcí DBMS, spolu s aktualizací dat, je zpracování uživatelských požadavků na vyhledávání a přenos dat do aplikačních programů. Například posloupnost základních akcí implementovaných DBMS v procesu čtení záznamu sestává z následujících operací: aplikační program vydá požadavek DBMS na přečtení záznamu, který obsahuje hodnotu segmentu nebo klíče záznamu; DBMS hledá v podobvodu aplikačního programu popis dat, pro která byl požadavek vydán; DBMS pomocí běžného logického datového schématu určuje, jaký typ logických dat je potřeba; Na základě popisu fyzické organizace dat DBMS určí, který fyzický záznam je třeba přečíst; Problémy s DBMS operační systém příkaz k přečtení požadovaného záznamu; operační systém načítá data do systémových vyrovnávacích pamětí; Na základě porovnání schématu a podschématu, DBMS extrahuje informace požadované aplikačním programem; DBMS přenáší data ze systémových vyrovnávacích pamětí do pracovního prostoru aplikačního programu.

Akce, které DBMS provádí při aktualizaci dat, jsou podobné operacím čtení. DBMS provede potřebné transformace dat v systémových bufferech, opak transformací, které byly provedeny při čtení dat. Systém správy databází poté vydá operačnímu systému příkaz WRITE. Obecná architektura systému správy databází je znázorněna na Obr. 2. Je vlastní všem DBMS, které se liší omezeními a možnostmi pro provádění odpovídajících funkcí.

Proces porovnávání a výběru takových systémů pro konkrétní aplikaci spočívá v přizpůsobení jejich schopností specifickým požadavkům a omezením uživatele.

Pro práci se systémem správy databází potřebujete několik jazyků: programovací jazyky, jazyky pro popis obvodů a podobvodů, jazyky pro popis fyzických dat. Aplikační programátor používá programovací jazyky pro psaní programů (COBOL, FORTRAN, PL/1, ASSEMBLY) a nástroje pro popis dat - jazyk pro popis dílčích obvodů. Jazyk pro popis podschéma může být prostředkem pro popis dat v programovacím jazyce, prostředkem poskytovaným DBMS nebo nezávislým jazykem pro popis dat. Mnoho DBMS používá k popisu dat programovací jazyky. Pro aplikačního programátora musí DBMS poskytovat prostředky pro přenos příkazů a interpretaci zpráv vydávaných systémem. Rozhraní mezi aplikačním programem a DBMS – jazykem pro manipulaci s daty – je zabudováno do programovacího jazyka. Záznam je požadován v jazyce pro manipulaci s daty a načten do pracovního prostoru aplikačního programu; podobně, když zahrnete záznam do databáze, aplikační program jej umístí do pracovní oblasti a vydá příkaz v jazyce pro manipulaci s daty. Typické příkazy jazyka pro manipulaci s daty jsou: otevřít soubor nebo sadu záznamů; zavřít soubor nebo sadu záznamů; najít a přečíst zadanou kopii záznamu; předat obsah specifikovaných datových prvků z konkrétní instance záznamu; nahradit hodnotu určitých prvků zadané instance záznamu hodnotami z pracovního prostoru programu; vložit záznam z pracovního prostoru do sady záznamů; odstranit konkrétní instanci záznamu ze sekvence záznamů; zapamatovat si novou instanci záznamu v databázi; odstranit konkrétní instanci záznamu z databáze; přeuspořádat záznamy ve skupině v sestupném nebo vzestupném pořadí podle zadaného klíče.

Systémový programátor používá jazyk k popisu celkového logického datového obvodu. Tímto jazykem může být rozšíření programovacího jazyka, nástroj DBMS nebo nezávislý jazyk. K popisu rozložení dat používá systémový programátor nějakou formu jazyka fyzického popisu dat. Tento jazyk definuje umístění dat na fyzická zařízení, řízení vyrovnávací paměti, metody adresování a vyhledávání.

Při vzniku nových úkolů v systému managementu souvisejících se zpracováním velkých objemů informací vzniká problém zvolit metodu organizace dat, která zajistí jejich řešení. V tomto případě je nutné zvážit možné způsoby organizace dat a efektivita jejich použití k řešení problému: organizace dat ve formě souborů; použití existující databáze (beze změn obecného logického datového schématu); vývoj nového logického databázového schématu s využitím univerzálního DBMS; vývoj databáze a speciálního DBMS.

Jakákoli analýza nezbytná k vyhodnocení a výběru databáze organizace musí začít důkladným prozkoumáním potřeb uživatele. Na základě studie požadavků uživatelů byste měli sestavit úplný seznam data, která mají být uložena, s uvedením jejich charakteristik a vztahů, seznam procesů a uživatelů interagujících s databází, uvedení jejich priorit a nastavení parametrů přístupu k datům, formulování požadavků na čas a náklady na přístup k databázi. Kromě toho je nutné analyzovat dostupný hardware (velikost hlavní paměti procesoru, konfiguraci operačního systému, s ohledem na média pro přenos dat, dostupné zdroje a možnosti rozšíření externí paměti), jakož i počet a kvalifikace systémových a aplikačních programátorů.

Pokud je potřeba uspořádat data k vyřešení řady aplikované problémy v případě neexistence funkční databáze by měla být posouzena proveditelnost použití databázového konceptu k řešení zadaných problémů. Základem pro použití databáze jsou následující faktory: výrazné překrývání datových polí, duplikace akumulace a ověřování dat, nutnost řešit problém konzistence prvků; významný počet spotřebitelů informací; značný počet typů požadavků; relativní stálost nomenklatury žádostí. Zároveň je třeba při rozhodování o organizaci databáze pamatovat na to, že její vytvoření může vést ke snížení efektivity jednotlivých aplikačních programů a dotazů, neboť účelem organizace databáze je zvýšení efektivity celého systému. .

Když se v řídicím systému s fungující databází objeví nové úkoly, měla by být posouzena možnost použití společné datové struktury pro popis předmětných oblastí, tzn. soubor objektů a procesů nových uživatelů v jazyce podschémat fungující databáze nebo v případě potřeby úpravy stávajícího obecného logického schématu odhadnout náklady na provedení nezbytných změn a dopad těchto změn na Obecná charakteristika systému z hlediska uspokojování potřeb všech uživatelů systému.

Pokud se rozhodne vyvinout novou databázi, vyvstává úkol vybrat si univerzální nebo vyvinout specializovanou DBMS a navrhnout její obecnou logickou a fyzickou strukturu a volba DBMS je zpravidla základem pro návrh a organizace logických a fyzických struktur databáze.

Stávající DBMS poskytují tři hlavní přístupy ke správě dat: hierarchický, síťový a relační (obr. 3). Hierarchický přístup je založen na reprezentaci hierarchie objektů. Hierarchické vztahy jsou přímo podporovány ve fyzickém návrhu DBMS. Hierarchické vztahy jsou speciálním případem síťových vztahů. Dodavatel může například dodávat několik druhů zboží a každý druh zboží může mít několik dodavatelů. Relační systémy nerozlišují mezi objekty a vztahy. Síťové a hierarchické vztahy mohou být reprezentovány ve formě dvourozměrných tabulek nazývaných vztahy a majících následující vlastnosti: každý prvek tabulky představuje jeden datový prvek (neexistují žádné opakující se skupiny); prvky sloupce jsou stejné povahy, sloupcům jsou jednoznačně přiřazena jména; v tabulce nejsou dva stejné řádky; řádky a sloupce lze prohlížet v libovolném pořadí, bez ohledu na jejich informační obsah. Databáze vybudovaná pomocí vztahů se nazývá relační a v ideálním případě má následující výhody: možnost použití neškolenými uživateli; jednoduchost bezpečnostního systému (pro každý vztah je specifikována legálnost přístupu); nezávislost na datech; možnost stavby jednoduchý jazyk manipulace s daty pomocí relační algebry.

Při výběru univerzálního DBMS pro implementaci specifické sady aplikačních programů založených na použití databáze byste měli vyhodnotit jazyk popisu dat poskytovaný uživateli, jazyk pro manipulaci s daty a prostředky údržby fyzické databáze. Obvykle se rozlišují vlastnosti, které definují jazyk popisu dat: přehlednost, snadnost studia, stupeň nezávislosti dat, postupy ochrany před neoprávněným přístupem, popisné prvky (datové typy, velikost a název atd.), podporované vztahy (hierarchické, síťové , vztahový) . Mezi charakteristikami jazyků pro manipulaci s daty je třeba zdůraznit následující: reprezentované prostředky přístupu (ve fyzické posloupnosti, hodnotou datového prvku, klíčem), kompatibilita se základními (vysokoúrovňovými) programovacími jazyky, snadnost učení a využití, datová nezávislost, možnosti a prostředky současného využití databáze několika aplikačními aplikacemi.

3. Výběr DBMS

Provádí se s ohledem na potřeby uživatele pomocí jedné z následujících metod: analýza proveditelnosti, experimentální ověření, simulace a modelování.

Metoda analýzy schopností je založena na bodování výše uvedených charakteristik SŘB z pohledu požadavků uživatele. Každá charakteristika je studována ze dvou hledisek – zda ​​je přítomna v navrhovaném DBMS a jaká je její kvalita. Kvalita je hodnocena podle standardní stupnice. Koeficient pořadí se vynásobí vahou přidělenou dané složce a sečte se skóre vážená pro každou složku.

Experimentální metoda ověřování spočívá ve vytvoření specifického aplikačního prostředí a jeho použití k získání provozních charakteristik daného hardwarového a softwarového systému. Pro experimentální ověření je nutné navrhnout a načíst generickou databázi; poté pomocí jazyka pro manipulaci s daty DBMS modelujte požadavky na zpracování stávajících a očekávaných aplikačních programů a proveďte experimentální test uvažovaného DBMS.

Při metodě simulace a modelování provozu DBMS se používají matematické výrazy, které určují závislost jednoho z parametrů na ostatních. Doba přístupu může být například reprezentována jako funkce počtu přístupů na disk, množství přenesených informací a času procesoru generování odpovědi na požadavek. Protože uvedené parametry závisí na způsobu ukládání dat a způsobu přístupu k nim, vyžadují různé DBMS různé modely. Jakmile jsou tyto modely vyvinuty, lze je použít k odhadu doby zpracování a nákladů při použití různých DBMS specifikací různých podmínek (změna velikosti databáze, přístupových metod, poměrů blokování atd.).

Nekvalifikovaný návrhář může uplatňovat omezení na konkrétní DBMS na začátku procesu návrhu databáze. Uživatelské požadavky jsou v tomto případě uměle specifikovány hierarchickými a síťovými strukturami konkrétního DBMS bez uvažování jiných možných konstrukčních řešení. Tento přístup může vést ke snížení účinnosti systému.

Níže jsou uvedeny stručná charakteristika nějaký univerzální DBMS.

INES DBMS se zaměřuje na řešení problémů vyhledávání informací především pomocí dialogu. Poskytuje možnost rychlého přístupu k databázi za účelem získání referenčních dat a efektivního zobrazení velkých objemů dat při sestavování souhrnů a při generování počátečních polí pro řešení ekonomických problémů.

Systém umožňuje přístup k datům z uživatelských aplikačních programů napsaných v ASSEMBLY, PL/1, COBOL, ALGOL-60, FORTRAN-4.

Používají se speciální vstupní jazyky (jazyk pro vstup ekonomických ukazatelů, jazyk pro zadávání dokumentů) a dotazovací jazyky, které splňují základní požadavky na jazyky pro popis dat a jazyky pro manipulaci s daty.

Pro práci s daty, která mají hierarchickou strukturu, se používá speciální přístupová metoda. INES DBMS disponuje systémem pro generování výstupních zpráv a systémem pro vizualizaci zpráv, které uživateli umožňují nastavit strukturu dokumentu a jeho detaily, vyhledávat, měnit a opravovat údaje a zobrazovat je na displeji.

KVANT-M DBMS je systém pracující v reálném čase navržený pro provoz na minipočítači a používaný k řešení problémů v informačních a referenčních systémech (fakografické, bibliografické, rezervace objednávek atd.).

Uživatelské programy lze psát v COBOL, FORTRAN, BASIC-2 a přistupovat k databázi pomocí CAM rozhraní.

KVANT-M DBMS podporuje databázi sestávající ze sady polí (souborů). Položky pole mají stejnou strukturu a jedinečné sekvenční číslo (ISN). Záznamy se skládají z polí, která jsou nejmenší jednotkou dat v databázi. Pole může být deklarováno jako klíč. Pro popis dat v souborech je vytvořeno schéma obsahující názvy polí záznamu, jejich typ a znak označující, zda je pole klíčem. Pro uživatele, ke kterým mají přístup, je vytvořeno jedno nebo více podschémat.

Fyzická datová struktura používá obrácené seznamy klíčových hodnot a zajišťuje, že adresování je nezávislé na fyzickém umístění dat. Systém poskytuje následující typy přístup: sériový přes ISN; v logickém sledu; NA ZNAMENÍ.

Jazykem pro manipulaci s daty je jazyk KVANT SCRIPT-M. Je to konverzační jazyk podobný angličtině, který je navržen tak, aby efektivně vyhledával a zvýrazňoval záznamy v databázi a zobrazoval je.

V poslední době se výroba vysokorychlostních osobních počítačů s velkými provozními a externí paměť, s možností jejich spojení do lokální sítě. Pro tyto počítače se objevovaly a objevují univerzální DBMS, které uživateli poskytují nástroje a vymoženosti, které jsou někdy bohatší než u minipočítačů a sálových počítačů. Tento proces ještě nebyl zaveden, a proto nemá smysl uvádět v učebnici charakteristiky těchto SŘB.

4. Specializované databáze

Proces návrhu specializované databáze zahrnuje: logický návrh, fyzický návrh, vývoj specializovaného DBMS.

Logický návrh zahrnuje analýzu. požadavky, modelování dat aplikačního programu a jejich integrace, vývoj logického obvodu. Analýza požadavků uživatelů se provádí standardními metodami systémové analýzy: dokumentace, průzkum, simulované zprávy. Analýza požadavků vytváří systematické datové soubory a specifikace zpracování pomocí standardních definic dat, které minimalizují nekonzistence ve vyvinutých specifikacích.

Datový model je navržen tak, aby reprezentoval uživatelské prostředí. Vzhledem k tomu, že databáze je vytvořena pro mnoho uživatelů, je integrační fáze navržena tak, aby vyřešila konflikty mezi požadavky uživatelů během procesu modelování.

Ve fázi vytváření diagramu je nutné uživatelské modely sloučit do jednoho, ze kterého lze odlišit všechny alternativní pohledy. Úkolem syntézy optimální logické struktury databáze je určit optimální logickou strukturu ve smyslu přijatého kritéria, zajišťující realizaci množiny požadavků všech uživatelů systému. Mezi kritérii používanými pro syntézu logické struktury databáze lze vyzdvihnout minimální náklady na ukládání, aktualizaci a přenos informací po určitou dobu, minimum celkových informačních toků, minimální množství uložených informací, minimální náklady na aktualizaci. informace, maximální rychlost, maximální spolehlivost. Pokud specifikace požadavků a datové modely nezávisí na DBMS, pak schéma databáze je jeho popis v jazyce pro popis dat. Kromě schématu jsou vyvíjeny popisy databázových podmnožin (subschéma) uživatelů. Návrh fyzické databáze zahrnuje fyzickou reprezentaci dat, výběr a dokumentaci metod přístupu a umístění dat.

Na základě logického návrhu musí fyzický návrhář určit reprezentaci každého datového prvku, záznamu a pole. Pro každé fyzické pole musí být nastavena jeho velikost. Při určování fyzické reprezentace dat je třeba vzít v úvahu následující faktory: úspora paměti, minimalizace redundance (pomocí referencí nebo ukazatelů), způsob zpracování (sekvenční, náhodné) a adresování, koeficient aktivity pole a záznamu (určuje výběr zařízení s přímým nebo sekvenčním přístupem), nezávislost na datech, doba odezvy na požadavek (určuje organizaci dat a typ úložného zařízení).

Specifika úloh řešených na základě vyvíjené databáze, požadavky uživatelů a logický návrh databáze jsou základem pro volbu způsobu adresování a organizace vyhledávání dat. Metody adresování zahrnují: sekvenční skenování, blokové vyhledávání, binární vyhledávání, indexově sekvenční metoda, přímé adresování, míchání a různé jejich kombinace.

Sekvenční skenování zahrnuje kontrolu klíče každého záznamu. Metoda může být účinná pouze při dávkovém zpracování sekvenčních polí na magnetické pásce.

Vyhledávání bloků se používá v případech sekvenčních polí seřazených podle klíče. Záznamy jsou seskupeny do bloků a každý blok je kontrolován, dokud není nalezen požadovaný blok, jehož záznamy jsou čteny.

Při binárním vyhledávání je oblast vyhledávání rozdělena pokaždé na polovinu a klíč výsledného záznamu je porovnáván s klíčem vyhledávání. Binární vyhledávání obvykle není vhodné pro zařízení s přímým přístupem a používá se při vyhledávání indexů polí.

Metoda indexového sekvenčního adresování používá indexy. Index nejvyšší úrovně určuje umístění indexu nejnižší úrovně, který určuje umístění bloku záznamů. Blok záznamů je buď skenován, nebo je prohledáván binárně nebo blokově. Metoda zahrnuje řazení záznamů podle klíče. V případě libovolného pole se používá metoda index-arbitrary. To však vyžaduje mnohem větší index, protože musí obsahovat jeden prvek pro každou položku v poli, nikoli pro blok položek.

Přímé adresování zahrnuje určitý překlad klíče na adresu. Existuje mnoho metod pro převod klíče na adresu v poli. Nejjednodušším způsobem je zadat relativní adresu monitoru záznamu ve vstupní zprávě. V některých aplikacích se adresa vypočítává na základě identifikátorů objektu.

Metoda náhodného přehrávání zahrnuje převod klíče datové položky na kvazináhodné číslo, které se používá k určení umístění záznamu.

Při navrhování fyzické struktury databáze musíte definovat a zdokumentovat, jak se ke každému typu záznamu přistupuje, identifikovat záznamy, ke kterým se přistupuje přímo pomocí klíčů, a záznamy, ke kterým se přistupuje pomocí ukazatelů z jiných záznamů nebo indexů. Každému poli, v závislosti na metodě přístupu, musí být přidělen prostor na fyzických zařízeních ( magnetické disky, pásky). To umístí data tak, aby byla upřednostněna často používaná data nebo aby se maximalizovala blízkost uložených dat.

Nejpoužívanější je metoda indexového sekvenčního adresování. V tomto případě můžete použít dvě metody přístupu - ISAM a VSAM. V metodě přístupu ISAM jsou záznamy seskupeny tak, aby mohly být umístěny na jednotlivých stopách cylindrů diskového modulu, a jedna stopa na každém cylindru je přidělena pro indexy ukazující na záznamy umístěné na tomto cylindru. Pokud je třeba přidat nová data, umístí se do oblasti přetečení (ukazatele na oblasti přetečení jsou také zahrnuty v indexové stopě). Přístupová metoda VSAM je podobná metodě ISAM, avšak metoda VSAM je nezávislá na typu zařízení a nepracuje na kategoriích, jako jsou koleje a válce. Namísto válců rozdělených do stop se používají řízené oblasti, které jsou zase rozděleny do řízených intervalů. V metodě VSAM existuje jedna sada ukazatelů (index) na spravovanou oblast.

Návrh specializovaného DBMS zahrnuje vývoj jazyka pro popis dat, jazyka pro manipulaci s daty a prostředků pro údržbu fyzické databáze. Základní požadavky, které musí jazyky pro popis a manipulaci s daty splňovat, byly identifikovány při zvažování otázky volby univerzálního DBMS. Nejběžnějším jazykem pro popis programátorských dat (podobvodů) je datová sekce COBOL; moderní DBMS zpravidla vyvíjejí vlastní jazyky pro popis dat pro popis schémat a fyzické struktury databáze. Asociace pro jazyky datových systémů (CODASYL) navrhla jazyk pro popis dat, který se používá jak k logickému popisu dat, tak k popisu jejich fyzické organizace.

5. Distribuované databáze

V souvislosti s tvorbou a rozvojem řady automatizovaných řídicích systémů v současnosti založených na počítačových sítích je relevantní návrh distribuovaných databází (RDB). Distribuovaná databáze je systém informačně propojených a určitým způsobem interagujících lokálních databází (LDD), které mají svůj vlastní informační obsah a strukturu. RDB je v podstatě distribuovaný paměťový systém, který ukládá všechna data vyžadovaná odpovídajícím automatizovaným řídicím systémem. Jeho zvláštností je, že fragmenty vygenerované logické struktury jsou umístěny v geograficky vzdálených databázích. Fyzická implementace konektivity RDB se provádí organizováním informačních toků v rámci LDB a mezi nimi prostřednictvím komunikačních kanálů.

Hlavním problémem při vytváření RDB je umístění dat; to určuje takové charakteristiky RDB, jako je objem uložených a aktualizovaných dat, intenzita informačních toků a spolehlivost systémů.

Návrh RDB může probíhat za následujících podmínek:

a) tvorba automatizovaného řídicího systému teprve začíná a úkolem je vybrat optimální strukturu RDB a rozmístění jednotlivých LDB;

b) existuje určitý počet LDB a výpočetních středisek a úkolem je alokovat další počet LDB a optimálně měnit strukturu spojů v systému;

c) formování geografie a struktury systému je dokončeno a úkolem je optimálně přerozdělit pole a změnit topologii spojení.

Nejtypičtějšími úkoly při návrhu RDB jsou určení struktury RDB, určení topologie spojů, volba strategie pro vyhledávání a aktualizaci informací a volba řídicího systému pro RDB.

Existují centralizované, decentralizované a kombinované struktury RDB. Nejpoužívanější jsou kombinované RDB, které se vyznačují přítomností centrální databáze uchovávající celosystémové informace o umístění polí v RDB. Počet LDB na každé úrovni hierarchie je určen omezením objemu uložených informací a omezeními nákladů na vytvoření LDB. Umístění LBD závisí na umístění spotřebitelů a informačních zdrojů.

Volba topologie sítí LBD je dána povahou jejich informačních vztahů, směrem a intenzitou informačních toků a požadovanou spolehlivostí a spolehlivostí přenosu informací. Obvykle jsou uživatelé přiřazeni k jedné LDB a prostřednictvím této LDB jsou připojeni k dalším databázím v RDB. Rozlišují se následující typy struktur LBD spojení v RBD: radiální, radiálně-uzlové, prstencové, každá s každým, kombinované (obr. 4, a - d). Nejspolehlivější, s rychlé hledání informace je systém se strukturou „každý s každým“. Informační spojení tohoto typu jsou charakteristická pro objekty, které jsou si podřízeny pouze funkčně.

Strategie vyhledávání ovlivňuje množství a umístění strukturních a toků dotazových informací. Pokud informace požadované uživatelem nejsou k dispozici v nejbližším LDB, lze navrhnout následující strategie vyhledávání:

1) podle strukturních informací o umístění dat v RDB je vyhledána požadovaná LDB a zpřístupněna tato LDB;

2) vyhledávání se provádí v LDB vyšší úrovně; pokud potřebné informace chybí, analyzují se strukturní informace o obsahu všech podřízených LBD; pokud potřebné informace chybí, přejděte do LDB vyšší úrovně hierarchie;

3) je podáno odvolání ke kontrolnímu LDB, kde jsou uloženy strukturální informace o všech LDB;

4) všechny LBD jsou dotazovány buď paralelně, nebo postupně.

Strategie 1 poskytuje minimální množství dotazovacích informací, ale v každém LDB je nutné uložit strukturální informace o umístění polí v RDB.

Strategie 2 je typická pro hierarchické systémy, ve kterých převládají informační toky shora dolů.

Strategie 3 minimalizuje strukturální informace.

Strategie 4 se vyznačuje velkými toky informací o požadavcích.

Fungování RDB předpokládá přítomnost informačních aktualizačních proudů v něm. Mezi aktualizačními strategiemi lze rozlišit následující: aktualizaci všech duplicitních polí napříč všemi LDB provádí informační zdroj; zdroj aktualizuje informace pouze v nejbližší LDB, všechna ostatní duplicitní pole jsou aktualizována z iniciativy této LDB; aktualizace duplikovaných polí se provádí podle algoritmu (například minimalizace celkových toků aktualizací). Strategie aktualizace musí zajistit specifikovanou spolehlivost, spolehlivost a výkon RDB. Vývoj a implementace účinných systémů řízení povodí jsou v současné době v rané fázi. Hlavním kritériem při vývoji řídicího systému RDB je minimální pracnost tvorby a implementace jeho softwaru. Problém lze vyřešit doladěním a úpravou stávajících DBMS nebo vytvořením efektivních speciálních systémů řízení RDB.

Ve své nejobecnější podobě je databáze definována jako soubor vzájemně souvisejících informací. Z této definice vyplývá důležitá vlastnost databáze, a to, že databáze zahrnuje nejen data samotná, ale i vazby mezi nimi. Jednou z hlavních myšlenek databáze je sdílené ukládání dat s jejich popisy. Díky tomu se ukládaná data stávají „otevřenými“, srozumitelnými pro libovolný počet aplikací pracujících s databází. Díky tomu je databáze nezávislým informačním zdrojem, který lze opakovaně používat různými aplikacemi a přitom na nich zůstat nezávislý.

Kromě toho, že databáze popisuje data, vysvětluje jejich význam a strukturu, podporuje určitá omezení kladená na tato data, například určuje typ dat, jejich dimenzi atd.

Tím pádem, databáze je druh strukturovaného datového informačního zdroje určený pro víceúčelové, opakované použití v konkrétních tematických oblastech.

Databáze fungují pod kontrolou systémů pro správu databází (DBMS), které jsou definovány jako kolekce jazyků a programů potřebných pro práci s databází. DBMS umožňují vytvářet databáze, zadávat a měnit informace v nich a přistupovat k těmto informacím. Zásadně odlišná bude organizace softwarové a informační podpory v případě použití DBMS (obr. 2.5).

Aplikace přistupují k datům uloženým v jedné nebo více databázích prostřednictvím DBMS. Organizace softwarového a informačního komplexu přitom není určena softwarem, ale informační podpora. Ukázalo se, že data jsou nezávislá na aplikacích, aplikace zase mohou využívat jakákoli data obsažená v databázi. DBMS udržuje integritu dat, určuje jejich sdílení různými programy a různými uživateli a do té či oné míry zajišťuje bezpečnost informací.

Rýže. 2.5. Schéma organizace softwarové a informační podpory

Pomocí subd

Provádí také nejdůležitější informační procedury s daty obsaženými v databázi na žádost uživatele nebo příkaz přijatý z aplikace.

Při použití DBMS typu kompilátoru se vytvářejí aplikace, které pracují přímo s databázemi. Samotný DBMS jako samostatný softwarový nástroj pro práci s daty přitom prakticky chybí.

Ve skutečnosti se ve fázi kompilace sloučí jádro databáze a aplikace (obrázek 2.6).

Rýže. 2.6. Schéma pro sloučení databázového jádra a aplikací

V současné době jsou aplikace vyvíjeny zpravidla kvalifikovanými programátory. Navrhování databázových struktur je přitom nemožné bez účasti ekonomů – specialistů v dané oblasti, protože informační schopnosti databáze jsou do značné míry určovány kvalitou jejího návrhu.

Databázové prvky

Databáze je systémová, tzn. skládá se z určitého počtu prvků a vztahů mezi nimi (obr. 2.7)

Rýže. 2.7. Strukturální jednotky databáze

Nejmenší z nich je datový prvek, který se v některých případech nazývá také pole nebo atribut a který odpovídá jednomu atributu. Datový prvek je tedy nejmenší sémanticky smysluplná pojmenovaná jednotka dat. Datový prvek je definován následujícími charakteristikami: jméno (celé jméno, datum narození, název společnosti), typ (znak, číslo, kalendář), délka (maximální možný počet znaků - 15 bajtů) a přesnost (počet desetinných míst). pro číselná data).

Datové položky jsou organizovány do záznamů nazývaných n-tice. Přihlásit se obecný případ odpovídá indikátoru a nese data o jednom z homogenních objektů, například o jednom účtu, jednom zaměstnanci atd. V některých případech se používá koncept datového agregátu, který zaujímá mezipolohu mezi datovým prvkem a záznamem. Datový agregát může být jednoduchý (skládající se pouze z datových prvků) nebo složený (skládající se z prvků a jednoduchých datových agregátů).

Soubor záznamů stejného typu se nazývá databázový soubor (nebo tabulka). Je třeba poznamenat, že databázový soubor nemusí vždy odpovídat fyzickému souboru. V některých případech jsou informace databázového souboru obsaženy v několika fyzických souborech a naopak několik databázových souborů může být obsaženo v jednom fyzickém souboru.

Databáze je tedy souborem vzájemně propojených databázových souborů.

Význam těchto pojmů lze vysvětlit na schématu (obr. 2.8).

Datový prvek obsahuje jeden atribut, v tomto případě název města – Moskva. Datový agregát se skládá z několika detailů považovaných za jeden celek. Záznam se skládá z jednoho nebo více datových prvků a obsahuje informace o jednom objektu, v uvedeném příkladu o jednom podniku. Soubor záznamů stejného typu tvoří databázový soubor, na obrázku se jedná o soubor s informacemi o podnicích. Sbírka takových souborů, vzájemně propojených tak či onak, tvoří databázi. Diagram ukazuje tři soubory informací propojené takto: podniky jsou obsluhovány bankami, mají v těchto bankách otevřené účty. Pokud mezi soubory neexistuje žádné spojení, nelze jejich sbírku považovat za databázi.

Rýže.2.8. Příklad vztahu mezi strukturními jednotkami databáze

Životní cyklus databáze

Jako každý systém má i databáze svůj životní cyklus, který představuje konzistentní vývoj systému v čase. Rozlišují se následující hlavní fáze životního cyklu.

Plánování. Jeho účelem je určit a analyzovat požadavky na vytvářenou databázi. Zároveň jsou uvažovány různé pohledy na data v závislosti na vykonávaných funkcích, jsou stanoveny konkrétní požadavky na databázi v závislosti na typech dotazů, objemu prohlížení databázových souborů, režimu práce s touto databází atd.

Návrh databáze. Na základě analýzy potřeb uživatelů a integrace těchto potřeb je vytvořen doménový model. Na základě tohoto modelu je vybudována logická databázová struktura orientovaná na konkrétní DBMS. Posledním krokem je analýza a vyhodnocení schopností databáze z hlediska uspokojování potřeb různých skupin uživatelů.

Materializace databáze.Účel této etapy životní cyklus- naplnění a načtení databáze pomocí nástrojů DBMS. To zahrnuje následující práce: příprava dat; přenos vstupních informací z dokumentů na počítačová média; transformace existujících datových souborů podle specificky vyvinuté struktury získané v předchozí fázi.

Provoz databáze. Cíle této etapy životního cyklu jsou: zajištění implementace a nepřetržitého provozu databáze; bezpečnost dat v případě selhání počítačového systému a jiných mimořádných situací; analýza fungování databázového systému z hlediska jeho účinnosti a produktivity. Jako kritéria pro hodnocení databáze je použit systém kvantitativních a kvalitativních ukazatelů. Mezi kvantitativní ukazatele patří: doba odezvy na požadavek, použitá externí a RAM paměť, spolehlivost a další náklady (na aktualizaci databáze, vytvoření, reorganizaci, restrukturalizaci). Kvalitativní ukazatele jsou flexibilita, adaptabilita, dynamika, obnovitelnost, schopnost zachovat integritu dat atd.

Vývoj a zlepšování databáze. Při provozu databáze vyvstávají nové úkoly, s jejichž řešením je spojen vznik nových datových prvků a vazeb mezi nimi, což vede k nutnosti vytvořit modifikovatelnou databázi. Je třeba rozlišovat mezi reorganizací databáze a restrukturalizací databáze. První souvisí se změnou hodnot dat, tzn. zlepšení informačního systému má pozitivní vliv na rozvoj databáze a její úpravy. Restrukturalizace zahrnuje změnu strukturálních posunů, což znamená vytvoření téměř nové databáze.

Návrh databáze

Mezi fázemi životního cyklu databáze má velký význam fáze návrhu. Je to dáno tím, že kvalita databáze do značné míry určuje kvalitu celého informačního systému. Navíc právě v této fázi dochází k nejaktivnější interakci mezi vývojáři a odborníky v dané oblasti a formují se základní představy o dané oblasti, které budou tvořit základ EIS. Design má tedy výzkumný charakter a řeší problémy spojené nejen s vymezením předmětné oblasti a tvorbou jejího modelu, ale také s principy konstrukce logických struktur.

Návrh databáze prochází několika fázemi. Je obvyklé rozlišovat fáze koncepčního, logického a fyzického návrhu, i když někdy se nazývají odlišně a v některých případech některé z nich skutečně chybí.

Na první etapa je vytvořen konceptuální neboli infoologický datový model předmětné oblasti. Vyznačuje se tím, že nezávisí na vlastnostech konkrétních DBMS. Popisuje hlavní objekty předmětové oblasti, jejich vlastnosti a souvislosti mezi nimi. Předmětovou oblast je možné popsat přirozeným jazykem, ale pro větší přesnost, přehlednost a snadnost dalšího navrhování se používají formalizované prostředky. Popis vytvořený pomocí přirozeného jazyka, matematických vzorců, tabulek, grafů a dalších nástrojů, které jsou srozumitelné každému, kdo pracuje na návrhu databáze, se tedy nazývá konceptuální datový model.

Existuje mnoho přístupů k vytvoření konceptuálního datového modelu: grafové modely, sémantické sítě, model vztahu mezi entitou atd. Nejoblíbenější z nich je model vztahu entita ( ER-model, z angl. Entita- Vztah). ER-model navrhl americký vědec Peter Ping Shen Chen v roce 1976. K dnešnímu dni bylo vyvinuto několik jeho odrůd, ale všechny jsou založeny na grafických diagramech navržených Chenem.

Ve formuláři je graficky znázorněn model vztahu entita ER-diagram, který se skládá ze sady hodnot popisujících vlastnosti entity a vztahu (Entita - Vztah Diagramy).

Mezi výhody tohoto modelu patří:

snadná formalizace,

snadnost porozumění;

popis grafickými prostředky;

jasnost obrazu různé typy připojení;

snadnost převodu do databázového schématu podporovaného některými DBMS.

Hlavními součástmi modelu entita-vztah jsou entita, atributy a vztahy (obrázek 2.9).

Rýže.2.9. ER -diagram

Podstata (Entita) - určitý reálný nebo imaginární objekt, který je významný pro uvažovanou předmětnou oblast, informace o které jsou předmětem ukládání. Každá entita musí mít určité vlastnosti: mít jedinečný název a jeden nebo více atributů, které jednoznačně identifikují každou instanci entity. Atribut je jakákoli charakteristika entity, která je významná pro uvažovanou předmětnou oblast. Je určen ke kvalifikaci, identifikaci, klasifikaci, kvantifikaci nebo vyjádření stavu entity.

Spojení (Vztah) - pojmenovaná asociace mezi dvěma entitami, která je významná pro uvažovanou předmětnou oblast.

Vztah je pojmenován a název každého vztahu mezi dvěma entitami musí být jedinečný.

Koncepční model je sestaven na základě rozhovorů a průzkumů expertů - specialistů na danou oblast a musí splňovat řadu požadavků:

musí být nezávislé na konkrétní DBMS;

musí být srozumitelné jak pro vývojáře informačních systémů, tak pro odborníky na dané téma;

by měl minimalizovat další konstrukční úsilí. To znamená, že jeho struktury musí být snadno převedeny na logické modelové struktury;

měly by pokud možno existovat v počítačově vnímatelné podobě. V tomto případě bude vhodný pro počítačově podporovaný návrh databáze.

Cílem konceptuálního modelování je tedy vytvoření přesné a úplné reprezentace předmětné oblasti, tzn. definovat objekty, jejich vlastnosti a objektové vztahy (tedy vztahy).

Na Druhá fáze design, je vytvořen logický neboli datalogický model. Takový model se již nestaví z hlediska objektů a vztahů, ale z hlediska konkrétního DBMS, ve kterém má být databáze používána. Tento model se také nazývá databázové schéma.

V současnosti jsou známy tři logické datové modely (nazývají se také klasické nebo pozoruhodné modely), a to hierarchický, síťový a relační.

Hierarchické a síťové datové modely se začaly používat v systémech správy databází na počátku 60. let. Na počátku 70. let 20. století. byl navržen relační datový model.

Hlavními prvky kteréhokoli z těchto modelů jsou objekty a vztahy mezi nimi a rozlišovacím znakem je rozdíl ve způsobech znázornění vztahů mezi objekty.

Třetí etapa- fyzický design. Jeho výsledkem je fyzický model, který obsahuje popis databáze z hlediska její fyzické struktury. Fyzický model zahrnuje výběr paměťových médií, určení způsobu umístění databáze a jejích komponent na tato média, popis možností a proveditelnosti komprese dat a optimalizaci přístupu k datům na fyzické úrovni.

Pokud je tedy konceptuální model nezávislý na DBMS a případně i na datovém modelu a logický model závisí na konkrétním DBMS, pak fyzický model závisí nejen na DBMS, ale také na technickém a částečně systémovém softwaru. .

Současná fáze vývoje informačních systémů přináší některé změny klasického schématu návrhu databáze:

ve fázi koncepčního návrhu se široce používají grafické metody;

díky novým metodologiím je docela snadné převést koncepční model na logický model pro různé DBMS. V některých případech může být přechod od konceptuálního modelu k logickému automatizovaný nebo dokonce zcela automatický;

moderní DBMS a další software umožňují značně zjednodušit fyzická organizace databází. Fáze fyzického návrhu je proto nyní výrazně omezena a někdy téměř zcela automatizována.

Typy logických datových modelů

Jak bylo uvedeno výše, hlavní typy logických datových modelů jsou: hierarchické, síťové a relační.

Hierarchický datový model umožňuje vytvářet databáze se stromovou strukturou. V nich každý uzel obsahuje svůj datový typ (entitu). Na nejvyšší úrovni stromu v tomto modelu je jeden uzel - kořen, na další úrovni jsou uzly spojené s tímto kořenem, pak uzly spojené s uzly předchozí úrovně atd., přičemž každý uzel může mít pouze jeden předek (obr. 2.10). Takové databáze podporují vztah jeden k mnoha.

Vyhledávání dat v hierarchickém systému vždy začíná od kořene. Poté se provede sestup z jedné úrovně do druhé, dokud není dosaženo požadované úrovně. Přesun systémem z jednoho záznamu do druhého se provádí pomocí odkazů.

Hlavními výhodami hierarchického modelu je jednoduchost popisu hierarchických struktur reálného světa a rychlé provádění dotazů, které odpovídají datové struktuře. Takové modely však často obsahují nadbytečná data a nejsou vhodné pro reprezentaci vztahů mnoho k mnoha. Navíc ne vždy je vhodné začínat pokaždé vyhledávat potřebná data z kořene a neexistuje ani jiný způsob, jak se databází pohybovat v hierarchických strukturách. Hierarchické systémy jsou nejstarší generací databázových systémů, byly vyvinuty pro velké počítače.

Rýže. 2.10. Hierarchická struktura databázového modelu

Síťový datový model je také založena na grafickém znázornění vztahů mezi objekty. Zde však kromě vertikálních spojů existují i ​​horizontální, tzn. je povoleno podřízení jednoho objektu mnoha objektům. Na rozdíl od hierarchických síťových modelů tedy podporují vztahy many-to-many. Každý vygenerovaný prvek v nich může mít více než jednoho předka (obr. 2.11).

Rýže. 2.11. Síťová struktura databázového modelu

Síťové systémy jsou však poměrně složité a vyžadují solidní software. V nich, stejně jako v hierarchických systémech, se přechod od záznamu k záznamu provádí pomocí odkazů vložených do každého záznamu. Svého času byly docela populární a používaly se pro minipočítače a sálové počítače.

Relační model organizace databáze je v současnosti nejoblíbenější. Důvodem je skutečnost, že přítomnost zásadních nedostatků hierarchických a síťových modelů vedla k neúčinnosti jejich použití v moderní podmínky. Schopnosti relačního modelu umožnily tyto nedostatky překonat a popsat hierarchické a síťové struktury.

Relační databáze je databáze, kterou její uživatel vnímá jako kolekci tabulek. Prezentace dat ve formě tabulek je plně v souladu s tradičními „nepočítačovými“ technologiemi zpracování informací, je vizuální a srozumitelná většině uživatelů. Tabulky relačních databází lze prohlížet na obrazovce počítače nebo tisknout. Všimněte si také, že relační datový model nejlépe odpovídá struktuře ekonomických informací.

Základní pojmy relačních databází

Relační datový model vyvinutý E. Coddem v 70. letech 20. století je založen na matematické teorii relací a opírá se o systém pojmů relační algebry, z nichž nejdůležitější jsou tabulka (relace), řádek (nice), sloupec (atribut), obsah sloupce (doména), primární klíč, cizí klíč.

V relačním modelu jsou data prezentována ve formě propojených tabulek. Každá tabulka se skládá z řádků (záznamů stejného typu nebo n-tic) a sloupců (polí nebo atributů) a má název, který je v rámci databáze jedinečný. Slovo "stejný typ" znamená, že všechny záznamy mají stejnou sadu atributů nebo polí, ačkoli každý atribut může mít svou vlastní hodnotu. Každý sloupec tabulky má jedinečný název pro svou tabulku. Sloupce jsou v tabulce uspořádány podle pořadí, v jakém se jejich názvy objevily při vytváření tabulky. Každý atribut může mít podmnožinu hodnot z konkrétní oblasti (domény). Na rozdíl od sloupců nemají řádky názvy, jejich pořadí v tabulce není definováno a jejich počet není omezen.

Vysvětleme si výše uvedené pojmy na příkladu relačního databázového modelu obsahujícího informace o zaměstnancích určité společnosti. Podívejme se na tabulku s údaji o zaměstnancích firmy (tab. 2.6).

Tabulka 2.6

Zaměstnanci

Personální číslo	Příjmení I.O.	Kód oddělení	Pracovní telefon
	PETROV A.V.
	ROMANENKO S.T.
	ŠTĚPÁNOVÁ I.S.

Můžete vidět, že všechny tři položky mají stejné atributy, ale nabývají různých hodnot. Takže pro záznam č. 1 má atribut „personální číslo“ hodnotu 008976 a pro záznam č. 2 - 008980 atd. Hodnoty některých atributů mohou být pro různé záznamy stejné, například záznamy č. 1 a č. 2 mají stejnou hodnotu pro atribut „kód oddělení“. Každá tabulka však musí mít atribut (nebo kolekci atributů), jehož hodnota se nikdy neopakuje a jednoznačně identifikuje každý řádek v tabulce. To je nezbytné, abyste při práci s databází mohli rozlišit jeden záznam od druhého. Takové vlastnosti se nazývají jedinečné. Je volán jedinečný atribut tabulky nebo sada jejích jedinečných atributů primární klíč nebo klíčové pole. V této tabulce je klíčem atribut „personální číslo“.

V případě, že je záznam jednoznačně určen hodnotami několika polí (nebo sadou jedinečných atributů), existuje složený (zřetězený) klíč.

V některých případech nemusí mít atribut žádný význam: například zaměstnanec č. 3 nemá pracovní telefonní číslo a odpovídající atribut není vyplněn. V tomto případě se říká, že atribut má hodnotu null. Klíč nemůže mít hodnotu null.

Jednoduchou kolekci tabulek nelze považovat za databázi, pokud mezi nimi neexistují určité vztahy. V relačních databázích vztahy označují shodu mezi záznamy ve dvou tabulkách. Podívejme se na druhou tabulku obsahující informace o odděleních (tabulka 2.7)

Tabulka 2.7

Mezi dvěma výše uvedenými tabulkami můžete navázat vztah "ZAMĚSTNANEC - pracuje v - ODDĚLENÍ". Pokud chcete zjistit informace o oddělení, ve kterém pracuje zaměstnanec č. 2, je třeba vzít hodnotu atributu „kód oddělení“ v tabulce „ZAMĚSTNANCI“ a najít odpovídající kód v tabulce „ODDĚLENÍ“. Sloučí se tak dva záznamy z různých tabulek

ROMANENKO S.T.

ODDĚLENÍ LIDSKÝCH ZDROJŮ

Můžete vidět, že vztah mezi dvěma tabulkami je založen na shodě hodnot atributů dvou tabulek, v našem případě je to atribut „kód oddělení“ tabulky „ZAMĚSTNANCI“ a atribut „kód“ tabulky tabulka „ODDĚLENÍ“. Takové atributy se nazývají komunikační atributy. Atribut vztahu v jedné tabulce musí být klíč. Ve výše uvedeném příkladu je atribut „code“ klíčem pro tabulku „ODDĚLENÍ“. Pokud by tomu tak nebylo a kódy oddělení v této tabulce se opakovaly, nebylo by možné určit, na které oddělení se odkazuje v prvním stůl. Druhý atribut vztahu – v tomto případě „kód oddělení“ tabulky ZAMĚSTNANCI – je tzv. cizí klíč, protože odkazuje na klíč jiné (externí) tabulky (obr. 2.12).

Tabulka 2 primární klíč

Postrelační databáze

Jak již bylo zmíněno, relační databáze se skládají z dvourozměrných tabulek, které spolu souvisí. Při návrhu relační databáze jsou tedy všechny informace rozděleny do mnoha dvourozměrných polí. V některých případech tabulka odpovídá mnoha skutečným objektům, jako jsou „oddělení“, „zaměstnanci“, „účty“ atd. Ale někdy, když se musíte vypořádat s hierarchickými informacemi, musí být stejný objekt „rozložen“ do několika tabulek.

Příkladem mohou být víceřádkové dokumenty, jako je faktura. Každý z těchto dokumentů obsahuje obecné podrobnosti, jako je číslo, datum, jméno dodavatele a příjemce. V tabulce „Faktury“ tvoří tyto údaje jeden záznam. Faktura je však víceřádkový dokument a pro uložení každého řádku obsahujícího název produktu, jeho množství, cenu a množství bude také vyžadován samostatný záznam. Je tedy nutné vytvořit dodatkovou tabulku „Řádky faktury“ spojenou s předchozí. Údaje pro každou fakturu budou obsaženy v jednom záznamu v první tabulce a v jednom nebo více záznamech ve druhé.

Tento přístup má řadu nevýhod. Za prvé se zvyšuje počet tabulek a vztahů mezi nimi, což napříč celou databází vede k pomalejšímu provádění dotazu. Za druhé se nebere v úvahu hierarchie a logická jednota tabulek. V tomto příkladu lze tabulku Řádky faktury považovat za podřízenou tabulce Faktury, protože bez ní nemůže existovat. A pouze v jednotě tyto dvě tabulky popisují takzvaný obchodní objekt - obdobu skutečného dokumentu. Rozdělení obchodních objektů do více tabulek komplikuje strukturu databáze a její pochopení uživateli.

FAKTURAČNÍ ŘÁDKY

FAKTURY

Tyto nedostatky odstraňuje postrelační datový model, který je v podstatě vývojem relačního modelu s tím rozdílem, že odstraňuje omezení atomičnosti (nedělitelnosti) atributů.

Omezení atomicity atributu znamená, že v relační databázi může atribut (pole) každého záznamu obsahovat pouze jednu hodnotu. Na druhou stranu v postrelačním modelu může pole obsahovat více hodnot nebo dokonce celou tabulku. Je tedy možné „vnořit“ jeden stůl do druhého.

To vám umožňuje efektivněji provozovat obchodní objekty, z nichž každý se stává logicky integrální a představuje pouze jeden záznam.

Podle vývojářů postrelačních DBMS se rychlost provádění dotazů v nich zvyšuje až 20krát ve srovnání s relačními DBMS. Přechod od relačních databází, které se staly všudypřítomnými, k porelačním je však spojen se značnými náklady a je stále omezený.

Úložiště dat

Datový sklad je systém navržený tak, aby poskytoval jednotný informační prostor pro účely analýzy a optimalizace jeho podnikání.

Činnost každého ekonomického subjektu je spojena s využíváním a zpracováním informací, které jsou nejdůležitějším ekonomickým zdrojem pro dosahování vysoké ekonomické výkonnosti. Charakteristickým rysem EIS je však potřeba zpracovávat dva typy dat, a to provozní a analytická. Proto je v procesu fungování EIS třeba vyřešit dvě třídy problémů:

zajištění každodenní práce podniku při zadávání a zpracování informací;

organizace informačního úložiště za účelem komplexní vícerozměrné analýzy a studia dat k identifikaci vývojových trendů, předpovědi podmínek, hodnocení a řízení rizik atd. a nakonec usnadnit rozhodování.

Úlohy první třídy - automatizace provozních činností - jsou kompletně vyřešeny OLTR-systémy (Online Transakční Proces­ Ing - operativní zpracování transakcí), které zahrnují automatizované bankovní systémy, účetní systémy atd. Určené pro práci s analytickými daty OLAP- systémy (Online Analytická zpracovává se - operativní analytické zpracování), které jsou postaveny pomocí technologie datových skladů a jsou určeny pro agregovanou analýzu velkých objemů dat. Tyto systémy jsou nedílnou součástí rozhodovacích systémů nebo systémů řízení třídy střední A horní spravovat­ ment, těch. systémy určené pro průměrné a vyšší úrovně vedení společnosti.

Srovnávací charakteristiky využití dat v provozních a analytických systémech zpracování jsou uvedeny v tabulce. 2.8.

Tabulka 2.8

Charakteristika operačních a analytických informačních systémů

Vlastnostidata	Systém
	operativní zpracování	analytické zpracování
Účel	Operativní vyhledávání, jednoduché druhy zpracování	Analytické zpracování, prognózování, modelování
Úroveň agregace	Podrobné údaje	Agregovaná data
Doba skladování	Od několika měsíců do jednoho roku	Od několika desítek let a více
Frekvence aktualizace	Vysoký. Aktualizujte po malých porcích	Nízký. Aktualizace ve velkých částech, až několik milionů záznamů najednou
Kritérium účinnost	Počet transakcí za jednotku času	Rychlost provádění složitých dotazů a transparentnost struktury úložiště pro uživatele

Moderní EIS je tedy systém založený na sdílení transakčních OLTP- systémy a úložiště dat (Data Sklad).

Termín „datový sklad“ se stal populárním v 90. letech. Jak definoval William Inmon, který je zakladatelem této technologie, datový sklad (DW) je doménově specifická, integrovaná, neměnná, historická sbírka dat organizovaná za účelem podpory rozhodování.

Charakteristické rysy datového skladu jsou:

orientace na předmětnou oblast, tzn. Do datového skladu jsou umístěny pouze informace, které mohou být užitečné pro provoz analytických systémů;

podpora historických dat, která určuje skutečnost, že analýza vyžaduje informace nashromážděné za dlouhou dobu;

integrace dříve oddělených dat pocházejících z různých zdrojů do jednoho úložiště, jakož i jejich ověřování, koordinace a redukce do jediného formátu;

Agregace, která zajišťuje současné ukládání agregovaných a primárních dat v databázi tak, aby požadavky na stanovení celkových hodnot byly dokončeny dostatečně rychle.

Datový sklad je tedy specializovaná databáze, ve které se shromažďují, integrují a shromažďují informace nezbytné pro manažery k přípravě manažerských rozhodnutí; např. v bankovnictví se jedná o informace o klientech bank, úvěrových záležitostech, úrokových sazbách, směnných kurzech, kurzech akcií, stavu investičního portfolia, provozních dnech poboček atd.

V tomto ohledu není datový sklad určen ani tak pro zadávání informací, jako spíše pro jejich rychlé vyhledávání a analýzu. Proto systémy založené na datovém skladu mají databázovou architekturu, která zajišťuje vysokou rychlost provádění dotazů na obrovské množství informací. Vyznačují se odlišným designem uživatelského rozhraní, které představuje speciální prostředky pro vyhledávání informací, jejich shrnutí a zacházení do detailů.

V současné době se vyvíjejí taková úložiště, ve kterých se data nejen shromažďují, ale je poskytována i možnost jejich změny: uspořádání analytických funkcí, úpravy managementu, doplňování chybějících dat.

Systém řízení datového skladu se skládá z několika funkčních bloků.

Databáze. Představuje jádro celého systému. Zásadním rozdílem mezi skladovou databází je její promyšlená struktura, která má optimální skladbu subjektů specifických pro finanční odvětví, dále struktura a soubor atributů těchto subjektů, v důsledku čehož struktura databáze skladu je optimalizována pro rychlé načítání a rychlé načítání dat, nikoli pro rychlé provádění transakcí.

Nástroje pro konfiguraci databáze a správu metadat. Tyto nástroje jsou určeny pro konfiguraci informačního modelu datového skladu při implementaci a změnu tohoto modelu za provozu, pro postupné rozšiřování funkčnosti datového skladu. Pro zajištění maximální flexibility a adaptability datového skladu by navíc měla být metadata ukládána do databáze jako samostatné informace (Metadata) - údaje o datech. Metadata zahrnují informace o fyzických datech, technických a obchodních procesech, pravidlech a datové struktuře. Plní tedy roli referenční knihy obsahující informace o zdrojích primárních dat, algoritmech zpracování, kterým byla původní data podrobena, popis datových struktur a jejich vztahů atd.

Technologie sběru dat. Nekonzistentnost a nejednotnost dat, fragmentace a izolace zdrojů, rozdíly ve způsobech ukládání dat, nemožnost přístupu k datům z některých zdrojů neumožňují plné využití těchto dat. Potřebujeme proto speciální technologii sběru dat, která zajistí pravidelný a nepřetržitý příjem dat z různých zdrojů, zejména ze vzdálených poboček, přidružených pracovišť a dalších informačních systémů, a umožní nám přeměnit celou řadu dat nashromážděných bankou na informace. cenné pro podnikání. Tato technologie zahrnuje datové formáty, technologii jejich generování, obchodní pravidla upravující extrakci dat z externích zdrojů, distribuci metadat (regulační a referenční informace) a mnoho dalšího.

Ke sběru dat se používají dva přístupy: ETL- systémy a podnikový standard pro formát výměny dat. Prvním způsobem sběru dat je použití nástrojů ETL (Výpis, Transforma), speciální systémy pro extrakci dat z jiných databází, jejich transformaci podle pravidel popsaných v tomto systému a nahrání do úložiště. Druhým přístupem je použití standardního formátu pro sběr dat a vytvoření postupů pro stahování dat na zdrojové straně. To vám umožňuje shromažďovat homogenní data z heterogenních systémů, decentralizovat vývoj postupů nahrávání dat a poskytovat řešení tohoto problému specialistům, kteří mají znalosti o zdrojovém systému.

Systém čištění a načítání dat. Tento systém zajišťuje kontrolu vstupních dat, automatickou opravu chyb, odstranění duplicit a nesprávných hodnot, přivádění dat do jednotné normy, načítání velkého množství dat, víceúrovňové protokolování.

Počítací aparát. Speciální výpočetní přístroj poskytuje:

agregace dat - výpočet zobecněných ukazatelů, například výpočet měsíční, čtvrtletní a roční bilance;

konsolidace dat - sčítání dat podél organizační hierarchie, například výpočet konsolidované bilance banky;

výpočet derivátových ukazatelů, jako je skutečné plnění rozpočtu, likvidita, marže atd.

Uživatelská rozhraní a sestavy. Datový sklad při hromadění cenných informací musí zajistit jejich maximální využití zaměstnanci. K dosažení tohoto cíle má speciální uživatelská rozhraní navržená pro rychlé načítání dat a pokročilou technologii pro vytváření a vydávání zpráv.

Rozhraní pro externí systémy. Datový sklad poskytuje informace externím analytické systémy a generátory zpráv. K tomuto účelu se používají průmyslové standardy pro přístup k datům.

Architektura systému řízení datového skladu je znázorněna na Obr. 2.15.

Rýže. 2.15. Architektura systému řízení datového skladu

Data jsou do skladu načítána z provozních systémů zpracování dat a z externích zdrojů, například z oficiálních zpráv podniků a bank, výsledků burzovních obchodů atd. Při načítání dat do úložiště se kontroluje integrita, srovnatelnost a úplnost načtených dat a také se provádí jejich nezbytná konverze a transformace.

Datový sklad je určen pro vyšší a střední management společnosti, zodpovědný za rozhodování a rozvoj podnikání. Jedná se o vedoucí strukturálních, finančních a klientských oddělení, dále marketingových oddělení, analytických a plánovacích oddělení, například oddělení reportingu, obecného účetnictví, treasury, analytického oddělení, marketingového oddělení atd.

Datový sklad je založen na konceptu vícerozměrného informačního prostoru neboli hyperkrychle (multidimenzionální krychle). Hodnoty uložené v buňkách této krychle a nazývané fakta představují kvantitativní ukazatele charakterizující činnost společnosti. Zejména se může jednat o údaje o obratech a zůstatcích na účtech, struktuře výdajů a příjmů, stavu a toku finančních prostředků atp. Rozměry krychle, tvořící jednu z jejích ploch, jsou množinou dat stejného typu určené k popisu faktů, například poboček, produktů, dodavatelů, zákazníků a měn atd., tzn. jsou zodpovědní za popis jakostních znaků společnosti. Agregace dat se provádí podle rozměrů krychle, takže prvky dimenzí jsou obvykle seskupeny do hierarchických struktur, například pobočky jsou často seskupeny podle teritoriální základny, klienti - podle odvětví, data - do týdnů, měsíců, čtvrtletí a let. Každá buňka této krychle je „odpovědná“ za konkrétní sadu hodnot pro své jednotlivé dimenze, například obrat rozvahy za den, čtvrtletí, rok podle poboček.

V současné době jsou nejrozšířenější tři typy datových modelů používaných při výstavbě datových skladů: multidimenzionální, relační a kombinované.

Pro vícerozměrný model charakterizované využíváním nerelačních prostorových databází ve formě hyperkrychlí, poskytujících vícerozměrné ukládání, zpracování a prezentaci dat. Hlavní výhodou vícerozměrného modelu je rychlost načítání dat. Data jsou v průsečíku rozměrů hyperkrychle. Chcete-li je hledat, nemusíte organizovat spojení mezi tabulkami, jak se to dělá v relačních DBMS. Díky tomu je průměrná doba odezvy na komplexní (neregulovaný) dotaz v multidimenzionálním modelu o 1-2 řády nižší než v relačním.

Hyperkrychle však vyžaduje velké množství diskového úložiště, protože předem rezervuje prostor pro všechna možná data, tento objem se dramaticky zvyšuje s vysokým stupněm granularity dat a je obtížné data upravit, protože přidání další dimenze vyžaduje kompletní přestavbu dat. hyperkrychle.

Proto je vhodné použít vícerozměrný HD model, když je jeho objem malý (ne více než 10-20 gigabajtů) a hyperkrychle má časově stabilní sadu měření.

Použitím relační model Vícerozměrná struktura datového skladu je implementována relačními tabulkami jak se standardními schématy rozložení dat, jako je „hvězda“ a „sněhová vločka“, tak se složitějšími, specifikovanými šablonami. SQL-žádosti. Datové sklady vybudované na základě relačního modelu jsou schopny ukládat obrovské množství informací, ale v rychlosti provádění dotazů jsou horší než multidimenzionální modely. V relačním modelu je hyperkrychle emulována DBMS na logické úrovni.

V posledních letech se začaly používat kombinované datové sklady, ve kterém je relační DBMS kombinována s celou sadou vícerozměrných. Relační databáze je v tomto případě centrální úložiště a umožňuje shromažďovat obrovské množství informací. Data požadovaná konkrétními analytickými aplikacemi jsou alokována z centrálního úložiště do vícerozměrných databází. Každá vícerozměrná databáze uchovává informace o jedné z oblastí činnosti (obr. 2.16).

Rýže. 2.16. Logické schéma kombinovaného datového skladu

Data Marts

Jednou z možností implementace datového skladu v praxi je vybudování datových tržišť (Data Marts). Někdy se jim také říká data marts. Datový trh je předmětově orientovaná sbírka dat, která má specifickou organizaci. Obsah datových trhů je zpravidla určen k řešení určitého okruhu homogenních problémů v jedné nebo více souvisejících tematických oblastech nebo k plnění specifických obchodních funkcí nebo pro konkrétní oddělení. Například pro řešení problémů souvisejících s analýzou bankovních úvěrových služeb se používá jedna vitrína a pro analýzu aktivit banky na akciovém trhu slouží druhá.

Datový trh je tedy relativně malé a specializované datové úložiště obsahující pouze data specifická pro dané téma a určené pro použití konkrétní funkční jednotkou. Funkčně orientované datové trhy jsou tedy datové struktury, které poskytují řešení analytických problémů v konkrétní funkční oblasti nebo divizi společnosti, například řízení ziskovosti, analýza trhu, analýza zdrojů, analýza peněžních toků, analýza zákaznické základny, průzkum trhu, správa aktiv a pasiv atd. Data marts lze tedy považovat za malá tematická úložiště, která jsou vytvářena za účelem poskytování informací pro analytické úkoly konkrétních manažerských útvarů společnosti.

Uspořádání dat do vitríny je dáno potřebou poskytnout schopnost analyzovat data z konkrétní oblasti pomocí nejoptimálnějších prostředků.

Datové tržiště a datové sklady se od sebe značně liší. Pro řešení podnikových problémů přítomných v podnikovém informačním systému je vytvořen datový sklad. Datové sklady jsou obvykle vytvářeny a získávány centrálně řízenými organizacemi, jako jsou klasické organizace informační technologie, například banka. Datový sklad sestavuje celá korporace.

Datové tržiště je vyvinuto tak, aby vyhovovalo potřebám řešení specifické homogenní řady problémů. Jedna společnost tedy může mít mnoho různých datových trhů, z nichž každý má svůj vlastní vzhled a obsah.

Dalším rozdílem je granularita dat, protože datový trh obsahuje již agregovaná data. Naopak nejpodrobnější data obsahuje datový sklad.

Protože úroveň integrace v datových tržištích je vyšší než ve skladech, nelze granularitu datového tržiště snadno rozložit na granularitu skladu. Vždy ale můžete jít opačným směrem a jednotlivá data agregovat do zobecněných ukazatelů.

Na rozdíl od skladu obsahuje datové tržiště jen malé množství historických informací, vázaných pouze na krátké časové období a významných až v okamžiku, kdy splňují požadavky na řešení problému. Datové tržiště lze považovat za logicky nebo fyzicky oddělené podmnožiny datového skladu. Na Obr. Obrázek 2.17 ukazuje vztah mezi datovými tržišti a datovými sklady na příkladu bankovního odvětví.

Data marts jsou obvykle hostována ve vrstvené technologii, která je optimální pro flexibilitu analýzy, ale není optimální pro velké objemy dat.

Struktura datových tržišť je také zaměřena na vícerozměrnou organizaci dat ve formě krychle. Jejich výstavba je však vzhledem k omezenému informačnímu rozsahu, který odpovídá potřebám jedné funkční oblasti, mnohem jednodušší a výnosnější.

Rýže. 2.17. Vztah mezi datovými tržišti a datovým skladem

Existují dva typy datových trhů – závislé a nezávislé. Závislý datový trh je ten, jehož zdrojem je datový sklad. Zdroj nezávislý datový trh je primární prostředí softwarové aplikace. Závislé datové tržiště jsou stabilní a mají robustní architekturu. Nezávislé datové tržiště jsou nestabilní a mají nestabilní architekturu, alespoň při přenosu dat.

Je třeba poznamenat, že data marts jsou ideálním řešením nejvýznamnějšího konfliktu v návrhu datového skladu – výkon versus flexibilita. Obecně platí, že čím standardizovanější a flexibilnější je model datového skladu, tím méně efektivní je při odpovídání na dotazy. Je to dáno tím, že požadavky vstupující do standardně navrženého systému vyžadují podstatně více přípravných operací než v optimálně navrženém systému. Přesměrováním všech uživatelských dotazů na datové tržiště při zachování flexibilního modelu datového skladu mohou vývojáři dosáhnout flexibility a dlouhodobé stability v návrhu skladu a také optimálního výkonu pro uživatelské dotazy.

Jakmile jsou data uložena v úložišti, lze je distribuovat mezi mnoho datových trhů pro přístup podle uživatelských dotazů. Tyto datové tržiště mohou mít mnoho podob – od databází klient-server po desktopové databáze, OLAP- kostky nebo dokonce dynamické tabulky. Výběr nástrojů pro uživatelské dotazy může být široký a odrážet preference a zkušenosti konkrétních uživatelů. Široká škála takových nástrojů a jejich snadné použití z nich učiní nejméně nákladnou část implementace projektu datového skladu. Pokud jsou data ve skladu dobře strukturovaná a mají ověřenou kvalitu, pak se jejich přenos do jiných datových trhů stane rutinní a nízkonákladovou operací.

Použití technologií data mart, závislých i nezávislých, nám umožňuje řešit problém konsolidace dat z různých zdrojů, abychom co nejefektivněji vyřešili problémy analýzy dat. V tomto případě mohou být zdrojem různé účetní a referenční systémy, které se liší architekturou a funkčností, zejména geograficky rozptýlené.

Existuje několik způsobů, jak sdílet databázi Accessu, v závislosti na vašich potřebách a dostupnosti zdrojů. Tento článek popisuje dostupné možnosti a výhody každého z nich a poskytuje zdroje dodatečné informace o pracovních metodách.

Chcete-li změnit strukturu databáze, musíte mít v počítači nainstalovaný Access.

V tomto článku

Sdílení dat pomocí síťových složek

Toto je nejjednodušší možnost s minimální požadavky, ale poskytuje nejméně funkcí. Při této metodě je databázový soubor uložen na sdíleném síťovém disku a všichni uživatelé jej používají současně. Protože jsou všechny databázové objekty používány současně, může data měnit více uživatelů současně, což omezuje spolehlivost a dostupnost. Výkon může být také ovlivněn, protože všechny databázové objekty jsou odesílány přes síť.

Tato volba je vhodná v případě, že databázi bude využívat více lidí současně a uživatelé nebudou muset měnit strukturu databáze.

Poznámka: Tato metoda je méně bezpečná než jiné metody sdílení databáze, protože každý uživatel má úplnou kopii databázového souboru, což zvyšuje riziko neoprávněného přístupu.

Sdílení databáze pomocí síťové složky

Pokud neexistuje žádná sdílená síťová složka, musíte ji nakonfigurovat.

Další informace o tomto naleznete v nápovědě k operačnímu systému počítače, který bude použit ke sdílení databáze. Pokud je sdílená složka zapnutá síťový server, možná budete potřebovat pomoc od správce sítě.

Aplikace Access musí být nakonfigurována tak, aby se otevírala ve sdíleném režimu na počítačích všech uživatelů. Tento režim je výchozí, ale toto je třeba zkontrolovat: pokud uživatel otevře databázi ve výhradním režimu, ostatní uživatelé nebudou moci s daty pracovat. Na každém počítači postupujte podle níže uvedených kroků.

1. Spusťte Access a na kartě Soubor vybrat předmět Možnosti.

   V okně Možnosti přístupu vybrat předmět Možnosti klienta.

Zkopírujte soubor databáze do sdílené složky. Dále nakonfigurujte atributy souboru tak, aby umožňovaly čtení/zápis do databázového souboru. Chcete-li databázi používat, musíte mít k ní přístup pro čtení a zápis.

V počítači každého uživatele vytvořte zástupce souboru databáze. V dialogovém okně Vlastnosti zástupce zadejte ve vlastnosti cestu k souboru databáze cílová, pomocí adresy UNC namísto písmene připojené jednotky. Například místo cesty F:\sample.accdb označte cestu \\název počítače\shared.accdb.

Poznámka: Uživatelé mohou tuto akci provést sami.

Sdílení rozdělené databáze

Tato metoda je užitečná, pokud nemáte web SharePoint nebo databázový server. Obecný přístup ke sdíleným databázím lze přistupovat přes síť nebo prostřednictvím webu SharePoint. Když je databáze rozdělena na oddíly, je reorganizována do dvou souborů: serverová databáze, která obsahuje datové tabulky, a klientská databáze, která obsahuje všechny ostatní databázové objekty (například dotazy, formuláře, sestavy). Každý uživatel pracuje s daty pomocí lokální kopie externí databáze.

Výhody dělení databáze

Zvýšená produktivita. Přes síť jsou sdílena pouze data, nikoli tabulky, dotazy, formuláře, sestavy, makra nebo moduly.

Zvýšená dostupnost Databázové transakce, jako je úprava záznamů, jsou rychlejší.

Vylepšené zabezpečení. Uživatelé přistupují k back-endové databázi prostřednictvím propojených tabulek; Je méně pravděpodobné, že by útočníci mohli získat neoprávněný přístup k datům prostřednictvím klientské databáze.

Zvýšená spolehlivost Pokud uživatel narazí na problém a databáze se neočekávaně zavře, jakékoli poškození databázového souboru je obvykle omezeno na kopii klientské databáze, kterou má uživatel otevřenou.

Flexibilní vývojové prostředí Každý uživatel může nezávisle vyvíjet dotazy, formuláře, sestavy a další databázové objekty, aniž by to ovlivnilo práci ostatních uživatelů. Navíc můžete vyvíjet a distribuovat novou verzi klientské databáze, aniž byste narušili přístup k datům uloženým na backendu databáze.

Pokud vám tato metoda vyhovuje, přejděte k pokynům v článku Rozdělení databáze Accessu.

Sdílení databáze na webu SharePoint

Pokud máte server se službou SharePoint (zejména s Access Services), existuje několik možných dobré možnosti. Integrace SharePoint pomáhá zajistit snadnější přístup k vaší databázi. Když publikujete webovou databázi, Access Services vytvoří web SharePoint, který obsahuje databázi. Všechny databázové objekty a samotná data se přesunou do seznamů SharePoint na tomto webu.

Publikovaná databáze je umístěna na internetu. Můžete vytvářet webové formuláře a sestavy, které se spouštějí v okně prohlížeče, stejně jako standardní objekty Accessu (někdy nazývané klientské objekty, aby se odlišily od webových objektů). Chcete-li používat klientské objekty Accessu, musíte nainstalovat aplikaci Access, ale všechny databázové objekty uložené na SharePointu jsou sdílené.

Poznámka: Pokud máte v počítači nainstalovaný Access, můžete používat klientské objekty z webové databáze, nejen webové databázové objekty.

Access Services poskytuje platformu pro vytváření bezplatných dat, která lze používat na internetu. Webové databáze se vytvářejí a publikují pomocí Access 2010 a SharePointu a webovou databázi pak můžete používat prostřednictvím webového prohlížeče.

Formuláře, sestavy a makra rozhraní běží v prohlížeči.

Pokud používáte webovou databázi, data jsou uložena v seznamy SharePoint: Všechny tabulky se převedou na seznamy SharePoint a ze záznamů se stanou položky seznamu. To vám umožní řídit přístup k vaší webové databázi pomocí oprávnění SharePointu.

Dotazy a datová makra běží na serveru: Veškeré zpracování SQL probíhá na serveru. To zlepšuje výkon sítě, protože se přes ni přenášejí pouze sady výsledků.

Uložení databáze do knihovny dokumentů

Databázi lze uložit do libovolné knihovny dokumentů SharePointu. Tato metoda je podobná ukládání databáze do síťové složky a poskytuje pohodlný způsob řízení přístupu k databázi. Při propojení se seznamy SharePoint jsou sdílena pouze data, nikoli databázové objekty. Každý uživatel dostane svou vlastní kopii databáze.

Pokud například váš web SharePoint obsahuje seznamy, které sledují problémy služeb zákazníkům a ukládají data zaměstnanců, můžete v Accessu vytvořit databázi, která slouží jako rozhraní k těmto seznamům. Můžete tvořit Přístupové dotazy k analýze těchto problémů a zpráv Access k formátování a publikování písemných zpráv pro týmové schůzky. Pokud mají uživatelé na svých počítačích nainstalovaný Access, můžete sdílet dotazy a sestavy Accessu pro seznam SharePointu pomocí nabídky Výkon. Při zobrazení seznamu na webu SharePoint budou uživatelé moci vyhledat a otevřít dotazy, sestavy a další objekty Accessu z nabídky Výkon. Pokud uživatelé nemají Access, mohou stále využívat data ze seznamů pomocí zobrazení SharePointu.

Otevřete databázi, kterou chcete sdílet.

Na kartě Soubor vybrat předmět Uložit jako.

Poznámka: Pokud používáte Access 2010, vyberte položky Soubor > Uložit a publikovat > Uložit databázi jako > SharePoint.

V dialogovém okně Uložit na SharePoint Přejděte do příslušné knihovny dokumentů.

Zkontrolujte název a typ databázového souboru, v případě potřeby je změňte a klikněte na tlačítko Uložit.

Další informace najdete v tématech Publikování ve službách Access a Import a propojení dat se seznamem SharePointu.

Sdílejte databázi propojením se seznamy SharePointu

Tato metoda má stejné výhody jako použití rozdělené databáze a umožňuje každému uživateli upravit svou vlastní kopii databáze, protože sdílení data jsou přístupná prostřednictvím webu SharePoint. I když to neposkytuje výhody publikování databáze na webu SharePoint, poskytuje to výhodu centralizace dat. Protože se data nacházejí v seznamech SharePointu, lze je sdílet v síti pomocí funkcí SharePointu.

Tato metoda zahrnuje tři hlavní kroky.

Přesouvání dat do seznamů SharePoint.

Vytvořte odkazy na tyto seznamy.

Distribuce databázových souborů.

K dokončení prvních dvou kroků můžete použít Průvodce migrací webu SharePoint a poslední krok můžete dokončit pomocí jakýchkoli dostupných nástrojů.

Použijte Průvodce exportem tabulek do SharePointu

Na kartě Práce s databázemi ve skupině Přenos dat klikací prvek SharePoint.

Poznámka: Tento prvek je dostupný pouze v případě, že je databázový soubor uložen ve formátu ACCDB.

Podle průvodce exportujte tabulky do SharePointu; konkrétně zadejte umístění webu SharePoint. Chcete-li proces zrušit, klepněte na tlačítko zrušení.

Chcete-li zobrazit další informace o migraci, na poslední stránce průvodce zaškrtněte políčko Podrobnosti.

Tato stránka obsahuje informace o tom, které tabulky jsou přidruženy k seznamům, a také informace o umístění zálohy a URL databáze. Zobrazuje také varování v případě problémů s migrací a označuje umístění tabulky protokolů, kde můžete zobrazit další informace o problémech.

Po dokončení všech kroků průvodce klepněte na tlačítko Připraven.

Pokud průvodce zobrazí varování, měli byste si prohlédnout tabulku protokolu a provést potřebnou akci. Můžete například chtít rozbalit některá pole nebo je převést na jiné datové typy, které jsou kompatibilní se seznamy SharePoint.

Poznámka: Chcete-li zobrazit seznamy na webu SharePoint, klikněte na tlačítko Snadné spuštění Seznamy nebo vyberte položku Zobrazit veškerý obsah webu. Možná budete muset obnovit stránku ve webovém prohlížeči. Chcete-li zobrazit seznamy v podokně Snadné spuštění na webu SharePoint nebo změnit jiná nastavení (například zapnout sledování verzí), můžete změnit nastavení seznamu na webu SharePoint. Další informace najdete v nápovědě pro váš web SharePoint.

Sdílení databáze pomocí serveru

Databázi můžete sdílet pomocí aplikace Access a databázového serveru (jako je SQL Server). Tato metoda poskytuje mnoho výhod, ale vyžaduje další software - databázový server.

Tato metoda je podobná sdílení databáze, protože tabulky jsou uloženy online a každý uživatel má místní kopii souboru databáze Data společnosti Microsoft Access obsahující odkazy na tabulky, dotazy, formuláře, sestavy a další databázové objekty. Tato možnost se používá, pokud je databázový server dostupný a všichni uživatelé mají nainstalovaný Access. Výhody této metody se liší v závislosti na použitém softwaru databázového serveru, ale obecně zahrnují uživatelské účty a selektivní přístup k datům, vynikající dostupnost dat a pohodlné vestavěné nástroje pro správu dat. Většina aplikací databázového serveru navíc funguje dobře se staršími verzemi Accessu, takže není nutné, aby všichni uživatelé používali stejnou verzi. Sdílí se pouze tabulky.

Výhody sdílení databáze pomocí databázového serveru

Vysoký výkon a škálovatelnost V mnoha případech poskytuje databázový server lepší výkon než jeden databázový soubor aplikace Access. Mnoho produktů databázových serverů také poskytuje podporu pro velmi velké databáze o velikosti přibližně 500 na interval (2 GB) pro soubor databáze aplikace Access (dva gigabajty). Produkty databázových serverů obvykle pracují velmi efektivně tím, že zpracovávají dotazy paralelně (pomocí více nativních vláken v jednom procesu ke zpracování uživatelských dotazů) a také minimalizují dodatečné požadavky na paměť při přidávání nových uživatelů.

Zvýšená dostupnost Většina produktů databázových serverů umožňuje vytvářet zálohy databáze při jejím používání. Uživatelé tak nemusí kvůli zálohování dat násilně zavírat databázi. Kromě toho databázový server obvykle velmi efektivně zpracovává souběžné úpravy a zamykání záznamů.

Zvýšená bezpečnost Není možné úplně ochránit databázi. Produkty databázových serverů však nabízejí silné zabezpečení, které vám může pomoci chránit vaše data před neoprávněným použitím. Většina produktů databázových serverů nabízí zabezpečení založené na účtech, což vám umožňuje určit, kdo může zobrazit které tabulky. I když je rozhraní získáno nesprávně, neoprávněné použití dat je zakázáno zabezpečením založeným na účtu.

Možnosti automatického obnovení V případě selhání systému (jako je pád operačního systému nebo výpadek napájení) mají některé produkty databázových serverů mechanismy automatické obnovení, které obnoví databázi do posledního stavu konzistence během několika minut, bez potřeby DBA. účastnit se.

Zpracování na serveru Použití Accessu v konfiguraci klient-server pomáhá snížit provoz v síti tím, že před odesláním výsledků klientovi zpracuje databázové dotazy na serveru. Zpracování serveru je obvykle efektivnější, zejména při práci s velkými datovými sadami.

Základní kroky pro používání Accessu s databázovým serverem

Faktory, které je třeba vzít v úvahu při výběru metody

Požadavky na metodu	Rozdělení databáze	Síťová složka	web SharePoint	Databázový server
Nutnost dostupnosti software databázového serveru
Potřeba SharePointu
Nutnost dostupnost Přístup ke službám na serveru SharePoint			Záleží na scénáři: Propojení se seznamy a uložení do knihovny dokumentů nevyžaduje Access Services; Publikování jako webová databáze nebo webová aplikace vyžaduje Access Services.
Dostupnost dat		Vhodné pro malé skupiny, pokud se data mění jen málo	Nejlepší. Vhodné pro případy offline použití.	Nejlepší
Bezpečnost	Závisí na dodatečných opatřeních	Nejméně bezpečný způsob	Nejlepší	Nejlepší
Flexibilita	Flexibilní způsob. Nové databázové funkce lze snadno vyvíjet bez přerušení. Uživatelé mohou změnit strukturu ve své vlastní kopii.	Méně flexibilní způsob. Vývoj lze provést pomocí offline kopie databáze, která je následně nahrazena. Uživatelé nemají možnost individuálně měnit strukturu databáze.	Flexibilní způsob. Pomocí oprávnění SharePointu můžete řídit přístup a měnit design. Umožňuje použití některých databázových objektů, jako jsou formuláře, způsobem založeným na prohlížeči.	Flexibilní způsob. Nové databázové funkce lze snadno vyvíjet bez přerušení. Uživatelé mohou měnit strukturu objektů ve své vlastní kopii.

30.03.2017 3,4 tis

Dodržováním zásad popsaných v tomto článku můžete vytvořit databázi, která funguje podle očekávání a lze ji v budoucnu přizpůsobit novým požadavkům. Podíváme se na základní principy návrh databáze a také způsoby, jak jej optimalizovat.

Proces návrhu databáze

Správně strukturovaná databáze:

• Pomáhá vám ušetřit peníze místo na disku odstraněním nepotřebných dat;
• Udržuje přesnost a integritu dat;
• Poskytuje pohodlný přístup k datům.

Vývoj databáze zahrnuje následující fáze:

1. Analýza požadavků nebo určení účelu databáze;
2. Organizace dat v tabulkách;
3. Specifikace primárních klíčů a analýza vztahů;
4. Normalizace tabulek.

Uvažujme každý fáze návrhu databáze více informací. Upozorňujeme, že tento tutoriál pokrývá model relační databáze Edgara Codda napsaný v SQL ( spíše než hierarchické, síťové nebo objektové modely).

Analýza požadavků: Určení účelu databáze

Pokud například vytváříte databázi pro veřejnou knihovnu, musíte zvážit, jak by měli k databázi přistupovat čtenáři i knihovníci.

Zde je několik způsobů, jak shromáždit informace před vytvořením databáze:

• Dotazování lidí, kteří to budou používat;
• Analýza obchodních formulářů, jako jsou faktury, plány, průzkumy;
• Zvážení všech existujících datových systémů ( včetně fyzických a digitálních souborů).

Začněte sběrem existujících dat, která budou zahrnuta do databáze. Dále určete typy dat, která chcete uložit. Stejně jako objekty, které tato data popisují. Například:

klienti

• Adresa;
• Město (*): Stát (*): PSČ;
• Emailová adresa.

Zboží

• Název;
• Cena;
• Množství na skladě;
• Množství na objednávku.

Objednávky

• Číslo objednávky;
• Obchodní zástupce;
• Datum;
• Produkt;
• Množství;
• Cena;
• Cena.

Při návrhu relační databáze se tyto informace později stanou součástí datového slovníku, který popisuje tabulky a pole databáze. Rozdělte informace na co nejmenší části. Zvažte například rozdělení pole poštovní adresa a stát, abyste mohli filtrovat lidi podle státu, ve kterém žijí.

Jakmile se rozhodnete, jaká data budou zahrnuta do databáze, odkud budou data pocházet a jak budou použita, můžete začít plánovat vlastní databázi.

Struktura databáze: stavební bloky

Dalším krokem je vizuální reprezentace databáze. K tomu potřebujete přesně vědět, jak jsou relační databáze strukturovány. V rámci databáze jsou související data seskupena do tabulek, z nichž každá se skládá z řádků a sloupců.

Chcete-li převést seznamy dat na tabulky, začněte vytvořením tabulky pro každý typ objektu, jako jsou produkty, prodeje, zákazníci a objednávky. Zde je příklad:

Každý řádek v tabulce se nazývá záznam. Záznamy obsahují informace o něčem nebo někom, například o konkrétním zákazníkovi. Sloupce (také nazývané pole nebo atributy) obsahovat stejný typ informací, které se zobrazují pro každý záznam, například adresy všech zákazníků uvedených v tabulce.

Chcete-li zajistit konzistenci napříč záznamy při navrhování databázového modelu, přiřaďte každému sloupci vhodný datový typ. Mezi běžné datové typy patří:

• CHAR - konkrétní délka textu;
• VARCHAR - text různé délky;
• TEXT - velké množství textu;
• INT je kladné nebo záporné celé číslo;
• FLOAT , DOUBLE — čísla s pohyblivou řádovou čárkou;
• BLOB - binární data.

Některé DBMS také nabízejí datový typ Autonumber, který automaticky generuje jedinečné číslo na každém řádku.

Ve vizuální reprezentaci databáze bude každá tabulka reprezentována blokem v diagramu. V záhlaví každého bloku by mělo být uvedeno, co data v této tabulce popisují, a atributy by měly být uvedeny níže:

Na navrhování informační databáze musíte se rozhodnout, které atributy, pokud nějaké, budou sloužit jako primární klíč pro každou tabulku. Primární klíč ( PK) je jedinečný identifikátor pro tento objekt. S ním můžete vybrat data konkrétního zákazníka, i když znáte pouze tuto hodnotu.

Atributy zvolené jako primární klíče musí být jedinečné, neměnné a nelze je nastavit na NULL ( nemohou být prázdné). Z tohoto důvodu jsou vhodným primárním klíčem objednávková čísla a uživatelská jména, nikoli však telefonní čísla nebo adresy. Jako primární klíč můžete také použít několik polí současně ( tomu se říká složený klíč).

Když přijde čas na vytvoření skutečné databáze, implementujete logickou i fyzickou strukturu prostřednictvím jazyka pro definici dat podporovaného vaším DBMS.

Musíte také vyhodnotit velikost vaší databáze, abyste zajistili, že můžete dosáhnout požadované úrovně výkonu a že máte dostatek místa pro uložení dat.

Vytváření vztahů mezi entitami

Nyní, když byla data převedena do tabulek, musíme analyzovat vztahy mezi nimi. Složitost databáze je určena počtem prvků interagujících mezi dvěma souvisejícími tabulkami. Určení složitosti pomáhá zajistit, že svá data rozdělíte do tabulek tím nejefektivnějším způsobem.

Každý objekt lze propojit s jiným pomocí jednoho ze tří typů vztahů:

Komunikace jeden na jednoho

Pokud existuje pouze jedna instance objektu A pro každou instanci objektu B, říká se, že mají vztah jedna ku jedné ( často označované 1:1). Tento typ vztahu můžete označit v ER diagramu čárou s pomlčkou na každém konci:

Pokud nemáte důvod tato data při návrhu a vývoji databází oddělovat, poměr 1:1 obvykle naznačuje, že je lepší tyto tabulky spojit do jedné.

Ale za určitých okolností má větší smysl vytvářet tabulky se vztahy 1:1. Máte-li volitelné datové pole, například "popis", které je pro mnoho záznamů ponecháno prázdné, můžete přesunout všechny popisy do samostatné tabulky, čímž eliminujete prázdná pole a zlepšíte výkon databáze.

Aby byla zajištěna správná korelace dat, budete muset do každé tabulky zahrnout alespoň jeden identický sloupec. S největší pravděpodobností to bude primární klíč.

Komunikace jeden k mnoha

K těmto vztahům dochází, když záznam v jedné tabulce souvisí s více záznamy v jiné tabulce. Jeden zákazník může například zadat mnoho objednávek nebo si čtenář může půjčit několik knih z knihovny. Vztahy jedna k mnoha (1:M) jsou označeny takzvanou vránou stopou, jako v tomto příkladu:

Chcete-li implementovat vztah 1:M, přidejte primární klíč z "jedné" tabulky jako atribut do druhé tabulky. Pokud je takto primární klíč určen v jiné tabulce, nazývá se cizí klíč. Tabulka na straně "1" vztahu je nadřazenou tabulkou k podřízené tabulce na druhé straně.

Komunikace mnoho s mnoha

Když několik objektů tabulky může souviset s několika objekty jiné. Říkají, že mají spojení" mnoho-k-mnoho» ( M:N). Například v případě studentů a kurzů, protože student může absolvovat mnoho kurzů a každý kurz může navštěvovat mnoho studentů.

V ER diagramu jsou tyto vztahy znázorněny pomocí následujících řádků:

Při návrhu struktury databáze je nemožné implementovat tento druh spojení. Místo toho je musíte rozdělit do dvou vztahů jeden k mnoha.

Chcete-li to provést, musíte mezi těmito dvěma tabulkami vytvořit novou entitu. Pokud existuje vztah M:N mezi prodejem a produkty, můžete to nazvat nový objekt « prodané_produkty“, protože bude obsahovat údaje pro každý prodej. Tabulka prodeje i tabulka produktů budou mít vztah 1:M s prodanými_produkty . Tento druh mezilehlého objektu v různé modely nazývaná tabulka odkazů, objekt asociace nebo tabulka odkazů.

Každá položka v tabulce vztahů bude odpovídat dvěma entitám ze sousedních tabulek. Například tabulka spojení mezi studenty a kurzy může vypadat takto:

Povinné nebo ne?

Dalším způsobem, jak analyzovat spojení, je zvážit, která strana vztahu musí existovat, aby existovala ta druhá. Volitelná strana může být označena kroužkem na řádku. Například země musí existovat, aby mohla mít zástupce v OSN, a ne naopak:

Dva objekty mohou být na sobě závislé ( jedno bez druhého nemůže existovat).

Rekurzivní spojení

Někdy při návrhu databáze ukazuje tabulka sama na sebe. Například tabulka zaměstnanců může mít atribut "manažer", který odkazuje na jinou osobu ve stejné tabulce. Tomu se říká rekurzivní odkazy.

Extra připojení

Cizí spojení jsou ta, která jsou vyjádřena více než jednou. Obvykle můžete jeden z těchto odkazů smazat, aniž byste žádný ztratili důležitá informace. Pokud má například objekt „studenti“ přímý vztah s jiným objektem zvaným „učitelé“, ale má také nepřímý vztah s učiteli prostřednictvím „předmětů“, musíte vztah mezi „studenty“ a „učiteli“ odstranit. Protože jediný způsob, jak jsou studenti přidělováni učiteli, je prostřednictvím předmětů.

Normalizace databáze

Po předběžném návrhu databáze můžete použít pravidla normalizace, abyste zajistili správnou strukturu tabulek.

Přitom ne všechny databáze je nutné normalizovat. Obecně platí, že databáze se zpracováním transakcí v reálném čase ( OLTP), musí být normalizovány.

Databáze s interaktivním analytickým zpracováním ( OLAP), umožňující snadnější a rychlejší analýzu dat, může být s určitým stupněm denormalizace efektivnější. Hlavním kritériem je zde rychlost výpočtů. Každá forma nebo úroveň normalizace zahrnuje pravidla spojená s nižšími formami.

První forma normalizace

První forma normalizace ( zkráceně 1NF) uvádí, že během logický design Databáze Každá buňka v tabulce může mít pouze jednu hodnotu, nikoli seznam hodnot. Proto tabulka, jako je ta níže, neodpovídá 1NF:

Možná budete chtít obejít toto omezení rozdělením dat do dalších sloupců. Ale to je také proti pravidlům: tabulka se skupinami duplicitních nebo úzce souvisejících atributů nevyhovuje první formě normalizace. Například tabulka níže neodpovídá 1NF:
Místo toho během návrhu fyzické databáze rozdělte data do více tabulek nebo záznamů, dokud každá buňka nebude obsahovat pouze jednu hodnotu a nebudou zde žádné další sloupce. Taková data se považují za členěná na jejich nejmenší použitelnou velikost. Ve výše uvedené tabulce můžete vytvořit další tabulku " Podrobnosti o prodeji“, která spojí konkrétní produkty s prodejem. „Prodej“ bude mít vztah 1:M s „ Podrobnosti o prodeji».

Druhá forma normalizace

Druhá forma normalizace ( 2NF) stanoví, že každý z atributů musí zcela záviset na primárním klíči. Každý atribut musí záviset přímo na celém primárním klíči a ne nepřímo prostřednictvím jiného atributu.

Například atribut „věk“ závisí na „narozeniny“, který zase závisí na „ID studenta“, má částečnou funkční závislost. Tabulka obsahující tyto atributy nebude odpovídat druhé formě normalizace.

Kromě toho tabulka s primárním klíčem sestávajícím z několika polí porušuje druhou formu normalizace, pokud jedno nebo více polí nezávisí na každé části klíče.

Tabulka s těmito poli tedy nebude odpovídat druhé formě normalizace, protože atribut „název produktu“ závisí na ID produktu, ale ne na čísle objednávky:

• Číslo objednávky (primární klíč);
• ID produktu (primární klíč);
• Jméno výrobku.

Třetí forma normalizace

Třetí forma normalizace 3NF) : Každý neklíčový sloupec musí být nezávislý na každém jiném sloupci. Pokud v návrh relační databáze změna hodnoty v jednom neklíčovém sloupci způsobí změnu jiné hodnoty, tato tabulka nevyhovuje třetí formě normalizace.

Podle 3NF nemůžete ukládat žádná odvozená data do tabulky, jako je například sloupec "Daň", který v příkladu níže přímo závisí na celkových nákladech na objednávku:

Svého času byly navrženy další formy normalizace. Včetně Boyce-Coddovy formy normalizace, forem čtyři až šest a normalizace doménového klíče, ale první tři jsou nejběžnější.

Vícerozměrná data

Někteří uživatelé mohou potřebovat přístup k více pohledům stejného datového typu, zejména v databázích OLAP. Mohou například chtít znát prodeje podle zákazníka, země a měsíce. V této situaci je lepší vytvořit centrální tabulku, na kterou mohou odkazovat tabulky zákazníků, zemí a měsíců. Například:

Pravidla integrity dat

Také pomocí nástroje pro návrh databází je nutné nakonfigurovat databázi s přihlédnutím ke schopnosti kontrolovat data z hlediska souladu s určitými pravidly. Mnoho DBMS, jako je Microsoft Access, automaticky aplikuje některá z těchto pravidel.

Pravidlo integrity uvádí, že primární klíč nikdy nemůže mít hodnotu NULL. Pokud se klíč skládá z více sloupců, žádný z nich nemůže mít hodnotu NULL. V opačném případě může nejednoznačně identifikovat položku.

Pravidlo referenční integrity vyžaduje, aby každý cizí klíč zadaný v jedné tabulce byl mapován na jeden primární klíč v tabulce, na kterou odkazuje. Pokud je primární klíč změněn nebo odstraněn, musí být tyto změny implementovány do všech objektů, na které tento klíč v databázi odkazuje.

Pravidla integrity obchodní logiky zajišťují, že data odpovídají určitým logickým parametrům. Například čas schůzky musí být v rámci standardní pracovní doby.

Přidávání indexů a pohledů

Index je seřazená kopie jednoho nebo více sloupců s hodnotami ve vzestupném nebo sestupném pořadí. Přidání indexu vám umožní rychleji najít záznamy. Namísto opětovného řazení pro každý dotaz může systém přistupovat k záznamům v pořadí určeném indexem.

I když indexy urychlují načítání dat, mohou zpomalit přidávání, aktualizaci a odstraňování dat, protože index musí být znovu vytvořen, kdykoli se záznam změní.

Pohled je uložený požadavek na data. Pohledy mohou obsahovat data z více tabulek nebo zobrazit část tabulky.

Pokročilé vlastnosti

Po návrh databázového modelu Databázi můžete upřesnit pomocí pokročilých vlastností, jako je text nápovědy, vstupní masky a pravidla formátování, která se vztahují na konkrétní schéma, pohled nebo sloupec. Výhodou této metody je, že jelikož jsou tato pravidla uložena v samotné databázi, bude prezentace dat konzistentní napříč více programy, které k datům přistupují.

SQL a UML

Unifikovaný Modelovací Jazyk ( UML) je další vizuální způsob vyjádření složitých systémů vytvořených v objektově orientovaném jazyce. Některé z konceptů zmíněných v tomto tutoriálu jsou v UML známé pod různými názvy. Například objekt v UML je znám jako třída.

UML se v dnešní době tak často nepoužívá. V současné době se používá akademicky a v komunikaci mezi vývojáři softwaru a jejich klienty.

Dobrý špatný

V moderní svět Data jsou stále důležitější a bez nadsázky můžeme říci, že svět je řízen daty. Proto je nyní velká pozornost věnována sběru, ukládání, analýze a prodeji dat. Klíčem k úspěšnému rozvoji moderního podnikání je shromažďování, systematizace a využívání například informací o vašich zákaznících, jako jsou jejich potřeby, nákupní preference atd. Tyto informace mohou pomoci při přijímání informovaných rozhodnutí ohledně praktické účinnosti propagačních nabídek, identifikaci nerentabilních obchodních segmentů, analýze poptávky po vyrobeném zboží nebo službách, sledování dynamiky obchodu s jednotlivými položkami a přezkoumání dalších klíčových faktorů. Databáze nám při správném používání poskytují tyto výhody oproti našim konkurentům.

Pokud jste vlastníkem malého podniku a ve své práci ještě nepoužíváte systém řízení vztahů se zákazníky (CRM nebo Customer Relationship Management), který automatizuje generování strategií interakce se zákazníky, pak úspěch vašeho podnikání podléhá určitým rizikům. . Pamatujte, že vaši konkurenti nespí!

Pojďme se podívat na to, jaký software můžete použít k vytvoření databáze přizpůsobené jedinečným potřebám vaší malé firmy, která bude shromažďovat denní, týdenní, měsíční nebo roční data.

Filemaker Pro 12

Tato databáze na dlouhou dobu nezaslouženě zmizela z dohledu administrátorů a vývojářů databází, ale od svého vzniku ji obchodní komunita milovala. Filemaker Pro, vytvořený společností Apple, funguje jako operační systém Systém Mac a dále systém Windows. Program je intuitivní a velmi snadno použitelný nástroj pro tvorbu vlastních databází s podporou poskytování dat na internetu, který je schopen generovat reporty v normálním i pokročilém režimu a lze jej integrovat s jinými databázovými systémy.

Microsoft Access 2010

Po dlouhou dobu systém správy databáze Access z balíčku Microsoft Office je nejoblíbenějším řešením pro většinu malých podniků. Nyní však čelí konkurenci jiných DBMS, které se snáze používají, lépe integrují s cloudovými systémy a nevyžadují rozsáhlé znalosti v oblasti vytváření, údržby databází a vývoje softwaru.

Pokud již databázi máte, je pravděpodobné, že byla vytvořena pomocí aplikace Microsoft Access. Nová verze 2010 vypadá a funguje lépe a ve srovnání s předchozími verzemi, jako je široce používaná verze 2003, se snáze používá. Navzdory skutečnosti, že tento DBMS začal být vytlačován konkurenty, stále zaujímá vedoucí postavení v tomto segmentu softwarového trhu.

Databáze Oracle Application Express (APEX) pro tento podnik

APEX je systém pro správu databází postavený na megaúspěšném databázovém stroji Oracle. APEX je k dispozici zcela zdarma, pokud jste již zákazníkem Oracle, a poskytuje pokročilejší systém pro vytváření obchodních aplikací než Microsoft Access nebo FileMaker Pro. Použití APEX však není tak jednoduché jako pouhé zadávání dat do tabulek, jak se to dělá v databázi Accessu.

Pokud již používáte Oracle nebo předpokládáte, že budete potřebovat pokročilejší možnosti správy databází, jako je integrace s jinými datovými systémy v budoucnu nebo zpracování velmi velkých objemů dat s rychlým výkonem, pak je APEX tou správnou volbou.

Zoho Creator je relativním nováčkem ve světě databází a nabízí intuitivní cloudový databázový systém. Vývojáři Zoho vytvořili skutečně spolehlivý, snadno použitelný systém, ve kterém rychle vytvoříte jednoduchou databázovou aplikaci bez velkých příprav. To bylo možné díky použití formulářů pro zadávání dat, velmi dobrému report builderu a integraci s jinými systémy, která je často nezbytná, když již máte existující databázi vytvořenou v jiných DBMS, nebo když používáte databáze vašich partnerů.

Při rozhodování manažer na jakékoli úrovni vychází z informací, které má k dispozici o předmětu řízení, proto efektivita jeho práce přímo závisí na kvalitativních charakteristikách těchto informací, jako je přiměřenost, úplnost, spolehlivost, včasnost, konzistence atd.

Informační systémy hrají a budou hrát v moderních podmínkách stále důležitější roli při dosahování strategických cílů organizace. To vede k novým požadavkům na informační systémy a jejich funkce. Takové systémy již nejsou jen nástrojem, který poskytuje zpracování informací oddělením a koncovým uživatelům v rámci organizace. Nyní musí vyrábět produkty a služby založené na informacích, které organizaci poskytnou konkurenční výhodu na trhu.

Informační systémy a informační technologie používané v jejich rámci jsou výsledkem určitých rozhodnutí manažerů v organizaci. Systémy a technologie si však zase diktují své vlastní specifické podmínky pro podnikání a mění organizace.

A bez ohledu na to, jaké konzultanty manažer v této oblasti přiláká, konečná rozhodnutí musí učinit on osobně. Manažer musí být schopen maximálně využít potenciálních výhod informačních technologií. Musí mít dostatečné znalosti k zajištění obecného řízení procesu aplikace a vývoje informačních technologií v organizaci a musí rozumět tomu, kdy jsou v této oblasti zapotřebí další zdroje nebo pomoc specialistů třetích stran.

Od vynálezu písma stojí lidstvo před úkolem ukládat data. Vedení záznamů má dlouhou historii, ale i přes vývoj od hliněných tabulek k papyru, poté k pergamenu a nakonec k papíru mělo celou dobu jedno společné – informace byly zpracovávány ručně.

S rozvojem civilizace hrozilo, že správa dokumentů pohltí veškerý čas specialistů – na konci 20. století mělo mnoho společností celá patra vyhrazená pro ukládání dokumentů, což, jak vidíte, není tak daleko od ukládání hliněných tabulek v sumerštině. archiv.

S příchodem počítačů se zjednodušila úloha správy dokumentů - ukládání dokumentů v elektronické podobě se ukázalo jako jednoduché, levné a pohodlné. Klíčová součást tohoto nová technologie byl tam software. Programování a používání počítačů je relativně snadné a třídění, analýza a zpracování dat je mnohem snazší. Pro běžné podnikové aplikace, jako je účetnictví, mzdy, inventář, správa předplatného, ​​bankovnictví a správa knihovny dokumentů, se objevily standardní balíčky.

Reakce na vznik těchto nových technologií byla docela předvídatelná: velké podniky uchovávaly ještě více informací a požadovaly stále rychlejší vybavení.

Průmyslové podniky, korporace, resortní struktury, vládní a řídící orgány nashromáždily v průběhu své činnosti velké objemy dat. Obsahují obrovské možnosti pro získávání užitečných analytických informací, na jejichž základě lze identifikovat skryté trendy, budovat strategii rozvoje a nacházet nová řešení.

Je zřejmé, že poskytnout rychlý přístup k většině dat není tak obtížné. Každý z nás se však setkal se situací, kdy se nalezení potřebného dokumentu, tak prozíravě uloženého minulý měsíc (či rok), ukázalo jako neúměrně pracné. V tuto chvíli se ukazuje, že tradiční možnosti souborových systémů již k úspěchu v moderním světě – ve světě informačních technologií – nestačí.

Dnes, aby získaly další konkurenční výhody, potřebuje většina tuzemských společností pro své podnikání seriózní IT podporu - systém transformace společnosti založený na využití informačních technologií a zaměřený na zvýšení efektivity organizace.

V druhé polovině 90. let si mnoho podniků začalo uvědomovat, že data, která mají k dispozici, jsou cenným aktivem, jehož správné využití může vytvářet konkurenční výhody. Velké společnosti shromažďují data o svých zákaznících, dodavatelích, produktech a službách po celá desetiletí. Uvědomili si však, že jejich data jsou uložena v nesourodých systémech a že je třeba tyto informace integrovat, aby se podnik dále rozvíjel. Potřeba integrovat podnikové informace dala podnět k vytvoření databází.

To platí zejména nyní, kdy se díky rychlému rozvoji elektronického obchodování mohou internetové firmy během několika měsíců nebo dokonce týdnů proměnit ve velké podniky. A v důsledku toho jejich databáze rychle porostou.

Obezřetný manažer by proto měl začít investovat do podpory IT, aniž by přivedl podnik do bodu rozhodnutí, kdy jeho společnost čelí nákladovému stropu. Skutečným problémem, kterému čelí vrcholové vedení společnosti, je uspořádání nashromážděných datových archivů tak, aby bylo snadné najít požadované informace. Hledání vzorů, trendů, anomálií a relevantních informací ve velké databázi je jednou z nových a nejzajímavějších oblastí správy dat.

Pro ty, kteří se již vydali touto cestou, je zřejmé, že databáze mohou radikálně změnit povahu práce jakékoli organizace umístěné v různých tematických oblastech a zbavit manažery rutinních postupů spojených s vyhledáváním informací v mnoha souborech, papírových dokumentech, referenčních dokumentech. knih a norem. Toto je nová etapa ve vývoji společnosti, která ji vede k další fázi evoluce, i když často za použití revolučních metod.

Snížení časových nákladů je pouze nepřímým efektem automatizace. hlavním úkolem rozvoj informačních technologií jiným způsobem - získáním zásadně nových kvalit organizací, které jí dávají významné konkurenční výhody. To je přesně ten případ, který hodně stojí.

Navíc je dnes instalace a správa databází mnohem méně komplikovaný proces než před několika lety. Návrh a správa databáze jsou z velké části automatizované. Software, který umožňuje tento problém vyřešit – vytvořit databázi, aktualizovat informace v ní uložené – a poskytnout k ní pohodlný přístup pro prohlížení a vyhledávání, se nazývá systém správy databází (DBMS).

Systém správy databází vytváří specifické prostředí pro práci uživatele na obrazovce počítače (uživatelském rozhraní). Kromě toho má DBMS určité provozní režimy a příkazový systém. Informační systémy jsou vytvářeny a fungují na bázi DBMS. Stojí za připomenutí, že systémy pro správu databází jsou jednou z nejúspěšnějších technologií v celém počítačovém průmyslu. Za databázové systémy a aplikace se ročně utratí miliardy dolarů. Systémy pro správu databází hrají výjimečnou roli v organizaci moderních průmyslových, instrumentálních a výzkumných informačních systémů.

Typické způsoby práce s DBMS jsou vytváření databáze, editace databáze, manipulace s databází, vyhledávání v databázi. Pro provoz v každém režimu existuje vlastní systém příkazů DBMS. Jakákoli uživatelská práce s databází je postavena ve formě algoritmu složeného z těchto příkazů. Takové algoritmy lze provádět v režimu přímého provádění (daný příkaz je okamžitě proveden) a v režimu automatického provádění, tj. v režimu programu.

Při vytváření databáze se uživatel snaží uspořádat informace podle různých charakteristik a rychle získat vzorek s libovolnou kombinací charakteristik. Uživatelé databáze mohou být různí aplikační programy, softwarových systémů, stejně jako odborníci na domény, kteří vystupují jako spotřebitelé nebo zdroje dat (nazývaní koncoví uživatelé).

Hlavním rysem dobře postaveného DBMS je jeho funkčnost prudké snížení mzdových nákladů na zpracování téměř všech interních a externích obchodních informací organizace. Takto navržená databáze umožňuje každému oddělení využívat informace zadané jedním uživatelem a odstraňuje nutnost duplikace dat ze strany podnikových divizí, což vede k výraznému snížení mzdových nákladů. Například informace o prodaném produktu jsou již v okamžiku vyskladnění stejně dostupné jak pro obchodního manažera, tak pro obchodní aplikace obecného účetnictví a mezd.

Mezitím, navzdory obrovským úspěchům spojeným s usnadněním instalace, správy a používání DBMS, zejména těch, které běží na osobní počítače nebo pracovní stanice, mnozí stále preferují použití souborového systému. Existuje tichý předpoklad, že s DBMS musí zacházet dobře vyškolený personál na plný úvazek a že většina uživatelů databází nemá žádné školení v databázové technologii. Pro uživatele je stále obtížné připojit se k DBMS, najít požadovaný adresář nebo názvy databází, kde jsou data uložena, a formulovat dotazy a aktualizovat databázi. Konektivita a přístupové paradigma souborový systém stále se zdají výrazně srozumitelnější.

Při přemýšlení o úspěchu svého podnikání by však manažer neměl takovým náladám podlehnout. Stojí za to připomenout, že nyní je snadné a levné vytvořit databázi. Dělají to miliony lidí a nemusíte se k tomu stát počítačovým operátorem. K tomu, abyste přeměnili hromady souborů s těžko dostupnými informacemi na moderní databázi, stačí kompetentní IT inženýr a několik školení pro zaměstnance. Zatímco opuštěním výhod DBMS z důvodu okamžitého pohodlí personálu a jeho neochoty měnit zavedený řád, manažer riskuje, že zůstane jediným uživatelem klínového písma na světě, který přešel na fonetickou abecedu.