Etapy návrhu a tvorby databáze. Etapy vývoje databáze

Etapy návrhu databáze.

motivy: fáze návrhu databáze, návrh databáze založený na modelu objektových vztahů

Před vytvořením databáze musí vývojář určit, z jakých tabulek se má databáze skládat, jaká data mají být v každé tabulce umístěna, jak tabulky propojit. Tyto problémy se řeší ve fázi návrhu databáze.

V důsledku návrhu by měla být určena logická struktura databáze, tedy složení relačních tabulek, jejich struktura a mezitabulkové vztahy.

Před vytvořením databáze je nesmírně důležité mít popis vybrané předmětová oblastĸᴏᴛᴏᴩᴏᴇ by měla pokrývat skutečné objekty a procesy, identifikovat všechny potřebné zdroje informací pro splnění očekávaných požadavků uživatelů a určit potřeby pro zpracování dat.

Na základě takového popisu je ve fázi návrhu databáze stanovena skladba a struktura dat předmětné oblasti, která by měla být v databázi a zajistit plnění potřebných dotazů a uživatelských úkolů. Datová struktura předmětové oblasti může být zobrazena informačně-logickým modelem. Na základě tohoto modelu se snadno vytvoří relační databáze.

Fáze návrhu a vytváření databáze jsou určeny následujícím pořadím:

‣‣‣ vytvoření informačně-logického datového modelu předmětné oblasti;

‣‣‣ definování logické struktury relační databáze;

‣‣‣ konstrukce databázových tabulek;

‣‣‣ vytvoření datového schématu;

‣‣‣ zadávání dat do tabulek (vytváření záznamů);

‣‣‣ vývoj potřebných formulářů, požadavků, maker, modulů, reportů;

‣‣‣ vývoj uživatelského rozhraní.

V procesu vývoje datového modelu je nesmírně důležité identifikovat informační objekty, které splňují požadavky normalizace dat, a určit vztahy mezi nimi. Tento model umožňuje vytvořit relační databázi bez duplikace, která poskytuje jednorázové zadání dat během počátečního načítání a úprav a také integritu dat při provádění změn.

Při vývoji datového modelu lze použít dva přístupy. V prvním přístupu nejprve se určí hlavní úkoly, pro jejichž řešení se buduje základna, identifikují se datové potřeby úkolů a podle toho se určí skladba a struktura informační objekty. S druhým přístupem typické objekty předmětné oblasti jsou okamžitě instalovány. Nejracionálnější kombinace obou přístupů. To je způsobeno tím, že na počáteční fáze Zpravidla neexistují vyčerpávající informace o všech úkolech. Použití této technologie je o to oprávněnější, že flexibilní nástroje pro tvorbu relačních databází umožňují provádět změny v databázi a upravovat její strukturu v libovolné fázi vývoje, aniž by byla dotčena dříve zadaná data.

Proces výběru informačních objektů předmětné oblasti, které splňují požadavky normalizace, lze provádět na základě intuitivního nebo formálního přístupu. Teoretický základ formální přístup vyvinul a plně popsal v monografiích o organizaci databází slavný americký vědec J. Martin.

Díky intuitivnímu přístupu lze snadno identifikovat informační objekty odpovídající skutečným objektům. Výsledný informačně-logický model přitom zpravidla vyžaduje další transformace, zejména transformaci vícehodnotových vztahů mezi objekty. S tímto přístupem jsou možné významné chyby, pokud není dostatek zkušeností. Následné ověření splnění normalizačních požadavků obvykle ukazuje kritický význam zpřesňování informačních objektů.

Zvažte formální pravidla, která se používají k výběru informačních objektů.

‣‣‣ Na základě popisu předmětové oblasti identifikujte dokumenty a jejich atributy, které mají být uloženy v databázi;

‣‣‣ definovat funkčních závislostí mezi atributy;

‣‣‣ vybrat všechny závislé atributy a označit pro každý z jeho klíčových atributů, tj. ty, na kterých závisí;

‣‣‣ skupinové atributy stejně závislé na klíčových atributech. Výsledné skupiny závislých atributů spolu s jejich klíčovými atributy tvoří informační objekty.

Při definování logické struktury relační databáze na základě modelu je každý informační objekt adekvátně reprezentován relační tabulkou a vztahy mezi tabulkami odpovídají vztahům mezi informačními objekty.

Během procesu vytváření databázových tabulek odpovídajících informační objekty sestavený datový model. Dále lze vytvořit datové schéma, ve kterém jsou fixovány existující logické vztahy mezi tabulkami. Tyto odkazy odpovídají vazbám informačních objektů. Datové schéma lze nastavit tak, aby zachovalo integritu databáze, pokud byl datový model vyvinut v souladu s požadavky normalizace. Integrita dat znamená, že vztahy mezi záznamy různých tabulek jsou navázány a správně udržovány v databázi při načítání, přidávání a mazání záznamů v souvisejících tabulkách, stejně jako při změně hodnot klíčových polí.

Po vytvoření datového schématu se provede vstup konzistentních dat z dokumentů předmětné oblasti.

Na základě vytvořené databáze se tvoří potřebné dotazy, formuláře, makra, moduly, sestavy, které provedou požadované zpracování databázových dat a jejich prezentaci.

S pomocí vestavěných nástrojů a databázových nástrojů, a uživatelské rozhraní, který umožňuje řídit procesy zadávání, ukládání, zpracování, aktualizace a prezentace databázových informací.

2 Návrh databáze založené na modelu objektových vztahů

Existuje řada metod vytváření informačně-logických modelů. Jednou z nejpopulárnějších modelovacích technik současnosti je použití ERD (Entity-Relationship Diagrams). V ruské literatuře se těmto diagramům říká ʼʼobjekt – vztahʼʼ nebo ʼʼesence – spojeníʼʼ. Model ERD navrhl Peter Ping Shen Chen v roce 1976 ᴦ. K dnešnímu dni bylo vyvinuto několik druhů, ale všechny jsou založeny na grafických diagramech navržených Chenem. Diagramy jsou sestaveny z malého počtu komponent. Kvůli přehlednosti prezentace jsou široce používány v CASE-tools (Computer Aided Software Engineering).

Zvažte použitou terminologii a notaci.

Entita- skutečný nebo imaginární objekt, který je podstatný pro uvažovanou předmětnou oblast, informace o které mají být uloženy.

Každá entita musí mít jedinečný identifikátor. Každá instance entity musí být jednoznačně identifikována a odlišena od všech ostatních instancí daného typu (entity). Každá entita musí mít nějaké vlastnosti:

‣‣‣ mají jedinečný název; navíc u tohoto názvu je třeba vždy použít stejný výklad (definici entity). A naopak: stejný výklad nelze použít na různá jména, pokud nejde o aliasy;

‣‣‣ mají jeden nebo více atributů, které buď patří nějaké entitě, nebo je zdědí prostřednictvím vztahu;

‣‣‣ mají jeden nebo více atributů, které jednoznačně identifikují každou instanci entity.

Subjekt musí být nezávislý nebo závislý. Znakem závislé entity je přítomnost atributů zděděných vztahem (obr. 1.).

Vztah- pojmenovaná asociace mezi dvěma entitami, která je významná pro uvažovanou předmětnou oblast. Jedna z entit účastnících se spojení je nezávislá, je zvykem volat nadřazenou entitu, druhá je závislá, zvykem je volat podřízenou nebo podřízenou entitu. Zpravidla je každá instance nadřazené entity spojena s libovolným (včetně nuly) počtem instancí podřízené entity. Každá instance podřízené entity je přidružena přesně k jedné instanci nadřazené entity. Τᴀᴋᴎᴍ ᴏϬᴩᴀᴈᴏᴍ, instance podřízené entity může existovat, pouze pokud existuje nadřazená entita.

Spojení je pojmenováno vyjádřeným gramatickým obratem slovesa a umístěno blízko spojnice. Jméno každého vztahy mezi dvěma danými entitami musí být jedinečné, ale názvy vztahů v modelu nemusí být jedinečné. Každý vztah má svou definici. Definice vztahu je tvořena zřetězením názvu nadřazené entity, názvu vztahu, výrazu stupně vztahu a názvu podřízené entity.

‣‣‣ prodávající může být odměněn za jednu nebo více smluv;

‣‣‣ Smlouva musí být uzavřena právě jedním prodávajícím.

V diagramu je vztah reprezentován segmentem (křivkou). Konce segmentu pomocí speciálních označení (obr. 2) označují stupeň spojení. Zároveň charakter čáry - čárkovaná nebo plná, naznačuje povinnost komunikace.

