Anotācija: Šī un nākamās divas lekcijas ir veltītas relāciju datu bāzu teorijai. Tā kā visa relāciju pieeja datu bāzes organizēšanai ir tīri praktiska, šī teorija galvenokārt ir pragmatiska. Galvenā problēma, ko tiecas atrisināt relāciju datu bāzu teorija, ir noteiktu datu bāzes shēmu noderīgo īpašību atklāšana un šādu shēmu konstruēšanas veidu izstrāde. Šo problēmu parasti īsi dēvē par relāciju datu bāzes projektēšanas problēmu.

Ievads

Neskatoties uz praktisko ievirzi, relāciju datu bāzes teorija ir neatkarīga zinātnes nozare, kurā strādājuši (un turpina strādāt) daudzi slaveni pētnieki, kuru vārdi parādīsies mūsu lekcijās. Mēs neplānojām šajā kursā detalizēti aprakstīt galvenos rezultātus šajā jomā. Mūsu mērķis ir sniegt tikai tās definīcijas un apgalvojumus, kas nepieciešami vispārējai procesa izpratnei relāciju datu bāzes dizains pamatojoties uz normalizāciju.

Tā kā svarīgākās relāciju datu bāzu īpašības no praktiskā viedokļa ir balstītas uz koncepciju funkcionālā atkarība, esam iekļāvuši īsu attiecīgo teorētisko jautājumu iztirzājumu atsevišķā lekcijā. Starp šiem jautājumiem, slēgšanas un kas aptver funkcionālo atkarību kopas, Ārmstronga aksiomas un Hīta teorēma par pietiekamu nosacījumu bezzudumu attiecību sadalīšanās. Šīs lekcijas jēdzieni un apgalvojumi ir patiešām nepieciešami 7. lekcijas materiāla apguvei, taču mēs arī centāmies ar vienkāršiem piemēriem parādīt lasītājiem, kas tas ir relāciju datu bāzes teorija, kāds ir tā sarežģītības līmenis un cik tas ir intuitīvs.

Ņemiet vērā, ka mēs nedalījām teorētisko materiālu par daudzvērtību atkarības Un savienojuma atkarības. Tas tika darīts divu iemeslu dēļ. Pirmkārt, šāda veida atkarības modelēšanā ir retāk sastopamas priekšmeta joma izmantojot datu bāzes. Tāpēc uzskatījām par pietiekamu 8. lekcijas ietvaros izklāstīt tikai attiecīgā teorētiskā materiāla pamatus. Otrkārt, lai gan teorija daudzvērtību atkarības Un savienojuma atkarības, patiesībā, nav daudz sarežģītāks par teoriju funkcionālās atkarības, tā definīcijas un apgalvojumi ir pārāk apgrūtinoši šim kursam.

Funkcionālās atkarības

Pats svarīgākais no praktiskā viedokļa normālas attiecību formas ir balstīti uz fundamentāliem relāciju datu bāzu teorijas koncepcija funkcionālā atkarība. Tālākai prezentācijai mums būs nepieciešamas vairākas definīcijas un apgalvojumi (mēs tos paskaidrosim un ilustrēsim, turpinot).

Vispārīgas definīcijas

Lai tas tiek dots attiecību mainīgais r , un X un Y ir patvaļīgas r galvenes apakškopas (“saliktie” atribūti).

Pēc nozīmes attiecību mainīgais r atribūts Y ir funkcionāli atkarīgs no atribūta X tad un tikai tad, ja katra X vērtība atbilst tieši vienai Y vērtībai. Šajā gadījumā tiek arī teikts, ka atribūts X funkcionāli definē atribūts Y (X ir determinants ( noteicējs) Y, un Y ir atkarīgs no X). Mēs to apzīmēsim kā r.X->r.Y .

Piemēram, mēs izmantosim attiecību EMPLOYEE_PROJECTS (SLUN_NAME, SLU_NAME, SLU_ZARP, PRO_NOM, PROJECT_RUK)(6.1. att.). Acīmredzot, ja SLU_NOM ir attiecību primārā atslēga DARBINIEKI, tad šīm attiecībām tas ir godīgi funkcionālā atkarība (FD) SLN_NAME->SERV_NAME .

Patiesībā attiecību ķermenim EMPLOYEES_PROJECTS tādā formā, kādā tas parādīts attēlā. 6.1, tiek izpildīti arī šādi FD (1):

Rīsi. 6.1.

SLUN_NOM->SLUN_NAME SLUN_NOM->SLUN_ZARP SLU_NOM->PRO_NOM SLUN_NOM->PROJECT_RUK (SLUN_NAME, SLU_NAME)->SLUN_ZARP (SLUN_NAME, SLUN_NAME)->PRO_NOM (SLUN_NAME) ->PROJECT_RUK un utt.

Tā kā visu darbinieku vārdi ir atšķirīgi, ir izpildīti arī šādi FD (2):

SERV_NAME->SERV_NAME SERV_NAME->SLU_ZARP SER_NAME->PRO_NAME utt.

Turklāt, piemēram, attēlā. 6.1 ir izpildīts un FD (3):

SLU_ZARP->PRO_NOM

Tomēr ņemiet vērā, ka FD grupas (1) raksturs atšķiras no FD grupu (2) un (3) rakstura. Loģiski ir pieņemt, ka darbinieku identifikācijas numuriem vienmēr jābūt atšķirīgiem un katram projektam ir tikai viens vadītājs. Tāpēc (1) grupas FD ir jābūt patiesiem jebkurai derīgai vērtībai attiecību mainīgais EMPLOYEES_PROJECTS un to var uzskatīt par invarianti, vai integritātes ierobežojumišis attiecību mainīgais.

Grupas FD (2) balstās uz mazāk dabisku pieņēmumu, ka visiem darbiniekiem ir dažādi vārdi. Tas attiecas uz piemēru attēlā. 6.1, bet iespējams, ka laika gaitā FD grupas (2) netiks apmierinātas nevienai vērtībai attiecību mainīgais EMPLOYEES_PROJECTS.

Visbeidzot, 3. grupas FD ir balstīts uz ļoti nedabisku pieņēmumu, ka divi dažādos projektos iesaistītie darbinieki nesaņem vienādu algu. Atkal, šis pieņēmums attiecas uz piemēru attēlā. 6.1, bet visticamāk tā ir sakritība.

