Par objektu (ne)nosaukumiem

janvāris 31, 2009

Nesen boot forumā bija kārtējais jautājums – vai var izveidot tabulu kolonu nosaukumus izmantojot ciparus. Vismaz man zināmajās var gan, tikai problēma ir mazliet cita – tā rezultātā mēs veidojam objektu nosaukumus, ar kuriem var ļoti viegli kļūdīties. Padomājiet paši – ja kolonas nosaukums ir skaitlis, cik grūti ir vienai kolonai pieskaitīt nevis otru kolonu, kuras nosaukums ir “2”, bet vienkārši skaitli 2? Otra lieta – vienmēr jāatceras, ka kolonas nosaukums jāliek pēdiņās (Oracle) vai apostrofos (MySQL), vai iespējams vēl kādos citos specsimbolos, savukārt, ja ir ielikts, tad atkal lasot kodu ir ļoti viegli palaist garām to, ka tā ir kolona, nevis vienkārši skaitlis 2.

Nu lūk domājot par šīm jaukajām iespējām, ka SQLā izmantot dažādas iespējas kā sabojāt gan savu, gan nākošo koda uzturētāju dzīvi, nāk prātā dažas iespējas, ar kurām gribējās padalīties publiski. Piemēri Oraclē, bet līdzīgas tehnikas noteikti var izmantot arī citur.

Mēs varam izveidot tabulas ar identiskiem nosaukumiem, tikai vienu lielajiem, vienu mazajiem burtiem:

SQL> create table A (lielais number);
Table created.
SQL> create table "a" (mazais number);
Table created.

Pētam kāda tad nu izskatā tabula A un tabula a:

SQL> desc A
 Name                                      Null?    Type
 ----------------------------------------- -------- -------
 LIELAIS                                            NUMBER
SQL> desc a
 Name                                      Null?    Type
 ----------------------------------------- -------- -------
 LIELAIS                                            NUMBER

Hmmm, kaut kā dīvaini, vai ne? Tas tāpēc, ka Oracle noklusēti visus nenopēdiņotus objektu identifikatorus pārveido uz lielajiem burtiem. Lai tiktu pie tabulas a, mums nosaukums jāraksta pēdiņās:

SQL> desc "a"
 Name                                      Null?    Type
 ----------------------------------------- -------- -------
 MAZAIS                                             NUMBER

Bet tas ir tikai priekš pirmziemniekiem. Krutāki džeki varētu spert soli tālāk un izveidot piemēram tabulas nosaukumu, kā tukšuma simbolu (space). Tad meklējot tabulu nosaukumus shēmā, cilvēkus ar vājākiem nerviem var viegli novest pie pārliecības, ka nupat ir iegūta nopietna Oracles kļūda – 3 ieraksti atlasīti, bet rāda tikai divus :O

SQL> create table " " (A number, "a" number);
Table created.
SQL> select table_name from user_tables;
TABLE_NAME
------------------------------
a

A
3 rows selected.

Bet nekas, arī tas vēl nav viss. Vai tad mums būtu jāapmierinās tikai ar simboliem, kas iegūstami uz klaviatūras? Noteikti nē! Atceramies (vai uzzinam kā nu kurš) par jauko iespēju lietot ALT taustiņu kopā ar cipartastatūras (numeric keypad) taustiņiem. Lūk izmantojam ALT+223 un iegūstam brīnišķīgu kolonas nosaukumu:

SQL> create table abnormal ("▀" number);
Table created.
SQL> desc abnormal
 Name                                      Null?    Type
 ----------------------------------------- -------- -------
 ▀                                                  NUMBER

Tiec nu tagad manai kolonai klāt! 😉

Varam, protams, paeksperimentēt ar iebūvētajām funkcijām, arī tas dod iespēju izveidot kolonu, pie kuras nemaz tik viegli nevar tikt klāt. Tātad neieliekot kolonas nosaukumu pēdiņās, to nemaz neredz.

