Krátko o dôležitých.

Normalizácia databázy

Prvá normálna forma (1NF)

• neexistujú žiadne opakujúce sa údaje
• zaručená elementárnosť (atomicity) údaje (všetky údaje sú autonómne a nezávislé).

Na horné poschodie To sa dosahuje vytvorením primárneho kľúča, potom prenos duplicitných dátových skupín na nové tabuľky, vytvorenie primárnych kľúčov pre tieto tabuľky a tak ďalej. Okrem toho musíte rozdeliť všetky záznamy, ktorých stĺpce obsahujú kompozitné informácie, na samostatných riadkoch pre každý fragment údajov stĺpca.

Druhá normálna forma (2NF)

• tabuľka spĺňa podmienky 1NF
• každý stĺpec závisí od celého kľúča a nie z jeho časti.

Tretia normálna forma (3. nová)

• tabuľka spĺňa podmienky 2NF
• Žiadny stĺpec nie je závislý na stĺpci, ktorý nie je súčasťou primárneho kľúča.
• neobsahuje odvodené údaje

Ďalšie normálne formy, ktoré nemajú osobitnú praktickú hodnotu:

Normálna forma chlapcov CODD (BOYCE-CODD)

Možnosť 3NF. Navrhnuté na vyriešenie situácie s prítomnosťou mnohých prekrývajúcich sa kandidátskych kľúčov. V skutočnosti nenájde logické odôvodnenie mimo akademickej obce.

Štvrtý normálny formulár

Navrhnuté na riešenie problému s viaccennými závislosťami. Takéto situácie vznikajú, ak je jeden stĺpec kompozitného primárneho kľúča závisí od tabuľky 3DNF tabuľky závisí na druhom stĺpci primárneho kľúča.

Piata normálna forma

Používa sa pri práci s rozkladom vzťahov so stratami a bez straty. Vyskytuje sa v situácii, keď si môžete rozbiť jeden postoj do niekoľkých rôznych vzťahov, ale potom sa už nebudeme schopní logicky vrátiť do pôvodného formulára.

Šiesty normálna forma (normálna forma domény)

Zaručuje nedostatok anomálií modifikácie v databáze. V reálnych podmienkach je prakticky nedosiahnuteľný.

Vzťahy.

Akonáhle som počul od ženách, ktoré muži
Okamžite sa snažte opustiť miestnosť, v ktorej
Znie to slovo "vzťah".<...> Kľúč k úspechu
Vzťah je povedomie každého o jeho úlohe
v tomto ohľade, ako aj o pravidlách a obmedzení, \\ t
tento postoj.
C) Robert Viera, "Professional SQL Server 2000 Programovanie "

Typy vzťahov

• Jedno-to-one (to znamená, že v rôznych základoch je potrebné uložiť zhodné údaje alebo keď existuje výnimka maximálna veľkosť Dáta riadkov)
• Nulový alebo jeden
• Jedným z nich
• Jeden až -nulya, - jeden alebo -my
• Mnoho-to-mnoho (objaviť tabuľky)

Združenie

Vnútorný spoj.

Vylúčenie Únie (exkluzívneho pripojenia). Do výsledku vzorky spadajú len tie tabuľky tabuliek, ktoré majú zhodu v tabuľke párov na danom stave.

Vľavo | správne pripojiť

Inclusive Cirking. V dôsledku vzorky, vstupov z tabuľky, stojaci vľavo / vpravo Pripojiť sa. resp. Zároveň sa vyplnia údaje z chýbajúceho "páru" NULOVÝ.
Z ľavého ľavého vstupu doľava - Všetky položky z ľavého stola zostávajú.
Z ľavostranného práva - Všetky záznamy z pravého stola RIGHT_TABLE sú povolené.

Plné pripojenie.

Inclusive Cirking. Nielen záznamy, ktoré sa stretávajú v inom stole, ale tiež sa nenachádzajú z oboch tabuliek, nie sú nájdené, pre ktoré v súlade s druhou tabuľkou. V tomto prípade budú údaje z chýbajúceho záznamu "páru" naplnené null.

Cross cross.

Cross Association (cartesovo práca). Každý záznam z jednej tabuľky je vyrobený v súlade s každým záznamom z inej tabuľky. Počet výsledných záznamov sa rovná počtu záznamov v oboch tabuľkách.

Zásady objednania niekoľkých Pripojiť sa.'OV

V prípade, že potrebujete kombinovať viacero tabuliek, musíte si zapamätať dve zásady:

1. Všetky odbory zostali Pripojiť sa. Vnímané ako jediná tabuľka, ktorá sa má zapnúť alebo vylúčiť z dotazu.
2. Všetky odbory majú pravdu Pripojiť sa. Tiež vnímané ako jediná tabuľka, ktorá umožňuje alebo výnimku z dotazu.

Dôsledkom týchto zásad je nasledujúce odporúčanie na vytvorenie zložitých združení: \\ t

• Kdekoľvek môžete, použite vnútorné pripojenie.
• Ak je potrebné použiť vonkajší pripojenie - musia byť umiestnené posledné, a na začiatku Únie sa nachádza vnútorný pripojenie.

P.S. Všetky vyššie uvedené sú všeobecné "postuláty" teórie relačných databáz, ktoré nie sú viazané na zvláštnosti určitých DBMS.

Databáza (databáza) je usporiadaný súbor údajov. Dátová organizácia je zvyčajne navrhnutá tak, aby odrážala skutočný vzťah uložených údajov takým spôsobom, aby sa uľahčilo spracovanie týchto informácií.