Nākotnē mūs interesēs tikai tie funkcionālās atkarības, kas jāizpilda visām iespējamām vērtībām attiecību mainīgie.

Ņemiet vērā: ja relācijas r atribūts A ir iespējamā atslēga, tad jebkuram šīs attiecības atribūtam B tas vienmēr ir spēkā

PROGRAMMĒŠANA DELPHI 6 VIDĒ

Datu bāze. Izveidojiet pārskatu, izmantojot programmu Word.

Apstiprinājusi Redakcijas un izdevējdarbības padome

universitāte kā laboratorijas darbnīca

Voroņeža 2004

UDK 681.3

Vorobjovs E.I., Korotkevičs D.E.. Programmēšana Delphi 6 vidē: Laboratorijas darbnīca: 2.daļa: Datu bāzes. Izveidojiet pārskatu, izmantojot programmu Word. Straumes. Voroņeža: Voroņeža. Valsts tech. Univ., 2004. 107 lpp.

Laboratorijas darbnīcas otrajā daļā tiek apspriesta teorētiskā un praktiskā informācija programmu rakstīšanai Delphi 6 vidē par tēmu: “Datu bāzu projektēšana, atskaišu veidošana Word un pavedienu izmantošana, veidojot augstas veiktspējas aplikācijas”.

Izdevums atbilst valsts augstākās profesionālās izglītības standarta 230100 virziena “Informātika un datorzinātnes” specialitātes 230104 “Datorizētās projektēšanas sistēmas” disciplīnas “Programmēšana augsta līmeņa valodās” prasībām.

Tabula 3. Il. 19. Bibliogrāfija: 7 nosaukumi.

Zinātniskais redaktors: Dr. Tech. zinātnes, prof. Jā.E. Ļvovičs

Recenzenti: Voroņežas Meža akadēmijas Datorzinātņu katedra (katedras vadītājs, tehnisko zinātņu doktors, prof. V.E. Mežovs);

Dr Tech. zinātnes, prof. O.Ju.Makarovs

© Vorobjovs E.I., Korotkevičs D.E., 2004

© Dizains. Voroņežas štats

Tehniskā universitāte, 2004

Ievads

Datu bāzes koncepcija

Datu bāzes tiek uzskatītas par galveno Delphi priekšrocību. Pat specializētās valodas darbam ar datu bāzēm (piemēram, MS Visual FoxPro) ir acīmredzami zemākas vienkāršības un programmēšanas jaudas ziņā šāda veida lietojumprogrammām. Delphi slēpj visu sarežģītību un tajā pašā laikā dod vislielāko spēku. Nekad nav bijis tāda uzdevuma, ko Delfos nevarētu īstenot īsā laika periodā. Un galvenais, ka tas viss tiek īstenots ļoti ērti un viegli saprotami. Delphi varat izveidot vienkāršas lietojumprogrammas, pat ar sarežģītām datu bāzēm, bez vienas koda rindiņas. Šī apmācība aptver laboratorijas uzdevumus, lai apgūtu metodes darbam ar vietējām datu bāzēm.

Relāciju datu bāzes teorija

Pirms desmit gadiem datu bāzes programmēšana bija ļoti grūts uzdevums. Mūsdienās to ir grūti iedomāties, jo, pateicoties Delphi, programmu rakstīšanas process ir vienkāršots, un datu bāzes šķirņu skaits jau ir desmitiem.

Datu bāzes tiek iedalītas lokālajās (instalētas klienta datorā, kur darbojas programma) un attālinātās (instalētas serverī, attālajā datorā). Serveru datu bāzes atrodas attālā datorā un darbojas servera programmatūras kontrolē. To galvenās priekšrocības ir iespēja strādāt ar vienu datu bāzi vienlaikus vairākiem lietotājiem, un tajā pašā laikā tīklam ir minimāla slodze. Ir arī tīkla datu bāzes, kas rada pārāk lielu slodzi tīklam un ir neērti lietot gan programmētājam, gan gala lietotājam. Kad programma izveido savienojumu ar tīkla datu bāzi, tā lejupielādē gandrīz pilnīgu tās kopiju no servera. Ja veicāt izmaiņas, jūsu kopija tiks pilnībā lejupielādēta atpakaļ. Tas ir ļoti neērti, jo rada lielu tīkla slodzi pārmērīgas datu pārsūtīšanas dēļ. Klienta-servera tehnoloģijā klienta programma nosūta serverim vienkāršu teksta pieprasījumu, lai saņemtu dažus datus. Serveris to apstrādā un atgriež tikai nepieciešamo datu daļu. Kad ir jāmaina daži dati, serverim atkal tiek nosūtīts pieprasījums tos mainīt, un serveris maina datus savā datubāzē. Tādējādi tīklā galvenokārt tiek pārsūtīti tikai teksta pieprasījumi, kas parasti aizņem mazāk nekā kilobaitu. Visus datus apstrādā serveris, kas nozīmē, ka klienta mašīna tiek noslogota daudz mazāk un nav tik prasīga resursiem. Serveris klientam nosūta tikai visnepieciešamākos datus, kas nozīmē, ka nav nevajadzīgas visas datu bāzes kopijas lejupielādes. Pateicoties tam visam, tīkla datu bāzes jau ir novecojušas un praktiski netiek izmantotas. Tos gandrīz pilnībā aizstāj klienta-servera tehnoloģija. Bet vietējās datu bāzes vienmēr darbosies. To uzglabāšanas formāts var mainīties vai var tikt pievienotas dažas jaunas funkcijas, bet pašas datu bāzes pastāvēs. Tālākai apsvēršanai mums ir jādefinē jauns jēdziens - tabula. Līdz šim ir apspriesti tikai vispārīgie principi, tāpēc tika izmantots vispārīgais jēdziens datubāzēm. Datu bāzes tabula ir kā divdimensiju masīvs, kurā dati ir sakārtoti kolonnā (spilgtākais tabulas piemērs ir Excel). Datubāze, rupji runājot, ir tikai fails, kurā var saglabāt no vienas līdz vairākām tabulām. Lielākā daļa vietējo datu bāzu var saglabāt tikai vienu tabulu (dBase, Paradox, XML). Bet ir vietējo datu bāzu pārstāvji, kur vienā failā ir vairākas tabulas (piemēram, Access).