SQL> create table personas (vards varchar2(10), "SYSDATE" date);
Table created.
SQL> insert into personas values ('Jānis', sysdate-1);
1 row created.
SQL> select vards, sysdate from personas;
VARDS      SYSDATE
---------- ---------
Jānis      31-JAN-09
1 row selected.
SQL> select vards, "SYSDATE" from personas;
VARDS      SYSDATE
---------- ---------
Jānis      30-JAN-09

Nu lūk  nepavisam nav nepieciešams apmierināties tikai ar cipariem un skaitļiem, novest ļaudis totālā nesapratnē var arī daudz elegantāk un efektīvāk 🙂

Advertisements

Datu modelēšana – ievads

novembris 7, 2008

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?

Lasīt pārējo šī ieraksta daļu »


Datu bāze vai datu izgāztuve? III

Oktobris 31, 2007

Šī ir trešā un pagaidām pēdējā daļa rakstam, kurš tika iesākts šeit. Šai daļā ir apkopoti tie “ieguvumi”, ko jūs varat gaidīt no savas datu izgāztuves.

Datu izgāztuves sekas

Zemāk uzskaitītās potenciālās sekas protams nav pilnīgs uzskaitījums, tās ir spēkā tad, ja ir sliktākais scenārijs atbilstoši iepriekš uzskaitītajām datu izgāztuves pazīmēm. Tāpēc es ceru, ka ir maz tādas datubāzes pasaulē un Latvijā, kas atbilst pilnīgi visām šīm pazīmēm, vai sliktākajā gadījumā jums vismaz ar tādām nav jādarbojas 🙂 Pat ja jums tomēr nav īpaši paveicies un nākas ar kaut ko tādu darboties, jācer, ka jums izdosies kaut kā izkļūt no situācijas, piemēram, atrodot kādu, kas jau ir izpētījis šo datu bāzi, varbūt datubāze ir tik maza, ka to spēj izanalizēt jebkurš saprātīgā laikā, varbūt jūs varat pierunāt klientu sākt jaunu skaistu dzīvi bez vecajiem nevienam nesaprotamajiem datiem.

1. Attīstība un izmaiņas ir gandrīz neiespējamas

Jo vairāk jūsu datu bāze patiesībā ir datu izgāztuve, jo vairāk katra izmaiņa jums izmaksās.

Jūs esat nolemti būt kopā ar savu datu izgāztuvi un nekas cits neatliek kā lūgt Dievu, lai kāds neatrastu kādu kļūdu.

2. Migrācija (Datu konversija) ir gandrīz neiespējama

Pieņemsim, ka jūs esat sapratis, kādā ķezā esat iekūlies un nolēmis sākt jaunu skaistu dzīvi, tiesa gan no vecās sistēmas izgūstot ārā vecos datus. Sliktās ziņas ir tādas, ka īstas datu izgāztuves gadījumā tas var būt ļoti sarežģīti un robežoties ar manuālu darbu.

  • Ar 1. Dokumentācijas neesamība un 2. Vienīgā zinošā persona nesen mainīja darbu jūs nezināt KO migrēt. Jūs nezināt, kurās tabulās un kolonās glabājas kādi dati, nav skaidrs kuri no tiem ir jāņem vērā, bet kurus var ignorēt, piemēram, tāpēc, ka kolona tabulā ir palikusi, bet to reāli neviens vairs neizmanto. Patiesību sakot jums nav skaidrs, ko vispār šis tabulu un kolonu jūklis nozīmē.
  • Ar 5. Visa loģika aplikācijā / datubāzē ir tikai tabulas un 7.1. Datu integritātes ierobežojumu trūkums jums ir ieraksti bez nepieciešamās informācijas (jo nav NOT NULL ierobežojumu), jums ir bāreņu ieraksti, jums vairākās vietās glabājas viena un tā pati informācija, kas ir pretrunīga utt.
  • Ar 7.3. Klasifikatoru trūkums un 7.4. Nekorektu datu tipu lietošana katrs lietotājs ir ievadījis datus kā viņam labpatika, tā vietā lai veiktu tiešu klasifikatoru pārkodēšanu jums ir jākasa ārā informācijas druskas no teksta laukiem. Tā vietā lai vienkārši iegūtu datumu, jums ir jāveic konvertācija no 5 dažādiem laika formātiem vienā un tai paša laukā, piedevām izdomājot ko darīt, ja tāds datums vienkārši neeksistē. Pats sliktākais scenārijs šai gadījumā ir tāds, ka jūs esat spiesti nolīgt kādu bariņu ar studentiem/melnstrādniekiem, kas manuāli iziet cauri visiem ierakstiem un tos salabo.
  • Ar 7.2. Šifrēti un neinformatīvi tabulu nosaukumi migrācijas koda rakstīšanas uzdevums kļūst par murgu un katru vakaru jums sāpēs galva 🙂