DBMS - Database Management Systems - Toto je špecializovaný softvér, ktorý sa očakáva, že bude spravovať databázy. To sa dosahuje interakciou s užívateľom na jednej strane a vlastne s databázou na strane druhej.

Dbms všeobecný účel Musí vykonať definíciu, tvorbu, zmenu, správu a produkt požiadaviek do databázy.

Ako príklady DBMS, takéto široko známe balíky môžu byť nazývané ako

• MySQL
• Postgresql
• Microsoft SQL Server
• Odtlačok
• IBM DB2.
• Microsoft Access.
• Sqlite.

Databázy zvyčajne nie sú tolerované medzi rôznymi DBMS, ale je možné komunikovať medzi DBMS (as používateľským softvérom) rôzne štandardy, ako je SQL, ODBC alebo JDBC.

DBMS sú často klasifikované podľa modelu údajov podporovaného. Od 80. rokov, takmer všetky populárne DBMS podporujú relačný dátový model, ktorý poskytuje štandardný jazyk. sQL dotazy (Hoci posledné roky získava popularity Nosql).

Takže hlavné úlohy, ktoré vykonáva DBMS, zahŕňajú

Definícia tvorby údajov o vytváraní, zmenách a odstraňovaní štruktúr, ktoré určujú organizáciu všetkých ostatných údajov v databáze, ktorý sa menia dát, meniaci sa a vymazanie údajov samotných. Získavanie údajov. Poskytovanie informácií vo forme vhodné na priame používanie inými aplikáciami. Registrácia a riadenie databázy užívateľov, poskytovanie bezpečnosti údajov, údržbu integrity, obnovy informácií, riadenie simultánneho prístupu, sledovania výkonnosti atď.

DBMS sú široko používané v bankovníctve, dopravných spoločnostiach, \\ t vzdelávacie inštitúcie, Telekomunikácie, riadiť finančné informácie a ľudské zdroje. No, nemali by ste zabúdať, že väčšina webových backredov používa jednu alebo iné DBMS.

Jednou z hlavných čŕt vývoja databázy je nedostatok hotových riešení a algoritmov. Každá databáza je konkrétne na úlohu, pre ktorú je navrhnutý. To odlišuje vývoj databázy z vývoja typických aplikácií, pre ktoré algoritmy a vzorové šablóny boli vyvinuté na dlhú dobu a nemusia nič vymyslieť. Aj keď sú samozrejme techniky dizajnu databázy spoločné pre všetky aplikácie.

Modely databázy

Ako už bolo spomenuté, najrozšírenejší model údajov je relačným modelom. Vzhľad relačného modelu však predchádzali iní, najmä

• Hierarchický alebo navigačný model
• Sieťový model

Hierarchický model bol široko používaný v DBMS dodávaných IBM v šesťdesiatych rokoch. Základnou myšlienkou je, že vstup v takejto databáze môže mať niekoľko "dcérskych spoločností" a jedného "rodičov". Všeobecne platí, že podozrivo podobne ako hierarchický systém súborov. Ak chcete získať vstup do takejto databázy, často potreboval pasáž v celom strome.

Model siete je flexibilnejšou verziou toho istého prístupu. To vám umožní mať záznam niekoľko "rodičov". Tento model, ktorý sa objavuje na začiatku 70. rokov, nebol rozšírený a čoskoro posunul relačným modelom.

V roku 1970, Edgar CODD (IBM Employee) navrhol relačného modelu, ktorý výrazne uľahčil úlohu vyhľadávania informácií v databáze. Môžete premýšľať o relačnom modeli ako "tabuľky", v ktorom sú "riadky" vstupy v databáze. Vzťahy v relačnej databáze sa nazývajú aj Novinky a skupiny záznamov ("Tabuľky") vzťahy (vzťahy). Relačný model je schopný vyjadriť komunikačné hierarchické a sieťové modelya pridané svoje vlastné pripojenia zodpovedajúce tabuľkovému modelu.

Na základe návrhov kódexu, v polovici 1970, bol vyvinutý systém R DBMS a do konca sa objavila podpora štandardizovaného jazyka sql dotazu.

V roku 1980, s prijatím objektovo orientovaného programovania, bolo čoraz ťažšie vysielať objekty na relačnom modeli. Nakoniec to viedlo k vzniku Nosql a Newsql tento moment Len rozvíjať. Príklady prístupu Nosql môžu byť tzv. Dokumentovo orientované databázy postavené na základe XML. Hlavnou výhodou Nosql je vysoká horizontálna škálovateľnosť, t.j. Schopnosť zvýšiť produktivitu pridaním serverov. S adventným technológia cloudNosql sa stal najmä v dopyte.

Avšak, relačného modelu zostáva najbežnejším, takže nám bývame na to podrobnejšie.

Relačný model

Relačný model pôsobí s koncepciami záznamov, atribútov a vzťahov. Pomer môže byť predstavený vo forme dvojrozmernej tabuľky, potom atribúty sú stĺpce stola (presnejšie, mená stĺpcov) a záznamy sú tabuľkové čiary.

Relačný model vyžaduje prísne stanovenie dátovej štruktúry uloženej v databáze, to znamená, že vzťahy a atribúty pre túto databázu sú stanovené.

Predstavujeme niektoré definície.