Vietējās datu bāzes

No vietējām datu bāzēm kā visizplatītākās uzskatīsim relāciju datu bāzes. Kas ir relāciju datu bāze? Šī ir tabula, kurā kolonnas ir tajā saglabāto datu nosaukumi, un katrā rindā tiek glabāti paši dati. Datu bāzes tabula ir līdzīga Excel izklājlapai (precīzāk, Excel savus datus saglabā patentētā formātā, kas izveidots, izmantojot datu bāzes tehnoloģiju). Vietējās datu bāzes tabulas var glabāt lokālajā cietajā diskā vai centralizēti glabāt tīkla diskā failu serverī. Šos failus var kopēt, izmantojot standarta rīkus tāpat kā jebkuru citu failu, jo pašas datu bāzes tabulas nav piesaistītas noteiktai vietai. Galvenais, lai programma var atrast tabulu. Katrā tabulā ir jābūt vienam unikālam laukam, kas unikāli identificēs rindu. Šo lauku sauc par atslēgas lauku. Šos laukus ļoti bieži izmanto, lai savienotu vairākas tabulas. Bet pat tad, ja tabula nav saistīta, atslēgas lauks joprojām ir nepieciešams. Kā atslēgu vēlams izmantot ciparu tipu, un, ja datu bāze atļauj, labāk būs “autoincrement” tipa (automātiski pieaugošs/samazinošs skaitlis vai skaitītājs). Kolonnu nosaukumiem datu bāzes tabulā arī jābūt unikāliem, taču šajā gadījumā ne obligāti skaitļiem. Tos var saukt kā gribi, ja vien tas ir unikāli un saprotami. Katrai kolonnai (datu bāzes laukam) ir jābūt noteiktam tipam. Veidu skaits un to šķirnes ir atkarīgs no datu bāzes veida, piemēram, dBASE formāts (faili ar paplašinājumu DBF) atbalsta tikai 6 veidus, bet Paradox jau atbalsta līdz 15. Datu bāzi var glabāt vienā failā (Piekļuve ) vai vairākos (Paradox, dBase). Precīzāk, tabulas dati vienmēr tiek glabāti vienā failā, bet papildu informācija var atrasties atsevišķos failos. Papildu informācija var ietvert indeksus, ierobežojumus vai noklusējuma vērtību sarakstu konkrētiem laukiem. Ja vismaz viens no failiem tiek bojāts vai dzēsts, dati var kļūt nepieejami rediģēšanai.

Kas notika indeksi? Ļoti bieži tabulu datos tiek veiktas zināmas izmaiņas, tāpēc pirms jebkuras rindas rediģēšanas tā ir jāatrod. Pat statiskās tabulas, kas tiek izmantotas kā atsauces grāmatas, arī tiek pakļautas meklēšanas darbībām pirms pieprasīto datu parādīšanas. Meklēšana ir diezgan laikietilpīga darbība, it īpaši, ja tabulā ir daudz rindu. Indeksi ir paredzēti, lai paātrinātu šo procedūru, un tos var izmantot arī kā šķirošanas sākumpunktu. Šajā posmā pietiek zināt, ka neindeksētu lauku nevar pasūtīt.

Ja jums ir nepieciešams kāds galds, kas jāpasūta pēc lauka " Uzvārds", tad šis lauks vispirms ir jāindeksē. Tad tikai jānorāda, ka tabulai tagad jāstrādā ar tādu un tādu indeksu, un tā tiks sakārtota automātiski.

Labi izstrādātā datu bāzē tiek novērsta datu dublēšana un līdz minimumam samazināta nekonsekventu datu glabāšanas iespējamība. Tādējādi datu bāzu izveidei ir divi galvenie mērķi: samazināt datu dublēšanu un palielināt to uzticamību.

Jebkura programmatūras produkta, tostarp datu bāzes pārvaldības sistēmas, dzīves cikls (lielākoties) sastāv no projektēšanas, ieviešanas un darbības posmiem.

Protams, vissvarīgākais faktors datu bāzes lietojumprogrammas dzīves ciklā ir projektēšanas posms. Sistēmas veiktspēja un informācijas bagātība un līdz ar to kalpošanas laiks ir atkarīgs no tā, cik rūpīgi ir pārdomāta datu bāzes struktūra un cik skaidri ir definētas tās elementu attiecības.

Prasības datu bāzei

Tātad, labi izstrādāta datu bāze:

1. Atbilst visām lietotāju prasībām datu bāzes saturam. Pirms datu bāzes projektēšanas ir nepieciešams veikt plašu izpēti par lietotāju prasībām datu bāzes funkcionalitātei.

2. Nodrošina datu konsekvenci un integritāti. Veidojot tabulas, ir jādefinē to atribūti un daži noteikumi, kas ierobežo iespēju lietotājam ievadīt nepareizas vērtības. Lai pārbaudītu datus pirms tiešas ierakstīšanas tabulā, datu bāzei ir jāizsauc datu modeļa noteikumi un tādējādi jānodrošina informācijas integritāte.

3. Nodrošina dabisku, viegli uztveramu informācijas strukturējumu. Kvalitatīva datu bāzes uzbūve ļauj datu bāzes vaicājumus padarīt “caurspīdīgākus” un vieglāk uztveramus; Līdz ar to tiek samazināta nepareizu datu ievadīšanas iespējamība un uzlabota datu bāzes uzturēšanas kvalitāte.

4. Atbilst lietotāju datu bāzes veiktspējas prasībām. Ar lielu informācijas apjomu, produktivitātes uzturēšanas jautājumiem

sāk spēlēt galveno lomu, nekavējoties “izceļot” visus projektēšanas posma trūkumus.

Šie punkti atspoguļo datu bāzes projektēšanas pamatdarbības:

1. Noteikt datu bāzes informācijas vajadzības.

2. Analizējiet reālās pasaules objektus, kas jāmodelē datu bāzē. No šiem objektiem veido entītijas un šo entītiju raksturlielumus (piemēram, entītijai “detaļa” raksturlielumi var būt “nosaukums”, “krāsa”, “svars” utt.) un veido to sarakstu.

3. Saskaņojiet entītijas un raksturlielumus - tabulas un kolonnas (laukus) jūsu izvēlētās DBVS (Paradox, dBase, FoxPro, Access, Clipper, InterBase, Sybase, Informix, Oracle utt.) apzīmējumos.

4. Definējiet atribūtus, kas unikāli identificē katru objektu.

5. Izstrādājiet noteikumus, kas noteiks un uzturēs datu integritāti.

6. Izveidot savienojumus starp objektiem (tabulām un kolonnām), normalizēt tabulas.

7. Plānot datu uzticamības jautājumus un, ja nepieciešams, informācijas noslēpuma saglabāšanu.

Saistītā informācija.

Relāciju algebra ir balstīta uz kopu teoriju un ir datu bāzes loģikas pamatā.
Kad es tikko pētīju datu bāzu un SQL struktūru, iepriekšēja iepazīšanās ar relāciju algebru ļoti palīdzēja turpmākajām zināšanām pareizi iekļauties manā galvā, un es centīšos, lai šis raksts radītu līdzīgu efektu.

Tātad, ja jūs gatavojaties sākt studijas šajā jomā vai jūs vienkārši interesējat, lūdzu, noklikšķiniet uz kaķa.

Relāciju datu bāze

Vispirms iepazīstināsim ar relāciju datu bāzes jēdzienu, kurā mēs veiksim visas darbības.

Relāciju datu bāze ir relāciju kopums, kas satur visu informāciju, kas jāsaglabā datu bāzē. Šajā definīcijā mūs interesē termins relācija, bet pagaidām to atstāsim bez stingras definīcijas.
Labāk iedomāsimies produktu tabulu.

PRODUKTU tabula

ID	VĀRDS	UZŅĒMUMS	CENA
123	Sīkdatnes	Dark Side LLC	190
156	Tēja	Dark Side LLC	60
235	Ananāsi	OJSC “Frukty”	100
623	Tomāti	OOO "Dārzeņi"	130

Tabula sastāv no 4 rindām, rinda tabulā ir kortežs relāciju teorijā. Sakārtotu kopu kopu sauc par relāciju.
Pirms attiecību definēšanas ieviesīsim vēl vienu terminu – domēns. Domēni saistībā ar tabulu ir kolonnas.

Skaidrības labad mēs tagad ieviešam stingru attiecības definīciju.

Dotas N kopas D1,D2, …. Dn (domēni), relācija R virs šīm kopām ir formas sakārtotu N-korežu kopa , kur d1 pieder pie D1 utt. Kopas D1,D2,..Dn sauc par relācijas R domēniem.
Katrs kortedža elements apzīmē viena atribūta vērtību, kas atbilst vienam no domēniem.

Atslēgas attiecībās

Relācijā prasība ir tāda, ka visiem kortežiem jābūt atšķirīgiem. Lai unikāli identificētu virkni, ir primārā atslēga. Primārā atslēga ir atribūts vai minimālā atribūtu skaita kopa, kas unikāli identificē noteiktu korteju un nesatur papildu atribūtus.
No tā izriet, ka visiem primārās atslēgas atribūtiem ir jābūt nepieciešamiem un pietiekamiem, lai identificētu konkrētu korešu, un, izlaižot kādu no atslēgā esošajiem atribūtiem, tas būs nepietiekams identifikācijai.
Piemēram, šādā tabulā atslēga būs pirmās un otrās kolonnas atribūtu kombinācija.

DRIVERS galds

Redzams, ka organizācijai var būt vairāki draiveri, un, lai unikāli identificētu draiveri, ir nepieciešama gan vērtība no ailes “Organization Name”, gan no ailes “Driver Name”. Šādu atslēgu sauc par salikto atslēgu.

Relāciju datu bāzē tabulas ir savstarpēji saistītas un saistītas viena ar otru kā galvenās un pakārtotās tabulas. Savienojums starp galvenajām un pakārtotajām tabulām tiek veikts, izmantojot galvenās tabulas primāro atslēgu un pakārtotās tabulas ārējo atslēgu.
Ārējā atslēga ir atribūts vai atribūtu kopa, kas ir primārā atslēga galvenajā tabulā.

Ar šo sagatavošanas teoriju pietiks, lai iepazītos ar relāciju algebras pamatoperācijām.

Relāciju algebras darbības

Relāciju algebras astoņas pamatoperācijas ierosināja E. Kods.

• Asociācija
• Krustojums
• Atņemšana
• Dekarta produkts
• Paraugs
• Projekcija
• Savienojums
• Divīzija

Operāciju pirmā puse ir līdzīga tām pašām operācijām komplektos. Dažas operācijas var izteikt ar citām operācijām. Apskatīsim lielāko daļu darbību ar piemēriem.

Lai saprastu, ir svarīgi atcerēties, ka jebkuras algebras darbības rezultāts attiecībām ir cita relācija, ko pēc tam var izmantot citās operācijās.
Izveidosim vēl vienu tabulu, kas mums noderēs piemēros.

SELLERS galds

ID	PĀRDEVĒJS
123	OOO "Dārta"
156	AAS "Vedro"
235	CJSC “Dārzeņu Baza”
623	AS "Firma"

Vienosimies, ka šajā tabulā ID ir ārējā atslēga, kas saistīta ar tabulas PRODUKTI primāro atslēgu.

Vispirms apskatīsim vienkāršāko darbību – attiecību nosaukumu. Tā rezultāts būs tāda pati relācija, tas ir, veicot darbību PRODUKTI, mēs saņemsim relācijas PRODUKTI kopiju.

Projekcija

Projekcija ir darbība, kurā atribūti no relācijas tiek iegūti tikai no norādītajiem domēniem, tas ir, no tabulas tiek atlasītas tikai nepieciešamās kolonnas, un, ja tiek iegūti vairāki identiski korteži, tad paliek tikai viena šāda kortedža eksemplārs. iegūto attiecību.
Piemēram, izveidosim projekciju uz tabulas PRODUKTI, atlasot no tās ID un CENU.

Darbības sintakse:
π (ID, CENA) PRODUKTI

Parauga nosacījumā mēs varam izmantot jebkuru Būla izteiksmi. Veiksim citu atlasi, kuras cena ir lielāka par 90 un produkta ID ir mazāka par 300:

σ(CENA> 90^ID<300) PRODUCTS

Reizināšana

