Datu modelēšana iet cieši rokrokā ar datubāzēm un SQLu. Bez konceptuālās modelēšanas nav iespējams (vai ir ļoti maza varbūtība) iegūt datubāzes modeli, kuru varēs veiksmīgi izmantot gan lai rakstītu saprātīgus pieprasījumus, gan lai potenciālas izmaiņas nenovestu pie pilnīgas esošā modeļa pārstrādes, gan lai pieprasījumu rezultāti tiktu iegūti pieteikami ātri. Tieši tāpat kā bez projektēšanas nav iespējams uzcelt lielu māju, lai tā nesagāztos un nebūtu šķība, tāpat bez datu modelēšanas nav iespējams iegūt labu datu modeli daudzmaz sarežģītākai situācijai. Savukārt mazmājiņai vai mazam šķūnītim nekāds oficiāls projekts, protams, nav vajadzīgs, bet nu mazs uzmetums uz papīra arī nebūt neskādētu. Bez loģiskās datu modelēšanas, ķeroties uzreiz pie tabulām, var ļoti viegli pazaudēt kopējo pārskatu, izlaist detaļas, izveidot katru modeļa daļu savādāk, nepamanīt kādas kopējas lietas, ko varētu unificēt utt. utjp.
Kas ir datu modelēšana?
Datu modelēšana ir process, kura laikā tiek analizēti un saprasti biznesam svarīgie datu objekti un kura rezultātā tiek izveidots datu modelis. Ar biznesu šet jāsaprot kāda joma, ko Jūs esat nolēmuši analizēt un saprast, piemēram, tā var būt mājas bibliotēkas uzskaites izveide (populārs uzdevums studentiem), grāmatvedība, dokumentu vadība, metamodeļa (modelis par datu modeli) izveide. Analīze un saprašana, protams, kaut kādē mērā ir formalizēta, vai vismaz tās vizuālais rezultāts – datu modelis – ir formalizēts. Tas nozīmē, ka Jūs varat sev šo modeli fiksēt jebkādā veidā, bet ir vispārpieņemtas notācijas, kā to pieņemts darīt tā, lai saprastu arī citi ļaudis. Tādas piemēram ir ER (Entity-relationship) modelēšana vai UML (Unified modeling language).
Kā norisinās datu modelēšana?
Datu modelēšana parasti notiek prasību analīzes laikā. Prasību analīzi var uztvert kā formālu procesu ar formālu gala dokumentu (programmatūras prasību specifikāciju), bet pat, ja tas nenotiek tik formāli, kaut kādā mērā tas notiek vienmēr. Vai nu to dara prātā, vai uz papīra, vai haotiski, vai metodiski, bet process vienalga notiek. Tad nu lūk šai laikā tiek identificētas un uzskaitītas konkrētās jomas svarīgās lietas, par kurām:
- mēs kaut ko gribam zināt vai
- saglabāt informāciju vai
- notiek to apstrāde vai
- viss augšminētais kopā.
Šīs svarīgās lietas var būt dažādas, piemēram:
- fiziskas taustāmas lietas – grāmatas, mājas, mašīnas;
- netaustāmas lietas – bankas konts, grāmatas pasūtījums;
- notikumi – grāmatas pārdošana, mājas izīrēšana, mašīnas tehniskā apkope.
Šīs svarīgās lietas sauc par entītijām (entity). Vienlaicīgi ar entītiju identificēšanu tiek noskaidrotas vēl divas lietas:
- to savstarpējā saistība – relācijas (relationships) un
- lietas, kas entītijas identificē, apraksta un izskaidro tuvāk – atribūti.
Savstarpējo saistību piemērs – entītijai Grāmata ir Autors, tas ir, konkrētu Grāmatu ir uzrakstījis viens vai vairāki konkrēti Autori, un, savukārt, konkrēts Autors ir uzrakstījis vienu vai vairākas Grāmatas. Lūk mēs esam nonākuši jau pie jēdziena kardinalitāte – relācijai katrā tās galā var pateikt atkārtošanās skaitu. Piemēram, Grāmatai var būt vairāki Autori, bet tai ir viens Īpašnieks.
Atribūti, savukārt, vai nu identificē, vai paskaidro Entītijas. Mēs varam atrast konkrētu Mašīnu pec tās Reģistrācijas numura (abstrahējoties no sarežģītiem gadījumiem, kad Latvijā pārdod speciālos numurus, piemēram, XXX, kurus var mainīt no vienas mašīnas uz citu). Mašīnu sīkāk raksturo tās Krāsa, Marka, Modelis, Izlaiduma gads un vēl daudz citi atribūti.
Datu modelis
Parasti kaut kā tā ir iegājies, ka tiklīdz kāds ierunājas par datu modeli, tā iedomājas speciālu rīku, ar ko tas veidots, šī rīka atrašanu, instalāciju, tā apgūšanu. Protams, ka lielākiem projektiem bez tā neiztikt, bet visvienkāršākajā gadījumā Jums ir nepieciešams tikai zīmulis un papīrs. Nekādu rīku, nekādu dzelžu un datora. Lūk reāls piemērs:
Datu modeļa piemērs
Protams, ka šim datu modelim ir daudz trūkumu un tas ir nepilnīgs (trūkst relāciju vārdi, identificējošie atribūti, atribūtu obligātums utt), taču kā sākotnējais uzmetums tas varētu derēt, lai saprastu objektus par ko vispār konkrētajā gadījumā būs runa.
Tā kā mana pirmā iepazīšanās ar datu modelēšanu notika izmantojot ER modelēšanu un tai atbilstošo notāciju, tā vēl joprojām man patīk vislabāk. Kādā no nākošajiem rakstiem pastāstīšu sīkāk par šīs notācijas smalkumiem, taču tai pašā laikā patiesībā ir vienalga vai Jūs izmantojat šo, vai UML objektu klašu modeli, vai kaut ko citu.
Identificējot funkcionālās prasības, tas ir, kādas darbības vispār konkrētais produkts veiks, pie reizes jādomā arī par to, kur attiecīgi informācija tiks glabāta un no kurienes ņemta. Savukārt, ja Jums ir datu modeļa entītijas, kas nekur netiek aizpildītas, vai kuru saturu nekur nerāda, tad tas izskatās aizdomīgi un Jums ir jābūt speciālam iemeslam, kāpēc tā notiek.
Svarīgas lietas, ko atcerēties par datu modelēšanu
- Līdz šim es esmu šai rakstā visus datu modeļus sapratis tikai kā konceptuālos datu modeļus. Tiem nav nekādas saistības ar kādu konkrētu DBVS. Modeli, ko Jūs redzat augstāk, tikpat labi var implementēt MySQLā, kā Oraclē vai jebkādā citā datu bāzes vadības sistēmā. Veidojot konceptuālo datu modeli, ir jāabstrahējas no jebkādas konkrētas DBVS.
- Veidojot konceptuālo datu modeli Jūs neko nezinat par tabulām, kolonām, primārām un ārējām atslēgām un tamlīdzīgām lietām. Jūs runājat par entītijām, atribūtiem un relācijām (vai klasēm, atribūtiem un asociācijām UMLā). Tās nebūt ne vienmēr 1:1 pāriet tabulās, kolonās un ārējās atslēgās.
- Konceptuālais datu modelis atspoguļo konkrētās jomas, konkrētā biznesa valodu un jēdzienus. Tajā nav nekāda programmētāju žargona un tikai viņam vien saprotamu lietu. Ar nelielu izglītošanos šo modeli var saprast jebkurš kaut cik saprātīgs Jūsu klients un lasot to viņš redzēs sev saprotamus jēdzienus un lietas.
- Konceptuālajā datu modelī neformāli sakot jūs centieties entītijas un atribūtus padarīt pēc iespējas un nepieciešamības atomārākus un izslēdzat visas datu dublicēšanās. Formāli runājot Jūs veicat normalizāciju līdz kādai no normālformām. Tikai pēc tam veidojot tabulas un kolonas Jūs veiksiet denormalizāciju, kur tas nepieciešams ātrdarbības nolūkiem. Tādējādi ir iegūta kontrolēta un zināma datu dublicēšanās nevis nekontrolēta un neskaidra.
- Katra kļūda konceptuālajā datu modelī ar daudzkārt lielāku spēku nāks atpakaļ nākošajās fāzēs – tad, kad Jūs veidosiet loģisko datu modeli (tabulas, kolonas, ierobežojumus) un vēl jo vairāk vēlāk, kad nāksies veikt dīvainus un/vai ļoti daudz pieprasījumus datubāzei, lai paveiktu kādu vienkāršu lietu, nāksies veikt kaut kādas datu pārkonvertēšanas no vienas sistēmas uz otru utt. No otras puses labā ziņa ir tāda, ka katra veiksmīgā konstrukcija Jums nākotnē prasīs mazāk darba 🙂
Šis bija ļoti īss ieskats datu modelēšanā. Ņemot vērā to, ka par šo tematu ir uzrakstītas grāmatu grāmatas (kur noteikti pa vidu derīgām lietām mēdz būt arī ūdens lappušu aizpildīšanai), Jūs nevarat cerēt apgūt šo lietu pāris stundās, ja nekad iepriekš neesat ar to nodarbojies, bet tas, protams, nekādi nekavē sākt un mēģināt. Mēģināšu turpināt arī šo tēmu nākotnē un paskaidrot sīkāk lietas, kas šeit tika pieminētas tikai garām ejot vai netika pieminētas vispār.
Tālākā lasāmviela un saistītie raksti
- Data modeling wikipēdijā;
- Datu bāze vai datu izgāztuve 1 daļa.
Datubāzes 
Ieteikums, varbūt uzraksti rakstu par piemērotāko db, lielām sistēmām. Maksas vs bezmaksas.
Skat.: http://pods.lv/2008/11/06/ekase_-_valsts_budzeta_elektronisko_norekinu_sistema/
Mhmm šim ieteikumam gan es tomēr nesekošu. Ja gribi zināt manu viedokli, tad tas ir tāds, ka:
1) nevar vispār jebkādā veidā unificēt visus maksas produktus un visus bezmaksas produktus, jo tas ir pārāk liels vispārinājums. Apmēram tā kā runāt par nēģeriem un baltajiem gudrības kontekstā. Tas rezultēsies tikai fleimā.
2) nevar vispārināt arī lielas sistēmas. Pirmkārt lielas – kas tas ir? Katram tas ir kaut kas savs. Nesen viena forumā viens džeks runāja par to, ka viņam jāveido sistēma ar daudz datiem – jāievada visas skolas stundu saraksts. Citi, savukārt, arī sistēmas ar ntajiem Giga un varbūt pat dažiem Tera datiem nebūt neuzskata par lielām. Tālāk jautājums, protams, ko katra konkrētā sistēma dara – vai tā ir ļoti transakcionāla, vai vairāk tikai lasāma utt.
3) attiecīgi no 1) un 2) seko, ka tādu vispārīgu salīdzinājumu izdarīt vienkārši nevar kā šķiru.
Un es esmu diezgan pārliecināts, ka lielāko daļu lietu var izdarīt uz daudzāms DBVS, tikai jāatceras, ka tās ir atšķirīgas un jāizmanto atbilstoši tam kā tās domātas 🙂
T.i. nevajag ar Oracle līdzekļiem un zināšanām bez domāšanas ķerties pie SQL server vai MySQL un otrādi.
ER diagramu zīmēšana ir mans mīļākais process darbā ar datubāzēm. 🙂
Tikai man nepatīk tās zīmēt ar roku uz papīra – pamēģini tagad savai Grāmatas entītijai pievienot vēl vienu atribūtu… 🙂 Tas tā, nedaudz ne pa tēmu.
Andrisp – tas jau kā reiz ir pa tēmu 🙂 Nu protams, ka uz papīra nav tas ērtākais, kā to darīt un noteikti, ka jebkurā lielākā projektā un/vai datubāzes izveidē ar to vien nepietiks, bet doma bija tāda, ka priekš kaut kā pavisam maza nekādus mega rīkus nevajag…
Nujā, protams. 🙂
Btw, mysql’istiem iesaku bezmaksas http://dev.mysql.com/workbench/ (kādreiz fabforce dbdesigner). Pēc tabuliņu sazīmēšanas, ērti varēs arī SQL CREATE skriptus saģenerēt.
Btw #2, šeit viens džeks brīvajā laikā nodarbojas ar ER diagrammu zīmēšanu un publiskošanu internetā: http://www.databaseanswers.org/data_models/index.htm
Var noderēt, ja vajag kādas idejas. Bet tāpat paskatīties arī interesanti, jo tur dažas tādas tīri jancīgas. :]
Jā pēdējā saite bija manā potenciālajā saišu noliktavā 🙂 , tikai tā bija domāta nākotnei, jo tur ir loģiskie datu modeļi (tabulas, kolonas, FK) nevis konceptuālie. Bet, protams, visādi citādi idejas tur noteikti var smelties, tas fakts.
Bet kā nomodelēt multipotenciālu nākotni?
Apskatītais modelis, nosaukšu to par modeli-1, ir mirkļa fotouzņēmums (datubāze attēlo, kas ir).
Nav grūti stādīties priekšā modeli-2, kas attēlo gan to, kas bija, gan ir tagad un ir plānots nākotnē, pēdējai paredzot tikai vienu attīstības scenāriju, piemēram – vispirms tiks uzbūvēts objekts A, bet pēc tam objekts B un relācijas starp abiem.
Bet pamēģiniet radīt modeli-3, kas bez iepriekšminētā paredzētu arī iespēju vispirms uzbūvēt objektu B un tikai tad A, nepārstrādājot A, B un to savstarpējo relāciju projektus!
Redzētie gatavie komercprodukti aizvelk līdz modelim-2. Tad, ja dzīve ko maina (bet tas mēdz notikt ~pusē gadījumu), ir jāpārtaisa projektu saturs.
Es jau kādu laiku šaurā nozarē cenšos radīt un uzlabot modeli-3. It kā sekmīgi, bet bez pārliecības, ka daru to optimāli un ka neizgudroju divriteni. Lielākās grūtības ir sadurvietās ar ne-datu, 1 un 2 tipa modeļu sistēmām. Arī ātrdarbībā, piemēram, cik ātri iegūstams snapšots par konkrētu pagātnes momentu vai tagadni. Pagaidām glābj tas, ka datu apjoms nav pārāk liels un sistēmas lietotāju skaits un prasīgums nepieaug strauji.
Ja godīgi es īsti neiebraucu. Teiksim tā – paskaidrojums ir pārāk vispārīgs un abstrakts. OK es saprotu ir objekts A, objekts B. Tikai nesaprotu kāda veida tad ir relācijas ir starp tiem? Kas tās tādas ir, kaut kas konkrētāks prasās. Vienīgā relācija ko starp tāda veida objektiem pašlaik saskatu – ir, ka ir potenciāli kaut kāda atkarība, ka B (tualetes poda skrūvēšana) nāk pēc A (tualetes grīdas ielikšanas). Bet šajā konkrētā gadījumā izskatās, ka tie ir savstarpēji neatkarīgi (patiesībā runa bija par tualetes poda izgatavošanu un grīdas ielikšanu, ko var darīt pilnīgi neatkarīgi) un patiesībā ir vienalga ar kuru sākt.
Jebšu doma bija pavisam citāda?
Pieņemsim, ka relācijas ir divas caurules starp podu A un podu B.
To instalēšana ir pietiekami ātra un vienkārša, lai tam netaisītu atsevišķu projektu (kas vienalga būs atkarīgs no A un B kārtības), bet to nav pieļaujams aizmirst izdarīt. Cauruli uzstādīt pirms podiem vai piekārt tikai vienā galā nav iespējams.
Māris, vari kaut kā praktiskāk apskaidrot ? Es arī nesaprotu.