Pierwszym krokiem przy projektowaniu bazy danych o klientach jest
Właściwe podejście do projektowania bazy danych zawsze zaczyna się od określenia celu, w jakim ta baza ma powstać. Moim zdaniem, jeśli na tym etapie popełnimy błąd, cała reszta – od struktury tabel, przez relacje, aż po optymalizację wydajności – będzie już tylko łataną prowizorką. Bazy danych, szczególnie w biznesowych zastosowaniach, muszą odpowiadać na konkretne potrzeby firmy, działu czy nawet pojedynczego użytkownika. Nie chodzi tutaj tylko o przechowywanie danych o klientach, ale o to, by te dane wspierały jakieś procesy: sprzedaż, obsługę klienta, marketing, raportowanie, i tak dalej. Dlatego przed jakimkolwiek rysowaniem diagramów czy wrzucaniem rekordów trzeba bardzo dokładnie przemyśleć, do czego ta baza będzie wykorzystywana. Z mojego doświadczenia wynika, że najlepsze systemy powstają, gdy projekt zaczyna się właśnie od warsztatów z użytkownikami końcowymi, analizy procesów i dopiero potem rusza techniczna robota. To też jest zgodne z metodyką projektowania systemów informatycznych, gdzie wymagania biznesowe są pierwszym krokiem (patrz: standardy takie jak ISO/IEC 25010 czy metodyka UML). Praktyczny przykład: jeżeli sklep internetowy chce lepiej segmentować swoich klientów, to już na etapie planowania bazy trzeba przemyśleć, jakie dane i relacje będą potrzebne, żeby ten cel osiągnąć. Z góry wiadomo wtedy, co trzeba uwzględnić, a co jest zbędne. Takie podejście oszczędza później sporo czasu i pieniędzy.
Często spotykam się z przeświadczeniem, że projektowanie bazy danych powinno zaczynać się od strony technicznej – jakiegoś wymyślania algorytmów, budowania zaawansowanych wyszukiwarek czy nawet podpisywania umów ze specjalistami. To są, moim zdaniem, typowe pułapki myślowe, które wynikają z mylenia procesu produkcji oprogramowania z etapem planowania i analizy. Na przykład, projektowanie algorytmów sortowania na samym początku nie ma sensu, bo jeszcze nie wiadomo, jakie dane, w jakich ilościach i w jakich kontekstach będą sortowane. Bez zrozumienia celu bazy takie działania są trochę jak strzelanie na oślep – można wymyślić coś błyskotliwego, co okaże się zupełnie nieprzydatne lub wręcz szkodliwe. Tworzenie systemów wyszukiwania zaawansowanego jest z kolei krokiem, który powinien wynikać z dokładnej analizy wymagań użytkowników – najpierw trzeba wiedzieć, jakie informacje są kluczowe i w jaki sposób będą potrzebne, dopiero potem buduje się konkretne funkcje. Podpisywanie umów na wykonanie bazy z jakimiś specjalistami bez jasnego określenia celu to kolejny błąd organizacyjny. Takie działanie może prowadzić do powstania systemu, który formalnie istnieje, ale absolutnie nie spełnia rzeczywistych potrzeb firmy czy użytkowników końcowych. Moim zdaniem, wszystkie te podejścia pokazują, jak łatwo jest pomylić kolejność działań – w praktyce dopiero dobrze zdefiniowany cel pozwala stworzyć sensowny projekt techniczny bazy danych. Takie są też standardy branżowe i w sumie zdrowy rozsądek. Bez określenia celu cały projekt może się rozjechać już na samym początku.