Istnieje konceptualna podstawa do projektowania baz danych.
W klasycznym projekcie bazy danych istnieją trzy modele: koncepcyjny, logiczny i fizyczny.
Model koncepcyjny wyłania się z analizy wymagań i ewoluuje wraz z ewolucją leżącego u jego podstaw przedmiotu lub zmienia się rozumienie przedmiotu. Model pojęciowy przypisuje elementarne dane do formy i semantyki, ale nie zajmuje się takimi zagadnieniami, jak skład tabeli.
Model logiczny wykorzystuje relacyjny model danych. Można go wyprowadzić z modelu pojęciowego, ale dotyczy również składu relacji. Występują tutaj normalizacja i inne kwestie dotyczące kompozycji. Model logiczny przewiduje projektowanie tabeli, a także kwerendy i aktualizacje aplikacji.
Model fizyczny implementuje relacje jako tabele, a także dodaje wszystkie inne funkcje, takie jak indeksy, obszary tabel itp.potrzebne do zbudowania bazy danych. Pochodzi z modelu logicznego, ale w grę wchodzą: objętość danych, obciążenie, wydajność i przestrzeń dyskowa.
To brzmi długotrwale i nużąco, ale w rzeczywistości jest szybkie, jeśli wiesz, jak to zrobić. Całość można zrobić w ciągu kilku tygodni, podczas gdy reszta zespołu wciąż debatuje nad funkcjonalnymi specyfikacjami. Dla naprawdę małego projektu (6 tabel, 50 kolumn) można to zrobić w kilka dni, za pomocą tylko ołówka i papieru. W przypadku większych projektów istnieją narzędzia, które sprawiają, że projektowanie staje się bardziej automatyczne, mniej podatne na błędy i łatwe do przedstawienia.
Ale co się stanie, gdy odkryjesz, że model koncepcyjny był niedokładny lub niekompletny, a pozostałe dwa modele i sama baza danych muszą zostać zmienione? To tutaj przybywa na ratunek Data Independence. Niezależność danych polega na projektowaniu bazy danych, co oznacza enkapsulacja dla projektu obiektu. Mianowicie zapobiega to rozprzestrzenianiu się drobnego dopasowania w jednym miejscu na obiektach aplikacji. Obiekty zależą tylko od danych, z których korzystają.
Jeśli do schematu ma zostać dodana nowa tabela, szanse, że jakaś aplikacja zostanie zerwana, są znikome. Nawet jeśli istniejąca tabela musi zostać zmieniona, zapytania korzystające tylko ze starych kolumn nie będą miały żadnej różnicy. Nawet jeśli obiekty są zależne od zmiany, nadal możesz nadać zmienionej tabeli nową nazwę, a następnie utworzyć widok ze starą nazwą, która sprawia, że wygląda tak, jak stary stół.
Niezależność danych fizycznych jest prawie kompletna w dobrym DBMS. Możesz reorganizować dane, dodawać i upuszczać indeksy itp. I nie powinieneś zmieniać żadnej aplikacji.
Podsumowując, zarządzanie zmianami może być wykonane doskonale przy użyciu naprawdę dobrych produktów DBMS. Niestety, wielu administratorów i programistów nie wie, jak w odpowiedni sposób korzystać z tych funkcji DBMS, mimo że istnieją one od lat.
Co, jeśli odwrócisz to: powiedz, że specyfikacja klienta jest obecnie tylko dla jednego wykonawcy na czas trwania trasy koncertowej, ale w przyszłości dwa z ich zespołów mogą wyruszyć w trasę razem, grając w te same programy. Czy nadal dodajesz artist_id do tabeli z datami zwiedzania, ograniczając system do 1 artysty na turę? A może myślisz o przyszłości, czyniąc ją relacją HaBtM? – Calvin