Pri vývoji databázy je možné rozlíšiť nasledujúce fázy práce.

Etapa I. Formulácia problému.

V tejto fáze sa vytvorí úloha na vytvorenie databázy. Podrobne popisuje zloženie databázy, účel a účel jej vytvorenia a tiež uvádza, aké práce sa majú v tejto databáze vykonávať (výber, doplnenie, zmena údajov, tlač alebo výstup zostavy atď.). ).

Etapa II. Objektová analýza.

V tejto fáze sa zvažuje, z akých objektov môže databáza pozostávať, aké sú vlastnosti týchto objektov. Po rozdelení databázy na samostatné objekty je potrebné zvážiť vlastnosti každého z týchto objektov, alebo inými slovami určiť, aké parametre popisujú každý objekt. Všetky tieto informácie je možné usporiadať vo forme samostatných záznamov a tabuliek. Ďalej musíte zvážiť typ údajov každej jednotlivej jednotky záznamu. Do vytváranej tabuľky by sa mali zadať aj informácie o typoch údajov.

Stupeň III. Syntéza modelu.

V tejto fáze je podľa vyššie uvedenej analýzy potrebné vybrať konkrétny databázový model. Ďalej sa zvažujú výhody a nevýhody každého modelu a porovnávajú sa s požiadavkami a úlohami vytváranej databázy. Po takejto analýze vyberte model, ktorý dokáže maximalizovať realizáciu úlohy. Po výbere modelu musíte nakresliť jeho diagram zobrazujúci vzťahy medzi tabuľkami alebo uzlami.

Štádium IV. Výber spôsobov prezentácie informácií a softvérových nástrojov.

Po vytvorení modelu je potrebné v závislosti od zvoleného softvérového produktu určiť formu prezentácie informácií.

Vo väčšine DBMS môžu byť údaje uložené v dvoch formách:

• používanie formulárov;
• bez použitia formulárov.

Formulár Je používateľom vytvorené grafické rozhranie na zadávanie údajov do databázy.

Etapa V. Syntéza počítačového modelu objektu.

V procese vytvárania počítačového modelu je možné rozlíšiť niektoré fázy, ktoré sú typické pre každý DBMS.

1. fáza Spustenie DBMS, vytvorenie nového databázového súboru alebo otvorenie predtým vytvorenej databázy.

2. fáza Vytvorenie pôvodnej tabuľky alebo tabuliek.

Pri vytváraní pôvodnej tabuľky musíte zadať názov a typ každého poľa. Názvy polí by sa v tej istej tabuľke nemali opakovať. V procese práce s databázou môžete tabuľku doplniť o nové polia. Vytvorenú tabuľku je potrebné uložiť pod názvom, ktorý je jedinečný v rámci vytváranej databázy.

1. Informácie v tabuľke by sa nemali duplikovať. Medzi tabuľkami by sa nemali opakovať. Ak sú určité informácie uložené iba v jednej tabuľke, bude potrebné ich zmeniť iba na jednom mieste. To zefektívňuje prácu a tiež eliminuje možnosť nesúladu informácií v rôznych tabuľkách. Napríklad jedna tabuľka by mala obsahovať adresy a telefónne čísla klientov.

2. Každá tabuľka by mala obsahovať informácie len o jednej téme. Informácie o každej téme sú oveľa jednoduchšie spracovať, ak sú obsiahnuté v tabuľkách, ktoré sú na sebe nezávislé. Napríklad je lepšie ukladať adresy zákazníkov a objednávky v samostatných tabuľkách, aby po odstránení objednávky zostali informácie o zákazníkoch v databáze.

3. Každá tabuľka musí obsahovať povinné polia. Každé pole v tabuľke by malo obsahovať samostatné informácie o téme tabuľky. Napríklad tabuľka s údajmi o zákazníkoch môže obsahovať polia s názvom spoločnosti, adresou, mestom, krajinou a telefónnym číslom. Pri navrhovaní polí pre každú tabuľku nezabudnite, že každé pole musí byť spojené s témou tabuľky. Neodporúča sa zahrnúť do tabuľky údaje, ktoré sú výsledkom výrazu. Tabuľka by mala obsahovať všetky potrebné informácie. Informácie by mali byť rozdelené do najmenších logických jednotiek (napríklad polia Meno a Priezvisko, nie všeobecné pole Meno).

4. Databáza musí mať primárny kľúč. Je to potrebné, aby DBMS mohol prepojiť údaje z rôznych tabuliek, napríklad údaje o zákazníkovi a jeho objednávkach.

3. fáza Vytváranie obrazovkových formulárov.

Najprv musíte zadať tabuľku, na základe ktorej sa vytvorí formulár. Môžete ho vytvoriť pomocou sprievodcu formulárom, ktorý určí, aký druh by mal mať, alebo samostatne. Pri vytváraní formulára môžete zadať nie všetky polia, ktoré tabuľka obsahuje, ale len niektoré z nich. Názov formulára môže byť zhodný s názvom tabuľky, na základe ktorej bol vytvorený. Na základe jednej tabuľky môžete vytvoriť niekoľko formulárov, ktoré sa môžu líšiť typom alebo počtom použitých polí z tejto tabuľky. Po vytvorení formulára je potrebné ho uložiť. Vytvorený formulár je možné upravovať zmenou umiestnenia, veľkosti a formátu polí.

4. fáza Napĺňanie databázy.

Proces vypĺňania databázy môže prebiehať v dvoch formách: vo forme tabuľky a vo forme formulára. Číselné a textové polia je možné vyplniť ako tabuľku, zatiaľ čo polia MEMO a OLE je možné vyplniť ako formulár.

Štádium VI. Práca s vytvorenou databázou.

Práca s databázou zahŕňa nasledujúce kroky:

• vyhľadať potrebné informácie;
• triedenie údajov;
• výber údajov;
• vytlačenie;
• zmena a doplnenie údajov.

Základné úlohy návrhu databázy

Hlavné ciele:

• Poskytnutie uloženia v databáze všetkých potrebných informácií.
• Poskytnutie možnosti získať údaje pre všetky potrebné požiadavky.
• Zníženie redundancie a duplicity údajov.
• Zabezpečenie integrity údajov (správnosti ich obsahu): odstránenie rozporov v obsahu údajov, odstránenie ich straty a pod.

Hlavné fázy návrhu databázy

Koncepčný (infoologický) dizajn- budovanie sémantického modelu domény, teda informačného modelu najvyššej úrovne abstrakcie. Takýto model je vytvorený bez zamerania sa na nejaký konkrétny DBMS a dátový model. Pojmy „sémantický model“, „konceptuálny model“ a „infoologický model“ sú synonymá. Okrem toho sa v tomto kontexte slová „model databázy“ a „model domény“ (napríklad „koncepčný databázový model“ a „koncepčný doménový model“) môžu použiť rovnako, keďže takýto model je obrazom reality aj obrázok projektovaná databáza pre túto realitu.

Konkrétny typ a obsah konceptuálneho modelu databázy je určený formálnym aparátom zvoleným na tento účel. Bežne sa používajú grafické zápisy podobné ER diagramom.

Koncepčný databázový model najčastejšie zahŕňa:

• popis informačných objektov, prípadne pojmov predmetnej oblasti a súvislostí medzi nimi.
• popis integritných obmedzení, t.j. požiadavky na platné hodnoty údajov a vzťahy medzi nimi.

Logický (datalogický) dizajn- vytvorenie databázovej schémy na základe špecifického dátového modelu, napríklad relačného dátového modelu. Pre relačný dátový model je datalogický model súbor schém vzťahov, zvyčajne špecifikujúcich primárne kľúče, ako aj „vzťahy“ medzi vzťahmi, čo sú cudzie kľúče.

Transformácia konceptuálneho modelu na logický model sa zvyčajne uskutočňuje podľa formálnych pravidiel. Táto fáza môže byť do značnej miery automatizovaná.

