Andmebaasi projekteerimine. Parimad praktikad

Kursuse järgse voolu alguse eel Andmebaasid oleme koostanud väikese autoriartikli, kus on olulised näpunäited andmebaasi koostamiseks. Loodame, et see materjal on teile kasulik.

Andmebaasid on igal pool: alates kõige lihtsamatest blogidest ja kataloogidest kuni usaldusväärsete infosüsteemide ja suurte sotsiaalsete võrgustikeni. Ei ole nii oluline, kas andmebaas on lihtne või keeruline, vaid kui oluline on selle õige projekteerimine. Kui andmebaas on projekteeritud mõtlematult ja selge eesmärgita, ei ole see mitte ainult ebaefektiivne, vaid edasine töö andmebaasiga on kasutajatele tõeline piin ja läbimatu mets. Siin on mõned näpunäited andmebaasi koostamiseks, mis aitavad luua kasuliku ja kasutajasõbraliku toote.

1. Määrake, milleks tabel on ja milline on selle struktuur

Täna aitavad sellised arendusmeetodid nagu Scrum või RAD (kiire rakenduste arendus) IT-meeskondadel andmebaase kiiresti arendada. Kuid ajahimu tõttu on väga suur kiusatus sukelduda otse andmebaasi ehitamisse, halvasti mõistes, mis on eesmärk ja millised peaksid olema lõpptulemused.
 
Käib nagu meeskond, kes sihib efektiivset ja kiiret tööd, kuid see on peaaegu illusioon. Mida kaugemale ja kiiremini projekti süvenetakse, seda rohkem aega kulub vigade tuvastamiseks ja muutmiseks andmebaasi projektis.

Seetõttu on esimene asi, mida tuleb lahendada, määrata oma andmebaasi eesmärk. Millise rakenduse jaoks andmebaas välja töötatakse? Kas kasutaja töötab lihtsalt kirjetega ja tuleb pöörata tähelepanu tehingutele või huvitab teda rohkem andmete analüüs? Kuidas andmebaas peab olema üles seatud? Kas see jälgib klientide käitumist või haldab lihtsalt nende vahelisi suhteid? 

Mida varem projekteerimismeeskond nendele küsimustele vastab, seda sujuvam ja lihtsam on andmebaasi projekteerimisprotsess.

2. Millised andmed valida talletamiseks?

Plaanige ette. Mõelge sellele, mida tulevikus veebisait või süsteem, mille jaoks andmebaas on kavandatud, teeb. Oluline on ületada tavalised tehnilise ülesande nõudmised. Kuid palun, ärge alustage kohe mõtlemist kõikidele võimalikele andmetüüpidele, mida kasutaja kunagi salvestada võib. Mõelge pigem sellele, kas kasutajad saavad kirjutada postitusi, üles laadida dokumente või fotosid või vahetada sõnumeid. Kui jah, siis peab andmebaasis nende jaoks ruumi olema.

Töötage meeskonna, osakonna või organisatsiooniga, kelle jaoks kavandatud andmebaasi tulevikus toetatakse. Suhelge eri tasandite inimestega, alates klienditeeninduse spetsialistidest kuni osakonnajuhatajateni. Nii saad tagasiside abil selge arusaama ettevõtte nõudmistest. 

Kasutajate vajadused isegi ühe osakonna raames on paratamatult konfliktis. Kui te selle otsaga silmitsi seisate, ärge kartke toetuda oma kogemusele ja leida kompromiss, mis rahuldab kõiki osalisi ja teenib andmebaasi lõppeesmärki. Olge kindel: tulevikus saad +100500 karma ja mägi küpsiseid.

3. Modelleerige andmeid ettevaatlikult

Andmete modelleerimisel on mõned olulised punktid, millele tasub tähelepanu pöörata. Nagu me varem ütlesime, sõltub andmebaasi otstarve sellest, milliseid meetodeid kasutada modelleerimisel. Kui me projekteerime andmebaasi operatiivseks kirje töötlemiseks (OLTP), teisisõnu nende loomiseks, redigeerimiseks ja kustutamiseks, siis kasutame tehingute modelleerimist. Kui andmebaas peab olema relatsiooniline, siis on kõige parem rakendada mitmemõõtmelist modelleerimist.

Modelleerimise käigus luuakse kontseptuaalsed (CDM), füüsilised (PDM) ja loogilised (LDM) andmemudelid. 

Kontseptuaalsed mudelid kirjeldavad subjekte ja andmetüüpe, mida need sisaldavad, ning nendevahelisi suhteid. Jagage oma andmed loogilisteks tükkideks — nii on elu palju lihtsam.
Peamine on mõõt, ärge liialdage.