Parasti tā visa rezultātā ar milzīgām pūlēm jums ir izdevies vismaz daļēji pārnest datus, bet visi lietotāji sūdzas, ka iepriekšējā sistēma bija labāka, jo tajā bija visi dati un tā pieļāva daudz lielāku rīcības brīvību (varēja dažus laukus ievadīt, dažus ne, varēja pierakstīt visu teksta laukā savā iemīļotajā formātā, tagad jāizvēlas kaut kādas predefinētas vērtības, lai papildinātu klasifikatorus, jāiet uz citām formām utt.).

3. Teorija, ka aplikācija ir galvenā vērtība nevis dati

Iespējams, ka datu izgāztuves biežākais cēlonis ir doma, ka galvenais ir aplikācija nevis paši dati. Šī diskusija laika gaitā uzpeld atkal un atkal. Es gan esmu redzējis tikai to, ka aplikācijas nāk un iet bet vēlme pēc vēsturiskajiem datiem paliek. Piemērs par man zināmāko Oracle datu bāzi. Es neredzu īpašu iemeslu kāpēc šodien nevarētu lietot to pašu datu modeli, kas tika saprātīgi projektēts deviņdesmito gadu sākumā versijā 7.X. Tai pašā laikā pa šo laiku ir mainījušās vairākas modes kā tad ir stilīgi un vajadzētu programmēt aplikācijas, piemēram,

  • tekstuālas formas, kas tika izpildītas uz servera;
  • klienta servera formas;
  • 3 līmeņu arhitektūra, ar aplikāciju serveri neskaitāmās valodās, piemēram, java, php, .NET, kur katram ir savs adeptu bariņš.

Lielākajā daļā esošo projektu esmu redzējis vēlmes ielādēt sākotnējos datus no teksta failiem, dažādām vēsturiskām un ne tik vēsturiskām datu bāzu pārvaldību sistēmu datu bāzēm vai tās pašas DBPS iepriekšējā datu modeļa versijas. Visi šie dati tika ievadīti izmantojot kādu aplikāciju. Kur tās ir tagad? Izmestas vēstures mēslainē, neviens par tām neatceras, ja neskaita iespējams kāda izstrādātāja nostaļģiskas atmiņas. Bet to ievadītie dati bieži ir interesanti vēl joprojām. Diemžēl ja jums ir datu izgāztuves cienīga datu bāze, tad ir spēkā šī teorija, ka galvenā vērtība ir aplikācija, jo datus bez aplikācijas neviens nespēj saprast un apstrādāt.

Kopsavilkums

Datu izgāztuves simptomu neesamība negarantē, ka jūsu datubāzei nebūs problēmu. Bet pieļaujot šīs kļūdas jums būs problēmas, ko nav iespējams atrisināt (izņemot 7.5. Haotiski indeksi) ar skaņošanu, kešošanu, rakstot optimālākus SQL vaicājumus, lietojot bind (bind) mainīgos, iegādājoties „niknāku” dzelzi vai ko citu. Tās ir loģiskās kļūdas, kas bieži vien nozīmē datubāzes projektēšanu no sākuma un iespējams arī jūsu aplikācijas pārrakstīšanu no nulles. Ja jūs noteikti esat pārliecināts, ka kādu no šiem simptomiem jūs apzināti gribat pieļaut, tad pārdomājiet to vismaz divreiz un vismaz sev noformulējiet gan plusus, gan mīnusus jūsu izvēlētajai pieejai. Tas vismaz ļaus jums ielūkoties dziļāk iespējamās problēmās un iegūt jaunas lēmumu pieņemšanas prasmes 🙂

Turpmākā lasāmviela:

1. http://en.wikipedia.org/wiki/Anti-pattern – Anti-pattern, no Vikipēdijas, brīvās enciklopēdijas;

2. http://www.web-hits.org/txt/codingunmaintainable.html – Kā rakstīt neuzturamu kodu;

3. http://asktom.oracle.com/pls/asktom/f?p=100:8:3045776155360546::NO – Oracle Open World 2006 programmētāju un DBA slikto paradumu prezentācija, lielākā daļa no tām attiecas uz jebkuru datubāzi.

Raksta pirmā daļa, otrā daļa.


Datu bāze vai datu izgāztuve? II

Oktobris 30, 2007

Šī ir otrā daļa rakstam, kurš tika iesākts šeit. Būs vēl arī trešā pēdējā daļa, kurā tiks paskaidrots, kādas potenciālas problēmas jūs nakotnē gaida, ja jūs veidojat nevis datu bāzi, bet datu izgāztuvi.

4. Nosaukumu vadlīniju trūkums

Parasti šī problēma iet roku rokā ar Sākotnējā projektējuma trūkums (3). Haotiski nosaukumi gan datubāzes objektiem, gan programmatūrā ir viens no labākajiem veidiem, kā rakstīt neuzturamu kodu. Tas rada pilnīgi nesapratni, par katru objektu ir jāpārliecinās, ko tas patiesi nozīmē, nav iespējams izmantot analoģiju, balstoties uz esošajām zināšanām. Nav tik būtiski kādas tieši vadlīnijas tiek izmantotas, kā tieši nosaukumu tiek veidoti, bet ļoti būtiski ir, lai jūsu projektā nosaukumu veidošanas vadlīnijas tiktu pieņemtas un pēc tam tās tiktu ievērotas.

Turpmākā lasāmviela:

1. http://www.gplivna.eu/papers/naming_conventions.htm – Nosaukumu veidošanas vadlīnijas Oracle tabulām, kolonām, indeksiem, ierobežojumiem u.c.

5. Visa loģika aplikācijā / datubāzē ir tikai tabulas

Visa jūsu aplikācijas biznesa loģika ir ārpus Oracle datubāzes? Jā? Tad kāda iemesla dēļ jūs iztērējāt tik daudz naudas par Oracle licencēm? Jūs noteikti būtu iztikuši ar MySQL. Kāpēc? Vienkārši tāpēc, ka Oracle piedāvātā funkcionalitāte salīdzinot ar MySQL ir daudz lielāka, un tas neapšaubāmi atstāj iespaidu arī uz ātrdarbību. Tas būtu apmēram tas pats, kā īrēt milzīgu māju, ar daudzām istabām un dažādu aprīkojumu, bet spītīgi izmantot tikai dzīvojamo istabu. Jūs nelietojat piemēram tualeti. Galu galā kāpēc lai lietotu, var taču iziet ārā dārzā un paveikt nepieciešamās lietas tur 🙂 Jūs nelietojat virtuvi, jo var taču tāpat ārā uz ugunskura. Un te nu lūk ir jautājums – vai tiešām jūs šādi rīkotos arī ar savu īrēto māju, par kuru esat samaksājis krietnu naudu, bet tās piedāvātās iespējas izmantojat tikai par dažiem procentiem? Tieši tāda pati situācija ir ar datubāzēm, jo sevišķi datubāzēm, kas nodrošina plašu funkcionalitāti. Jūs esat samaksājis tik daudz naudas un pēc tam labprātīgi sevi aplaupat.

Ja jūs meklējat brīnumu, ko sauc par datubāzes neatkarību, tad visticamāk jūs esat sasnieguši situāciju, kad jūsu aplikācija optimāli nestrādā ne uz vienas no izmantotajām datubāzēm Visa iebūvētā funkcionalitāte ir cik vien iespējams tuvu datiem un tas ir primārais iemesls, kāpēc tā parasti veic attiecīgās lietas labāk, nekā tās pašas iespējas ārpus datubāzes. Pēc iepriekšējās analoģijas tas būtu kā dzīvot dažādas arhitektūras mājās, bet izmantot vienalga tikai dzīvojamo istabu. Esmu pārliecināts, ka jūs nebūtu apmierināts ar šādu dzīves kvalitāti.