Reizināšana jeb Dekarta reizinājums ir operācija, kas tiek veikta ar divām relācijām, kuras rezultātā mēs iegūstam relāciju ar visiem domēniem no divām sākotnējām relācijām. Šajos domēnos esošie korteži būs visas iespējamās virkņu kombinācijas no sākotnējām relācijām. Tas būs skaidrāk ar piemēru.

Mēs iegūstam tabulu PRODUKTI un PĀRDEVĒJI Dekarta precizitāti.
Darbības sintakse:

PRODUKTI × PĀRDEVĒJI
Jūs ievērosiet, ka šīm divām tabulām ir vienāds ID domēns. Šādā situācijā domēniem ar tādu pašu nosaukumu tiek pievienots atbilstošās attiecības nosaukums, kā parādīts tālāk.
Īsuma labad nereizināsim pilnās attiecības, bet gan paraugus ar nosacījuma ID<235

(tās pašas kopas ir izceltas krāsā)

PRODUKTI.ID	VĀRDS	UZŅĒMUMS	CENA	PĀRDEVĒJI.ID	PĀRDEVĒJS
123	Sīkdatnes	Dark Side LLC	190	123	OOO "Dārta"
156	Tēja	Dark Side LLC	60	156	AAS "Vedro"
123	Sīkdatnes	Dark Side LLC	190	156	AAS "Vedro"
156	Tēja	Dark Side LLC	60	123	OOO "Dārta"

Šīs darbības izmantošanas piemērā iedomājieties nepieciešamību atlasīt pārdevējus, kuru cenas ir mazākas par 90. Ja prece nebūtu, vispirms būtu jāiegūst produktu ID no pirmās tabulas, pēc tam izmantojot šos ID no otrās tabulas, lai iegūtu nepieciešamo. PĀRDEVĒJA nosaukumi un, izmantojot produktu, šāds vaicājums būtu:

π (PĀRDEVĒJS) σ (RODUCTS.ID=SELLERS.ID ^ CENA<90) PRODUCTS × SELLERS

Šīs darbības rezultātā mēs iegūstam attiecību:

PĀRDEVĒJS

AAS "Vedro"

Savienojums un dabiskais savienojums

Savienošanas darbība ir apgriezta projekcijas darbībai un izveido jaunu relāciju no divām esošām. Jauna relācija tiek iegūta, savienojot pirmās un otrās relācijas korteņus, savukārt relācijas, kurās norādīto atribūtu vērtības sakrīt, tiek pakļautas konkatenācijai. Konkrēti, ja savienojat PRODUCTS un SELLERS attiecības, šie atribūti ir ID domēnu atribūti.

Tāpat skaidrības labad varat iedomāties savienojumu kā divu darbību rezultātu. Vispirms tiek ņemts avota tabulu reizinājums, un pēc tam no iegūtās relācijas mēs veicam atlasi ar nosacījumu par atribūtu vienādību no tiem pašiem domēniem. Šajā gadījumā nosacījums ir PRODUCTS.ID un SELLERS.ID vienlīdzība.

Mēģināsim savienot attiecības PRODUKTI un PĀRDEVĒJI un iegūt attiecību.

PRODUKTI.ID	VĀRDS	UZŅĒMUMS	CENA	PĀRDEVĒJI.ID	PĀRDEVĒJS
123	Sīkdatnes	Dark Side LLC	190	123	OOO "Dārta"
156	Tēja	Dark Side LLC	60	156	AAS "Vedro"
235	Ananāsi	OJSC “Frukty”	100	235	CJSC “Dārzeņu Baza”
623	Tomāti	OOO "Dārzeņi"	130	623	AS "Firma"

Dabisks savienojums saņem līdzīgu relāciju, bet, ja mums datu bāzē ir pareizi konfigurēta shēma (šajā gadījumā PRODUCTS ID tabulas primārā atslēga ir saistīta ar tabulas SELLERS ID ārējo atslēgu), tad iegūtā relācija satur tikai viens ID domēns.

Darbības sintakse:
PRODUKTI ⋈ PĀRDEVĒJI;

Jūs saņemat šo attiecību:

PRODUKTI.ID	VĀRDS	UZŅĒMUMS	CENA	PĀRDEVĒJS
123	Sīkdatnes	Dark Side LLC	190	OOO "Dārta"
156	Tēja	Dark Side LLC	60	AAS "Vedro"
235	Ananāsi	OJSC “Frukty”	100	CJSC “Dārzeņu Baza”
623	Tomāti	OOO "Dārzeņi"	130	AS "Firma"

Krustpunkts un atņemšana.

Krustošanās operācijas rezultāts būs relācija, kas sastāv no kortežiem, kas ir pilnībā iekļauti abās relācijās.
Atņemšanas rezultāts būs relācija, kas sastāv no korteņiem, kas ir pirmās relācijas korteži, nevis no otrās relācijas kortežiem.
Šīs darbības ir līdzīgas tām pašām operācijām ar kopām, tāpēc es domāju, ka nav nepieciešams tās detalizēti aprakstīt.

Informācijas avoti

• Datubāzu izmantošanas un projektēšanas pamati - V. M. Iļjušečkins
• lekciju kurss Ievads datu bāzēs - Jennifer Widom, Stanford University

Būšu pateicīgs par pamatotiem komentāriem

Īsumā par svarīgākajām lietām.

Datu bāzes normalizācija

Pirmā normālā forma (1NF)

• nav datu grupu dublikātu
• tiek garantēta datu atomitāte (visi dati ir autonomi un neatkarīgi).

Augstākajā līmenī tas tiek panākts, izveidojot primāro atslēgu, pēc tam pārvietojot atkārtotas datu grupas uz jaunām tabulām, izveidojot primārās atslēgas šīm tabulām utt. Turklāt visi ieraksti, kuru kolonnās ir salikta informācija, ir jāsadala atsevišķās rindās katrai kolonnas datu daļai.

Otrā normālā forma (2NF)

• tabula atbilst 1NF nosacījumiem
• katra kolonna ir atkarīga no visas atslēgas, nevis no tās daļas.

Trešā parastā forma (3NF)

• tabula atbilst 2NF nosacījumiem
• neviena kolonna nav atkarīga no kolonnas, kas neietilpst primārajā atslēgā
• nesatur atvasinātus datus

