Koncepčný návrh Niekedy technický. Jeho hlavné etapy sú:

1) predbežný dizajn,

2) Náčrt (pracovný alebo techno-pracujúci) dizajn,

3) výroba, testovanie a ukončenie experimentálneho vzorového systému (obr. 4.3).

Obr. 4.3. Štádií koncepčného dizajnu.

Koncepcia koncepčného dizajnu začína podrobnou analýzou primárnych údajov a vylepšuje koncepčný dátový model, po ktorom je navrhnutý architektúra systému. V tomto prípade je vybraná schopnosť používať existujúce IP a zodpovedajúci spôsob ich konverzie. Po výstavbe projektu je špecifikovaný pôvodný obchodný plán. Výstupné komponenty tejto fázy sú koncepčný dátový model, model architektúry systému a rafinovaným podnikateľským plánom.

Počas vykonávania následných konštrukčných štádií sa predpokladá hlbšia a podrobná štúdia riešení vyvinutých v tomto štádiu. Zároveň nevylučuje vznik ich základnej zmeny. Hoci súčasné regulačné dokumenty stanovujú možnosť vykonania zmien projektu alebo programu (koncepcie), spravidla je to spojené so stratami finančných, materiálnych a pracovných zdrojov tak "zákazníkom" a "developer". Tieto straty môžu byť veľmi významné, ak potrebujeme urobiť významné zmeny v počiatočných riešeniach dizajnu a neskôr táto potreba vzniká. Preto je zvláštny význam tohto dizajnu fázy pre úspešné vytvorenie AIS, ako aj zodpovednosť vývojárov a zákazníka pri vykonávaní práce a koordinovať konečný dokument.

Na fázy vývojaIntegrácia a testovanie by sa mali vytvoriť testovacia databáza a testy. Vývoj, prototypové a testovacie databázy a aplikácie v súlade s projektom. Rozhrania s existujúcimi systémami sú ladení. Je opísaná konfigurácia aktuálnej verzie softvéru. Na základe výsledkov testov sú optimalizované databázu a aplikácie. Prílohy sú integrované do systému, ich testovanie sa vykonáva v systéme a testovaní systému. Hlavnými výsledkami javiska sú pripravené aplikácie, ktoré sú kontrolované ako súčasť systému na komplexných testoch, aktuálny popis konfigurácie softvéru, ktorý je upravený testovacou verziou systému a prevádzkovú dokumentáciu pre systém.

V dôsledku tohto dizajnu by sa mala získať logická štruktúra systému (subsystém, modul atď.), Schémy vstupov, výstup, reprezentáciu, konverziu dát atď.

V súlade so zákonnými pravidlami a dokumentáciou projektu, konečná fáza vytvorenia systému zahŕňa komplexné testovanie všetkých jeho zložiek, školenia užívateľov, trvalé podávanie atď.

Etapa implementácie Zahŕňa akcie na inštaláciu a implementáciu databáz a aplikácií. Hlavný výsledok javiska je pripravený a prenesený do softvéru zákazníka a hardvérovej platformovej platformy systému, sprievodná dokumentácia a akty akceptačných testov založených na výsledkoch experimentálnej prevádzky.

Na fáza prevádzky Trvalý (lepší - automatický) systém riadenia systému (monitorovanie) s cieľom sledovať stav objektu, včasné odhalenie chýb a abnormálnych situácií, jeho vývoj.

Podporné a vývojové stupne Zahŕňa procesy a operácie súvisiace s registráciou, diagnostikou a lokalizáciou chýb, vykonávanie zmien a testovania, implementácie regenerácie, replikácie a šírenia nových verzií jeho prevádzky, prenos aplikácií na novú platformu a škálovanie systému. Výskumný stupeň V skutočnosti je to re-iterácia fázy vývoja.

Výsledkom koncepčnej fázy dizajnu AIS je konečný dokument - "Koncepčný projekt", "AvanProekt", "Pilotný projekt" alebo "Koncepcia a program vytvárania ...". V budúcnosti budú prevažne použité výrazy "koncepcia projektu" a "koncepcia" alebo "vytváranie programu ...".

Koncepčný dizajn systému je charakterizovaný komprimovanými termínmi. Z tohto dôvodu môže byť výkon prác spojených s ním spojeným a prieskumom predbežného projektu sa môže uskutočniť paralelne alebo prekrývať v čase ich vykonávania.

Pri navrhovaní, vr. Pri riešení problémov automatizácie procesov je bežne akceptovaná jedna z dvoch možností: vytvorenie systému rozhodujúcich úloh hybnosti alebo obsahuje sľubné úlohy ("na pestovaní"), pričom sa zohľadní budúce potreby.

V prvom prípade si môžete vybrať lacné riešenie a rýchlo ho implementovať. Avšak, pravdepodobnosť je vysoká, že čoskoro bude systém potrebný na do značnej miery aktualizovaný alebo vymenený.

V druhom prípade sa vyžaduje závažnejšie štúdium požiadaviek a technických riešení, čo predstavuje nárast načasovania a nákladov projektu. Ale v tomto prípade je možné oveľa väčšie časové obdobie rozšíriť účinné fungovanie systému vytvoreného týmto spôsobom. Veľké investície sú však konjugát s väčšími rizikami. Preto sa odporúča rozbiť pripravovanú prácu na malých etapách, ktorých implementácia je schopná priniesť osobitný a hmatateľný výsledok, ktorý zabezpečuje riešenie úlohy. V tomto prípade, s minimálnymi investíciami, je možné zabezpečiť rýchly návrat a vytvoriť základ pre ďalší rozvoj systému, ktorý okrem iného podporuje, študovať získané výsledky, úpravu ďalších opatrení atď. Vývoj systému teda získa cyklickú povahu. A hoci tento prístup je trochu nákladnejší ako komplexné riešenie veľkého množstva problému, umožňuje znížiť vysoké riziká spojené so zmenami v požiadavkách vyvinutého systému.

Nemalo by sa prehliadať, že rýchly rozvoj vedy, technológií a technológií vedie k rýchlemu starnutiu použitých metód a systémov, ktoré nepriaznivo ovplyvňuje účinnosť ich používania. Zároveň v etapách vykonať zmeny jednotlivých zložiek systému oveľa jednoduchšie, ako je to úplne nahradenie. Okrem toho sa zvyčajne vyžaduje na zabezpečenie rýchleho návratu investícií, čo je dosť ťažké organizovať pri zavádzaní integrovaných riešení.

Môžete zdôrazniť tri hlavné typy dizajnu objektov a systémov Podľa stupňa ich zložitosti, objemu a počtu ďalších indikátorov: veľké, stredné a malé (malé) projekty.

Pri implementácii veľkých projektov sa zvyčajne uchyľujú k pomoci osvedčených rozsiahlych integrátorov, vrátane poradenských a implementačných organizácií.

Na implementáciu stredných projektov sa snažia robiť bez vlastného a (alebo) používať hotové riešenia, ktoré sa snažia prispôsobiť sa osobitným požiadavkám organizácie zákazníka.

Malé projekty sa vyznačujú použitím hotových riešení av niektorých prípadoch ich prispôsobujú špecifickým podmienkam používania.

Dizajn je. Začína vypracovanie v textovom a (alebo) grafickej forme pracovného plánu. V prvom štádiu návrhu musíte zistiť požiadavky na používateľa pre systém a na základe týchto požiadaviek tvoria rozloženie systému. Je vhodnejšie navrhnúť modulárnu metódu. Návrh informačných systémov priamo súvisí s ich programovaním, preto významnú časť projektovej práce súvisí s programovaním IP.

Modulárne programovanie- Spôsob rozvoja programov zahŕňajúcich program rozdelenie na nezávislých moduloch. Predpokladá sa, že modul musí mať optimálne rozmery (spravidla, aby sa plne prispôsobili na obrazovke displeja) a že rozdelenie veľkého programu na moduly uľahčuje jeho vývoj, ladenie a údržbu.

Programový modul, ktorý kombinuje údaje (vlastnosti) a operácie na nich (metódy) sa nazývajú objekt.

Objekt - Abstraktné mnohé objekty, ktorých všetky položky majú rovnaké charakteristiky.

Voľba dizajnových nástrojov môže významne ovplyvniť nasledujúce vlastnosti metód konštrukcie:

· Orientácia na vytvorenie jedinečného alebo typického projektu;

Isteračná povaha procesu navrhovania;

· Možnosť rozkladu projektu na komponenty, vyvinutý skupinami obmedzených čísel, po ktorom nasleduje integrácia komponentov;

· Pevná disciplína dizajn a rozvoj počas ich kolektívnej povahy;

· Potreba odcudzenie projektu od vývojárov a jeho následnú centrálnu podporu.

Model
Modelovanie oblasti predmetu je založené na používaní grafických diagramov, vrátane malého počtu heterogénnych zložiek. V roku 1976, Chen (Chen) navrhol pre návrh IC (databázy) na použitie Model Model vzťahu so subjektom je model "essence-komunikácia"), ktorá predstavuje koncepčné dátové modely. Boli rozšírené v moderných prípadových systémoch, ktoré podporujú automatizovaný IP design a zvyčajne sa používajú v informáciách a logickej modelovacej fáze.

ER model jasne zobrazuje štrukturálne bloky informácií a logických vzťahov medzi nimi. Hlavnými koncepciami sú esencia, komunikácia a atribút (pozri tabuľku).

Tabuľka konceptov: Essence, Connection a Atribút.

Typ komunikácie je indikovaný indexmi "1" alebo "m" nad zodpovedajúcou čiarou. Napríklad odkaz "Sprievodca" má typ "jeden pre mnoho": jeden zamestnanec môže viesť mnoho projektov; Komunikácia "Účasť" má typ "Mnohí pre mnoho": jeden zamestnanec sa môže zúčastniť na mnohých projektoch, a mnohí zamestnanci sa môžu zúčastniť projektu. Obrázok zobrazuje príklad ER diagramu.

Na základe modelov ER sú vytvorené relačné databázy.

Dôležitým parametrom IP je jednoduchosť jeho používania, ktorá zahŕňa kvalitu dizajnovej dokumentácie. Pri navrhovaní by ste sa mali zamerať na nasledujúce dokumenty:

GOST 24.602-86. Automatizované riadiace systémy. Zloženie a obsah práce na etapách stvorenia. (Zavedené z 01.01.89.-m.: Vydavateľstvo Normy, 1986.-12 p.).

GOST 34.601-90.. Informačné technológie. Súbor noriem pre automatizované systémy. Automatizované systémy. Fáza stvorenia (zavedená z 29.12.90, 24.601-86. 24.602-86. 1997).

GOST 34.602-89. Súbor noriem pre automatizované systémy. Technická úloha vytvoriť automatizovaný systém. Zaviesť 01.01.90.

GOST 34.603-92.. Informačné technológie. Typy testov automatizovaných systémov.

RD 50-640-87. Automatizované dizajnové systémy. Postup vykonávania práce pri vytváraní systémov: inštrukcie. - M.: Vydavateľstvo štandardov, 1987.-28 p. a atď.

Zhrnutie prehľadu prednášky

Pre študentov špecialitu
T1002 "Softvérové \u200b\u200binformačné technológie"

(L.V. Rudikova, Ph.D., Associate Professor)

Otázka 31. Architektúra DBMS. Model relačného dát

1. Koncepcia databázy.

2. Trojúčelová databázová architektúra.

3. Bytový cyklus databázy.

4. Architektúra DBMS.

5. Model relačného dát.

6. Navrhovanie relačných databáz.

7. Normálnych foriem vzťahov.

8. Relačnej algebry.

1. Koncepcia databázy.

Databázový systém je akýkoľvek informačný systém založený na počítači, v ktorom môžu byť údaje zdieľané s mnohými aplikáciami.

Informačný systém - Automatický systém, ktorý organizuje údaje a vynikajúce informácie.

Systém riadenia informácií - Systém poskytujúci riadenie podpory informácií.

Dáta - Rozptýlené fakty.

Informácie - organizované a spracované údaje.

Pod databáza Rozumie sa veľa vzájomne prepojených elementárnych skupín údajov (informácie), ktoré môžu byť spracované jedným alebo viacerými aplikačnými systémami. Databázový systém pozostáva z databázy; Softvér na všeobecné použitie systém správy databáz (DBMS) a slúži na správu databázy; vhodné vybavenie a ľudia.

Každé DBMS musia spĺňať tieto požiadavky:

· poskytnite používateľovi možnosť vytvárať nové databázy a určiť ich diagram (logická dátová štruktúra) S pomocou špeciálneho jazyka - jazyk definície údajov; \\ T udržiavať rôzne názory na rovnaké údaje;

· povoliť " opýtať sa»Údaje a zmeniť ich jazyk dotazualebo dánsky manipulačný jazyk; \\ T umožniť integráciu údajov a zdieľanie rôznych aplikácií;

· udržať uskladnenie veľmi veľkých dátových polí meraných gigabajmi a viac, v priebehu času, ich chránia pred náhodným poškodením a neoprávneným použitím, ako aj na poskytovanie modifikácie databázy a prístup k údajom podľa požiadaviek, t.j. zaručiť bezpečnosť a integritu údajov;

· kontrolný prístup k údajom súčasne pre mnoho používateľov; Odstránenie vplyvu žiadosti o jedného používateľa požiadať o iný a zabrániť simultánnemu prístupu, ktorý môže pokaziť údaje, t.j. Zaručujú riadenie prístupu paralelného dát.

Systém s databázou pozostáva z nasledujúcich komponentov:

· Používatelia, t.j. Ľudí, ktorí používajú údaje.

· Aplikácie, t.j. Užívateľské programy, ktoré vyžadujú údaje zo systému.

· DBMS - softvér, ktorý spravuje prístup k údajom a poskytuje špecifikovanú funkčnosť systému s databázou.

· Údaje, t.j. Riadky uložené v súboroch.

· Hostiteľský systém je počítačový systém, v ktorom sú súbory uložené. Prístup k reťazcom údajov vykonáva hostiteľský systém. Úlohou DBMS je vytvoriť požiadavky, ktoré vám umožnia používať funkčnosť systému systémového systému hostiteľského systému na udržanie rôznych aplikácií. DBMS je ďalšia úroveň softvéru, ktorá je nad softvérovým softvérom nadbytočná.

