RELĀCIJU DATU BĀZES MODELIS: ELEMENTI, KĀ TO IZDARĪT, PIEMĒRS - TEHNOLOĢIJAS - 2025

Relāciju datu modelis ir metode strukturēšanas datus, izmantojot attiecības, izmantojot tīklveida struktūru, kas sastāv no kolonnas un rindas. Tas ir relāciju datu bāzu konceptuālais princips. To ierosināja Edgars F. Kodds 1969. gadā.

Kopš tā laika tas ir kļuvis par dominējošo datu bāzu modeli biznesa lietojumprogrammām, salīdzinot ar citiem datu bāzes modeļiem, piemēram, hierarhisko, tīkla un objektu.

Avots: pixabay.com

Kodam nebija ne mazākās nojausmas, cik ārkārtīgi būtisks un ietekmīgs būs viņa darbs kā relāciju datu bāzu platforma. Lielākā daļa cilvēku ļoti labi pārzina attiecību fizisko izpausmi datu bāzē: tabulu.

Relāciju modelis tiek definēts kā datu bāze, kas ļauj grupēt savus datu elementus vienā vai vairākās neatkarīgās tabulās, kuras var savstarpēji saistīt, izmantojot laukus, kas kopīgi katrai saistītajai tabulai.

Datu bāzes pārvaldība

Datu bāzes tabula ir līdzīga izklājlapai. Tomēr attiecības, kuras var izveidot starp tabulām, ļauj relāciju datu bāzei efektīvi uzglabāt lielu datu daudzumu, kuru var efektīvi izgūt.

Relāciju modeļa mērķis ir nodrošināt deklaratīvu metodi datu un vaicājumu noteikšanai: lietotāji tieši deklarē, kādu informāciju satur datu bāze un kādu informāciju no tās vēlas.

No otras puses, viņi datu bāzu pārvaldības sistēmas programmatūrai atstāj pienākumu aprakstīt datu struktūras glabāšanai un izguves procedūru, lai atbildētu uz jautājumiem.

Lielākā daļa relāciju datu bāzu izmanto SQL valodu datu meklēšanai un definēšanai. Pašlaik ir daudz relāciju datu bāzu pārvaldības sistēmu vai RDBMS (Relāciju datu bāzes pārvaldības sistēma), piemēram, Oracle, IBM DB2 un Microsoft SQL Server.

Īpašības un elementi

- Visi dati ir konceptuāli attēloti kā sakārtots datu izvietojums rindās un kolonnās, ko sauc par relāciju vai tabulu.

- Katrā tabulā jābūt galvenē un korpusā. Galvenē ir vienkārši kolonnu saraksts. Pamatteksts ir datu kopums, kas aizpilda tabulu, sakārtots rindās.

- Visas vērtības ir skalāri. Tas ir, katrā tabulas rindā / kolonnā ir tikai viena vērtība.

-Elementi

Nākamajā attēlā parādīta tabula ar tās pamatelementu nosaukumiem, kas veido pilnīgu struktūru.

Tuple

Katra datu rinda ir kopums, kas pazīstams arī kā ieraksts. Katra rinda ir n-veida paraugs, bet “n-” parasti tiek atmesta.

Kolonna

Katra tabulas kolonna tiek saukta par atribūtu vai lauku. Kolonna attēlo vērtību kopu, kāda var būt konkrētam atribūtam.

Atslēga

Katrā rindā ir viena vai vairākas kolonnas, ko sauc par tabulas atslēgu. Šī apvienotā vērtība ir unikāla visām tabulas rindām. Izmantojot šo taustiņu, katrs korpuss tiks unikāli identificēts. Tas ir, atslēgu nevar dublēt. To sauc par galveno atslēgu.

No otras puses, sveša vai sekundāra atslēga ir lauks tabulā, kas attiecas uz kādas citas tabulas primāro atslēgu. To izmanto, lai atsauktos uz primāro tabulu.

- integritātes noteikumi

Izstrādājot relāciju modeli, jūs definējat dažus nosacījumus, kas jāievēro datu bāzē, ko sauc par integritātes noteikumiem.

