Czasem wystarczy ?zwykła? baza danych

Przy dostępności wszystkich nowych technik informatycznych istotne jest, by nie zapominać, iż najprostsze rozwiązanie jest często najlepsze. Sam miałem niedawno powtórkę tej lekcji przy okazji dwóch projektów informatycznych. Obydwa rozpoczęły się od przymiarek do skomplikowanych systemów opartych na sieci, a zakończyły na zastosowaniu zwykłych baz danych. Bazy danych często umożliwiają utworzenie zdolnego do działania i efektywnego rozwiązania, dlatego znajomość technik baz danych ma kluczowe znaczenie dla współczesnych automatyków. 
Istnieją cztery kategorie baz danych ? relacyjne, sieciowe, hierarchiczne i obiektowe. Przeważająca większość zastosowań to relacyjne bazy danych, stosujące SQL (ang. Structured Query Language ? strukturalny język zapytań). Prócz komercyjnych systemów zarządzania relacyjnymi bazami danych (ang. Relational DataBase Management Systems, inaczej nazywane SQL DataBases) od Microsoftu, IBM, Oracle, SAS oraz innych producentów jest kilka takich systemów, dostępnych na zasadach otwartego źródła, np. PostgreSQL (www.postgresql.org), Firebird (firebird.sourceforge.net) czy MySQL (www.mysql.com).

Teoria relacyjnych baz danych, oparta na matematycznej algebrze zbiorów, została opisana w pracy dr. E.F. Codda: ?A Relational Model of Data for Large Shared Data Banks? (relacyjny model danych w dużych współużytkowanych bankach danych). Praca ta została opublikowana w 1970 r. na łamach Communications of the ACM (wydawnictwie stowarzyszenia Association of Computer Machinery). Reguły konstrukcji relacyjnych baz danych i specyfikacja języka zapytań do relacyjnych baz danych zostały zdefiniowane formalnie poprzez wprowadzenie normy ISO/IEC 9075:1992, ?Database Language SQL? oraz amerykańskiego standardu ANSI X3.135-1992. Normy te (i zgodność z nimi) jest w skrócie nazywana SQL-92. W roku 1999, a później w 2003, zostały wprowadzone rozszerzenia do języka SQL, ale podstawowy model relacyjnej bazy danych pozostał niezmienny. 
W relacyjnych bazach danych dane są zgrupowane w tabelach. Każda tabela bazy danych składa się z kolumn, określanych także jako atrybuty oraz z wierszy nazywanych także rekordami. 
Każdy wiersz (rekord, struktura) może być rozpatrywany jako obiekt, natomiast każda z kolumn zawiera wartości jednej określonej własności (atrybutu) wszystkich obiektów. Tabele mogą być powiązane relacjami: one-to-one, one-to-many, many-to-many (jeden do jednego, jeden do wielu, wiele do wielu) z innymi tabelami poprzez wspólne (wzajemnie skorelowane) kolumny.
Przykładowo, dwie różne tabele mogą zawierać kolumny z numerami seryjnymi urządzeń. Jeśli numery seryjne w dwóch tabelach będą takie same, to odpowiednie wiersze (rekordy) z dwóch różnych tabel okażą się związane relacją (wzajemną zależnością). Powoduje to dublowanie tych samych danych w obrębie bazy danych (powtórzenia w różnych tabelach), ale podczas projektowania relacyjnej bazy danych stosuje się standardowe procedury, nazywane ?normalizacją bazy danych?, by uzyskać efektywny układ tabel i zminimalizować dublowanie danych. 
Gdy trzeba skonstruować bazę danych do zastosowań produkcyjnych, należy zacząć od współpracy z zakładowym administratorem baz danych. W wielu przedsiębiorstwach jest wydzielona specjalna grupa informatyków, odpowiedzialna za zarządzanie firmowymi bazami. To oni są odpowiedzialni za to, by dane były definiowane i przechowywane w sposób spójny, żeby wprowadzanie i dostęp do danych było ograniczone odpowiednimi procedurami bezpieczeństwa, by przestrzegano firmowych reguł w zarządzaniu danymi. Jeśli nasza ?produkcyjna? baza będzie częścią korporacyjnej architektury baz danych (lub korporacyjnego systemu informatycznego), musi dostosować się do odpowiednich wymogów. 
Czasem wiele spośród danych potrzebnych w projekcie, obejmującym produkcyjną bazę danych, już istnieje i jest już dostępnych w innych, korporacyjnych bazach danych. Przykładowo, może już istnieć baza danych wykorzystywana w systemie zarządzania zasobami przedsiębiorstwa, a zawierająca: dane, opisy i specyfikacje sprzętu (maszyn, urządzeń). Stąd można zaczerpnąć dane identyfikacyjne urządzeń produkcyjnych. Podobnie mogą już istnieć inwentaryzacyjne bazy danych ze wskazaniem identyfikatorów i lokalizacji urządzeń. Jeśli takie dane już istnieją, powinny być wykorzystane w projekcie ?produkcyjnej bazy danych?. Zazwyczaj jest w firmie choćby jeden guru, który wie wszystko o firmowych bazach danych ? to może być cenny pomocnik. 
Administratorzy korporacyjnych baz danych mają spore doświadczenie, które można wykorzystać w projektach produkcyjnych baz danych. Pamiętajmy jednak, by nie pominąć opisu danych i wyjaśnienia ich znaczenia. Nazwy tabel i kolumn w bazie danych powinny być jasne, a ich przeznaczenie ? zrozumiałe. Wszystko to powinno być dodatkowo opisane i wyjaśnione w stosownej dokumentacji firmowej. Pozwala to uniknąć błędów popełnianych przez inne osoby ? błędów wynikających z niezrozumienia naszych struktur danych. Pozwala również uniknąć błędów nam samym ? błędów wynikających z niezrozumienia struktur danych innych osób. Administratorzy baz danych znają procedury normalizacji i pomogą nam zaprojektować efektywne struktury baz danych. Jednakże dyskusje z nimi wymagają znajomości i zrozumienia języka SQL. Współczesny automatyk powinien, choć trochę, znać język SQL i choćby podstawy teorii relacyjnych baz danych, by móc zastosować proste rozwiązania do prostych problemów.  
Dennis Brandl jest prezesem BR&L Consulting, 
firmy konsultingowej w Cary w USA.
dbrandl@brlconsulting.com  
Artykuł pod redakcją Adama Majczaka