Databázový systém je teda možné reprezentovať ako nasledujúcu sekvenciu úrovne:

Na najnižšej úrovni sú uložené údaje v fyzických súboroch (fyzická pamäťová databáza). Na najvyššej úrovni - aplikácie s vlastnými myšlienkami rovnakých fyzických údajov. Každá reprezentácia databázy je špecifická logická štruktúra postavená z fyzikálnych dát. Aby sa zabezpečilo rozhranie medzi fyzickou pamäťou databázy a jej rôznymi logickými verziami (množstvo podporovaných reprezentácií) DBMS, by sa zase pozostáva z niekoľkých úrovní.

2. Trojúčelová databázová architektúra.

Rozdiel medzi logickým a fyzickým zastúpením údajov je oficiálne uznaný v roku 1978, keď výborANSI / SPARC. navrhol všeobecnú štruktúru databázových systémov. Táto štruktúra bola menovaná trojnásobná architektúra. Tri úrovne architektúry sú nasledovné: interné, koncepčné a externé.

Vnútorná úroveň - Toto je úroveň, ktorá určuje fyzický pohľad na databázu, ktorá je najbližšie k fyzickému ukladaniu a je spojená s metódami zachovania informácií o fyzických skladovacích zariadeniach. Objavte, fyzické adresy, indexy, ukazovatele atď. Sú spojené s touto úrovňou. Pre túto úroveň, dizajnéri fyzických databáz, ktoré rozhodujú, ktoré fyzické zariadenia budú ukladať údaje, ktoré prístupové metódy sa použijú na extrahovanie a aktualizáciu údajov a aké opatrenia by sa mali prijať na udržanie alebo zvýšenie výkonu systému správy databázy. Používatelia sa nedotýkajú tejto úrovne.

Koncepčná úroveň - štrukturálna úroveň definícia logickej databázovej schémy. Na tejto úrovni sa vykonáva koncepčný dizajn databázy, ktorý zahŕňa analýzu potrebných používateľov a určenie položiek údajov, ktoré potrebujete. Výsledkom koncepčného dizajnu je koncepčný systém, logický opis všetkých dátových prvkov a vzťahov medzi nimi.

Externá úroveň - Štrukturálne BD BP Definovanie zobrazenia údajov používateľa. Každá skupina užívateľov dostane vlastnú prezentáciu údajov v databáze. Každá takáto prezentácia údajov dáva užívateľsky orientovaný popis dátových prvkov, z ktorých prezentácia údajov a vzťah medzi nimi. Môže byť priamo stiahnutý z koncepčnej schémy. Kombinácia týchto reprezentácií údajov a poskytuje externú úroveň.

Prezentácie používateľov a aplikácií	Externá úroveň
Zobrazí
Koncepčný systém	Koncepčná úroveň
Ukážka	Vnútorná úroveň
Hostiteľský systém
Podlažné údaje

Obr. Úrovne DBMS

3. Životný cyklus databázy.

Proces návrhu, implementácia databázového systému sa nazýva databáza životného cyklu (HCBD). Postup vytvárania systému sa volá systém životného cyklu (ZHS).

Porozumenie a správny prístup k HCBD je veľmi dôležitý a vyžaduje podrobnú pozornosť, pretože je založená na prístupe, \\ t orientovaný na údaj. Dátové prvky sú stabilnejšie ako funkcie systému. Vytvorenie správnej dátovej štruktúry si vyžaduje komplexnú analýzu tried dátových jednotiek a vzťahov medzi nimi. Ak vybudujete logickú databázovú schému, potom v budúcnosti môžete vytvoriť ľubovoľný počet funkčných systémov pomocou tejto schémy. Funkčný orientovaný prístup môže byť použitý len na vytvorenie dočasných systémov, ktoré sú určené na krátkodobú prevádzku.

HCBD sa skladá z nasledujúcich krokov:

1. Predbežné plánovanie - BD Plánovanie vykonávané v procese vypracovania strategického databázového plánu. Počas procesu plánovania sa zhromažďujú tieto informácie:

· ktoré aplikačné programy sa používajú, a aké funkcie vykonávajú;

· aké súbory sú spojené s každou z týchto aplikácií;

· aké nové aplikácie a súbory sú v procese práce.

Tieto informácie pomáhajú určiť, ako sa používajú informácie o aplikácii, určiť budúce požiadavky na databázový systém.

Informácie o tejto fáze sú zdokumentované ako generalizovaný dátový model.

2. Kontrola uskutočniteľnosti . Tu je určená technologická, prevádzková a ekonomická realizovateľnosť plánu na vytvorenie databázy, t.j:

· technologická realizovateľnosť - Existuje technológia na implementáciu plánovanej databázy?

· prevádzková realizovateľnosť - existujú nejaké prostriedky a odborníci potrebné na úspešnú implementáciu plánu tvorby BD?

· hospodárska realizovateľnosť - je možné definovať závery? Plánovaný systém vyplatí? Je možné vyhodnotiť náklady a výhody?

3. Definícia požiadaviek zahŕňa výber cieľov databáz, čistí požiadavky na informácie o požiadavkách na systém a vybavenie a softvér. V tomto štádiu zberu údajov a stanovenie požiadaviek sa teda vytvorí všeobecný informačný modelVyjadrené v nasledujúcich úlohách:

· Ciele systému sú určené analýzou informačných potrieb. To tiež nevyhnutne označuje, ktorá databáza by mala byť vytvorená (distribuovaná, holistická) a ktoré sú potrebné komunikačné nástroje. Výstupný dokument - Komentár opisujúci cieľ systému.

· Definícia požiadaviek používateľa: Dokumentácia vo forme zhrnutých informácií (pripomienky, správy, prieskumy, dotazníky atď.); fixácia systémových funkcií a definícia aplikačných systémov, ktoré tieto požiadavky spĺňajú. Údaje sa predkladajú vo forme príslušných dokumentov.

· Určenie všeobecných požiadaviek na vybavenie a softvér spojené s udržiavaním požadovanej úrovne rýchlosti. (Zistenie počtu používateľov systému, počet vstupných správ denne, počet výtlačkov). Tieto informácie sa používajú na výber typov počítačov a DBMS, hlasitosti disku, počtu tlačiarní. Údaje tejto fázy sú uvedené v správe obsahujúcom príklady konfigurácií zariadení a softvéru.

· Vývoj plánu pre postupné vytváranie systému, ktorý obsahuje výber zdrojových aplikácií.

4. Koncepčný návrh - vytvorenie koncepčného databázového systému. Špecifikácie sú vyvinuté v rozsahu potrebnom na prechod na implementáciu.

Hlavný výstupný dokument je jeden infologický model(alebo bD schéma na koncepčnej úrovni). Pri vývoji tohto modelu sa informácie a funkcie používajú na vykonanie systému definovaného pri zbere a definíciách systému. V tomto štádiu je tiež žiaduce identifikovať: 1) pravidlá pre údaje; 2) pravidlá pre procesy; 3) Pravidlá pre rozhranie.

5. Predaja – proces transformácie koncepčného modelu do funkčnej databázy. Zahŕňa nasledujúce etapy.

1) Výber a nadobudnutie potrebných DBMS.

2) Konverzia koncepčného (infologického) modelu databázy do logického a fyzického dátového modelu:

· na základe infodického dátového modelu, dátový systém pre konkrétne DBMS sa v prípade potreby vybuduje, ak je to potrebné, tanečná denormalizácia je implementovaná s cieľom urýchliť spracovanie žiadostí vo všetkých žiadostiach kritických podľa času;

· sú definované, ktoré aplikačné procesy musia byť implementované v dátovom systéme ako uskladnené postupy;

· implementovať obmedzenia zamerané na zabezpečenie integrity údajov a vykonávania pravidiel pre údaje;

· dizajn a vygenerovať spúšťače na implementáciu všetkých centrálne špecifických pravidiel pre pravidlá integrity údajov a údajov, ktoré nemôžu byť špecifikované ako obmedzenia;

· rozvíjať stratégiu indexovanie a klastrovanie; Vyhodnoťte veľkosť všetkých tabuliek, klastrov a indexov;

· definujte úrovne prístupu používateľa, rozvíjať a implementovať pravidlá bezpečnosti a auditu. Vytvorte úlohy a synonymá, ktoré poskytujú prístup multiplayer s dohodnutými úrovňami prístupu Access.

· vypracovať sieťovú topológiu databázy a bezproblémového prístupového mechanizmu na vzdialené údaje (replikovaná alebo distribuovaná databáza).

3) Budovanie slovníka slovníka, ktorý určuje ukladanie definícií databázových údajov. Dátový slovník obsahuje aj informácie o prístupovej autorite, ochrane údajov a pravidlách ochrany údajov.

4) Naplnenie databázy.

5) Vytvorenie aplikačných programov, kontrolu kontroly.

6) Užívateľský tréning.

6. Hodnotenie a zlepšenie systému DB.Zahŕňa prieskum užívateľov s cieľom objasniť funkčné nezvyčajné potreby. V prípade potreby sa vykonajú zmeny, pridávajú nové programy a dátové prvky, keď zmeníte a rozširujte potreby.

HCBD teda zahŕňa:

· Štúdium oblasti a prezentácie príslušnej dokumentácie (1-3).

· Výstavba infologického modelu (4).

· Predaj (5).

· Hodnotenie práce a podpory databázy (6).

4. Architektúra DBMS.

Obr. Hlavné komponenty DBMS

Údaje, metadáta - obsahovať nielen údaje, ale aj informácie o štruktúre údajov ( metadáta). V relačnom DBMS sa metadáta obsahuje systémové tabuľky (pomery), názvy vzťahov, názvy atribútov týchto vzťahov a typov údajov týchto atribútov.

Často DBMS podporuje indexyúdajov. Index - Jedná sa o dátovú štruktúru, ktorá pomáha rýchlo nájsť dátové položky v prítomnosti časti ich hodnoty (napríklad index, ktorý nájde konkrétny vzťah, ktorý má zadanú hodnotu jedného z atribútov). Indexy sú súčasťou uložených dát a opisy, ktoré uvádzajú, ktoré atribúty sú indexy - časť metaúdajov.

Správca pamäte - Nasleduje požadované informácie z miesta skladovania a zmeny informácií v ňom na požiadavke uvedenej úrovne systému.

V jednoduchých databázových systémoch môže systém pamäte správcu slúžiť ako systém súborov operačného systému. Na zlepšenie efektívnosti však DBMS však zvyčajne vykonáva priame ovládanie pamäte. Správca pamäte sa skladá z dvoch komponentov:

· Správca súborov ovláda umiestnenie súborov na disku a prijíma blok alebo bloky obsahujúce súbory dožiadaním nárazníka manažéra (disk vo všeobecnosti je rozdelený do diskové bloky - Súvisiace oblasti pamäte obsahujúcej 4000 až 16000 bajtov).

· Manažér vyrovnávacej pamäte spravuje hlavnú pamäť. Prijíma bloky údajov z disku prostredníctvom správcu súborov a vyberie základnú pamäťovú stránku na uloženie konkrétneho bloku. Môže dočasne uložiť disk disk v hlavnej pamäti, ale vráti ho na disk, keď je hlavná pamäťová stránka potrebná pre iný blok. Stránky sa tiež vrátia na disk na žiadosť správcu transakcií.

"Žiadosť o" procesor - žiadosti o procesy a požiada o zmeny údajov alebo metaúdajov. Ponúka najlepší spôsob, ako vykonať potrebnú prevádzku a udáva príslušné príkazy správcovi pamäte.

Procesor (manažér) požiadaviek transformuje žiadosť alebo činnosť s databázami, ktoré možno vykonať na veľmi vysokej úrovni (napríklad vo forme žiadostiSql ), V poradí požiadaviek na uskladnené údaje typu jednotlivých nôh vzťahu alebo častí indexu na postoji. Často najťažšia časť spracovania požiadavka je to organizácia, t.j. voľbu dobra plán alebo postupnosť požiadaviek na pamäťový systém, ktorý je zodpovedný za požiadavku.

Manažér transakcií - zodpovedný za integritu systému a mala by zabezpečiť simultánne spracovanie mnohých požiadaviek, nedostatok zaťaženia žiadostí (dodatok, \\ tmin, max ) a ochrana údajov v prípade výstupu systému. Interaguje s manažérom požiadaviek, pretože by mali vedieť, aké údaje sú aktuálnymi požiadavkami (aby sa zabránilo konfliktným situáciám), a môžu odložiť niektoré požiadavky a operácie, aby sa zabránilo konfliktom. Správca transakcií tiež spolupracuje so správcom pamäte, pretože schémy ochrany údajov zvyčajne zahŕňajú ukladanie súboru zmien údajov. So správnym poradím vykonávania operačného súboru registrácia Bude obsahovať záznam o zmenách, takže môžete dokonca znovu vykonávať tieto zmeny, ktoré nedosiahli disk kvôli zlyhaniu v systéme.

Typické DBMS umožňuje užívateľovi zoskupiť viac požiadaviek a / alebo zmeny v jednej transakcii. Transakcia - Toto je skupina operácií, ktoré sa musia vykonávať postupne ako jeden.

Databázový systém spravidla podporuje viacero transakcií súčasne. Je to správne vykonávanie všetkých takýchto transakcií a poskytuje manažér transakcií. Zabezpečuje sa správna realizácia transakciíKyselina. -Seconditions (Atomicity, konzistencia, izolácia, trvanlivosť):

· atomitude - vykonávanie všetkých transakcií, alebo niektorý z nich (napríklad, stiahnutie peňazí z bankomatu a vhodný debet na účet klienta musí byť jedinou atómovou transakciou, nie je povolené vykonávať každú z týchto operácií samostatne);

· konzistencia - podmienka, v ktorej údaje spĺňajú všetky možné očakávania (napríklad podmienkou konzistencie pre databázu leteckej dopravy, nie je žiadny z miest v lietadle pre dvoch cestujúcich);

