logo

Duomenų bazės dizainas

Duomenų bazės dizainas

Įvadas

Galbūt mes susidūrėme su žodžiu ' Duomenų bazė ' gana dažnai. Šis terminas labai pabrėžia jo rankas. Dažniau tai susiję ne tik su kūrėjo perspektyva, bet gana dažnai naudojama ne technologijų grupėms ar bendruomenėms. Techniškai duomenų bazė yra labiau saugojimo terminas, naudojamas apibūdinti ryšį su skirtingų formų duomenimis, kurie yra koaguliuojami vienoje vietoje. Taigi duomenų bazę galime apibrėžti kaip organizuotą duomenų rinkinį, paprastai saugomą ir pasiekiamą elektroniniu būdu per kompiuterines sistemas. Šis straipsnis yra labai orientuotas į duomenų bazės dizainą ir dažniausiai buvo atsižvelgiama į jo susiejimą su cituojamais terminais ir metodikomis. Aptarsime tuos terminus, susijusius su duomenų bazės dizainu, kad suprastume detales ir dalis. Pakalbėkime apie tai iš karto.

„Linux“ spartieji klavišai

Kas yra duomenų bazės dizainas?

Duomenų bazės projektavimas paprastai gali būti apibrėžtas kaip užduočių arba procesų rinkinys, kuris pagerina įmonės duomenų valdymo sistemos projektavimą, kūrimą, diegimą ir priežiūrą. Tinkamos duomenų bazės sukūrimas sumažina priežiūros išlaidas, taip pagerindamas duomenų nuoseklumą, o ekonomiškai efektyvioms priemonėms daroma didelė įtaka vietos diske. Todėl turi būti puiki duomenų bazės kūrimo koncepcija. Projektuotojas turėtų laikytis apribojimų ir nuspręsti, kaip elementai koreliuoja ir kokie duomenys turi būti saugomi.

Pagrindiniai duomenų bazių projektavimo tikslai yra sukurti siūlomos duomenų bazių sistemos fizinius ir loginius projektavimo modelius. Norint tai išplėtoti, loginis modelis visų pirma yra sutelktas į duomenų reikalavimus, todėl reikia atsižvelgti į monolitinius svarstymus, todėl saugomi fiziniai duomenys turi būti saugomi nepriklausomai nuo fizinių sąlygų. Kita vertus, fizinės duomenų bazės projektavimo modelis apima loginio duomenų bazės projektavimo modelio vertimą kontroliuojant fizinę laikmeną naudojant aparatūros išteklius ir programinės įrangos sistemas, tokias kaip duomenų bazių valdymo sistema (DBVS).

Kodėl duomenų bazės dizainas yra svarbus?

Svarbią aplinkybę, į kurią galima atsižvelgti pabrėžiant duomenų bazės projektavimo svarbą, galima paaiškinti toliau pateiktais punktais.

  1. Duomenų bazės dizainas pateikia brėžinius, kaip duomenys bus saugomi sistemoje. Tinkamas duomenų bazės dizainas labai paveikia bendrą bet kurios programos veikimą.
  2. Duomenų bazei apibrėžti projektavimo principai suteikia aiškų supratimą apie bet kurios programos elgseną ir tai, kaip apdorojamos užklausos.
  3. Kitas pavyzdys, kuriuo reikia pabrėžti duomenų bazės dizainą, yra tai, kad tinkamas duomenų bazės dizainas atitinka visus vartotojų reikalavimus.
  4. Galiausiai, programos apdorojimo laikas labai sutrumpėja, jei tinkamai įgyvendinami labai efektyvios duomenų bazės kūrimo apribojimai.

Gyvenimo ciklas

Nors duomenų bazės gyvavimo ciklas nėra svarbi diskusija, kurią reikia tęsti šiame straipsnyje, nes mes sutelkiame dėmesį į duomenų bazės dizainą. Tačiau prieš pereinant tiesiai prie projektavimo modelių, sudarančių duomenų bazės dizainą, svarbu suprasti bendrą duomenų bazės darbo eigą ir gyvavimo ciklą.

Reikalavimų analizė

Visų pirma, reikia planuoti, kokie yra pagrindiniai projekto reikalavimai, pagal kuriuos reikia tęsti duomenų bazės kūrimą. Taigi juos galima apibrėžti taip:

Planavimas - Šis etapas yra susijęs su viso DDLC (duomenų bazės kūrimo gyvavimo ciklo) planavimu. Prieš tęsiant atsižvelgiama į strateginius sumetimus.

Sistemos apibrėžimas - Šis etapas apima tinkamos duomenų bazės ribas ir apimtis po planavimo.

Duomenų bazių projektavimas

Kitas žingsnis apima duomenų bazės sukūrimą, atsižvelgiant į vartotojo reikalavimus, ir suskirstymą į įvairius modelius, kad nebūtų taikoma apkrova ar didelė priklausomybė nuo vieno aspekto. Todėl buvo taikomas tam tikras į modelį orientuotas požiūris, todėl loginiai ir fiziniai modeliai atlieka esminį vaidmenį.

Fizinis modelis - Fizinis modelis yra susijęs su loginio modelio praktika ir įgyvendinimu.

java data dabar

Loginis modelis - Šis etapas visų pirma susijęs su modelio kūrimu pagal siūlomus reikalavimus. Visas modelis sukurtas popieriuje, neįgyvendinant ir neatsižvelgiant į DBVS.

Įgyvendinimas

Paskutinis žingsnis apima diegimo metodus ir mūsų reikalavimus atitinkančios elgsenos patikrinimą. Tai užtikrina nuolatinis duomenų bazės su skirtingais duomenų rinkiniais integravimo testavimas ir duomenų konvertavimas į mašinai suprantamą kalbą. Manipuliavimas duomenimis visų pirma yra sutelktas į šiuos veiksmus, kai užklausos yra paleidžiamos ir patikrinama, ar programa sukurta patenkinamai, ar ne.

Duomenų konvertavimas ir įkėlimas - Šis skyrius naudojamas duomenims importuoti ir konvertuoti iš senosios sistemos į naują.

išteklių paskirstymo grafikas

Testavimas - Šis etapas susijęs su klaidų nustatymu naujai įdiegtoje sistemoje. Testavimas yra labai svarbus žingsnis, nes jis tiesiogiai patikrina duomenų bazę ir lygina reikalavimų specifikacijas.

Duomenų bazės projektavimo procesas

Duomenų bazės kūrimo procesas apima įvairius konceptualius metodus, kuriuos reikia turėti omenyje. Idealus ir gerai struktūrizuotas duomenų bazės dizainas turi turėti galimybę:

  1. Sutaupykite vietos diske pašalindami perteklinius duomenis.
  2. Išlaiko duomenų vientisumą ir tikslumą.
  3. Suteikia prieigą prie duomenų naudingais būdais.
  4. Loginių ir fizinių duomenų modelių palyginimas.

Logiška

Loginis duomenų modelis paprastai aprašo duomenis kuo detaliau, nesijaudinant dėl ​​fizinių duomenų bazės įdiegimų. Loginio duomenų modelio ypatybės gali apimti:

  1. Visi subjektai ir santykiai tarp jų.
  2. Kiekvienas subjektas turi gerai apibrėžtus atributus.
  3. Nurodomas kiekvieno objekto pirminis raktas.
  4. Nurodomi išoriniai raktai, naudojami ryšiams tarp skirtingų objektų nustatyti.
  5. Šiame lygyje vyksta normalizavimas.

Loginis modelis gali būti sukurtas naudojant šį metodą:

  1. Nurodykite visus objektus su pirminiais raktais.
  2. Nurodykite lygiagrečius ryšius tarp skirtingų objektų.
  3. Išsiaiškinkite kiekvieno objekto atributus
  4. Išspręskite daug prieš daugelį santykių.
  5. Atlikite normalizavimo procesą.

Be to, vienas svarbus veiksnys po pirmiau pateikto požiūrio yra kritiškai išnagrinėti dizainą, pagrįstą reikalavimų rinkimu. Jei griežtai laikomasi aukščiau nurodytų veiksmų, yra tikimybė, kad bus sukurtas labai efektyvus duomenų bazės dizainas, atitinkantis vietinį metodą.

Norėdami suprasti šiuos dalykus, žiūrėkite toliau pateiktą paveikslėlį, kad gautumėte aiškų vaizdą.

Jei palyginsime loginių duomenų modelį, kaip parodyta aukščiau esančiame paveikslėlyje, su kai kuriais diagramos duomenų pavyzdžiais, galime gauti faktus, kad konceptualiame duomenų modelyje pirminio rakto nėra, o loginis duomenų modelis turi pirminius raktus visas jo savybes. Be to, loginiai duomenys modeliuoja dangtelio ryšį tarp skirtingų objektų ir suteikia vietos išoriniams raktams užmegzti ryšius tarp jų.