Atribut- jakákoli charakteristika účetní jednotky, která je významná pro zvažovanou předmětnou oblast. Je určen ke kvalifikaci, identifikaci, klasifikaci, kvantifikaci nebo vyjádření stavu entity. Atribut představuje typ charakteristik (vlastností) spojených s množinou reálných nebo abstraktních objektů (lidé, místa, události, stavy, myšlenky, dvojice objektů atd.) (obr. 3). Instance atributu je specifická charakteristika konkrétní instance entity. Instance atributu je definována typem charakteristiky (např. ʼʼColorʼʼ) a její hodnotou (např. ʼʼlilacʼʼ), nazývanou hodnota atributu. V modelu ER jsou atributy spojeny s konkrétními entitami. Každá instance entity musí mít jednu konkrétní hodnotu pro každý ze svých atributů.

Jedinečný identifikátor je atribut nebo sada atributů a/nebo vztahů, které jednoznačně charakterizují každou instanci daného typu entity. V případě plné identifikace je instance daného typu entity plně identifikována svými vlastními klíčovými atributy, jinak se na identifikaci podílejí i atributy jiné entity, rodiče.

Charakter identifikace je zobrazen ve schématu na komunikační lince (obr. 4).

Každý atribut je identifikován jedinečným názvem, vyjádřeným slovním spojením, které popisuje charakteristiku, kterou atribut představuje. Atributy jsou zobrazeny jako seznam názvů v rámci přidruženého bloku entity, přičemž každý atribut zabírá samostatný řádek. Atributy, které definují primární klíč, jsou umístěny na začátku seznamu a jsou označeny ʼʼ#ʼʼ.

Každá entita musí mít alespoň jeden možný klíč. Možný klíč entity je jeden nebo více atributů, jejichž hodnoty jedinečně identifikují každou instanci entity. Pokud existuje více možných klíčů, jeden z nich je určen jako primární klíč a zbytek jako alternativní klíče.

Dnes je na základě Chenova přístupu vytvořena metodika IDEF1X, která je navržena s ohledem na takové požadavky, jako je snadnost studia a možnost automatizace. Diagramy IDEFlX používá řada běžných nástrojů CASE (např. ERwin, Design/IDEF).

Entita v metodologii IDEF1X se nazývá nezávislá na identifikátoru nebo jednoduše nezávislá, pokud každá instance entity musí být jednoznačně identifikována bez definování jejího vztahu s jinými entitami. Entita se obvykle nazývá závislá na identifikátorech nebo jednoduše závislá, pokud jednoznačná identifikace instance entity závisí na jejím vztahu k jiné entitě (obr. 5).

Každé entitě je přiřazen jedinečný název a číslo, oddělené lomítkem ʼʼ/ʼʼ a umístěné nad blokem.

Pokud je instance potomkové entity jednoznačně určena svým vztahem s nadřazenou entitou, pak se vztah obvykle nazývá identifikační, jinak je neidentifikující.

Identifikační vztah mezi nadřazenou entitou a podřízenou entitou je zobrazen jako plná čára. Na Obr. 5: #2 - závislá entita, Vztah 1 - identifikační vztah. Podřízená entita v identifikačním vztahu je entita závislá na identitě. Nadřazená entita v identifikačním vztahu musí být jak nezávislá, tak závislá na identifikátoru (to je určeno jejími vztahy s jinými entitami).

Přerušovaná čára znázorňuje neidentifikující vztah. Na Obr. 5: #4 je nezávislý subjekt, odkaz 2 je neidentifikující odkaz. Podřízená entita v neidentifikujícím vztahu bude na identifikátoru nezávislá, pokud není zároveň podřízenou entitou v žádném identifikačním vztahu.

Vztah lze dále definovat zadáním stupně nebo mohutnosti (počet instancí podřízené entity, ĸᴏᴛᴏᴩᴏᴇ může existovat pro každou instanci nadřazené entity). V IDEF1X jsou vyjádřeny následující mohutnosti:

‣‣‣ Každá instance nadřazené entity může mít přidruženou nulu, jednu nebo více instancí podřízené entity;

‣‣‣ každá instance nadřazené entity musí mít přidruženou alespoň jednu instanci podřízené entity;

‣‣‣ každá instance nadřazené entity musí mít přidruženou nejvýše jednu instanci podřízené entity;

‣‣‣ Každá instance nadřazené entity je spojena s určitým pevným počtem instancí podřízené entity.

Výkon spoje je označen tak, jak je znázorněno na obr. 6 (výchozí napájení - N).

Výsledkem je informačně-logický model, který využívá řada běžných CASE nástrojů, jako je ERwin, Design / IDEF. CASE-technologie mají zase vysoký potenciál ve vývoji databází a informačních systémů, a to ve zvyšování produktivity práce, zlepšování kvality softwarových produktů, podpoře jednotného a konzistentního stylu práce.

Fáze návrhu databáze - koncepce a typy. Klasifikace a vlastnosti kategorie "Fáze návrhu databáze" 2017, 2018.

Podstatou návrhu databáze (DB), stejně jako jakéhokoli jiného procesu návrhu, je vytvořit popis nového systému, který dříve v této podobě neexistoval a který je po implementaci schopen údajně fungovat za vhodných podmínek. Z toho vyplývá, že fáze návrhu databáze by měly důsledně a logicky odrážet podstatu tohoto procesu.

Obsah návrhu databáze a fáze

Myšlenka designu vychází z nějaké formulované společenské potřeby. Tato potřeba má prostředí pro svůj výskyt a cílové publikum spotřebitelů, kteří výsledek návrhu využijí. Proto proces návrhu databáze začíná prozkoumáním dané potřeby z pohledu zákazníků a funkčního prostředí jejího zamýšleného umístění. To znamená, že první fází je sběr informací a definice modelu předmětové oblasti systému a také pohled na ni z pohledu cílového publika. Obecně platí, že pro stanovení požadavků na systém je určen rozsah akcí a také hranice databázových aplikací.

Dále návrhář, který již má určité představy o tom, co potřebuje vytvořit, objasní úkoly údajně řešené aplikací, vytvoří si jejich seznam (zejména má-li vývoj designu velkou a komplexní databázi), ujasní pořadí řešení. problémy a analyzuje data. Takový proces je také etapovou projekční prací, ale obvykle ve struktuře návrhu jsou tyto kroky absorbovány etapou koncepční design- fáze výběru objektů, atributů, odkazů.

Tvorba koncepčního (informačního modelu) zahrnuje předběžné vytvoření koncepčních požadavků uživatelů, včetně požadavků na aplikace, které nemusí být implementovány okamžitě, ale zohledňují, které v budoucnu zlepší funkčnost systému. Konceptuální model, který se zabývá reprezentacemi objektových abstrakcí množiny (bez specifikace způsobů fyzického uložení) a jejich vztahy, odpovídá obsahu doménového modelu. Proto se v literatuře první fáze návrhu databáze nazývá infoologický design.

Dále na samostatnou etapu (nebo doplnění předchozí) navazuje etapa tvorby požadavků na operační prostředí, kde se vyhodnocují požadavky na výpočetní prostředky, které mohou zajistit fungování systému. Čím větší je objem navrhované databáze, čím vyšší je aktivita uživatelů a intenzita volání, tím vyšší jsou požadavky na zdroje: na konfiguraci počítače, na typ a verzi operační systém. Vyžaduje například víceuživatelský režim budoucí databáze internetové připojení pomocí operačního systému, který je vhodný pro multitasking.

V dalším kroku musí návrhář zvolit systém pro správu databází (DBMS) a softwarové nástroje. Poté je třeba koncepční model přenést do datového modelu kompatibilního s vybraným řídicím systémem. Často je to však spojeno se zaváděním úprav a změn koncepčního modelu, protože ne vždy mohou být vzájemné vztahy objektů, reflektované koncepčním modelem, implementovány pomocí tohoto DBMS.

Tato okolnost určuje vznik další etapy – vznik konkrétního koncepčního modelu podporovaného DBMS. Tento krok odpovídá fázi logického návrhu (vytvoření logického modelu).

Konečně poslední fází návrhu databáze je fyzický návrh – fáze propojení logické struktury a prostředí fyzického úložiště.

Hlavní fáze návrhu v podrobné podobě jsou tedy reprezentovány fázemi:

• infologický design,
• formování požadavků na provozní prostředí
• výběr řídicího systému a softwarových nástrojů DB,
• logický design,
• fyzický design

Ty klíčové budou podrobněji rozebrány níže.

infoologický design

Identifikace entit je sémantickým základem infologického designu. Entita je zde takový objekt (abstraktní nebo konkrétní), o kterém se budou v systému shromažďovat informace. V infoologickém modelu oborové oblasti je uživatelsky přívětivým způsobem, který nezávisí na konkrétní implementaci databáze, popsána struktura a dynamické vlastnosti oborové oblasti. Ale termíny jsou brány v typickém měřítku. To znamená, že popis není vyjádřen prostřednictvím jednotlivých objektů předmětné oblasti a jejich vztahů, ale prostřednictvím:

• popis typů objektů,
• omezení integrity spojená s popsaným typem,
• procesy vedoucí k evoluci předmětné oblasti – jejímu přechodu do jiného stavu.

Infoologický model lze vytvořit pomocí několika metod a přístupů:

1. Funkční přístup vychází ze stanovených úkolů. Funkční se nazývá proto, že se používá, jsou-li známy funkce a úkoly osob, které budou s pomocí navržené databáze sloužit jejich informačním potřebám.
2. Předmětový přístup se zaměřuje na informace o informacích, které budou obsaženy v databázi, a to i přesto, že struktura dotazů nemusí být určena. V tomto případě se při výzkumu předmětné oblasti řídí jejím co nejadekvátnějším zobrazením v databázi v kontextu celá škála předpokládané žádosti o informace.
3. Integrovaný přístup založený na metodě „entity-relationship“ spojuje výhody obou předchozích. Metoda je redukována na rozdělení celé předmětné oblasti na místní části, které jsou modelovány samostatně a poté znovu sloučeny do jediné oblasti.

Vzhledem k tomu, že použití metody entita-vztah je v této fázi kombinovanou metodou návrhu, stává se prioritou častěji než ostatní.

Lokální reprezentace s metodickým oddělením by měly pokud možno obsahovat informace, které by stačily k řešení samostatného problému nebo k zajištění požadavků pro některou skupinu potenciálních uživatelů. Každá z těchto oblastí obsahuje asi 6-7 entit a odpovídá jakékoli samostatné externí aplikaci.

Závislost entit se projevuje v jejich rozdělení na silné (základ, rodič) a slabé (dítě). Silná entita (například čtenář v knihovně) může existovat v databázi sama o sobě, zatímco slabá entita (například předplatné tohoto čtenáře) je "připojena" k silné a neexistuje samostatně.

Je nutné oddělit pojmy „instance entity“ (objekt charakterizovaný specifickými hodnotami vlastností) a pojem „typ entity“ – objekt, který je charakterizován společným názvem a seznamem vlastností.

Pro každou jednotlivou entitu jsou vybrány atributy (soubor vlastností), které v závislosti na kritériu mohou být:

• identifikace (s jedinečná hodnota pro entity tohoto typu, což z nich činí potenciální klíče) nebo popisné;
• jednohodnotové nebo vícehodnotové (s příslušným počtem hodnot pro instanci entity);
• základní (nezávislé na jiných atributech) nebo odvozené (vypočítané na základě hodnot jiných atributů);
• jednoduchý (nedělitelný jednosložkový) nebo složený (složený z více složek).

Poté se provede specifikace atributu, specifikace vazeb v místním zastoupení (rozdělené na nepovinné a povinné) a spojení místních zastoupení, které lze sloučit do jednoho až 4-5 místních regionů. krok. V případě nárůstu počtu dochází k binárnímu slučování oblastí v několika fázích.

Během tohoto a dalších mezistupňů se projevuje iterativní charakter návrhu, který je zde vyjádřen tím, že pro odstranění rozporů je nutné se vrátit do fáze modelování lokálních reprezentací pro upřesnění a změnu (např. změnit stejná jména sémanticky odlišných objektů nebo se dohodnout na atributech integrity na stejných atributech v různých aplikacích).

Výběr řídicího systému a databázového softwaru

Praktická implementace informačního systému závisí na volbě systému správy databáze. Nejdůležitějšími kritérii při výběru jsou parametry:

• typ datového modelu a jeho soulad s potřebami předmětné oblasti,
• příležitost v případě rozšíření informačního systému,
• výkonnostní charakteristiky zvoleného systému,
• provozní spolehlivost a pohodlí DBMS,
• nástroje zaměřené na pracovníky správy dat,
• náklady na samotný DBMS a další software.

Chyby ve výběru DBMS téměř jistě vyvolají potřebu později upravit koncepční a logické modely.

Návrh logické databáze

Logická struktura databáze musí odpovídat logickému modelu předmětné oblasti a zohledňovat vztah datového modelu k podporované DBMS. Etapa proto začíná výběrem datového modelu, kde je důležité vzít v úvahu jeho jednoduchost a přehlednost.

Struktura přirozených dat přednostně odpovídá modelu, který ji reprezentuje. Pokud jsou tedy například data prezentována ve formě hierarchické struktury, pak je lepší zvolit hierarchický model. V praxi je však taková volba častěji určována systémem správy databází, nikoli datovým modelem. Koncepční model je tedy ve skutečnosti převeden do datového modelu, který je kompatibilní s vybraným systémem správy databází.

Odráží se zde i povaha designu, která umožňuje (či nutnost) vrátit se ke konceptuálnímu modelu a změnit jej, pokud zde reflektované vztahy mezi objekty (resp. atributy objektů) nelze implementovat pomocí prostředků zvolené DBMS.

Po dokončení etapy by měla být vygenerována databázová schémata obou úrovní architektury (koncepční i externí), vytvořená v jazyce pro definici dat podporovaném vybranou DBMS.

Databázová schémata jsou generována pomocí jednoho ze dvou odlišných přístupů:

• nebo použití přístupu zdola nahoru, při práci z nižších úrovní definice atributů, seskupených do vztahů, které představují objekty, na základě vztahů existujících mezi atributy;
• nebo pomocí obráceného přístupu shora dolů, aplikovaného s výrazným (až stovky a tisíce) nárůstem počtu atributů.

Druhý přístup zahrnuje definici řady entit na vysoké úrovni a jejich vztahů s následným detailováním na požadovanou úroveň, která odráží například model vytvořený na základě metody „entity-relationship“. V praxi se však většinou oba přístupy kombinují.

Fyzický návrh databáze

Na další krok fyzický návrh databáze, logická struktura je zobrazena ve formě struktury úložiště databáze, to znamená, že je navázána na takové fyzické paměťové médium, kde budou data co nejefektivněji umístěna. Zde je podrobně popsáno datové schéma s uvedením všech typů, polí, velikostí a omezení. Kromě vývoje indexů a tabulek jsou definovány základní dotazy.

Konstrukce fyzikálního modelu je spojena s řešením protichůdných problémů v mnoha ohledech:

1. problémy s minimalizací prostoru pro ukládání dat,
2. cíle dosažení integrity, bezpečnosti a maximální výkon.

Druhý úkol je v rozporu s prvním, protože například:

• pro efektivní fungování transakcí musíte vyhradit místo na disku pro dočasné objekty,
• pro zvýšení rychlosti vyhledávání je třeba vytvořit indexy, jejichž počet je určen počtem všech možných kombinací polí zapojených do vyhledávání,
• pro obnovení dat bude databáze zálohována a bude veden protokol o všech změnách.

To vše zvětšuje velikost databáze, takže projektant hledá rozumnou rovnováhu, ve které jsou úlohy optimálně řešeny kompetentním umístěním dat do paměťového prostoru, nikoli však na úkor ochrany databáze, která zahrnuje jak ochranu před neoprávněným přístupem, tak ochranu z neúspěchů.

Pro dokončení tvorby fyzického modelu jsou vyhodnoceny jeho provozní charakteristiky (rychlost vyhledávání, efektivita provádění dotazu a spotřeba zdrojů, správnost operací). Někdy je tato fáze, jako jsou fáze implementace databáze, testování a optimalizace, stejně jako údržba a provoz, vyňata z rozsahu přímého návrhu databáze.

Federální agentura pro vzdělávání

Státní vzdělávací instituce vyššího odborného vzdělávání

AMUR STÁTNÍ UNIVERZITA

(GOUVPO "AmSU")

TEST

v oboru "Informační systémy v ekonomii"

na téma: "Principy výstavby a fáze navrhování databází"

Vykonavatel

student skupiny C - 81 N.A. Vokhmyanina

Dozorce

docent, Ph.D. D. G. Ševko

Blagoveščensk 2010

Úvod

1. Principy tvorby databází

2. Koncepce budování databází

3. Fáze návrhu databáze

Bibliografický seznam

ÚVOD

Vnímání skutečného světa lze korelovat se sledem různých, i když někdy vzájemně souvisejících jevů. Od pradávna se lidé pokoušeli tyto jevy popsat (i když jim nerozuměli). Takový popis se nazývá data.

Tradičně se sběr dat provádí pomocí specifického komunikačního prostředku, například pomocí přirozeného jazyka na určitém médiu.

V současnosti se úspěšné fungování různých firem, organizací a podniků jednoduše neobejde bez vyvinutého informačního systému, který umožňuje automatizovat sběr a zpracování dat. Obvykle je vytvořena databáze pro ukládání a přístup k datům obsahujícím informace o určité předmětné oblasti.

databáze (DB)- pojmenovaná množina dat, která odráží stav objektů a jejich vztahy v uvažované oblasti.