· izolácia- S paralelným vykonávaním dvoch alebo viacerých transakcií musia byť ich výsledky izolované od seba. Simultánne vykonávanie dvoch transakcií by nemal viesť k výsledku, ktorý by neboli vykonané postupne (napríklad pri predaji vstupenky na rovnaký let v prípade bezplatného posledného miesta so simultánnou požiadavkou pre dvoch agentov, dotazu musí byť dokončená iným - nie);

· dlhý termín - Po dokončení transakcie by sa výsledok nemal spustiť v prípade zlyhania systému, aj keď táto porucha nastane ihneď po ukončení transakcie.

Zvážte aj 3 typy prístupu k DBMS:

1. Vyšetrovanie - Otázky o údajoch môžu byť generované dvoma spôsobmi:

a)cez spoločné rozhranie dotazu (Napríklad relačné DBMS umožňuje požiadavkySql ktoré sa prenášajú do procesu dotazu, a tiež prijíma odpovede na ne);

b) použitie programové rozhrania - Žiadosti sa prenášajú prostredníctvom osobitného rozhrania (ľubovoľné požiadavky nemožno prenášať prostredníctvom tohto rozhrania);

2. Úpravy - Toto sú operácie na zmenu údajov. Môžu byť tiež vykonávané buď pomocou spoločného rozhrania alebo prostredníctvom rozhrania aplikačného programu;

3. Modifikácie schémy - Toto sú príkazy správcov príkazov, ktoré majú právo na zmenu systému DB alebo vytvoriť novú databázu.

Architektúra klienta / server. V mnohých verziách moderného softvéru sa implementuje architektúra klientsky server.: Jeden proces (klient) pošle požiadavku na vykonanie iného procesu (server). Databáza je spravidla rozdelená na serverový proces a niekoľko klientskych procesov.

V najjednoduchšej architektúre je klient / server všetky DBMS server, s výnimkou rozhraní požiadaviek, ktoré komunikujú s užívateľom a odosielať požiadavky alebo iné príkazy na server. Napríklad relačné DBMS často používa jazykSql Zobrazenie dotazov klienta k serveru. Databázový server potom poskytuje klientovi odpoveď vo forme tabuľky (vzťah). Existuje tendencia zvýšiť zaťaženie klienta, pretože ak existuje viac používateľov pracovných databáz so serverom, môžu vzniknúť problémy.

5. Model relačného dát.

RMD niektorých predmetových domény je súbor vzťahov, ktoré sa líšia v čase. Pri vytváraní informačného systému vám súbor vzťahov umožňuje ukladať údaje o objektoch oblasti predmetu a simulovať odkazy medzi nimi.

Postoj Je to dvojrozmerná tabuľka obsahujúca niektoré údaje. MatematickyN. -Odstňovateľný postoj R. Pochopte mnoho decrojských dielD 1 d 2 ... d n sady ( domény) D 1, D 2, ..., D N (), nie nevyhnutne odlišné:

R d 1 d 2 ... d n,

kde d 1 d 2 ... d n - Full Cartesovo prácu, t.j. Sada všetkých druhov kombináciín. Prvky, kde každý prvok prijíma ich doménu.

Doména - Toto je sémantická koncepcia. Doména je možné zobraziť ako podmnožina hodnôt niektorých typov údajov, ktoré majú určitý význam. Doména sa vyznačuje nasledujúcimi vlastnosťami:

· Doména jedinečný názov(v databáze).

· Doména je definovaná na niektorých jednoduchýtyp údajov alebo na inú doménu.

· Doména môže mať nejaké logický stavČo vám umožňuje opísať podmnožinu údajov povolených pre túto doménu.

· Domény sémantický záťaž.

Atribút vzťahov Existuje pár typu<Имя_атрибута: Имя_домена>. Názvy atribútov musia byť jedinečné vo vzťahu. Názvy atribútov sa často zhodujú s menami príslušných domén.

R. Definované na sade domén obsahuje dve časti: hlavička a telo.

Vzťah názvu - Toto je fixný počet atribútov vzťahu:

Názov vzťahu opisuje karteziánsky produkt domén, na ktorých je uvedený vzťah. Názov je statický, nezmení sa pri práci s databázou. Ak sú atribúty pridané alebo odstránené vo vzťahu k, v dôsledku toho už dostaneme inýpostoj (aj s predchádzajúcim menom).

Vzťahy na telo Obsahuje mnoho násobný vzťahy. Každý dužinami predstavuje mnoho párov typu<Имя_атрибута: Значение_атрибута>:

takáto hodnota atribútu patrí do domény. Vzťah tela je sada dcízde, t.j. Podskupina karteziánskej výroby domén. Telo samotného vzťahu je teda vzťah v matematickom zmysle slova. Vzťah tela sa môže zmeniť pri práci s databázou - Cortices sa môžu meniť, pridať a odstrániť.

Vzťah je zvyčajne napísaný vo formulári:

alebo kratšie

,

alebo jednoducho

Počet atribútov sa nazýva stupeň (alebo -arit ) vzťahy. Nazýva sa sila množstva nových moc vzťahy.

Schéma vzťahov Nazývaný zoznam názvov atribútov tohto vzťahu s doménou, na ktorú sa vzťahujú:

Ak atribúty berú hodnoty z tej istej domény, potom sa nazývajú lietadlom, kde pre túto doménu je veľa prípustných porovnaní. Ak napríklad doména obsahuje číselné údaje, všetky porovnávacie operácie sú pre neho povolené. A pre domény obsahujúce symbolické údaje však môžu byť špecifikované nielen porovnávacie operácie na rovnosť a nerovnosť hodnôt. Ak je pre túto doménu definovaná lexikografické objednanie, má tiež celý rad porovnávacích operácií.

Schémy dvoch vzťahov sa nazývajú ekvivalent Ak majú rovnaký stupeň a je možné zefektívniť názvy atribútov v schémach, že porovnateľné atribúty budú umiestnené na rovnakých miestach, to znamená, že atribúty, ktoré prijímajú hodnoty z jednej domény:

Byť - Schéma vzťahov. - Diagram vzťahu po objednaní názvov atribútov. Potom

~

Z hľadiska rovnocenných vzťahov sú teda splnené tieto podmienky: \\ t

· Tabuľky majú rovnaký počet stĺpcov.

· Tabuľky obsahujú stĺpce s rovnakými menami.

· Stĺpce s rovnakým názvom obsahujú údaje z tých istých domén.

· Tabuľky majú rovnaké riadky, pokiaľ ide o skutočnosť, že poradie stĺpcov sa môže líšiť.

Všetky takéto tabuľky majú odlišný snímkyrovnaký vzťah.

Vlastností vzťahov. Vlastnosti vzťahov sú priamo nasledované z vyššie uvedenej definície vzťahu. V týchto vlastnostiach existujú najmä rozdiely medzi vzťahmi a tabuľkami.

· Neexistujú žiadne identické tresle .

· Corgers nie sú objednané (zhora nadol) .

· Atribúty nie sú objednané (zľava doprava) .

· Všetky hodnoty atribútov .

Obr. Schematický obraz o vzťahu

Relačný model je to databáza vo forme množstva vzájomne prepojených vzťahov. V každom spojení môže jeden postoj pôsobiť ako hlavný a druhý postoj pôsobí ako podriadený. Jedným zloženým pozadím hlavného vzťahu môže byť spojený s niekoľkými kortičkami podriadeného vzťahu. Na podporu týchto spojení musia obidva vzťahy obsahovať súbory atribútov, pre ktoré sú pripojené. Väčšinou primárny kľúčový vzťah Určite určuje hlavný vzťah. Súbor atribútov musí byť prítomný v podriadenom postoji modelovej komunikácii, ktorá zodpovedá primárnemu kľúču hlavného vzťahu. Tento súbor atribútov je však už sekundárny kľúč alebo externý kľúč . Definuje mnoho nových vzťahov, ktoré sú spojené s jedinou vecnou nulou.

6. navrhovanie relačných databáz.

Pri navrhovaní relačnej databázy sa musia vyriešiť nasledujúce problémy:

1) Berúc do úvahy sémantiku oblasti predmetu je potrebné predložiť objekty oblasti predmetu vo forme abstraktného dátového modelu (dizajn datalog). Tí. - Rozhodnite sa v systéme databázy: Od akých vzťahov by mala byť databáza, ktorá by mala byť v týchto vzťahoch, aké sú prepojenia medzi vzťahmi.

2) Zabezpečte účinnosť databázových dotazov (fyzický dizajn databázy).

Po štádiu dizajnu datalog sa musí získať nasledujúci výsledok:

· Výstavba správneho dátového obvodu zameraného na model relačného dát.

· Opis databázovej schémy z hľadiska vybraných DBMS.

· Popis externých modelov z hľadiska vybraných DBMS.

· Opis deklaratívnych pravidiel na podporu integrity databázy.

· Vývoj podporných postupov pre sémantickú integritu databázy.

Úlohou navrhovania navrhovania relačnej databázy sa skladá z výberu základného diagramu z rôznych alternatívnych možností.

Správny Nazýva sa systém DB, v ktorej neexistujú žiadne nežiaduce závislosti medzi atribútmi vzťahov. Vývojový proces správnej schémy BD sa nazýva logický dizajn .

Navrhovanie databázového systému sa môže vykonávať dvoma metódami:

· Metóda rozkladu (oddiel) – počiatočný súbor vzťahov zahrnutých v databázovom systéme sa nahrádza iným súborom vzťahov, ktoré sú projekciami pôvodných vzťahov! V tomto prípade sa počet vzťahov zvyšuje.

· Metóda syntézy – usporiadanie schémy DB zo špecifikovaného zdroja základných závislostí medzi objektmi oblasti predmetu.

Klasický dizajn DB je spojený s teóriou normalizácia ktorý je založený na analýze funkčných závislostí medzi atribútmi vzťahov. Funkčné závislosti určujú stabilný vzťah medzi objektmi a ich vlastnosťami v posudzovanej oblasti.

Metóda rozkladu je proces konzistentnej normalizácie systémov vzťahov: Každá nová iterácia zodpovedá normálnej forme vyššej objednávky a má najlepšie vlastnosti v porovnaní s predchádzajúcim. Očakáva sa preto, že sa očakáva existencia univerzálneho vzťahu obsahujúceho všetky atribúty databázy, potom na základe analýzy atribútov medzi atribútmi (alebo sa vykoná pokus) univerzálny vzťah rozklad, t.j. Prechod na niekoľko ohľadov menšieho rozmeru a počiatočný vzťah sa musia izolovať pomocou prirodzenej prevádzky pripojenia.

Každá normálna forma zodpovedá určitému množstvu obmedzení, a vzťah je v určitom normálnom formulári, ak spĺňa obmedzenia, ktoré je pre neho charakteristické.

Teória relačných databáz zvyčajne prideľujú tieto normálne formuláre:

prvý normálny formulár (1)Nf);

· druhá normálna forma (2Nf);

· tretia normálna forma (3Nf);

· normálny formulár CODD BAIBcnf);

· Štvrtý normálny tvar (4Nf);

· piata normálna forma alebo forma projekcie - zlúčeniny (5Nf alebo pynf).

Hlavné vlastnosti normálnych foriem:

· každá ďalšia normálna forma v zmysle je lepšia ako predchádzajúca;

· pri prechode na nasledujúcu normálnu formu sa uložia vlastnosti predchádzajúcich normálnych vlastností.

Systémy BD sa nazývajú ekvivalentAk sa obsah počiatočnej databázy môže získať prirodzeným pripojením vzťahov zahrnutých v výslednom okruhu a nové no sa objavujú v pôvodnej databáze.

7. Normálne formy vzťahov.

Proces normalizácie je založený na primeranej odraze predmetnej oblasti vo forme tabuliek obsahujúcich informácie o simulovanom objekte a schopnosť zmeniť databázový stav v čase. Z dôvodu nekonzistentnosti modelu modelu modelu sa môžu vyskytnúť abnormality, ktoré sa prejavujú pri vykonávaní príslušných operácií:

· Vložte anomálie (vložka) - Skladovanie v jednom ohľade heterogénnych informácií.

· Aktualizovať anomálie (aktualizácia) -Full dátový vzťah v dôsledku skladovania heterogénnych.

· Odstrániť anomálie (odstrániť) - skladovanie heterogénnych informácií v jednom ohľade.

Mali by ste tiež zvážiť vznikajúce nedefinované ( NULOVÝ) Hodnoty. V rôznych DBMS pri vykonávaní rôznych operácií (porovnanie, združovanie, triedenie, zoskupenie atď.)NULOVÝ -Notions sa môžu alebo nebudú rovnaké, rôznymi spôsobmi ovplyvniť výsledok výkonu operácií na určenie priemerných hodnôt a nájsť počet hodnôt. Ak chcete vylúčiť chyby v mnohých DBMS, je náhradaNULOVÝ -Notion nula pri vykonávaní výpočtov, oznámenie všetkýchNULOVÝ -Notion sa rovná sebe navzájom, atď.

Normalizácia - Rozdelenie tabuľky do niekoľkých, ktoré majú najlepšie vlastnosti pri aktualizácii, vloží a vymazanie údajov. Tí. Normalizácia je proces konzistentnej výmeny stola s kompletnými rozkladmi, až kým nie sú všetky z nich v 5 nf, avšak v praxi stačí, aby sa tabuľka na NFBC.

Normalizačný postup je založený na skutočnosti, že jediná funkčná závislosť v akomkoľvek tabuľke by mala byť závislosť druhov, kde primárny kľúč a niektoré iné pole. Preto v procese normalizácie by ste sa mali zbaviť všetkých "iných" funkčných závislostí, t.j. od tých, ktorí majú iný vzhľad ako.

Ak nahradíte primárne (externé) kľúče v čase normalizácie, mali by sa zvážiť 2 prípady:

1. Tabuľka má napríklad zložený primárny kľúč, napríklad pole, ktoré funkčne závisí od časti tohto tlačidla, napríklad z (nezávisí od plného kľúča). Odporúča sa vytvoriť inú tabuľku obsahujúcu a (- primárny kľúč) a odstrániť z pôvodnej tabuľky:

Nahradiť, primárny kľúč, fz

na, primárny kľúč

a primárny kľúč.