Taustiņu integritāte

Primārajai atslēgai jābūt unikālai visiem sīktēliem, un tā nedrīkst būt nulle (NULL). Pretējā gadījumā jūs nevarēsit unikāli identificēt rindu.

Vairāku kolonnu atslēgai nevienā no šīm kolonnām nedrīkst būt NULL.

Referenču integritāte

Katrai svešas atslēgas vērtībai ir jāsakrīt ar atsauces vai primārās tabulas primārās atslēgas vērtību.

Rindu ar svešu atslēgu var ievietot sekundārajā tabulā tikai tad, ja šī vērtība pastāv primārajā tabulā.

Ja atslēgas vērtība mainās primārajā tabulā, jo rinda tiek atjaunināta vai izdzēsta, tad attiecīgi jāatjaunina vai jādzēš visas sekundāro tabulu rindas ar šo svešo atslēgu.

Kā izveidot relāciju modeli?

-Savākt datus

Jāsavāc nepieciešamie dati, lai tos varētu uzglabāt datu bāzē. Šie dati ir sadalīti dažādās tabulās.

Katrā slejā jāizvēlas atbilstošs datu tips. Piemēram: veseli skaitļi, peldošā komata skaitļi, teksts, datums utt.

-Definējiet primārās atslēgas

Katrā tabulā par galveno atslēgu jāizvēlas kolonna (vai dažas kolonnas), kas unikāli identificēs katru tabulas rindu. Primāro atslēgu izmanto arī, lai atsauktos uz citām tabulām.

- Izveidot attiecības starp tabulām

Datubāzei, kas sastāv no neatkarīgām, nesaistītām tabulām, nav liela nozīme.

Vissvarīgākais aspekts, veidojot relāciju datu bāzi, ir attiecību identificēšana starp tabulām. Attiecību veidi ir:

Viens daudziem

"Klases saraksta" datu bāzē skolotājs var mācīt nulles vai vairāk klases, savukārt klasi māca viens skolotājs. Šis attiecību veids ir pazīstams kā viens pret daudziem.

Šīs attiecības nevar attēlot vienā tabulā. Datu bāzē «Klases saraksts» var būt tabula ar nosaukumu Skolotāji, kurā glabājas informācija par skolotājiem.

Lai saglabātu katra skolotāja mācītās klases, jūs varētu izveidot papildu slejas, taču jūs saskarsies ar problēmu: cik kolonnu izveidot.

No otras puses, ja jums ir tabula ar nosaukumu Klases, kurā tiek glabāta informācija par klasi, jūs varētu izveidot papildu slejas, lai saglabātu informāciju par skolotāju.

Tā kā skolotājs var mācīt daudzas klases, viņa dati tiks dublēti daudzās tabulas Klases rindās.

Izstrādājiet divus galdus

Tādēļ jums ir jāizstrādā divas tabulas: Klases tabula, lai saglabātu informāciju par klasēm, ar primāro atslēgu ar Class_Id, un Skolotāju tabula, lai saglabātu informāciju par skolotājiem, un Teacher_Id kā galveno atslēgu.

Pēc tam attiecības starp vienu var izveidot, primārajai atslēgai no tabulas Meistars (Master_Id) tabulā Klases, kā parādīts zemāk.

Klases tabulas sleja Master_Id ir pazīstama kā sveša atslēga vai sekundāra atslēga.

Katrai Master_Id vērtībai tabulā Master var būt nulle vai vairāk rindu tabulā Classes. Katrai klases_Id vērtībai tabulā Klases skolotāju tabulā ir tikai viena rinda.

Daudziem daudziem

"Produktu pārdošanas" datu bāzē klienta pasūtījums var saturēt vairākus produktus, un produkts var parādīties vairākos pasūtījumos. Šāda veida attiecības ir pazīstamas kā daudzas no tām.

Jūs varat sākt datu bāzi "Produktu pārdošana" ar divām tabulām: Produkti un Pasūtījumi. Tabulā Produkti ir informācija par izstrādājumiem, kā galveno atslēgu norādot produktu ID.

