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.

3 Responses to Datu bāze vai datu izgāztuve?

  1. […] Datubāzu resurss latviski –Šis ir rakstu kopums par relāciju datubāzēm, SQL valodu un dažādām datubāzu iespējām. Ja tev ir idejas, ko šeit vēl ir nepieciešams pievienot, izlasi lapu “Kas šeit ir atrodams?” un kļūsti par vienu no autoriem! « Datu bāze vai datu izgāztuve? […]

  2. […] 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 […]

Komentēt

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Mainīt )

Twitter picture

You are commenting using your Twitter account. Log Out / Mainīt )

Facebook photo

You are commenting using your Facebook account. Log Out / Mainīt )

Google+ photo

You are commenting using your Google+ account. Log Out / Mainīt )

Connecting to %s

%d bloggers like this: