Datu bāze vai datu izgāztuve? III

Šī 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.

• Ar 1. Dokumentācijas neesamība un 2. Vienīgā zinošā persona nesen mainīja darbu jūs nezināt KO mainīt;
• Ar 3. Sākotnējā projektējuma trūkums un 4. Nosaukumu vadlīniju trūkums jūs nezināt KĀ mainīt;
• Ar 5. Visa loģika aplikācijā / datubāzē ir tikai tabulas un 7.1. Datu integritātes ierobežojumu trūkums jūs nevarat būt droši, ka mazākā jūsu izmaiņa neizsauks neprognozējamas izmaiņas pavisam citur un vienkārši nenobeigs jūsu sistēmu.

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

Šī 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?

Šī 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.

Efektīva (vairāk vai mazāk) SQL un PL/SQL vadlīnijas

1. Iespēja kaut ko izdarīt visātrāk ir to nedarīt vispār, tāpēc par katru SQL teikumu būtu jāpārliecinās:

• vai tas vispār ir vajadzīgs, varbūt to var nemaz nepildīt,
• vai to tiešām ir nepieciešams pildīt tik daudz reižu (ciklā), varbūt to var pildīt tikai vienreiz (piemēram iegūt kodu no db, aizpildīt mainīgo ar sistēmas datumu utml),
• varbūt to var pildīt tikai kādos speciālos gadījumos (if, case).

2. Pēc iespējas jādomā kopas operācijās. Jāmēģina izvairīties no procedurālas SQL teikumu sasaistes. Ja problēmu ir iespējams atrisināt tikai ar SQL līdzekļiem, tad vispārējā gadījumā tā arī jādara. Jo sevišķi jāmēģina izvairīties no SQL konstrukcijām, kas ir ievietotas PL/SQL ciklos.

3. Dinamisko SQLu ir atļauts lietot tad un tikai tad, ja ar statisko SQLu uzdevumu nav iespējams izpildīt.

4. Ja tomēr nepieciešams izmantot dinamisko SQLu un jo sevišķi, ja ir paredzams, ka tas notiks bieži, tad ir jāizmanto EXECUTE IMMEDIATE kopā ar USING klauzu, lai tiktu lietoti bind variables.

5. Dinamiski ģenerējot SELECT teikumus ar iepriekš nezināmu skaitu parametru (tipiski izvērstām meklēšanas iespējām) ir jāizmanto konteksta iespējas (CREATE OR REPLACE CONTEXT), lai sistēma netiktu pārpludināta ar tikai vienreizlietojamiem unikāliem SQL teikumiem, kas nelieto BIND VARIABLES.

6. Ir jāmēģina izvairīties no lietotāja definētu funkciju izsaukšanas SQLā, jo sevišķi, ja attiecīgais SQLs tiek izpildīts bieži vai arī lietotāja definētā funkcija tiek izsaukta daudz reižu viena SQL teikuma ietvaros, jo tiek apstradāts liels datu apjoms. Tā vietā lietotāja definētā funkcija jāmēģina iekļaut pamata SQL teikumā.

7. Ja PL/SQL kodā no datubāzes jāiegūst mainīgie, kas pēc tam nemainās un tiek vairākkārt izmantoti, tad tos vēlams inicializēt vai nu pakotnes ķermenī (bet tikai tad, ja vērtība datubāzē NEVAR mainīties starp vairākiem pakotnes izsaukumiem) vai arī procedūras sākumā (ja vērtība datubāzē var mainīties starp vairākiem pakotnes izsaukumiem).

8. UPDATE operācijām pēc iespējas jāveic koriģēšana tikai tām kolonām, kas patiesi ir mainījušās.

9. Visiem SELECT, UPDATE, INSERT INTO..SELECT FROM, MERGE un DELETE, kas nav triviāli (nenotiek uz vienu tabulu pēc primārās atslēgas) vajadzētu noskaidrot potenciālo izpildes plānu lietojot tādus rīkus kā EXPLAIN PLAN vai AUTOTRACE SQL*Plusā vai izmantojot atbilstošu funkcionalitāti PL/SQL Developer vai SQL Navigator vai līdzīgos vizuālajos rīkos.

Vērtējot izpildes plānu jāņem vērā šādi faktori:

• Ja darbība tiks izpildīta ļoti bieži un atgriezīs mazu rezultātu kopumu, tad iesaistītajām operācijām būtu jānotiek pēc indeksa(-iem) un ir jāizvairās no tabulu full scan.
• Ja darbības rezultātam ir nepieciešams pārskanēt visu tabulu, tad ir jāveic full scan pa visu tabulu un jāizvairās no tabulu kombionēšanas (join) izmantojot nested loops uz šo tabulu.
• Izpildes plānam darbu būtu jāsāk no tabulas, kura ir visselektīvākā, t.i., kur attiecība <Paredzamais atgriezto ierakstu skaits>/<Viss tabulas ierakstu skaits> ir vismazākais, lai kopsummā veicot pieprasījumu tiktu parbaudīta iespējami mazākā ierakstu kombinācija datubāzē.

10. Hintu (ne)lietošana. Izpildes plāni pēc iespējas optimāli būtu jāpanāk nelietojot hintus, bet izmantojot datu bāzes statistikas. Tāpēc arī par izpildes plāna pareizību var ar zināmu drošību pārliecināties tikai līdzīga satura un apjoma (testa, produkcijas) datu bāzē, kurai ir veikta atbilstoša statistiku rēķināšana un ir līdzīga konfigurācija.

10.1. Ja tas nav iespējams, tad pēc iespējas jālieto hinti, kas dod optimizatoram (optimizer) papildus informāciju, bet tieši nenosaka plāna izpildes veidu:

• ALL_ROWS – mērķis ir iegūt visu rezultātu ar iespējami mazāko resursu patēriņu;
• FIRST_ROWS (n) – mērķis ir iegūt pirmās (n) rindiņas pēc iespējas ātrāk;
• DYNAMIC_SAMPLING (n) – dinamiski rēķina statistikas, atkarībā no dotā līmeņa n. Informācija par līmeņiem. Vērtīgs, ja statistikas netiek rēķinātas, kā arī priekš pagaidu tabulām (temporal tables).
• DRIVING_SITE (table) – ja vaicājuma izpilde notiek vairākās datubāzēs izmantojot datubāzes linku, tad norāda kurā datubāzē vaicājums tiks izpildīts.
• CARDINALITY (n) – norāda sagaidāmo ierakstu apjomu vaicājumam. Sevišķi noderīgs, ja nepieciešams izmantot tipus.

10.2. Hinti, kurus ieteicams izmantot tikai tad, ja ir 100% pārliecība par savu taisnību un kā pēdējo līdzekli:

• FULL (table) – ja ir pilnīga pārliecība, ka ir nepieciešama visas tabulas pārskanēšana, lai iegūtu rezultātu, tipiski varētu noderēt atskaitēm, pilnīgi nepieņemams tipiskai datu ievadei/attēlošanai.
• LEADING (table) – ja ir pilnīga pārliecība, ka vaicājuma izpilde jāsāk ar konkrētu tabulu un statistiku rēķinašana tabulām un indeksiem nedod vēlamo rezultātu.
• Speciālos gadījumos, ja ir jāveic liela datu pievienošana kādā tabulā, tad var izmantot APPEND – paturot prātā, ka šīs operācijas rezultātā izveidotos datus nav iespējams atjaunot bez pilnas rezerves kopijas, kā arī, ka pēc šis operācijas ir jābeidz transakcija (COMMIT, ROLLBACK), ja vēlas veikt kādas darbības ar izmainīto tabulu.

10.3. Jebkuru citu hintu vajadzētu lietot tad un tikai tad, ja tā lietotājs pilnībā apzinās šī hinta sekas, piemēram, INDEX, INDEX_ASC vai INDEX_FFS – ir pilnīga pārliecība, ka indekss vienmēr būs tāds pats kā sākumā (saturēs tās pašas kolonas), indekss netiks nomests (drop), indekss netiks pārsaukts, šis indekss jebkuros apstākļos būs patiesi īstais un vienīgais, kas derēs vislabāk, lai iegūtu nepieciešamo rezultātu.

10.4. RULE hintu vajadzētu lietot tad un tikai tad, ja cilvēks zin, saprot un spēj izskaidrot visus RBO likumus, kas to nosaka (http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96533/rbo.htm#38864 un http://www.oreilly.de/catalog/orsqltunpr/chapter/).

Turpmākā lasāmviela:

• Oracle Database Performance Tuning Guide 10g Release 2 (10.2)
• Oracle SQL Tuning Guide
• Patērēta laika mērīšana Oraclē
• Autotrace