2. Tabuľka má primárny (možný) kľúč, pole, ktoré nie je možným kľúčom, ale funkčne závisí od, ako aj ostatné nezmyselné pole, ktoré je funkčne závislé na :. \\ T Odporúča sa vytvoriť tabuľku obsahujúcu a (- primárny kľúč) a - odstrániť z pôvodnej tabuľky: Treba poznamenať, že pri vykonávaní takýchto operácií by malo byť spočiatku mať niektoré "veľké" (univerzálne) vzťahy.

Opp.1. Postoj je B. prvá normálna forma (1NF) potom a len vtedy, keď žiadny z jeho riadkov neobsahuje jednu hodnotu v ľubovoľnom poli jednej hodnoty a žiadna z kľúčových polí nie je prázdna.

Podľa OPP.1 bude akýkoľvek postoj v 1NF, t.j. Pomer spĺňajúci vlastnosti vzťahov: neexistujú žiadne identické tresle, pokiaľ ide o to isté; Corgers nie sú objednané; Atribúty nie sú objednané a mení sa podľa mena; Všetky hodnoty atribútov sú atómové.

OPR.2. Postoj je v druhá normálna forma (2NF) potom a len vtedy, ak je pomer v 1NF a v závislosti od časti komplexného tlačidla (tj všetky polia, ktoré nie sú zahrnuté v primárnom kľúči, sú spojené s plnou funkčnou závislosťou s primárnym kľúčom) .

Ak je potenciálny kľúč jednoduchý, potom sa vzťah automaticky nachádza v 2NF.

Ak chcete odstrániť závislosť atribútov z časti komplexného kľúča, musíte vyrábať rozklad vzťahy do niekoľkých vzťahov. Atribúty, ktoré závisia od časti komplexného kľúča, sú vyrobené v samostatnom postoji.

Atribúty sa nazývajú vzájomne nezávislý Ak nie je žiadny z nich funkčne závislý na strane druhej.

Opp.3. Postoj je B. tretia normálna uniforma (3NF) Potom a len vtedy, ak je postoj v 2NF a všetky non-selekčné atribúty sú vzájomne nezávislé (tj žiadny z neebestých polí závisí od funkčne z akéhokoľvek iného neselektívneho poľa).

Na odstránenie závislosti nexianových atribútov je potrebné rozkladať vzťah k niekoľkým vzťahoch. Súčasne sú tieto atribúty, ktoré sú závislé, sú vyrobené v samostatnom postoji.

Keď vzťahy s pomocou normalizačného algoritmu na 3 NFF vzťah, predpokladá sa, že všetky vzťahy obsahujú jeden potenciálny kľúč. Nie je to vždy pravda. Existujú prípady, keď vzťah môže obsahovať viacero kľúčov.

OPR.4. Postoj je B. normálny formulár BAI CODD (NFBC) Potom a len ak sú determinanty všetkých funkčných závislostí potenciálnymi kľúčmi (buď - ak sa každá funkčná závislosť medzi jeho palenty zníži na kompletnú funkčnú závislosť na možnom kľúči).

Ak je postoj v NFBC, je automaticky v 3 NFF, ktorý vyplýva z definície 4. Ak chcete odstrániť závislosť od determinantov, ktoré nie sú potenciálnymi kľúčmi, je potrebné vykonať rozklad, pričom tieto determinanty a časti závislé od nich v samostatnom postoji.

Existujú prípady, keď pomer neobsahuje žiadne funkčné závislosti. Tí. Pomer je úplne kľúčový, t.j. Vzťahový kľúč je všetky mnohé atribúty. Takže máme viaccennú závislosť, pretože Vzťah medzi atribútmi je stále k dispozícii.

OPR.5. Postoj je B. štvrtý normálny formulár (4NF) potom a len vtedy, ak je postoj v NFBC a neobsahuje ne-triviálne viacnásobné závislosti.

Vzťahy s non-triviálnymi viaccennými závislosťami vznikajú spravidla v dôsledku prirodzeného spojenia dvoch vzťahov na spoločnej oblasti, ktorá nie je kľúčová v žiadnom zo vzťahov. Naozaj vedie k ukladaniu v jednom rešpektovaní informácií o dvoch nezávislých subjektoch.

Na odstránenie netriviálnych viacvalových závislostí je možné rozkladať počiatočný vzťah do niekoľkých nových.

OPR.6. Postoj je B. piata normálna forma (5NF) Potom a len ak je akékoľvek dostupné pripojenie triviálne.

OPR.6. Identifikuje aj definíciu.

OPR.7. Pomer nie je v 5 nf, ak existuje ne-triviálna závislosť zlúčeniny.

Tak Ak v každom kompletnom rozklade obsahujú všetky prognózy zdrojového vzťahu možný kľúč, možno konštatovať, že pomer je v 5 nf. Pomer, ktorý nemá žiadny úplný rozklad, je tiež v 5 nf.

Nepoznám nič o tom, aké potenciálne kľúče sú vo vzťahu k a ako atribúty sú vzájomne prepojené, nemožno tvrdiť, že tento postoj je v 5 NFF alebo v iných normálnych formách.

Možný kľúč Vzťah sa nazýva súbor atribútov vzťahu, ktorý je úplne a jednoznačný (funkčne) určí hodnoty všetkých ostatných atribútov vzťahu. Vo všeobecnom prípade môže existovať niekoľko možných kľúčov. Zo všetkých možných kľúčov je vzťah zvyčajne vybraný jedným, ktorý je považovaný za hlavný a ktorý sa nazýva primárny kľúčový vzťah.

Vzájomné nezávislé atribúty – ide o atribúty, ktoré nezávisia od jedného z druhých. Ak existuje niekoľko FZ, každý atribút alebo súbor atribútov, na ktorých závisí iný atribút, sa nazýva determinantom vzťahu.

9. Relačná algebra.

Relačný algebra je základom pre prístup k relačným údajom. Hlavným účelom algebry je poskytnúť výrazy. Výrazy môžu byť použité pre:

· definície regiónu vzorky. Definície údajov za ich výber, ako výsledok operácie odberu vzoriek;

· definície regiónu aktualizácie. Definície údajov pre ich zasunutie, zmenu alebo odstránenie, ako výsledok operácie aktualizácie;

· definícia (pomenované) virtuálne vzťahy. Prezentačné údaje pre vizualizáciu prostredníctvom predloženia;

· popis obrázku, t.j. Definovanie údajov na uloženie vo forme vzťahu "okamžitého obrázku";

· definícia bezpečnostných pravidiel, t.j. Určenie údajov, pre ktoré sa vykonáva kontrola prístupu;

· stanovenie požiadaviek na stabilitu, t.j. Definovanie údajov, ktoré sú zahrnuté v oblasti pre niektoré súčasné operácie riadenia prístupu;

· definícia pravidiel integrity, t.j. Niektoré z niektorých osobitných pravidiel, ktoré by mali spĺňať databázu spolu so všeobecnými pravidlami, ktoré predstavujú časť relačného modelu a aplikuje sa na každú databázu.

V implementáciách špecifických relačných DBMS, ani relačná algebra ani relačný kalkul sa nepoužíva vo svojej čistej forme. Skutočným štandardom prístupu k relačným údajom bol jazyk SQL (štruktúrovaný jazyk dotazu).

Relačná algebra definovaná kódom sa skladá z 8 operátorov, ktorí tvoria 2 skupiny:

• tradičné sady na súpravy (združenie, križovatka, odčítanie, karteziánske práce);
• Špeciálne relačné operácie (vzorka, projekcia, pripojenie, rozdelenie).

Okrem toho je algebra zaradený do operácie priradenia, ktorý vám umožní uložiť výsledky výpočtu algebraických výrazov v databáze a premenovanie prevádzky atribútov, čo umožňuje správne vytvárať hlavičku (diagram) výsledného pomeru .

Stručný prehľad o prevádzkovateľoch relačnej algebry.

Vzorka– vracia vzťah, ktorý obsahuje všetky cortices určitého vzťahu, ktorý spĺňa určité podmienky. Prevádzka vzorky je tiež obmedzovacia operácia (obmedziť. - Limit, teraz sa vzorka prijíma častejšie -Vyberte).

Premietanie– vracia postoj obsahujúci všetky cortices (t.j. pod corterates) určitého vzťahu po vylúčení niektorých atribútov z neho.

Zloženie– vracia vzťah obsahujúci všetky druhy kortices, ktoré sú kombináciou dvoch tresiek, ktoré patria do dvoch špecifických vzťahov.

Združenie– vracia pomer obsahujúci všetky cortices, ktoré patria alebo jeden z dvoch určitých vzťahov, alebo oboje.

Priesečník -vracia vzťah, ktorý obsahuje všetky cortices, ktoré patria do oboch dvoch špecifických vzťahov súčasne.

Odčítanie -vráti postoj obsahujúci všetky cortices, ktoré patria do prvých dvoch určitých vzťahov a nepatria do druhej.

Pripojenie (Prírodné) - vráti vzťah, ktorý je kombináciou dvoch TVPles (vo vlastníctve dvoch špecifických vzťahov), ktorý má spoločnú hodnotu pre jeden alebo viac spoločných atribútov týchto dvoch vzťahov (a takýchto spoločných hodnôt vo výslednom TUCT sa objavujú len raz a nie dvakrát).

Divízia - Pre dva vzťahy, binárne a ponúkne, vracia pomer obsahujúci všetky hodnoty jedného atribútu binárneho vzťahu, ktorý zodpovedá (v inom atribúte) všetkým hodnotám v Unline Attitude.

Literatúra

1. Dátum K.J. Úvod do databázových systémov, 6. vydanie: za. z angličtiny - K.; M.; SPB.: Vydavateľstvo "Williams", 2000. - 848 p.

2. Connoli T., Begg K., Strnk A. Databázy: Návrh, implementácia a podpora. Teória a prax, 2. ed.: Per. z angličtiny - M.: Vydavateľstvo "Williams", 2000. - 1120 s.

3. KARPOVA TS Databázy: modely, vývoj, implementácia. - SPB.: Peter, 2001. - 304 p.

4. Faronov V.V., Shumakov P.V. Delphi 4. Riadenie developer databázy. - m.: "Nolide", 1999. - 560 p.

5. J. GROFF, P.VAINBERG. SQL: Plná príručka: za. z angličtiny - K.: Vydavateľská skupina BHV, 2001. - 816 p.

6. Ken Getz, Paul Litvin, Mike Gilbert. Prístup 2000. Developer sprievodca. T.1, 2. PER. z angličtiny - K.: Vydavateľská skupina BHV, 2000. - 1264 C, 912 C.

7. MAKLAS S.V BPWIN A EPWIN. Prípadové nástroje pre rozvoj informačných systémov. - M.: DIALOG MAFI, 2001. - 304 p.

8. ULMAN D., UID D. Úvod do databázy / trans systému. z angličtiny - M.: Lori, 2000. - 374 p.

9. Khomonenko A.D., Tsygankov V.M., Maltsev M.G. Databázy: Návod pre vyššie vzdelávacie inštitúcie / ed. Prof. A.d.homonenko. - SPB.: Korunková tlač, 2000. - 416 p.

Pri použití špirálového modelu:

- existuje akumulácia a opätovné použitie dizajnových riešení, návrhov, modelov a prototypov informačného systému a informačných technológií;

- orientácia sa vykonáva na vývoji a modifikácii systému a technológie v procese ich dizajnu;

- analýza rizika sa vykonáva a náklady v procese navrhovania systémov a technológií.

2.3.2. Koncepčný návrh

Koncepcia informačného systému

V predchádzajúcej časti bola ukázaná (obr. 2.3.2), že pracovné a finančné náklady sa postupne zvyšujú v prvej dvoch fázach životného cyklu a prudko zvýšenie fázy praktickej implementácie informačného systému. Medzitým, chyby vyrobené v prvých dvoch fázach generujú ťažké, často intraktívne problémy, a môžu tiež vážne ovplyvniť náklady, pracovný plán a nakoniec výsledky práce ako celku. Vzhľadom na uvedené dôvody uvedené nižšie existujú dôvody na ich pridelenie do nezávislého a špecifického typu činnosti - koncepčný návrh informačných systémov. Výsledok koncepčného dizajnu je koncepcia informačného systémuPod ktorým budeme rozumieme systémovo vzájomne prepojený súbor konštrukčných riešení TI S t, ktorý implementuje požadovanú kvalitu informačnej podpory.

Slovne zadaná koncepcia môže byť opísaná nasledovne: Podstatou tejto koncepcie je pôvodný, objektívny, nestranný a vyčerpávajúci prístup. Východiskovým bodom koncepcie by mal slúžiť ako konečné produkty alebo požiadavky na prevádzku. Na tomto základe by mala byť celková štruktúra "ideálneho systému" určená s minimálnym účtom prevládajúcich vlastností spoločnosti alebo akúkoľvek organizáciu použitých metód a zariadení. Konečným cieľom je vydať optimálne informácie, ktoré zabezpečujú optimálnu kombináciu ľudí a vybavenia, vykonávať tieto funkcie, ktoré môžu byť najlepším možným spôsobom, resp. Osoba, ktorá využíva zariadenie na najúčinnejšiu úlohu.

Koncept koncepčného dizajnu by sa mal určiť takým spôsobom, že dizajnér je všetky počiatočné údaje založené na ich vedomostiach, skúsenosti a intuície by mohli byť prevedené na extrémne formalizované súkromné \u200b\u200búlohy pre dizajn, vrátane úlohy na navrhovanie štruktúry objektu.

Definujeme úlohu koncepčného dizajnu prostredníctvom svojich komponentov.

Objekt koncepčného dizajnu je súčasný stav informačného systému

Sc \u003d (sc		S c)
kde S C je stav existujúceho informačného systému, s C				S.

v súlade s tým, organizačné a technické, funkčné a informačné štrukturálne riešenia.

Koncepčný dizajn predmet . Podľa všeobecne prijatých

terminológia Technická literatúra Predmet koncepčného dizajnu by sa mal nazývať "Developer" alebo "Designer". Zdá sa však, že tieto podmienky najlepšie odrážajú obsah podrobného (fyzického) dizajnu. Pokiaľ ide o rozvoj koncepcie informačných systémov, moderný termín "systémový integrátor" je atraktívnejší.

Systém koncepcie dizajnu. Hlavným cieľom

povinný dizajn môže byť formulovaný takto: Stanovenie súboru štátov informačného systému s t,

kvalita kvality kvality súvisiacej s kvalitou súvisiacou s kvalitou.

Koncepčný dizajn informačných systémov je viacúčelové (hodnotenie a porovnanie jednotlivých cieľov v jednotných univerzálnych jednotkách nemožné). Preto účel koncepčného dizajnu predstaví vektor

				S ti \u003d (s ti	S ti.	S ti.
		; \\ T S ti.		- Bol som sľubným rozhodnutím:
kde s ti	; \\ T S ti.

- organizačné a technické (cieľový stav organizačných a technických štruktúr);

- procedurálny (cieľový stav procesnej štruktúry);

- informácie (cieľový stav informačnej štruktúry).Praktická činnosť. Na dosiahnutie cieľov koncepčného

extrakcia Systémový integrátor musí vykonávať niekoľko systémovo vzájomne prepojených prác zameraných na zlepšenie organizačnej a technickej štruktúry, štruktúry informačných procesov a informačných štruktúr. Označujú tieto druhy práce:

W i o \u003d (w i o) - práca zameraná na zlepšenie organizačnej a technickej štruktúry pre štáty TI;

W i p \u003d (w i p) - práca zameraná na zlepšenie funkčnej štruktúry pre štáty Ti P;

W i \u003d (w i i) - práca zameraná na zlepšenie informačnej štruktúry pre štáty Ti I.

Úlohu koncepčného dizajnu informačných systémov.

Štruktúra koncepcie koncepčného dizajnu a formalizácie jej hlavných zložiek nám umožňuje formulovať v organizačných podmienkach úlohy koncepčného dizajnu informačných systémov:

V vyjadrení (3.8) S T - súbor cieľa v zmysle vyjadrenia štátu informačného systému, koncept koncepčného dizajnu. Za-

tieto termíny s * zahŕňajú vektor aktuálneho stavu informačného systému a mnoho prípustných operátorov, ktoré preložili informácie

systému z existujúceho stavu. Preto formálne úloha koncepčného dizajnu informačných systémov môže byť zastúpená trojnásobkom:

< S с ,W ,S t >.

Podobné podanie definuje koncepčný návrh informačných systémov ako proces nastavenia a riešenia problému (3.9).

Moderné prístupy k koncepčnému dizajnu informačných systémov

Problém koncepčného dizajnu informačných systémov: Stav a riešenia

V súčasnosti najčastejšie takzvaný prehľadávať prístupna zlepšenie informačnej podpory. Podstatou pozitívneho prístupu spočíva v heuristickej analýze objektívnych činností vo všeobecnosti alebo na jednej z úloh organizácie, na základe ktorých sú vyčlenené samostatné informačné postupy, ktoré spĺňajú dva podmienky: \\ t

- podpora nízkej kvality;

- možnosť zlepšenia vytvorením a implementáciou technických zariadení, automatizácie alebo Organizačné a právne rozhodnutia.

Existujúce a sľubné technické a organizačné riešenia získané v dôsledku opísaného prístupu umožňujú udržiavať na určitej úrovni a zlepšiť informačnú podporu organizácií. Z dôvodu objektívnych dôvodov však tento prístup má tak veľa vyčerpaný.

Od polovice 20. storočia sa v navrhovaní informačných systémov objavil všeobecný trend - veľké a komplexné informačné systémy sa stali objektmi dizajnu. To viedlo k prudkému zvýšeniu vysokej kvality a priemernej zložitosti projektov.

Preto sa v dizajne veľkých systémov začala sledovať nefunkčnosť prístupov s nedostatočne rozvinutými alebo slabo vyvinutými fázami koncepčného dizajnu. Externe sa to prejavuje v vzniku objektívnych ťažkostí od manažérov organizácií a technických služieb, ktoré rozhodujú v priebehu celého komplexu otázok zlepšenia informačnej podpory. Tieto ťažkosti sú spôsobené skutočnosťou, že existujúce prístupy výslovne neposkytujú odpoveď o potrebe a dostatočnosti zlepšenia informačnej podpory vrátane: \\ t

- racionálne (formálne) kritériá a metódy hodnotenia existujúcej kvality a požiadaviek na kvalitu podpory potenciálnych informácií;

- zoznam prioritných úloh činností organizácií, ktorých informačné procesy možno zlepšiť na základe štrukturálnych riešení;

- zLEPŠOVANÁ SAŤ POTREBOVACÍ

- pomer organizačných, technických, funkčných a informačných riešení;

- potrebné finančné, technické a iné zdroje;

- lehoty na projektové práce;

- regulačný rámec potrebný na organizovanie informačnej podpory na základe nových konštrukčných riešení.

Okrem toho, pre väčšinu organizácií organizácií existuje nedostatok skúseností s organizovaním veľkých projektov všeobecne a navyše, v trhových podmienkach, ak je to potrebné:

- konjunktúra na štúdium;

- identifikujte skutočné ciele projektov

- nájdite si požadované finančné a iné zdroje, interprety atď. Okrem toho, kvôli novinke predmetnej oblasti, absencia

celá a testovaná metodika, ktorá nám umožňuje zvážiť proces koncepcie komplexne, so systémovými pozíciami, problémy so zlepšovaním, modernizáciou alebo vytváraním informačných systémov vznikajú a pred vývojármi tretích strán v prípade, že ich prinášajú navrhnúť. To sťažuje zlepšenie informačnej podpory, pretože vývojár musí nielen vybrať alebo vytvoriť technické prostriedky, ale aj na riešenie cieľov oblasti predmetu, úlohy spojené s vedecky rozumnou výstavbou štruktúry, berú do úvahy Požiadavky na inžiniersku psychológiu a ergonómiu, systémové požiadavky atď.

Vyššie uvedený zoznam najnaspešnejších problémov naznačuje, že v súčasnosti existujú koncepčné riešenia na zlepšenie informačnej podpory v podmienkach neistoty založených na Eurystik. Ako viete, heuristické metódy sú založené na neformálnych intuitívnych úvahách o skúsenostiach riešenia podobných alebo podobných úloh vrátane iných ľudí. Nespĺňajú aj podmienky výkonu.

Existuje empiricky zavedený vzťah medzi stupeňou realizácie súčasného štátu, ako aj moderné technické a organizačné schopnosti zlepšenia informačnej podpory a objem heuristických postupov.

Ďalším skrytým faktorom negatívnym ovplyvňujúcim výsledky projektu je aróda tradičného manažérskeho cyklu, ktorá je hlavnou nevýhodou, ktorá je základom spätnej väzby (regulácia). Kontrola výsledkov projektu sa vykonáva v skutočnosti po fyzickej realizácii informačného systému založeného na subjektívnom hodnotení ("dobré", \\ t

"Zlá") Stav informačnej podpory. Postup pri prispôsobovaní technickej úlohy prakticky neodhalí a neupravuje heuristické chyby vykonané v predchádzajúcich štádiách a je v určitom rozsahu formálne.

Existujúca situácia v oblasti zlepšovania informačnej podpory organizácií teda neumožňuje prijať triviálne riešenia s garantovaným úspechom cieľa. Preto sa práca v tomto smere vykonávajú spontánne a nie vždy účinne. V dôsledku toho vedie nielen k porušeniu podmienok vykonávania projektov, nadprúdových fondov, nedodržania požiadaviek konečného výsledku, ale aj vzniku nadmerných a často nezlučiteľných informačných systémov v organizáciách s výraznými negatívnymi vlastnosťami : Duplikácia, nedostatok integrity a konzistencie, zníženie dostupnosti informácií, ťažkosti jeho integrácie.

Vlastnosti problému a podmienky koncepčného dizajnu informačných systémov

Z vyššie uvedeného vyplýva, že zvážené prístupy k koncepčnému dizajnu informačných systémov neumožňujú systematicky zohľadniť osobitosti podstaty a súčasného stavu problému zlepšenia informačnej podpory, ako aj špecifiká. \\ T činnosti organizácií. Nižšie je systematický zoznam funkcií problému koncepčného dizajnu informačných systémov.

Vyčleniť nasledujúcefunkcie definované podstatou problému zlepšenia podpory informácií.

1. Rastúce požiadavky a zvýšenie spôsobilosti používateľa.

2. Vlastná komplexnosť konečných výsledkov projektových aktivít (projektov).

3. Multi-termín problém v prítomnosti rôznych, často nekonzistentných ukazovateľov hodnotenia kvality podpory informácií. Zdá sa, že je prípustné hovoriť o absencii systému formulovaných, vzájomne prepojených ukazovateľov kvality, ako aj požiadaviek na regióny ich platných hodnôt.

4. Potreba vykonávať objektívne činnosti, a preto informačná podpora v oblasti neistoty cieľov a rizika.

5. Potreba nepretržitého riešenia problému zlepšenia informačnej podpory.

6. Potreba aktívnej účasti na projektoch projektov v dôsledku skutočnosti, že tieto sú dopravcovia objektívnych vedomostí a koncových užívateľov systému.

7. Nedostatok formálnych riešení riešení.

Funkcie definované aktuálnym stavom problému.

1. Nedostatok systému rozvoja systému ("Riešenia fragment"). K dnešnému dňu je rozvoj vedeckej a metodickej základne zlepšenia informačnej podpory v počiatočnej fáze.

Systémové aspekty nie sú hlboko vyvinuté, slabo implementované: kontrola a plánovanie procesov zlepšenia informačnej podpory na zemi; Koordinácia technických konceptov a návrhov; Riadenie kvality informačnej podpory; Analýza existujúceho a vývoja novej organizácie informačnej podpory a ďalších.

2. Nestabilitu ekonomickej situácie, variabilita právnych predpisov a politík v oblasti hospodárskej činnosti. V dôsledku toho sa riziko investičných projektov stáva vysokým rizikom cien a predpovedaním nákladov na projekt.

3. Trvalo existujúca organizačná reštrukturalizácia.

4. Dynamika informačných technológií definovaných výsledkami Vedecký a technický pokrok.

4. Plánovacie a cenové chyby.

5. Nedostatočná zložitosť problému je organizácia práce na zemi. Počet a kvalita popredných materiálov zaslaných na miesta nezodpovedá zložitosti a relevantnosti problému.

6. Obmedzené financovanie práce.

7. Prítomnosť existujúcich informačných technológií, jedným alebo inými poskytovaním informačných potrieb organizácií.

Funkcie definované štruktúrou a objektívnymi činnosťami organizácií . Vykonáva sa zlepšenie informačnej podpory

v osobitné podmienky: Hierarchia, územné rozdelenie organizačnej štruktúry a činností; Multitasking objektívnej činnosti; Dynamika organizačnej štruktúry, podmienky prevádzky a riešených úloh.

Organizácie pozostávajú z divízií špecializujúcich sa na jednotlivé funkcie alebo úlohy. Zdá sa, že je to prirodzené, pretože to vedie

na zjednodušte organizačnú štruktúru a využívanie zamestnancov jednej špeciality. Takéto funkčné jednotky zabezpečujú vysokú efektívnosť objektívnej činnosti, ale zároveň sa vyznačujú určitými vlastnosťami, ktoré sú reštriktívnym faktorom v dizajne informačných systémov: \\ t

1. Neschopnosť funkčných jednotiek organizovať efektívnu spoluprácu a koordináciu s inými funkčnými jednotkami, dodávateľom projektu, organizáciami tretích strán. V niektorých prípadoch manažéri funkčných jednotiek nepoznajú alebo nedostatočne predstavujú a neberú do úvahy ciele celého projektu. Často to, čo sa zdá byť užitočným funkčným lídrom pre svoje rozdelenie, nie je zaujímavé alebo dokonca škodlivé pre inú jednotku alebo vo všeobecnosti pre organizáciu.

2. Inherentné na hlavnej rivalitu medzi funkčnou jednotnosťou metód vytvárania stroja.

3. Zodpovednosť za vzťahy a koordinácia môže byť fuzzy alebo neistá Kvôli paralelom alebo zneužitiu povinností. To spomaľuje a komplikuje rozhodovací proces a má negatívny vplyv na celý projekt.

4. Vzhľadom na významné veľkosti a organizačnej zložitosti je riadenie organizácie alebo divízií pomerne ťažké zaplatiť potrebnú pozornosť aktuálnym problémom s projektom. Vážne a často definujúci faktor je prirodzený pre manažérov nekompetentnosť v tejto oblasti.

Špecifiká predmetovej činnosti určujú špecifiká podpory informácií: kolektívne využívanie geograficky distribuovaných informačných zdrojov; diskrétnosť, nesúlad, stochasticita tečúcich informačných procesov; vysoké nároky na kvalitu všetkých postupov informačného procesu; nedostatok priori informácie o vlastnostiach informačných procesov, veľkým objemom a rôznorodosťou spracúvaných informácií, zložitosť informačných vzťahov; Prísne organizačné a právne stanovenie informačných procesov a rad ďalších faktorov. Existujú rôzne a často protichodné informačné potreby používateľov.

Podmienky koncepčného dizajnu . Súbor prezentovaných funkcií zlepšenia informačnej podpory určuje množstvo podmienok, v prípade, ktoré v životnom cykle projektu musí existovať rozvinutá fáza koncepčného dizajnu:

1. Informačný systém je veľký a náročný. Projekt je systém pozostávajúci z podsystémov, ktoré musia byť kombinované do jedného funkčne spojeného celého.

2. Projekt je technicky ťažké.

3. Potreba finančnej kontroly vo všetkých fázach projektu.

4. Prítomnosť obmedzení v odhadoch a grafoch kalendára.

5. Potreba rýchlej reakcie na zmeny v podmienkach projektu.

6. Prispôsobenie veľkého počtu funkčných jednotiek do projektu

a pokrytie významného počtu typov práce.

7. Možnosť zásadných zmien organizačnej štruktúry.

8. Potreba veľkej obstarávania a dodávky materiálov, vybavenia, služieb.

rýchlo

vážny

Technický

v odhade I.

pýšenie

pozmeňujúce a doplňujúce návrhy

komplexnosť

kalendár

negatívny

na meranie

v štruktúre

vplyvy

podmienka

Podmienky projektu nevyhnutnosti

Koncepčný návrh

Obr. 2.3.3. Podmienky potreby koncepčného dizajnu

Na základe okolností (súčasný stav a charakteristiky problému koncepčného dizajnu) sa zrejmé, že ďalšie využívanie všeobecne uznávaných prístupov k koncepčnému dizajnu sa stáva jedným z dôvodov čoraz významného zníženia kvality podpory informácií.

Preto osoba, ktorá rozhoduje o účele zlepšenia informačnej podpory a spôsoby, ako dosiahnuť tieto ciele, súbor jasných, homogénnych a vzájomne prepojených metód a nástrojov, ktoré by použili, ktoré by správne identifikovali ciele zlepšenia informačnej podpory a Dosiahnite ich.

Inými slovami, je potrebná špeciálna koncepčná technológia dizajnu, ktorá spĺňa tieto požiadavky:

- integrita a systémová hodnota procesu, ktorú vykonáva táto technológia, ktorá by mala obsahovať funkčne úplný súbor komponentov "technologického reťazca";

- vysoký stupeň presnosti odstraňovania procesu v štádiu (postupoch), ktorý otvára možnosť jej technológie;

- pravidelnosť procesu a neamunty väčšiny etáp, čo umožňuje uplatňovať podľa ich opisu zákonov veľkých počtov a priemerných hodnôt;

- v dôsledku toho sa na jednej strane objavuje možnosť ich štandardizácie a zjednotenia, a na strane druhej, plánovania, účtovníctva a organizácie.

Jedna z architektúr BD sa nazýva ANSI / SPARC.

Hlavnou myšlienkou je zvýrazniť trojnásobné abstrakcie v popise údajov. Účel - Oddelenie užívateľského zastúpenia databázy z jeho fyzického reprezentácie.

Dôvody, pre ktoré je takéto oddelenie žiaduce:

Každý užívateľ musí mať prístup k všeobecným údajom pomocou svojej vlastnej myšlienky;

Užívatelia by sa nemali zaoberať podrobnosťami o údajoch o fyzických ukladaniach;

Administrátor databázy musí byť schopný zmeniť štruktúru databázy bez ovplyvnenia prezentácie používateľov;

Vnútorná štruktúra databázy by nemala závisieť od zmien vo fyzických aspektoch uskladnenia informácií, ako je napríklad prepnutie na nové zariadenie atď.;

Rozlišujú sa tri úrovne architektúry databázy - externé, koncepčné a interné.

Externá úroveň - Zastúpenie databázy z hľadiska používateľov pozostáva z niekoľkých externých zastúpení, zvyčajne relevantných skupín používateľov. Rôzne zobrazenia sa môžu líšiť na rovnaké údaje, môžu tiež obsahovať vypočítané údaje, ktoré nie sú uložené v databáze.

Koncepčná úroveň - všeobecné zastúpenie databázového systému. Úroveň opisuje, aké údaje sú uložené v databáze a ktoré odkazy sú uložené medzi nimi. Koncepčný systém - Toto je úplná prezentácia požiadaviek na údaje z organizácie, nezávisí od metódy ukladania údajov. Koncepčná úroveň predstavuje nasledujúce komponenty:

1. Všetky dátové prvky.

2. Obmedzenia uložené na dátové prvky.

3. Informácie o sémantických údajov.

4. Informácie o bezpečnostných opatreniach a podpora integrity údajov.

Vnútorná úroveň - popisuje implementáciu databázy a je určená na zabezpečenie optimálneho výkonu systému a ekonomického využívania svojich zdrojov, pričom sa zohľadnia konkrétne DBMS.

Vnútorná úroveň zodpovedá nasledujúcim informáciám:

1. Opis ukladacích detailov označujúcich skutočnú veľkosť uložených prvkov.

2. Distribúcia miesta na disku pre ukladanie a indexy údajov.

3. Informácie o fyzickej organizácii údajov.

4. Informácie o kompresii metód údajov a šifrovania.

Pod vnútornou úrovňou leží fyzickýktorý je kontrolovaný operačným systémom podľa usmernení DBMS, ich funkcie na tejto úrovni nie sú jasne rozdelené.

Dva prístupy k koncepčnému dizajnu: Vzostupne.

S prístupom smerom nahor sa dizajn začína od najnižšej úrovne z výberu atribútov. Potom sa zistia, že vzťahy medzi nimi sú zistené, to znamená, že funkčné závislosti, potom pomocou špeciálnych algoritmov na základe funkčných závislostí, sú vytvorené databázové schémy.

Prístup upstream je lepší na použitie pre návrh jednoduchých databáz, pretože s nárastom počtu atribútov na vytvorenie všetkých vzťahov medzi nimi sťažujú, okrem toho v počiatočných štádiách dizajnu veľkých systémov je ťažké Zvýraznite všetky atribúty.

Prístup downstream začína identifikáciou niekoľkých entít na vysokej úrovni a spojenia medzi nimi. Potom sa modelová rafinovanosť uskutočňuje v niekoľkých etapách a objavujú sa nové subjekty, komunikácie a atribúty.

Tam je tiež zmiešané dizajnové stratégie, v tomto prípade sa používajúci prístup hore a downstream sa používajú pre rôzne časti systému a potom sú výsledky poháňané.

Koncepcia subjektu.

Pri opise akejkoľvek oblasti predmetu osoba používa koncepcie jednotlivých položiek, faktov alebo udalostí, ktoré z okolitého sveta zdôrazňuje od všetkých ostatných a určitým spôsobom ich identifikuje. Preto je hlavnou zložkou sémantického modelu esencia.

Subjekt (subjekt) je "predmet", ktorý možno identifikovať určitým spôsobom, ktorý ho odlišuje od iných položiek. Predmet sa používa v širšom zmysle, napríklad v systéme riadenia učebných osnov, reálne objekty sa používajú ako položky (tréningový prípad, publikum, učitelia, fakty, sedenie atď.).

Charakteristiky entít. Problém jedinečnosti podstaty.

Všeobecne platí, že subjekt je typ alebo trieda odlíšiteľných objektov. Základom identifikácie podstaty na konkrétnu triedu je prítomnosť charakteristík charakteristík (atribúty), ktoré sú obsiahnuté v triede. Rozdiel medzi ostatnými subjektmi triedy sa vykonáva na základe hodnôt rovnakých charakteristík.

Hodnoty väčšiny vlastných charakteristík účtovnej jednotky sa časom menia, ale to neznamená zmiznutie podstaty a vzhľadu nových → potrebu identifikovať vlastnosti subjektu, ktoré sa časom nezmenia a jedinečne identifikujú podstatu .

Problém je, že v praxi nie je možné nájsť nezmenené atribúty. Aj keď takéto atribúty sú (číslo spätnej väzby a číslo pasu), potom počas prevádzky systému, môže byť potrebné upraviť tieto atribúty, napríklad na opravu vykonaných chýb.

Z hľadiska reálneho sveta môže takáto korekcia zodpovedať obom modifikáciám tohto atribútu (primárny kľúč) a vytvorenie nového subjektu. Jedným z riešení takéhoto problému môže byť zavedenie klávesov náhradných esencií. Nevýhodou tohto prístupu je odstrániť model zo skutočného sveta, to znamená, že model obsahuje informácie, ktoré chýbajú v oblasti predmetu.

Koncepčný dizajn sa teda začína pri identifikácii v oblasti subjektu subjektov, určenie charakteristík týchto subjektov, určujúce sady atribútov, jedinečne určujúce entity; Z týchto súborov si vyberte primárny kľúč alebo injekčný náhradný náhradník.

Vo formáte IDEFX je subjekt určený takto:

Všetky súbory atribútov, ktoré by mohli byť zobrazené ako klávesy sú označené AK (alternatívne tlačidlo).

Komunikácia. Koncepcia komunikácie.

Položky, udalosti a jednotlivci v oblasti predmetu sú v určitých vzťahoch. Pri budovaní sémantického modelu je potrebné identifikovať tieto vzťahy. Povolenie vzťahu v modeli vedie k vzniku nových atribútov alebo subjektov v závislosti od druhov interakcie.

Nech je v oblasti predmetu fakt - "Študent študuje v skupine." To znamená, že prepojenie medzi študentom subjektov a skupinou. S podrobnejšími analýzami sa zistia ďalšie fakty: Študent môže súčasne študovať len v jednej skupine, skupina môže pozostávať z mnohých študentov.

Takéto interakcie sa odrážajú ako "jeden k mnohým" vzťahom a v norme IDEFX sa odrážajú takto: \\ t

V dôsledku budovania komunikácie, entity "študent" bol nový atribút označený FK (cudzí kľúč). Hodnota tohto atribútu by sa mala zhodovať s hodnotou primárneho kľúča subjektu skupiny.

V norme IDEFX je "jeden až mnoho" klasifikovaný podľa nasledujúcich funkcií:

1) ako nulová hodnota;