Předmět je obvykle chápán jako určitá oblast lidské činnosti nebo oblast reálného světa, která má být studována pro organizaci řízení a automatizace, například podnik, univerzita atd.

Systém pro správu databází (DBMS)- sada jazykových a softwarových nástrojů určených k vytváření, vyplňování, aktualizaci a mazání databází.

Programy, se kterými uživatelé pracují s databází, se nazývají aplikace.

1. ZÁSADY STAVEBNÍCH DATABÁZÍ

Na moderní databáze a následně i na DBMS, na kterých jsou postaveny, jsou kladeny následující základní požadavky.

1. Vysoký výkon (krátká doba odezvy na požadavek).

Doba odezvy – časový úsek od okamžiku požadavku do databáze do skutečného přijetí dat. Obdobným pojmem je doba přístupu – časový interval mezi vydáním příkazu pro zápis (čtení) a skutečným přijetím dat. Přístupem se rozumí operace vyhledávání, čtení nebo zápisu dat. Operace zápisu, mazání a úpravy dat se často označují jako operace aktualizace.

2. Snadná aktualizace dat.

3. Datová nezávislost.

4. Sdílení dat mezi mnoha uživateli.

5. Zabezpečení dat - ochrana dat před úmyslným či neúmyslným porušením tajemství, zkreslením nebo zničením.

6. Standardizace konstrukce a provozu databáze (ve skutečnosti DBMS).

8. Přátelské uživatelské rozhraní.

Nejdůležitější jsou první dva protichůdné požadavky: zlepšení výkonu vyžaduje zjednodušení struktury databáze, což naopak celý postup komplikuje aktualizace dat, zvyšuje jejich redundanci.

Nezávislost na datech- možnost měnit logickou a fyzickou strukturu databáze beze změny pohledů uživatelů.

Nezávislost dat znamená neměnnost povahy datového úložiště, softwaru a hardwaru. Poskytuje minimální změny ve struktuře databáze se změnami ve strategii přístupu k datům a struktuře samotných zdrojových dat. Toho je dosaženo „posunutím“ všech změn do koncepční a logické fáze návrhu s minimálními změnami během fáze fyzického návrhu.

Bezpečnost dat zahrnuje jejich integritu a ochranu.

Integrita dat - odolnost uložených dat proti zničení a zničení spojené s poruchami technické prostředky, systémové chyby a chybné jednání uživatelů.

Ona navrhuje:

1. absence nepřesně zadaných údajů nebo dvou stejných záznamů o stejné skutečnosti;

2. ochrana proti chybám při aktualizaci databáze;

3. nemožnost mazání (nebo kaskádové mazání) souvisejících dat různých tabulek;

4. nezkreslení dat při práci ve víceuživatelském režimu a v distribuovaných databázích;

5. bezpečnost dat v případě poruchy zařízení (obnova dat).

Integritu zajišťují spouštěče integrity – speciální aplikace-programy, které fungují za určitých podmínek. Ochrana údajů před neoprávněným přístupem zahrnuje omezení přístupu k důvěrným údajům a lze ji dosáhnout:

1. zavedení systému hesel;

2. získání oprávnění od správce databáze (DBA);

4. tvorba pohledů - tabulky odvozené od původních a určené pro konkrétní uživatele.

Poslední tři procedury se snadno provádějí v rámci Structured Query Language - SQL, často označovaného jako SQL2.

Standardizace zajišťuje návaznost generací DBMS, zjednodušuje interakci databází jedné generace DBMS se stejnými a různými datovými modely. Standardizace (ANSI/SPARC) byla do značné míry implementována z hlediska uživatelského rozhraní DBMS a jazyka SQL. To umožnilo úspěšně vyřešit problém interakce různých relační DBMS jak pomocí jazyka SQL, tak pomocí aplikace Open DataBase Connection (ODBC). V tomto případě jak místní, tak vzdálený přístup k datům (technologie klient/server nebo síťová možnost).

2. KONCEPCE VYTVÁŘENÍ DATABÁZE

Existují dva přístupy k budování databáze založené na dvou přístupech k vytvoření automatizovaného řídicího systému (ACS).

První z nich, hojně využívaný v 80. letech a proto tzv klasický (tradiční), spojené s automatizací workflow (soubor dokumentů pohybujících se v procesu podniku). Dokumenty byly počáteční a výstupní souřadnice, jak je vidět z příkladu1.

Byla použita následující teze. Data jsou méně mobilní než algoritmy, takže byste měli vytvořit obecnou databázi, kterou pak lze použít pro jakýkoli algoritmus. Brzy se však ukázalo, že vytvoření univerzální databáze je problematické. Koncept datové integrace, který donedávna dominoval s prudkým nárůstem jejich objemu, se ukázal jako neudržitelný. Navíc se začaly objevovat aplikace (např. grafický editor) založené na široce používaných standardních algoritmech.

V 90. letech 20. století vznikla druhá, moderní přístup spojené s řízením automatizace. Jedná se o prvotní identifikaci standardních aplikačních algoritmů (v zahraniční terminologii business algoritmů), pod kterými jsou definována data, potažmo databáze. Objektově orientované programování jen zvýšilo důležitost tohoto přístupu.

Při provozu databáze jsou možné režimy pro jednoho a více uživatelů (několik uživatelů se připojuje k jednomu počítači přes různé porty).

Použijte návrh databáze shora dolů a shora dolů. První se používá v distribuovaných databázích při integraci navržených lokálních databází, které lze provádět pomocí různé modely data. Typičtější pro centralizované databáze je design shora dolů.

3. FÁZE NÁVRHU DATABÁZE

Návrh databáze probíhá ve čtyřech fázích.

Na jevišti formulace a analýza požadavků jsou stanoveny cíle organizace, stanoveny požadavky na databázi. Skládají se z obecných požadavků definovaných v části 1 a specifických požadavků. Ke stanovení konkrétních požadavků se obvykle používá metoda dotazování personálu. různé úrovněřízení. Všechny požadavky jsou dokumentovány ve formě přístupné koncovému uživateli a návrháři databáze.

Etapa koncepční design spočívá v popisu a syntéze informační požadavky uživatelů do původního databázového projektu. Počátečními daty může být soubor uživatelských dokumentů v klasickém přístupu nebo aplikačních algoritmů (business algorithms) v moderním přístupu. Výsledkem této etapy je vysokoúrovňová reprezentace (ve formě databázového tabulkového systému) požadavků na informace uživatelů na základě různých přístupů.

Nejprve je vybrán model databáze. Poté je vytvořena databázová struktura, která se plní daty pomocí systémů menu, obrazovkových formulářů nebo v režimu prohlížení databázové tabulky. Poskytuje také ochranu a integritu (včetně referenčních) dat pomocí DBMS nebo vytvářením spouštěčů.

Probíhá logický design reprezentace dat na vysoké úrovni je převedena do struktury použitého DBMS. Hlavním cílem etapy je odstranění redundance dat pomocí speciálních normalizačních pravidel. Cílem normalizace je minimalizovat opakování dat a případné strukturální změny databáze během aktualizačních procedur. Toho je dosaženo rozdělením (rozložením) jedné tabulky na dvě nebo více s následným použitím navigačních operací v dotazech. Všimněte si, že navigační vyhledávání zpomaluje výkon databáze, tzn. zvyšuje dobu odezvy na dotaz. Výslednou logickou strukturu databáze lze kvantifikovat pomocí různé vlastnosti(počet přístupů k logickým záznamům, množství dat v každé aplikaci, celkové množství dat). Na základě těchto hodnocení lze logický rámec zlepšit, aby se dosáhlo vyšší účinnosti.

Kroky návrhu databáze

Proces návrhu zahrnuje následující kroky:

• 1. Infologický design.
• 2. Stanovení požadavků na provozní prostředí, ve kterém bude informační systém fungovat.
• 3. Výběr systému pro správu databází (DBMS) a dalších softwarových nástrojů.
• 4. Návrh datové (logické) databáze.
• 5. Fyzický návrh databáze.

V první fázi vytváří vývojář (správce databáze) spojením soukromých pohledů na obsah databáze získaných na základě uživatelských průzkumů a vlastních pohledů na data, která mohou být vyžadována v budoucích aplikacích. zobecněný neformální popis databáze. Tento popis se provádí pomocí přirozeného jazyka, matematické vzorce, tabulky, grafy a další nástroje, které jsou srozumitelné všem lidem pracujícím na návrhu databáze. Takový popis předmětné oblasti se nazývá infologický datový model.

Infoologický datový model je model orientovaný na člověka a je zcela nezávislý na fyzických parametrech prostředí úložiště dat. Takovým paměťovým médiem může být lidská paměť, nikoli počítač. Proto se infoologický model nezmění, dokud některé změny v reálném světě nevyžadují provedení příslušných změn tak, aby tento model nadále odrážel předmětnou oblast.