No otras puses, tabulā Pasūtījumi ir norādīti klienta pasūtījumi, kuru galvenā atslēga ir orderID.

Pasūtīto tabulu nevar uzglabāt pasūtītajā tabulā, jo jūs nezināt, cik kolonnu rezervēt produktiem. Tā paša iemesla dēļ pasūtījumus nevar glabāt arī tabulā Produkti.

Lai atbalstītu attiecības starp daudziem, jums jāizveido trešā tabula, kas pazīstama kā savienojuma tabula (OrderDetails), kur katra rinda attēlo vienumu noteiktā secībā.

Tabulā OrderDetails primārā atslēga sastāv no divām kolonnām: orderID un productID, unikāli identificējot katru rindu.

Tabulas OrderDetails kolonnas orderID un productID tiek izmantotas, lai atsauktos uz tabulām Pasūtījumi un Produkti. Tāpēc tabulā OrderDetails tās ir arī svešas atslēgas.

Vienu pēc otra

Datu bāzē "Produktu pārdošana" izstrādājumam var būt papildu informācija, piemēram, papildu apraksts un tā attēls. Turot to produktu tabulā, tiktu izveidotas daudz tukšas vietas.

Tāpēc izvēles datu glabāšanai var izveidot citu tabulu (ProductExtras). Produktiem ar izvēles datiem tiks izveidots tikai viens ieraksts.

Divām tabulām - Produktiem un ProductExtras - ir savstarpēji saistītas attiecības. Katrā rindā tabulā Produkti tabulā ProductExtras ir maksimāli viena rinda. Tas pats produkta ID jāizmanto kā primārā atslēga abām tabulām.

Priekšrocība

Strukturālā neatkarība

Relāciju datu bāzes modelī datu bāzes struktūras izmaiņas neietekmē piekļuvi datiem.

Kad ir iespējams veikt izmaiņas datu bāzes struktūrā, neietekmējot DBVS iespējas piekļūt datiem, var teikt, ka ir panākta struktūras neatkarība.

Konceptuālā vienkāršība

Relāciju datu bāzes modelis ir konceptuāli vēl vienkāršāks nekā hierarhiskais vai tīkla datu bāzes modelis.

Tā kā relāciju datu bāzes modelis atbrīvo dizaineru no detalizētas datu fiziskas glabāšanas, dizaineri var koncentrēties uz datu bāzes loģisko skatu.

Vienkārša projektēšana, ieviešana, uzturēšana un lietošana

Relāciju datu bāzes modelī tiek panākta gan datu neatkarība, gan struktūras neatkarība, kas datu bāzes projektēšanu, uzturēšanu, pārvaldīšanu un izmantošanu padara daudz vieglāku nekā citi modeļi.

Ad-hoc vaicājumu jauda

Ļoti jaudīgu, elastīgu un ērti lietojamu vaicājumu klātbūtne ir viens no galvenajiem relāciju datu bāzes modeļa milzīgās popularitātes iemesliem.

Relāciju datu bāzes modeļa vaicājumu valoda, ko sauc par strukturētu vaicājumu valodu vai SQL, padara ad-hoc vaicājumus par realitāti. SQL ir ceturtās paaudzes valoda (4GL).

4GL ļauj lietotājam norādīt, kas jādara, nenorādot, kā tas jādara. Tādējādi, izmantojot SQL, lietotāji var norādīt, kādu informāciju viņi vēlas, un atstāt sīkāku informāciju par to, kā iegūt informāciju datu bāzē.

Trūkumi

Aparatūras izdevumi

Relāciju datu bāzes modelis slēpj tā ieviešanas sarežģītību un detalizētu informāciju par lietotāja datu fizisku uzglabāšanu.

Lai to izdarītu, relāciju datu bāzu sistēmām nepieciešami datori ar jaudīgāku aparatūru un datu glabāšanas ierīcēm.

