Relacyjna baza danych jako struktura stosowana do przechowywania informacji o dokumentach

Dokumentami elektronicznymi oczywiście łatwiej zarządzać niż papierowymi. Dlatego często przekształca się, dokumenty papierowe do postaci elektronicznej, a ściślej rzecz biorąc wykonuje się ich elektroniczne kopie (skany). Oczywiście do zarządzania zbiorem dokumentów elektronicznych konieczne są odpowiednie narzędzia.
Jak już poprzednio napisałem, zwykła struktura katalogów na dysku twardym nie będzie zbyt pomocna do zarządzania dokumentami, mimo, że dokumenty tworzą strukturę hierarchiczną podobną do struktury plików na dysku twardym.

Postaram się pokrótce omówić powody dla których tak jest.

  1. System plików danego komputera jest zazwyczaj dostępny tylko dla jednego lub kilku użytkowników. Oczywiście można to ograniczenie łatwo przekroczyć, umieszczając, umieszczając pliki na serwerze lokalnej sieci wykorzystywane w organizacji. Wtedy jednak powstają kolejne problemy. W przypadku organizacji wielooddziałowych ścieżka do pliku nie identyfikuje go jednoznacznie, bo ten sam plik może mieć ścieżkę \\serwer\plik, albo \\Warszawa\serwer\plik.
  2. Dowolność nazw plików. Szczególnie dotkliwie odczuwamy ją, gdy nazwy są nadawane np przez urządzenie skanujące lub przyjmujące faks i są np. postaci FKMBT_C250080809141707. Oczywiście w tej nazwie są dostępne pewne informacje, np. czas powstania pliku, ale nie są one wystarczające dla skutecznego zarządzania systemem. Nie mniej jednak, gdyby wymyślić system nazw plików i systematycznie go stosować mogłoby to służyć za podstawę zarządzania niewielką ilością plików. Należy jednak pamiętać, że w nazwie zmieści się jednak bardzo ograniczona ilość informacji. Tymczasem pożądane byłoby, żeby pewna ilość informacji o dokumencie (w tym krótki jego opis, informacja do kogo został skierowany etc) była możliwa do odczytania z sytemu zarządzania, bez czytania całego dokumentu.
  3. Trudność przeszukiwania. Wprawdzie istnieją niezłe programy do przeszukiwania systemu plików, wymienię tu Google Desktop i Copernic Desktop Search, oddają one nieocenione usługi i sam używam jednego z nich, uważam jednak, że na tego typu rozwiązanie można sobie pozwolić w domu lub niewielkiej firmie (oczywiście jeśli miałby to być jedyny spsób na wyszukiwanie dokumentów). Zasadniczym problemem wydaje się jednak, że wyszukiwanie "pełnotekstowe" w plikach w przypadku skanowanych dokumentów albo nie działa, albo wymaga zastosowania OCR.
  4. Na koniec sprawa, która wydaje się najistotniejsza. Z systemu plików nie da się wygenerować żadnych sensownych raportów o posiadanych dokumentach. Na przykład jeśli mamy w systemie plików katalog "umowy", a w nim podkatalogi np: "sprzedaż", "najem", "licencyjne", "zlecenia", "o_dzielo", to wprawdzie łatwo policzymy ile jest umów o dzieło, ale w żaden sposób nie wygenerujemy spisu umów zakończonych, albo spisu umów obowiązujących, albo tych, których wartość przekracza określona kwotę etc. Nie pomoże nam w tym żaden system typu Google Desktop.
    1. Jeśli sobie to uświadomimy, to staje się jasne, że dla skutecznego zarządzania dokumentami nie wystarczą same pliki, w których mieszczą się np zeskanowane kopie naszych "papierów". Konieczne jest wprowadzenie do systemu dodatkowych informacji, które będziemy nazywać metadanymi. Na dodatek te matedane muszą być w sensowny sposób zorganizowane i przechowywane w jakiejś strukturze, które pozwoli je analizować i wyciągać z nich wnioski. Na przykład do każdej umowy można przewidzieć następujące metadane (nie jest to na pewno katalog wyczerpujący):

  • Nazwa kontrahenta
  • Data zawarcia
  • Data przewidywanego zakończenia
  • Okres wypowiedzenia
  • Data rzeczywistego zakończenia
  • Typ umowy (np sprzedaży, o dzieło, o pracę etc)
  • Wartość umowy
  • Departament nadzorujący

Jeśli takie metadane są w systemie, to już stosunkowo łatwo zaprogramować wydruk np. wszystkich umów zawartych z tym samym kontrahentem.
Strukturą idealną do przechowywania i zarządzania takimi metadanymi jest system zarządzania relacyjną bazą danych.