RELIACINĖS DUOMENŲ BAZĖS MODELIS: ELEMENTAI, KAIP TAI PADARYTI, PAVYZDYS - TECHNOLOGIJA - 2025

Reliacinis duomenų bazės modelis yra struktūrizuoti duomenis metodas, naudojant santykius, naudojant tinklelį, kaip struktūros, sudarytas iš stulpelių ir eilučių. Tai yra koncepcinis reliacinių duomenų bazių principas. Jį pasiūlė Edgaras F. Coddas 1969 m.

Nuo tada jis tapo dominuojančiu verslo programų duomenų bazių modeliu, palyginti su kitais duomenų bazių modeliais, tokiais kaip hierarchinis, tinklo ir objekto.

Šaltinis: pixabay.com

Coddas net neįtarė, koks nepaprastai svarbus ir įtakingas bus jo, kaip reliacinių duomenų bazių, darbas. Daugelis žmonių yra gerai susipažinę su fizine santykių išraiška duomenų bazėje: lentelė.

Reliacinis modelis yra apibrėžtas kaip duomenų bazė, leidžianti sugrupuoti savo duomenų elementus į vieną ar daugiau nepriklausomų lentelių, kurios gali būti susietos viena su kita, naudojant laukus, būdingus kiekvienai susijusiai lentelei.

Duomenų bazių valdymas

Duomenų bazės lentelė yra panaši į skaičiuoklę. Tačiau santykiai, kuriuos galima sukurti tarp lentelių, leidžia reliacinėje duomenų bazėje efektyviai saugoti didelį kiekį duomenų, kuriuos galima efektyviai atkurti.

Reliacinio modelio tikslas yra pateikti deklaratyvų duomenų ir užklausų nustatymo metodą: vartotojai tiesiogiai deklaruoja, kokią informaciją turi duomenų bazė ir kokios informacijos iš jos nori.

Kita vertus, duomenų bazių valdymo sistemos programinei įrangai jie palieka aprašyti saugotinų duomenų struktūras ir gavimo procedūrą atsakant į klausimus.

Daugybė reliacinių duomenų bazių naudoja SQL kalbą užklausdami ir apibrėždami duomenis. Šiuo metu yra daug reliacinių duomenų bazių valdymo sistemų arba RDBMS (Reliacinių duomenų bazių valdymo sistema), tokių kaip „Oracle“, „IBM DB2“ ir „Microsoft SQL Server“.

Savybės ir elementai

- Visi duomenys konceptualiai pateikiami kaip užsakytas duomenų išdėstymas eilutėse ir stulpeliuose, vadinamas santykiu arba lentele.

- Kiekviena lentelė turi turėti antraštę ir korpusą. Antraštė yra tiesiog stulpelių sąrašas. Kūnas - tai duomenų rinkinys, kuris užpildo lentelę, suskirstytas į eilutes.

- Visos vertės yra skalės. T. y., Bet kurioje lentelės eilutės / stulpelio vietoje yra tik viena reikšmė.

-Elementai

Šiame paveikslėlyje parodyta lentelė su pagrindinių elementų, kurie sudaro visą struktūrą, pavadinimais.

Tuple

Kiekviena duomenų eilutė yra suvestinė, dar vadinama įrašu. Kiekviena eilutė yra n-formos rinkinys, bet „n-“ paprastai atmetama.

Stulpelis

Kiekvienas rinkinio stulpelis vadinamas atributu arba lauku. Stulpelis parodo verčių rinkinį, kurį gali turėti konkretus atributas.

Raktas

Kiekvienoje eilutėje yra vienas ar keli stulpeliai, vadinami lentelės klavišais. Ši bendra vertė yra unikali visoms lentelės eilutėms. Naudodamiesi šiuo klavišu, kiekvienas rinkinys bus unikaliai identifikuojamas. Tai yra, rakto negalima dubliuoti. Jis vadinamas pirminiu raktu.

Kita vertus, pašalinis arba antrinis raktas yra lentelės laukas, nurodantis pirminį kai kurios kitos lentelės raktą. Jis naudojamas nuorodoms į pirminę lentelę.

- vientisumo taisyklės

