Obr. 3.5.

Vo fáze formulácie a analýza požiadaviek Ciele organizácie sa stanovia, požiadavky na databázu sa určujú. Pozostávajú z všeobecných požiadaviek definovaných vyššie a špecifické požiadavky. Na vytvorenie osobitných požiadaviek sa zvyčajne používa metóda rozhovoru zamestnancov rôznych úrovní kontroly. Všetky požiadavky sú zdokumentované vo formulári, cenovo dostupný koncový užívateľ a databázový dizajnér.

Koncepcia koncepčného dizajnu je opísať a syntetizovať informácie o informáciách používateľov do pôvodného projektu DB. Zdrojové údaje môžu byť sada užívateľských dokumentov (obr. 3.3) s klasickým prístupom alebo algoritmmi aplikácií (obchodné algoritmy) s moderným prístupom. Výsledkom tejto fázy je zastúpenie na vysokej úrovni (vo forme systému databázových tabuliek) požiadaviek na používateľské informácie na základe rôznych prístupov.

Po prvé, vyberie sa model databázy. Potom, použitím štruktúry BD, je vytvorená štruktúra databázy, ktorá je naplnená dátami pomocou príkazov NMID, menu systémov, formulárov obrazovky alebo v zobrazení tabuľky databázy. Poskytuje tiež ochranu a integritu (vrátane referenčných) údajov pomocou DBMS alebo budovaním spúšťačov.

V procese logický dizajn Prezentácia údajov na vysokej úrovni sa konvertuje na štruktúru použitého DBMS. Hlavným cieľom javiska je odstrániť redundanciu údajov pomocou špeciálnych normalizačných pravidiel.

Účelom normalizácie je minimalizovať opakovanie údajov a možné štrukturálne zmeny v databáze s postupmi aktualizácie. To sa dosahuje oddelením (rozkladu) jednej tabuľky v dvoch alebo viacerých, po ktorom nasleduje použitie žiadostí o prevádzku navigácie. Získaný logická štruktúra Databáza možno odhadnúť na kvantifikáciu rôznych charakteristík (počet odkazov na logické záznamy, množstvo údajov v každej žiadosti, celkové množstvo údajov). Na základe týchto odhadov logická štruktúra Môže sa zlepšiť, aby sa dosiahla väčšia účinnosť.

Špeciálna diskusia si zaslúži postup riadenia BD. Je to najjednoduchší v režime jedného používateľa. V režime Multiplayer av distribuovaných databázach je postup výrazne komplikovaný. So súčasným prístupom niekoľkých používateľov bez prijatia osobitných opatrení je možné postihnutie. Na odstránenie tohto fenoménu použite systém transakcií a usporiadanie tabuliek alebo jednotlivých záznamov.

Transakcia - Proces zmeny súboru, záznamu alebo databázy spôsobenej prevodom jednej vstupnej správy.

Vo fáze fyzického dizajnu sú vyriešené problémy súvisiace s výkonom systému skladovacie konštrukcie Údaje a metódy prístupu.

Interakcia medzi konštrukčnými stupňami a systémom slovníka sa musí posudzovať samostatne. Postupy dizajnu sa môžu používať nezávisle v neprítomnosti systému slovníka. Samotný systém slovníka možno považovať za prvok automatizácie dizajnu.

Návrh a odhadované kritériá sa používajú vo všetkých etapách rozvoja. V súčasnosti je neistota pri výbere kritérií najslabším miestom v dizajne databázy. Je to spôsobené obtiažnosťou opisu a identifikácie veľkého počtu alternatívnych riešení.

Je ľahšie riešiť kvantitatívne kritériá, ktoré zahŕňajú čas odozvy na žiadosť, náklady na modifikáciu, náklady na pamäť, čas stvorenia, náklady na reorganizáciu. Obtiažnosť môže spôsobiť rozpor kritérií pre seba.

Zároveň je mnoho kritériá optimalita, ktoré sú nesmierne vlastnosti, sú ťažké výrazné v kvantitatívnom reprezentácii alebo vo forme cieľovej funkcie.

Flexibilita, prispôsobivosť, prístupnosť pre nových používateľov, kompatibilita s inými systémami, schopnosť obnoviť, schopnosť obnoviť, schopnosť distribúcie a expanzie sa môže vzťahovať na kritériá kvality.

Konštrukčný proces je dlhý a časový spotrebný a zvyčajne trvá niekoľko mesiacov. Hlavnými zdrojmi databázového dizajnéra sú vlastnou intuíciou a skúsenosťami, preto kvality riešenia môže byť v mnohých prípadoch nízka.

Hlavnými dôvodmi nízkej efektívnosti určenej databázy môžu byť:

• neexistuje dostatok hlbokej analýzy požiadaviek (počiatočné fázy dizajnu), vrátane ich sémantiky a prepojenia údajov;
• veľké trvanie štruktúry štruktúry, ktorá tento proces robí, je únavné a ťažké vykonávať počas manuálneho spracovania.

Za týchto podmienok sa rozvoj automatizácie rozvoja stane prvoradým.

Hlavné etapy vývoja databázy

Fáza 1. Objasnenie úloh

V prvej fáze je vypracovaný zoznam všetkých hlavných úloh, ktorý by mal byť v zásade vyriešiť túto žiadosť - vrátane tých, ktoré nie sú potrebné dnes, ale môžu sa objaviť v budúcnosti. Podľa "hlavných" úloh sú funkcie, ktoré musia byť prezentované vo formách alebo správach o žiadosti.

Stage 2. Postupnosť výkonu úloh

Aby žiadosť pracovala logicky a pohodlne, je najlepšie kombinovať hlavné úlohy v tematických skupinách a potom zefektívniť úlohy každej skupiny, aby sa nachádzali v poradí ich vykonávania. Môže sa ukázať, že niektoré úlohy budú spojené s rôznymi skupinami alebo že implementácia určitej úlohy by mala predchádzať realizácii inej krajiny patriacej inej skupine.

Fáza 3. Analýza údajov

Po vytvorení zoznamu úloh je najdôležitejším krokom vypracovať podrobný zoznam všetkých údajov potrebných na vyriešenie každej úlohy. Niektoré údaje budú potrebné ako zdroj a nezmenia sa. Ďalšie údaje budú kontrolované a zmenené počas úlohy. Niektoré dátové prvky môžu byť odstránené alebo pridané. Nakoniec, niektoré údaje budú získané výpočtami: ich výstup bude súčasťou úlohy, ale nebudú zahrnuté do databázy.

Fáza 4. Definícia dátovej štruktúry

Po predbežnej analýze všetkých potrebných dátových položiek, musíte ich zefektívniť na objektoch a súvisieť s objektmi s tabuľkami a požiadavkami databázy. V prípade relačných databáz sa typ prístupu používa proces s názvom Normalizácia, v dôsledku čoho sa vyrába najefektívnejšia a flexibilnejšia metóda skladovania.

Fáza 5. Vývoj rozloženia aplikácie a používateľského rozhrania

Po nastavení štruktúry tabuľky aplikácií je Microsoft Access ľahko vytvoriť svoje usporiadanie pomocou formulárov a prepojte ich pomocou nekomplikovaných makrácií alebo postupov spracovania udalostí. Predbežné pracovné usporiadanie je ľahké preukázať zákazníkovi a získať súhlas pred schválením žiadostí úloh.