2) Podľa stupňa závislosti záväzných entít;

3) Cartinou;

1. Klasifikácia komunikácie ako hodnoty null. Budeme pokračovať v príklade so študentom. V určitom okamihu, študent nesmie patriť do skupiny, napríklad, keď je študent v akademickej dovolenke, alebo pri prekladaní zo špeciality na špecializáciu. Atribút "skupinového čísla" je teda v podstate "študenta", s výnimkou hodnoty primárneho kľúča účtovnej jednotky "skupiny", môže mať nulovú hodnotu.

Takéto spojenie (s možnosťou nullovej hodnoty externého kľúča) sa v podstate predkovi poznamenáva diabel.

Zvážte ďalší príklad - "Zamestnanec pracuje v oddelení." Usporiadame odôvodnenie podobné predchádzajúcemu príkladu. Ak "každý zamestnanec by mal pracovať na oddelení", potom medzi subjektmi "Zamestnanec" a "Oddelenie" je odkaz "jeden k mnohým" bez možnosti neurčitého externého kľúča. Je tiež zobrazený, len rhombus v podstate nie je predchodca.

2. Klasifikácia komunikácie podľa stupňa závislosti subjektov. Niekedy, keď ide o predmet reálneho sveta, sú charakteristiky obsiahnuté v iných subjektoch, napríklad špecializácia je identifikovaná špeciálnym kódom, ktorý patrí k svojmu vlastnému číslu.

071901 - Prvé 4 číslice - špeciálne číslo, zvyšok - číslo špecializácie. Zároveň je číslo špecializácie jedinečné v rámci špeciality.

Subjekty podobné subjektom "špecializácia" sa nazývajú slabé alebo závislé, a sú zobrazené obdĺžnikovými obdĺžnikmi so zaoblenými rohmi:

Komunikácia sa nazýva "jeden k mnohým" identifikačným odkazom a zobrazí sa nie bodkovaná čiara a prevod primárneho kľúča podstaty predkov do primárneho kľúča detekčnej jednotky. Samozrejme, identifikačný odkaz nemôže dovoliť neurčitú hodnotu externého kľúča.

Predtým popísané dlhopisy neboli identifikované, zobrazené bodkovanou čiarou a primárny kľúč predkov sa prenesie na nie sú kľúčové atribúty.

3. Klasifikácia výpočtu. Štandard IDEFX podporuje nasledujúcu komunikačnú kardinálnosť (obrázok 4):

Napríklad v skupine musí byť aspoň 1 študent.

Zvyčajne pri implementácii databázy entity, medzi ktorými existujú "1 až 1" dlhopisy, sú riešené ako spoločná tabuľka. Zo sémantického hľadiska však nie je možné kombinovať takéto tabuľky, pretože sa získa účtovná jednotka s nezrozumiteľnou hodnotou.

Úlohu externého kľúča.

Niekedy pre presnejší opis oblasti predmetu je zadaný koncepcia úlohy atribútu pre externý kľúč. Úlohou je hodnota, ktorú je atribút v podstate. Napríklad v príklade kurátorky skupiny, "číslo tables" atribút ", v podstate skupiny, môže hrať úlohu" kuracieho ". Ak je spojenie zabudované v opačnom smere, externý kľúč hrá úlohu "skupiny dohľadu".

Existujú situácie, keď musí zavedenie úlohy externého kľúča.

1) Napríklad, keď sú prítomné dve alebo viac komunikácií medzi dvoma subjektmi → Popíšte účtovné vedenie, ktoré je charakterizované číslom do jedného dátumu a súčet. Účet sa vyznačuje číslom, názvom a časťou zostatku. Medzi subjektmi možno rozlíšiť dve spojenia:

- "Účet elektroinštalácie" - jeden a ten istý účet môže byť pripísaný na rôzne elektroinštalácie a elektroinštalácie len jeden účet → komunikácia "jedna k mnohým"; Zapojenie nemôže mať, ale mať kreditné účty, to znamená, že pripojenie neumožňuje neurčitú externú kľúčovú hodnotu; Kreditový účet nie je zapojený do identifikácie elektroinštalácie, preto spojenie nie je identifikované;

- "Zapojenie bude deformovať návrh zákona" - primárny kľúč k účtu účtovnej jednotky "by mal dvakrát vstúpiť do zloženia nie sú kľúčové atribúty účtovnej jednotky" elektroinštalácie ", to znamená, že bez úlohy externého kľúča.

2) V prípade rekurzívneho spojenia - keď sa rodič a potomok sa zhodujú. Príkladom je hierarchia podriadenosti v organizácii, keď pre daného zamestnanca je potrebné zohľadniť jeho bezprostredný nadriadený: \\ t

Pošlite svoju dobrú prácu v znalostnej báze je jednoduchá. Použite nižšie uvedený formulár

Študenti, absolventi študenti, mladí vedci, ktorí používajú vedomostnú základňu vo svojich štúdiách a práce, budú vám veľmi vďační.

Publikované na adrese http://www.allbest.ru/

Úvod

1. Koncepčný dizajn

1.1 Definícia typov entít

1.2 Definícia atribútov a viazanie ich s typmi subjektu

1.3 Definícia domén atribútov

1.4 Alternatívne a primárne kľúčové informácie

2. Logický dizajn

2.1 Konverzia miesta lokálne koncepčného dátového modelu na miestny logický model

2.2 Kontrola modelov pomocou pravidiel normalizácie

2.3 Skontrolujte model pre užívateľské transakcie a vykonanie dotazu