Doména je súprava obsahujúca kompletnú sadu všetkých možných hodnôt určitej premennej. Domény sa často tiež nazývajú dátový typ. Atribút objednal para názvy atribútov a doména (d_j \\). Zásielka je záverečná objednaná sada ((D_1, D_2, LDOTS, D_N)) Titul (diagram) Vzťahový pomer (A_1, A_2, LDOTS, A_N)), kde \\ (A_J) - Atribúty . Atribút Hodnota Špecifická hodnota, ktorá patrí do domény atribútu. Telo vzťahu je sada Noviniek, kde (d ^ i_J v d_j \\ (d_j \\) - domény. Záznamová zásielka ((d ^ i_1, d ^ i_2, ldots, d ^ i_n) \\ t s pevným (I). Pomer zbierky titulu vzťahu a vzťahov. Diagram databázy Viaceré schémy všetkých vzťahov zahrnuté v databáze.

Môžete odoslať vzťah vo forme tabuľky. Potom je telo vzťahu telo tabuľky, názov vzťahu - názov tabuľky, atribúty - mená stĺpcov, záznamov - reťazce a hodnoty atribútov sú v bunkách:

\\ (A_1 \\ t	(A_2)	(ldots)	(A_N)	← titulok
(D ^ 1_1 \\ t	(D ^ 1_2 \\ t	(ldots)	(D ^ 1_n \\)	← záznam
(D ^ 2_1 \\ t	(D ^ 2_2 \\)	(ldots)	(D ^ 2_n \\)	← záznam
(ldots)	(ldots)	(ldots)	(ldots)	← záznam
(D ^ m_1 \\ t	(D ^ M_2 \\)	(ldots)	(D ^ m_n)	← záznam

Relačný model ukladá nasledujúce dodatočné požiadavky na vzťahy:

Je zrejmé, že atribúty (presnejšie, ich hodnoty) sú nejako v závislosti od seba - inak je vzťah jednoducho neštruktúrovaný súbor údajov. Koncepcia sa používa na určenie závislostí medzi atribútmi funkčná závislosť.

Funkčná závislosť sady atribútov (B,) je funkčne závislá od množiny atribútov (A) (písomná (A \\ TRMORROW B \\)), ak pre všetky dva záznamy, ktoré majú rovnaké hodnoty (A), ich hodnoty (b) sa zhodujú. V opačnom prípade sa každá hodnota (A) zodpovedá jedinej hodnote (b) (nie nevyhnutne jedinečným, presne jediným).

Inými slovami, ak určitý súbor atribútov (a) jednoznačne určuje (v rámci tohto pomeru) hodnoty atribútov (b), potom (b /) sú funkčne závislé od \\ t a \\).

Ako známe príklad funkčnej závislosti, môžete citovať matematickú definíciu funkcie. Pre funkciu, každá hodnota argumentov zodpovedá jedinej hodnote funkcie. Bezprostredne nesprávne, napríklad pre funkciu (y \u003d hriech (x)), akákoľvek hodnota (Y) z oblasti definície (1 GEQ Y GEQ-1) zodpovedá nekonečnému súboru hodnôt (X), ale pre každú hodnotu (x) je presne jedna hodnota (y), tak (x do y). Upozorňujeme, že koncepcia funkčnej závislosti sa vzťahuje aj na funkcie mnohých premenných. Hodnota funkcie je funkčne závislá všetky argumenty v rovnakom čase. Napríklad pre funkciu (Z \u003d F (x, y)) sa vykonáva FZ (X, Y) až Z) alebo skrátene, \\ (XY \\ tO z).

Vzťahy v tejto súvislosti možno považovať za niektoré stôl alebo diskrétne funkcie.

Práca s fz.

Existujú určité formálne pravidlá pre prácu s vzťahom FZ.

Formálne pravidlá úzko súvisia s koncepciami uzáver a ireducible fz..

AXIOMS \u200b\u200bARMSTRONG

Existujú pravidlá pre stiahnutie nového fz z existujúcich, nazývaných aXIOMS \u200b\u200bARMSTRONG.

AXIOMS \u200b\u200bARMSTRONG

1. Pravidlo reflexivity: ak sú (b Spence A), potom (RightArrow b \\)
2. Doplnkové pravidlo: Ak sú (správne), potom (AC RightArrow BC)
3. Pravidlo tranzitu: ak sú (správne) a (B Rarmororow c), potom (správne c)

Z týchto osí sa môžu zobraziť aj nasledujúce dodatočné pravidlá:

1. Pravidlo o sebahodnotení: (A \\ TRMORROW A)
2. Pravidlo rozkladu: ak sú (správne), potom (správne) a) a \\ ta pravimrow c \\ t
3. Kombinácia Pravidlo: Ak sú (správne), a \\ (RightArrow C), potom (RightArrow BC)
4. Kompozimálne pravidlo: ak sú (správne) a (c), potom (AC RIMORROW BD)

Je možné vidieť, že vzhľadom na pravidlo odrazivosti, akýkoľvek súbor atribútov (A) znamená FZ formulára (A \\ t). Taký FZ, ako aj nasledujúci z nich, nepredstavujú úroky a nazývajú sa triviálne.

Triviálna funkcionálna závislosť FZ (A \\ t), taká, že (b \\ t).

V zásade sú tieto pravidlá dostatočné na nájdenie všetkých FZ, nasledovné z údajov. V tomto ohľade sa zavedie koncepcia uzatvorenia súborov FZ.

Uzavretie Set FZ uzatvorením sady FZ sa nazýva takáto množina FZ, ktorá zahŕňa všetky súbory zdroja FZ, ako aj všetky ich vyplývajúce. Inými slovami, pre vzťah (R \\), ktorý má funkčné závislosti (S), uzáver (s ^ +) sa nazýva súbor všetkých FZ, možný pre (R \\ T) (S \\).

Vyžaduje sa spravidla na zriadenie, či bude určitý FZ (X Rarrorororow y) tento súbor Fz (s). Ukazuje sa, že je možné potom a len vtedy, ak sa súbor atribútov (Y) je podmnožinou uzáveru atribútu (X ^ +) v \\ t

Atribúty obvodov (X ^ +) Atribúty (X ^ +) sú sada všetkých atribútov, ktoré sú funkčne závislé od akejkoľvek podmnožiny (X \\).

Na výpočet uzavretia viacerých atribútov (X ^ +) pozdĺž množiny FZ (S \\) existuje nasledujúce pravidlo: pre každý FZ (RightArrow B) v \\ t , ak sú (podmnožina x ^ +), potom (b / podmnožina x ^ +), a stačí začať s predpokladom, že (x ^ + \u003d x).

Treba poznamenať, že pre akékoľvek uzavretie (X ^ +), existuje FZ formulára (x b), kde (B podmnožina x ^ +), teda uzávery všetkých atribútov Vzťah podľa svojho FZ opisujú obvod fz tohto vzťahu.

Toto pravidlo sa používa na výpočet neredukovateľnej sady FZ ekvivalentu (v zmysle rovnocennosti ich uzáverov). Zníženie množstva FZ pri zachovaní uzáveru (a teda interná logika opísanom FZ je dôležitým krokom v konštrukcii databázy.

Sada FZ sa nazýva IREDECIBLE, ak:

1. Pravá strana každého FZ obsahuje len jeden prvok.
2. Nie je možné odstrániť žiadny atribút žiadnej ľavej časti fzovej súpravy bez zmeny uzáveru
3. NO FZ SET môžu byť odstránené bez zmeny uzáveru.

Pre ľubovoľné množstvo FZ existuje aspoň jeden ekvivalentný neredukovateľná sada. Takéto veľa sa volá minimálny náter.

Životný cyklus informačných systémov

Analýza situácie (zložitosť vývoja IP, nie účinné využívanie OP), ktorú vedci uskutočnili vedci, ukázalo, že toto ustanovenie bolo spôsobené tým, že softvér Nie je rešpektované veľmi dôležitými požiadavkami:

· Nedostatok úplnej špecifikácie všetkých požiadaviek;

· Neexistencia prijateľnej metodiky (systém metód) vývoja IP;

· Nedostatok zdieľania spoločného globálneho projektu do samostatných komponentov, ktoré môžu byť účinné kontroly a riadenie.

Životný cyklus (LCC) informačných systémov je štrukturálny prístup k vývoju softvéru.

(Určitá schéma) na 09/26/12

1. Plánovanie vývoja OP. Prípravné akcie, ktoré umožňujú maximálnu účinnosť na implementáciu stupňov IP LCC. Tri hlavné zložky: hodnotenie rozsahu práce; Posúdenie potrebných zdrojov; Posúdenie celkových nákladov projektu.

2. Stanovenie systémových požiadaviek. Určenie rozsahu akcií a hraniciach databázovej aplikácie, funkcií, zloženia jeho používateľov a aplikácií.

3. Zber a analýza užívateľských požiadaviek. Zber a analýza informácií o časti organizácie, ktorej práca bude podporovaná pomocou vytvorenej IP, definíciu užívateľských požiadaviek pre systém. Zdroje: anketa a prieskum; pozorovanie; Štúdium dokumentov; Predošlé skúsenosti.

4. Navrhovanie databázy. Vytvorenie databázového projektu. Dva hlavné prístupy k dizajnu databázových systémov: " nadol"A" vzostupný».

5. Výber cieľových DBMS. Výber vhodného typu DBMS určeného na podporu vytvorené aplikácie Databázy.

6. Vývoj aplikácií. Navrhovanie užívateľského rozhrania a aplikačných programov určených na prácu s databázou.

7. Vytvorenie prototypu. Vytvorenie pracovného modelu databázovej aplikácie.

8. Implementácia. Fyzická implementácia databázy a vyvinuté aplikácie.

9. Konverzia a zaťaženie dát. Prevod existujúcich údajov v nová základňa Údaje, sťahovanie a úprava existujúcich aplikácií na účely organizácie spolupráca s novou databázou.

10. Testovanie. Proces vykonávania aplikácií na vyhľadávanie chýb. Testované stratégie: testovanie smerom nadol; Vzostupné testovanie; Testovacie prúdy; Intenzívne testovanie.

11. Prevádzka a údržba. Monitorovanie systému a podpory jej normálneho fungovania: kontrolu výkonu; Sprievodné a modernizácie aplikácií.

Teória relačnej databázy

Terminológia

V roku 1970 bol relačný model prvýkrát navrhnutý napr. Kód.

Relačné DBMS predpokladá, že užívateľ vníma databázu ako súbor tabuliek (a nie taká inak).

Matematické vzťahy.

Teória relačnej databázy je založená na matematickej teórii vzťahov.

Nech D1, D2, ... DN niektoré súbory.

Cartesian Work D1 D2 ... DN \u003d ((X1, X2, ..., XN) X1 D1, X2 D2, ... XN DN)

Pomer je podskupina R D1 * D2 * ... * DN

Napríklad n \u003d 2, D1 \u003d (2,4) a D2 \u003d (1,3,5), D1 * D2 \u003d ((2,1), (2,3), (2,5), (4, 1) ), (4,3), (4.5)), R \u003d ((2,1), (4,1))

Podskupina m. B. Stav je uvedený napríklad:

R \u003d (((x1, x2) X1 D1, X2 D2, X2 \u003d 1), A1, A2, ... AT-Atribút Názvy s D1, D2 domén, ... VTB Potom napíšeme vzťah v Formulár:

R (A1: D1, A2: D2, ... An: DN)

Vlastnosti vzťahov:

· Postoj má jedinečný názov;

· Každý atribút má jedinečný názov (vo vzťahu k);

· Každá bunka vzťahu obsahuje iba atómovú hodnotu a žiadne opakované skupiny (pomer sa normalizuje);

D1 - Študenti
D2 - Disciplíny: Matematika, počítačová veda

· Objednávka atribútov nezáleží;

· Objednávka TUPOURE ABBITRALRY;

· Každá zásielka je jedinečná.

Relačné klávesy

Relačné kľúče sa podávajú jedinečne identifikovať kravatu popis kravatu medzi vzťahmi.

Relačnej integrity.

Relačné algebry

Výsledok operácie môže byť použitý ako operand pre inú operáciu, ktorá vám umožní vytvoriť vnorené výrazy (zatvorenie RA).

Relačná algebra je jazyk, v ktorom sú všetky cortices spracované jedným príkazom.

Päť hlavných operácií:

· Výber,

· Projekcia,

· Karteziánska práca,

· Združenie,

· Rozdiel.

Na základe týchto operácií je možné získať iné:

· Zlúčeniny

· Prechod,

· Odchod.

V predikáte sa môžu použiť príznaky logických operácií ^ (a), v (alebo), ~ (nie).

Príklad. Získajte zoznam všetkých zamestnancov s platom nad 300.

Projekcia.

Určuje postoj, ktorých atribúty sú APP1, ..., APR a obsahuje iba jedinečné príbehy.

Karteziánska práca

Karteziánska práca sa používa zriedka, výsledok aplikuje vzorku.

Združenie

Rozdiel

Operácie spojenia.

Teta Connection

Prirodzené pripojenie

Externé pripojenie

Potom vľavo externá zlúčenina Všetky počiatočné informácie sa udržiavajú z pomeru R. Podobne je možné určiť správne vonkajšie spojenie.

Alpinácia

Alumni prevádzka sa dá určiť pomocou projekčných a zložených operátorov.

Križovatka

Zastúpenie

Vymenovanie:

· Poskytuje flexibilný mechanizmus ochrany databázy v dôsledku utajenia niektorých jeho časti Špecifickí používatelia;

· Umožňuje organizovať prístup užívateľa k údajom, ktorý je pre nich najvhodnejší;

· Umožňuje zjednodušiť komplexné operácie so základnými vzťahmi.

Pravidlá, ktoré by mali uspokojiť
Relačné DBMS

Určiť, či SUBO relačný kód (1985) navrhol 13 pravidiel, na ktoré by mali uspokojiť.

№		Pravidlo
		Základné pravidlo. Relačné DBMS musia byť schopné kontrolovať databázy výlučne s pomocou svojich relačných funkcií.
		Prezentácia informácií. Všetky informácie v relačnej databáze sú výslovne založené na logickej úrovni len jedným spôsobom - vo forme hodnôt v tabuľkách. Vrátane metaúdajov.
		Garantovaný prístup. Pre každý prvok relačnej databázy, logický prístup založený na kombinácii tabuľky, hodnoty primárneho kľúča a názvu stĺpca musia byť zaručené.
		Podporte neisté hodnoty. DBMS podporuje neisté hodnoty (null).
		Relačný systém. Popis databázy by mal byť v logickej úrovni takým spôsobom ako bežné údaje, ktoré umožňujú používateľom používať rovnaký vzťah relačného jazyka na ich odvolanie.
		Úplné údaje. Relačné DBMS môže podporovať niekoľko jazykov. Avšak, jeden jazyk by mal existovať v extrémnom opatrení, ktorých prevádzkovatelia by umožnili nasledujúce funkcie: 1. Definícia údajov; 2. Definícia zastúpení; 3. príkazy manipulácie; 4. Obmedzenia integrity; 5. Povolenie používateľa; 6. Organizácie transakcií
		Extrakcia na vysokej úrovni, vložte, odstrániť, aktualizácie. Schopnosť DBMS vykonávať operácie na extrahovanie týchto príkazov vkladania, odstrániť a aktualizovať ako jednu operáciu.
		Fyzickú nezávislosť od údajov. Z metódy ukladania
		Logická nezávislosť od údajov. Nezávislosť aplikácií z meniacich sa základných tabuliek.
		Nezávislosť obmedzení integrity. Obmedzenia integrity by sa mali určiť na postoje relačných údajov a uložené v adresári systému, a nie v aplikačných programoch.
		Nezávislosť od distribúcie dát.
		Pravidlo zakazujúce bypass trakt. Ak má DBMS nízky jazyk (s konzistentným spracovaním riadkov), nemalo by to umožniť pravidlá a obmedzenia integrity opísanej v relačnom jazyku na vysokej úrovni.

Modelové údaje na základe procesu normalizácie

Cieľom normalizácie.

Proces normalizácie bol navrhnutý v roku 1972 E. F. CODD - Tri normálne formy (NF): prvý (1NF), druhý (2NF) a tretí (3. nová).

Výraznejšia definícia tretieho NF (R. BOIS a E. F. CODD, 1974) je normálna forma chlapcov CODD (NFBC).

Redundancia dát a anomálie.

Absencia normalizácie vedie:

· Redundancia údajov

· Inzercia Anomálie (nie je možné pridať záznamy)

· Odstránenie anomálie (iné informácie sa stratia pri vymazaní informácií)

· Aktualizovať anomálie (aktualizácia Mnohé záznamy sú povinné)

· Ochranné vlastnosti bez straty a ochrany závislosti.

Funkčné závislosti

Databáza - súbor súvisiacich údajov organizovaných určitými pravidlami zahŕňajúcimi všeobecné zásady Popisy, skladovanie a manipulácia, nezávislá od aplikačných programov. Relačná databáza je databáza, v ktorej sú informácie uvedené vo forme dvojrozmerných tabuliek uložených v súboroch. Tabuľka sa skladá z čiar nazývaných záznamov, záznamy sa skladajú zo stĺpcov, nazývaných polia.

Systém správy databázy (DBMS) je celkom jazyka a softvérurčené na vytvorenie, udržanie a zdieľanie BD mnohými používateľmi. Užívatelia DBMS možno rozdeliť do troch veľkých skupín:

• vývojári databázy sú zodpovední za písanie aplikácií pomocou databázy;
• koncový užívatelia pracujú s databázou alebo prostredníctvom určitého informačného systému, alebo užívateľského rozhrania systému správy databázy;
• administrátori databázy zabezpečujú údržbu výkonu databázy, bezpečnosti údajov a bezpečnosť, operáciu databázy.

Základná architektúra DBMS je trojvrstvový model, v ktorom sa zdá, že DBMS sa skladajú z externej, koncepčnej a vnútornej úrovne. Na vonkajšej úrovni sa zdá, že obsah DBMS vidí samostatný používateľ. Na koncepčnej úrovni sú údaje DBMS opísané vo všeobecnom modeli oblasti predmetu, pre ktorú je vytvorený informačný systém. Vnútorná úroveň sú skutočné údaje nachádzajúce sa v súboroch. DBMS sa tiež uskutočňuje dátový slovník obsahujúci informácie o všetkom, čo je uložené v databáze (mená všetkých tabuliek a reprezentácií, uložených postupov a spúšťačov, Účtovníctvo Používatelia DBMS atď.). Tento druh informácií sa nazýva metadáta.

Model relačného dát je založený na matematických princípoch teórie súprav a matematickej logiky. Tieto zásady boli najprv použité na modelovanie údajov v 60. rokoch minulého storočia CODD. Relačný model určuje, ako môžu byť údaje prezentované (dáta štruktúra), ako môžu byť údaje chránené pred nesprávnymi zmenami (integrita údajov) a ktoré operácie môžu byť vykonané s údajmi (dátové transakcie). Základné pojmy relačného modelu:

• všetky údaje sú koncepčne reprezentované ako objednaný súbor riadkov a stĺpcov, nazývaný pomer;
• všetky údaje sú skalárne;
• dátový riadok sa nazýva n-ticu, počet nôh sa nazýva základné číslo;
• každý stĺpec v taverne sa nazýva atribút, počet atribútov sa nazýva stupeň vzťahu;
• nulové informácie nie sú opísané žiadne informácie;
• potenciál Key K pre R pomeru je podmnožina množiny atribútov R, vždy majú vlastnosť jedinečnosti (to znamená, že nie sú žiadne dve tresle vo vzťahu k R s rovnaká hodnota K) a neopúšťanie majetku (t.j. Nie z podskupín K nemu nemá majetok jedinečnosti). Potenciálny kľúč pozostávajúci z viac ako jedného atribútu sa nazýva zlúčenina a z jedného jednoduchého. Primárnym kľúčom je potenciálny kľúč, v ktorom sú cortices fyzicky objednané.
• externý kľúč je definovaný nasledovne. Nech R2 je nejakým postojom. Potom externý kľúč FK vzhľadom na R2 je podskupina množiny atribútov R2, že je pomer R1 s potenciálnym kľúčom K, a hodnota FK v akomkoľvek R2 R2 sa vždy zhoduje s hodnotou K nejakého Cortery v R1 . Obmedzenie, pomocou ktorých musia byť externé kľúčové hodnoty primerané na hodnoty zodpovedajúceho potenciálneho kľúča, sa nazývajú referenčný limit. V súlade s tým, pod referenčnou integritou, je zrejmé, že požiadavka, ktorá v databáze neexistovala poruchy referenčných obmedzení.

Nasledujúce operácie sú prípustné na údajoch v relačnom modeli:

• vzorka vráti vzťah obsahujúci všetky cortices daného pomeru, ktoré spĺňajú určité podmienky;
• projekcia vráti vzťah obsahujúci všetky cortices určeného vzťahu po vylúčení niektorých atribútov z nej;
• produkt vráti vzťah obsahujúci Novinky, ktoré sú všetky možné kombinácie TVP patriacich do dvoch zdrojových vzťahov;
• združenie vráti vzťah obsahujúci všetky príbehy patriace do dvoch zdrojových vzťahov;
• zlúčenina vráti vzťah, ktorým je pripojenie dvoch trubiek, ktoré patria k zdrojovému vzťahu a majú všeobecnú hodnotu pre jeden alebo viac atribútov zdroja vzťah; V tomto prípade sa celková hodnota atribútov nachádza v konštrukčnom n-nite len raz.

Programovanie v strednom prostredí Delphi 6

Databázy. Vytvorenie správy S. pomocou slova..

SCHVÁLENÉ ROZDELENÍM REZERVOVANÍ

univerzita ako laboratórny dielňa

Voronezh 2004.

UDC 681.3.

Vorobyov E.I., Korotkhevich de .. Programovanie streda Delphi 6: Laboratórna dielňa: CH. 2: Databázy. Vytvorenie prehľadu pomocou programu Word. Vlákna. Voronezh: Voronezh. Štát tehn Univerzita, 2004. 107 p.

V druhej časti laboratórnej dielne sa teoretické a praktické informácie považujú za písanie programov v prostredí Delphi 6 na tému: "Design databázy, vytváranie správ program Word A používanie prúdov pri vytváraní vysoko výkonných aplikácií. "

Publikácia je v súlade s požiadavkami štátneho vzdelávacieho štandardu vyššieho odborného vzdelávania v smere 230100 "informatiky a výpočtovej techniky", špeciálnych 230104 "automatizovaných dizajnových systémov", disciplíny "Programovanie v jazykoch na vysokej úrovni".

Tabuľka. 3. IL. 19. BiBLIGR.: 7 Pomenované.

Vedecký editor: Dr. Tehn. Sciences, prof. Ya.e. Lvovich

Recenzenti: Oddelenie počítačové vybavenie Voronezh Lesnícke akadémie (hlava. Katedra Dr. Tekhn. Sciences, prof. V.e. Mezhov);

dr. Tech. Sciences, prof. O.yu.makarov

© Vorobyov E.I., Korotkhevich D.E., 2004

© Design. Voronezh State

technická univerzita, 2004

Úvod

Databázový koncept

Databázy sa považujú za hlavnú výhodu Delphi. Dokonca aj špecializované jazyky pre prácu s databázami (napr. MS Vizuálne foxpro.) Je zrejme horší ako jednoduchosť a relikvie programovania tohto typu aplikácií. Delphi skrýva všetky ťažkosti a zároveň dáva najväčšiu moc. Nebola takáto úloha, ktorá by nebola schopná realizovať na Delphi v krátkom časovom období. A čo je najdôležitejšie, že všetko je implementované veľmi pohodlné a ľahko pochopiteľné. V DELPHI môžete vytvoriť jednoduché aplikácieDokonca aj s komplexnými základňami, bez jedného riadku kódu. V tomto návod Laboratórne úlohy sa považujú za zvládnutie techník na prácu s miestnymi databázami.

Teória relačných databáz

Pred desiatimi rokmi bolo programovanie databáz veľmi ťažké povolanie. Teraz je už ťažké si predstaviť, že, pretože vďaka Delphi, proces písania programov bol zjednodušený, a počet databázových odrôd je už vo výške desiatok.

Databázy sú rozdelené do lokálneho (nainštalovaného počítača klienta, kde program funguje aj) a vzdialený (nainštalovaný na serveri, vzdialený počítač). Serverová základňa Údaje sa nachádzajú na vzdialenom počítači a prevádzkujú spustený server softvér. Na ich hlavné výhody môžete pripisovať schopnosť pracovať s jednou databázou súčasne viac používateľov, a zároveň sa vykonáva minimálne zaťaženie siete. Existujú stále sieťové databázy, ktoré vytvárajú príliš veľa záťaže na sieť a nepohodlné v programátorovi aj koncovému používateľovi. Keď sa program pripojí k databáze siete, čerpá takmer kompletnú kópiu zo servera. Ak ste vykonali zmeny, vaša kópia je úplne čerpaná. Je to veľmi nepríjemné, pretože je vytvorené. obrovský tlak V sieti spôsobené nadmerným čerpaním údajov. Keď klient-server technológia, klientský program pošle jednoduchú požiadavku na text na server, aby dostal všetky údaje. Server spracuje a vracia iba požadovanú dátovú časť. Ak potrebujete znova zmeniť akékoľvek údaje, požiadavka na server je odoslaná na zmenu servera a server mení dáta v databáze. Tak, cez sieť, existujú len textové žiadosti o sieti, ktoré zaberá menej kilobajtu. Všetky dáta spracováva server, čo znamená, že klientský stroj je načítaný oveľa menej a nie toľko náročný na zdroje. Server pošle klientovi iba tie najvýznamnejšie údaje, čo znamená, že nie je potrebné zbytočné čerpanie kópií celej základne. Vďaka tomu všetkému sú sieťové databázy už zastarané a prakticky nepoužívajú. Takmer úplne vytlačí technologický klient-server. Miestne databázy však vždy budú žiť. Môže existovať formát skladovania alebo pridať nové funkcie, ale samotné databázy budú existovať. Pre ďalšie zváženie musíme definovať novú koncepciu - stôl. Doteraz uviedli len všeobecné zásady, takže sa použil všeobecný koncept databázy. Tabuľka databázy je ako dvojrozmerné pole, v ktorom sú vytvorené údaje v stĺpci (jasný príklad tabuľky - Excel). Databáza - zhruba hovoriť, je to len súbor, v ktorom môže byť uložený z jedného na niekoľko tabuliek. Väčšina miestnych databáz môže uložiť iba jednu tabuľku (DBASE, Paradox, XML). Existujú však zástupcovia lokálnych databáz, kde sa v jednom súbore uzatvára niekoľko tabuliek (napríklad prístup).

Miestne databázy

Z miestnych databáz považujeme reláciu ako najbežnejšie. Čo je to relačná databáza? Toto je tabuľka, v ktorej sú názvy údajov uložených v nej sú ako stĺpce a každý riadok ukladá samotné údaje. Databázová tabuľka je podobná elektronike tabuľka programu Excel (Ak chcete byť presnejší, potom Excel ukladá svoje údaje vo forme vlastný formátna základe databázovej technológie). Miestne databázové tabuľky je možné uložiť na lokálnom pevnom disku alebo centrálne uložených sieťový disk súborový server. Tieto súbory je možné kopírovať pomocou Štandardné nástroje Rovnako ako akýkoľvek iný súbor, pretože samotné databázové tabuľky nie sú viazané na konkrétne miesto. Hlavnou vecou je, že program môže nájsť tabuľku. Každá tabuľka by mala byť jedinečné pole, ktoré určite identifikuje reťazec. Toto pole sa nazýva kľúč. Tieto polia sú veľmi často používané na viazanie viacerých tabuliek medzi sebou. Ale aj keď tabuľka nie je pripojená, pole kľúčov je stále potrebné. Odporúča sa použiť ako kľúč Číselný typ A ak databáza umožňuje, bude lepšie, ak ide o typ "autoincrement" (automaticky zvyšuje / znižuje číslo alebo merač). Názvy stĺpcov v tabuľke databázy by mali byť tiež jedinečné, ale v tomto prípade nie nevyhnutne numerické. Môžu byť povolaní, ako sa vám páči, ak to bolo len jedinečné a zrozumiteľné. Každý stĺpec (databázové pole) musí mať definovaný typ. Počet typov a ich typy závisí od typu databázy, ako je formát DBASE (súbory s rozšírením DBF) Podpora iba 6 typov a Paradox je už až 15. Databáza môže byť uložená v jednom súbore (prístup) alebo v niekoľkých (Paradox, DBASE). Presnejšie povedané, tieto tabuľky sú vždy uložené v jednom súbore, ale môžu byť umiestnené ďalšie informácie samostatné súbory. Ako pre viac informácií Môžu existovať indexy, obmedzenia alebo zoznam predvolených hodnôt pre konkrétne polia. Ak je aspoň jeden zo súborov pokazený alebo odstránený, dáta môžu byť neprístupné na úpravu.

Čo indexy? Veľmi často sú údaje z tabuliek vystavené niektorým zmenám, takže pred úpravou nad ľubovoľným reťazcom, musíte ho nájsť. Dokonca aj statické tabuľky použité ako adresáre sú tiež vystavené vyhľadávaniu pred výstupom požadovaných údajov. Hľadanie je pomerne časovo náročné, najmä ak tabuľka obsahuje veľa riadkov. Indexy sú zamerané na urýchlenie tohto postupu, ako aj pri triedení možno použiť ako východiskový bod. V tomto štádiu stačí vedieť, že neindexované pole nie je možné zefektívniť.

V prípade potreby tak, aby sa určitá tabuľka objednala poľa " Priezvisko"Toto pole musí byť prvýkrát napísané. Potom potrebujete špecifikovať, že tabuľka musí pracovať teraz s takým indexom a automaticky sa triedi.

V dobre navrhnutej databáze je redundancia údajov vylúčená a pravdepodobnosť rozporných údajov je minimalizovaná. Tvorba databáz je teda dva hlavné ciele: znížiť redundanciu údajov a zvýšiť ich spoľahlivosť.

Životný cyklus akéhokoľvek softvérového produktu, vrátane systému správy databázy, je (veľký) z etáp dizajnu, predaja a prevádzky.

Prirodzene, najvýznamnejší faktor v Životný cyklus Aplikácie pracujúce s databázou sú štádium dizajnu. Z toho, ako starostlivo je štruktúra základne uvažovaná, ako jasne sú prepojenia medzi jeho prvkami určené, výkon systému a jeho informačný sýtosť, a preto čas jeho života závisí.

Požiadavky na databázu

Takže, dobre navrhnutá databáza:

1. spĺňa všetky požiadavky používateľa pre obsah databázy. Pred navrhovaním základne je potrebné vykonať rozsiahle štúdie užívateľských požiadaviek na fungovanie databázy.

2. Zaručuje konzistenciu a integritu údajov. Pri navrhovaní tabuliek musíte definovať svoje atribúty a niektoré pravidlá, ktoré obmedzujú možnosť zadania nesprávneho hodnoty používateľa. Na overenie údajov pred nasmerovaním do tabuľky by sa databáza mala nazvať pravidlá modelu údajov, čím sa zabezpečí zachovanie integrity informácií.

3. Poskytuje prirodzené, ľahko vnímajúce štruktúrovanie informácií. Kvalitatívna konštrukcia základne vám umožňuje vykonať žiadosti o databázu viac "transparentné" a jednoduché pochopenie; Preto je znížená pravdepodobnosť nesprávnych údajov a zlepšená sa kvalita základnej podpory.

4. Usporučí požiadavky používateľov pre výkon databázy. S veľkými množstvami informácií, otázky ochrany produktov

začnite hrať hlavnú úlohu, okamžite "zvýraznenie" všetkých nedostatkov dizajnu fázy.

Nasledujúce položky predstavujú hlavné kroky dizajnu databázy:

1. Určite potreby informácií o databáze.

2. Analyzujte objekty skutočného sveta, ktoré je potrebné modelovať v databáze. Tvoriť podstatu a charakteristiku týchto subjektov z týchto objektov (napríklad pre entity "časť" Charakteristiky môžu byť "meno", "farba", "hmotnosť" atď.) A tvoriť ich zoznam.

3. V súlade s subjektmi a charakteristikami - tabuľky a stĺpce (polia) v notácii vybraných DBMS (Paradox, DBASE, FOXPRO, Access, Clipper, Interbase, Sybase, Informix, Oracle atď.).

4. Určite atribúty, ktoré jednoznačne identifikujú každý objekt.

5. Vypracovať pravidlá, ktoré vytvoria a udržiavajú integritu údajov.

6. Inštalácia odkazov medzi objektmi (tabuľkami a stĺpcami), aby sa tabuľky normalizovali.

7. Plánujte otázky spoľahlivosti údajov av prípade potreby zachovájte utajenie informácií.

Podobné informácie.