Citas parastās formas, kurām nav lielas praktiskas vērtības:

Boisa-Koda normālā forma

Variants 3NF. Izstrādāts, lai atrisinātu situāciju, kad kandidātu atslēgas pārklājas daudz. Patiesībā ārpus akadēmiskās kopienas nav loģiska pamatojuma.

Ceturtā normālā forma

Izstrādāts, lai atrisinātu problēmas ar daudzvērtīgām atkarībām. Šādas situācijas rodas, ja tabulā, kas samazināta līdz 3NF, viena saliktās primārās atslēgas kolonna ir atkarīga no citas primārās atslēgas kolonnas.

Piektā normālā forma

Izmanto, strādājot ar attiecību sadalīšanu ar un bez zaudējumiem. Tā rodas situācijā, kad ir iespējams vienas attiecības sadalīt vairākās dažādās attiecībās, bet pēc tam mēs vairs nevarēsim tās loģiski atgriezt sākotnējā formā.

Sestā parastā forma (domēna atslēgas parastā forma)

Nodrošina, ka datu bāzē nav modifikāciju anomāliju. Reālos apstākļos tas praktiski nav sasniedzams.

Attiecības.

Reiz no sievietēm dzirdēju, ka vīrieši
nekavējoties mēģiniet atstāt telpu, kurā
Tika dzirdēts vārds "attiecības".<...>panākumu atslēga
attiecības ir katra savas lomas apzināšanās
šajā sakarā, kā arī noteikumus un ierobežojumus,
ko uzliek šīs attiecības.
(C) Roberts Viera, “Profesionālā SQL Server 2000 programmēšana”

Attiecību veidi

• Viens pret vienu (ir jēga, ja atbilstošie dati ir jāsaglabā dažādās datu bāzēs vai ja ir pārsniegts maksimālais rindas datu lielums)
• Nulle vai viens pret vienu
• Viens pret daudziem
• Viens līdz -nulle, -viens vai -daudzi
• Daudzi pret daudziem (savienojuma galdi)

Asociācijas

IEKŠĒJĀ PIEVIENOŠANĀS

Ekskluzīva pievienošanās. Atlases rezultātā tiek iekļauti tikai tie tabulas ieraksti, kuriem ir atbilstības pāra tabulā konkrētajam nosacījumam.

LEFT|RIGHT JOIN

Iekļaujoša pievienošanās. Atlases rezultāts ietver ierakstus no tabulas pa kreisi/pa labi no PIEVIENOJIES attiecīgi. Šajā gadījumā tiks aizpildīti dati no trūkstošā “pārī savienotā” ieraksta NULL.
NO left_table LEFT JOIN right_table– visi ieraksti no kreisās tabulas ir iekļauti left_table
NO left_table RIGHT JOIN right_table– tiek iekļauti visi ieraksti no labās tabulas right_table

PILNĪGS PIEVIENOJIES

Iekļaujoša pievienošanās. Atlases rezultātā tiek iekļauti ne tikai ieraksti, kuriem ir sakritība otrā tabulā, bet arī ieraksti no abām tabulām, kuriem otrā tabulā atbilstība netika atrasta. Šajā gadījumā dati no trūkstošā “pārī savienotā” ieraksta tiks aizpildīti ar NULL.

KRUSTS PIEVIENOTIES

Krusta savienība (Dekarta produkts). Katrs ieraksts no vienas tabulas tiek saskaņots ar katru ierakstu no citas tabulas. Iegūto ierakstu skaits ir vienāds ar ierakstu skaita reizinājumu abās tabulās.

Vairāku sakārtošanas principi PIEVIENOJIES s

Ja jums ir jāapvieno vairākas tabulas, jums jāatceras divi principi:

1. Visas arodbiedrības pa kreisi PIEVIENOJIES tiek uzskatīta par vienu tabulu, lai iekļautu vaicājumu vai izslēgtu no tā.
2. Visas arodbiedrības ir pa labi PIEVIENOJIES ARĪ tiek uzskatīta par vienu tabulu, lai iekļautu vaicājumu vai izslēgtu no tā.

Šo principu rezultāts ir šāds ieteikums sarežģītu asociāciju veidošanai:

• Kur vien iespējams, izmantojiet INNER JOIN.
• Ja ir nepieciešams izmantot OUTTER JOIN, tie jāievieto pēdējie, un IEKŠĒJIE JOIN ir jāievieto savienojuma sākumā.

P.S. Visi iepriekš minētie ir vispārīgi relāciju datu bāzu teorijas “postulāti”, kas nav saistīti ar noteiktu DBVS iezīmēm.

Datu modelis ir datu struktūru un to apstrādes darbību kopums. Izmantojot datu modeli, varat vizuāli attēlot objektu struktūru un starp tiem izveidotās attiecības. Datu modeļu terminoloģiju raksturo jēdzieni “datu elements” un “saistošie noteikumi”. Datu elements apraksta jebkuru datu kopu, un asociācijas noteikumi nosaka algoritmus datu elementu savstarpējai savienošanai. Līdz šim ir izstrādāti daudzi dažādi datu modeļi, bet praksē tiek izmantoti trīs galvenie. Ir hierarhiskie, tīkla un relāciju datu modeļi. Attiecīgi viņi runā par hierarhiskām, tīkla un relāciju DBVS.

O Hierarhiskais datu modelis. Hierarhiski sakārtoti dati ir ļoti izplatīti ikdienas dzīvē. Piemēram, augstākās izglītības iestādes struktūra ir daudzlīmeņu hierarhiska struktūra. Hierarhiskā (koka) datubāze sastāv no sakārtotas elementu kopas. Šajā modelī sākotnējie elementi rada citus elementus, un šie elementi savukārt rada turpmākus elementus. Katram pakārtotajam elementam ir tikai viens vecākelements.

Organizatoriskās struktūras, materiālu sarakstus, grāmatu satura rādītājus, projektu plānus un daudzas citas datu kopas var attēlot hierarhiskā formā. Automātiski tiek saglabāta saikņu integritāte starp senčiem un pēcnācējiem. Pamatnoteikums: neviens bērns nevar pastāvēt bez sava vecāka.