2.4 Budovanie záverečného grafu "Essence of Communication"

Záver

Zoznam použitých literatúry

Úvod

Databáza je kombináciou nezávislých materiálov (článkov, výpočty, predpisy, súdne rozhodnutia a iné druhy materiálov) systematizované tak, že tieto materiály možno nájsť a spracovať pomocou elektronického výpočtového stroja (počítače).

DBMS skrýva tabuľky sériového sledovania od užívateľa, čo ich vykonávajú čo najefektívnejším spôsobom. Veľmi dôležitou vlastnosťou relačných systémov je, že výsledkom ľubovoľnej požiadavky na databázové tabuľky je tiež tabuľka, ktorá môže byť uložená v databáze a / alebo s ohľadom na ktoré možno vykonať nové žiadosti. Dizajn koncepčný kľúč

Hlavným účelom informačných systémov je ukladať informácie o svete a procesoch toho, čo sa deje v ňom, ktoré sú nakoniec poskytované používateľom. Keďže len niektoré časti reálneho sveta majú záujem o rôzne skupiny ľudí, údaje o každom informačnom systéme sa vzťahujú na konkrétnu oblasť. Časť skutočného systému, ktorý sa má študovať na účely jeho opisu, sa nazýva oblasť predmetu.

Existuje kompletný predmet a jeho fragmenty, pričom každý fragment môže predstavovať svoju oblasť predmetu. Napríklad pre univerzitu možno rozlíšiť nasledujúce fragmenty: Oddelenie odbornej prípravy, účtovné oddelenie, personálne oddelenie, cestovné poriadky atď.

Informácie potrebné na opis oblasti predmetu môžu obsahovať informácie o ľuďoch, objektoch, dokumentoch, udalostiach, konceptoch atď.

Každá oblasť predmetu je charakterizovaná množstvom objektov - prvky reálnych systémov a procesov pomocou objektov, ako aj množstvo používateľov charakterizovaných jedným pohľadom na oblasť predmetu. Najmä pre účtovné zariadenia - všetky druhy dokumentov. Účtovné procesy - Výpočet platov, materiálne účtovníctvo, bankové operácie atď Nakoniec, používatelia tohto fragmentu účtovníctva zamestnancov, zamestnancov finančných orgánov, manažérov spoločnosti atď.

Každý objekt má špecifickú sadu vlastností, ktoré sú v informačnom systéme pamätané. Pri spracovaní údajov je často potrebné riešiť súbor homogénnych objektov, napríklad, ako sú študenti alebo fakulty a zaznamenávajú informácie o rovnakých vlastnostiach pre každého z nich. Kombinácia objektov s rovnakou sadou vlastností sa nazýva trieda objektu. Pre objekty jednej triedy bude nastavená vlastnosť rovnaká, hoci hodnoty týchto vlastností sa môžu líšiť pre každý objekt.

Trieda objektov sa často nazýva esencia. Každá entita má atribúty. Atribút je majetkom objektu charakterizujúce jeho inštanciu. Účtovná jednotka "Študent" môže mať atribúty "meno", "Rok narodenia", "dátum prijatia", atď. sú rôzne, tj. Súbor atribútov je rovnaká a ich hodnoty sú iné.

Účelom mojej práce je vytvoriť databázu pre účtovníctvo predaja a doručenia súborov súborov a komponentov PC. Bude tiež použitý na zohľadnenie pohybu tovaru medzi dodávateľom a príjemcom.

Úlohy práce:

Určiť typy subjektov

Určite typy komunikácie

Určite atribúty a spojte ich so subjektmi

Určite domény atribútov

Určite alternatívne kľúče (atribúty)

Vytvorte schému "Komunikácia Essence"

Premeniť lokálne koncepčný model na lokálny logický dátový model

Skontrolujte modely pomocou pravidiel normalizácie

Skontrolujte model pre užívateľské transakcie a vykoná požiadavky

Vybudovať záverečný graf "Essence of Communication"

1. Koncepčný návrh

Koncepčný (infografický) 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 tejto súvislosti sa slová "databázový model" a "model subjektu" môžu použiť rovnako (napríklad "koncepčná databáza" a "koncepčný model oblasti"), pretože takýto model je oboje Realita a 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 pripojení medzi nimi.

Opis obmedzení integrity, t.j. Požiadavky na platné hodnoty údajov a prepojenia medzi nimi.

1.1 Definícia typov subjektov

Subjekt - akýkoľvek rozoznateľný objekt (objekt, ktorý môžeme odlíšiť od druhého), informácie o tom, ktoré musia byť uložené v databáze. Subjekty môžu byť ľudia, miesta, lietadlá, lety, chuť, farba atď. Je potrebné rozlišovať takéto koncepty ako typ podstaty a inštanciu subjektu.

Essencia je kolektívna koncepcia, niektoré abstrakcie skutočne existujúceho objektu, procesu, javov alebo niektorých prezentácií objektu, ktorý sa musí uložiť v databáze.

Je potrebné rozlišovať takéto koncepty ako typ podstaty a inštanciu subjektu. Koncepcia typu subjektu patrí do súboru homogénnych osobností, objektov, udalostí alebo myšlienok, pôsobiacich ako celku. Kópia účtovnej jednotky patrí do konkrétnej veci v súbore. Napríklad typ subjektu môže byť mestom a kopírovaním - Moskva, Kyjev, atď.

Rozlišujú sa tri typy subjektov: Rod, Associative (Association) a charakteristika (charakteristika). Okrem toho podmnožina označení tiež definujú v rôznych asociatívnych subjektoch. Teraz dávame definíciu podobností.

Rodainská esencia.

ROD (silná) subjekt - nezávislá od inej podstaty. Essencia typu nemôže byť združením, charakteristikou alebo označením (pozri nižšie).

Združenie.

Associative Essence (alebo Association) vyjadruje pripojenie "mnohých až mnohých" medzi dvoma subjektmi. Je to dosť nezávislá podstata. Napríklad medzi subjektmi, muža a ženami existuje asociatívne pripojenie, vyjadrené asociatívnou manželskou esenciou.

Charakteristické.

Charakteristická podstata sa tiež nazýva slabá esencia. Je spojená so silnejšou podstatou pripojenia "jeden až mnoho" a "jeden až jeden". Charakteristický subjekt opisuje alebo určuje iný subjekt. To úplne závisí od toho a zmizne s zmiznutím.

Označenie.

Určenie je takáto subjekt, s ktorým sú iné subjekty spojené s princípom "mnohých" alebo jedného "alebo" jeden k jednému ". Označenie, naopak, charakteristiky sú nezávislá esencia. Essencia fakulty napríklad označuje študentovi patriaci do tejto jednotky inštitútu, ale je celkom nezávislý.

Definícia typov komunikácie

Komunikácia - Toto je graficky znázornená asociácia, inštalovaná medzi dvoma typmi subjektov. Podobne ako podstata, pripojenie je typickým konceptom, všetky inštancie oboch záväzných typov subjektov podliehajú pravidlám záväzných. Preto je správne hovoriť o type komunikácie, inštalovanej medzi typmi subjektu, a na inštanciách typu komunikácie, ktoré sú inštalované medzi inštanciami typu vzoriek. Vo verzii modelu ER diskutovaného tu je toto združenie vždy binárne a môže existovať medzi dvoma rôznymi typmi subjektov alebo medzi typom esencie a oni sami (rekurzívna komunikácia). Dva konce sú pridelené v akomkoľvek spojení (v súlade s existujúcim párom väzbových entít), z ktorých každá označuje koniec konca, stupeň konania komunikácie (koľko kópií tohto typu subjektu by malo byť prítomné v každej inštancii Z tohto typu komunikácie), viazanie komunikácie (tj. Každá inštancia tohto typu subjektu by sa mala zúčastniť určitej inštancie tohto typu komunikácie).

Komunikácia je predložená vo formulári. Zároveň v mieste "dokovania" komunikácie s podstatou:

Trojbodový vstup do obdĺžnika podstaty, ak pre tento subjekt z dôvodu pripojenia (alebo by mal) používať mnoho prípadov subjektu;

Jednorazová položka, ak sa môže zúčastniť iba jedna inštancia účtovnej jednotky (alebo by mala).

Povinný koniec spojenia je zobrazený s pevnou čiarou a voliteľnou - prerušovanou čiarou.

Spojenie medzi subjektmi letenky a cestujúcim spája vstupenky a cestujúcim. Koniec komunikácie s názvom "pre" vám umožňuje spájať s jedným cestujúcim viac ako jeden lístok a každý lístok musí byť spojený s akýmkoľvek cestujúcim. Koniec komunikácie s názvom "má" ukazuje, že každý lístok môže patriť len jednému cestujúcemu a cestujúci nie je povinný mať aspoň jeden lístok.

Obr. jeden. Príklad typ komunikácie

· Každý lístok je určený pre jedného a jediného cestujúceho;

· Každý cestujúci môže mať jeden alebo viac lístkov.

Rekurzívna komunikácia

V nasledujúcom príklade (Obr. 2) zobrazuje rekurzívne spojenie, ktoré spája podstatu človeka s ním sám. Koniec komunikácie s názvom "Syn" určuje skutočnosť, že niekoľko ľudí môže byť synovia jedného otca. Koniec komunikácie s názvom "otec" znamená, že každý človek by mal mať synov.

Obr. 2.. Príklad rekurzívneho typu komunikácie

Laconic orálna interpretácia grafu je nasledovná:

Každý muž je syn jedného a jediného človeka;

Každý muž môže byť otcom jedného alebo viacerých mužov.

Typy väzieb medzi tabuľkami

Komunikácia vám umožňuje simulovať vzťah medzi objektmi objektov.

Existujú 4 typy pripojení:

1. " Jeden na jedného" - Do akejkoľvek inštancie podstaty A zodpovedá len jednej kópii subjektu v a naopak.

Každý konkrétny študent môže mať len jednu charakteristiku a táto charakteristika sa vzťahuje na jedného študenta.

2. " Jedným z nich" - Každá inštancia esencie A zodpovedá 0, 1 alebo viacerým kópiám účtovnej jednotky, ale len jedna kópia podstaty A. zodpovedá akúkoľvek inštanciu podstaty

Študent je zvýšený veľa odhadov; Odhad patrí len jednému študentovi.

3. " Mnoho-to-one" - do ľubovoľného prípadu účtovnej jednotky A zodpovedá len jednej inštancii účtovnej jednotky, ale akúkoľvek inštanciu subjektu v zodpovedá 0, 1 alebo niekoľkých kópiách podstaty A.

Učiteľ pracuje len v jednej kancelárii, ale zošit môže byť zakotvený v niekoľkých učiteľoch.

4. " Mnoho-spolu" - do ľubovoľného prípadu podstaty A zodpovedá 0, 1 alebo viacerým kópiám účtovnej jednotky a akúkoľvek inštanciu účtovnej jednotky v zodpovedá 0, 1 alebo viacerých kópiách esencie A.

Študent Ivanov študuje v niekoľkých učiteľoch. A každý učiteľ pracuje s mnohými študentmi.

1.2 Definícia atribútov a viazanie ich s typmi entitou

Atribút entity je akákoľvek časť, ktorá slúži na objasnenie, identifikáciu, klasifikáciu, numerickú charakteristiku alebo vyjadrenie štátu Essence. Názvy atribútov sa zadávajú do obdĺžnika zobrazujúcej podstatu pod názvom esencie a sú zobrazené malými písmenami, možno s príkladmi.

Príkladom účtovnej jednotky, ako je osoba so špecifikovanými atribútami (obr. 3) z technického hľadiska atribútov typu subjektu v modeli ER podobný atribútov vzťahu v modeli relačného dát. A tým, že v iných prípadoch zavádzanie pomenovaných atribútov vstupuje do určitého typu dátovej štruktúry, ktorých názov sa zhoduje s názvom typu entity v prípade ER modelu alebo s menom premennej pomeru v prípade relačného modelu. Po tejto typickej štruktúre by mali nasledovať všetky prípady typu entítu alebo všetky kortices vzťahu.

Obr. 3. Príklad typu subjektu s atribútmi

Pri určovaní atribútov typu entity v modeli ER je indikácia domény atribút voliteľná, hoci je to možné (pozri nižšie). Dokidejme, čo spôsobilo, že táto možnosť "oslabená" definícia atribútu. Po prvé, sémantické dátové modely sa používajú na konštrukciu koncepčných schém DB a tieto schémy sa konvertujú na relačné databázové schémy, ktoré sú podporované konkrétnymi DBMS.

Ako je uvedené vyššie, pri určovaní typu esencie je potrebné zabezpečiť, aby každý prípad účtovnej jednotky odlíšil od akejkoľvek inej inštancie toho istého subjektu. Keďže podstata je abstrakciou skutočného alebo predloženého objektu vonkajšieho sveta, táto požiadavka by sa mala pripomenúť pri výbere kandidáta na typy subjektu. Jedinečným identifikátorom účtovnej jednotky môže byť atribút, kombinácia atribútov, komunikácie, kombinácie dlhopisov alebo kombinácie pripojení a atribútov, jednoznačne rozlišovať akúkoľvek inštanciu subjektu z iných prípadov podstaty rovnakého typu. Dávame niekoľko príkladov. Na (obr. 4) ukazuje typ subjektu je kniha vhodná na použitie v databáze knižnice. Pri publikovaní akejkoľvek knihy v každom vydavateľstve je priradená jedinečné číslo - ISBN. Je zrejmé, že hodnota atribútu ISBN bude jednoznačne identifikovať dávku kníh v sklade. Okrem toho, samozrejme, kombinácia atribútov je vhodná ako jedinečný identifikátor.<автор, название, номер издания, издательство, год издания>.

Obr. štyri Typ subjektu, ktorého inštancie sú identifikované atribútmi

Na (obr. 5), diagram obsahuje dva viazané typy podstaty. Každý dospelý má jeden a len jeden a každý pas môže patriť len jednému dospelému človeku. Potom pripojenie osoby so svojím pasom jedinečne identifikuje dospelý človek, to znamená, že hrubo hovorí, pas určuje dospelého. Keďže môžu byť pasy, ktoré ešte neboli vydané žiadnej osobe, toto spojenie nie je jedinečným identifikátorom pasu.