Krok 6. Vytvorenie aplikácie

V prípade veľmi jednoduchých úloh je vytvorená rozloženie prakticky úplnou aplikáciou. Avšak, to je často potrebné napísať postupy, ktoré vám umožňujú plne automatizovať riešenie všetkých úloh naplánovaných v projekte. Preto budete musieť vytvoriť špeciálne spojivá, ktoré poskytujú prechod z jednej úlohy na druhú.

Fáza 7. Testovanie a zlepšenie

Po dokončení práce na jednotlivých komponentoch aplikácie musíte skontrolovať fungovanie aplikácie v každom možných režimoch. Makrá je potrebné otestovať, na to, aby ste to urobili, s použitím kroku-s-krok režimu ladenia, pri ktorom sa vykoná jeden konkrétny makro. Pri používaní Visual Basic, aplikácie sú k dispozícii, existujú rôzne nástroje ladenia, ktoré vám umožňujú skontrolovať aplikáciu, odhalenie a opravu chýb.

Ako výstavba autonómnych častí žiadosti sa odporúča ich previesť na zákazníka, aby skontroloval ich fungovanie a získanie stanoviska o potrebe vykonať akékoľvek zmeny. Po oboznámení sa s prácou aplikácie, takmer vždy má ďalšie návrhy na zlepšenie, bez ohľadu na starostlivé predbežné projekty projektu. Užívatelia často zisťujú, že niektoré body, o ktorých v procese stanovovania úloh, hovorili tak veľmi dôležité a nevyhnutné, v skutočnosti nehrajú významnú úlohu pri praktickom používaní žiadosti. Identifikácia potrebných zmien v počiatočných fázach vývoja aplikácie umožňuje výrazne znížiť čas na následné zmeny.

Ciele základného dizajnu databázy

Hlavné ciele:

• Zabezpečenie ukladania v databáze všetkých potrebných informácií.
• Zabezpečenie možnosti získania údajov o všetkých potrebných požiadavkách.
• Zníženie redundancie a duplikácie údajov.
• Zabezpečenie integrity údajov (správnosť ich obsahu): vylúčenie rozporov v obsahu údajov, eliminácia ich straty atď.

Hlavné etapy dizajnu databázy

Koncepčný (infologický) dizajn - budovanie sémantického modelu oblasti predmetu, to znamená, že informačný model najvyššej úrovne abstrakcie. Takýto model sa vytvorí bez orientácie na akomkoľvek konkrétnom DBMS a dátovom modeli. Podmienky "Sémantický model", "koncepčný model" a "infologický model" sú synonymom. Okrem toho, v tomto kontexte sa slová "databázový model" a "model predmetovej oblasti" môžu použiť rovnako (napríklad "koncepčná databáza" a "koncepčný model predmetu"), pretože takýto model je Realita aj realita a navrhnutá databáza pre túto realitu.

Špecifický formulár a obsah koncepčného modelu databázy je určený formálnym prístrojom vybraným na to. Typicky sa používajú grafické notácie podobné er diagramom.

Najčastejšie sa koncepčný databázový model obsahuje:

• oPIS INFORMAČNÝCH Objektov alebo koncepcií oblasti a pripojenia medzi nimi.
• opis obmedzení integrity, t.j. Požiadavky na platné hodnoty údajov a prepojenia medzi nimi.

Dizajn logického (datalog) - Vytvorenie databázovej schémy na základe špecifického dátového modelu, ako je model relačného dát. Pre model relačného dát je model DATOLOG sada systémov vzťahov, zvyčajne označuje primárne kľúče, ako aj "spojenia" medzi vzťahmi, ktoré predstavujú externé klávesy.

Konverzia koncepčného modelu na logický model sa zvyčajne vykonáva podľa formálnych pravidiel. Táto fáza môže byť do značnej miery automatizovaná.

V etape logického dizajnu zohľadňujú špecifiká konkrétneho modelu údajov, ale nemusí sa zohľadniť špecifiká konkrétneho DBMS.

Fyzický dizajn

Fyzický dizajn - Vytvorenie databázovej schémy pre konkrétne DBMS. Špecifikácie Špecifické DBMS môžu zahŕňať obmedzenia na pomenovanie databázových objektov, obmedzení na podporovaných typoch údajov atď. Okrem toho špecifikácie špecifických DBMS počas fyzického dizajnu zahŕňajú výber riešení spojených s fyzickým pamäťovým médiom (výber metód riadenia pamäte disku, oddelenie databáz na súbory a zariadeniach, metódy prístupu k údajom), vytváranie indexov atď.

Normalizácia

Pri navrhovaní relačných databáz sa zvyčajne vykonáva takzvaná normalizácia.

Modely "Essence-Communication"