Turpmākā lasāmviela:

1. http://www.rittmanmead.com/2004/11/24/the-cost-of-database-independence/ – The Cost of Database Independence by Mark Rittman.

6. Daudzas personas jau ir pielikušas savu pirkstu datu izgāztuves veidošanā

Kopā ar Sākotnējā projektējuma trūkumu (3) un Nosaukumu vadlīniju trūkumu (4) visi projekta dalībnieki, kas papildina jūsu datubāzi, ir kā bars cilvēku, kas izgrezno jūsu māju gan no iekšpuses, gan ārpuses bez jebkādas kopējas idejas un katrs pēc sava prāta un talanta spējām. Ja jūs esat veiksminieks, var gadīties, ka rezultāts jūs apmierina, bet vairumā gadījumu, tas būs kaut kas tāds, kas iedzīs šausmās pat vislielāko flegmatiķi. Tieši tāda pati situācija ir ar datubāzēm. Ir daudzas konvencijas, standarti un vadlīnijas, ko ievērot un, ja vairāk kā viena tiek lietota jūsu datubāzē, tad katra nākošā palielina kopējo neskaidrības un nesapratnes līmeni. Tas visacīmredzamāk kļūst tad, kad jums nākas vienlaicīgi modificēt divus objektus, kas izstrādāti vadoties pēc dažādām vadlīnijām – ko tagad darīt, turpināt, tādā pašā jau iesāktajā garā un palielināt kopējo dažādību vai izvēlēties vienu no esošajām, tādējādi iegūstot moduli, kam puse izskatās vienādi, bet otra puse otrādi? Varbūt vēl kādu citu variantu?

7. Datubāzu objektu fiziskie atribūti

7.1. Datu integritātes ierobežojumu trūkums

Šī parasti ir visradikālākā Visa loģika aplikācijā / datubāzē ir tikai tabulas (5) forma vai arī vienkārši rezultāts absolūtai nekompetencei. Ja jums datubāzē nav datu integritātes ierobežojumu, tad tas ir tikai laika jautājums, kad jums būs bāreņu (orphan) ieraksti, dublicētas vērtības un nevēlamas vērtības. Agrāk vai vēlāk kāds pamainīs datus apejot jūsu aplikāciju, agrāk vai vēlāk kāds pat negribot atradīs kļūdu jūsu aplikācijā un jūsu dati tiks sabojāti.

Mēģinājumi aplikācijas līdzekļiem ierobežot, piemēram, unikālas vērtības kādā kolonā  apriori ir gandrīz vienmēr lemti neveiksmei (vai arī risinājumi būs nepilnīgi), it sevišķi, ja jūsu aplikāciju vienlaicīgi lietos vairāk kā viens lietotājs 😉

Turpmākā lasāmviela:

1. http://en.wikipedia.org/wiki/Referential_integrity – Datu integritāte, no Vikipēdijas, brīvās enciklopēdijas;

2. Oracle® Database Application Developer’s Guide – Fundamentals, 6 Maintaining Data Integrity in Application Development;

3. http://tkyte.blogspot.com/2006/06/what-did-i-decide-on.html – The Tom Kyte Blog, some worst practises.

7.2. Šifrēti un neinformatīvi tabulu nosaukumi

Tabulas ar nosaukumiem tab1, tab2 un/vai kolonas ar nosaukumiem kol1, kol2 var pārvērst jebkura cilvēka dzīvi ellē. Tad jau labāk tabulu nosaukumi kādā matabelelendas valodā, vismaz ir iemesls uzzināt ko daži vārdi šai valodā nozīmē. Strādājot ar iepriekš neiepazītu datubāzi ir grūti atcerēties loģiskus nosaukumus, nemaz nerunājot par kol1 vai tab2. Katra tāda lietošanas reize nozīmē ieskatīšanos dokumentācijā vai cita veida pierakstos.

7.3. Klasifikatoru trūkums

Cilvēks spēj izlasīt un saprast informāciju, kas ir pasniegta daudzos un dažādos veidos. Cliēvks sēpj izloībt jgēu arī no dizeagn kļūidanas ifnomrācjias. Ar datu bāzēm un precīziem algoritmiem ir daudz sliktāk. Tiklīdz kā jums nāksies uzrakstīt kādu atskaiti par lietām, kas it kā datu bāzē glabājas, bet ir, piemēram, teksta laukā, tā momentāli radīsies lielas un pamatīgas problēmas. Pieņemsim, ka jūs vēlaties nopirkt auto ar elektriski paceļamiem logiem un meklējat tādus kādā no mūsu sludinājumu serveriem. Kā cilvēks es saprotu, ka el. logu pacēlāji, el. logu pac., Elektriski regulējami logi, el. Logi ir viens un tas pats, bet atskaiti ģenerēt uz šādiem tekstiem būtu krietni vien grūtāk. Patiesības labad jāsaka, ka visos lielākajos sludinājumu serveros ir iespēja atķeksēt pārdodamajam auto šo „ekstru” un iegūt vienu kopīgu tekstu visos sludinājumos, tiesa gan tas nekavē dažus censoņus tekstā ievadīt savus variantus. Protams arī klasificētas vērtības vien nenodrošinās korektu datu ievadi, piemēram, vienā no sludinājumu serveriem Opel Zafira bija klasificēta kā mikroautobuss, universāls un hečbeks, tai pašā laikā parasti tā visur tiek saukta kā minivens, bet šāda iespēja izvēlēties netika piedāvāta 🙂

Otra iespēja ir vienā laukā glabāt saliktus datus, piemēram, vārds un uzvārds. Agrāk vai vēlāk būs tādas iespējas, kā Jānis Bērziņš, Bērziņš Jānis, J. Bērziņš, Bērziņš J. un iespējams arī kādi citi varianti. Protams, ja jūsu biznesa vajadzības nekad neprasīs šos laukus sadalīt un atpazīt, tad viss ir kārtībā, citādi radīsies problēmas.

7.4. Nekorektu datu tipu lietošana

Visbiežāk novērotā grēkošana ir VARCHAR tipa lietošana NUMBER un DATE vietā. Tā rezultātā ir iegūts liels kļūdu potenciāls. Skaitļu vietā simboli, korektu datumu vietā 30. februāri ir tikai sākums. Turpinājumā kārtošana nez kāpēc notiks samērā dīvaini – vispirms ‘1’, ‘10’ un tad tikai ‘2’, nemaz nerunājot par to, kā kārtos datumus. Dažāda veida netiešo (implicit) konversiju sekas būs neoptimāli vaicājumu izpildes plāni. Lai no tā visa izvairītos ir jāizdara relatīvi vienkārša lieta – jāizvēlas atbilstošs datu tips katrai kolonai.

7.5. Haotiski indeksi

Šis ir vairāk fiziskais nekā loģiskais datu bāzes aspekts. Ja datubāzei ir vairāk vai mazāk tikai tie indeksi, kas tai reāli nepieciešami, tad ir vieglāk atrast kopējas datu pieejas shēmas. Ja datu bāzei indeksi ir veidoti haotiski un kā pagadās, tad pirmkārt tiek nevajadzīgi uzturēti lieki indeksi, kas palēnina DML (izņemot SELECT) teikumus, otrkārt – nav nekādas skaidrības kā tad aplikācija un/vai citas saskarnes iegūst datus.

Raksta pirmā daļa, trešā daļa.


Datu bāze vai datu izgāztuve?

Oktobris 24, 2007

Šī raksta oriģināls ir angliski un atrodams šeit. Tā kā tas ir manis paša rakstīts, tad ar autortiesībām viss ir kārtībāJ