Fizinis

Fizinių duomenų režimas paprastai parodo duomenų bazės kūrimo metodą ar koncepciją. Pagrindinis fizinių duomenų modelio tikslas yra parodyti visus struktūros lentelės, įskaitant stulpelio pavadinimas, stulpelio duomenų tipas, apribojimai, raktai (pirminis ir svetimas) ir ryšį tarp lentelių. Toliau pateikiamos fizinių duomenų modelio savybės:

  1. Nurodo visus stulpelius ir lenteles.
  2. Nurodo svetimus raktus, kurie paprastai apibrėžia ryšį tarp lentelių.
  3. Atsižvelgiant į vartotojo reikalavimus, gali įvykti normalizavimas.
  4. Kadangi atsižvelgiama į fizinį veiksnį, skirtumo priežastys bus aiškios nei loginis modelis.
  5. Skirtingų RDBVS fiziniai modeliai gali skirtis. Pavyzdžiui, „MySQL“ ir „SQL Server“ duomenų tipo stulpelis gali skirtis.

Kuriant fizinių duomenų modelį, reikia atsižvelgti į šiuos dalykus:

  1. Konvertuokite objektus į lenteles.
  2. Konvertuokite apibrėžtus ryšius į užsienio raktus.
  3. Konvertuokite duomenų atributus į stulpelius.
  4. Modifikuokite duomenų modelio apribojimus pagal fizinius reikalavimus.

Palyginus šį fizinių duomenų modelį su loginiu su ankstesniu loginiu modeliu, galime daryti išvadą, kad fizinėje duomenų bazėje objektų pavadinimai laikomi lentelių pavadinimais, o atributai laikomi stulpelių pavadinimais. Be to, kiekvieno stulpelio duomenų tipas yra apibrėžtas fiziniame modelyje, atsižvelgiant į faktiškai naudojamą duomenų bazę.

Žodynėlis

Esybė - Duomenų bazėje esantis subjektas gali būti apibrėžtas kaip abstraktūs duomenys, kuriuos išsaugome savo duomenų bazėje. Pavyzdžiui, klientas, produktai.

centruoti vaizdą css

Atributai - Atributas yra išsami duomenų forma, kurią sudaro tokie objektai kaip ilgis, pavadinimas, kaina ir kt.

Santykiai - Ryšys gali būti apibrėžtas kaip ryšys tarp dviejų esybių arba figūrų. Pavyzdžiui, asmuo gali būti susijęs su keliais asmenimis šeimoje.

Svetimas raktas - Tai veikia kaip nukreipimas į kitos lentelės pirminį raktą. Svetimajame rakte yra stulpelių su reikšmėmis, kurios egzistuoja tik pirminio rakto stulpelyje, į kurį jie nurodo.

Pirminis raktas - Pirminis raktas yra įrašų rodyklė, kuri yra unikali, o ne nulinė ir naudojama unikaliai identifikuoti lentelės atributus.

tat pilna forma

Normalizavimas – Lankstus duomenų modelis turi atitikti tam tikras taisykles. Šių taisyklių taikymas vadinamas normalizavimu.

Santrauka

Duomenų bazės projektavimas yra metodas, leidžiantis nustatyti spragas ir galimybes sukurti tinkamą panaudojimo metodą. Tai yra pagrindinis sistemos komponentas, kuris pateikia duomenų ir jų elgesio sistemoje planą. Tinkamam duomenų bazės dizainui visada teikiama pirmenybė, nes vartotojo reikalavimai yra per aukšti, o duomenų bazės kūrimo suvaržymų praktikos laikymasis gali būti tik galimybė pasiekti pageidaujamą efektyvumą. Be to, mes taip pat atskirai sužinojome apie skirtingus dizaino modelius, vaizduojančius idealų duomenų bazės dizainą, kartu su neribotomis diskusijomis apie jų savybes ir jų panaudojimą. Be to, sužinojome, kaip duomenų bazės gyvavimo ciklas lemia duomenų bazės dizainą ir kaip projektavimo koncepciją įtraukti į gyvavimo ciklo metodus, kad būtų galima sukurti efektyvias ir labai sudėtingas duomenų bazes, atsižvelgiant į vartotojo poreikius.