Zbývající modely, datové a fyzické, jsou počítačově orientované. S jejich pomocí umožňuje DBMS programům a uživatelům přístup k uloženým datům pouze pod jejich jmény, bez obav o fyzické umístění těchto dat. Potřebná data najde DBMS na externích úložných zařízeních pomocí fyzický datový model.

Vzhledem k tomu, že specifikovaný přístup je prováděn pomocí specifické DBMS, modely musí být popsány v jazyce popisu dat této DBMS. Takový popis se nazývá datalogický datový model.

Třívrstvá architektura (infologická, datalogická a fyzické vrstvy) umožňuje zajistit nezávislost uložených dat na programech, které je používají. Vývojář může v případě potřeby přepsat uložená data na jiná paměťová média nebo reorganizovat jejich fyzickou strukturu a změnit pouze fyzický datový model. DBA může do systému připojit libovolný počet nových uživatelů (nových aplikací) a v případě potřeby doplnit datalogický model. Uvedené fyzické změny a datum logické modely nezaznamenají stávající uživatelé systému (bude pro ně „transparentní“), stejně jako si nevšimnou nových uživatelů. Proto nezávislost na datech umožňuje databázovému systému vyvíjet se bez narušení stávajících aplikací.

Infologický (informačně-logický) model.Účelem infoologické fáze návrhu je získat sémantické (konceptuální) modely, které odrážejí předmětovou oblast a informační potřeby uživatelů. Proto se této fázi také říká sémantické modelování. Sémantické modelování je modelování datových struktur na základě významu těchto dat.

pojem "Předmět"- základní v teorii databází a nemá striktní definici. Vyplývá to z pojmů „objekt“ a „objekt“. Předmětná oblast(PODLE)- část reálného světa, kterou je třeba studovat za účelem organizace řízení a nakonec automatizace. Zdá se, že softwaru je mnoho fragmenty, které se vyznačují mnoha objektů, soubor procesů, které využívají objekty, a také soubor uživatelů vyznačujících se jediným pohledem na předmětnou oblast.

objekt nazýván fenoménem vnějšího světa. Buď je to něco skutečně existujícího – osoba, produkt, produkt, nebo proces – antikoncepce, příjem zboží, výroba produktů. Každý objekt má obrovské množství vlastností.

Příklady.

Objekt " Člověk" má vlastnosti: výška, jméno, datum narození ... ,

objekt - " Produkt"má vlastnosti: kvalita, datum výroby, vzhled ....

Mezi objekty existuje mnoho spojení. Například:

• · Člověk nakupuje, prodává, vyrábí Produkt
• · Produkt vytvořili, koupili, prodali člověk.

Položka - model reálného objektu, ve kterém jsou fixovány pouze vlastnosti a vztahy vybrané pro IS. Formuláře sady vybraných položek jádro objektu předmětová oblast a souhrn jejich vztahů - struktura fragmentu reality . Že. pojem „Předmětová oblast“ odpovídá pohledu spotřebitele na jádro objektu: zvýrazňuje pouze ty objekty, vlastnosti objektů a vztahy mezi objekty, které mají pro IS hodnotu a měly by být uloženy v databázi.

Všechny akce k identifikaci jádra předmětné oblasti se provádějí ve fázi analýzy IP.

Objektové jádro systému během životního cyklu IS nezůstává konstantní: objekty mizí a objevují se, mění se jejich vlastnosti a vztahy. Řetězce těchto změn fixované v čase se nazývají trajektorie oborů, a agregát společné vlastnosti trajektorie - doménová sémantika

Existuje celá řada technik modelování domén. Jedna z aktuálně nejpopulárnějších technik je založena na použití grafických diagramů, které obsahují malý počet heterogenních komponent ERD (Entity-Relationship Diagrams). V ruskojazyčné literatuře se těmto diagramům říká „objekt – vztah“ nebo „podstata – spojení“.

Model ERD byl navržen v roce 1976. Peter Ping-sheng Chen. Následně mnoho autorů vyvinulo své vlastní verze takových modelů: Martinův zápis, IDEF1X zápis, Barkerův zápis), ale všechny jsou založeny na grafických diagramech navržených Chenem.

Většina moderních přístupů k navrhování relačních databází je založena na použití různých modelů ER.

Ve skutečnosti všechny varianty diagramů entit-vztahů vycházejí ze stejné myšlenky – výkres je vždy jasnější. textový popis. Všechny takové diagramy využívají grafické znázornění entit předmětné oblasti, jejich vlastností (atributů) a vztahů mezi entitami.

Seznámíme se s ER diagramy v Barkerově zápisu, jelikož základní myšlenky jsou celkem snadno pochopitelné.

Základní pojmy ER-diagramů. Hlavními pojmy ER-modelu jsou entita, vztah a atribut.

Pro větší výraznost a lepší pochopení může být název entity doplněn příklady. konkrétní objekty tohoto typu.

Definice 1. Podstata je skutečný nebo imaginární objekt, o kterém musí být informace uloženy a dostupné. Entity mohou být lidé, místa, letadla, lety, chutě, barvy a tak dále.

Každá entita musí mít jméno vyjádřené podstatným jménem v jednotném čísle. V tomto případě je názvem entity název typu a ne nějaká konkrétní instance tohoto typu. Koncept typu entity se týká souboru homogenních osob, předmětů, událostí nebo myšlenek, které působí jako celek.

Příklady entit mohou být takové třídy objektů jako "Dodavatel", "Zaměstnanec", "Faktura".

Každá entita v modelu je zobrazena jako obdélník obsahující název entity:

Definice 2. Instance entity je konkrétním zástupcem tohoto subjektu.

Například zástupcem entity "Zaměstnanec" může být "Zaměstnanec Ivanov".

Instance entity musí být rozlišitelné, tj. entity musí mít některé vlastnosti, které jsou jedinečné pro každou instanci této entity.

Definice 3. atribut entity je pojmenovaná charakteristika entity. Jeho název musí být jedinečný pro konkrétní typ entity, ale může být stejný pro různé typy entit (například BARVA může být definována pro mnoho entit: DOG, CAR, PAINT atd.). Atributy se používají k definování toho, jaké informace by se měly o entitě shromažďovat. Příklady atributů entity CAR jsou TYPE, MARK, SPZ, COLOR a tak dále.

I zde je rozdíl mezi typem atributu a instancí. Typ atributu COLOR má mnoho instancí nebo hodnot: Červená, Modrá, Banán, Bílá noc atd., avšak každé instanci entity je přiřazena pouze jedna hodnota atributu.

Mezi typy entit a atributy neexistuje absolutní rozdíl. Atribut je takový pouze ve spojení s typem entity. V jiném kontextu může atribut fungovat jako samostatná entita. Například pro továrnu na automobily je barva pouze atributem produktu, zatímco pro továrnu na barvy je barva typem entity.

Každý atribut je opatřen názvem, který je v rámci entity jedinečný. Název atributu musí být vyjádřen jako podstatné jméno v jednotném čísle (případně s charakteristickými přídavnými jmény).

Příkladem atributů entity „Zaměstnanec“ mohou být atributy jako „Osobní číslo“, „Příjmení“, „Jméno“, „Patronym“, „Pozice“, „Plat“ atd.

Atributy jsou zobrazeny v obdélníku, který definuje entitu:

Atributy lze klasifikovat podle příslušnosti k jednomu ze tří různé typy: popisný, uvádějící, pomocný.

popisný atributy představují fakta vlastní každé instanci entity.

Ukazování atributy se používají k pojmenování nebo označení instancí entity.

Pomocný atributy se používají k přidružení instance jedné entity k instanci jiné. Atributy se řídí přesně stanovenými pravidly.

Definice 4. Klíč entity - minimální sada atributů, podle jejichž hodnot můžete jednoznačně najít požadovanou instanci entity. Minimalita znamená, že vyloučení jakéhokoli atributu z množiny neumožňuje identifikovat entitu těmi zbývajícími.

Například pro entitu Plán klíč je atribut Číslo letu nebo nastavit: Místo ODJEZDU, Čas odjezdu A Destinace(za předpokladu, že jedno letadlo létá z bodu do bodu najednou).

Entita může mít několik různých klíčů.

Klíčové atributy jsou v diagramu podtržené:

Definice 5. Spojení je nějaká asociace mezi dva entity. Jedna entita může souviset s jinou entitou nebo sama se sebou. Vztahy umožňují jedné entitě najít další entity s ní spojené.