Katrs no mums ir vairāk vai mazāk pazīstams ar datu bāzēm. Sākot ar vecu lapiņu jūkli ar telefonu numuriem un draugu dzimšanas dienām, un beidzot ar relāciju datu bāzu vadības sistēmām, kuras satur miljoniem ierakstu un terabaitiem datu.

Lielākā daļa cilvēku domā, ka nezin, kas ir datu izgāztuves. Bet patiesībā tā nemaz nav!

Kas tad ir datu izgāztuve?

Īsumā tā ir datu bāze, kurā nav definētu noteiktu algoritmu, kā iegūt korektus datus un dati ir pretrunīgi. Ja tā ir jūsu papīru kaudzīte vai tas ir jūsu dators, kas satur jums vien saprotamā haosā esošas datnes, tad tā ir tikai un vienīgi jūsu problēma. Bet, ja tā ir datu bāze, ko lieto desmitiem un simtiem lietotāju, kas nodrošina ar informāciju veselas organizācijas un pat valstis, tad, protams, situācija ir daudz sliktāka.

Kā jau tas parasts – apzināšanās, ka esat bedrē, ir jau pirmais solis ārā no bedres 🙂

Tāpēc sākumā parunāsim, kādi ir datu izgāztuves simptomi, bet tālāk kādas tam ir potenciāli sliktas sekas.

Kā no tā tikt vaļā – lūk tas jau ir krietni sarežģītāks jautājums. Diemžēl, kā jau parasti nesalīdzināmi daudz vieglāk ir ķezā neiekulties, nekā mēģināt no tās tikt ārā.

Datu izgāztuves simptomi

Šeit esmu centies apkopot plašāk izplatītos datu izgāztuvju simptomus. Lielākā daļa no tiem nav tīri jā/nē tipa jautājumi un atbildes, bet jo vairāk jums šādu simptomu ir pēc skaita un jo spēcīgāk jums tie izpaužas, jo lielāka iespēja, ka agrāk vai vēlāk jums nāksies sastapties ar negatīvām sekām.

Lai gan atsauces lielākoties ir saistītas ar Oracle datu bāzi, šie simptomi ir attiecināmi uz jebkuru datu bāzi, neatkarīgi no tā kādā vidē tā ir izstrādāta, ja vien šī datubāze nodrošina kaut ko vairāk, nekā iespēju glabāt datus tabulās.

1. Dokumentācijas neesamība

Ko es saprotu ar dokumentāciju? Es šeit nedomāju tikai un vienīgi dokumentus MS Word formātā atbilstoši kādam vispārpieņemtam standartam, kaut gan tā ir viena no ļoti reālām iespējām. Patiesībā dokumentācija var būt ļoti dažāda veida:

1) programmatūras projektējuma apraksts atbilstoši LVS standartam;

2) atsevišķs dokuments ko var nosaukt piemēram par datubāzes projektējuma aprakstu;

3) komentāri datubāzē pie katras tabulas un kolonas.

Ir ļoti svarīgi atcerēties, ka galvenais dokumentācijas mērķis nav iegūt visu tabulu un kolonu uzskaitījumu, bet ka galvenais mērķis ir darīt zināmu, kāpēc šāda tabula vai kolona ir izveidota, kādas ir tās iespējamās vērtības, ko katra vērtība nozīmē, kāda ir tabulas/kolonas sūtība.

Ir ļoti viegli noģenerēt kolonu un/vai tabulu sarakstu no datubāzes, ir ļoti viegli izgūt visām tabulām primārās atslēgas, sasvstarpējās relācijas un citus ierobežojumus, izmantojot datu vārdnīcu, bet daudz grūtāk ir saprast ko katrs no šiem objektiem dara un kādam mērķim kalpo. Piemēram, ir diezgan bezjēdzīgi kolonas komentāros rakstīt, ka tā ir ārējā atslēga uz tabulu X, bet nepaskaidrot tās biznesa nozīmi. To, ka šī kolona ir ārējā atslēga, ir ļoti viegli noskaidrot izmantojot datu vārdnīcu vai (kas būtu vēl labāk) pēc nosaukuma, kas atbilst attiecīgām vadlīnijām. Tai pašā laikā ne vienmēr ir acīmredzami, kāda ir biznesa nozīme šādai ārējai atslēgai.