Vo fáze logického návrhu sa berie do úvahy špecifickosť konkrétneho dátového modelu, ale špecifickosť konkrétneho DBMS sa nemusí brať do úvahy.

Fyzický dizajn

Fyzický dizajn- vytvorenie databázovej schémy pre konkrétny DBMS. Špecifiká konkrétneho DBMS môžu zahŕňať obmedzenia týkajúce sa pomenovania databázových objektov, obmedzenia podporovaných typov údajov atď. Okrem toho medzi špecifiká konkrétneho DBMS vo fyzickom dizajne patrí aj výber riešení súvisiacich s prostredím fyzického úložiska (výber metód správy diskovej pamäte, delenie databázy podľa súborov a zariadení, spôsoby prístupu k údajom), vytváranie indexov atď. .

Normalizácia

Pri návrhu relačných databáz sa zvyčajne robí takzvaná normalizácia.

Modely vzťahov entít

Model vzťahu entita (angl. "Model vzťahu entita" ), alebo ER-model navrhnutý P. Chenom v roku 1976, je najznámejším predstaviteľom triedy sémantických (konceptuálnych, infoologických) modelov domény. ER model je zvyčajne prezentovaný v grafickej podobe, s použitím pôvodného zápisu P. Chena, tzv ER diagram, alebo pomocou iných grafických zápisov ( Vrania noha, Informačné inžinierstvo atď.).

Hlavné výhody modelov ER:

• viditeľnosť;
• modely umožňujú navrhovať databázy s veľkým počtom objektov a atribútov;
• ER-modely sú implementované v mnohých počítačom podporovaných systémoch návrhu databáz (napríklad ERWin).

Hlavné prvky modelov ER:

• objekty (entity);
• atribúty objektu;
• spojenia medzi objektmi.

Entita je objekt domény, ktorý má atribúty.

Vzťah medzi subjektmi je charakterizovaný:

• typ komunikácie (1: 1, 1: N, N: M);
• trieda spolupatričnosti. Trieda môže byť povinná alebo voliteľná. Ak sa každá inštancia entity zúčastňuje vzťahu, potom je trieda členstva povinná, inak je voliteľná.

Sémantické modely

Sémantický model (konceptuálny model, infoologický model) – doménový model určený na reprezentáciu sémantiky domény na najvyššej úrovni abstrakcie. To znamená, že potreba používania „nízkoúrovňových“ konceptov spojených so špecifikami fyzickej prezentácie a uchovávania údajov bola eliminovaná alebo minimalizovaná.

Dátum KJ. Úvod do databázových systémov. - 8. vyd. - M.: "Williams", 2006:

Sémantické modelovanie je predmetom intenzívneho výskumu od konca 70. rokov 20. storočia. Hlavným motívom takýchto štúdií (t. j. problém, ktorý sa výskumníci snažili vyriešiť) bol nasledujúci fakt. Ide o to, že databázové systémy majú zvyčajne veľmi obmedzené znalosti o význame údajov, ktoré ukladajú. Častejšie umožňujú iba manipuláciu s určitými jednoduchými typmi údajov a definujú niektoré z najjednoduchších obmedzení integrity uložených na tieto údaje. Akýkoľvek komplexnejší výklad je ponechaný na používateľa. Bolo by však skvelé, keby systémy mohli byť o niečo informovanejšie a o niečo inteligentnejšie pri odpovedaní na požiadavky používateľov, ako aj podporovať zložitejšie používateľské rozhrania (t. j. vyššej úrovne).
[…]
Nápady sémantického modelovania môžu byť užitočné ako nástroj na návrh databázy, aj keď nie sú priamo podporované DBMS.

Najznámejším predstaviteľom triedy sémantických modelov je entitno-relačný model (ER-model).

Literatúra

• Dátum C.J.Úvod do databázových systémov. - 8. vyd. - M.: "Williams", 2006. - 1328 s. - ISBN 0-321-19784-4
• Kogalovský M.R. Pokročilé technológie informačných systémov. - M .: Tlač DMK; IT Co., 2003 .-- 288 s. - ISBN 5-279-02276-4
• Kogalovský M.R. Encyklopédia databázových technológií. - M .: Financie a štatistika, 2002. - 800 s. - ISBN 5-279-02276-4
• S. D. Kuznecov Základy databázy. - 2. vyd. - M .: Internetová univerzita informačných technológií; BINOMIAL. Vedomostné laboratórium, 2007. - 484 s. - ISBN 978-5-94774-736-2
• Connolly T., Begg K. Databáza. Návrh, realizácia a údržba. Teória a prax = Databázové systémy: Praktický prístup k návrhu, implementácii a manažmentu. - 3. vyd. - M.: "Williams", 2003. - 1436 s. - ISBN 0-201-70857-4
• Garcia-Molina G., Ullman J., Widom J. Databázové systémy. Kompletný kurz. - M.: "Williams", 2003. - 1088 s. - ISBN 5-8459-0384-X

pozri tiež

• Metódy návrhu

Odkazy

• Entity-relationship model – krok k jednotnému pohľadu na dáta – Citforum
• Rozšírenie relačného modelu, aby lepšie odrážal sémantiku - Citforum
• Sprievodca návrhom databázy webových stránok pre začiatočníkov
• Metóda na navrhovanie logickej štruktúry relačnej databázy bez normalizácie tabuliek

Poznámky (upraviť)

Nadácia Wikimedia. 2010.

Pozrite si, čo je „Dizajn databázy“ v iných slovníkoch:

Správca databázy je osoba zodpovedná za vypracovanie požiadaviek na databázu, jej návrh, implementáciu, efektívne používanie a údržbu, vrátane správy používateľských účtov databázy a ochrany pred neoprávneným ... ... Wikipedia

- (anglický databázový refaktoring) je jednoduchá zmena schémy databázy, ktorá prispieva k zlepšeniu jej dizajnu pri zachovaní funkčnej a informačnej sémantiky. Inými slovami, dôsledkom refaktorovania databázy nemôže byť ... ... Wikipedia

DIZAJN- jedna z foriem anticipačnej reflexie skutočnosti, proces vytvárania prototypu (prototypu) údajného predmetu, javu alebo procesu pomocou konkrétnych. metódy. P. je špecifická forma prejavu prognostického. ovládacie funkcie, ... ... Ruská sociologická encyklopédia

Požiadavka "DB" je presmerovaná sem; pozri aj iné významy. Objektívnou formou prezentovaná databáza, súbor nezávislých materiálov (články, výpočty, nariadenia, súdne rozhodnutia a iné podobné materiály), ... ... Wikipedia

Je možné rozlíšiť nasledujúce fázy vývoja databázy:

· Dizajn;

· Implementácia softvéru;

· Plnenie a prevádzka.

Fáza návrhu je teoretická konštrukcia pôvodného informačného modelu databázy. Obsahuje:

· Zber informácií o predmetnej oblasti, jej štruktúre, vstupných a výstupných informačných tokoch dát, štúdium automatizačných úloh, analýza a výber objektov zdrojového systému a určovanie súvislostí medzi nimi;

· Určenie vlastností a charakteristík pre každý objekt v databáze, ku ktorým sa priraďujú polia (atribúty), zostavujú sa počiatočné tabuľky a vzťahy medzi nimi, určujú sa dátové prvky zahrnuté v databáze, obmedzenia hodnôt údajov atď.

· Priradenie primárnych kľúčov (polí) pre každý objekt a normalizácia (rozdelenie) zdrojových tabuliek;

· Kontrola správnosti projektu, ktorý by mal zobraziť všetky vybrané objekty, ich atribúty a popísané procesy na požadovanej úrovni detailu, zobraziť predmetnú oblasť vyžadujúcu riešenie problému;

· Definícia logickej štruktúry databázy;

· Riešenie problémov ochrany a udržiavania integrity databázy. Integritou údajov sa rozumie systém opatrení zameraných na udržanie správnosti údajov v databáze v akomkoľvek danom čase.

Fáza implementácie softvéru je spojená s vývojom aplikácií na počítači, pre ktoré je potrebné vykonať nasledujúce kroky:

· Opíšte tabuľky získané pomocou DBMS a vložte ich do počítača;

· Pre používateľov informačného systému vypracovať rozhrania pre prácu s databázou, to znamená obrazovkové formuláre pre zadávanie a zobrazovanie údajov, zostavy pre tlač súhrnných údajov, požiadavky na príjem údajov;

· Vypracovať postup na udržiavanie a udržiavanie databázy v prevádzkyschopnom stave, prácu koncových používateľov;

· Na otestovanie systému vypracujte pokyny pre prácu s ním a zaškolte personál.

Fáza využívania a plnenia začína naplnením databázy špecifickými údajmi. Zahŕňa priamu údržbu a údržbu databázy.

Pri vývoji databázy pre veľké podniky a korporácie sa analýza a modelovanie vykonáva pomocou špeciálnych softvérových nástrojov, napríklad nástrojov CASE, ktoré vám umožňujú simulovať dátové toky, procesy a funkcie podniku, identifikovať úzke miesta a poskytnúť odporúčania na efektívnu organizáciu štruktúra a obchodné procesy v podniku....

Okrem vytvárania modelov súčasného stavu podniku a analýzy vám softvérové ​​modelovacie nástroje umožňujú vytvárať špecifikácie a zostavovať projekt budúceho systému, navyše je možné získať programový kód pre najbežnejšie DBMS. Fáza modelovania teda môže zachytiť štádium návrhu a časť fázy implementácie informačného systému.

Koncepčný návrh databázy

Prvá fáza procesu návrhu databázy sa nazýva koncepčný návrh databázy. Spočíva vo vytvorení koncepčného dátového modelu pre analyzovanú časť objektov skúmaného systému. Tento dátový model je vytvorený na základe informácií zaznamenaných v špecifikáciách požiadaviek používateľa. Koncepčný návrh databázy je absolútne nezávislý od takých detailov jej implementácie, ako je typ zvoleného DBMS, množina vytvorených aplikačných programov, použité programovacie jazyky, typ zvolenej výpočtovej platformy, ako aj akékoľvek iné zvláštnosti fyzickej realizácie. Vytvorený konceptuálny dátový model je zdrojom informácií pre fázu logického návrhu databázy.

Návrh logickej databázy

Druhá fáza návrhu databázy sa nazýva návrh logickej databázy. Jeho účelom je vytvoriť logický dátový model. Koncepčný dátový model vytvorený v predchádzajúcom kroku sa spresní a prevedie na logický dátový model. Logický dátový model zohľadňuje zvláštnosti zvoleného modelu organizácie dát v DBMS (napríklad relačný alebo sieťový model).

Ak koncepčný dátový model nezávisí od žiadnych fyzických aspektov implementácie, potom sa logický dátový model vytvorí na základe zvoleného modelu organizácie dát v DBMS. Inými slovami, v tejto fáze by už malo byť známe, ktorý DBMS bude použitý – relačný, sieťový, hierarchický alebo objektovo orientovaný. V tejto fáze sa však ignorujú všetky ostatné aspekty vybranej DBMS – napríklad akékoľvek zvláštnosti fyzickej organizácie jej štruktúr na ukladanie údajov a budovanie indexov.

Počas procesu vývoja sa logický dátový model neustále testuje a overuje, aby spĺňal požiadavky používateľov. Na kontrolu správnosti logického dátového modelu sa používa normalizačná metóda. Normalizácia zabezpečuje, že vzťahy odvodené z existujúceho dátového modelu nemajú redundanciu dát, ktorá by mohla spôsobiť anomálie aktualizácie po ich fyzickej implementácii. Logický dátový model musí okrem iného podporovať všetky transakcie, ktoré používatelia potrebujú.

Skonštruovaný logický dátový model je zdrojom informácií pre fázu fyzického návrhu a poskytuje vývojárovi fyzickej databázy prostriedky na nájdenie kompromisov potrebných na dosiahnutie stanovených cieľov, čo je veľmi dôležité pre efektívny návrh. Logický dátový model zohráva dôležitú úlohu aj vo fáze prevádzky a údržby hotového systému. Pri správne organizovanej údržbe vám dátový model udržiavaný v aktuálnom stave umožňuje presne a vizuálne znázorniť akékoľvek zmeny vykonané v databáze a posúdiť ich vplyv na aplikačné programy.

Normalizácia databázy

Pri návrhu databáz je najdôležitejšie definovať štruktúry tabuliek a vzťahy medzi nimi. Chyby v dátovej štruktúre je ťažké, ak nie nemožné, programovo opraviť. Čím lepšia je dátová štruktúra, tým jednoduchšie je programovanie databázy. Teória návrhu databázy obsahuje koncept normálnych foriem navrhnutých na optimalizáciu štruktúry databázy. Normálne formy sú lineárnou postupnosťou pravidiel aplikovaných na databázu a čím vyššie číslo normálnej formy, tým je štruktúra databázy dokonalejšia. Normalizácia je viackrokový proces, v ktorom sú databázové tabuľky organizované, oddelené a dáta sú usporiadané. Úlohou normalizácie je odstrániť niektoré nežiaduce vlastnosti z databázy. Úlohou je najmä eliminovať niektoré typy redundancie údajov a tým sa vyhnúť anomáliám pri zmenách údajov. Anomálie zmeny údajov sú zložitosťou operácií vkladania, zmeny a vymazávania údajov vyplývajúcich zo štruktúry databázy. Hoci existuje veľa úrovní, zvyčajne stačí normalizácia na Tretiu normálnu formu.

Uvažujme o príklade normalizácie databázy riadenia doručenia objednávok. Neusporiadaná databáza „Predaj“ by pozostávala z jednej tabuľky (obr. 7).

Obr. 7. DB "Predaj"

V tabuľke každý záznam obsahuje informácie o niekoľkých objednávkach od toho istého zákazníka. Keďže stĺpec s informáciami o produkte obsahuje priveľa údajov, je ťažké získať z tejto tabuľky informácie o objednaných tovaroch (napr. zostaviť prehľad o celkových nákupoch pre rôzne druhy tovaru).

Prvá normálna forma

Prvá normálna forma predurčuje atomicitu všetkých údajov obsiahnutých v stĺpcoch. Slovo „atóm“ pochádza z latinského „atomis“, čo doslova znamená „neoddeliteľný“. Prvá normálna forma určuje, že na každej pozícii definovanej riadkom a stĺpcom existuje iba jedna hodnota, nie pole alebo zoznam hodnôt. Výhody tejto požiadavky sú zrejmé: ak sú zoznamy hodnôt uložené v jednom stĺpci, potom neexistuje jednoduchý spôsob, ako s týmito hodnotami manipulovať. To samozrejme zvyšuje počet záznamov v tabuľke.

Znormalizujme databázu Predaj do prvej normálnej podoby (obr. 8).

Obr. 8. Prvá normálna forma

3.3.2. Druhá normálna forma

Do druhého normálneho formulára môžete prejsť z tabuľky, ktorá už zodpovedá prvému normálnemu formuláru. Okrem toho musí byť splnená nasledujúca podmienka: každé nekľúčové pole musí úplne závisieť od primárneho kľúča.

Znormalizujme databázu Predaj na druhú normálnu formu. Všetky informácie, ktoré nesúvisia s jednotlivými objednávkami, budú zvýraznené v samostatnej tabuľke. Výsledkom je, že namiesto jednej tabuľky „Predaj“ získame dve – tabuľku „Objednávky“ (obr. 9) a tabuľku „Produkty“ (obr. 10).

Obr. 9. Tabuľka objednávok

Obr. 10. Tabuľka produktov

Typ produktu je teda uložený iba v jednej tabuľke. Upozorňujeme, že počas normalizácie sa nestratia žiadne informácie.

3.3.3. Tretia normálna forma

