Logický datový model. Pojem normalizace vztahů. Modelovací úrovně
Zavedení. Základní pojmy databáze
Databáze (DB) se používají v různých oborech a oblastech lidské činnosti. Mohou to být například databáze obsahující informace o zákaznících, produktech, poskytovaných službách, obchodních transakcích atd. Odborná literatura nabízí mnoho definic databází, které odrážejí určité aspekty subjektivního názoru různých autorů. Databází budeme rozumět soubor objektů (produktů, klientů, plateb) prezentovaných tak, že je lze vyhledávat a zpracovávat pomocí počítače. Prostředky pro správu těchto dat jsou tzv systémy pro správu databází(DBMS).
Historie vývoje systémů pro správu databází (DBMS) sahá desítky let zpět. První průmyslové DBMS od IBM byly uvedeny do provozu v roce 1968 a v roce 1975 se objevil první standard, který definoval řadu základních pojmů v teorii databázových systémů.
Rozvoj výpočetní techniky, vznik osobních počítačů, výkonných pracovních stanic a počítačových sítí vedl k rozvoji databázové techniky. Počítače se staly nástroji pro vedení záznamů, což nutilo vývojáře softwaru vytvářet systémy, které se běžně nazývají desktopové DBMS.
S příchodem lokálních sítí dochází k přenosu informací mezi počítači, takže nastal problém sladit data uložená a zpracovávaná na různých místech, ale logicky propojená. Řešení tohoto problému vedlo ke vzniku distribuovaných databází, které umožňují organizovat paralelní zpracování informací a udržovat integritu databází.
Pro distribuované ukládání dat a přístup k databázi jsou počítače sloučeny do lokálních, regionálních a dokonce i globálních sítí. V současné době se k budování sítí široce používá technologie klient-server. Systém klient-server je běžná lokální síť, která obsahuje skupinu klientských počítačů a jeden speciální počítač – server. Klientské počítače kontaktují server kvůli různým službám. Serverový počítač jim může posílat různé programy, například textový editor, práci s tabulkami, provádění databázových dotazů a vracení výsledků. Základní myšlenkou je, že každý počítač dělá to, co dělá nejefektivněji. Server načítá a aktualizuje data, klient provádí speciální výpočty a poskytuje výsledky koncovému uživateli. Nejprve servery vykonávaly nejjednodušší funkce: tiskové servery, souborové servery na žádost klienta o přístup k souboru, server odeslal soubor na klientský počítač; Databázový server je program, který běží na serverovém počítači a zajišťuje klientský přístup k databázi. Systém klient-server je tedy založen na principu dělby práce. Klient je počítač, se kterým uživatel pracuje, a serverový počítač provádí servis pro skupinu klientů: přistupuje k databázi, aktualizuje databázi atd. Progresivním způsobem kolektivního přístupu k databázím v posledních 20 letech je využití World Wide Web se skupinou jeho služeb.
Příklady serverů zahrnují:
Telekomunikační server, který poskytuje služby pro propojení lokální sítě s jinými sítěmi a servery;
Počítačový server, který umožňuje provádět výpočty, které nelze provádět na pracovních stanicích;
Diskový server, který má rozšířené externí paměťové prostředky a zpřístupňuje je pro použití klientskými počítači a případně dalšími servery;
Souborový server, který podporuje sdílené úložiště souborů pro všechny pracovní stanice;
Databázový server je vlastně běžný DBMS, který přijímá a obsluhuje požadavky přes lokální síť.
Ačkoli je obvykle jedna databáze uložena zcela na jediném místě sítě a spravována jediným serverem, databázové servery poskytují jednoduchou a levnou aproximaci distribuovaných databází, protože sdílená databáze je dostupná všem uživatelům v místní síti.
Přístup k databázi z aplikačního programu nebo uživatele se provádí přístupem do klientské části systému. Hlavním rozhraním mezi klientskou a serverovou částí je databázový jazyk SQL. Souhrnný název SQL server se vztahuje na všechny databázové servery založené na SQL. Opatrností při programování můžete vytvářet aplikační informační systémy, které jsou mobilní ve třídě SQL serverů.
Jednou z perspektivních oblastí DBMS je flexibilní konfigurace systému, ve které se rozložení funkcí mezi klientskou a uživatelskou částí DBMS určuje již při instalaci systému.
DBMS musí zajistit logickou integritu dat . Logická integrita databáze by měla zahrnovat udržování konzistentních a úplných informací, které přiměřeně odrážejí předmětnou oblast.
Tento koncept je spojen s požadavkem na integritu logických dat transakce. Transakce– skupina logicky kombinovaných po sobě jdoucích operací pro práci s daty, zpracovanými nebo zrušenými jako celek. Pokud například zadáte objednávku na určitý produkt, musíte provést řadu operací: zaregistrovat požadavek na produkt, rezervovat produkt, snížit tento produkt ve skladu. Pokud dojde v kterékoli z fází k porušení, dojde k selhání a naruší se logická integrita databáze. Aby se takovým případům předešlo, je zavedena transakce „Zadat objednávku“. , ve kterém musí být provedeny všechny potřebné operace na databázi, tzn. výrobek se prodá, jeho množství na skladě se sníží nebo dojde k návratu do původního stavu (výrobek se neprodá a jeho množství na skladě zůstává stejné).
DBMS interagují mezi databází a systémovými uživateli, stejně jako mezi databází a aplikačními programy, které implementují určité funkce zpracování dat.
DBMS poskytují spolehlivé ukládání velkých objemů komplexních dat do externí paměti počítače a efektivní přístup k nim. Mezi hlavní funkce DBMS patří:
· definice dat - jsou určeny informace, které mají být v databázi uloženy, je specifikována struktura dat, jejich typ a také je uvedeno, jak spolu budou data souviset;
· zpracování dat - data lze zpracovávat různými způsoby: vybrat libovolná pole, filtrovat a třídit data, kombinovat data a počítat součty;
· správa dat - jsou stanovena pravidla pro přístup k datům, jejich změny a přidávání nových dat, jsou stanovena pravidla pro hromadné využívání dat.
Hierarchický datový model
První hierarchické datové modely se objevily na konci 50. let. Představovaly stromovou strukturu, kde byla data distribuována napříč úrovněmi od master po slave a představovaly neorientovaný graf. Příklad hierarchického datového modelu je na Obr. 1.
Obrázek 1. Hierarchický datový model
Model je charakterizován počtem úrovní a uzlů. Každá úroveň představuje jeden nebo více objektů (dat) a může mít několik uzlů podřízených úrovní a spojení mezi všemi objekty jsou pevně fixována a jeden potomek nemůže mít více než jednoho předka. Hlavní typy datových struktur uvažovaného modelu jsou pole, záznam, soubor. Záznam je hlavní strukturní jednotkou zpracování dat a jednotkou výměny mezi RAM a externí pamětí. V modelu založeném na záznamech se databáze skládá ze záznamů v pevném formátu, které mohou být různých typů. Každý typ záznamu definuje pevný počet polí, z nichž každé má pevnou délku.
Pole je elementární jednotka logické organizace dat, která odpovídá samostatné, nedělitelné jednotce informace – detailu.
Záznam je kolekce polí odpovídajících logicky souvisejícím detailům. Struktura záznamu je určena složením a posloupností jeho jednotlivých polí, z nichž každé obsahuje základní údaje.
Soubor je sada záznamů stejné struktury s hodnotami v samostatných polích a pole mají jeden význam.
Typickým představitelem (nejznámějším a nejrozšířenějším) je IMS (Information Management System) DBMS od IBM. První verze systému se objevila v roce 1968.
2.2.2. Síťový datový model
Síťový model je chápán jako datový model podobný hierarchickému, ale umožňující volný systém spojení mezi uzly na různých úrovních. Jedná se o rozšíření hierarchického datového modelu. Síťové modely tedy umožňují přítomnost dvou nebo více „předků“ (obr. 2).
Na rozdíl od hierarchického modelu může mít potomek síťového modelu více než jednoho předka a jeden objekt může být jak hlavní, tak potomek. V tomto modelu jsou tedy vztahy mezi daty takové, že každý záznam může být podřízen záznamům z více než jednoho souboru. V síťových modelech můžete mít přímý přístup k libovolnému objektu pomocí klíče bez ohledu na úroveň, na které se v modelu nachází.
Výhodou síťového modelu je efektivita implementace z hlediska spotřeby paměti a rychlosti přístupu. Nevýhodou je zvýšená složitost datového schématu postaveného na jeho základě.
Rýže. 2. Datový model sítě
Typickým představitelem systémů založených na síťovém datovém modelu je DBMS IDMS (Integrated Database Management System), vyvinutý společností Cullinet Software, Inc. a zpočátku se zaměřoval na použití sálových počítačů (univerzálních počítačů) od IBM. Architektura systému vychází z návrhů Data Base Task Group (DBTG) organizace CODASYL (Conference on Data Systems Languages), která byla zodpovědná za definici programovacího jazyka COBOL. Zpráva DBTG byla publikována v roce 1971 a brzy poté se objevilo několik systémů podporujících architekturu CODASYL, včetně IDMS DBMS. IDMS v současné době vlastní Computer Associates.
Normalizace databáze
Při návrhu databází je nejdůležitější definovat struktury tabulek a vztahy mezi nimi. Chyby ve struktuře dat je obtížné a často nemožné programově opravit. Čím lepší je struktura dat, tím snazší je programování databáze. Teorie návrhu databáze obsahuje koncept normálních forem určených k optimalizaci struktury databáze. Normální formy jsou lineární posloupnost pravidel aplikovaných na databázi a čím vyšší je číslo normální formy, tím dokonalejší je struktura databáze. Normalizace je vícestupňový proces, ve kterém jsou databázové tabulky organizovány, odděleny a data uvedena do pořádku. Účelem normalizace je odstranit některé nežádoucí vlastnosti z databáze. Cílem je zejména eliminovat některé typy redundance dat a vyhnout se tak anomáliím při změnách dat. Anomálie změny dat jsou potíže při vkládání, úpravě a mazání dat, které vznikají v důsledku struktury databáze. Přestože existuje mnoho úrovní, obvykle stačí normalizace na Třetí normální formu.
Uvažujme příklad normalizace databáze řízení doručení objednávek. Neuspořádaná databáze „Prodej“ by sestávala z jedné tabulky (obr. 7).
Obr.7. DB "Prodej"
Každý záznam v tabulce obsahuje informace o několika objednávkách od jednoho zákazníka. Protože sloupec s informacemi o produktu obsahuje příliš mnoho dat, je obtížné získat z této tabulky uspořádané informace (například vytvořit sestavu o celkových nákupech pro různé typy produktů).
První normální forma
První normální forma určuje atomicitu všech dat obsažených ve sloupcích. Slovo „atom“ pochází z latinského „atomis“, což doslova znamená „nedělitelný“. První normální forma určuje, že na každé pozici definované řádkem a sloupcem je pouze jedna hodnota, nikoli pole nebo seznam hodnot. Výhody tohoto požadavku jsou zřejmé: pokud jsou seznamy hodnot uloženy v jednom sloupci, neexistuje snadný způsob, jak s těmito hodnotami manipulovat. To samozřejmě zvyšuje počet záznamů v tabulce.
Databázi „Prodej“ normalizujme do první normální podoby (obr. 8).
Obr.8. První normální forma
3.3.2. Druhá normální forma
Do druhého normálního formuláře se můžete přesunout z tabulky, která již odpovídá prvnímu normálnímu formuláři. Navíc musí být splněna následující podmínka: každé neklíčové pole musí být zcela závislé na primárním klíči.
Pojďme normalizovat databázi "Prodej" na druhou normální formu. Veškeré informace nesouvisející s jednotlivými objednávkami oddělíme do samostatné tabulky. Výsledkem je, že místo jedné tabulky „Prodej“ získáme dvě – tabulku „Objednávky“ (obr. 9) a tabulku „Produkty“ (obr. 10).
Obr.9. Tabulka "Objednávky"
Obr. 10 Tabulka "Produkty"
Typ produktu je tedy uložen pouze v jedné tabulce. Vezměte prosím na vědomí, že během normalizace se neztratí žádné informace.
3.3.3. Třetí normální forma
Tabulka je považována za vyhovující třetí normální formě, pokud odpovídá druhé normální formě a všechny neklíčové sloupce jsou vzájemně nezávislé. Sloupec, jehož hodnoty jsou odvozeny z dat z jiných sloupců, je jedním z příkladů závislosti.
Pojďme normalizovat databázi "Prodej" do třetí normální formy. Chcete-li to provést, odstraňte sloupec „Celkem“ z tabulky „Objednávky“. Hodnoty v tomto sloupci nezávisí na žádném klíči a lze je vypočítat pomocí vzorce ("Cena")*("Množství"). Byla tak získána databáze „Prodej“ s optimální strukturou, která se skládá ze dvou tabulek (obr. 11).
Rýže. 11. Normalizovaná databáze "Prodej"
3.2 Softwarová implementace databáze
Softwarová implementace databáze se provádí vytvořením cílového DBMS v jazyce definice dat (DDL). Příkazy DDL se kompilují a používají k vytváření schémat a prázdných databázových souborů. Ve stejné fázi jsou definovány všechny konkrétní uživatelské pohledy.
Aplikační programy jsou implementovány pomocí jazyků třetí nebo čtvrté generace. Některé prvky těchto aplikačních programů budou databázové zpracování transakcí napsané v jazyce manipulace s daty (DML) cílového DBMS a volané z programů v základním programovacím jazyce - například Visual Basic, C++, Java. Tato fáze také vytváří další součásti projektu aplikace, jako jsou obrazovky nabídek, formuláře pro zadávání dat a sestavy. Je třeba poznamenat, že mnoho existujících DBMS má své vlastní vývojové nástroje, které umožňují rychle vytvářet aplikace pomocí neprocedurálních dotazovacích jazyků, různých generátorů sestav, generátorů formulářů, grafických generátorů a generátorů aplikací.
Tato fáze také implementuje funkce ochrany databáze a podpory integrity aplikace. Některé z nich jsou popsány pomocí DDL, zatímco jiné může být nutné definovat jinými prostředky – například pomocí dalších utilit DBMS nebo vytvořením aplikačních programů, které implementují požadované funkce.
3.2.1. Vývoj aplikací
Vývoj aplikací je návrh uživatelského rozhraní a aplikačních programů určených pro práci s databází. Ve většině případů nelze návrh aplikace dokončit, dokud není dokončen návrh databáze. Na druhou stranu je databáze navržena tak, aby podporovala aplikace, a proto je nutné neustále vyměňovat informace mezi fázemi návrhu databáze a návrhu aplikací pro tuto databázi.
Musíte zajistit, aby všechny funkce požadované specifikacemi požadavků uživatele byly podporovány uživatelským rozhraním příslušných aplikací. To platí jak pro návrh aplikačních programů pro přístup k informacím v databázi, tak pro návrh transakcí, tzn. navrhování metod přístupu k databázi.
Kromě návrhu, jak může uživatel získat přístup k funkcím, které potřebuje, byste měli také navrhnout vhodné uživatelské rozhraní pro vaše databázové aplikace. Toto rozhraní by mělo poskytovat informace, které uživatel potřebuje, pro něj nejpohodlnějším způsobem.
3.2.2 Testování databáze
Testování je proces spouštění aplikačních programů za účelem nalezení chyb. Před použitím nového systému v praxi by měl být důkladně otestován. Toho lze dosáhnout vývojem promyšleného testovacího algoritmu využívajícího reálná data, která musí být strukturována tak, aby celý proces testování probíhal přísně sekvenčně a metodicky správně. Úkolem testování není proces demonstrování nepřítomnosti chyb, je nepravděpodobné, že by bylo možné prokázat nepřítomnost chyb v softwaru – spíše naopak, může pouze ukázat jejich přítomnost. Pokud bude testování provedeno úspěšně, pak budou jistě odhaleny chyby v aplikačních programech a databázových strukturách. Jako vedlejší produkt může testování pouze prokázat, že databáze a aplikační programy fungují v rámci svých specifikací a zároveň splňují stávající požadavky na výkon. Sběr statistických dat ve fázi testování nám navíc umožňuje stanovit ukazatele spolehlivosti a kvality vytvořeného softwaru.
Stejně jako u návrhu databáze musí být uživatelé nového systému zapojeni do procesu testování. V ideálním případě by testování systému mělo být prováděno na samostatné sadě zařízení, ale často to prostě není možné. Při použití skutečných dat je důležité nejprve vytvořit jejich záložní kopie pro případ, že by došlo k jejich poškození kvůli chybám. Po dokončení testování je proces tvorby aplikačního systému považován za dokončený a může být převeden do průmyslového provozu.
3.3 Provoz a údržba databáze
Provoz a údržba - podpora běžného fungování databáze.
V předchozích krocích byla databázová aplikace plně implementována a otestována. Systém nyní vstupuje do poslední fáze svého životního cyklu, která se nazývá provoz a údržba. Zahrnuje provádění akcí, jako jsou:
· sledování výkonu systému. Pokud výkon klesne pod přijatelnou úroveň, může být vyžadována další reorganizace databáze;
· údržba a modernizace (v případě potřeby) databázových aplikací. Nové požadavky jsou začleněny do databázové aplikace, když jsou znovu provedeny předchozí kroky životního cyklu.
Jakmile je databáze uvedena do provozu, její provoz by měl být nepřetržitě monitorován, aby bylo zajištěno, že výkon a další ukazatele splňují požadavky. Typický DBMS obvykle poskytuje různé nástroje pro správu databáze, včetně nástrojů pro načítání dat a sledování fungování systému. Tyto nástroje mohou monitorovat výkon systému a poskytovat informace o různých metrikách, jako je využití databáze, účinnost uzamykacího systému (včetně informací o počtu zablokování, ke kterému došlo) a vybrané strategie provádění dotazů. Správce databáze může tyto informace použít k vyladění systému za účelem zlepšení výkonu (například vytvořením dalších indexů), urychlení provádění dotazů, změny struktury úložiště nebo spojení či rozdělení jednotlivých tabulek.
Proces monitorování musí být udržován po celou dobu životnosti aplikace, což umožňuje kdykoli efektivní reorganizaci databáze, aby vyhovovala měnícím se požadavkům. Tyto změny poskytují informace o nejpravděpodobnějších vylepšeních databáze a zdrojích, které mohou být v budoucnu vyžadovány. Pokud DBMS, který používáte, nemá některé potřebné nástroje, bude je muset správce buď vyvinout sám, nebo zakoupit potřebné další nástroje od vývojářů třetích stran.
4. Microsoft Access DBMS
4.1. Účel a obecné informace o Microsoft Access DBMS
Systém Microsoft Access je systém pro správu databází, používá relační datový model a je součástí balíku aplikací Microsoft Office. Je navržen tak, aby ukládal, zadával, vyhledával a upravoval data a také je pohodlnou formou zobrazoval.
Oblasti použití Microsoft Access zahrnují následující:
· v drobném podnikání (účetnictví, zadávání objednávek, vedení informací o zákaznících, vedení informací o obchodních kontaktech);
· ve velkých korporacích (aplikace pro pracovní skupiny, systémy zpracování informací);
· jako osobní DBMS (adresář, správa investičního portfolia, kuchařka, katalogy knih, záznamy, videa atd.).
Access je jedním z nejvýkonnějších, nejpohodlnějších a nejjednodušších systémů pro správu databází. Protože je Access součástí Microsoft Office, sdílí mnoho stejných funkcí jako aplikace Office a může si s nimi vyměňovat informace. Když například pracujete v Accessu, můžete otevírat a upravovat soubory a používat schránku ke kopírování dat z jiných aplikací.
Nástroje pro vývoj objektů v Accessu jsou „průvodci“ a „konstruktoři“. Jedná se o speciální programy, které slouží k vytváření a úpravě tabulek, dotazů, různých typů formulářů a sestav. Typicky se „master“ používá k vytváření a „konstruktor“ se používá k úpravě objektů. Proces úprav zahrnuje změnu vzhledu nějakého objektu za účelem jeho vylepšení. Při úpravě formuláře můžete změnit názvy a pořadí polí, zvětšit nebo zmenšit velikost oblasti pro zadávání dat atd. K vytváření formulářů můžete použít „konstruktor“, ale je to velmi pracná práce. Access obsahuje speciální softwarové nástroje, které vám pomohou analyzovat datové struktury, importovat tabulky a textová data, zlepšit výkon aplikací a vytvářet a přizpůsobovat aplikace pomocí vestavěných šablon. Chcete-li své aplikace plně automatizovat, můžete k propojení dat s formuláři a sestavami použít makra.
Access implementuje správu relačních databází. Systém podporuje primární a cizí klíče. Zajišťuje integritu dat na úrovni jádra, což neumožňuje nekompatibilní operace aktualizace nebo odstranění. Tabulky v Accessu jsou vybaveny nástroji pro validaci dat, tzn. Neplatný vstup není povolen. Každé pole tabulky má svůj vlastní formát a standardní popisy, což usnadňuje zadávání dat. Access podporuje následující typy polí, včetně: Tab, Text, Numerický, Čítač, Měna, Datum/čas, MEMO, Boolean, Hypertextový odkaz, Objekt OLE, Příloha a Vypočítaná pole. Pokud v polích nejsou žádné hodnoty, systém poskytuje plnou podporu pro prázdné hodnoty.
Access umožňuje používat grafické nástroje, stejně jako Microsoft Word, Excel, PowerPoint a další aplikace, k vytváření různých typů grafů a tabulek. Můžete vytvářet histogramy, 2D a 3D grafy. Do formulářů a sestav Accessu můžete přidávat všechny druhy objektů: obrázky, diagramy, zvukové klipy a videoklipy. Propojením těchto objektů s rozvinutou databází lze vytvářet dynamické formuláře a sestavy. V Accessu můžete také použít makra k automatizaci určitých úloh. Umožňují otevírat a zavírat formuláře a sestavy, vytvářet nabídky a dialogová okna pro automatizaci vytváření různých aplikačních úloh.
V Accessu získáte kontextovou nápovědu kliknutím
4.2. Microsoft Access Objects
Po spuštění Access DBMS se objeví okno pro vytvoření nové databáze nebo pro práci s dříve vytvořenými databázemi, případně existujícími šablonami (obr. 12).
Rýže. 12. Spusťte aplikaci Access
Šablony jsou prázdné databázové struktury, ve kterých se definují typy polí, vytvářejí se základní objekty, navazují vztahy mezi tabulkami atd.
Při vytváření nové databáze Access otevře prázdnou tabulku obsahující jeden řádek a dva sloupce (obrázek 13).
Obr. 13. Nové okno databáze
Levá strana okna (navigační oblast) zobrazuje všechny vytvořené databázové objekty, přičemž vidíme pouze prázdnou tabulku, protože vytvořené objekty již nejsou v nové databázi (obr. 13). Mezi hlavní objekty Access DBMS patří následující.
Tabulky. Tabulky jsou hlavními objekty databází, protože ukládají všechna data a definují strukturu databáze. Databáze může obsahovat tisíce tabulek, jejichž velikost je omezena pouze dostupným místem na pevném disku počítače. Počet záznamů v tabulkách je určen velikostí pevného disku a počet polí není větší než 255.
Tabulky v Accessu lze vytvářet následovně:
· v režimu „designer“;
· v režimu zadávání dat do tabulky.
Tabulku můžete vytvořit importem nebo vytvořením odkazu na data uložená jinde. To lze provést například s daty uloženými v souboru aplikace Excel, seznamu služeb Windows SharePoint Services, souboru XML nebo jiné databázi MS ACCESS. SharePointový seznam umožňuje poskytnout přístup k datům uživatelům, kteří nemají nainstalovanou aplikaci MS ACCESS. Když importujete data, vytvoří se jejich kopie v nové tabulce v aktuální databázi. Následné změny provedené ve zdrojových datech neovlivní importovaná data a naopak. Po provedení vazby dat se v aktuální databázi vytvoří propojená tabulka, která poskytuje dynamické připojení k datům uloženým jinde. Změny dat v propojené tabulce se projeví ve zdroji a změny ve zdroji se projeví v propojené tabulce.
Zobrazení datového listu zobrazuje data uložená v tabulce, zatímco zobrazení Návrh zobrazuje strukturu tabulky.
Pokud vaše tabulky sdílejí společná pole, můžete použít podtabulku k vložení záznamů z jiné tabulky do jedné tabulky. Tento přístup umožňuje současně prohlížet data z více tabulek.
Žádosti. Dotazy jsou speciální nástroje určené k vyhledávání a analýze informací v databázových tabulkách, které splňují určitá kritéria. Nalezené záznamy, nazývané výsledky dotazů, lze prohlížet, upravovat a analyzovat různými způsoby. Kromě toho lze výsledky dotazu použít jako základ pro vytváření dalších objektů aplikace Access. Existují různé typy dotazů, z nichž nejběžnější jsou výběrové dotazy, parametrické a křížové dotazy, dotazy na mazání záznamů, změny a další. Méně používané jsou akční dotazy a dotazy SQL (Structured Query Language). Pokud požadovaný požadavek neexistuje, můžete jej vytvořit dodatečně.
Žádosti se generují různými způsoby, například pomocí „průvodce“ můžete požadavek vytvořit i ručně v režimu „návrhář“. Nejjednodušším a nejčastěji používaným typem dotazu je výběrový dotaz. Tyto dotazy vybírají data z jedné nebo více tabulek a tvoří je do nové tabulky, jejíž záznamy lze upravovat. Vybrané dotazy se používají k výpočtu součtů, průměrů a dalších součtů. Dotazy tedy využívají data z hlavních tabulek a vytvářejí dočasné tabulky.
Formuláře. Formuláře slouží k zadávání a úpravě záznamů v databázových tabulkách. Formuláře lze zobrazit ve třech režimech: režim pro zadávání dat, režim tabulky, kde jsou data prezentována v tabulkovém formátu, a režim „rozvržení“ a „návrh“, který umožňuje provádět změny a doplňky formulářů.
Hlavními prvky formuláře jsou nápisy, které označují text, který je přímo zobrazen ve formuláři, a pole obsahující hodnoty polí tabulky. Ačkoli režim Tvůrce umožňuje vytvořit formulář od začátku, obvykle se používá k upřesnění a vylepšení formulářů vytvořených pomocí průvodce. Kromě výše uvedených nástrojů lze formuláře vytvářet také pomocí následujících nástrojů:
· "forma";
· „rozdělená forma“;
· „několik prvků“;
· "prázdný formulář".
Nejefektivnější je používat formuláře pro zadávání dat ve formě speciálních formulářů, protože formulář může vypadat jako formulář. Použití formulářů umožňuje zadávat data v uživatelsky přívětivé formě známých dokumentů. I/O formuláře umožňují zadávat data do databáze, prohlížet je, měnit hodnoty polí, přidávat a mazat záznamy. Formulář může obsahovat tlačítko, které slouží k vytištění sestavy, otevření dalších objektů nebo automatickému provedení jiných úkolů.
Zprávy. Sestavy slouží k zobrazení informací v tabulkách ve formátované podobě, která je přehledně prezentována na obrazovce monitoru i na papíře. Zpráva je efektivním prostředkem pro tisk dat z databáze ve formě požadované uživatelem (ve formě certifikátů, zkušebních písemek, tabulek atd.). Kromě dat extrahovaných z více tabulek a dotazů mohou sestavy obsahovat prvky návrhu nalezené v tištěných dokumentech, jako jsou nadpisy, záhlaví a zápatí.
Sestavu lze zobrazit ve čtyřech režimech: v režimu „designer“, který umožňuje měnit vzhled sestavy, ve vzorovém režimu prohlížení, ve kterém lze zobrazit všechny prvky hotové sestavy, avšak ve zkrácené podobě formuláře, v režimu „rozvržení“, který umožňuje jeho přehlednější zobrazení (ve srovnání s návrhovým režimem) a formátování sestavy a v režimu náhledu, kdy se sestava zobrazuje tak, jak bude vytištěna.
Tabulky, dotazy, formuláře a sestavy jsou objekty nejpoužívanější při vývoji databází Access.
Možnosti databáze lze však výrazně rozšířit pomocí přístupových stránek, maker a modulů.
Stránky. Aby uživatelé internetu měli přístup k informacím, mohou být v databázi vytvořeny speciální datové stránky. Pomocí datových stránek můžete prohlížet, přidávat, měnit a manipulovat s daty uloženými v databázi. Datové stránky mohou také obsahovat data z jiných zdrojů, jako je Excel. Pro publikování informací z databáze ve Web Access je zahrnut „průvodce“, který zajistí vytvoření přístupové stránky.
Makra. Makra jsou malé programy jednoho nebo více makro příkazů, které provádějí specifické operace, jako je otevření formuláře, tisk sestav, kliknutí na tlačítko atd. To je zvláště užitečné, pokud máte v úmyslu sdílet databázi s nekvalifikovanými uživateli. Můžete například psát makra, která obsahují posloupnost příkazů provádějících rutinní úlohy, nebo můžete akce, jako je otevření formuláře nebo tisk sestavy, přidružit k tlačítkům na formuláři tlačítka.
Moduly Modul je databázový objekt, který umožňuje vytvářet knihovny rutin a funkcí používaných v celé aplikaci. Pomocí kódů modulů můžete řešit problémy, jako je zpracování vstupních chyb, deklarování a používání proměnných, organizace smyček atd.
Vytváření tabulek
Při zadávání dat do Accessu mají pole názvy: Pole1, Pole2 atd. Můžete použít navrhovaná jména nebo je změnit. Názvy polí v tabulce lze zadat dvěma způsoby. Po výběru způsobu vytvoření tabulky se zobrazí příkaz „ Vytvořit"a vyvolá se odpovídající okno. Na obr. 8. ukazuje vytvoření tabulky v režimu návrhu. Požadovaná pole tabulky jsou vytvořena se zadaným datovým typem, který se vybírá pomocí tlačítka výběru - „zaškrtnutí“ ve spodní části okna je sekce pro výběr vlastností pole, které jsou ve výchozím nastavení nabízeny.
Rýže. 14. Vytvoření tabulky v návrhovém režimu
Vlastnosti polí v databázové tabulce Accessu jsou uvedeny ve spodní polovině tabulky (obr. 14).
Tabulku můžete vytvořit v režimu návrhu změnou, přidáním nebo odstraněním polí tabulky. Pro zavedení nového pole je název pole uveden v horní části okna tabulky a je určen jeho typ. Chcete-li pole přejmenovat, musíte změnit jeho název ve sloupci „Název pole“.
Při vytváření tabulek se používají následující hlavní datové typy (obr. 15).
Vývoj informačních systémů (IS) je o vytváření nástrojů pro správu informací. IS přijímají informace, zpracovávají je podle určitých pravidel a doručují výsledek spotřebitelům: pro tisk, na obrazovku, do sluchátek a přenos do jiných systémů.
K vytvoření vysoce kvalitní IP tedy nestačí porozumět obchodním procesům a potřebám zákazníka. Je důležité pochopit, jaké informace by měl systém spravovat. A k tomu potřebujete vědět, které objekty spadají do předmětové oblasti navrženého IS a jaké logické vazby mezi nimi existují. K formování takového porozumění se používají logické modely předmětné oblasti.
Co znázorňuje logický model?
Účelem konstrukce logického modelu je získat grafické znázornění logické struktury zkoumané oblasti.
Logický model domény ilustruje entity a také jejich vzájemné vztahy.
Subjekty popisují objekty, které jsou předmětem činnosti předmětné oblasti, a subjekty, které v rámci předmětné oblasti vykonávají činnosti. Vlastnosti objektů a subjektů v reálném světě jsou popsány pomocí atributů.
Vztahy mezi entitami jsou znázorněny pomocí spojení. Pravidla a omezení vztahů jsou popsána pomocí vlastností vztahu. Vztahy obvykle definují buď závislosti mezi entitami, nebo vliv jedné entity na druhou.
Příklad: Objednávka pizzy
Klient zadá objednávku na nákup pizzy. Obecně platí, že zákazník si může objednat různá množství různých druhů pizzy. Každá objednávka tedy obsahuje položky. Každá pozice označuje druh pizzy, kterou chce klient dostat, a také její množství.
Základní požadavky
Základní požadavky na obsah modelu
1. Logický model musí zobrazovat všechny entity a vztahy, které jsou významné pro účel, pro který jej kreslíme.
2. Všechny objekty modelu (entity i vztahy) musí být pojmenovány. Pojmenování entit a vztahů by mělo být provedeno z hlediska předmětné oblasti.
3. U spojení musí být uvedena násobnost (jedna - mnoho).
4. Pro každé připojení musí být uveden směr čtení.
Příklad: do modelu byly přidány názvy spojů, jejich rozměry a směr čtení.
5. Pro entity musí být uvedeny minimálně základní atributy.
Příklad: pro entity jsou zadány základní atributy
Základní požadavky na kvalitu modelu:
<Сущность 1> — <отношение / влияние> — <Сущность 2>.
Čtení z dříve diskutovaného příkladu: Zákazník zadá objednávku. Objednávka obsahuje pozice, z nichž každá označuje, jaký druh pizzy a v jakém množství si klient přeje obdržet.
Klient může existovat bez objednávky. Objednávku však nelze zaregistrovat bez indikace zákazníka. Jeden klient může zadat neomezený počet objednávek
Podle modelu může mít jedna objednávka nekonečný počet položek. Je třeba si ujasnit, do jaké míry je to správné.
2. Model musí být strukturovaný, entity musí být seskupeny podle jejich logického významu.
3. Je velmi vhodné vyhnout se křížení spojů.
4. Uspořádání objektů modelu by mělo být takové, aby se daly pohodlně číst.
Existuje jeden postřeh - pokud je model příjemný na pohled, pak je s největší pravděpodobností vyroben kvalitně.
- Musíme určit, proč potřebujeme logický model. Na jaké otázky by nám měl nakonec odpovědět? Proč to ovlivní kvalitu analýzy a jak to pomůže vyřešit zadaný úkol?
Bez odpovědí na tyto otázky ztrácí vývoj modelu veškerý smysl, protože budeme dělat něco, od čeho nic zvlášť neočekáváme. Výsledek tomu bude odpovídat.
Odpovědi na tyto otázky nám dávají požadavky na model a při vývoji nám umožní rozhodovat o jeho vývoji a posuzovat jeho kvalitu.
- Je nutné určit hranice modelování — jakou část zkoumané oblasti má model pokrývat.
Odpověď na tuto otázku zpravidla vyplývá z pochopení úkolu, kterému obchodní analytik čelí.
Ve většině případů jsou hranice modelování určeny buď studovanými obchodními procesy, nebo fragmentem informačního prostoru společnosti, který spadá pod řešený problém.
- Vývoj logického modelu by měl začít v okamžiku zahájení výzkumu předmětné oblasti a skončit, když je úkol dokončen. Toto je téměř jediný artefakt, který se vyvíjí během analýzy předmětné oblasti a stanovení systémových požadavků.
Vývoj logického modelu je iterativní proces. Měl by být důsledně vylepšován a podrobně rozpracován podle oblasti předmětu a daného úkolu.
- Během analýzy jsou entity a vztahy identifikovány a zobrazeny na modelu.
Logický model musí být postaven tak, že entity se nazývají podstatná jména, spojení slovesa a čtení diagramu by generovalo, byť neobratné, věty, které popisují, co se děje v oblasti předmětu. Pokud se to podařilo, pak model vyšel báječně. Pokud to selže, vývojář modelu má stále co dělat.
- Při vývoji modelu se objasňuje složení entit a vztahů a určují se atributy entit.
Závěr
Je důležité si uvědomit, že logický model není o struktuře databáze, ale o logické struktuře předmětové oblasti vašeho úkolu. Vyloučením z vyvíjených atributů se připravíte o efektivní nástroj pro analýzu a návrh, který vám umožní velmi přesně zohlednit aspekty podnikání, které nejsou znázorněny dynamickými modely.
A naopak – včasné a kompetentní použití logického modelu z něj dělá velmi silný nástroj v rukou obchodního nebo systémového analytika.
Sergej Kalinov
Vedoucí obchodní analytik
18. února 2015
Kvalita vyvíjené databáze zcela závisí na kvalitě jednotlivých fází jejího návrhu. Kvalitní vývoj logického datového modelu má velký význam, protože na jedné straně zajišťuje adekvátnost věcné databáze, na druhé straně určuje strukturu fyzické databáze a následně i jeho provozní vlastnosti.
Stejná data lze seskupovat do relačních tabulek různými způsoby, tzn. je možné organizovat různé soubory vztahů mezi propojenými informačními objekty předmětné oblasti. Seskupování atributů ve vztazích by mělo být racionální, minimalizovat duplicitu dat a zjednodušovat postupy pro zpracování a aktualizaci.
Konkrétní sada relací má lepší vlastnosti pro zahrnutí, úpravu a mazání dat, pokud splňuje specifické požadavky na normalizaci relací.
Normalizace vztahů– formální aparát omezení jejich tvorby, který umožňuje eliminovat duplicitu dat, zajistit jejich konzistenci a snížit náklady na údržbu databáze.
V praxi se nejčastěji používají pojmy první, druhá a třetí normální forma.
Vztah se nazývá normalizované nebo zredukován na první normální formu(1NF), pokud jsou všechny jeho atributy jednoduché nebo atomární (dále jen nedělitelné). Relace v první normální formě bude mít následující vlastnosti:
■ ve vztahu nejsou žádné identické n-tice;
■ n-tice nejsou objednány;
■ atributy nejsou seřazeny a liší se podle názvu;
■ všechny hodnoty atributů jsou atomické.
Jak je vidět z uvedených vlastností, jakýkoli vztah je automaticky v první normální formě.
Snadno lze ukázat, že první normální forma umožňuje uložení v jednom vztahu heterogenních informací, redundanci dat, což vede k neadekvátnosti logického datového modelu předmětné oblasti. První normální forma tedy pro správné datové modelování nestačí.
Pro zvážení problematiky redukce vztahů na druhou normální formu je nutné vysvětlit pojem funkční závislosti.
Ať existuje vztah R. Množina atributů Y je funkčně závislá na množině atributů X, pokud pro jakýkoli vztahový stav R pro jakékoli n-tice toho, co následuje, tzn. ve všech n-ticích, které mají stejné hodnoty atributů X, hodnoty atributů Y se také shodují v jakémkoli stavu vztahu R.
Mnoho atributů X volal determinant funkční závislosti a množina atributů U – závislá část.
V praxi tyto závislosti odrážejí vztahy nalezené mezi objekty domény a jsou dalšími omezeními definovanými doménou. Funkční závislost je tedy sémantický pojem. Nastává, když hodnoty některých dat v předmětné oblasti lze použít k určení hodnot jiných dat. Pokud například znáte osobní číslo zaměstnance, můžete určit jeho příjmení. Funkční závislost klade další omezení na data, která mohou být uložena ve vztahu. Pro správnost databáze je nutné při provádění operací úpravy databáze zkontrolovat všechna omezení definovaná funkčními závislostmi.
Funkční závislost atributů vztahu připomíná pojem závislosti v matematice. Funkční závislost v matematice je trojice objektů X, Y A F, kde X je množina reprezentující definiční obor funkce, Y– soubor hodnot a F– pravidlo, podle kterého je každý prvek spojen s jedním a pouze jedním prvkem Naproti tomu ve vztazích může hodnota závislého atributu nabývat různých nepředvídatelných hodnot v různých stavech databáze, odpovídajících různým stavům databáze. předmětová oblast. Například zaměstnanec, který si při uzavření legálního manželství změní příjmení, povede k tomu, že při stejné hodnotě determinantu, řekněme personálního čísla, bude hodnota závislého argumentu jiná.
Funkční závislost atributů uvádí pouze to, že pro každý konkrétní stav databáze lze hodnotu jednoho atributu použít k jednoznačnému určení hodnoty jiného atributu. Konkrétní hodnoty závislé části se mohou v různých stavech databáze lišit.
Vztah je in druhá normální forma(2NF), pokud je v první normální formě (1NF) a neexistují žádné neklíčové atributy, které závisí na části složeného klíče.
Z definice 2NF vyplývá, že pokud je kandidátský klíč jednoduchý, pak je relace automaticky ve druhé normální formě.
Vztahy redukované na druhou normální formu však stále obsahují heterogenní informace a vyžadují zapsání dalšího programového kódu v podobě spouštěčů pro správný chod databáze. Dalším krokem ke zlepšení kvality vztahů je přivést je do třetí normální formy.
Vztah je in třetí normální forma(ZNF), pokud je v 2NF a všechny neklíčové atributy jsou vzájemně nezávislé.
Relační datový model sestávající ze vztahů redukovaných na 3NF je adekvátní doménový model a vyžaduje pouze ty spouštěče, které udržují referenční integritu. Tyto spouštěče jsou standardní a jejich vývoj vyžaduje minimální úsilí.
Vývoj logického modelu relační databáze lze tedy reprezentovat jako definující vztahy, které odrážejí koncepty předmětné oblasti a přivádějí je do třetí normální formy.
Algoritmus vývoje zahrnuje tři fáze.
Fáze I. Snížení na 1NF. Zde je nutné definovat a definovat vztahy, které odrážejí koncepty předmětné oblasti. Všechny vztahy jsou automaticky v 1NF.
Etapa II. Snížení na 2NF. Pokud je v některých relacích zjištěna závislost atributů na části komplexního klíče, pak by měly být rozloženy následovně: atributy, které závisí na části komplexního klíče, jsou umístěny v samostatné relaci spolu s touto částí klíče, a všechny klíčové atributy zůstávají v původním vztahu.
. Klíč je složitý klíč.
– závislost všech atributů na klíči relace;
– závislost některých atributů na části komplexního klíče.
– zbývající část původního vztahu;
- nový postoj.
Stupeň III. Snížení na 3NF. Pokud je v některých relacích zjištěna závislost některých neklíčových atributů na jiných neklíčových atributech, pak se provede rozklad těchto vztahů: neklíčové atributy, které jsou závislé na jiných neklíčových atributech,
vytvořit samostatný vztah. V novém vztahu se klíč stává determinantem funkční závislosti.
Nechť například počáteční vztah –. NA- klíč.
Pak mají funkční závislosti následující tvar:
Po rozložení vztahu dostaneme:
V praxi je poměrně vzácné, aby byl logický databázový model vytvořen pomocí daného algoritmu. Častěji se používají různé verze ER diagramů podporované vhodnými CASE nástroji. Základní pojmy ER diagramů jsou uvedeny ve standardech IDEF1 a IDEF1X. Výše uvedený algoritmus je však užitečný jako ilustrace problémů, které mohou nastat při definování slabě normalizovaných vztahů v prvních fázích návrhu. Pochopení těchto problémů je zvláště důležité při provádění úprav a vylepšení databáze, když jsou zaváděny nové entity, objevují se nové závislosti atd.
1.1 Logické modely
Logický (predikátový) model reprezentace znalostí je založen na algebře výroků a predikátů, na systému axiomů této algebry a jejích pravidlech vyvozování. Z predikátových modelů je nejrozšířenější model predikátů prvního řádu, založený na pojmech (argumenty predikátů - logické konstanty, proměnné, funkce), predikátech (výrazy s logickými operacemi).
Příklad. Vezměme si prohlášení: „Inflace v zemi dvakrát převyšuje loňskou úroveň. To lze zapsat ve formě logického modelu: r(InfNew, InfOld, n), kde r(x,y) je vztah ve tvaru „x=ny“, InfNew je aktuální inflace v zemi, InfOld je loňská inflace. Pak můžeme uvažovat pravdivé a nepravdivé predikáty, například r(InfNew, InfOld, 2)=1, r(InfNew, InfOld, 3)=0 atd. Velmi užitečné operace pro logické inference jsou operace implikace a ekvivalence.
Logické modely jsou vhodné pro reprezentaci logických vztahů mezi fakty, jsou formalizované, striktní (teoretické) a pro jejich použití existuje vhodná a adekvátní sada nástrojů, například logický programovací jazyk Prolog.
Modely tohoto typu jsou založeny na konceptu formálního systému. Formulace a řešení jakéhokoli problému souvisí s konkrétním oborem. Při řešení problematiky rozvrhování zpracování dílů na obráběcích strojích tedy zapojujeme do předmětové oblasti takové objekty, jako jsou konkrétní stroje, díly, časové intervaly a obecné pojmy „stroj“, „součást“, „druh stroje“. “ atd.
Všechny objekty a události, které tvoří základ společného chápání informací nezbytných k vyřešení problému, se nazývají předmětná oblast. Mentálně je předmětná oblast reprezentována jako složená ze skutečných objektů nazývaných entity. Entity předmětné oblasti jsou mezi sebou v určitých vztazích. Vztahy mezi entitami jsou vyjádřeny pomocí propozic. V jazyce (formálním nebo přirozeném) výroky odpovídají výrokům.
Pro reprezentaci matematických znalostí v matematické logice se používají logické formalismy - výrokový počet a predikátový počet. Tyto formalismy mají jasnou formální sémantiku a byly pro ně vyvinuty inferenční mechanismy. Predikátový počet byl proto prvním logickým jazykem, který byl použit k formálnímu popisu oblastí souvisejících s řešením aplikovaných problémů.
Popisy tematických oblastí provedené v logických jazycích se nazývají logické modely. Logické modely vytvořené pomocí logických programovacích jazyků jsou široce používány ve znalostních bázích a expertních systémech.
1.2 Modely produktů
Produkční model reprezentace znalostí je vývoj logických modelů směrem k efektivitě reprezentace znalostí a výstupu.
Produkce je výraz obsahující jádro interpretované frází „Pokud A, pak B“, název, rozsah, podmínka použitelnosti jádra a postpodmínka, což je postup, který má být proveden poté, co jádro byla úspěšně implementována. Všechny části kromě jádra jsou volitelné.
Vzájemně propojený soubor produktů tvoří systém. Hlavním problémem odvození znalostí v produktovém systému je výběr dalšího produktu k analýze. Konkurenční produkty tvoří frontu.
Produkty (společně se síťovými modely) jsou nejoblíbenějšími prostředky reprezentace znalostí v systémech umělé inteligence. Implikaci lze interpretovat v obvyklém logickém smyslu jako znak logického důsledku B z pravého A. Jsou možné i jiné interpretace součinu, například A popisuje nějakou podmínku nutnou pro provedení akce B.
Pokud je určitá sada produktů uložena v paměti systému, tvoří systém produktů. V produktovém systému musí být specifikovány speciální procedury produktového managementu, pomocí kterých se produkty aktualizují a dochází k implementaci toho či onoho produktu z aktualizovaných.
Produktový systém zahrnuje základnu pravidel (produkty), globální databázi a systém řízení. Báze pravidel je paměťová oblast, která obsahuje soubor znalostí ve formě pravidel IF - THEN. Globální databáze je paměťová oblast obsahující aktuální data (fakta). Řídicí systém generuje závěry pomocí báze pravidel a databáze. Existují dva způsoby, jak tvořit závěry – přímé závěry a inverzní závěry.
Při přímých inferencích se vybere jeden z datových prvků obsažených v databázi, a pokud při porovnání tento prvek souhlasí s levou stranou pravidla (premisy), pak se z pravidla odvodí odpovídající závěr a uloží se do databáze. nebo se provede akce definovaná pravidlem a podle toho se změní obsah databáze. Při zpětných inferencích proces začíná od stanoveného cíle. Pokud je tento cíl v souladu s pravou stranou pravidla (závěrem), pak je premisa pravidla brána jako dílčí cíl nebo hypotéza. Tento proces se opakuje, dokud není získána shoda dílčího cíle s daty. Při velkém počtu výrobků v modelu výrobku se kontrola konzistence výrobkového systému stává obtížnější, tzn. spoustu pravidel. Počet produktů, se kterými moderní systémy AI pracují, proto zpravidla nepřesahuje tisíc.
Úroveň. Obecně lze jako možnosti řešení použít třídy strategií navrhované v ekonomické literatuře. 16. Vlastnosti návrhu inteligentního ekonomického informačního systému Návrh informačního systému začíná průzkumem předmětné oblasti. Moderní technologie pro takové průzkumy jsou založeny na konceptu a softwaru obchodního reengineeringu ...
Americké a západoevropské vzdělávací instituce jsou v tomto směru považovány za progresivní a takové kurzy ochotně rozvíjejí. Hlavní typy a technologie inteligentních informačních systémů Znalosti jsou základem inteligentního systému Mnoho druhů lidské duševní činnosti, jako je psaní programů pro počítač, matematika, vedení úvah o...
Proroctví M. Nostradama: vychází vydání většiny z jeho staletí. Vzájemná propojenost těchto knih, stejně jako Avesty, je pozoruhodná. Jestliže v Bibli Zarathushtra mluví o budoucím příchodu proroka M. Nostradama, pak v Proroctvích samotného M. Nostradama opakovaně nacházíme jeho apel na učení Zarathushtra. V tomto ohledu je čtyřverší 83 století 8 velmi charakteristické (citováno z...
Při provádění základních funkcí musí DBMS používat různé popisy dat. Podívejme se, jak tyto popisy vytvořit.
Při vývoji databáze (IS) obvykle existuje několik úrovní modelování, pomocí kterých dochází k přechodu od předmětové oblasti ke konkrétní implementaci databáze pomocí prostředků konkrétní DBMS. Lze rozlišit následující úrovně: samotná předmětná oblast, konceptuální model předmětné oblasti, logický datový model, fyzický datový model, samotná databáze a aplikace.
Předmět je část reálného světa, data, o kterých chceme reflektovat v databázi. Například jako předmět si můžete vybrat účetní oddělení podniku, oddělení lidských zdrojů, banku, obchod atd. Předmětová oblast je nekonečná a obsahuje jak v podstatě důležité pojmy a data, tak i nevýznamná či nevýznamná data. Zvolíte-li tedy jako předmět účtování zboží na skladě, pak jsou pojmy „faktura“ a „faktura“ zásadně důležité pojmy a skutečnost, že zaměstnanec přebírající faktury má dvě děti, není pro účtování zboží důležitá. . Z pohledu HR oddělení jsou však zásadní údaje o přítomnosti dětí. Důležitost dat tedy závisí na volbě domény.
Koncepční doménový model
Koncepční doménový model - to jsou naše znalosti o předmětné oblasti ve formě pojmů (pojmů). Znalosti mohou být buď ve formě neformálních znalostí v mozku odborníka, nebo vyjádřeny formálně pomocí nějakých prostředků. Takovými nástroji mohou být textové popisy předmětné oblasti, soubory náplní práce, pravidla pro podnikání ve firmě atp. Zkušenosti ukazují, že textový způsob reprezentace doménového modelu je extrémně neefektivní. Mnohem informativnější a užitečnější při vývoji databází jsou popisy předmětné oblasti vytvořené pomocí specializovaných grafických zápisů. Existuje velké množství metod pro popis předmětné oblasti. Konceptuální databázový model – odráží informační obsah dat, jako základní pojmy a vztahy mezi nimi. Koncepční model neovlivňuje fyzický stav dat, včetně datové architektury, přístupových metod a fyzických datových formátů.
Na Obr. Obrázek 7 ukazuje fragment koncepčního modelu předmětové oblasti "Podnik".
Obrázek 7 - Koncepční model IS "Enterprise"
Mezi nejznámější metody studia oborů a vytváření konceptuálních modelů patří systémová analýza. Existuje také řada technik, které berou v úvahu principy systémové analýzy - technika strukturální analýzy SADT a IDEF0 na ní založené, Hein-Sarsonovy diagramy datových toků, technika objektově orientované analýzy UML atd. Konceptuální model předmětová oblast spíše popisuje procesy probíhající v předmětné oblasti a data, která tyto procesy používají. Úspěch dalšího vývoje aplikací závisí na tom, jak správně je daná oblast modelována.
Datový model - nástroje pro zobrazení předmětové oblasti definované:
Přijatelná organizace dat;
Omezení integrity (sémantika);
Sada operací povolených na objektech datového modelu.
Logický datový model
Na další, nižší úrovni je logický datový model předmětné oblasti.
Logický model popisuje koncepty předmětné oblasti, jejich vztahy a také omezení dat uložená předmětnou oblastí. Příklady pojmů jsou „zaměstnanec“, „oddělení“, „projekt“, „plat“. Příklady vztahů mezi pojmy jsou „zaměstnanec je registrován právě v jednom oddělení“, „zaměstnanec může provádět více projektů“, „na jednom projektu může pracovat více zaměstnanců“. Příklady omezení jsou „věk zaměstnance není nižší než 16 a není vyšší než 60 let“.
Existují tři hlavní typy logických modelů:
Hierarchický model;
Síťový model;
Relační model.
Logický datový model pro DBMS relačního typu je databázový diagram zobrazený na obrázku 8
Obrázek 8 - Příklad logického datového modelu
Logický datový model je počátečním prototypem budoucí databáze. Logický model je konstruován z hlediska informačních jednotek, ale bez odkazu na konkrétní DBMS. Předběžným prostředkem vývoje logického datového modelu jsou v současnosti různé možnosti infoologických (informačně-logických) modelů - ER- diagram (Entita-vztah , diagramy vztahů mezi entitami ). Stejný ER model lze převést na relační datový model, datový model pro hierarchické a síťové DBMS nebo na postrelační datový model.
Rozhodnutí učiněná na předchozí úrovni při vytváření infoologického modelu předmětné oblasti vymezují určité hranice, v rámci kterých lze logický datový model rozvíjet a v rámci těchto hranic lze činit různá rozhodnutí.
Logický datový model se vyznačuje tím, že při splnění všech základních požadavků DBMS nepodporuje orientaci na konkrétní DBMS, která je implementována ve fyzickém datovém modelu.
Fyzický datový model
Na ještě nižší úrovni je fyzický datový model.
Fyzický datový model popisuje data pomocí specifického DBMS. Omezení přítomná v logickém datovém modelu jsou implementována různými nástroji DBMS, například pomocí indexů, deklarativních omezení integrity, spouštěčů a uložených procedur. V tomto případě opět rozhodnutí učiněná na úrovni logického modelování určují určité hranice, v rámci kterých lze fyzický datový model rozvíjet. Stejně tak v rámci těchto hranic lze činit různá rozhodnutí. Například vztahy obsažené v logickém datovém modelu musí být převedeny na tabulky, ale pro zlepšení rychlosti přístupu k datům lze v každé tabulce volitelně deklarovat různé indexy. Zde hodně záleží na konkrétním DBMS.
Pokud je fyzický datový model implementován pomocí relačního DBMS, pak se vztahy vyvinuté ve fázi formování logického datového modelu převedou na tabulky, atributy se stanou sloupci tabulky, vytvoří se jedinečné indexy pro klíčové atributy, domény se převedou na akceptované datové typy. v konkrétním DBMS.
Vlastní databázový a informační systém. A nakonec se v důsledku předchozích fází objeví samotná databáze. Databáze je implementována na specifické hardwarové a softwarové bázi a volba této báze může výrazně zvýšit rychlost práce s databází. Můžete například vybrat různé typy počítačů, změnit počet procesorů, velikost paměti RAM, diskové subsystémy atd. Velmi důležitá je také konfigurace DBMS v rámci zvolené softwarové a hardwarové platformy.
Ale opět platí, že rozhodnutí učiněná na předchozí úrovni – na úrovni fyzického designu – určují hranice, v nichž lze rozhodovat o volbě softwarové a hardwarové platformy a nastavení DBMS. Je tedy jasné, že rozhodnutí učiněná v každé fázi modelování a vývoje databáze ovlivní následující fáze. Zvláštní roli proto hraje správná rozhodnutí v raných fázích modelování.