Turpmākā lasāmviela:

1.New Media (Oracle) Database Design Template(Ļoti laba datubāzes projektējuma apraksta veidne).

2. Vienīgā zinošā persona nesen mainīja darbu

Kopā ar Dokumentācijas neesamība (1) un Visa loģika aplikācijā / datubāzē ir tikai tabulas (5) ir ļoti lielas problēmas, ja sistēmā ir nepieciešamas izmaiņas vai no sistēmas ir jāizgūst dati. Tādā gadījumā vienīgā izeja ir analizēt datu modeli, analizēt datus un aplikācijas kodu (ja ir pieejams pirmkods). Tas prasa laiku. Tas prasa ļoti daudz laiku un resursus. Un nav nekādas garantijas, ka veiktās izmaiņas neizsauks pilnīgi neprognozētas sekas kaut kur citur. Iespējams, ka jūs tikai pēc kāda laika uzzināsiet, ka jūsu veiktās izmaiņas rada kļūdu kādā speciālā gadījumā vai vēl sliktāk – nemanāmi sabojā jūsu datus. Tāpēc rūpējieties un neizturieties pavirši pret jūsu vienīgo zinošo personu, bet tai pašā laikā piespiediet viņu atrisināt Dokumentācijas neesamības problēmu vai vismaz nodot savas zināšanas citiem kolēģiem.

3. Sākotnējā projektējuma trūkums

Jebkas, kas nav triviāls vai neskaitāmas reizes jau paveikts un kļuvis par absolūtu rutīnu prasa sākotnējo projektējumu. Saskaņā ar būvniecības noteikumiem Latvijā nevienu māju nav iespējams uzbūvēt bez projekta. Diemžēl nez kāpēc cilvēkiem liekas, ka Informāciju tehnoloģijās tas nav spēkā un ka ir iespējams ietaupīt laiku un resursus projektējumu neveicot. Patiesībā vismaz ilgtermiņā tas ir daudz dārgāk. Jo tuvāk projekta sākumam tiek pieļauta kļūda, jo dārgāk tā izmaksās. Ja datu modelis ir nekorekts jau pašā sākumā, neviens pasaules ģeniālākais programmētājs nespēs panākt, lai jūsu aplikācija darbojas pieņemamā ātrumā un arī paši “niknākie dzelži” tur būs bezspēcīgi.

Turpmākā lasāmviela:
Loģiskā modelēšana:

1. Data Model Patterns: Conventions of Thought by David C. Hay, ISBN: 0932633293;

2. The Data Model Resource Book, Vol. 1: A Library of Universal Data Models for All Enterprises by Len Silverston, ISBN: 0471380237;

3. Requirements Analysis: From Business Views to Architecture by David C. Hay, ISBN: 0130282286;

4. http://www.phlonx.com/resources/nf3/ – Ieskats datubāzes normalizācijā;

5.http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:6692296628899 – piemērs kā nevajag darīt;

6. Oracle Insights Tales of the Oak Table, Chapter 11 Bad CaRMa by Tim Gorman, ISBN: 1590593871;

7. http://www.learndatamodeling.com/ – īss pārskatas par datu modelēšanu.

8. http://www.tdan.com/edatt1_archive.htm – rakstu arhīvs. Var meklēt piemēram David Hay; viņam ir vairāki vērtīgi raksti šajā vietnē.

9. ievads datu modelēšanā un relāciju modelēšanā.

 Fiziskā modelēšana Oraclei:

1. Expert Oracle Database Architecture: 9i and 10g Programming Techniques and Solutions by Thomas Kyte, ISBN: 1590595300;

2. Effective Oracle by Design (Osborne ORACLE Press Series) by Thomas Kyte, ISBN: 0072230657;

3. Oracle Insights Tales of the Oak Table, Chapter 10 Design Disasters by Jonathan Lewis, ISBN: 1590593871;

4. http://asktom.oracle.com – Thomas Kyte atbildes uz daudziem un dažādiem jautājumiem.

 

Raksta otrā daļa, trešā daļa.