Tabuľka sa považuje za tretiu normálnu formu, ak je v druhej normálnej forme a všetky nekľúčové stĺpce sú navzájom nezávislé. Stĺpec, ktorého hodnoty sa vypočítavajú z údajov v iných stĺpcoch, je jedným z príkladov závislosti.

Normalizujme databázu predaja na tretiu normálnu formu. Ak to chcete urobiť, odstráňte stĺpec "Celkom" z tabuľky "Objednávky". Hodnoty v tomto stĺpci sú nezávislé od akéhokoľvek kľúča a možno ich vypočítať pomocou vzorca ("Cena") * ("Množstvo"). Takto sme získali databázu „Predaj“ s optimálnou štruktúrou, ktorá pozostáva z dvoch tabuliek (obr. 11).

Ryža. 11. Normalizovaná databáza "Predaj"

3.2 Softvérová implementácia databázy

Softvérová implementácia databázy sa vykonáva vytvorením cieľového DBMS v jazyku definície údajov (DDL). Príkazy DDL sa zostavujú a používajú na generovanie schém a prázdnych databázových súborov. V rovnakej fáze sú definované aj všetky špecifické užívateľské pohľady.

Aplikačné programy sú implementované pomocou jazykov tretej alebo štvrtej generácie. Niektoré prvky týchto aplikácií budú transakcie spracovania databáz napísané v jazyku manipulácie s údajmi (DML) cieľového DBMS a volané z programov v základnom programovacom jazyku - napríklad Visual Basic, C++, Java. Vytvára aj ďalšie súčasti projektu aplikácie — napríklad obrazovky s ponukami, formuláre na zadávanie údajov a zostavy. Treba mať na pamäti, že mnohé existujúce DBMS majú svoje vlastné vývojové nástroje, ktoré vám umožňujú rýchlo vytvárať aplikácie pomocou neprocedurálnych dopytovacích jazykov, rôznych generátorov zostáv, generátorov formulárov, grafických generátorov a generátorov aplikácií.

Táto fáza tiež implementuje nástroje používané aplikáciou na ochranu databázy a udržiavanie jej integrity. Niektoré z nich sú opísané pomocou jazyka DDL, zatiaľ čo iné môže byť potrebné určiť inými prostriedkami - napríklad pomocou dodatočných nástrojov DBMS alebo vytvorením aplikačných programov, ktoré implementujú požadované funkcie.

3.2.1. Vývoj aplikácií

Vývoj aplikácií je návrh používateľského rozhrania a aplikačných programov navrhnutých na prácu s databázou. Vo väčšine prípadov nie je možné dokončiť návrh aplikácie, kým nie je dokončený návrh databázy. Na druhej strane je databáza navrhnutá tak, aby podporovala aplikácie, takže medzi návrhom databázy a návrhom aplikácií pre danú databázu musí prebiehať neustála výmena informácií.

Musíte zabezpečiť, aby všetky funkcie predpokladané v špecifikáciách používateľských požiadaviek poskytovalo používateľské rozhranie príslušných aplikácií. Týka sa to ako návrhu aplikácií pre prístup k informáciám v databáze, tak aj návrhu transakcií, t.j. navrhovanie metód prístupu k databáze.

Okrem navrhovania spôsobov prístupu užívateľa k funkciám, ktoré potrebuje, by ste mali tiež navrhnúť vhodné užívateľské rozhranie pre vaše databázové aplikácie. Toto rozhranie by malo poskytovať informácie, ktoré používateľ potrebuje, tým najpohodlnejším spôsobom.

3.2.2 Testovanie databázy

Testovanie je proces spúšťania aplikačných programov s cieľom nájsť chyby. Pred uvedením nového systému do praxe by mal byť dôkladne otestovaný. Dá sa to dosiahnuť vyvinutím premysleného testovacieho algoritmu s použitím reálnych dát, ktoré musia byť skonštruované tak, aby celý proces testovania prebiehal striktne sekvenčne a metodicky správnym spôsobom. Úlohou testovania nie je proces demonštrovania neprítomnosti chýb, je nepravdepodobné, že by bolo možné preukázať neprítomnosť chýb v softvéri - skôr naopak, môže len ukázať ich prítomnosť. Ak bude testovanie úspešné, určite sa odhalia chyby v aplikačných programoch a databázových štruktúrach. Ako vedľajší produkt môže testovanie iba ukázať, že databáza a aplikácie fungujú podľa ich špecifikácií a zároveň spĺňajú existujúce požiadavky na výkon. Okrem toho zber štatistických údajov v štádiu testovania umožňuje stanoviť ukazovatele spoľahlivosti a kvality vytvoreného softvéru.

Rovnako ako pri návrhu databázy musia byť do procesu testovania zapojení používatelia nového systému. V ideálnom prípade by sa testovanie systému malo vykonávať na samostatnej súprave zariadení, ale často to jednoducho nie je možné. Pri používaní reálnych dát je dôležité najskôr vytvoriť zálohy pre prípad poškodenia v dôsledku chýb. Po ukončení testovania sa proces vytvárania aplikačného systému považuje za ukončený a je možné ho preniesť do priemyselnej prevádzky.

3.3 Prevádzka a údržba databázy

Prevádzka a údržba – udržiava normálne fungovanie databázy.

V predchádzajúcich krokoch bola databázová aplikácia plne implementovaná a otestovaná. Systém teraz vstupuje do poslednej fázy svojho životného cyklu s názvom Prevádzka a údržba. Zahŕňa vykonávanie akcií, ako napríklad:

· Monitorovanie výkonu systému. Ak výkon klesne pod prijateľnú úroveň, môže byť potrebná ďalšia reorganizácia databázy;

· Údržba a modernizácia (v prípade potreby) databázových aplikácií. Nové požiadavky sú do databázovej aplikácie zapracované pri opakovaní predchádzajúcich fáz životného cyklu.

Keď je databáza v prevádzke, mali by ste neustále monitorovať proces jej prevádzky, aby ste sa uistili, že výkon a ďalšie ukazovatele spĺňajú požiadavky. Typický DBMS zvyčajne poskytuje rôzne nástroje na správu databáz, vrátane nástrojov na načítanie údajov a monitorovanie výkonu systému. Tieto pomocné programy môžu monitorovať výkon systému a poskytovať informácie o rôznych metrikách, ako je využitie databázy, výkon uzamykacieho systému (vrátane informácií o počte uviaznutia, ku ktorému došlo) a voliteľné stratégie vykonávania dotazov. Správca databázy môže tieto informácie použiť na vyladenie systému na zlepšenie výkonu (napríklad vytvorením ďalších indexov), zrýchlenie dopytov, zmenu štruktúry úložiska, spájanie alebo rozdeľovanie jednotlivých tabuliek.

Proces monitorovania sa musí udržiavať počas celého procesu aplikácie, aby bolo možné kedykoľvek vykonať efektívnu reorganizáciu databázy, aby sa splnili meniace sa požiadavky. Zmeny ako tieto poskytujú informácie o najpravdepodobnejších vylepšeniach databázy a zdrojoch, ktoré môžu byť potrebné v budúcnosti. Ak použitý DBMS nemá niektoré potrebné nástroje, bude ich musieť správca vyvinúť samostatne alebo zakúpiť potrebné dodatočné nástroje od vývojárov tretích strán.

4. DBMS Microsoft Access

4.1 Účel a všeobecné informácie o Microsoft Access DBMS

Systém Microsoft Access je systém správy databáz, ktorý využíva relačný dátový model a je súčasťou balíka aplikácií Microsoft Office. Je určený na ukladanie, zadávanie, vyhľadávanie a úpravu údajov, ako aj na ich vydávanie v pohodlnej forme.

Aplikácie pre Microsoft Access zahŕňajú nasledovné:

· V malom podnikaní (účtovníctvo, zadávanie objednávok, udržiavanie informácií o zákazníkoch, udržiavanie informácií o obchodných kontaktoch);

· Vo veľkých korporáciách (aplikácie pre pracovné skupiny, systémy spracovania informácií);