Galvenais šī modeļa trūkums ir nepieciešamība izmantot hierarhiju, kas bija datu bāzes pamatā projektēšanas laikā. Nepieciešamība pēc pastāvīgas datu reorganizācijas (un bieži vien šīs reorganizācijas neiespējamība) noveda pie vispārīgāka modeļa - tīkla modeļa - izveides.

O Tīkla datu modelis. Tīkla pieeja datu organizēšanai ir hierarhiskās pieejas paplašinājums. Šis modelis atšķiras no hierarhiskā ar to, ka katram ģenerētajam elementam var būt vairāk nekā viens ģenerējošais elements. ■

Tā kā tīkla datu bāze var tieši attēlot visa veida attiecības, kas raksturīgas attiecīgās organizācijas datiem, šos datus var pārvietot, izpētīt un vaicāt dažādos veidos, tas ir, tīkla modeli nesaista tikai viena hierarhija. Tomēr, lai veiktu pieprasījumu tīkla datu bāzei, ir nepieciešams padziļināti iedziļināties tās struktūrā (pa rokai jābūt šīs datu bāzes shēmai) un izstrādāt datu bāzes navigācijas mehānismu, kas ir būtisks šī datu bāzes modeļa trūkums. .

O Relāciju datu modelis. Relāciju datu modeļa pamatideja ir attēlot jebkuru datu kopu kā divdimensiju tabulu. Vienkāršākajā formā relāciju modelis apraksta vienu divdimensiju tabulu, bet visbiežāk modelis apraksta struktūru un attiecības starp vairākām dažādām tabulām.

Relāciju datu modelis

Tātad informācijas sistēmas mērķis ir apstrādāt datus par objektus reālā pasaule, ņemot vērā savienojumiem starp objektiem. Datu bāzes teorijā datus bieži sauc atribūti un objekti - entītijām. Objekts, atribūts un savienojums ir I.S. pamatjēdzieni.

Objekts(vai būtība) ir kaut kas, kas pastāv un atšķirams, tas ir, objektu var saukt par "kaut ko", kam ir nosaukums un veids, kā atšķirt vienu līdzīgu objektu no cita. Piemēram, katra skola ir objekts. Objekti ir arī cilvēks, klase skolā, uzņēmums, sakausējums, ķīmisks savienojums utt.. Objekti var būt ne tikai materiāli objekti, bet arī abstraktāki jēdzieni, kas atspoguļo reālo pasauli. Piemēram, pasākumi, reģioni, mākslas darbi; grāmatas (nevis kā iespieddarbi, bet kā darbi), teātra izrādes, filmas; tiesību normas, filozofiskās teorijas utt.

Atribūts(vai dota)- tas ir noteikts rādītājs, kas raksturo noteiktu objektu un ņem noteiktu ciparu, tekstu vai citu vērtību konkrētam objekta eksemplāram. Informācijas sistēma darbojas ar objektu kopām, kas veidotas saistībā ar noteiktu priekšmetu jomu, izmantojot specifiskus atribūtu vērtības noteiktu objektu (dati). Piemēram, pieņemsim nodarbības skolā kā objektu kopumu. Skolēnu skaits klasē ir atskaites punkts, kas iegūst skaitlisku vērtību (vienā klasē ir 28, citā ir 32). Klases nosaukums ir dots, kam ir teksta vērtība (vienam ir 10A, citam ir 9B utt.).

Relāciju datu bāzu izstrāde sākās 60. gadu beigās, kad parādījās pirmie darbi, kas apsprieda; iespēja, veidojot datu bāzes, izmantot pazīstamus un dabiskus datu pasniegšanas veidus - tā sauktos tabulu datu loģiskos modeļus.

Par relāciju datu bāzu teorijas pamatlicēju tiek uzskatīts IBM darbinieks doktors E. Kods, kurš 1970. gada 6. jūnijā publicēja rakstu. Datu relāciju modelis lielas koplietošanas datu bankām(Relāciju datu modelis lielām kolektīvajām datu bankām). Šis raksts bija pirmais, kurā tika izmantots termins “relāciju datu modelis”. Relāciju datu bāzu teorijai, ko 70. gados ASV izstrādāja doktors E. Kods, ir spēcīgs matemātiskais pamats, kas apraksta efektīvas datu organizēšanas noteikumus. E. Koda izstrādātais teorētiskais ietvars kļuva par pamatu datu bāzu projektēšanas teorijas attīstībai.

E. Kods, būdams matemātiķis pēc izglītības, ierosināja datu apstrādei izmantot kopu teorijas aparātu (savienojums, krustojums, atšķirība, Dekarta reizinājums). Viņš pierādīja, ka jebkuru datu kopu var attēlot īpaša veida divdimensiju tabulu veidā, ko matemātikā sauc par “relācijām”.

Relāciju Par datu bāzi tiek uzskatīta tāda datu bāze, kurā visi dati tiek parādīti lietotājam taisnstūrveida datu vērtību tabulu veidā, un visas darbības datu bāzē tiek reducētas līdz manipulācijām ar tabulām.

Tabula sastāv no kolonnas (lauki) Un līnijas (ieraksti); ir unikāls nosaukums datu bāzē. Tabula atspoguļo Objekta tipsīstā pasaule (entitāte), un katra no viņas virkne ir konkrēts objekts. Katra tabulas kolonna ir vērtību kolekcija noteiktam objekta atribūtam. Vērtības tiek atlasītas no visu iespējamo vērtību kopas objekta atribūtam, kas tiek izsaukts domēns.

Vispārīgākajā formā domēns tiek definēts, norādot kādu bāzes datu tipu, kuram pieder domēna elementi, un patvaļīgu Būla izteiksmi, kas tiek lietota datu elementiem. Ja novērtējat Būla nosacījumu datu vienumam un rezultāts ir patiess, tad šis vienums pieder domēnam. Vienkāršākajā gadījumā domēns tiek definēts kā derīga tāda paša veida potenciālo vērtību kopa. Piemēram, visu darbinieku dzimšanas datumu apkopošana ir “dzimšanas datuma domēns”, un visu darbinieku vārdi veido “darbinieka vārda domēnu”. Dzimšanas datuma domēnam ir jābūt norādīta laika datu tipam, un darbinieka vārda domēnam ir jābūt rakstzīmju datu tipam.

