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.

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.

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.

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.

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.

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.

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

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
  • Naleznosc
  • DataZamowienia
• pozycje_zamowienia
  • IdZamowienia
  • IdProduktu
  • LiczbaSztuk
• 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.

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.

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.

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 jednego”relacja „jeden do jednego”„jeden do jednego”. Elementem wspólnym obu tabel jest ich klucz podstawowy, a więc pole IdKlienta:

R1HW6sdfTFF0R

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.

Pola IdKlienta z obu tabel połączone są linią z oznaczeniem 1 na obu końcach.

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

Rq14t3AXerMIU

Film nawiązujący do treści materiału: Tworzenie relacji typu „jeden do jednego” w programie Microsoft Access.

Film nawiązujący do treści materiału: Tworzenie relacji typu „jeden do jednego” w programie Microsoft Access.

Film dostępny pod adresem /preview/resource/Rq14t3AXerMIU

Film nawiązujący do treści materiału: Tworzenie relacji typu „jeden do jednego” w programie Microsoft Access.

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

R1Xb6qePXj67k

Film nawiązujący do treści materiału: Tworzenie relacji typu „jeden do jednego” w programie LibreOffice Base.

Film nawiązujący do treści materiału: Tworzenie relacji typu „jeden do jednego” w programie LibreOffice Base.

Film dostępny pod adresem /preview/resource/R1Xb6qePXj67k

Film nawiązujący do treści materiału: Tworzenie relacji typu „jeden do jednego” w programie LibreOffice Base.

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