Pokud by účelem databáze bylo pouze ukládat samostatná, nesouvisející data, pak by její struktura mohla být velmi jednoduchá. Jedním z hlavních požadavků na organizaci databáze je však poskytnout možnost vyhledání některých entit podle hodnot jiných, pro které je nutné mezi nimi vytvořit určité vztahy. A protože skutečné databáze často obsahují stovky nebo dokonce tisíce entit, teoreticky mezi nimi lze navázat více než milion vztahů. Přítomnost takového množství spojení určuje složitost infoologických modelů.

Vztahy mezi entitami lze vyjádřit například následujícími frázemi - "ZAMĚSTNANEC může mít několik DĚTÍ", "každý ZAMĚSTNANEC musí být registrován právě v jednom ODDĚLENÍ".

Graficky je vztah reprezentován čárou spojující dvě entity:

Každý odkaz má dva konce a jeden nebo dva názvy. Jméno je obvykle vyjádřeno neurčitou slovesnou formou: „mít“, „patřit“ atd. Každý z názvů odkazuje na svůj konec spojení. Někdy se jména nepíší kvůli jejich samozřejmosti.

Každý odkaz může mít jednu z následujících možností typy komunikace :

Typ komunikace jedna ku jedné znamená, že jedna instance první entity (vlevo) je spojena s jednou instancí druhé entity (vpravo). Vztah jedna ku jedné nejčastěji naznačuje, že ve skutečnosti máme pouze jednu entitu, nesprávně rozdělenou na dvě.

Typ komunikace jeden k mnoha znamená, že jedna instance první entity (vlevo) je spojena s několika instancemi druhé entity (vpravo). Toto je nejčastěji používaný typ připojení. Zavolá se levá entita (na "jedné" straně). rodičovský , vpravo (ze strany "mnoho") - dceřiná společnost . (viz obr. grafický obrázek připojení)

Typ komunikace mnoho-k-mnoho znamená, že každá instance první entity může být spojena s více instancemi druhé entity a každá instance druhé entity může být spojena s více instancemi první entity. Typ vztahu mnoho k mnoha je dočasný typ vztahu povolený v raných fázích vývoje modelu. V budoucnu by tento typ vztahu měl být nahrazen dvěma vztahy one-to-many vytvořením zprostředkující entity.

Každé připojení může mít jeden ze dvou komunikační modality :

modalita" Možná může souviset s jednou nebo více instancemi jiné entity, možná nesouvisí ani jedna kopie.

modalita" musí " znamená, že instance jedné entity musí být spojena alespoň s jedním instance jiné entity.

Spojení může mít různá modalita z různých konců.

Popsaná grafická syntaxe umožňuje rozhodněčtěte diagramy pomocí následujícího schématu frázování:

<Каждый экземпляр СУЩНОСТИ 1> <МОДАЛЬНОСТЬ СВЯЗИ> <НАИМЕНОВАНИЕ СВЯЗИ> <ТИП СВЯЗИ> <экземпляр СУЩНОСТИ 2>.

Každý odkaz lze číst zleva doprava nebo zprava doleva. Například odkaz na obrázku 4 výše zní:

Zleva doprava: "Každý zaměstnanec může mít více dětí."

Zprava doleva: "Každé dítě musí patřit právě jednomu zaměstnanci."

Normální formy ER schémat. Stejně jako ve schématech relačních databází zavádějí ER diagramy pojem normální formy a jejich význam velmi úzce odpovídá významu relačních normálních forem. Uvádíme pouze velmi stručné a neformální definice prvních tří normálních forem.

V první normální forma ER diagramu eliminuje duplicitní atributy nebo skupiny atributů, tzn. jsou detekovány implicitní entity „převlečené“ za atributy.

v druhý normální jsou eliminovány atributy, které závisí pouze na části jedinečného identifikátoru (klíči entity). Tato část jedinečného identifikátoru identifikuje jednu entitu.

V třetí normální formulář, atributy, které závisí na atributech, které nejsou zahrnuty v jedinečném identifikátoru (klíči entity), jsou eliminovány. Tyto atributy jsou základem jediné entity.

Při správné definici entit budou výsledné tabulky okamžitě v 3NF. Hlavní výhodou metody je, že model je sestaven metodou postupného zpřesňování výchozích diagramů.

Načtení relačního schématu ze schématu ER:

Krok 1. Každá jednoduchá entita se promění v tabulku. Jednoduchá entita je entita, která není podtypem a nemá žádné podtypy. Název entity se stane názvem tabulky.

Krok 2 Každý atribut se stane možným sloupcem se stejným názvem; lze zvolit přesnější formát. Sloupce odpovídající volitelným atributům mohou obsahovat hodnoty null; sloupce, které odpovídají požadovaným atributům, nemohou.

Krok 3 Komponenty jedinečného identifikátoru entity se změní na primární klíč tabulky. Pokud existuje více možných jedinečných identifikátorů, vybere se ten nejpoužívanější. Pokud jedinečný identifikátor zahrnuje vztahy, je do sloupců primárního klíče přidána kopie jedinečného identifikátoru entity na vzdáleném konci vztahu (tento proces může pokračovat rekurzivně). K pojmenování těchto sloupců se používají názvy konců odkazů a/nebo názvy entit.

Krok 4 Vztahy many-to-one (a one-to-one) se stávají cizími klíči. Tito. vytvoří se kopie jedinečného identifikátoru z konce vztahu "one" a odpovídající sloupce tvoří cizí klíč. Volitelné vztahy odpovídají sloupcům, které umožňují hodnoty null; povinné vztahy - sloupce, které neumožňují hodnoty null.

Krok 5 Indexy se vytvářejí pro primární klíč (unikátní index), cizí klíče a atributy, na kterých mají být založeny dotazy.

Krok 6 Pokud byly v konceptuálním schématu přítomny podtypy, jsou možné dvě metody:

• všechny podtypy v jedné tabulce (tabulkách)
• pro každý podtyp - samostatná tabulka (b)

V metodě (a) je vytvořena tabulka pro nejvzdálenější supertyp a pohledy mohou být vytvořeny pro podtypy. Do tabulky je přidán alespoň jeden sloupec obsahující kód TYPE; stává se součástí primárního klíče.

Při použití metody (b) je pro každý podtyp první úrovně (pro nižší - reprezentace) nadtyp znovu vytvořen pomocí reprezentace UNION (společné sloupce jsou vybírány ze všech tabulek podtypů - sloupců nadtypu).

Krok 7 Existují dva způsoby, jak pracovat s exkluzivními vztahy:

• společné domény
• explicitní cizí klíče (b)

Pokud jsou zbývající cizí klíče všechny ve stejné doméně, tzn. mají společný formát (metoda (a)), vytvoří se dva sloupce: ID vztahu a ID entity. Sloupec ID odkazu se používá k rozlišení odkazů pokrytých obloukem vyloučení. Sloupec ID entity se používá k uložení hodnot jedinečného identifikátoru entity na vzdáleném konci přidruženého vztahu.

Pokud výsledné cizí klíče nepatří do stejné domény, pak se pro každý vztah pokrytý obloukem vyloučení vytvoří explicitní sloupce cizího klíče; všechny tyto sloupce mohou obsahovat hodnoty null.

Příklad vývoje jednoduchého ER modelu. Při vývoji modelů ER musíme získat následující informace o předmětu:

• 1. Seznam subjektů předmětné oblasti.
• 2. Seznam atributů entity.
• 3. Popis vztahů mezi entitami.

ER diagramy jsou vhodné v tom, že proces extrakce entit, atributů a vztahů je iterativní. Po vytvoření první přibližné verze diagramů je upřesňujeme rozhovory s odborníky na dané téma. Dokumentací, ve které jsou zaznamenány výsledky rozhovorů, jsou přitom samotné ER diagramy.

Předpokládejme, že stojíme před úkolem rozvíjet se informační systém objednává velkoobchodník. Nejprve si musíme prostudovat předmětnou oblast a procesy v ní probíhající. Za tímto účelem vedeme rozhovory se zaměstnanci společnosti, čteme dokumentaci, studujeme formuláře objednávek, faktury atd.

Například během rozhovoru s manažerem prodeje se ukázalo, že on (manažer) věří, že navrhovaný systém by měl provádět následující akce:

• · Ukládat informace o zákaznících.
• · Tisk faktur za vydané zboží.
• · Sledujte skladovou dostupnost.

Vyberme všechna podstatná jména v těchto větách - budou to potenciální kandidáti na entity a atributy a analyzujme je (nesrozumitelné výrazy zvýrazníme otazníkem):

• · Kupující
• · faktura je jasným kandidátem na entitu.
• · Produkt- jasný kandidát na subjekt
• · (?)Skladem- A obecně, kolik skladů má společnost? Pokud je více, pak bude kandidátem na nový subjekt.
• · (?)Dostupnost produktu- toto je s největší pravděpodobností atribut, ale atribut jaké entity?

Okamžitě je mezi subjekty zřejmá souvislost – „zákazníci mohou koupit mnoho produktů“ a „produkty mohou být prodány mnoha kupujícím“. První diagram vypadá takto:

Položením doplňujících otázek vedoucímu jsme zjistili, že společnost má několik skladů. Kromě toho může být každý produkt skladován v několika skladech a může být prodáván z jakéhokoli skladu.

Kam entity „Faktura“ a „Sklad“ umístit a k čemu je přiřadit? Položme si otázku, jak tyto entity souvisí mezi sebou a s entitami „Kupující“ a „Produkt“?

• · Kupující nakupuje zboží, přičemž dostává faktury, které obsahují údaje o množství a ceně nakupovaného zboží.
• · Každý zákazník může obdržet více faktur.
• · Každá faktura musí být vystavena pro jednoho kupujícího.
• · Každý nákladní list musí obsahovat několik zboží (neexistují prázdné nákladní listy). Každá položka může být prodána více zákazníkům prostřednictvím více faktur.
• · Kromě toho musí být každá faktura vystavena z konkrétního skladu a z libovolného skladu lze vystavit více faktur.

Po upřesnění tedy bude schéma vypadat takto:

zobrazení informací infologických atributů

Je čas přemýšlet o atributech entity. V našich rozhovorech se zaměstnanci společnosti jsme zjistili následující:

• · Každý kupující je právnickou osobou a má jméno, adresu, bankovní spojení.
• · Každý produkt má název, cenu a je také charakterizován měrnými jednotkami.
• Každá faktura má jedinečné číslo, datum vystavení, seznam zboží s množstvím a cenami a Celková částka nad hlavou. Faktura je vystavena z konkrétního skladu a pro konkrétního zákazníka.
• · Každý sklad má svůj vlastní název.

Opět vypíšeme všechna podstatná jména, která budou potenciálními atributy, a analyzujeme je:

• · Entita - rétorický termín, se kterým nepracujeme Jednotlivci. Nevěnujeme pozornost.
• · Jméno kupujícího
• · Adresa- jasná charakteristika kupujícího.
• · bankovní detaily- jasná charakteristika kupujícího.
• · Název produktu
• · (?) Cena produktu- Zdá se, že je to vlastnost produktu. Liší se tato vlastnost od ceny na faktuře?
• · Jednotka- jasný popis produktu.
• · Číslo faktury- jasná jedinečná vlastnost nákladního listu.
• · Datum faktury- výslovná charakteristika nákladního listu.
• · (?)Seznam zboží na faktuře- Seznam nemůže být atributem. Pravděpodobně budete muset tento seznam rozdělit do samostatné entity.
• · (?) Množství zboží ve faktuře- to je jasná charakteristika, ale charakteristika čeho? To není jen charakteristika „zboží“, ale „zboží na nákladním listu“.
• · (?)Cena zboží na faktuře- opět by se nemělo jednat pouze o popis zboží, ale o popis zboží ve faktuře. Ale cena zboží se již setkala výše - je to totéž?
• · Částka faktury- výslovná charakteristika nákladního listu. Tato vlastnost není nezávislá. Částka faktury se rovná součtu nákladů na veškeré zboží zahrnuté ve faktuře.
• · Název skladu- jasný popis skladu.

Při dodatečném rozhovoru s manažerem se to podařilo vyjasnit různé koncepty ceny. Ukázalo se, že každá položka má nějakou aktuální cenu. Jedná se o cenu, za kterou se produkt prodává tento moment. Tato cena se samozřejmě může v průběhu času měnit. Cena stejného produktu na různých fakturách vystavených v jiný čas, může být jiný. Tedy existuje dvě ceny- cena zboží na faktuře a aktuální cena zboží.

S nově vznikajícím konceptem „Seznam zboží na faktuře“ je vše celkem jasné.

Entity "Faktura" a "Produkt" spolu souvisí vztahem typu mnoho-k-mnoho. Takové spojení, jak jsme již poznamenali, by mělo být rozdělit do dvou vztahů jeden k mnoha. To vyžaduje další podstata.

Tato entita bude entitou "Seznam zboží na faktuře". Jeho vztah k entitám „Faktura“ a „Produkt“ je charakterizován následujícími frázemi

- "každý nákladní list musí mít několik položek ze seznamu zboží v nákladním listu",

• - "každý záznam ze seznamu zboží ve faktuře musí být zahrnut právě v jedné faktuře",
• -"každý produkt lze zahrnout do několika položek ze seznamu produktů na faktuře",
• - "Každý záznam ze seznamu zboží ve faktuře musí být spojen právě s jedním produktem."

Atributy "Množství zboží na faktuře" a "Cena zboží na faktuře" jsou atributy entity "Seznam zboží na faktuře".

Totéž udělejme s propojením propojujícím entity „Sklad“ a „Zboží“. Pojďme se představit další subjekt "Zboží skladem". Atribut této entity bude „Množství zboží na skladě“. Zboží tedy bude uvedeno na jakémkoli skladě a jeho množství na každém skladě bude jiné.

Nyní to vše můžete dát do grafu:

Koncepční a fyzikální modely ER. Příklad ER diagram vyvinutý výše je příkladem koncepční diagram. To znamená, že graf nebere v úvahu vlastnosti konkrétního DBMS. Z tohoto konceptuálního diagramu lze konstruovat fyzikální schéma, který již bude brát v úvahu takové vlastnosti DBMS, jako jsou platné typy a názvy polí a tabulek, integritní omezení atd. Fyzická verze výše uvedeného diagramu může vypadat například takto:

V tomto diagramu je každá entita databázovou tabulkou, každý atribut se stává sloupcem odpovídající tabulky. Upozorňujeme, že v mnoha tabulkách, například "VLASTNÍ_DETAIL" a "PROD_IN_SKLAD", odpovídající entitám "Záznam seznamu faktur" a "Položka zásob", jsou nové atributy, které nebyly v konceptuálním modelu - to jsou klíčové atributy nadřazených tabulek, migroval k podřízeným tabulkám za účelem poskytnutí vztahu mezi tabulkami prostřednictvím cizích klíčů.

Výsledné tabulky jsou v 3NF.

Diagramy entitních vztahů umožňují používat vizuální grafické symboly pro modelování entit a jejich vztahů.

Rozlišovat pojmový A fyzický ER diagramy. Konceptuální diagramy neberou v úvahu vlastnosti konkrétních DBMS. Fyzické diagramy jsou sestaveny podle konceptuálních diagramů a představují prototyp konkrétní databáze. Entity definované v konceptuálním diagramu se stávají tabulkami, atributy sloupci tabulek (současně se berou v úvahu datové typy a názvy sloupců povolené pro daný DBMS), vztahy jsou implementovány pomocí migrace klíčové atributy nadřazených entit a vytváření cizích klíčů.

Složitější prvky modelu ER. Zaměřili jsme se pouze na nejzákladnější a nejzřetelnější koncepty datového modelu ER. Mezi složitější prvky modelu patří následující:

Podtypy a nadtypy entit. Stejně jako v programovacích jazycích s vyvinutými typovými systémy (například v objektově orientovaných programovacích jazycích) je zavedena možnost zdědit typ entity na základě jednoho nebo více supertypů.

Entitu lze rozdělit na dva nebo více vzájemně se vylučujících podtypů, z nichž každý zahrnuje společné atributy a/nebo vztahy. Tyto společné atributy a/nebo vztahy jsou explicitně definovány ještě jednou vysoká úroveň. Podtypy mohou definovat své vlastní atributy a/nebo vztahy. V zásadě může podtypování pokračovat dále nízké úrovně, ale zkušenost ukazuje, že ve většině případů stačí dvě nebo tři úrovně.

Entita, ze které jsou definovány podtypy, se nazývá nadtyp. Podtypy musí tvořit kompletní sadu, tzn. každá instance nadtypu musí patřit do nějakého podtypu. Někdy je pro úplnost nutné definovat další podtyp OSTATNÍ.

Příklad: Supertype AIRCRAFT

Jak se to má číst? Od supertypu: LETADLO, což musí být LETADLO, VRTULNÍK, PTÁCI nebo JINÉ LETADLO. Od podtypu: VRTULNÍK, který patří do typu LETADLA. Z podtypu, který je zároveň nadtypem: LETADLO, které patří k typu LETADLA a musí to být KLUZÁK nebo MOTOROVÉ LETADLO.

Někdy je vhodné mít dva nebo více různých podtypů entity. Například entitu ČLOVĚKA lze rozdělit do podtypů podle profesních charakteristik (PROGRAMÁTOR, MLÉKÁŘ atd.), nebo třeba - podle pohlaví (MUŽ, ŽENA).

