Transformacja modelu konceptualnego do relacyjnego to kluczowy etap w projektowaniu bazy danych, który polega na przekształceniu encji, atrybutów i relacji z modelu konceptualnego w tabele, kolumny i relacje w modelu relacyjnym. Ten proces formalizuje projekt bazy danych i przygotowuje go do implementacji w systemie zarządzania bazą danych (DBMS).
1. Przekształcanie encji w tabele
Teoria: W modelu relacyjnym każda encja z modelu konceptualnego jest reprezentowana przez tabelę. Każda encja staje się tabelą, a jej atrybuty stają się kolumnami tej tabeli. Klucz główny (primary key) encji jest przekształcany w klucz główny tabeli, co zapewnia unikalną identyfikację każdego rekordu.
Ćwiczenie praktyczne:
- Ćwiczenie 1: Mając przygotowany model konceptualny z encjami (np. Klient, Zamówienie, Produkt), stwórz w programie do edycji tekstu (np. Notatnik) lub arkuszu kalkulacyjnym listę tabel i odpowiadających im kolumn (atrybutów). Zdefiniuj klucz główny dla każdej tabeli.
Przykład:
Tabela: Klient
Kolumny: klient_id (PRIMARY KEY), imię, nazwisko, adres, email
Tabela: Produkt
Kolumny: produkt_id (PRIMARY KEY), nazwa, cena, opis
2. Transformacja relacji 1 do 1
Teoria: W relacji 1 do 1 każda tabela ma dokładnie jeden rekord powiązany z jednym rekordem w innej tabeli. Można to zaimplementować przez dodanie klucza obcego (foreign key) jednej tabeli do drugiej lub poprzez połączenie dwóch tabel w jedną, jeśli jest to uzasadnione.
Ćwiczenie praktyczne:
- Ćwiczenie 2: Stwórz relację 1 do 1, na encjach z poprzedniej lekcji. Wybierz, do której tabeli chcesz dodać klucz obcy, i zdefiniuj go.
Przykład:
Tabela: Użytkownik
Kolumny: użytkownik_id (PRIMARY KEY), nazwa
Tabela: Profil
Kolumny: profil_id (PRIMARY KEY), użytkownik_id (FOREIGN KEY), biografia, zdjęcie_profilowe
W tym przypadku klucz użytkownik_id
w tabeli "Profil" odnosi się do rekordu w tabeli "Użytkownik", co zapewnia relację 1 do 1.
3. Transformacja relacji 1 do wielu
Teoria: Relacja 1 do wielu (one-to-many) jest implementowana przez dodanie klucza obcego w tabeli po stronie "wiele". Klucz obcy w tej tabeli wskazuje na tabelę po stronie "1". Przykładem jest relacja między tabelą „Klient” a „Zamówienie”, gdzie jeden klient może mieć wiele zamówień.
Ćwiczenie praktyczne:
- Ćwiczenie 3: Dla relacji 1 do wielu (np. Klient -> Zamówienie) stwórz tabele i dodaj klucz obcy do tabeli "Zamówienie", który będzie wskazywał na tabelę "Klient".
Przykład:
Tabela: Klient
Kolumny: klient_id (PRIMARY KEY), imię, nazwisko
Tabela: Zamówienie
Kolumny: zamówienie_id (PRIMARY KEY), klient_id (FOREIGN KEY), data_zamówienia, kwota
W ten sposób klient_id
w tabeli "Zamówienie" będzie odwoływał się do klient_id
w tabeli "Klient".
4. Transformacja relacji wiele do wielu
Teoria: Relacje wiele do wielu (many-to-many) wymagają stworzenia dodatkowej, pośredniczącej tabeli (join table), która będzie zawierać klucze obce z obu tabel. Tabela pośrednicząca przechowuje powiązania między rekordami w dwóch głównych tabelach. Na przykład, studenci mogą być zapisani na wiele kursów, a każdy kurs może mieć wielu studentów.
Ćwiczenie praktyczne:
- Ćwiczenie 4: Zaimplementuj relację wiele do wielu, np. między tabelami Student i Kurs. Utwórz tabelę pośredniczącą
Student_Kurs
.
Przykład:
Tabela: Student
Kolumny: student_id (PRIMARY KEY), imię, nazwisko
Tabela: Kurs
Kolumny: kurs_id (PRIMARY KEY), nazwa_kursu, opis
Tabela: Student_Kurs
Kolumny: student_id (FOREIGN KEY), kurs_id (FOREIGN KEY)
Tym sposobem, tabela "Student_Kurs" przechowuje powiązania między studentami i kursami.
5. Określanie kluczy głównych (PRIMARY KEY)
Teoria: Każda tabela w modelu relacyjnym musi mieć klucz główny (PRIMARY KEY), który jednoznacznie identyfikuje każdy rekord. Klucz główny może składać się z jednej kolumny lub kilku kolumn (klucz złożony).
Ćwiczenie praktyczne:
- Ćwiczenie 5: Dla każdej tabeli w swoim projekcie zdefiniuj klucz główny. W przypadku tabeli pośredniczącej (wiele do wielu) zdefiniuj klucz złożony składający się z dwóch kolumn (kluczy obcych).
Przykład:
Tabela: Student_Kurs
Kolumny: student_id (FOREIGN KEY), kurs_id (FOREIGN KEY)
PRIMARY KEY (student_id, kurs_id)
Klucz złożony zapewnia, że ta sama kombinacja student_id
i kurs_id
nie może pojawić się więcej niż raz, co zapobiega duplikowaniu zapisów.
7. Weryfikacja modelu relacyjnego
Teoria: Po zakończeniu transformacji modelu konceptualnego do relacyjnego warto przeprowadzić weryfikację projektu. Należy sprawdzić, czy struktura tabel odpowiada modelowi konceptualnemu, czy nie ma nadmiarowych danych oraz czy wszystkie relacje są poprawnie zaimplementowane.
Ćwiczenie praktyczne:
- Ćwiczenie 7: Zanalizuj swój model relacyjny z perspektywy integralności danych (czy wszystkie klucze obce są poprawnie zdefiniowane, czy wszystkie klucze główne są jednoznaczne).