· Ako osobný DBMS (adresár adries, vedenie investičného portfólia, kuchárska kniha, katalógy kníh, záznamy, videá atď.).

Access je jedným z najvýkonnejších, užívateľsky prívetivých a najjednoduchších systémov správy databáz. Keďže Access je súčasťou balíka Microsoft Office, má mnoho charakteristík aplikácií balíka Office a dokáže s nimi komunikovať. Napríklad pri práci v Accesse môžete otvárať a upravovať súbory a môžete použiť schránku na kopírovanie údajov z iných aplikácií.

Nástroje na navrhovanie objektov v Accesse sú „wizards“ a „designers“. Ide o špeciálne programy, ktoré slúžia na vytváranie a úpravu tabuliek, dotazov, rôznych typov formulárov a zostáv. Zvyčajne sa „sprievodca“ používa na vytváranie a „dizajnér“ na úpravu objektov. Proces úprav zahŕňa zmenu vzhľadu nejakého objektu s cieľom vylepšiť ho. Pri úprave formulára môžete zmeniť názvy a poradie polí, zväčšiť alebo zmenšiť veľkosť oblasti zadávania údajov atď. Na vytváranie formulárov môžete použiť aj "konštruktor", ale je to veľmi časovo náročná práca. Access obsahuje softvérové ​​nástroje, ktoré vám pomôžu analyzovať štruktúru údajov, importovať tabuľky a textové údaje, zlepšiť výkon aplikácií a vytvárať a prispôsobovať aplikácie pomocou vstavaných šablón. Ak chcete plne automatizovať svoje aplikácie, môžete použiť makrá na naviazanie údajov na formuláre a zostavy.

Access implementuje správu relačných databáz. Systém podporuje primárne a cudzie kľúče. Udržuje integritu údajov na úrovni jadra, čo zabraňuje nekompatibilným operáciám aktualizácie alebo vymazania. Tabuľky v Accesse sú vybavené nástrojmi na overenie údajov; neplatný vstup nie je povolený. Každé pole v tabuľke má svoj vlastný formát a štandardné popisy na uľahčenie zadávania údajov. Access podporuje nasledujúce typy polí vrátane: Tab, Text, Numeric, Counter, Mena, Date/Time, MEMO, Boolean, Hyperlink, OLE Object Fields, Attachment a Calculated. Ak polia neobsahujú žiadne hodnoty, systém poskytuje plnú podporu pre hodnoty null.

V Accesse môžete použiť grafiku, rovnako ako v Microsoft Word, Excel, PowerPoint a ďalších aplikáciách, na vytváranie rôznych druhov grafov a tabuliek. Môžete vytvárať pruhové, 2D a 3D grafy. Do formulárov a zostáv Accessu môžete pridať najrôznejšie objekty: obrázky, grafy, zvukové klipy a videoklipy. Prepojením týchto objektov s navrhnutou databázou môžete vytvárať dynamické formuláre a zostavy. Na automatizáciu niektorých úloh môžete v Accesse použiť aj makrá. Umožňujú vám otvárať a zatvárať formuláre a zostavy, vytvárať ponuky a dialógové okná s cieľom automatizovať vytváranie rôznych úloh aplikácie.

Access poskytuje kontextovú pomoc kliknutím a na obrazovke sa zobrazia informácie na pozadí problému, ktorý používateľa momentálne zaujíma. V tomto prípade môžete jednoducho prejsť na obsah systému pomoci, konkrétne informácie, históriu predchádzajúcich hovorov a záložky. Databázové informácie sú uložené v súbore s príponou .accdb.

4.2. Objekty Microsoft Access

Po spustení Access DBMS sa zobrazí okno na vytvorenie novej databázy alebo na prácu s predtým vytvorenými databázami, prípadne už existujúcimi šablónami (obr. 12).

Ryža. 12. Spustenie programu Access

Šablóny sú prázdne databázové štruktúry, v ktorých sa definujú typy polí, vytvárajú sa hlavné objekty, vykonáva sa vzťah medzi tabuľkami atď.

Keď vytvoríte novú databázu, Access otvorí prázdnu tabuľku obsahujúcu jeden riadok a dva stĺpce (obrázok 13).

Obr. 13. Nové okno databázy

V ľavej časti okna (navigačná oblasť) sú zobrazené všetky vytvorené databázové objekty, pričom vidíme len prázdnu tabuľku, keďže vytvorené objekty v novej databáze už neexistujú (obr. 13). Hlavné objekty Access DBMS sú nasledujúce.

Tabuľky... Tabuľky sú hlavným objektom databáz, pretože uchovávajú všetky údaje a definujú štruktúru databázy. Databáza môže obsahovať tisíce tabuliek, ktorých veľkosť je obmedzená len dostupným miestom na pevnom disku vášho počítača. Počet záznamov v tabuľkách je určený veľkosťou pevného disku a počet polí nie je väčší ako 255.

Tabuľky v Accesse možno vytvárať takto:

· V režime "konštruktor";

· V režime zadávania údajov do tabuľky.

Tabuľku môžete vytvoriť importovaním alebo prepojením údajov uložených inde. Dá sa to urobiť napríklad s údajmi uloženými v súbore Excel, v zozname služieb Windows SharePoint Services, súbore XML, inej databáze MS ACCESS. Zoznam SharePoint vám umožňuje poskytnúť prístup k údajom používateľom, ktorí nemajú nainštalovaný MS ACCESS. Importovaním údajov sa vytvorí ich kópia v novej tabuľke v aktuálnej databáze. Následné zmeny pôvodných údajov neovplyvnia importované údaje a naopak. Keď vytvoríte väzbu na údaje, v aktuálnej databáze sa vytvorí prepojená tabuľka, ktorá sa dynamicky pripojí k údajom uloženým inde. Zmeny údajov v prepojenej tabuľke sa prejavia v zdroji a zmeny v zdroji sa prejavia v prepojenej tabuľke.

Zobrazenie tabuľky zobrazuje údaje uložené v tabuľke a zobrazenie návrhu zobrazuje štruktúru tabuľky.

Ak tabuľky zdieľajú polia, môžete použiť podriadenú tabuľku na vloženie záznamov z inej tabuľky do jednej tabuľky. Tento prístup vám umožňuje zobraziť údaje z viacerých tabuliek súčasne.

Dopyty... Dotazy sú špeciálne nástroje určené na vyhľadávanie a analýzu informácií v databázových tabuľkách, ktoré spĺňajú určité kritériá. Nájdené záznamy, nazývané výsledky dotazov, je možné prezerať, upravovať a analyzovať rôznymi spôsobmi. Okrem toho môžu byť výsledky dotazu použité ako základ pre vytváranie ďalších objektov Accessu. Existujú rôzne typy dotazov, z ktorých najbežnejšie sú výberové dotazy, parametrické a krížové dotazy, dotazy na mazanie záznamov, modifikačné dotazy a iné. Menej často používané sú akčné dotazy a dotazy SQL (Structured Query Language). Ak požadovaná požiadavka nie je k dispozícii, je možné ju vytvoriť dodatočne.

Dotazy sa tvoria rôznymi spôsobmi, napríklad pomocou „sprievodcu“, dotaz môžete vytvoriť aj ručne v režime „návrh“. Najjednoduchším a najčastejšie používaným typom dotazu je výberový dotaz. Tieto dotazy vyberú údaje z jednej alebo viacerých tabuliek a vytvoria z nich novú tabuľku, v ktorej je možné meniť záznamy. Výberové dotazy sa používajú na výpočet súčtov, priemerov a iných súčtov. Dotazy teda využívajú údaje z podkladových tabuliek a vytvárajú dočasné tabuľky.

Formuláre... Formuláre slúžia na zadávanie a úpravu záznamov v databázových tabuľkách. Formuláre je možné zobraziť v troch režimoch: v režime určenom na zadávanie údajov, v režime tabuľky, kde sú údaje prezentované v tabuľkovom formáte a v režimoch „rozloženie“ a „návrh“, ktoré umožňujú vykonávať zmeny a doplnky. do formulárov.

