Dbać o jakość danych

Zły projekt bazy może doprowadzić do pogorszenia lub utraty jakości danych - co ma bezpośredni wpływ na sprawność informatyzowanego przedsiębiorstwa.

Zły projekt bazy może doprowadzić do pogorszenia lub utraty jakości danych - co ma bezpośredni wpływ na sprawność informatyzowanego przedsiębiorstwa.

O pomyślności firmy w dużej mierze decydują dane wprowadzane do jej baz danych, weryfikowane, przechowywane i użytkowane. Jeżeli jakość danych jest podejrzana lub wątpliwa - mogą doprowadzić przedsiębiorstwo do upadku wskutek straconych możliwości sprzedaży, błędnie wystawionych faktur, dostawy niewłaściwych części, za wysokiego lub za niskiego poziomu zapasów, nietrafnych decyzji itp. Lista ta jest długa.

Narzędzia do modelowania aplikacji budzą nieuzasadnione przekonanie, że tworzą również model danych, a to nieprawda. Model danych trzeba budować oddzielnie. Jeżeli aplikacja została źle zaprojektowana, to jest prawdopodobne, że projekt się nie uda i wszyscy o tym natychmiast się dowiedzą. Natomiast jeśli źle zaprojektujemy model danych, istnieje duża szansa, iż ten fakt przemknie nie zauważony, powodując pogorszenie jakości lub wręcz uszkodzenie danych.

Projekt bazy ważniejszy od projektu aplikacji

Programista, klient, użytkownik zawsze większą zwracają uwagę na kształt, wygląd, estetykę, elegancję i łatwość używania aplikacji niż na to, co leży u jej podłoża - bazę danych, z którą aplikacja współpracuje. Tymczasem dobry projekt bazy danych jest ważniejszy niż aplikacja. Te powody to:

Baza danych jest długowieczna. Aplikacje służą do rozwiązywania konkretnych problemów i mogą być łatwo zmienione lub zamienione na inne, gdy powstaną inne wymagania lub model działania biznesu. Natomiast dane trudno jest zamienić na inną postać lub cokolwiek dodać do nich po zapamiętaniu w bazie, jeśli okażą się niedostateczne do przewidywanego zastosowania. Trzeba więc przy tworzeniu pierwszej aplikacji jednocześnie zbudować dobry i kompletny model danych, nie sugerując się wymaganiami konkretnej aplikacji ani przewidywanym czasem jej funkcjonowania.

Producenci narzędzi do tworzenia hurtowni danych oferują wiele programów do czyszczenia i przetwarzania danych z bazy przed załadowaniem ich do hurtowni. Lecz nie ma co liczyć na cud - nic nie zawiesi reguły GIGO (Garbage In Garbage Out). Nie da się zapełnić hurtowni dobrymi danymi, jeśli źródła są uszkodzone lub złej jakości. Nie można poprawić jakości danych w bazie za pomocą narzędzi informatycznych.

Jakość danych jest bardzo ważna. Prawie każde przedsiębiorstwo przetrwa nieudany projekt aplikacji. Nie każde natomiast poradzi sobie z błędnymi danymi w swojej bazie danych. Problem jest tym trudniejszy, gdyż nie wystarczy znaleźć błędy w projekcie bazy danych i poprawić je. Trzeba znaleźć i poprawić błędne dane, a to może okazać się niewykonalne. Jak poprawić bazę, w której codziennie przybywa setki tysięcy rekordów?

Bazy danych stale rosną. Projektując bazę danych, rzadko zwracamy uwagę na to, że będzie ona używana znacznie dłużej niż aplikacje, które z niej aktualnie korzystają. Baza ciągle przyrasta i mimo iż znakomicie działała przy pierwszej aplikacji, to po kilku latach okazała się niewydolna, mało skalowalna. Projekt, który był dobry przy małej bazie, okazał się mało przydatny, gdy jej rozmiar wzrósł setki lub tysiące razy.

Dostęp do danych. Rozwój technik analitycznych i eksploracji danych zachęca kierownictwo przedsiębiorstw do używania takich narzędzi w celu prognozowania przyszłych działań przez projekcję danych z przeszłości. W jaki sposób informatyk odpowiedzialny za jakość danych wytłumaczy szefowi, że wprawdzie ma do dyspozycji gigabajty danych, ale ich jakość jest tak słaba, że nie można ich wykorzystać do przewidywanego zastosowania?

Z tego powodu w dużych przedsiębiorstwach, których istnienie zależy od powszechnego dostępu wszystkich pracowników (nie tylko kierownictwa) do danych, często tworzy się stanowisko administratora danych (nie bazy danych), usytuowanego na poziomie najwyższego kierownictwa firmy. Uczestniczy on w definiowaniu wymagań co do zakresu, formatu i użycia danych potrzebnych przedsiębiorstwu. Po ich zdefiniowaniu można przystąpić do projektowania baz danych.

Słuchać Codda i Date'a

Już w pierwszej połowie lat 70. pojawiła się - opracowana przez E. F. Codda i C. J. Date'a - teoria baz relacyjnych, pozwalająca na uniknięcie wielu problemów związanych z uzyskaniem i utrzymywaniem danych dobrej jakości w bazie. Ponadto teoria ta umożliwiała projektowanie baz dobrej wydajności prawie niezależnie od wielkości bazy (dobrze skalowanych wraz ze wzrostem rozmiaru bazy). SQL pozwala również na zadawanie zapytań ad hoc do bazy, czego nie zapewniały istniejące dotychczas systemy baz plikowych, sieciowych i hierarchicznych.

Teoria baz relacyjnych natomiast:

  • pozwala na wymuszanie reguł integralności w bazie znormalizowanej, co uniemożliwia wprowadzenie błędnych danych i uszkodzenie bazy

  • zapewnia najbardziej efektywne metody zapisu danych na dyskach, pozwalając na osiąganie dobrej wydajności przez zmniejszenie liczby odczytów (zapisów) na dysk niezbędnych do pobrania (zapisania) danych

  • umożliwia otrzymanie poprawnej odpowiedzi z bazy na poprawnie sformułowane zapytanie, dzięki normalizacji bazy oraz właściwemu zdefiniowaniu kluczy głównych i obcych.

    Normalizować czy nie?

    Aby zapewnić dobrą jakość danych w bazie, należy ją normalizować. Nie jest to warunek dostateczny uzyskiwania danych dobrej jakości, lecz niezbędny. Istnieje wiele przyczyn powodujących, że projektanci nie tworzą znormalizowanego modelu bazy. Dość często spotykana polega na niezrozumieniu potrzeby normalizacji lub przekonaniu, iż baza w pełni znormalizowana działa wolniej. Jeżeli nawet aplikacja posługuje się bazą zdenormalizowaną, powinna to być baza wirtualna, wyprowadzona z zapisanej na dysku bazy znormalizowanej.

    Użytkownicy hurtowni danych będą argumentować, że najwydajniejsze hurtownie zawsze posługują się zdenormalizowanym modelem danych. To prawda, ale jest to jednak raczej zdenormalizowany pogląd na bazy znormalizowane. Hurtownia nie służy do zapisu poszczególnych rekordów danych, a jedynie do odczytu danych. Do hurtowni dane ładuje podczas operacji zapełniania z baz znormalizowanych. Ponadto, jeśli uznamy, że dane w hurtowni nie spełniają oczekiwań użytkowników, można zmienić projekt hurtowni i załadować ją od początku. Nie można tego wykonać z bazami danych operacyjnych.

  • W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

    TOP 200