Laukiant kito srauto pradžios greičiu Parengėme nedidelę autorinę medžiagą su svarbiais patarimais kuriant duomenų bazę. Tikimės, kad ši medžiaga jums bus naudinga.
Duomenų bazės yra visur: nuo paprasčiausių tinklaraščių ir katalogų iki patikimų informacinių sistemų ir didelių socialinių tinklų. Nesvarbu, ar duomenų bazė yra paprasta, ar sudėtinga, svarbu ją tinkamai suprojektuoti. Kai duomenų bazė kuriama neapgalvotai ir aiškiai nesuvokiant tikslo, tai ne tik neefektyvu, bet ir tolesnis darbas su duomenų baze bus tikra kančia, neįžengiamas miškas vartotojams. Štai keletas duomenų bazės kūrimo patarimų, kurie padės sukurti naudingą ir lengvai naudojamą produktą.
1. Nustatykite, kam skirta lentelė ir kokia jos struktūra
Šiandien tokie kūrimo metodai kaip Scrum arba RAD (Rapid Application Development) padeda IT komandoms greitai kurti duomenų bazes. Tačiau vaikantis laiko labai didelė pagunda nerti tiesiai į bazės kūrimą, miglotai įsivaizduojant, koks pats tikslas, kokie turėtų būti galutiniai rezultatai.
Atrodo, kad komanda sutelkta į efektyvų, greitą darbą, bet tai yra miražas. Kuo toliau ir greičiau pasinersite į projekto gilumą, tuo daugiau laiko prireiks duomenų bazės dizaino klaidoms nustatyti ir pakeisti.
Taigi pirmas dalykas, kurį turite nuspręsti, yra apibrėžti savo duomenų bazės tikslą. Kokio tipo programai kuriama duomenų bazė? Ar vartotojas dirbs tik su įrašais ir turės atkreipti dėmesį į sandorius, ar jam labiau rūpi duomenų analizė? Kur turėtų būti dislokuota bazė? Ar jis stebės klientų elgesį ar tiesiog valdys santykius su klientais?
Kuo anksčiau projektavimo komanda atsakys į šiuos klausimus, tuo sklandesnis bus duomenų bazės kūrimo procesas.
2. Kokius duomenis turėčiau pasirinkti saugojimui?
Planuoti iš anksto. Mintys apie tai, ką svetainė ar sistema, kuriai kuriama duomenų bazė, veiks ateityje. Svarbu peržengti paprastus techninių specifikacijų reikalavimus. Tik nepradėkite galvoti apie visus galimus duomenų tipus, kuriuos vartotojas kada nors saugos. Verčiau pagalvokite, ar vartotojai galės rašyti įrašus, įkelti dokumentus ar nuotraukas, keistis žinutėmis. Jei taip yra, tuomet turite jiems skirti vietos duomenų bazėje.
Dirbkite su komanda, skyriumi ar organizacija, kurios projektavimo bazė bus palaikoma ateityje. Bendraukite su įvairaus lygio žmonėmis – nuo klientų aptarnavimo specialistų iki skyrių vadovų. Tokiu būdu atsiliepimų pagalba gausite aiškų supratimą apie įmonės reikalavimus.
Neišvengiamai prieštaraus vartotojų poreikiai net tame pačiame skyriuje. Jei susidursite su tuo, nebijokite pasikliauti savo patirtimi ir rasti kompromisą, kuris tiktų visoms šalims ir atitiktų galutinį duomenų bazės tikslą. Būkite tikri: ateityje gausite +100500 karmos ir kalną sausainių.
3. Atsargiai modeliuokite duomenis
Modeliuojant duomenis reikia atkreipti dėmesį į keletą pagrindinių dalykų. Kaip minėjome anksčiau, duomenų bazės paskirtis lemia, kokius metodus naudoti modeliuojant. Jei kuriame duomenų bazę, skirtą internetiniam įrašų apdorojimui (OLTP), kitaip tariant įrašams kurti, redaguoti ir ištrinti, naudojame transakcijų modeliavimą. Jei duomenų bazė turi būti reliacinė, geriausia naudoti daugiamatį modeliavimą.
Modeliavimo metu sukuriami konceptualūs (CDM), fiziniai (PDM) ir loginiai (LDM) duomenų modeliai.
Koncepciniai modeliai apibūdina esybes ir į juos įtrauktų duomenų tipus, taip pat ryšius tarp jų. Padalinkite duomenis į loginius gabalus – tai labai palengvina gyvenimą.
Svarbiausia yra saikas, nepersistenkite.
Jei esybę labai sunku suskirstyti į vieną žodį ar frazę, laikas naudoti potipius (antrinius subjektus).
Jei esybė gyvena savo gyvenimą, turi atributų, apibūdinančių jo elgesį ir išvaizdą, taip pat santykius su kitais objektais, tuomet galite saugiai naudoti ne tik potipį, bet ir supertipą (pagrindinį subjektą).
Jei nepaisysite šios taisyklės, kiti kūrėjai susipainios jūsų modelyje ir visiškai nesupras duomenų bei jų rinkimo taisyklių.
Koncepciniai modeliai įgyvendinami naudojant loginius. Šie modeliai yra tarsi fizinės duomenų bazės projektavimo planas. Loginiame modelyje identifikuojami verslo duomenų subjektai, nustatomi duomenų tipai ir taisyklės rakto būsena, kuri valdo ryšius tarp duomenų.
Tada Loginis duomenų modelis lyginamas su iš anksto pasirinkta DBVS (duomenų bazių valdymo sistemos) platforma ir gaunamas fizinis modelis. Jame aprašoma, kaip duomenys yra fiziškai saugomi.
4. Naudokite tinkamus duomenų tipus
Naudojant netinkamą duomenų tipą gali būti netikslūs duomenys, gali kilti sunkumų sujungiant lenteles, sunku sinchronizuoti atributus ir padidėti failų dydžiai.
Siekiant užtikrinti informacijos vientisumą, atribute turi būti tik jam priimtinų duomenų tipų. Jei į duomenų bazę įvedamas amžius, įsitikinkite, kad stulpelyje yra ne daugiau kaip 3 skaitmenų sveikieji skaičiai.
Sukurkite mažiausiai tuščių stulpelių su NULL reikšme. Jei kuriate visus stulpelius kaip NULL, tai yra didelė klaida. Jei jums reikia tuščio stulpelio konkrečiai verslo funkcijai atlikti, kai duomenys nežinomi arba dar neturi prasmės, drąsiai jį sukurkite. Juk negalime iš anksto pildyti stulpelių „Mirties data“ ar „Atleidimo data“, nesame pirštu į dangų rodantys pranašai :-).
Dauguma modeliavimo programinės įrangos (ER/Studio, MySQL Workbench, SQL DBM, gliffy.com) duomenys leidžia kurti duomenų regionų prototipus. Tai užtikrina ne tik teisingą duomenų tipą, programos logiką ir gerą našumą, bet ir reikalingą reikšmę.
5. Eik natūraliai
Spręsdami, kurį lentelės stulpelį naudoti kaip raktą, visada apsvarstykite, kuriuos laukus vartotojas gali redaguoti. Niekada nesirinkite jų kaip rakto – bloga idėja. Visko gali nutikti, bet jūs turite būti tikri, kad tai unikalu.
Geriausia naudoti natūralų arba verslo raktą. Jis turi semantinę reikšmę, todėl išvengsite dubliavimosi duomenų bazėje.
Išskyrus atvejus, kai verslo raktas yra unikalus (vardas, pavardė, pareigos) ir kartojasi skirtingose lentelės eilutėse arba turi keistis, tada sugeneruotas dirbtinis raktas turėtų būti priskirtas pirminiam raktui.
6. Normalizuokite saikingai
Norėdami efektyviai tvarkyti duomenis duomenų bazėje, turite laikytis gairių ir normalizuoti duomenų bazę. Yra penkios normalios formos.
Normalizuodami išvengsite pertekliaus ir užtikrinsite programoje ar svetainėje naudojamų duomenų vientisumą.
Kaip visada, viskas turėtų būti saikingai, net normalizuoti. Jei duomenų bazėje yra per daug lentelių su tais pačiais unikaliais raktais, vadinasi, jūs nuviliote ir per daug normalizavote duomenų bazę. Per didelis normalizavimas neigiamai veikia duomenų bazės našumą.
7. Išbandykite anksti, testuokite dažnai
Bandymo planas ir tinkamas testavimas turėtų būti duomenų bazės projektavimo dalis.
Geriausias būdas patikrinti duomenų bazę yra nuolatinis integravimas. Imituokite „dienos duomenų bazės gyvavimo“ scenarijų ir patikrinkite, ar tvarkomi visi kraštutiniai atvejai ir kokios vartotojo sąveikos yra tikėtinos. Kuo greičiau rasite klaidų, tuo daugiau sutaupysite laiko ir pinigų.
Tai tik septyni patarimai, kuriuos galite naudoti kurdami puikią našumo ir efektyvumo duomenų bazę. Jei laikysitės jų, išvengsite daugumos galvos skausmo ateityje. Šie patarimai yra tik ledkalnio viršūnė modeliuojant duomenų bazes. Yra daugybė „life hackų“. Kokius naudoji?
Šaltinis: www.habr.com