Przeczytaj

Dzielenie i łączenie

Już wiesz

Projekt relacyjnej bazy danych rozpoczynamy od analizy problemu – wycinka rzeczywistości, który baza danych ma odzwierciedlać. Wyodrębniamy w jej trakcie encjeencjaencje, które następnie przekształcamy w ich instancje – w relacyjnych bazach danych są to tabele.

Np. aplikacja służąca do rejestrowania pomiarów treningowych w klubie fitness mogłaby działać w oparciu o następujące dwie tabele:

tabela Zawodnicy:

RTbOnDDcgHxX0

Ilustracja przedstawia tabelę zawodników. W pierwszej kolumnie w nagłówku znajduje się: ID_Zawodnika a pod nim dane liczbowe. W drugiej kolumnie w nagłówku znajduje się: NICK a pod nim nazwy zawodników. W trzeciej kolumnie w nagłówku znajduje się: Imie a pod nim imiona zawodników. W czwartej kolumnie w nagłówku znajduje się: Nazwisko a pod nim imiona zawodników. W piątej kolumnie w nagłówku znajduje się: Email a pod nim adresy email zawodników. — Źródło: Contentplus.pl sp. z o.o., licencja: CC BY-SA 3.0.

ID_ZAWODNIKA	NICK	IMIE	NAZWISKO	EMAIL
1	ZosiaJ23	Zofia	Nowakowska	zosia1@email.pl
2	MaciekA007	Maciej	Kowalski	maciek9@email.pl
3	Alex302	Aleksander	Lewandowski	alexlew@email.pl
4	MaciekD008	Maciej	Wiśniewski	maciek5@email.pl

tabela Pomiary:

R3RaofSRUUdYL

Ilustracja przedstawia tabelę pomiarów. W pierwszej kolumnie w nagłówku znajduje się: ID_Pomiaru a pod nim dane liczbowe. W drugiej kolumnie w nagłówku znajduje się: Data pomiaru a pod nim daty. W trzeciej kolumnie w nagłówku znajduje się: Czas a pod nim wypisane są czasy. W czwartej kolumnie w nagłówku znajduje się: Dystans [m] a pod nim wartości liczbowe. W piątej kolumnie w nagłówku znajduje się: kilokalorie a pod nim wartości liczbowe. — Źródło: Contentplus.pl sp. z o.o., licencja: CC BY-SA 3.0.

ID_POMIARU	DATA POMIARU	CZAS	DYSTANS [m]	KILOKALORIE
1	2020‑04‑13	22:15:00	7481,6	197
2	2020‑04‑14	21:36:22	7363,1	192
3	2020‑04‑15	19:47:28	7211,5	187
4	2020‑04‑16	20:16:17	7317,6	189
5	2020‑04‑17	21:14:07	7348,9	194
6	2020‑04‑18	19:26:52	7205,6	186
7	2020‑04‑19	20:26:52	7322,1	190
8	2020‑04‑20	21:26:52	7358,7	194
9	2020‑04‑21	22:26:52	7532,2	195
10	2020‑04‑22	23:26:52	7548,6	199

W celu połączenia obu tabel wykorzystujemy klucz podstawowy z tabeli Zawodnicy, traktując go jako tzw. klucz obcy w tabeli Pomiary:

RdbHgAVa4kXh6

Ilustracja przedstawia tabelę pomiarów z dołączoną kolumną ID_ZAWODNIKA z tabeli Zawodnicy. W pierwszej kolumnie w nagłówku znajduje się: ID_Pomiaru a pod nim dane liczbowe. W drugiej kolumnie w nagłówku znajduje się: Data pomiaru a pod nim daty. W trzeciej kolumnie w nagłówku znajduje się: Czas a pod nim wypisane są czasy. W czwartej kolumnie w nagłówku znajduje się: Dystans [m] a pod nim wartości liczbowe. W piątej kolumnie w nagłówku znajduje się: kilokalorie a pod nim wartości liczbowe. W szóstej kolumnie, która zaznaczona jest czerwonym prostokątem w nagłówku znajduje się: ID_Zawodnika a pod nim wartości liczbowe. — Źródło: Contentplus.pl sp. z o.o., licencja: CC BY-SA 3.0.

Dzięki takiemu zabiegowi każdy pomiar będzie jednoznacznie przypisany do konkretnego zawodnika. Relacja łącząca obie tabele jest typu „jeden do wielu”, ponieważ jeden zawodnik może mieć odnotowanych wiele różnych pomiarów, natomiast konkretny pomiar dotyczy tylko jednego zawodnika.

W systemie zarządzania bazą danych relacja ta będzie oznaczona w następujący sposób:

R1XTqveTWALoe

Ilustracja przedstawia połączenie dwóch tabel, które wyglądają następująco: Zawodnicy IdZawodnika z ikoną klucza po prawej stronie Nick Imie Nazwisko Email Pomiary IdPomiaru z ikoną klucza po prawej stronie DataPomairu Czas Dystans Kilokalorie IdZawodnika Od pola IdZawodnika w tabeli Zawodnicy rozpoczyna się połączenie z oznaczeniem 1 do pola IdZawodnika w tabeli Pomiary z oznaczeniem nieskończoności. — Źródło: Contentplus.pl sp. z o.o., licencja: CC BY-SA 3.0.

Poznana relacja „jeden do wielu” jest najczęściej występującym, lecz nie jedynym typem powiązania występującym w praktycznych zastosowaniach relacyjnych baz danych.

Relacja typu „wiele do wielu”

W materiale Budowa relacyjnej bazy danych, etap IPzZgiSZUxBudowa relacyjnej bazy danych, etap I przedstawiony został przykład bazy danych wykorzystywanej do obsługi sklepu z produktami pszczelimi rodziców Tomka. Baza ta składała się z trzech tabel – Klienci, Zamowienia oraz Produkty:

R5FAHcJaTVLj2

Ilustracja przedstawia połączenia trzech tabel, które wyglądają następująco: Klienci IdKlienta z ikoną klucza po prawej stronie Imie Nazwisko UlicaNr KodPocztowy Miejscowość Telefon Email Zamowienia IdZamowienia z ikoną klucza po prawej stronie Klient Produkt LiczbaSztuk Naleznosc DataZamowienia produkty IdProduktu z ikoną klucza po prawej stronie Nazwa Pojemnosc CenaZaSztuke LiczbaSztukaDoSprzedania Od pola IdKlienta z tabeli klienci, o oznaczeniu 1 zaczyna się połączenie do pola Klient w tabeli zamowienia, z oznaczeniem nieskończoności. Od pola Produkt z tabeli zamowienia z oznaczeniem nieskończoności zaczyna się połączenie do pola IdProduktu w tabeli pozycje_zamowienia, pole oznaczono 1. — Źródło: Contentplus.pl sp. z o.o., licencja: CC BY-SA 3.0.

Dla uproszczenia przyjęto, że konkretne zamówienie może dotyczyć tylko jednego produktu. Dzięki takiemu założeniu można było ustanowić relację „jeden do wielu” między tabelami Zamowienia oraz Produkty, ponieważ określony produkt może co prawda występować w wielu różnych zamówieniach, ale konkretne zamówienie może dotyczyć tylko jednego produktu.

Takie uproszczenie jest jednak sporym ograniczeniem dla sklepu oraz dużą niedogodnością dla klientów, którzy często dokonują zamówień obejmujących więcej niż jeden produkt. W celu dostosowania systemu obsługi sklepu do opisanej sytuacji musimy zmienić typ relacji występującej między tabelami Produkty i Zamowienia z „jeden do wielu” na „wiele do wielu”relacja „wiele do wielu”wiele do wielu”. Relację taką realizujemy poprzez zdefiniowanie dodatkowej tabeli (zwanej tabelą pośrednią, łączącą lub tabelą skrzyżowań), składającej się z kluczy podstawowych dwóch łączonych tabel:

RAewRflRay2mf

Ilustracja przedstawia połączenia czterech tabel, które wyglądają następująco: Klienci IdKlienta z ikoną klucza po prawej stronie Imie Nazwisko UlicaNr KodPocztowy Miejscowość Telefon Email Zamowienia IdZamowienia z ikoną klucza po prawej stronie Klient Produkt LiczbaSztuk Naleznosc DataZamowienia pozycje_zamowienia IdZamowienia IdProduktu produkty IdProduktu z ikoną klucza po prawej stronie Nazwa Pojemnosc CenaZaSztuke LiczbaSztukaDoSprzedania Od pola IdKlienta z tabeli klienci, o oznaczeniu 1 zaczyna się połączenie do pola Klient w tabeli zamowienia, z oznaczeniem nieskończoności. Od pola IdZamowienia z tabeli zamowienia z oznaczeniem 1 zaczyna się połączenie do pola IdZamowienia w tabeli pozycje_zamowienia, pole oznaczono nieskończonością. Od pola IdProduktu z tabeli pozycje_zamowienia zaczyna się połączenie z oznaczeniem nieskończoności do pola IdProduktu w tabeli produkty z oznaczeniem 1. Pole Produkt w tabeli Zamowienia zostało skreślone, natomiast pole LiczbaSztuk zostało otoczone zielonym prostokątem i strzałka wychodząca z niego kieruje na tabelę pozycje_zamowienia. — Źródło: Contentplus.pl sp. z o.o., licencja: CC BY-SA 3.0.

Połączenie tabel Produkty i Zamowienia relacją „wiele do wielu” jest realizowane za pomocą dwóch powiązań typu „jeden do wielu” oraz jednej tabeli pośredniej.

W celu zachowania poprawności obsługi zamówień powinniśmy dokonać kilku poprawek:

- w tabeli Zamowienia pozbywamy się pola Produkt, ponieważ informacje o produktach dotyczących danego zamówienia będą pochodziły z tabeli Pozycje_zamowienia,

- pole LiczbaSztuk przenosimy z tabeli Zamowienia do tabeli Pozycje_zamowienia.