Tāpēc RDBMS ir vajadzīgas jaudīgas mašīnas, lai tās darbotos nevainojami. Tomēr, tā kā mūsdienu datoru apstrādes jauda pieaug eksponenciālā ātrumā, mūsdienu scenārijā vajadzība pēc lielākas apstrādes jaudas vairs nav ļoti liela problēma.

Dizaina vienkāršība var izraisīt sliktu dizainu

Relāciju datu bāzi ir viegli izveidot un izmantot. Lietotājiem nav jāzina sarežģīta datu fiziskās glabāšanas informācija. Viņiem nav jāzina, kā dati faktiski tiek glabāti, lai tiem piekļūtu.

Šī projektēšanas un lietošanas vienkāršība var izraisīt slikti izstrādātu datu bāzu pārvaldības sistēmu izstrādi un ieviešanu. Tā kā datu bāze ir efektīva, šīs projektēšanas nepilnības netiks atklātas, izveidojot datu bāzi un kad ir tikai mazs datu apjoms.

Tā kā datu bāze aug, slikti izstrādātas datu bāzes palēnina sistēmu un noved pie veiktspējas pasliktināšanās un datu korupcijas.

"Informācijas salu" fenomens

Kā minēts iepriekš, relāciju datu bāzes sistēmas ir viegli ieviesamas un lietojamas. Tas radīs situāciju, kad pārāk daudz cilvēku vai departamentu izveidos savas datu bāzes un lietojumprogrammas.

Šīs informācijas salas novērsīs informācijas integrāciju, kas ir būtiska vienmērīgai un efektīvai organizācijas darbībai.

Šīs atsevišķās datu bāzes radīs arī tādas problēmas kā datu neatbilstība, datu kopēšana, datu dublēšana utt.

Piemērs

Pieņemsim, ka datu bāze sastāv no piegādātāju, detaļu un sūtījumu tabulām. Tabulu struktūra un daži ierakstu paraugi ir šādi:

Katra piegādātāju tabulas rinda tiek identificēta ar unikālu piegādātāja numuru (SNo), unikāli identificējot katru tabulas rindu. Tāpat katrai detaļai ir unikāls detaļas numurs (PNo).

Turklāt dotajā Piegādātāja / Detaļu kombinācijā Sūtījumos var būt ne vairāk kā viens sūtījums, jo šī kombinācija ir galvenā Sūtījumu atslēga, kas kalpo kā savienības tabula, jo tā ir attiecības starp daudziem.

Saistība starp tabulām Detaļas un Sūtījumi tiek parādīta, ja lauka PNo (detaļas numurs) ir kopīga, un attiecības starp piegādātājiem un sūtījumiem rodas, ja lauks SNo (piegādātāja numurs) ir kopīgs.

Analizējot sūtījumu tabulu, var iegūt informāciju, ka no Suneet un Ankit piegādātājiem tiek nosūtīti 500 rieksti, katrs 250.

Tāpat kopumā no trim dažādiem piegādātājiem tika piegādātas 1100 bultskrūves. No Suneet piegādātāja tika piegādātas 500 zilas skrūves. Nav sarkanu skrūvju sūtījumu.

Atsauces

1. Wikipedia, bezmaksas enciklopēdija (2019). Relāciju modelis. Iegūts no: en.wikipedia.org.
2. Tehnopēdija (2019). Relāciju modelis. Paņemts no: limitspedia.com.
3. Dinesh Thakur (2019. gads). Relāciju modelis. E-datora piezīmes. Paņemts no: ecomputernotes.com.
4. Geeks Geeksam (2019). Relāciju modelis. Iegūts no: geeksforgeeks.org.
5. Nanjanas Tehnoloģiskā universitāte (2019). Ātrās apmācības kurss par relāciju datu bāzes noformējumu. Paņemts no: ntu.edu.sg.
6. Adrienne Watt (2019. gads). 7. nodaļa. Relāciju datu modelis. BC atvērtās mācību grāmatas. Paņemts no: opentextbc.ca.
7. Toppr (2019). Relāciju datu bāzes un shēmas. Paņemts no: toppr.com.