• · Vztahy mnoho k mnoha. Někdy je nutné propojit entity tak, aby na obou koncích vazby mohlo být více instancí entity (např. všichni členové družstva společně vlastní majetek družstva). K tomu se zavádí jakýsi vztah „mnoho k mnoha“.
• · Stanovené stupně připojení. Někdy je užitečné určit možný počet instancí entit účastnících se daného vztahu (např. zaměstnanec se smí zúčastnit maximálně tří projektů najednou). Pro vyjádření tohoto sémantického omezení je povoleno na konci spojení uvést jeho maximální nebo povinný stupeň.
• · Kaskádové mazání instancí entit. Některé vztahy jsou tak silné (samozřejmě v případě vztahu jedna k mnoha), že když se odstraní instance referenční entity (odpovídající konci vztahu „jedna“), všechny instance entity odpovídající konci musí být vymazán i vztah „mnoho“. Odpovídající požadavek na „kaskádové odstranění“ lze formulovat při definování entity.
• · domény. Jako v případě relační model dat, je užitečné mít možnost určit potenciálně platnou sadu hodnot pro atribut entity (domény).

Nejsprávnější intuitivní výklad pojmu domény je chápání domény jako platné potenciální množiny hodnot daného typu. Například doména "Jména" je definována na základním typu řetězce znaků, ale její hodnoty mohou obsahovat pouze řetězce, které mohou představovat jméno (takové řetězce zejména nemohou začínat měkkým znakem).

Je třeba také poznamenat sémantický význam konceptu domény: data jsou považována za srovnatelná pouze tehdy, pokud patří do stejné domény. V našem příkladu jsou hodnoty domén „Čísla průchodů“ a „Čísla skupin“ celočíselného typu, ale nejsou srovnatelné.

Tyto a další složitější prvky datového modelu Entity-Relationships jej výrazně zlepšují, ale zároveň poněkud ztěžují jeho použití.

Kroky návrhu databáze

Všechny jemnosti budování informačního modelu určité předmětové oblasti lidské činnosti mají jeden cíl - získat dobrou databázi. Vysvětlíme si pojem dobrá databáze a zformulujeme požadavky, které musí taková databáze splňovat:

1. Databáze musí odpovídat informačním potřebám uživatelů (organizací) a strukturou a obsahem odpovídat řešeným úkolům;

2. Databáze musí poskytnout požadované údaje v přiměřené době, tzn. splňovat požadavky na výkon;

3. Databáze by měla být snadno rozšiřována při reorganizaci předmětové oblasti;

4. Databáze by měla být snadno změněna, když se změní softwarové a hardwarové prostředí;

5. Správná data načtená do databáze musí zůstat správná (při zadávání je nutné zkontrolovat správnost dat).

Zvažte hlavní fáze návrhu (obr. 3.5):

První etapa. Plánování rozvoje databáze. V této fázi bude zdůrazněn nejúčinnější způsob implementace fází. životní cyklus systémy.

Druhá fáze. Stanovení systémových požadavků. Definuje se rozsah a hranice databázové aplikace a shromažďují a analyzují se požadavky uživatelů.

Třetí etapa. Návrh koncepčního databázového modelu. Proces vytváření databáze začíná definicí koncepčního modelu, který představuje objekty a jejich vztahy, aniž by bylo specifikováno, jak jsou fyzicky uloženy. Úsilí v této fázi by mělo být zaměřeno na strukturování dat a identifikaci vztahů mezi nimi. Tento proces lze rozdělit do několika dalších dílčích kroků:

a) Specifikace úkolu. Před zahájením práce na konkrétní aplikaci vývojář má obvykle určitou představu o tom, co bude vyvíjet. V jiných případech, kdy se vyvíjí malá osobní databáze, mohou být takové reprezentace zcela úplné. V jiných případech, kdy se rozsáhlá databáze vyvíjí na zakázku, může být takových pohledů velmi málo, nebo budou určitě povrchní. Je zjevně příliš brzy začít s vývojem s definicí tabulek, polí a vztahů mezi nimi. Tento přístup může vést k úplnému přepracování většiny aplikací. Proto byste měli věnovat nějaký čas sestavování seznamu všech hlavních úkolů, které by v zásadě měla tato aplikace vyřešit, včetně těch, které mohou v budoucnu nastat.

Rýže. 3.5. Schéma návrhu databáze

b) Vyjasnění posloupnosti úkolů. Aby aplikace fungovala logicky a pohodlně, je nejlepší uspořádat hlavní úkoly do skupin a úkoly každé skupiny pak uspořádat tak, aby byly v pořadí, v jakém jsou splněny. Seskupení a grafické znázornění pořadí jejich provádění pomůže určit přirozené pořadí úkolů.

c) Analýza dat. Po definování seznamu úkolů je nutné pro každý úkol vytvořit podrobný seznam údajů potřebných pro jeho řešení. Po fázi analýzy dat můžete přistoupit k vývoji konceptuálního modelu, tzn. k výběru objektů, atributů a vztahů.

Čtvrtá etapa. Sestavení logického modelu. Konstrukce logického modelu začíná výběrem datového modelu. Při výběru modelu důležitá role hraje jednoduchost, viditelnost a srovnání přirozené datové struktury s modelem, který ji představuje. Pokud je například hierarchická struktura součástí samotných dat, pak by bylo vhodnější zvolit hierarchický model. Ale často je tato volba určena úspěšností (nebo dostupností) konkrétního DBMS. To znamená, že vývojář si vybírá DBMS, nikoli datový model. V této fázi je tedy koncepční model převeden na datový model, který je kompatibilní s vybraným DBMS. Je možné, že vztahy mezi objekty zobrazenými v konceptuálním modelu nebo některé atributy objektů se později ukáží jako nerealizovatelné pomocí zvolené DBMS. To bude vyžadovat změnu koncepčního modelu. Verze koncepčního modelu, kterou může poskytnout konkrétní DBMS, se nazývá logický model. Někdy se proces definování konceptuálních a logických modelů nazývá definování datové struktury.

Pátá etapa. Konstrukce fyzikálního modelu. Fyzický model definuje rozložení dat, přístupové metody a techniku ​​indexování. Ve fázi fyzického návrhu jsme vázáni na konkrétní DBMS a podrobněji popisujeme datové schéma s uvedením typů, velikostí polí a omezení. Kromě návrhu tabulek a indexů tento krok definuje také základní dotazy.

Při konstrukci fyzikálního modelu je nutné řešit dva problémy, které jsou ve své podstatě vzájemně opačné. Prvním je minimalizace prostoru pro ukládání dat a druhým maximalizace výkonu, integrity a zabezpečení dat. Například pro zajištění vysoké rychlosti vyhledávání je nutné vytvořit indexy a jejich počet bude dán všemi možnými kombinacemi polí zapojených do vyhledávání; Obnova dat vyžaduje protokolování všech změn a vytváření zálohy DB; Pro efektivní práce transakce vyžadují vyhrazení místa na disku pro dočasné objekty atd., což vede ke zvětšení (někdy značnému) velikosti databáze.

Šestá etapa. Odhad fyzikálního modelu. V této fázi se provádí hodnocení výkonu. Zde můžete zkontrolovat efektivitu provádění dotazů, rychlost vyhledávání, správnost a pohodlí provádění operací s databází, integritu dat a efektivitu spotřeby počítačových zdrojů. Při neuspokojivém výkonu je možné se vrátit k revizi fyzických a logických datových modelů, volbě SŘB a typu počítače.

sedmá etapa. Implementace DB. S uspokojivým výkonem můžete přejít k vytváření rozvržení aplikace, tedy sady základních tabulek, dotazů, formulářů a sestav. Toto předběžné uspořádání lze zákazníkovi předvést a získat souhlas před podrobnou implementací aplikace.

Osmá etapa. Testování a optimalizace. Povinnou fází je testování a optimalizace vyvíjené aplikace.

Devátá etapa, finále. Údržba a provoz. Vzhledem k tomu, že během testovací fáze není možné identifikovat a odstranit všechny chyby, je fáze údržby pro databáze společná.

Existují dva hlavní přístupy k návrhu datového schématu: shora dolů a zdola nahoru. S přístupem zdola nahoru začíná práce od nižší úrovně - úrovně definujících atributů, které se na základě analýzy vztahů mezi nimi seskupují do vztahů reprezentujících objekty a vztahy mezi nimi. Proces normalizace tabulek pro relační datový model je typickým příkladem tohoto přístupu. Tento přístup je vhodný pro navrhování relativně malých databází. Při zvýšení počtu atributů na několik stovek nebo dokonce tisíců je vhodnější strategií návrhu přístup shora dolů. Tento přístup začíná definicí několika entit na vysoké úrovni a vztahů mezi nimi. Poté jsou tyto objekty podrobně popsány na požadovanou úroveň. Příkladem tohoto přístupu k návrhu je použití modelu vztahu entita. V praxi se tyto přístupy většinou kombinují. V tomto případě můžeme mluvit o smíšeném designovém přístupu.