Hlavnými prvkami formulára sú štítky, ktoré označujú text, ktorý je priamo zobrazený vo formulári, a polia obsahujúce hodnoty polí v tabuľke. Zatiaľ čo režim návrhu umožňuje vytvoriť formulár od začiatku, zvyčajne sa používa na spresnenie a zlepšenie formulárov vytvorených pomocou sprievodcu. Okrem vyššie uvedených nástrojov možno formuláre vytvárať aj pomocou nasledujúcich nástrojov:

· "formulár";

· "Rozdelená forma";

· "Niekoľko prvkov";

· "Prázdny formulár".

Najúčinnejšie je použiť formuláre na zadávanie údajov vo forme špeciálnych formulárov, keďže formulár môže mať formu formulára. Používanie formulárov umožňuje zadávať údaje v užívateľsky príjemnej forme známych dokumentov. I/O formuláre vám umožňujú zadávať údaje do databázy, prezerať si ju, meniť hodnoty polí, pridávať a mazať záznamy. Formulár môže obsahovať tlačidlo používané na tlač zostavy, otváranie iných objektov alebo automatické vykonávanie iných úloh.

Správy... Zostavy slúžia na zobrazenie informácií v tabuľkách vo formátovanej forme, ktorá je prehľadne prezentovaná na obrazovke monitora aj na papieri. Správa je efektívnym nástrojom na tlač údajov z databázy v užívateľsky požadovanej forme (vo forme referencií, skúšobných hárkov, tabuliek a pod.). Okrem údajov získaných z viacerých tabuliek a dotazov môžu zostavy obsahovať prvky dizajnu, ktoré je možné vytlačiť, ako sú nadpisy, hlavičky a päty.

Zostavu je možné zobraziť v štyroch režimoch: v režime „návrh“, ktorý umožňuje meniť vzhľad zostavy, v režime ukážkového zobrazenia, v ktorom je možné zobraziť všetky prvky hotovej zostavy, avšak v skrátenom formulár, v režime "rozloženie", ktorý umožňuje prehľadnejšie zobraziť (v porovnaní s návrhovým režimom) a formátovať zostavu a v režime náhľadu, kde sa zostava zobrazí tak, ako bude vytlačená.

Tabuľky, dotazy, formuláre a zostavy sú najčastejšie používané objekty v návrhu databázy Accessu.

Možnosti databázy je však možné výrazne rozšíriť použitím prístupových stránok, makier a modulov.

Stránky. Ak chcete používateľom internetu poskytnúť prístup k informáciám, môžete v databáze vytvoriť špeciálne stránky pre prístup k údajom. Stránky prístupu k údajom vám umožňujú prezerať, pridávať, upravovať a manipulovať s údajmi uloženými v databáze. Stránky prístupu k údajom môžu obsahovať aj údaje z iných zdrojov, ako je napríklad Excel. Na publikovanie informácií z databázy do Web Access je zahrnutý "sprievodca", ktorý vytvorí prístupovú stránku.

Makrá. Makrá sú malé programy jedného alebo viacerých makier, ktoré vykonávajú špecifické operácie, napríklad otvorenie formulára, tlač zostáv, kliknutie na tlačidlo atď. Toto je obzvlášť užitočné, ak máte v úmysle preniesť databázu nekvalifikovaným používateľom. Môžete napríklad písať makrá, ktoré obsahujú postupnosť príkazov, ktoré vykonávajú rutinné úlohy, alebo priraďovať akcie, ako je otvorenie formulára alebo tlač zostavy, s tlačidlami na formulári s tlačidlami.

Moduly. Modul je databázový objekt, ktorý vám umožňuje vytvárať knižnice rutín a funkcií používaných v celej aplikácii. Pomocou kódov modulov môžete riešiť úlohy, ako je spracovanie vstupných chýb, deklarovanie a aplikácia premenných, organizovanie slučiek atď.

Základné koncepty databázy

Vývoj výpočtovej techniky prebiehal v dvoch hlavných smeroch:

používanie výpočtovej techniky na vykonávanie numerických výpočtov;

využitie výpočtovej techniky v informačných systémoch.

Informačný systém je súbor softvérových a hardvérových nástrojov, metód a ľudí, ktorí zhromažďujú, uchovávajú, spracúvajú a vydávajú informácie na riešenie zadaných úloh. V počiatočných štádiách používania informačných systémov sa používal model spracovania založený na súboroch. Neskôr sa v informačných systémoch začali využívať databázy. Databázy sú modernou formou organizácie, uchovávania a prístupu k informáciám. Príkladom veľkých informačných systémov sú bankové systémy, systémy objednávania lístkov na vlaky atď.

Databáza je integrovaná zbierka štruktúrovaných a vzájomne prepojených údajov, organizovaných podľa určitých pravidiel, ktoré poskytujú všeobecné zásady pre popis, ukladanie a spracovanie údajov. Databáza sa zvyčajne vytvára pre predmetnú oblasť.

Oblasť je časť reálneho sveta, ktorú je potrebné preštudovať, aby sa vytvorila databáza na automatizáciu procesu riadenia.

Súbory princípov, ktoré definujú organizáciu logickej štruktúry na ukladanie údajov do databázy, sa nazývajú dátové modely.

Existujú 4 hlavné dátové modely – zoznamy (ploché tabuľky), relačné databázy, hierarchické a sieťové štruktúry.

Dlhé roky sa prevažne používali ploché tabuľky (jednoduché databázy), ako napríklad zoznamy v Exceli. V súčasnosti sa pri vývoji databáz najviac využívajú relačné dátové modely. Relačný dátový model je súbor najjednoduchších dvojrozmerných tabuliek – relácií, t.j. Najjednoduchšia dvojrozmerná tabuľka je definovaná ako relácia (množina záznamov rovnakého typu spojených jednou témou).

Od pojmu relácia (relácia) pochádza názov relačného dátového modelu. Relačné databázy využívajú niekoľko dvojrozmerných tabuliek, v ktorých sa riadky nazývajú záznamy a stĺpce sú polia, medzi záznamami ktorých sú vytvorené prepojenia. Tento spôsob organizácie údajov umožňuje spájať údaje (záznamy) v jednej tabuľke s údajmi (záznammi) v iných tabuľkách prostredníctvom jedinečných identifikátorov (kľúčov) alebo polí kľúčov.

Základné pojmy relačných databáz: normalizácia, vzťahy a kľúče

1. Princípy normalizácie:

Každá tabuľka databázy by nemala mať duplicitné polia;

Každá tabuľka musí mať jedinečný identifikátor (primárny kľúč);

Každá hodnota primárneho kľúča musí mať dostatočné informácie o type entity alebo objekte tabuľky (napríklad informácie o akademickom výkone, skupine alebo študentoch);

Zmeny hodnôt v poliach tabuľky by nemali ovplyvniť informácie v iných poliach (okrem zmien v kľúčových poliach).

2. Typy logického spojenia.

Vzťah je vytvorený medzi dvoma spoločnými poľami (stĺpcami) dvoch tabuliek. Existujú vzťahy so vzťahmi jeden k jednému, jeden k mnohým a mnoho k mnohým.

Vzťahy, ktoré môžu existovať medzi záznamami dvoch tabuliek:

one - to - one, každý záznam z jednej tabuľky zodpovedá jednému záznamu v inej tabuľke;

jeden - až - veľa, každý záznam z jednej tabuľky zodpovedá niekoľkým záznamom inej tabuľky;

veľa - to - jeden, veľa záznamov z jednej tabuľky zodpovedá jednému záznamu v inej tabuľke;

veľa - až - veľa, viacero záznamov z jednej tabuľky zodpovedá niekoľkým záznamom v inej tabuľke.

Typ vzťahu vo vzťahu, ktorý vytvoríte, závisí od toho, ako definujete súvisiace polia:

Vzťah typu one-to-many sa vytvorí, keď iba jedno z polí je primárnym kľúčom alebo jedinečným indexovým poľom.

Vzťah jeden k jednému sa vytvorí, keď obe polia, ktoré sa majú prepojiť, sú kľúčové polia alebo majú jedinečné indexy.

Vzťah many-to-many sú vlastne dva vzťahy one-to-many s treťou tabuľkou, ktorej primárny kľúč pozostáva z polí cudzieho kľúča ostatných dvoch tabuliek.

3. Klávesy. Kľúč je stĺpec (môže byť viacero stĺpcov), ktorý sa pridáva do tabuľky a umožňuje vám prepojiť záznamy v inej tabuľke. Existujú dva typy kľúčov: primárny a sekundárny alebo cudzí.

Primárny kľúč je jedno alebo viac polí (stĺpcov), ktorých kombinácia hodnôt jedinečne identifikuje každý záznam v tabuľke. Primárny kľúč neumožňuje hodnoty Null a musí mať vždy jedinečný index. Primárny kľúč sa používa na prepojenie tabuľky s cudzími kľúčmi v iných tabuľkách.

Cudzí (sekundárny) kľúč je jedno alebo viacero polí (stĺpcov) v tabuľke, ktoré obsahujú odkaz na pole primárneho kľúča alebo polia v inej tabuľke. Cudzí kľúč určuje, ako sa tabuľky spájajú.

Z dvoch logicky súvisiacich tabuliek sa jedna nazýva tabuľka primárnych kľúčov alebo hlavná tabuľka a druhá sa nazýva sekundárna (cudzia) tabuľka kľúčov alebo podriadená tabuľka. DBMS vám umožňujú porovnávať súvisiace záznamy z oboch tabuliek a zobrazovať ich spolu vo formulári, zostave alebo dotaze.

Existujú tri typy primárnych kľúčov: polia kľúča počítadla (počítadlo), jednoduchý kľúč a zložený kľúč.

Pole Počítadlo (Typ údajov "Počítadlo"). Typ údajov pre pole v databáze, ktorý automaticky vyplní pole jedinečnou číselnou hodnotou pre každý záznam, ktorý sa pridá do tabuľky.

Jednoduchý kľúč. Ak pole obsahuje jedinečné hodnoty, ako sú kódy alebo inventárne čísla, potom toto pole možno definovať ako primárny kľúč. Akékoľvek pole, ktoré obsahuje údaje, možno zadať ako kľúč, pokiaľ pole neobsahuje duplicitné hodnoty alebo hodnoty Null.

Kompozitný kľúč. V prípadoch, keď nie je možné zaručiť jedinečnosť hodnôt každého poľa, je možné vytvoriť kľúč pozostávajúci z niekoľkých polí. Táto situácia je najbežnejšia pre tabuľku, ktorá sa používa na prepojenie dvoch tabuliek typu many-to-many.

Opäť je potrebné poznamenať, že pole primárneho kľúča by malo obsahovať iba jedinečné hodnoty v každom riadku tabuľky, t.j. nie je povolená žiadna zhoda, ale v poli sekundárneho alebo cudzieho kľúča je zhoda hodnôt v riadkoch tabuľky povolená.

Ak máte problémy s výberom vhodného typu primárneho kľúča, potom je vhodné zvoliť ako kľúč pole počítadla.

Programy, ktoré sú určené na štruktúrovanie informácií, ich umiestňovanie do tabuliek a manipuláciu s údajmi, sa nazývajú systémy správy databáz (DBMS). Inými slovami, DBMS sú určené na vytváranie a udržiavanie databázy, ako aj na prístup k údajom. V súčasnosti existuje viac ako 50 typov DBMS pre osobné počítače. Najbežnejšie typy DBMS sú: MS SQL Server, Oracle, Informix, Sybase, DB2, MS Access atď.

Vytvorenie databázy. Etapy návrhu

Tvorba databázy začína návrhom.

Etapy návrhu databázy:

Prieskum domén;

Analýza údajov (subjekty a ich atribúty);

Definovanie vzťahov medzi entitami a definovanie primárneho a sekundárneho (cudzieho) kľúča.

V procese návrhu sa určuje štruktúra relačnej databázy (zloženie tabuliek, ich štruktúra a logické súvislosti). Štruktúra tabuľky je určená zložením stĺpcov, dátovým typom a veľkosťou stĺpcov, kľúčmi tabuľky.

Medzi základné pojmy databázového modelu „entita – vzťah“ patria: entity, vzťahy medzi nimi a ich atribúty (vlastnosti).

Entita - akýkoľvek konkrétny alebo abstraktný objekt v uvažovanej predmetnej oblasti. Entity sú základné typy informácií, ktoré sú uložené v databáze (ku každej entite v relačnej databáze je priradená tabuľka). Medzi entity môžu patriť: študenti, klienti, oddelenia atď. Inštancia entity a typ entity sú rôzne pojmy. Typ entity označuje súbor homogénnych osôb, predmetov alebo udalostí, ktoré pôsobia ako celok (napríklad študent, klient atď.). Inštancia entity odkazuje napríklad na konkrétnu osobu v množine. Typ entity môže byť študent a inštancia môže byť Petrov, Sidorov atď.

Atribút je vlastnosť entity v doméne. Jeho názov musí byť jedinečný pre konkrétny typ entity. Pre entitu študent možno použiť napríklad tieto atribúty: priezvisko, meno, priezvisko, dátum a miesto narodenia, údaje z pasu atď. V relačnej databáze sú atribúty uložené v poliach tabuľky.

Vzťah – vzťah medzi entitami v doméne. Vzťahy sú spojenia medzi časťami databázy (v relačnej databáze ide o spojenie medzi záznamami tabuľky).

Entity sú údaje, ktoré sú klasifikované podľa typu a vzťahy ukazujú, ako tieto typy údajov navzájom súvisia. Ak opíšeme určitú predmetnú oblasť z hľadiska entity – vzťahu, tak dostaneme entitu – model vzťahu pre túto databázu.

Zvážte tematickú oblasť: Dekanát (výkon študentov)

V DB „Dekanát“ by sa mali uchovávať údaje o študentoch, skupinách študentov, o známkach študentov v rôznych odboroch, o učiteľoch, o štipendiách a pod. Obmedzíme sa na údaje o študentoch, skupinách študentov a známkach študentov v rôznych odboroch. Definujeme entity, atribúty entít a základné požiadavky na databázové funkcie s obmedzenými údajmi.

Hlavnými vecne významnými subjektmi DB „Dekanát“ sú: Študenti, Skupiny študentov, Disciplíny, Progres.

Základné doménovo významné atribúty entít:

Študenti - priezvisko, meno, priezvisko, pohlavie, dátum a miesto narodenia, skupina študentov;

Skupiny študentov – názov, kurz, semester;

Disciplíny - názov, počet hodín

Progres - hodnotenie, typ kontroly.

Základné požiadavky na funkcie databázy:

Vyberte si postup študenta podľa disciplíny s uvedením celkového počtu hodín a typu kontroly;

Vyberte si výkon študentov podľa skupín a disciplín;

Vybrať odbory, ktoré študuje skupina študentov v konkrétnom kurze resp

určitý semester.

Z rozboru údajov predmetnej oblasti vyplýva, že každej entite musí byť priradená najjednoduchšia dvojrozmerná tabuľka (relácie). Ďalej musíte vytvoriť logické prepojenia medzi tabuľkami. Medzi tabuľkami Študenti a Progres je potrebné stanoviť taký vzťah, aby každý záznam z tabuľky Študenti zodpovedal niekoľkým záznamom v tabuľke Progres, t.j. jeden až veľa, pretože každý študent môže mať viacero známok.

Logický vzťah medzi entitami Skupiny – Študenti sú definované ako jeden k mnohým na základe skutočnosti, že v skupine je veľa študentov a každý študent je súčasťou jednej skupiny. Logická súvislosť medzi entitami disciplíny – študijný prospech je definovaná ako jedna k mnohým, pretože za každú disciplínu môžu mať rôzni študenti viacero známok.