Obr. päť Typ subjektu, ktorého inštancie sú identifikované spojením

Na (obr. 6), diagram obsahuje tri viazané typy subjektu. Profesor má vedomosti v niekoľkých tréningových disciplínach. Vyučovanie každej disciplíny je k dispozícii viacerým profesorom. Inými slovami, profesor a disciplína medzi subjektmi definovali pripojenie "Mnoho k mnohým". Každý profesor môže pripraviť kurzy pre ktorúkoľvek disciplínu prístupnú. Každá disciplína môže byť venovaná niekoľkým vzdelávacím kurzom. Každý profesor môže pripraviť len jeden kurz na akúkoľvek disciplínu prístupnú, a každý kurz možno venovať len jednej disciplíne. Každá kópia typu essencie kurzu je teda jednoznačne identifikovaná kópiou podstaty profesora a kópiu subjektu disciplíny, tj pripravuje pár spojení s menami koncov a je určený na strane krajiny. Všimnite si, že subjekty profesora a disciplíny so spojeniami nie sú identifikované.

Obr. 6.. Typ subjektu, ktorého kópie sú identifikované kombináciou väzieb

Nakoniec, na (obr. 7) je príkladom typu subjektu, ktorého jedinečný identifikátor, ktorý je kombináciou atribútov a pripojení. Každá osoba môže mať deti a každá osoba má otca. Potom za predpokladu, že dvojčatá, ktoré sa objavili na svetle súčasne nedávajú rovnaké mená, potom jedinečný identifikátor typu essence osoby môže byť kombináciou atribútov.

Obr. 7.. Typ subjektu, ktorého inštancie sú identifikované kombináciou atribútov a odkazov

1.3 Definícia domén atribútov

Doména V modeli relačného dát - typ údajov, to znamená, že prípustný súbor hodnôt.

Koncepcia typu údajov je základná; Každá hodnota, každá premenná, každý parameter, každé čítanie, a najmä každý relačný atribút týka konkrétneho typu.

Príkladmi môžu byť typy "Integer" (sada všetkých celých čísel), "reťazec" (sada všetkých čiar), "číslo dielu" (súbor všetkých počtov častí), atď., Keď hovoríme, že niektorý atribút Má typ atribútu "celý", myslíme, že všetky hodnoty tohto atribútu patria do nastavenej "celku" a nie iné.

Analogicky s matematikou sú dátové typy rozdelené do skalárny a nekvalifikovaný. Hodnota neznámeho typu (non-hodnota) má pre používateľa sadu viditeľných komponentov a hodnota skalárneho typu (skalárna hodnota) nemá žiadne. Príklady bezhalovaného typu sú typ vzťahu a typu výrobku; Príklad skalárneho typu je typ "celé číslo".

Obmedzenia vykonávania databázových systémov na počítačoch sú uložené na definíciu typov určitej podmienenosti. Teoreticky typové celé číslo je teoreticky všetky možné celé čísla, avšak v skutočnosti, celé číslo je súbor všetkých celých čísel môže byť prezentovaný v posudzovaní počítačového systému. (Odvtedy existujú také celé čísla, ktoré presahujú možnosť prezentácie v akomkoľvek počítačovom systéme).

Mal by sa vyznačovať typom ako taký (logický koncept) a formát fyzickej reprezentácie hodnôt tohto typu v špecifickom počítačovom systéme; Typy sa týkajú úrovne logický modela fyzické znázornenie hodnôt - na úroveň predaja. Napríklad operácie definované pre typ "reťazec" nemajú zmysel pre typ "Číslo", aj keď čísla v konkrétnej implementácii sú fyzicky reprezentované čiarami. Hodnoty typu "dátum" sú často fyzicky reprezentované skutočným číslom, ale väčšina operácií, ktoré dávajú zmysel pre typ "Číslo", nie sú zmyselné pre typ "dátum".

Relačný dátový model nepredpíše povinnú podporu všetkých preddefinovaných typov, s výnimkou logického typu (boolean), bez ktorého nie je možné robiť pri vykonávaní operácií. Zvyčajne určitý typ je podporovaný systémom, ďalšie typy používateľa môžu byť navyše navrhnuté.

1.4 Informácie o alternatívnych a primárnych kľúčoch

Perevi.kľúčové slovo - V modeli relačného dát, jeden z možných kľúčových vzťahov vybraných ako hlavný kľúč (alebo predvolený kľúč).

Ak existuje jeden potenciálny kľúč vo vzťahu k primárnemu kľúču. Ak existuje niekoľko potenciálnych kľúčov, jeden z nich je vybraný ako primárny a iní volá " alternatívny".

Z hľadiska teórie sú všetky potenciálne kľúče vzťahu ekvivalentné, to znamená, že majú rovnaké vlastnosti. jedinečnosť a minimálny. Avšak, jeden z potenciálnych kľúčov je zvyčajne vybraný ako primárny, ktorý je najvýhodnejší na určité praktické účely, napríklad na vytvorenie externých tlačidiel v iných ohľadoch alebo na vytvorenie klastrového indexu. Preto ako primárny kľúč, spravidla ten, ktorý má najmenšiu veľkosť (fyzické ukladanie) a / alebo zahŕňa najmenší počet atribútov.

1.6 Stavebný graf Essence-Komunikácia

2. Logický dizajn

Logickým dizajnom databázy je proces navrhovania modelov informačnej štruktúry podniku uskutočniteľné v súlade s požiadavkami vybranej informačnej organizácie systému. Generovaný logický model však nezávisí od charakteristík špecifických DBMS a iných fyzikálnych podmienok implementácie.

2.1 Konvertovať lokronálne koncepčný dátový model na miestny logický model

1. Prvým krokom je odstrániť spojenie "Mnoho k mnohým". Takéto spojenie je prítomné medzi subjektmi "Kit" a "zákazníkom" firmou ". Tieto odkazy porušujeme zavedením stredného entity "Zoznam"

2. Odstránenie komplexných pripojení. Komplexné spojenia sú pripojenia, v ktorých sa zúčastňujú tri alebo viac typov subjektov. V mojej práci nie sú takéto pripojenia.

3. Odstránenie rekurzívnych pripojení. Rekurzívne spojenia - spojenia, v ktorých subjekty komunikujú s zlyhaním. V mojej práci nie sú takéto pripojenia.

4. Odstránenie pripojení atribútov.

5. Vymazanie viacerých atribútov v mojej práci je jeden atribút s viacerými telefónmi. Rozdeľujeme "telefón príjemcu" na "príjemcu domáceho telefónu" a "príjemcu mobilného telefónu". "Dodávateľ telefón" na "poskytovateľa mobilných telefónov" a "telefónny telefón".

6. Odstránenie nadmerných odkazov. V mojej práci nie sú takéto pripojenia.

2.2 Kontrola modelov pomocou pravidiel normalizácie

Technológia navrhovania relačných databáz je spojená s teóriou normalizácie založenej na analýze funkčných závislostí medzi atribútmi vzťahov. Koncepcia funkčnej závislosti je základom teórie normalizácie relačných databáz. Funkčné závislosti určujú stabilný vzťah medzi objektmi a ich vlastnosťami v posudzovanej oblasti. Preto je proces podpory funkčných závislostí charakteristických pre túto oblasť predmetu základný pre proces navrhovania.

V teórii relačných databáz zvyčajne zdôrazňuje nasledujúci postup normálnych formulárov:

1. 1 Normálna forma

2. 2 Normálna forma

3. 3 Normálna forma

Prvá normálna forma (1NF)

Variabilný vzťah je v prvej normálnej forme (1NF), ak a len ak v akomkoľvek platnej hodnote, každá zásielka obsahuje iba jednu hodnotu pre každý z atribútov.

V relačnom modeli je postoj vždy v prvej normálnej forme na určenie koncepcie postoja. Pokiaľ ide o rôzne tabuľky, nemusia byť správne reprezentácie vzťahov, a preto nemusia byť v 1NF.

Druhá normálna forma (2NF)

Variabilný vzťah je v druhej normálnej forme, ak je len vtedy, ak je v prvej normálnej forme a každý neutrálny atribút je neredukovateľná (funkčne) závisí od jeho potenciálneho kľúča.

Tretia normálna forma (3NF)

Variabilný vzťah je v treťom normálnom formulári, ak a len ak je v druhej normálnej forme, a neexistujú žiadne tranzitívne funkčné závislosti nexiánskych atribútov z kľúčov.

2.3 Skontrolujte model pre užívateľské transakcie a vykonanie dotazu

1. Informácie o dostupných komponentoch špecifikovaného zdroja;

Vyberte komponenty. Názov komponentu, dodávateľa spoločnosti. Dodávateľ názov, komponenty, Dodávateľské číslo

Od dodávateľa komponentov

Kde pevný dodávateľ, názov spoločnosti "AMD"

A dodávateľ spoločnosti, číslo dodávateľa \u003d komponenty, číslo dodávateľa;

2. Informácie o súpravách objednaných konkrétnym zákazníkom s uvedeným názvom príjemcu;

Vyberte Set, Názov sady, Zoznam, Nastavte číslo, Číslo zákazníkom, Číslo spoločnosti, zákazník spoločnosti, Meno zákazníka, príjemcu, PHOE príjemcu

Zo súboru, zoznamu, zákazníkom, príjemcom

Kde spoločnosť zákazník, meno spoločnosti zákazníkom - "Intercom"

A súprava kit. Nastaviť a zoznam zoznamu, Číslo spoločnosti Customers \u003d Customer Company, Spoločnosť zákazníka a príjemca, Číslo príjemcu \u003d číslo príjemcu;

2.4 Budovanie konečného diagramu" Essence komunikácie"

Záver

V tomto kurze som vytvoril databázu na automatizáciu interiéru počítača. V počiatočnej fáze som zostavil model predmetovej oblasti, ktorú je potrebné identifikovať objekty, ktoré majú najväčší záujem užívateľov. Na tento účel som zostavil podrobný opis oblasti a pripojenia, ktoré sú prítomné medzi týmito objektmi, skontrolovali jeho model pre takéto typy odkazov ako komplexné, rekurzívne spojenie s atribútmi, rozdelenú komunikáciu k mnohým mnohým, a tiež identifikovali typy typy atribútov a atribútov a na základe týchto údajov vybudované diagram "essence-komunikácia"

Na 2 úrovne som urobil komunikačnú kontrolu a overovanie modelov pomocou normalizačných pravidiel. Môj dátový model bol v prvej a druhej normálnej forme, v 3 normálnej forme som priniesol model zistením tranzitívnych závislostí a previesť ich na iný subjekt (zoznam). Skontroloval model pre užívateľské transakcie a vykonanie dotazov a potom vybudoval poslednú "essence-komunikačnú" graf. Na základe mojej práce som mohol povedať, že moja databáza pomôže dobre v počítači interiéru.

Zoznam použitých literatúry

1. Databázy. Tutorial A.D. Homonenko

2. Wayskos J. Efektívna práca s MS Access 2000

3. Wikipedia

4. Dátum K. J. Úvod do databázového systému

Publikované na Allbest.ru.

...

Podobné dokumenty

Počiatočné údaje pre konštrukciu komplexu výroby farieb a rozpúšťadiel s celkovou kapacitou 7000 t / g. Základ na vývoj zdrojových údajov a všeobecných technologických informácií. Popis hlavných technologických systémov výroby.

kurz práce, pridané 17.02.2009


Charakteristika automatizovaných krokov dizajnu. Metódy a algoritmus pre výpočet rýchlosti spotreby základných materiálov na ženskej demi-sezóna srsti pomocou programov BASIQ NORMA 1 a NORMA 2. Vlastnosti automatizácie spracovania údajov pomocou počítača.

kurz, pridané 06.05.2010


Výber elektrického motora a dizajnu dvojstupňovej šnúry červov. Kritériá na návrh: Výber materiálov veľkosti a prevodoviek. Výpočet vysokorýchlostného a nízko rýchlosti prenosu. Navrhovanie červov a červových kolies. Rozloženie reduktora.

kurz práce, pridané 01/12/2012


Vypracovanie zdrojových údajov pre dizajn hydinového domu. Stanovenie požadovaného tepelného odolnosti tepla. Výpočet oblastí jednotlivých podlahových zón. Výpočet tepelnej straty cez uzavreté štruktúry. Výpočet režimu tepelného vzduchu a výmeny ovzdušia.

kurz práce, pridané 09/10/2010


Základné informácie o silikátovej tehli. Výroba limetého oxidu kremičitého. Silos na zastavenie zmesi surovín. Proces autoklávového spracovania materiálov. Výpočet potrieb surovín. Vstupná regulácia materiálov. Výpočet skladu.

práca, pridané 01/27/2014


Pravidlá pre návrh a rekonštrukciu mechanických výrobných dielní: Všeobecné informácie o konštrukcii výroby mechanickej montáže, opis pracovného návrhu a pracovnej dokumentácie, interiéru navrhovanej časti časti časti.

vyšetrenie, pridané 12/28/2008


Charakteristiky produktov železobetónových výrobkov a betónových zmesí. Výpočet výkonu prípravy betónových zmesí. Výber technologických zariadení. Určenie objemu zásobníkov materiálu a výber typov skladu.

kurz, pridané 11.06.2015


Funkcie systému automatizovaného dizajnu oblečenia. Umelecký dizajn odevných modelov. Antropometrická analýza obrázkov. Dizajnové metódy vzorov modelov. Rozvoj rodiny modelov, vývoj vzorov a definíciu noriem spotreby.

práca, pridaná 26.06.2009


Prevádzkové podmienky obrábacieho zariadenia, ktoré slúžia ako poháňané výklenkom. Motor pre jeho dizajn, kinematický výpočet pohonu. Výber materiálov na prenos červa a stanovenie prípustných namáhaní. Výpočet hriadeľov a ložísk.

kurz práce, pridané 06/16/2011


Odôvodnenie Výber systému a systému zásobovania vodou, hydraulický výpočet siete a výber merača. Stanovenie požadovaného tlaku. Konštrukčné štandardy kanalizácie, výpočet vnútornej a nádvorie siete. Špecifikácia materiálov a zariadení.