Ja divas vērtības nāk no viena domēna, tad abas vērtības var salīdzināt. Piemēram, ja no dzimšanas datumu domēna tiek ņemtas divas vērtības, varat tās salīdzināt un noteikt, kurš darbinieks ir vecāks. Ja vērtības tiek ņemtas no dažādām jomām, tad to salīdzināšana nav atļauta, jo, visticamāk, tam nav jēgas. Piemēram, nekas konkrēts nebūs, salīdzinot darbinieka vārdu un dzimšanas datumu.

Katrai kolonnai (laukam) ir nosaukums, ko parasti raksta tabulas augšpusē. Veidojot tabulas noteiktā DBVS ietvaros, katram laukam ir iespējams izvēlēties savu tips, tas ir, definēt noteikumu kopumu tā attēlošanai, kā arī noteikt darbības, kuras var veikt ar šajā laukā saglabātajiem datiem. Veidu kopas dažādās DBVS var atšķirties.

Lauka nosaukumam tabulā jābūt unikālam, taču dažādās tabulās var būt lauki ar vienādu nosaukumu. Jebkurā tabulā ir jābūt vismaz vienam laukam; Lauki tabulā atrodas atbilstoši secībai, kādā to nosaukumi parādījās, kad tā tika izveidota. Atšķirībā no laukiem virknēm nav nosaukumu; to secība tabulā nav noteikta, un to skaits ir loģiski neierobežots.

Tā kā tabulas rindas nav sakārtotas, nav iespējams izvēlēties rindu pēc tās pozīcijas - starp tām nav “pirmās”, “otrās” vai “pēdējās”. Jebkurā tabulā ir viena vai vairākas kolonnas, kuru vērtības unikāli identificē katru tās rindu. Šādu kolonnu (vai kolonnu kombināciju) sauc primārā atslēga. Lai numurētu ierakstus tabulā, bieži tiek ieviests mākslīgs lauks. Šāds lauks, piemēram, varētu būt tā kārtas lauks, kas var nodrošināt katra ieraksta unikalitāti tabulā. Atslēgai ir jābūt šādām īpašībām.

Unikalitāte. Nevienā brīdī diviem dažādiem relāciju kortežiem nav vienādas vērtības atslēgā iekļautajai atribūtu kombinācijai. Tas nozīmē, ka tabulā nevar būt divas rindas, kurām ir vienāds identifikācijas numurs vai pases numurs.

Minimālisms. Nevienu no atslēgā iekļautajiem atribūtiem nevar izslēgt no atslēgas, nepārkāpjot unikalitāti. Tas nozīmē, ka nevajadzētu izveidot atslēgu, kas ietver gan pases numuru, gan identifikācijas numuru. Pietiek izmantot kādu no šiem atribūtiem, lai unikāli identificētu korešu. Atslēgā nevajadzētu iekļaut arī neunikālu atribūtu, tas ir, identifikācijas numura un darbinieka vārda kombinācija kā atslēga ir aizliegta. Izslēdzot no atslēgas darbinieka vārdu, katru rindu joprojām var unikāli identificēt.

Katrai relācijai ir vismaz viena iespējamā atslēga, jo visu tās atribūtu kopums apmierina unikalitātes nosacījumu – tas izriet no pašas attiecības definīcijas.

Viens no iespējamiem taustiņiem ir nejauši izvēlēts kā primāro atslēgu. Atlikušās iespējamās atslēgas, ja tādas ir, tiek uzskatītas par alternatīvās atslēgas. Piemēram, ja kā primāro atslēgu atlasāt identifikācijas numuru, pases numurs būs alternatīvā atslēga.

Tabulu attiecības ir vissvarīgākais relāciju datu modeļa elements. Tas tiek atbalstīts svešās atslēgas.

Aprakstot relāciju datu bāzes modeli, vienam un tam pašam jēdzienam bieži tiek lietoti dažādi termini atkarībā no apraksta līmeņa (teorija vai prakse) un sistēmas (Access, SQL Server, dBase). Tabulā 2.3 sniedz lietoto terminu kopsavilkumu.

2.3. tabula. Datu bāzes terminoloģija

Datu bāzu teorija____________ Relāciju datu bāzes_________ SQL Server __________

Attiecību tabula Tabula

Tuple Record Row

Atribūta lauks_______________Kolonna

Relāciju datu bāzes

Relāciju datu bāze ir attiecību kopa, kas satur visu informāciju, kas jāsaglabā datu bāzē. Tas nozīmē, ka datu bāze ir tabulu kopa, kas nepieciešama visu datu glabāšanai. Relāciju datu bāzes tabulas ir loģiski saistītas viena ar otru.Prasības relāciju datu bāzes projektēšanai kopumā var reducēt līdz vairākiem noteikumiem.

О Katrai tabulai datu bāzē ir unikāls nosaukums, un tā sastāv no viena veida rindām.

O Katra tabula sastāv no noteikta kolonnu un vērtību skaita. Vienas rindas kolonnā nevar saglabāt vairāk nekā vienu vērtību. Piemēram, ja ir tabula ar informāciju par autoru, izdošanas datumu, tirāžu utt., tad ailē ar autora vārdu nevar saglabāt vairāk par vienu uzvārdu. Ja grāmatu ir uzrakstījuši divi vai vairāki autori, jums būs jāizmanto papildu tabulas.

O Nevienā brīdī tabulā nebūs divas rindas, kas dublē viena otru. Rindām ir jāatšķiras vismaz ar vienu vērtību, lai tās varētu unikāli identificēt jebkuru tabulas rindu.

О Katrai kolonnai tabulā ir piešķirts unikāls nosaukums; tam ir iestatīts konkrēts datu tips, lai šajā kolonnā tiktu ievietotas viendabīgas vērtības (datumi, uzvārdi, tālruņu numuri, naudas summas utt.).

O Pilns datu bāzes informācijas saturs tiek attēlots kā pašu datu nepārprotamas vērtības, un šī ir vienīgā attēlošanas metode. Piemēram, attiecības starp tabulām ir balstītas uz datiem, kas glabājas attiecīgajās kolonnās, nevis uz norādes, kas mākslīgi definē attiecības.

О Apstrādājot datus, jūs varat brīvi piekļūt jebkurai tabulas rindai vai kolonnai. Tabulā saglabātās vērtības neuzliek nekādus ierobežojumus datu piekļuves secībai. Kolonnu apraksts,