Po korektach struktura bazy danych będzie wyglądała następująco:

RciFla3ygpDtQ

W praktycznych realizacjach bazodanowych najczęściej spotykamy się z relacjami typu „jeden do wielu” oraz „wiele do wielu”.

Relacja typu „jeden do jednego”

Dane osobowe przechowywane w bazie danych powinny podlegać szczególnej ochronie. Dodatkowo, biorąc pod uwagę plan rozbudowy sklepu w kierunku możliwości dokonywania zakupów poprzez stronę internetową, w sklepie rodziców Tomka pojawiła się potrzeba bezpiecznego przechowywania loginów oraz haseł logowania do kont klientów. I chociaż hasła będą przechowywane w postaci niejawnej (poprzez zastosowanie szyfrowania lub hashowania), należy zrobić wszystko, aby wzmocnić poziom ochrony tych danych.

Gdyby tabelę Klienci uzupełnić o pola login i hasło, przybrałaby ona następującą postać:

R1KWVd3EWfoNe

Ilustracja przedstawia tabelę Klienci. Zawiera ona takie pola jak: IdKlienta, obok którego znajduje się ikona klucza, Imie, nazwisko, UlicaNr, KodPocztowy, Miejscowosc, Telefon, email, Login, Haslo. — Źródło: Contentplus.pl sp. z o.o., licencja: CC BY-SA 3.0.

Ze względów bezpieczeństwa wyizolujmy część danych do osobnej tabeli o nazwie Klienci_ochrona. Uzyskamy w ten sposób następujące dwie tabele:

R1NekSs5QnyEd

Ilustracja przedstawia dwie tabele: Klienci_ochrona oraz Klienci. W tabeli klienci_ochrona znajdują się pola: IdKlienta, obok którego znajduje się ikona klucza, UlicaNr, KodPocztowy, Miejscowosc, Telefon, email, Login, Haslo. W tabeli klienci znajdują się pola: IdKlienta z ikoną klucza po lewej stronie. Imie, nazwisko. — Źródło: Contentplus.pl sp. z o.o., licencja: CC BY-SA 3.0.

Zależność między danymi przechowywanymi w obu tabelach jest taka, że każdemu rekordowirekordrekordowi z tabeli Klienci_ochrona odpowiada dokładnie jeden rekord z tabeli Klienci oraz każdemu rekordowi z tabeli Klienci odpowiada dokładnie jeden rekord z tabeli Klienci_ochrona. Jest to zależność typu „jeden do jednegorelacja „jeden do jednego”jeden do jednego”. Elementem wspólnym obu tabel jest ich klucz podstawowy, a więc pole IdKlienta:

R1HW6sdfTFF0R

Nawiązanie relacji typu „jeden do jednego” w programie Microsoft Access przedstawiono w filmie:

Rq14t3AXerMIU

Źródło: Contentplus.pl Sp. z o.o., licencja: CC BY-SA 4.0.

Nawiązanie relacji typu „jeden do jednego” w programie LibreOffice Base przedstawiono w filmie:

R1Xb6qePXj67k

Źródło: Contentplus.pl Sp. z o.o., licencja: CC BY-SA 3.0.

Relacja typu „jeden do jednego” jest najrzadziej występującym typem powiązania w relacyjnych bazach danych. Jest ona wykorzystywana w celu:

poprawienia efektywności dostępu do danych poprzez podział tabeli z wieloma kolumnami na dwie lub więcej tabel o mniejszej liczbie kolumn,
zwiększenia bezpieczeństwa danych szczególnie istotnych poprzez ich odizolowanie w osobnej tabeli,
wydzielenia danych krótkotrwałych, które można wówczas łatwiej usunąć, gdy już nie są potrzebne.

Słownik

encja

(ang. entity) schematyczny opis rzeczywistych lub wymyślonych obiektów posiadających te same cechy, zwane atrybutami lub własnościami

rekord

w kontekście relacyjnej bazy danych to jeden wiersz tabeli, zawiera wartości wszystkich pól; rekordem nazywa się również wiersze uzyskiwane w wynikach zapytań, każdy taki wiersz zawiera wartości z pól wskazanych w zapytaniu

relacja „jeden do jednego”

typ relacji w bazie danych polegający na tym, że jeden rekord w tabeli A ma dokładnie jeden odpowiadający mu rekord w tabeli B oraz konkretny rekord z tabeli B również posiada tylko jeden pasujący rekord z tabeli A

relacja „wiele do wielu”

typ relacji w bazie danych polegający na tym, że jeden rekord w tabeli A może mieć wiele odpowiadających rekordów w tabeli B oraz konkretny rekord z tabeli B może mieć również wiele pasujących rekordów z tabeli A, np. na jeden produkt może być złożonych wiele zamówień, natomiast konkretne zamówienie może dotyczyć wielu różnych produktów

Wprowadzenie

Infografika

Dzielenie i łączenie

Relacja typu „wiele do wielu”

Relacja typu „jeden do jednego”

Słownik