Kui subjekti on väga raske ühe sõna või fraasiga klassifitseerida, on aeg kasutada alamtype (tütarsubjekte).

Kui subjekt elab oma elu, omab atribuutide, mis kirjeldavad selle käitumist ja välimust, samuti suhteid teiste objektidega, võib julgelt kasutada mitte ainult alamtype, vaid ka ülemtype (vanemsubjekt). 

Kui seda reeglit ei järgita, segad teised arendajad teie mudelis ära ja nad ei saa täielikult aru andmetest ja reeglitest, kuidas neid koguda.

Kontseptuaalsed mudelid viiakse ellu loogiliste mudelite kaudu. Need mudelid nagu maakaart füüsilise andmebaasi projekteerimiseks. Loogilises mudelis tuvastatakse äriliste andmete subjektiid, määratakse andmetüübid, võtme staatuse reeglid, mis reguleerivad andmete vahelisi suhteid.

Seejärel sätitakse Loogiline andmemudel valitud eelnevalt platvormi SÜDB (süsteemi database management) ja se loob füüsilise mudeli. See kirjeldab andmete füüsilise salvestamise viisi.

4. Kasutage sobivaid andmetüüpe

Vale andmetüübi kasutamine võib põhjustada vähem täpseid andmeid, raskusi tabelite ühendamisel, atribuutide sünkroonimisel ja suurte failide tekkimist.
Teabe terviklikkuse tagamiseks peab atribuut sisaldama ainult sobivaid andmetüüpe. Kui andmebaasi kantakse vanus, siis veenduge, et veerus on salvestatud maksimaalselt 3-kohalised täisarvud.

Looge minimaalselt tühje veerge, millel on NULL väärtus. Kui kõik veerud on NULL, siis on see tõsine viga. Kui aga vajate tühja veergu konkreetse äritegevuse funktsiooni täitmiseks olukordades, kus andmed on teadmata või veel ei oma tähendust, siis looge see julgelt. Lõppude lõpuks ei saa me ette täita veerge 'Surma kuupäev' või 'Küsimiseks kuupäev', me ei ole ennustajad, kes plaksutavad õhku :-).

Enamik modelleerimistarkvarasid (ER/Studio, MySQL Workbench, SQL DBM, gliffy.andmete struktuur võimaldab luua andmevaldkondade prototüüpe. See tagab mitte ainult õige andmetüübi, rakenduse loogika ja hea jõudluse, vaid ka vajalikud väärtuse määramise.

5. Eelistage loomulikku

Otsustades, millist tabeli veergu valida võtmena, pöörake alati tähelepanu, milliseid välju kasutaja saab redigeerida. Ärge kunagi valige neid võtmena — see on halb mõte. Kõike võib juhtuda, ja te peate tagama unikaalsuse.

Parim on kasutada loomulikku, ehk äri võtme (natural key). See omab tähenduslikku sisu, nii vältite andmebaasis dubleeritust. 

Kui aga äri võti ei ole unikaalne (nimi, perekonnanimi, amet) ja kordub erinevates tabeliridades või kui see peab muutuma, tuleks esmaseks võtmiseks määrata genereeritud kunstlik, surrogaatvõti (artificial key).

6. Normaliseerige määral

Andmete tõhusaks korraldamiseks andmebaasis on vajalik järgida teatud soovitusi ja normaliseerida andmebaasi. On olemas viis normaalset vormi, millega tuleb arvestada.
Normaliseerimise abil vältite liigset kordumist ja tagate rakenduses või veebisaidil kasutatavate andmete terviklikkuse.

Nagu alati, peab kõike olema mõõdukalt, sealhulgas normaliseerimist. Kui andmebaasis on liiga palju tabeleid, millel on sama unikaalne võti, olete liialdanud ja normaliseerinud andmebaasi liialt. Ülemäärane normaliseerimine mõjutab andmebaasi jõudlust negatiivselt.

7. Testige varakult, testige tihti

Testimisplaan ja korralik testimine peavad olema andmebaasi projekteerimise osa.

Andmebaasi on kõige parem testida pideva integreerimise (Continuous Integration) kaudu. Modelleerige stsenaarium "Üks päev andmebaasi elust" ja kontrollige, kas kõik piirjuhtumid on hallatud ning millised kasutajate interaktsioonid on tõenäolised. Mida varem leidate vead, seda rohkem säästate aega ja raha.

Need on ainult seitse nõuannet, mille abil saate kujundada suurepärase andmebaasi jõudluse ja tõhususe osas. Kui järgite neid, suudate vältida enamikku tulevikus tekkivaid peavalusid. Need nõuanded on vaid jäämäe tipp andmebaasi modelleerimises. On tohutult palju nippe. Milliseid kasutate?

Allikas: habr.com