Kurdami reliacinį modelį, jūs apibrėžiate kai kurias sąlygas, kurias turi atitikti duomenų bazė, vadinamas vientisumo taisyklėmis.

Rakto vientisumas

Pagrindinis raktas turi būti unikalus visoms dalims ir negali būti negaliojantis (NULL). Priešingu atveju negalėsite unikaliai identifikuoti eilutės.

Kelių stulpelių klavišuose nė viename iš stulpelių negali būti NULL.

Referencinis vientisumas

Kiekviena pašalinio rakto reikšmė turi atitikti nurodytos arba pirminės lentelės pirminio rakto vertę.

Eilę su svetimu raktu į antrinę lentelę galima įterpti tik tuo atveju, jei ši vertė egzistuoja pirminėje lentelėje.

Jei rakto vertė pasikeičia pirminėje lentelėje dėl eilutės atnaujinimo ar ištrynimo, tada visos antrinių lentelių su šiuo užsienio raktu eilutės turėtų būti atitinkamai atnaujintos arba ištrintos.

Kaip sudaryti reliacinį modelį?

-Rinkti duomenis

Turi būti surinkti reikiami duomenys, kad būtų galima saugoti duomenų bazėje. Šie duomenys yra suskirstyti į skirtingas lenteles.

Kiekvienam stulpeliui reikia pasirinkti tinkamą duomenų tipą. Pvz .: sveikieji skaičiai, slankiojo kablelio skaičiai, tekstas, data ir kt.

- Apibrėžkite pirminius klavišus

Kiekvienos lentelės pirminiu raktu turi būti pasirinktas stulpelis (arba keli stulpeliai), kuris unikaliai atpažins kiekvieną lentelės eilutę. Pagrindinis raktas taip pat naudojamas nuorodoms į kitas lenteles.

-Kurkite ryšius tarp lentelių

Duomenų bazė, susidedanti iš nepriklausomų, nesusijusių lentelių, nėra labai svarbi.

Svarbiausias aspektas kuriant reliacinę duomenų bazę yra ryšių tarp lentelių nustatymas. Santykių tipai yra šie:

Vienas daugeliui

Duomenų bazėje „Klasių sąrašas“ mokytojas gali mokyti nulinę ar daugiau klasių, o klasę moko vienas mokytojas. Šis santykių tipas yra žinomas kaip vienas su daugeliu.

Šis santykis negali būti pateiktas vienoje lentelėje. „Klasių sąrašo“ duomenų bazėje galite turėti lentelę pavadinimu „Mokytojai“, kurioje kaupiama informacija apie mokytojus.

Norėdami laikyti kiekvieno mokytojo mokomas klases, galite sukurti papildomų stulpelių, tačiau iškiltų problema: kiek stulpelių sukurti.

Kita vertus, jei turite lentelę pavadinimu „Klases“, kurioje kaupiama informacija apie klasę, galite sukurti papildomų stulpelių informacijai apie mokytoją laikyti.

Kadangi mokytojas gali mokyti daugelį klasių, jo duomenys būtų dubliuojami daugelyje klasių lentelės eilučių.

Suprojektuokite dvi lenteles

Todėl turite suprojektuoti dvi lenteles: „Klasių“ lentelę, kurioje būtų kaupiama informacija apie klases, o „Class_Id“ yra pagrindinis raktas, ir „Mokytojų“ lentelę, kurioje būtų kaupiama informacija apie mokytojus, o „Teacher_Id“ yra pagrindinis raktas.

Tada santykį „vienas su daugeliu“ galima sukurti, klasių lentelėje laikant pirminį raktą iš pagrindinės lentelės (Master_Id), kaip parodyta žemiau.

Lentelės „Classes“ stulpelis „Master_Id“ yra žinomas kaip pašalinis arba antrinis raktas.

Kiekvienai pagrindinės lentelės „Master_Id“ reikšmei klasių lentelėje gali būti nulis ar daugiau eilučių. Kiekvienai klasei „Class_Id“ reikšmei skirtoje lentelėje „Mokytojai“ yra tik viena eilutė.

Daugelis daugeliui

Duomenų bazėje „Produktų pardavimas“ kliento užsakyme gali būti keli produktai, o produktas gali būti pateiktas keliais užsakymais. Šis santykio tipas žinomas daugeliui.