Na základe vyššie uvedeného zostavujeme entitno-vzťahový model pre databázu „Dekanát“ – šípka je symbolom vzťahu: jeden – k – mnohým.

Na vytvorenie databázy musíte použiť jeden zo známych DBMS, napríklad Access DBMS.

Etapy návrhu databázy

Bez jej podrobného popisu nie je možné vytvoriť databázu, rovnako ako bez výkresu a podrobného popisu výrobných technológií nie je možné vyrobiť žiadny zložitý výrobok. Inými slovami, potrebujete projekt. Projekt považuje sa za náčrt nejakého zariadenia, ktoré sa neskôr prenesie do reality.

Proces navrhovania databázy je proces prechodov od neformálneho verbálneho popisu informačnej štruktúry predmetnej oblasti k formalizovanému popisu objektov v predmetnej oblasti v zmysle určitého modelu. Konečným cieľom návrhu je vybudovať špecifickú databázu. Je zrejmé, že proces navrhovania je zložitý a preto má zmysel rozdeliť ho na logicky ucelené časti – etapy.

Existuje päť hlavných fáz návrhu databázy:

1. Zber informácií a systémová analýza predmetnej oblasti.

2. Infologický dizajn.

3. Výber DBMS.

4. Datalogický dizajn.

5. Fyzický dizajn.

Zber informácií a systémová analýza predmetnej oblasti- toto je prvá a najdôležitejšia fáza pri návrhu databázy. Je potrebné vykonať podrobný slovný popis predmetov predmetnej oblasti a skutočných spojení, ktoré existujú medzi skutočnými predmetmi. Je žiaduce, aby opis definoval vzťah medzi objektmi predmetnej oblasti.

Vo všeobecnosti existujú dva prístupy k výberu zloženia a štruktúry predmetu:

· Funkčný prístup- používa sa vtedy, keď sú vopred známe funkcie určitej skupiny osôb a komplexy úloh, na údržbu ktorých je táto databáza vytvorená, t.j. minimálna požadovaná množina objektov predmetnej oblasti pre popis je jasne zvýraznená.

· Predmetový prístup- keď informačné potreby zákazníkov databázy nie sú jasne zaznamenané a môžu byť viacrozmerné a dynamické. V tomto prípade je ťažké vybrať minimálnu množinu objektov v predmetnej oblasti. Opis predmetnej oblasti zahŕňa také predmety a vzťahy, ktoré sú pre ňu najcharakteristickejšie a najpodstatnejšie. V tomto prípade sa databáza stáva predmetom a je vhodná na riešenie rôznych úloh (čo sa zdá byť najlákavejšie). Náročnosť univerzálneho pokrytia predmetnej oblasti a nemožnosť špecifikovať potreby používateľov však vedie k príliš zložitej databázovej schéme, ktorá bude pre niektoré úlohy neúčinná.

Systémová analýza by mala byť ukončená podrobným popisom informácií o objektoch predmetnej oblasti, ktoré by mali byť uložené v databáze, formuláciou konkrétnych úloh, ktoré sa budú pomocou tejto databázy riešiť so stručným popisom algoritmov na ich riešenie, a popis výstupných a vstupných dokumentov pri práci s databázou.

Infologický dizajn- čiastočne formalizovaný opis predmetov predmetnej oblasti v zmysle určitého sémantického modelu.

Prečo potrebujeme infoologický model a aký je prínos pre dizajnérov? Faktom je, že proces navrhovania je zdĺhavý a vyžaduje diskusiu so zákazníkom a odborníkmi na danú problematiku. Navyše pri vývoji serióznych podnikových informačných systémov je databázový projekt základom, na ktorom je vybudovaný celý systém ako celok, a o otázke možnosti úverovania často rozhodujú bankoví experti na základe dobre vypracovaného infologického databázový projekt. Informologický model by preto mal obsahovať taký formalizovaný popis predmetnej oblasti, ktorý bude ľahko vnímateľný nielen odborníkmi v oblasti databáz. Popis by mal byť natoľko rozsiahly, aby bolo možné posúdiť hĺbku a správnosť vypracovania návrhu databázy.

Doteraz najpoužívanejší model Chenovho „vzťahu entít“ (Entity Relationship), sa stal de facto štandardom v infologickom modelovaní a dostal názov ER – model.

Výber DBMS sa vykonáva na základe rôznych požiadaviek na databázu a podľa toho aj schopností DBMS, ako aj v závislosti od existujúcich skúseností vývojárov.

Datalogický dizajn je tam popis databázy z hľadiska akceptovaného datalogického dátového modelu. V relačných databázach vedie k návrhu databázovej schémy datalogický alebo logický návrh, t.j. súbor vzťahových schém, ktoré adekvátne modelujú objekty predmetnej oblasti a sémantické spojenia medzi objektmi. Základom pre analýzu správnosti schémy sú funkčné závislosti medzi atribútmi databázy. V niektorých prípadoch sa medzi atribútmi vzťahov môžu objaviť nežiaduce závislosti, ktoré spôsobujú vedľajšie efekty a anomálie pri úprave databázy. Pod modifikácia rozumieť zadávaniu nových údajov do databázy, vymazávaniu údajov z databázy, ako aj aktualizácii hodnôt niektorých atribútov. Na odstránenie možných anomálií sa navrhuje normalizovať databázové vzťahy.

Fáza logického návrhu nie je len o návrhu schémy vzťahov. V dôsledku tejto fázy by sa spravidla mali získať tieto výsledné dokumenty:

· Popis koncepčnej schémy DB z hľadiska zvoleného DBMS.

· Popis externých modelov z hľadiska zvoleného DBMS.

· Popis deklaratívnych pravidiel pre zachovanie integrity databázy.

· Vývoj postupov na zachovanie sémantickej integrity databázy.

Fyzický dizajn je prepojenie logickej štruktúry databázy a prostredia fyzického úložiska s cieľom umiestniť dáta čo najefektívnejším spôsobom, t.j. mapovanie logickej štruktúry databázy na štruktúru úložiska. Rieši sa otázka umiestňovania uložených údajov do pamäťového priestoru, výber efektívnych metód prístupu k rôznym komponentom „fyzickej“ databázy, riešia sa otázky zabezpečenia bezpečnosti a ochrany údajov. Obmedzenia v logickom dátovom modeli sú implementované rôznymi nástrojmi DBMS, napríklad pomocou indexov, deklaratívnych obmedzení integrity, spúšťačov, uložených procedúr. V tomto prípade opäť rozhodnutia na úrovni logického modelovania definujú určité hranice, v rámci ktorých je možné vyvinúť fyzický dátový model. Rovnako v rámci týchto hraníc možno robiť rôzne rozhodnutia. Napríklad vzťahy obsiahnuté v logickom údajovom modeli sa musia skonvertovať na tabuľky, ale pre každú tabuľku môžete dodatočne deklarovať rôzne indexy, aby ste zvýšili rýchlosť prístupu k údajom.

Okrem toho možno na zlepšenie výkonu použiť možnosti paralelného spracovania. Výsledkom je, že databáza môže byť umiestnená na niekoľkých počítačoch v sieti. Na druhej strane možno využiť výhody viacprocesorových systémov.

Pre zaistenie bezpečnosti a ochrany údajov sa riešia otázky, ako sa zotaviť po zlyhaniach, zálohovať informácie, nakonfigurovať ochranné systémy pre zvolenú bezpečnostnú politiku atď.

Je potrebné poznamenať, že niektoré moderné relačné DBMS používajú najmä fyzické štruktúry a prístupové metódy založené na technológii návrhu súborov, čo v podstate odstraňuje problém fyzického dizajnu.

Je teda jasné, že rozhodnutia prijaté v každej fáze modelovania a vývoja databázy ovplyvnia nasledujúce fázy. Preto robenie správnych rozhodnutí v počiatočných fázach modelovania zohráva osobitnú úlohu.