Model "Essence-Communication" (angličtina "Model entity-vzťah" ) Alebo model ER navrhnutý P. Chenom v roku 1976, je najslávnejším zástupcom triedy sémantických (koncepčných, infologických) modelov oblasti predmetu. ER model je zvyčajne reprezentovaný v grafickej forme s použitím pôvodného notácie P. Chen, zavolal Diagramalebo pomocou iných grafických zápisov ( Vrána "s nohy, Informačné inžinierstvo a atď.).

Hlavné výhody modelov ER:

• jasnosť;
• modely vám umožňujú navrhnúť databázy s veľkým počtom objektov a atribútov;
• ER-modely sú implementované v mnohých automatizovaných systémoch dizajnu databáz (napríklad Erwin).

Hlavné prvky modelov ER:

• objekty (subjekt);
• atribúty objektov;
• komunikácia medzi objektmi.

Subjekt je objekt objekt s atribútmi.

Komunikácia medzi subjektmi je charakterizovaná:

• typ komunikácie (1: 1, 1: N, N: M);
• trieda príslušenstva. Trieda môže byť povinná a voliteľná. Ak je každá kópia účtovnej jednotky zapojená do pripojenia, trieda príslušenstva je povinná, inak - nepovinné.

Sémantické modely

Sémantický model (koncepčný model, infografický model) - model predmetnej oblasti určenej na prezentáciu sémantiky oblasti predmetu na najvyššej úrovni abstrakcie. To znamená, že potreba používania koncepcií "nízkej úrovne" spojenej so špecifikámi fyzickej prezentácie a ukladania údajov sa eliminujú alebo minimalizujú.

Dátum K. J. Úvod do databázových systémov. - 8. ed. - m.: Williams, 2006:

Sémantické modelovanie sa stalo predmetom intenzívneho výskumu od konca 1970. Hlavným motívom takýchto štúdií (to znamená, že problém, ktorý výskumníci sa snažili vyriešiť), bola nasledovná skutočnosť. Faktom je, že databázové systémy majú zvyčajne veľmi obmedzené informácie o význame údajov uložených v nich. Najčastejšie môžu tieto jednoduché typy len manipulovať a určiť niektoré jednoduché obmedzenia integrity uložených na tieto údaje. Akýkoľvek komplexnejší interpretácia je priradený používateľovi. Bolo by však skvelé, ak by systémy mohli mať mierne širšie množstvo informácií a je trochu intelektuálne reagovať na požiadavky užívateľa, ako aj udržiavať zložitejšie (tj vyššie úrovne) užívateľské rozhrania.
[…]
Myšlienky sémantického modelovania môžu byť užitočné ako nástroj databázového návrhu aj v neprítomnosti priamej podpory v DBMS.

Najznámejším zástupcom sémantických modelov je model "Essence-Communication" (ER model).

Literatúra

• Dátum K. J. Úvod do databázových systémov \u003d Úvod do databázových systémov. - 8. ed. - m.: "Williams", 2006. - 1328 p. - ISBN 0-321-19784-4
• Kogalovsky M.R. Sľubné informačné systémy technológie. - m.: dmk stlačte; Spoločnosť AYI, 2003. - 288 p. - ISBN 5-279-02276-4
• Kogalovsky M.R. Encyklopédia Databázové technológie. - M.: Financie a štatistiky, 2002. - 800 p. - ISBN 5-279-02276-4
• Kuznetsov s.d. Základy databáz. - 2. ed. - M.: Internetová univerzita informačných technológií; Binomiálne. Laboratórium poznatkov, 2007. - 484 p. - ISBN 978-5-94774-736-2
• Connolly T., Begg K. Databázy. Dizajn, implementácia a údržba. Teória a prax \u003d databázové systémy: praktický prístup k dizajnu, implementácii a manažmentu. - 3. ed. - m.: "Williams", 2003. - 1436 p. - ISBN 0-201-70857-4
• Garcia-Molina, Ulman J., Uidom J. Databázové systémy. Celý kurz. - m.: "Williams", 2003. - 1088 p. - ISBN 5-8459-0384-X

pozri tiež

• Metódy návrhu

Spojenie

• Model "Essence-Communication" - krok k jednému zastúpeniu údajov - citforum
• Rozšírenie relačného modelu pre lepšiu reflexiu sémantiky - citforum
• Príručka pre navrhovanie databáz miest "pre začiatočníkov"
• Spôsob navrhovania logickej štruktúry relačnej databázy bez normalizácie tabuliek

Poznámky

Nadácia Wikimedia. 2010.

Sledujte, čo je "design databázy" v iných slovníkoch:

Administrátor databázy osoba zodpovedná za vývoj databázových požiadaviek, jeho dizajn, implementáciu, efektívne využívanie a údržbu, vrátane riadenia užívateľských účtov a ochrany pred neoprávnenými ... Wikipedia

- (Eng. Databáza refaktoring) Toto je jednoduchá zmena v databázovej schéme, ktorá pomáha zlepšiť svoj projekt pri zachovaní funkčnej a informačnej sémantiky. Inými slovami, dôsledkom databázy Refaktoring nemôže byť ... ... Wikipédia

Dizajn - jedna z foriem popredného odrazu reality, proces vytvárania predhjedienok (prototyp) zamýšľaného objektu, fenoménu alebo procesu pomocou špecifickosti. Metódy. P. je špecifická forma prejavu prognostického. Funkcie riadenia, ... ... Ruská sociologická encyklopédia

Žiadosť "BD" je tu presmerovaný; Pozri tiež iné hodnoty. Databáza prezentovaná v objekte tvoria kombináciu nezávislých materiálov (články, výpočty, predpisy, súdne rozhodnutia a iné podobné materiály), ... ... Wikipedia

Skôr ako začnete vytvárať databázu, musíte na ňom nejaký čas stráviť dizajn.

Hlavným cieľom navrhovania databáz (databázy) je znížiť redundanciu uložených údajov, a následne ukladanie množstva použitého pamäte, zníženie nákladov na viacnásobné operácie aktualizácie redundantných kópií a eliminácia možnosti rozporov v dôsledku skladovania na rôznych miestach informácií o rovnakom objekte. Takzvaný, "čistý" BD projekt ("každý skutočnosť na jednom mieste") môže byť vytvorená pomocou metodiky normalizácie vzťahov. Normalizácia Musí byť použitý v konečnej skúšobnej fáze návrhu databázy.

Zlá štúdia štruktúry základne takmer vždy vedie k zbytočným časovým výdavkom na jeho spracovanie v budúcnosti. Skúsení vývojári neplatí žiadny menší dizajn databázy ako ich vytvorenie. Všeobecne platí, že vývoj databázy obsahuje tieto kroky:

1. Určenie zadania databázy.

2. Rozhodovanie o tom, ktoré zdroje musia databáza obsahovať.

3. Určenie zdrojových tabuliek databázy.

4. Definícia polí, ktoré budú zahrnuté do tabuliek a výber oblastí obsahujúcich jedinečné hodnoty.

5. Vymenovanie odkazov medzi tabuľkami a konečným sledovaním výslednej štruktúry.

6. Vytvorenie tabuliek, viazanie navzájom a experimentálne plnenie s procesnými údajmi.

7. Vytvorenie formulárov, správ a žiadostí o zadané operácie s zadanými údajmi.

Definovanie zadania databázy

Vývoj každej databázy začína štúdiom problému, ktorý by mal byť povolený, alebo potreby, ktoré by mala uspokojiť.

Ako príklad, skúste vytvoriť jednoduchú databázu knižnice knižnice literárnej knižnice. Databáza je navrhnutá tak, aby ukladanie údajov o knihách získaných knižnicou, informácie o umiestnení jednotlivých inštancií každej publikácie a informácií o čitateľoch.

Výber informácií zahrnuté v databáze

Ak chcete zachovať katalógy knižníc, organizácia vyhľadávania požadovaných štatistík o knihách a knižniciach v databáze by mala byť uchovávaná informácia, z ktorých väčšina je umiestnená v katalógových katalógoch. Analýza referenčných žiadostí ukazuje, že hľadať vhodné knihy (na témy, autora, publikovanie atď.) A výber potrebných (napríklad anotácia) by sa malo prideliť atribúty Katalógová karta:

2. Názov knihy.

3. Miesto publikácie (mesto).

4. Vydavateľ (vydavateľský názov).

5. Rok prepustenia.

6. Anotácia.

Atribúty na charakterizáciu skladovacích miest jednotlivých kópií kníh, možno pripísať:

1. izbová izba (izba).

2. Rock číslo v miestnosti.

3. Počet políc na stojane.

4. Číslo (číslo inventára kníh).

5. Dátum získavania.

6. Dátum umiestňovania konkrétnej knihy na určitom mieste.

7. Dátum zaistenia knihy z nainštalovaného miesta.

Atribúty na charakterizáciu čitateľov možno pripísať:

1. Čítač číslo lístka (formulár).

2. Familia Reader.

3. Názov čitateľa.

4. Sprievodca čitateľom.

5. Adresa čitateľa.

6. Telefónne čítačky.

7. Dátum vydania čitateľovi konkrétnej knihy.

8. Termín, pre ktorý je špecifická kniha vydaná čitateľovi.

9. Dátum návratnej knihy.

Definícia zdrojových tabuliek

Analýza vyššie uvedených objektov a atribútov vám umožňuje určiť nasledujúce tabuľky pre databázu dizajnu na vytvorenie databázy:

2. Knihy. Tabuľka je určená na skladovanie kníh o knihách.

3. Vydavatelia.Tube je určený na ukladanie informácií o vydavateľstve.

4. Uskladnenie. Tabuľka je navrhnutá tak, aby opísala miesto skladovania kníh.

5. Vydávanie.Tube je určený na ukladanie informácií o vydaných knihách.

6. ČitateliaFľaše sú určené na ukladanie informácií o čitateľoch knižnice.

Výber potrebných polí tabuľky

Definovaním sady tabuliek zahrnutých v databáze, musíte premýšľať o tom, ktoré informácie o každom objekte budú zahrnuté do každej z tabuliek. Každé pole by malo patriť do jednej samostatnej tabuľky. Zároveň by mali byť informácie v každej oblasti štrukturálne elementárne, to znamená, že by sa mala skladovať v poliach vo forme najmenších logických komponentov.

Na základe vyššie uvedeného lúka Vo vybraných tabuľkách a typ uložené údaje.

Knihy:

· kód knihy - numerické pole je určené pre jednoznačné definovanie každej konkrétnej knihy v databáze;

· názov knihy

· anotácia - textové pole;

· dátum uverejnenia;

· dátum prijatia knižnice;

· uskladnenie.
Vydavatelia:

· kód vydavateľa - numerické pole je určené na jednoznačné definovanie každého špecifického vydavateľa v databáze;

· názov vydavateľa - symbolické pole, nie viac ako 256 znakov;

· mesto, kde sa nachádza vydavateľ - symbolické pole, nie viac ako 25 znakov.

Skladovanie:

· kód umiestnenia - numerické pole je určené na jednoznačné definovanie každej konkrétnej police v databáze;

· číslo izby - číselné pole;

· hodnosť - číselné pole;

· Číslo políc - číselné pole.

Vydanie:

· vydávajúci kód - numerické pole je určené na jednoznačné definovanie každej špecifickej emisie v databáze;

· kniha vydaná izba - číselné pole;

· kód čitateľa - číselné pole;

· dátum vydania;

· funkciu vydania (počet dní);

· dátum návratu.

Čitatelia:

· Čítač číslo - numerické pole je určené pre jednoznačné definovanie každého špecifického čítačky v databáze;

· priezvisko

· názov - symbolické pole, nie viac ako 50 znakov;

· patronymický - symbolické pole, nie viac ako 50 znakov;

· adresa - symbolické pole, nie viac ako 256 znakov;

· telefón - symbolické pole, nie viac ako 20 znakov.

Výber jedinečných polí

V relačnej databáze môžu byť tabuľky navzájom spojené. Toto pripojenie je nainštalované pomocou jedinečných polí. Unikátne polia - Toto sú takéto polia, v ktorých sa nedajú opakovať hodnoty. Napríklad série a číslo pasu určite identifikuje akúkoľvek osobu, ktorá má pas. Takáto pole (alebo kombinácia polí), ktorá jednoznačne identifikuje záznam v tabuľke, sa nazýva primárny kľúčV kvalite primárneho kľúčového poľa, poradové číslo záznamu v katalógu, číslo tabuľky zamestnancov podniku, článok v maloobchodných predajoch môže byť.

Pre našu databázu sú nasledujúce polia primárne klávesy:

· Knihy - kód knihy.

· Vydavatelia - kód vydavateľa.

· Skladovanie - kód umiestnenia.

· Emisia - vydávajúci kód.

· Čitatelia – číslo lístka.

Účel pripojení medzi tabuľkami

Inteligentné odkazy prepojte dve tabuľky pomocou spoločnej oblasti, ktorá je k dispozícii v oboch tabuľkách. Existujú tri typy takýchto pripojení:

· jeden na jedného- každá položka tabuľky a nemôže byť spojená s viac ako jednou kartu B;

· jedným z nich- Jeden záznam v tabuľke A môže byť spojený s mnohými tabuľkami B (napríklad v každej triede môže byť mnoho študentov);

· mnoho-spolu- Každý záznam v tabuľke A môže byť spojený s mnohými záznamami v tabuľke B a každý záznam v tabuľke B - s mnohými zápismi v tabuľke A (napríklad každý študent môže mať niekoľko učiteľov, a každý učiteľ môže mať mnoho študentov ).

Relačné databázy vám nedovoľujú vytvárať odkazy ako mnoho-to-mnoho priamo. V reálnom živote sa však takéto dlhopisy nachádzajú veľmi často, preto sú implementované prostredníctvom pomocných tabuliek, spájajúcich niekoľko tabuliek typu pripojení jeden-to-mnoho.

Aby bolo možné priradiť jednu tabuľku na strane druhej, musíte zadať pole primárneho kľúča z prvej tabuľky v druhej tabuľke, t.j. Zaviesť do druhej tabuľky externý kľúč. Spojenie medzi týmito dvoma tabuľkami sa vykonáva pripojením primárneho kľúča hlavnej tabuľky (umiestnenej na strane "jedného" pomeru) do rovnakého poľa externého tlačidla súvisiacej tabuľky (umiestnené na strane "Mnoho "Pomer). Oblasť externého tlačidla v súvisiacej tabuľke musí mať rovnaký typ údajov ako primárny kľúč v materskej tabuľke, ale s jednou výnimkou. Ak má primárny kľúč hlavnej tabuľky "typu počítadla", pole externého tlačidla v súvisiacej tabuľke musí mať "číselný" typ údajov.

V našej databáze nastavíme tieto typy väzieb medzi tabuľkami:

1. Autori - knihy. Tu je odkaz mnoho-spoluKaždý autor môže mať viac ako jednu knihu a každá kniha môže napísať niekoľko autorov. Preto zadáme pomocnú tabuľku "Autori-knihy" s nasledujúcimi poliami:

· kód knihy.

2. Knihy - vydavatelia. Tu je odkaz mnoho-spolu, Akákoľvek kniha môže zverejniť niekoľko vydavateľov a akékoľvek problémy s vydavateľstvom nie je jedna kniha. Preto zadáme ďalší pomocný stôl "Book-Publishing" s nasledujúcimi poliami:

· kód knihy;

· kód vydavateľa.

3. Skladovanie - Knihy. Tu je odkaz jedným z nichNa jednej polici môžete nastaviť veľa kníh, ale akúkoľvek knihu môže byť len na jednej polici v úložisku. Pole "Storage Place" v tabuľkách "Book" preto definuje ako externý kľúč, a prepojte tabuľku "Storage" a "Knihy" podľa primárneho tlačidla "Umiestnenie kód" a externé tlačidlo "Storage Place".

4. Knihy - emisia. Tu je odkaz jedným z nich. Rovnaká kniha môže byť vydaná niekoľkokrát v rôznych dátumoch rôznym čitateľom. Preto je "počet vydaných" v tabuľke "emisií" definovaný ako externý kľúč, a pripojíme tabuľku "Knihy" a "vydávanie" primárnym kľúčom "knihy" a externý kľúč " Kniha vydaná ".

5. Čitatelia - vydávanie. Tu je odkaz jedným z nich. Rovnaká kniha môže byť vydaná niekoľkokrát rôznymi čitateľmi v rôznych časoch. Preto je pole "čitateľský kód" pole v tabuľke "Edsuance" definuje ako externý kľúč, a pripojíme "čitateľa" a "emisiu" tabuľku "čitateľa" a externý kľúč "čitateľský kód".

Normalizácia vzťahov

Po dokončení konštrukcie tabuliek a identifikácia väzieb, ktoré medzi nimi existujú, je potrebné dôkladne znovu odošlite výslednú štruktúru skôr, ako začnete vytvárať tabuľky a zadajte informácie. Normalizácia vzťahov umožňuje výrazne znížiť množstvo uložených informácií a eliminovať anomálie v organizácii ukladania údajov.

Pravidlo 1: Každé pole tabuľky musí predstavovať jedinečný typ informácií.

V navrhnutom databáze neexistujú žiadne polia v rôznych tabuľkách obsahujúcich tie isté informácie (s výnimkou externých kľúčov).

Pravidlo 2: Každá tabuľka musí mať jedinečný identifikátor, alebo primárny kľúč, ktorý sa môže skladať z jednej alebo viacerých polí.

V databáze, ktorú navrhnuté USA, všetky tabuľky (s výnimkou pomocných "autorov - knihy" a "vydavateľstva") obsahujú primárny kľúč.

Pravidlo 3: Pre každú hodnotu primárneho kľúča by hodnota v stĺpcoch údajov mala odkazovať na objekt tabuľky a plne ho opísať.

Toto pravidlo sa používa dvoma spôsobmi. Po prvé, tabuľka by nemala byť údajmi, ktoré nesúvisia s objektom definovaným primárnym kľúčom. Napríklad, hoci sú potrebné informácie o svojich autoroch pre každú knihu, ale autor je nezávislý objekt a údaje o tom by mali byť v príslušnej tabuľke. Po druhé, údaje v tabuľke musia plne opísať predmet.

Pravidlo 4: Mali by existovať možnosť zmeniť hodnoty akéhokoľvek poľa (nezahrnuté v primárnom tlačidle) bez toho, aby sa ovplyvnili tieto ostatné polia.

Posledne uvedené pravidlo vám umožňuje skontrolovať, či pri zmene údajov v tabuľkách nebudú žiadne problémy. Vzhľadom k tomu, v databáze, ktorú navrhnuté nami, údaje obsiahnuté v rôznych oblastiach tabuliek sa neopakujú nikde, máme možnosť nastaviť hodnoty všetkých polí (s výnimkou primárnych kľúčov).

Vyplnenie databázy, vytváranie formulárov a správ

Ak chcete zistiť, koľko štruktúra databázy zodpovedá úlohe a ako pohodlne pracovať s touto databázou musíte zadať niekoľko jednoduchých záznamov. Zvyčajne, potom je potrebné vrátiť sa k štruktúre základne a nastaviť ju v súlade s tým, aké výsledky sa získali počas takéhoto testu.

V záverečnej fáze vytvorte formuláre na zadávanie informácií do databázy, správy o výstupe informácie a požiadavky, s ktorými sa informácie odoberajú z niekoľkých tabuliek. Ak je základňa určená na prevedenie na iných užívateľov, potom s najväčšou pravdepodobnosťou je potrebné, aby niekto zo zahraničných ľudí skontroloval, ako pohodlná práca s formulármi a správami.

Získaný dátový systém Rozvinutá databáza v MS Access je prezentovaná na obr. 4.1.

Obr. 4.1. Systém dátových dát vyvinutý DB v Microsoft Access

Kontrolné otázky

1. Uveďte definíciu informačného systému.

2. Vysvetlite koncepciu databázy.

3. Aká je oblasť predmetu?

4. Uveďte definíciu DBMS.

5. Aký je model údajov?

6. Vysvetlite základné princípy modelu relačného dát.

7. Vysvetlite funkcie Microsoft Access DBMS.

8. Aké sú objekty základnej databázy Access?

9. Vysvetlite štruktúru prístupovej tabuľky.

10. Vysvetlite koncepty: dotaz, formulár, správa, prístupová stránka, makro, modul.

11. Aké sú hlavné štádiá databázového dizajnu?

12. Ako je výber informácií zahrnutých do databázy?

13. Vysvetlite koncepty: primárny kľúč, externý kľúč.

14. Aký je účel pripojení medzi tabuľkami?

15. Vysvetlite hlavné typy pripojení medzi tabuľkami.

16. Aká je normalizácia vzťahov s databázami?

Základné koncepcie databázy

Vývoj výpočtovej techniky sa uskutočnil v dvoch hlavných oblastiach:

aplikácia výpočtovej techniky na implementáciu číselných výpočtov;

použitie výpočtových zariadení v informačných systémoch.

Informačný systém je kombináciou softvéru a hardvéru, metód a ľudí, ktorí poskytujú zber, skladovanie, spracovanie a vydávanie informácií na vyriešenie úloh. V ranom štádiu používania informačných systémov sa použil vzorový model spracovania. V budúcnosti sa databázy začali uplatňovať v informačných systémoch. Databázy sú modernou formou organizácie, skladovania a prístupu k informáciám. Príkladmi veľkých informačných systémov sú bankové systémy, objednávky vstupeniek, atď.

Databáza je integrovaný súbor štruktúrovaných a vzájomne prepojených údajov, ktoré organizujú určité pravidlá, ktoré poskytujú všeobecné zásady opisu, ukladanie a spracovanie údajov. Typicky je databáza vytvorená pre oblasť predmetu.

Oblasť predmetu je súčasťou reálneho sveta, ktorý sa má študovať, aby sa vytvorila databáza na automatizáciu procesu riadenia.

Súpravy princípov, ktoré určujú organizáciu štruktúry logickej skladovania dát v databáze, sa nazývajú dátové modely.

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

Už mnoho rokov sa použili ploché tabuľky (ploché databázy) zoznamu zoznamov v programe Excel. V súčasnosti relačné dátové modely získali najväčšiu distribúciu vo vývoji databázy. Relačný dátový model je súborom jednoduchých dvojrozmerných tabuliek - vzťahy (eng. Vzťah), t.j. Najjednoduchšia dvojrozmerná tabuľka je definovaná ako postoje (mnohé z rovnakého typu záznamov kombinovanej jednej témy).

Z termínovaného vzťahu (pomeru) sa nazýva model relačného dát. Relačná databáza využíva niekoľko dvojrozmerných tabuliek, v ktorých sa riadky nazývajú záznamy a stĺpce polí medzi evidenciami, ktorých sú stanovené. Táto metóda dátovej organizácie umožňuje dát (záznamy) v jednej tabuľke komunikovať s údajmi (záznamy) v iných tabuľkách prostredníctvom jedinečných identifikátorov (kľúče) alebo kľúčových polí.

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

1. Zásady normalizácie:

V každej tabuľke by databáza nemala byť opakovaná polia;

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

Každá primárna kľúčová hodnota musí byť v súlade s dostatočnými informáciami o type subjektu alebo o objekte tabuľky (napríklad informácie o výkonnosti, skupine alebo študentov);

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

2. Typy logického pripojenia.

Komunikácia je nastavená medzi dvoma zdieľanými poliami (stĺpcami) dvoch tabuliek. Existujú pripojenia s pomerom "one-to-one", "one-to-mnoho" a "mnoho-co-mnoho".

Vzťahy, ktoré môžu existovať medzi dvoma záznammi tabuľky:

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

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

mnohí - to - jeden, množstvo záznamov z jednej tabuľky zodpovedá jednej vstupu v inej tabuľke;

mnohí - k mnohým, mnoho záznamov z jednej tabuľky zodpovedá niekoľkým záznamom v inej tabuľke.

Typ vzťahu v vytvorenom komunikácii závisí od spôsobu určenia súvisiacich polí:

"One-to-Mnoho" postoj sa vytvorí, keď je len jedna z polí je základným kľúčom kľúča alebo jedinečným indexom.

Pomer "One-to-One" sa vytvorí v prípade, keď sú obe pridružené polia kľúčové alebo majú jedinečné indexy.

Pomer "Mnohí - mnoho" je vlastne dva vzťahy "jeden-to-mnoho" s treťou stôl, ktorého primárny kľúč pozostáva z cudzích kľúčových polí oboch ďalších tabuliek

3. Kľúče. Kľúčom je stĺpec (môže existovať niekoľko stĺpcov), pridané do tabuľky a umožňuje vytvoriť spojenie so záznamami v inej tabuľke. Existujú dva typy kľúčov: primárne a sekundárne alebo externé.

Primárnym kľúčom je jedna alebo viac polí (stĺpce), kombinácia hodnôt, z ktorých každá položka určuje každú položku v tabuľke. Primárny kľúč neumožňuje hodnoty null a malo by mať vždy jedinečný index. Primárny kľúč sa používa na viazanie tabuľky s externými tlačidlami v iných tabuľkách.

Externý (sekundárny) kľúč je jeden alebo viac polí (stĺpce) v tabuľke obsahujúcom odkaz na poli alebo primárne pole kľúčov v inej tabuľke. Externý kľúč definuje spôsob kombinovania tabuliek.

Z dvoch logicky súvisiacich tabuliek sa človek nazýva primárna tabuľka kľúča alebo hlavná tabuľka a iná tabuľka sekundárneho (externého) kľúčovej alebo podriadenej tabuľky. DBMS vám umožní porovnať súvisiace záznamy z oboch tabuliek a zdieľajú ich vo formulári, správy alebo žiadosti.

Existujú tri typy primárnych tlačidiel: Kľúčové meračové polia (počítadlo), jednoduchý kľúč a kompozitný kľúč.

Pole počítadla (typ údajov "počítadlo"). Typ dát poľa v databáze, v ktorom pre každú tabuľku nahrávania sa do poľa automaticky zadá jedinečná číselná hodnota.

Jednoduchý kľúč. Ak pole obsahuje jedinečné hodnoty, ako sú kódy alebo čísla inventára, potom toto pole môže byť definované ako primárny kľúč. Ako kľúč môžete definovať akékoľvek pole obsahujúce údaje, ak toto pole neobsahuje opakované hodnoty alebo hodnoty null.

Kompozitný kľúč. V prípadoch, keď nie je možné zabezpečiť jedinečnosť hodnôt každého poľa, je možné vytvoriť kľúč pozostávajúci z niekoľkých oblastí. Najčastejšie sa táto situácia vyskytuje pre tabuľku, ktorá sa používa na viazanie dvoch tabuliek mnohých - k mnohým.

Je potrebné opäť opäť všimnúť, že v oblasti primárneho kľúča musí existovať len jedinečné hodnoty v každom riadku tabuľky, t.j. Zhoda nie je povolená a v poli Sekundárneho alebo externého kľúča je povolené zodpovedajúce hodnoty v tabuľkových riadkoch.

Ak existujú ťažkosti pri výbere vhodného typu primárneho kľúča, potom v klávesovej skrini, je vhodné vybrať pole počítadla.

Programy, ktoré sú určené na informačné informácie, umiestnite ho do tabuliek a manipulácie s dátou sa nazývajú systémy správy databáz (DBMS). Inými slovami, DBMS je navrhnutý tak, aby vytvorili a udržiavali databázy a prístup k údajom. V súčasnosti existuje viac ako 50 typov DBMS pre osobné počítače. Najbežnejšie typy DBMS zahŕňajú: MS SQL Server, Oracle, Informix, SYBASE, DB2, MS Access, atď.

Vytvorenie databázy. Štádiá dizajnu

Vytvorenie databázy začína dizajnom.

DB Design Fisti:

Štúdium oblasti predmetu;

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

Definícia vzťahov medzi subjektmi a definíciou primárnych a sekundárnych (externých) kľúčov.

V konštrukčnom procese sa stanoví štruktúra relačnej databázy (zloženie tabuliek, ich štruktúra a logické spojenia). Štruktúra tabuľky je určená kompozíciou stĺpcov, typom údajov a veľkosť stĺpcov, kľúčových tlačidiel.

Základné pojmy BD modelu "Essence - komunikácia" zahŕňajú: subjekty, odkazy medzi nimi a ich atribútmi (vlastnosti).

Essence je akýkoľvek konkrétny alebo abstraktný objekt v posudzovanej predmetovej oblasti. Subjekty sú základné typy informácií, ktoré sú uložené v databáze (tabuľka je priradená v relačnej databáze každého subjektu). Subjekty sa môžu týkať subjektov: študenti, klienti, divízie atď. Kópia účtovnej jednotky a typu subjektu sú rôzne koncepty. Koncepcia povahy subjektu patrí do súboru homogénnych osobností, objektov alebo udalostí, ktoré hovoria ako celé (napríklad študent, klient atď.). Kópia účtovnej jednotky patrí napríklad na konkrétnu osobnosť v súbore. Typ subjektu môže byť študent a kopírka - Petrov, Sidorov atď.

Atribút je podstatnou vlastnosťou v oblasti predmetu. Jeho názov musí byť jedinečný pre konkrétny typ subjektu. Napríklad pre subjekt môže študent použiť nasledujúce atribúty: priezvisko, meno, patronymický, dátum a miesto narodenia, podrobnosti o pase atď. V relačnej databáze sú atribúty uložené v oblasti tabuliek.

Komunikácia je vzťah medzi subjektmi v oblasti predmetu. Komunikácia sú spojenia medzi jednotlivými časťami (v relačnej databáze je spojenie medzi záznamami tabuliek).

Subjekty sú údaje, ktoré sú klasifikované podľa typu a kontakty ukazujú, ako tieto typy údajov korelujú s iným. Ak opisujete určitú oblasť, pokiaľ ide o subjekt - komunikácia, dostaneme model entity - pripojenie pre túto databázu.

Zvážte oblasť predmetu: DEANATE (výkon študentov)

Databáza "Deantat" by mala byť uchovávaná údaje o študentoch, skupinách študentov, o odhade študentov na rôznych disciplínach, o učiteľoch, o štipendiách atď. Obmedzujeme sa na študentov o študentov, študentov študentov a odhady študentov na rôznych disciplínach. Definujeme esencie, atribúty subjektov a základné požiadavky na databázové funkcie s obmedzenými údajmi.

Hlavnými subjektmi významnými subjektmi databázy Da "Deantat" sú: študenti, skupiny študentov, disciplíny, akademický výkon.

Hlavný cieľ a významné atribúty subjektov:

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

Skupiny študentov - meno, kurz, semester;

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

Vlhkosť - hodnotenie, typ kontroly.

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

Vyberte si výkon študenta na disciplína, čo označuje celkový počet hodín a typ kontroly;

Vyberte si výkon študenta v skupinách a disciplínach;

Vyberte si disciplíny študované skupinou študentov v určitom kurze alebo

určitý semester.

Z analýzy týchto predmetovej oblasti vyplýva, že každý subjekt musí byť pridelený najjednoduchší dvojrozmerný stôl (vzťah). Ďalej musíte nastaviť logické pripojenia medzi tabuľkami. Medzi tabuľkami, študentmi a akademickým výkonom musia vytvoriť takéto komunikáciu tak, aby každý záznam z tabuliek z tabuľky zodpovedá niekoľkým záznamom v tabuľke testovateľnosti, t.j. Jeden - k mnohým, pretože každý študent môže mať niekoľko odhadov.

Logické spojenie medzi subjektmi skupiny - Študenti sú definovaní ako jeden - k mnohým na to, že existuje mnoho študentov v skupine, a každý študent je súčasťou tej istej skupiny. Logické spojenie medzi subjektmi disciplíny - výkonnosť je definovaná ako jedna - k mnohým, pretože pre každú disciplínu je možné doručiť niekoľko odhadov rôznych študentov.

Na základe vyššie uvedeného modelu je entitou - spojenie pre databázu "Deanat" - šípka je symbolom komunikácie: jeden - k mnohým.

Ak chcete vytvoriť databázu, musíte použiť jednu zo známych DBMS, napríklad prístupových DBMS.

Proces návrhu obsahuje nasledujúce kroky.

Infologický dizajn.

Určenie požiadaviek na prevádzkové prostredie, v ktorom bude informačný systém fungovať.

Vyberte systém databázy (DBMS) a iný softvér nástrojov.

Logický dizajn databázy.

Fyzický návrh databázy.

1.1. Infologický dizajn.

Proces navrhovania informačných systémov je pomerne zložitá úloha. Začína s výstavbou infologického modelu údajov, to znamená, že identifikuje subjekty.

Infoografický model oblasti predmetu (softvér) je popis štruktúry a dynamiky softvéru, povaha informačných potrieb používateľov, pokiaľ ide o užívateľa, ktorý porozumieť užívateľovi a nie závislé od predaja databázy. Tento popis je vyjadrený z hľadiska ne-individuálnych objektov softvéru a dlhopisov medzi nimi, ale ich typy spojené s nimi súvisiacimi s nimi obmedzenia týkajúce sa integrity a týchto procesov, ktoré vedú k prechodu predmetnej oblasti z jedného štátu do druhého.

V súčasnosti sa používa dizajn s použitím metódy "entity-vzťah, ER-metódy", ktorá je kombináciou hmotnostných a aplikovaných metód a má výhody oboch.

Fáza infografického dizajnu začína modelovým softvérom. Dizajnér ho rozdeľuje do niekoľkých miestnych oblastí, z ktorých každý (ideálne) obsahuje informácie dostatočné na poskytnutie žiadostí o samostatnú skupinu budúcich užívateľov alebo riešenie samostatnej úlohy (podtlaky). Každé miestne zastúpenie je modelované oddelene, potom sú kombinované.

Voľba lokálneho zastúpenia závisí od rozsahu softvéru. Zvyčajne sa rozdelí do miestnych oblastí takým spôsobom, že každý z nich zodpovedá samostatnej externej aplikácii a obsahovať 6-7 subjektov.

Podstata - Toto je objekt, že informácie sa budú akumulovať v systéme. Esencie sú fyzicky existujúce (napríklad, Zamestnanec alebo AUTO ) A abstraktné (napríklad, Skúška alebo Diagnóza ).

Pre subjekty rozlišujú triedu, typ subjektu a inštancie. Existujú tri subjekty hlavnej triedy: tón, pridružený a charakteristický, ako aj podtriedou asociatívnych subjektov - označenie.

Sodná podstata (jadro ) - Toto je nezávislá podstata, ktorá nie je ani združenie, ani označenie, ani charakteristika. Takéto subjekty majú nezávislú existenciu, aj keď môžu označiť iné subjekty.

Associatívna podstata (združenie ) - Toto je pripojenie typu "Mnohí - mnoho" medzi dvoma alebo viacerými subjektmi alebo prípadmi podstaty. Združenie Považujú za plné subjekty, môžu: zúčastňovať sa na iných združeniach a notácii rovnakým spôsobom ako tyčové esencie; majú vlastnosti, t.j. Ak chcete mať nielen súbor kľúčových atribútov potrebných na špecifikáciu odkazov, ale aj ľubovoľný počet ďalších atribútov charakterizujúcich komunikáciu.

Charakteristická podstata ( charakteristický ) - Toto je pripojenie typu "Mnoho-K-One" alebo "one-to-one" medzi oboma subjektmi (osobitný prípad združenia). Jediný cieľ Charakteristiky v rámci predmetu skladá sa v opise alebo objasnenie iného subjektu. Potreba pre nich vzniká kvôli tomu, že esencie reálneho sveta sú niekedy viacvalové vlastnosti.

Napríklad, manžel môže mať niekoľko manželiek, knihu - niekoľko vlastností reissue (opravené, doplnené, ...), atď.

Existencia charakteristiky je úplne závislá od charakterizovanej entity: ženy strácajú stav manželky, ak ich manžel zomrie.

Označujúca podstatu ( označenie ) - Toto je pripojenie typu "mnohý-k-one" alebo "jedno-to-one" medzi dvoma subjektmi a je inýz charakteristiky toho, čo nezávisí od určeného subjektu. Označenia sa používajú na uloženie opakovaných hodnôt veľkých textových atribútov: "Codififiers" Študentské študentské disciplíny, mená organizácií a ich oddelenia, zoznamy tovaru atď.

Spravidla, notácia nepovažovať sa Ako úplný subjekt, hoci by to neviedlo k žiadnej chybe. Označenia a charakteristiky nie sú úplne nezávislé subjekty, pretože predpokladá prítomnosť nejakej inej entity, ktorá bude "označená" alebo "charakterizovaná". Stále však predstavujú súkromné \u200b\u200bprípady podstaty a môžu, samozrejme, mať vlastnosti, môžu sa zúčastňovať na združeniach, notácii a majú svoje vlastné (nižšie) vlastnosti. Zdôrazňujeme tiež, že všetky prípady charakteristík musia byť nevyhnutne spojené s kópiou esencie. Je však povolené, že niektoré kópie podstaty charakterizovali žiadne pripojenia.

Typ Essence charakterizované menom a zoznamom vlastností a konštrukcia - Špecifické hodnoty vlastností.

Typy subjektov môžu byť klasifikované ako silný a slabý . Silné esencie existujú samy o sebe a existencia slabých subjektov závisí od existencie silného.

Čítačka knižnice je napríklad silná podstata a predplatné tohto čitateľa je slabá, ktorá závisí od dostupnosti príslušnej čitateľa.

Slabé esencie sa nazývajú podriadené (dcérske spoločnosti)a silné - základné (hlavné, rodič).

Pre každú entitu sú vybraté vlastnosti (atribúty).

Rozlišovať:

Identifikácia a opisné atribúty. Identifikácia atribútov majú jedinečnú hodnotu pre subjekty tohto typu a sú potenciálne kľúče. Umožňujú vám jednoznačne rozpoznať subjekty subjektu. Z potenciálnych kľúčov je vybratý jeden primárny kľúč (PC). Ako počítač je zvyčajne vybratý potenciálny kľúč, podľa ktorého dochádza k záznamovým inštancie. Okrem toho by mal počítač zahrnúť do jeho zloženia, počet atribútov je minimálne nevyhnutný na identifikáciu. Zostávajúce atribúty sa nazývajú opisné a priložte vlastnosti podstaty.

Kompozitné a jednoduché atribúty. Jednoduchý atribút sa skladá z jednej zložky, jeho hodnota je nesporná. Kompozitný atribút je kombináciou niekoľkých komponentov, prípadne patrí rôznym typom údajov (napríklad celé meno alebo adresa). Rozhodnutie o použití kompozitného atribútu alebo rozdelenie na komponenty závisí od povahy jeho spracovania a formátu používateľa tohto atribútu.

Jednoznačné a viacvalové atribúty (môže mať jednu alebo mnohú hodnoty pre každú inštanciu jednotky).

Hlavné a derivátové atribúty. Hodnota hlavného atribútu nezávisí od iných atribútov. Hodnota odvodeného atribútu sa vypočíta na základe hodnôt iných atribútov (napríklad študentský vek je vypočítaný na základe dátumu narodenia a aktuálneho dátumu).

Špecifikácia atributa pozostáva z toho menáinštrukcie dátový typ a popisy obmedzení integrity - Mnohé hodnoty (alebo doména), ktoré môžu prijať tento atribút.

Ďalej sa vykonáva špecifikácia odkazov v rámci miestneho zastúpenia. Komunikácia môže mať iný zmysluplný význam (sémantika). Rozlišovať vzťahy ako typ "Essence-Essence", "Atribút entity-Atribút" a "Atribút Atribút" pre vzťah medzi atribútmi, ktoré charakterizujú tú istú podstatu alebo rovnaké spojenie ako "Essence-Essence".

Každý komunikácia charakterizovaný názov, povinnosť, typa stupeň. Rozlišovať nepovinnýa Povinnýkomunikácia. Ak je potrebné novo generovaný objekt jedného typu, ktorý je potrebné priradiť s predmetom iného typu, existuje medzi týmito typmi objektov povinnýkomunikácia (označená dvojitou čiarou). V opačnom prípade je pripojenie nepovinný.

Za typ Existuje viacero pripojení "jeden až jeden" (1: 1), "jeden až mnoho" (1: n) a "mnoho až mnoho" (m: n). ER Diagram obsahujúci rôzne typy odkazov je znázornené na obr. 1. Upozorňujeme, že povinné odkazy na obr. 1 zvýraznená dvojitá čiara.

Moc Komunikácia je určená počtom subjektov, na ktoré sa vzťahuje táto väzba. Príkladom binárnej komunikácie je vzťah medzi oddelením a zamestnancami, ktorí v ňom pracujú. Príkladom ternárneho pripojenia je typ typu skúška medzi subjektmi Disciplína , Študent , Učiteľ . Z posledného príkladu je možné vidieť, že spojenie môže mať tiež atribúty (v tomto prípade dátum a Vyhodnotenie ). Príklad ER Diagram indikujúcej entity, ich atribúty a odkazy sú znázornené na obr. 2.

Premietané riešenia dizajnu môžu byť opísané v jazyku Infographic modeling (YAIM) založený na jazyku SQL, ktorý vám umožní poskytnúť pohodlný a kompletný popis akéhokoľvek subjektu, a preto celú databázu. Napríklad:

Vytvorenie tabuľky misky * (Rodská essencia)

Primárny kľúč (BL)

Polia (celé číslo BL, text 60, typ 7)

Obmedzenia (1. Oblasti misky musia byť

jedinečný; V rozpore s výstupom

tam sú správy "takéto jedlo".

2. Hodnoty poľa by mali patriť

sada: Snack, polievka, horúca, dezert,

Piť; Pri porušovaní výstupu

"Môžete len snack, polievka, horúca

Dezert, pitie ");

Vytvorte tabuľku zloženie * (pripojí káble a výrobky)

Primárny kľúč (BL, PR)

Externý kľúč (BLI z misky

Hodnoty null nie sú povolené

Odstránenie z misky je kaskádové

Aktualizovať riad. Blip Kaskádový)

Externý kľúč (atď.

Hodnoty null nie sú povolené

Odstránenie z produktov je obmedzené

Aktualizujte produkty. PR Cascades)

Polia (BL celé, atď, hmotnosť celé číslo)

Obmedzenia (1. Hodnoty polí BL a PR by mali patriť

súprava hodnôt z príslušných polí tabuľky

Jedlá a výrobkov; Pri porušovaní výstupu

"Nie je takéto jedlo" alebo "neexistuje takýto výrobok."

2. Hodnota hmotnosti poľa musí ležať v rozsahu od 0,1 do 500 g);

Tento opis sa však nelíši viditeľnosťou. Aby sa dosiahol väčšie ilustráciu, odporúča sa doplniť projekt pomocou jazykov infologického modelovania "esence-komunikácia" alebo "tabuľka-komunikácia

V grafoch "essence-komunikácia" podstata zobrazujú (obr.2) označené obdĺžniky, združenie – označené Rhombami alebo Šesťuholníky, atribúty – označené ováli, ale komunikáciamedzi nimi - smerové rebrá(Linky spájajúce geometrické tvary), ktoré môžu byť pripevnené stupňom komunikácie (1 alebo list, nahradenie slova "veľa") a požadované vysvetlenie.

V jazyku infografického modelovania "tabuľka-komunikácia" (obr. 3) sú všetky subjekty zobrazené jednoplnkové stoly s titulkamiskladajúci sa z názov a typ Essence. Riadky tabuľky sú zoznamom atribútov entity a tie, ktoré tvoria primárny kľúč. v blízkosti A otáčajú sa okolo rámca. Komunikácia medzi subjektmi je označená šípmi smerujúcimi z primárnych kľúčov alebo ich komponentov.

(jadro)

(Association)

(charakteristika)

Po vytvorení miestnych názorov sa vykonáva ich združenie. S malým počtom miestnych oblastí (nie viac ako päť), sú kombinované v jednom kroku. V opačnom prípade sa binárne združenie zvyčajne vykonáva v niekoľkých etapách.

Pri zlúčení môže dizajnér tvoriť štruktúry deriváty s ohľadom na tie, ktoré sa používajú v miestnych myšlienkach. Takýto prístup môže sledovať tieto ciele: \\ t

kombinovať do jednofénnych čiastkových myšlienok o rôznych vlastnostiach toho istého objektu;

zavedenie abstraktných konceptov, vhodné vyriešiť problémy systému, vytvorenie ich spojenie so špecifickými koncepciami používanými v modeli;

vzdelávacie triedy a podtriedy takýchto objektov (napríklad trieda "výrobok" a podtriedy typov výrobkov vyrobených v podniku).

Vo fáze Spojku je potrebné identifikovať a eliminovať všetky protirečenia. Napríklad tie isté mená sémanticky odlišných objektov alebo spojení alebo nekonzistentných obmedzení integrity na rovnakých atribútoch v rôznych aplikáciách. Eliminácia rozporov spôsobuje, že je potrebné vrátiť sa do etapy modelovania miestnych zastúpení, aby sa v nich príslušné zmeny.

Po dokončení kombinácie sú výsledky dizajnu koncepčným infografickým modelom oblasti predmetu. Modely miestnych zastúpení sú externé infologické modely.

Určenie požiadaviek na prevádzku

Atmosféra.

V tomto štádiu požiadavky na výpočtové prostriedky potrebné na prevádzku systému, definíciu typu a konfiguráciu konkrétneho počítača, vyberte typ a verziu operačného systému. Objem výpočtových zdrojov závisí od zamýšľaného objemu navrhovanej databázy a na intenzitu ich používania. Ak bude databáza fungovať v režime Multiplayer, potom je potrebné pripojiť ho k sieti a prítomnosť vhodného operačného systému viacerých úloh.