„Produktų pardavimo“ duomenų bazę galite pradėti naudodami dvi lenteles: Produktai ir Užsakymai. Produktų lentelėje yra informacijos apie gaminius, kurių pagrindinis raktas yra „productID“.

Kita vertus, lentelėje „Užsakymai“ pateikiami kliento užsakymai, kurių pagrindinis raktas yra orderID.

Negalite laikyti užsakytų produktų lentelėje Užsakymai, nes nežinote, kiek stulpelių reikia rezervuoti gaminiams. Taip pat užsakymai negali būti laikomi produktų lentelėje dėl tos pačios priežasties.

Norėdami palaikyti santykius tarp daugelio, turite sukurti trečią lentelę, vadinamą prisijungimo lentele („OrderDetails“), kurioje kiekviena eilutė žymi elementą tam tikra tvarka.

Lentelės „OrderDetails“ pirminį raktą sudaro du stulpeliai: orderID ir productID, unikaliai identifikuojantys kiekvieną eilutę.

Lentelės „OrderDetails“ stulpeliai „orderID“ ir „productID“ naudojami užsakymų ir gaminių lentelėms nurodyti. Todėl jie taip pat yra svetimi raktai „OrderDetails“ lentelėje.

Vienas po kito

Duomenų bazėje „Produktų pardavimas“ produktas gali turėti pasirenkamą informaciją, pvz., Papildomą aprašymą ir jo atvaizdą. Laikydami jį produktų lentelės viduje, susidarys daug tuščių vietų.

Todėl pasirenkamiems duomenims saugoti gali būti sukurta kita lentelė („ProductExtras“). Produktams su neprivalomais duomenimis bus sukurtas tik vienas įrašas.

Dvi lentelės, „Products“ ir „ProductExtras“, yra susijusios viena su kita. Kiekvienoje „Produktų“ lentelės eilutėje yra daugiausia viena „ProductExtras“ lentelės eilutė. Tas pats produkto ID turi būti naudojamas kaip pagrindinis abiejų lentelių raktas.

Privalumas

Struktūrinė nepriklausomybė

Reliaciniame duomenų bazės modelyje duomenų bazės struktūros pakeitimai neturi įtakos prieigai prie duomenų.

Kai įmanoma pakeisti duomenų bazės struktūrą nepažeidžiant DBVS galimybės naudotis duomenimis, galima pasakyti, kad pasiektas struktūrinis nepriklausomumas.

Konceptualus paprastumas

Reliacinės duomenų bazės modelis konceptualiai yra dar paprastesnis nei hierarchinis ar tinklo duomenų bazių modelis.

Kadangi reliacinis duomenų bazės modelis atleidžia dizainerį nuo duomenų apie fizinį saugojimą, dizaineriai gali sutelkti dėmesį į loginį duomenų bazės vaizdą.

Projektavimo, diegimo, priežiūros ir naudojimo paprastumas

Reliacinės duomenų bazės modeliu pasiekiama duomenų nepriklausomybė ir struktūros nepriklausomybė, todėl duomenų bazę projektuoti, prižiūrėti, valdyti ir naudoti yra daug lengviau nei kitus modelius.

Ad-hoc užklausos talpa

Labai galinga, lanksti ir lengvai naudojama užklausų galimybė yra viena iš pagrindinių priežasčių, sukeliančių didžiulį reliacinių duomenų bazių modelių populiarumą.

Reliacinės duomenų bazės modelio užklausų kalba, vadinama struktūrizuota užklausų kalba arba SQL, ad-hoc užklausas paverčia realybe. SQL yra ketvirtosios kartos kalba (4GL).

4GL leidžia vartotojui nurodyti, ką reikia padaryti, nenurodant, kaip tai turėtų būti padaryta. Taigi, naudodamiesi SQL, vartotojai gali nurodyti, kokios informacijos jie nori, ir palikti informaciją, kaip gauti informaciją į duomenų bazę.

Trūkumai

Techninės įrangos išlaidos

Santykinis duomenų bazės modelis slepia jo diegimo sudėtingumą ir fizinio vartotojo duomenų saugojimo detales.

Norėdami tai padaryti, reliacinėms duomenų bazių sistemoms reikia kompiuterių su galingesne aparatine įranga ir duomenų saugojimo įrenginiais.

Todėl RDBMS reikia galingų mašinų, kad sklandžiai veiktų. Tačiau kadangi šiuolaikinių kompiuterių apdorojimo galia didėja eksponentiniu greičiu, didesnio apdorojimo galios poreikis šiandieniniame scenarijuje nebėra labai didelė problema.

Dėl dizaino paprastumo dizainas gali būti blogas

Reliacinę duomenų bazę lengva sukurti ir naudoti. Vartotojams nereikia žinoti sudėtingų duomenų apie fizinį saugojimą duomenų. Jiems nereikia žinoti, kaip duomenys iš tikrųjų saugomi, kad prie jų prieitų.

Dėl tokio dizaino ir naudojimo paprastumo gali būti sukurtos ir įdiegtos blogai suprojektuotos duomenų bazių valdymo sistemos. Kadangi duomenų bazė yra efektyvi, šie projektavimo neveiksmingumai nebus išaiškinti, kai bus sukurta duomenų bazė ir kai yra tik nedaug duomenų.

Augant duomenų bazei, prastai suprojektuotos duomenų bazės sulėtins sistemos veikimą ir gali pabloginti našumą bei sugadinti duomenis.

„Informacinių salų“ fenomenas

Kaip minėta anksčiau, reliacines duomenų bazių sistemas lengva įgyvendinti ir naudoti. Tai sukurs situaciją, kai per daug žmonių ar departamentų sukurs savo duomenų bazes ir programas.

Šios informacijos salos neleis integruoti informacijos, kuri yra būtina sklandžiam ir efektyviam organizacijos funkcionavimui.

Šios atskiros duomenų bazės taip pat sukurs tokių problemų kaip duomenų nenuoseklumas, duomenų dubliavimas, duomenų dubliavimas ir kt.

Pavyzdys

Tarkime, duomenų bazę, kurią sudaro tiekėjų, dalių ir siuntų lentelės. Lentelių struktūra ir kai kurie pavyzdžių įrašai yra tokie:

Kiekviena Tiekėjų lentelės eilutė žymima unikaliu tiekėjo numeriu (SNo), unikaliai nurodant kiekvieną lentelės eilutę. Taip pat kiekviena dalis turi unikalų dalies numerį (PNo).

Be to, vežimų lentelėje negali būti daugiau nei vienas pristatymas tam tikram tiekėjo / detalės deriniui, nes šis derinys yra pagrindinis siuntų raktas, kuris tarnauja kaip sąjunginė lentelė, nes tai yra santykis tarp daugelio.

Santykis tarp dalių ir siuntų lentelių pateikiamas turint bendrą lauką PNo (dalies numeris), o santykis tarp tiekėjų ir siuntų atsiranda turint bendrą SNo lauką (tiekėjo numerį).

Išanalizavus siuntų lentelę, galima gauti informacijos, kad iš „Suneet“ ir „Ankit“ tiekėjų iš viso siunčiama 500 riešutų, po 250.

Panašiai iš trijų skirtingų tiekėjų buvo atsiųsta 1100 varžtų. Iš „Suneet“ tiekėjo buvo išsiųsti 500 mėlynų varžtų. Nėra gabenamų raudonų varžtų.

Nuorodos

1. Vikipedija, nemokama enciklopedija (2019). Santykinis modelis. Paimta iš: en.wikipedia.org.
2. „Techopedia“ (2019 m.). Reliacinis modelis. Paimta iš: ribapedia.com.
3. Dineshas Thakuras (2019 m.). Reliacinis modelis. Kompiuterio užrašai. Paimta iš: ecomputernotes.com.
4. Geeks už Geeksą (2019). Reliacinis modelis. Paimta iš: geeksforgeeks.org.
5. Nanjano technologijos universitetas (2019). Greita pradžios duomenų bazių projektavimo pamoka. Paimta iš: ntu.edu.sg.
6. Adrienne Watt (2019 m.). 7 skyrius. Santykinių duomenų modelis. BC atidaryti vadovėliai. Paimta iš: opentextbc.ca.
7. „Toppr“ (2019 m.). Reliacinės duomenų bazės ir schemos. Paimta iš: toppr.com.