17.10.

2023

Modelowanie baz danych

WPROWADZENIE DO MODELOWANIA
DIAGRAM ERD, RDB

Opracowanie: dr inż. Ewelina Piotrowska

e.piotrowska@po.edu.pl
e.piotrowska.po.edu.pl

Aktualizacja: 2023-10-02

Politechnika Opolska | Opole University of Technology | www.po.edu.pl

Wydział Elektrotechniki, Automatyki i Informatyki| www.weaii.po.edu.pl
OPOLE 2018 Katedra Informatyki | www.ii.po.edu.pl

Czym jest baza danych ?

2

 Baza danych jest tematycznie wyodrębnionym, logicznie zintegrowanym i

odpowiednio uporządkowanym oraz utrwalonym zbiorem danych.
 Nie ma znaczenia, czy to kartoteka papierowa, czy dane w aplikacji
komputerowej. Jeśli informacje są uporządkowane i gromadzone w
określonym celu, już stają się bazą danych.
 Przyjmuje się, że dane to wartości przechowywane w bazie, zaś informacje to
dane przetwarzane i udostępniane użytkownikowi (te są dynamiczne).
Informacje mogą być prezentowane na wiele sposobów — jako wynik zastosowania
polecenia, wyświetlane w odpowiednio zaprojektowanej formatce na ekranie
komputera lub wydrukowane w postaci odpowiednio zredagowanego raportu.

1
 17.10.2023

Pojęcia związane z wartością: Dane

3

 Wartości przechowywane w bazie danych nazywamy danymi.

 Dane są statyczne, to znaczy nie zmieniają swojej postaci do czasu
zmodyfikowania poprzez proces manualny lub automatyczny.
Przykładowe dane:

Na tym etapie takie dane są nieprzydatne.

Nie da się na przykład określić znaczenia liczby 92883. Czy jest to kod
pocztowy? A może numer części? Nawet jeśli wiesz, że jest to numer
identyfikacji klienta, to czy jest on związany z Grzegorzem Popielskim?
Nie dowiesz się tego, dopóki nie przetworzysz tych danych.

Pojęcia związane z wartością: Informacje

4

 Informacje to dane, które przetwarza się tak, by nabrały znaczenia.

 Są one dynamiczne, to znaczy zmieniają się wraz z danymi w bazie
danych.
Można je także przetwarzać i prezentować na wiele różnych sposobów.
Można je przedstawiać jako wynik instrukcji SELECT języka SQL, pokazać je w
formularzu na ekranie komputera lub wydrukować w postaci raportu.
Pamiętaj o tym, że musisz przetworzyć dane tak, by stworzyć z nich
zrozumiałe informacje.
 Rysunek pokazuje, jak
dokonać transformacji
i przetworzyć dane
w zrozumiałe informacje. Zostały one przetworzone w tym przypadku do postaci karty
danych pacjenta, tak
by miały sens dla
każdego, kto będzie je
przeglądał.

2
 17.10.2023

Dane a informacje
5

 Bardzo ważne jest zrozumienie różnicy pomiędzy danymi a

informacjami.
 Bazę danych projektuje się, by zapewnić zrozumiałe informacje
osobom pracującym w danej firmie lub organizacji.
Te informacje dostępne będą tylko pod warunkiem, że w bazie danych
istnieją odpowiednie dane, a sama baza zbudowana jest w taki sposób, by
wspierać te informacje.
Gdyby kiedykolwiek zdarzyło Ci się zapomnieć, jaka jest różnica pomiędzy
danymi a informacjami, zapamiętaj następujący aksjomat:

Dane są tym, co przechowujesz, informacje są tym, co wydobywasz.

Istota danych
6

 Na przestrzeni lat zmianie uległ format danych:

Kiedyś dane były reprezentowane po prostu przez tekst i
wartości liczbowe przechowywane w bazie danych
Dzisiaj dane są rozszerzenie do formatu cyfrowego co pozwala
uwzględnić obrazy, dźwięki, wirtualne obiekty trójwymiarowe
oraz różno-rodne złożone struktury multimedialne
Ewolucyjny rozwój natury danych stanowi wyzwanie pod
względem sposobów użycia technologii w maksymalnym
możliwym zakresie.

3
 17.10.2023

Istota danych
7

 Zmianie uległ także przedmiot oraz główne obszary

zastosowania danych.
Kiedyś dane postrzegano głównie w kontekście systemów
księgowo-rachunkowych.
Obecnie należy uwzględnić np:
 systemy nawigacji satelitarnej wykorzystujące dynamiczne łącza z
satelitami, pomocne w znajdowaniu prawidłowej drogi do celu
 gry wirtualne umożliwiające osobom z całego świata grę i komunikowanie
się w czasie rzeczywistym
 systemy handlu elektronicznego elektronicznego pamiętające swoich
użytkowników oraz generujące listy potencjalnie interesujących dla nich
towarów
 kamery umieszczane na budynkach publicznych wykorzystujące
oprogramowanie rozpoznające twarze w celu zwiększenia poziomu
bezpieczeństwa

Modelowanie danych (ang. data modeling)

8

 Współczesne spojrzenie na kwestię zarządzania danymi pozwala

stwierdzić, że: zachodzi potrzeba gromadzenia i przechowywania
danych w najbardziej elementarnej, niepodzielnej, podstawowej
i umożliwiającej ponowne użycie postaci.
Tylko w ten sposób można tworzyć związki obsługujące tworzenie nowo
definiowanych informacji.
Ze względu na fakt, że często zachodzi potrzeba łączenia takich
podstawowych elementów danych, musimy zaprojektować odpowiednie
mechanizmy przechowujące i przetwarzające pozwalające na osiągnięcie tak
postawionych celów.
 Proces wykorzystywany w celu odkrywania takich podstawowych
elementów danych, określania ich wzajemnych związków oraz
definiowania ich w taki sposób, aby mogły być rozpoznawane i
używane w przyszłości, określa się mianem MODELOWANIA
DANYCH

4
 17.10.2023

Modelowanie danych
9

 Proces modelowania może pozwolić na uchwycenie reprezentacji

czegoś, co istnieje, czyli stanu bieżącego (ang. As-Is) fizycznych
danych
pozwala to określić, jaką strukturę posiadają dane w istniejącej bazie danych
oraz jakimi regułami w bieżącym środowisku zarządzania bazą
Dotyczy to zwykle pojedynczej aplikacji lub zbioru tabel w ograniczonym
schemacie takim jak baza danych.
Przykładowo, pełne udokumentowanie zakresu funkcjonowania
przedsiębiorstwa mogłoby wymagać określenia setek takich punktów
widzenia.
 Setek modeli logicznych mogłoby również wymagać opisaniA bardziej
teoretycznych reguł danych, a nie tylko tego, w jaki sposób są implementowane
fizycznie.
 Podobnie wiele modeli koncepcyjnych może wymagać uwzględnienie wszystkich
procesów biznesowych, aczkolwiek próba uwzględnienia wszystkich działań na
poziomie przedsiębiorstwa w ramach pojedynczej perspektywy jest bardziej
prawdopodobna na wyższym poziomie modelu koncepcyjnego niż na innych
etapach.

Modelowanie danych
10

 Model pomaga w zobrazowaniu sposobów zarządzania danymi

obecnie lub w przeszłości.
 Modelowanie danych jest również wykorzystywane w celu
tworzenia nowych projektów — projektów przyszłych (ang. To-Be).
Niekiedy tworzy się kilka projektów przyszłych, zaś zespół programistów
wybiera jeden z nich do implementacji.
 Modelowanie przeprowadza się w celu wypróbowania różnych
możliwości.
Może istnieć wiele rozwiązań nawet podobnych do siebie problemów i nie
zawsze prostą rzeczą jest wybranie najodpowiedniejszego z nich.
 Jednakże bez względu na cel użycia dane, w swojej podstawowej
postaci, muszą być zrozumiałe i należy się z nimi obchodzić w
sposób zdyscyplinowany, jeśli chodzi o kontekst ich cyklu istnienia.
O cyklu istnienia danych, etapach przez które przechodzą dane będzie w
dalszej części wykładów.

5
 17.10.2023

Zastosowania baz danych

11

 Użytkownicy chcą gromadzić ciągle wzrastające ilości danych, a

jednocześnie mieć możliwość manipulowania nimi w celu tworzenia
agregacji, trendów, schematów określania priorytetów, odchyleń oraz
odwzorowań danych na inne istotne informacje o danych (metadane).
 Najpopularniejsze są dwa główne rodzaje baz danych :
Operacyjne bazy danych (OLTP) to takie, które podlegają częstym modyfikacjom,
są one wykorzystywane głównie do przetwarzania transakcji, np. w bankach,
sklepach czy wytwórniach.
 Dane w takiej bazie muszą być zawsze aktualne i poprawne, niezależnie od dynamiki
zmian i operacji w nich rejestrowanych.
Analityczne bazy danych (OLAP) są wykorzystywane w sytuacjach, kiedy jest
potrzeba gromadzenia i śledzenia danych zmieniających się w czasie, np. bazy
danych statystycznych, bazy w laboratoriach chemicznych, agencjach
marketingowych itp.
 Ten typ bazy pomaga prześledzić pewne trendy, przygotować strategie biznesowe itd.
 Przykłady firm, które mogą wykorzystywać analityczne bazy danych: laboratoria
chemiczne, firmy geologiczne oraz agencje marketingowe zajmujące się analizą.

12

 Analityczne bazy danych często wykorzystują dane z baz

operacyjnych jako główne źródło, mogą więc istnieć między nimi
powiązania.
 Operacyjne i analityczne bazy danych spełniają bardzo specyficzne
potrzeby w zakresie przetwarzania danych, a tworzenie ich struktur
wymaga radykalnie odmiennych metodologii projektowych.

6
 17.10.2023

Dlaczego projektowanie baz danych jest ważne?

13

 Podstawowym powodem zainteresowania projektowaniem baz

danych powinien być fakt, że jest ono kluczowe dla zachowania
konsekwencji, integralności oraz dokładności danych w bazie.
 Jeśli baza danych zostanie zaprojektowana nieprawidłowo, trudno
będzie wydobyć z niej określone typy informacji, wzrośnie także
ryzyko uzyskania niedokładnych informacji.
Niedokładne informacje to prawdopodobnie najbardziej szkodliwy rezultat
nieprawidłowego projektowania bazy danych, który może mieć negatywny
wpływ na działanie organizacji.
Jeżeli baza danych ma bezpośrednie przełożenie na sposób przeprowadzania
codziennych operacji w firmie lub jeśli będzie miała wpływ na kierunek
rozwoju firmy w przyszłości, trzeba zainteresować się projektowaniem baz
danych.

Jak zbudować dom na zamówienie?

14

 Na pewno nie zaczniesz od zatrudnienia wykonawcy, który

rozpocznie budowę tak, jak mu się podoba.
 Z pewnością najpierw zaangażujesz architekta do zaprojektowania
nowego domu, a następnie wykonawcę, który go zbuduje.
 Architekt zapozna się z Twoimi potrzebami i wyrazi je w postaci
szkiców, uwzględniając decyzje dotyczące wielkości, kształtu i
wymagania różnych systemów (strukturalnych, mechanicznych,
elektrycznych).
 Następnie wykonawca zapewni siłę roboczą oraz materiały, w tym
te dotyczące systemów, i rozpocznie budowę zgodnie ze szkicami i
specyfikacjami.

7
 17.10.2023

Budowa domu a projektowanie bazy

15

 Wróćmy teraz do baz danych i pomyślmy o logicznym projekcie

bazy w taki sam sposób jak o rysunkach architektonicznych, a o
fizycznej implementacji bazy danych jak o ukończonym domu.
 Logiczny projekt bazy danych opisuje wielkość, kształt i niezbędne
dla bazy systemy, a także odnosi się do potrzeb informacyjnych
oraz operacyjnych firmy.
 Następnym krokiem jest fizyczna implementacja logicznego
projektu bazy danych przy wykorzystaniu systemów SZRBD.
Kiedy już tabele zostaną stworzone, zależności w tabelach ustawione, a
odpowiednie poziomy integralności danych ustalone, baza danych będzie
kompletna.
Teraz jest czas na zaprojektowanie i stworzenie aplikacji, która pozwoli na
prostą interakcję z danymi przechowywanymi w bazie.

Korzyści wynikające z dobrego modelowania

16

 Struktura bazy danych jest prosta do modyfikacji i utrzymania.

Modyfikacje, które wprowadzasz w polu lub tabeli, nie będą miały negatywnego
wpływu na inne pola lub tabele w bazie danych.
 Dane są łatwe do modyfikacji.
Zmiany, które wprowadzasz w wartości danego pola w tabeli, nie będą miały
negatywnego wpływu na inne pola w tabeli.
Co więcej, dobrze zaprojektowana baza danych ogranicza występowanie
duplikatów pól do absolutnego minimum, pozwalając na modyfikację danych
tylko w jednym polu.
 Informacje są łatwe do pozyskania.
Tworzenie kwerend jest łatwiejsze, ponieważ tabele są dobrze skonstruowane, a
zależności między nimi odpowiednio ustalone.
 Aplikacje użytkownika są łatwe do rozwinięcia i budowy.
Masz możliwość spędzenia większej ilości czasu na programowaniu i manipulacji
bieżącymi danymi zamiast na pracy nad likwidacją nieuniknionych problemów,
które pojawiają się, kiedy baza danych jest źle zaprojektowana.

8
 17.10.2023

Modelowanie „w skrócie”
17

 Każdy system informatyczny jest komputerową reprezentacją

jakiegoś fragmentu świata rzeczywistego.
 Należy zatem zbudować taki model świata rzeczywistego, który
łatwo i sensownie da się odzwierciedlić w system informatyczny.
 Budowaniem takich modeli zajmuje się dziedzina wiedzy zwana
modelowaniem.
Modelowanie - odwzorowanie rzeczywistych obiektów świata rzeczywistego
w systemie informatycznym (bazie danych):
 Obiekty materialne
 samochody, budynki, sprzęt komputerowy
 zasoby ludzkie (grupa pracowników)
 Obiekty niematerialne
 wiedza (znajomość technologii)
 zdarzenia (otrzymanie nagrody, urlopu)
 stany rzeczywistości (stan rachunku bankowego, polisa ubezpieczeniowa)

Miejsce modeli w projekcie

18

 Model danych odgrywa podstawową rolę w procesie tworzenia,

ale stanowi tylko jeden z wielu elementów składających się na
projekt systemów informatycznych.
 Modele: koncepcyjny, logiczny i fizyczny łączą się luźno ze sobą i
mogą służyć sobie nawzajem jako różne punkty widzenia
pojedynczego procesu biznesowego.
 Model danych nie oferuje pełnego odzwierciedlenia
wewnętrznego kodu, który należy utworzyć w celu obsługi
aplikacji.
 Model danych nie zawiera wszystkich informacji o nadawanych
uprawnieniach ani kodu łączy bazodanowych.
 Model danych nie ukazuje wymagań dotyczących rozmiaru i
wymaganej przestrzeni (choć część oprogramowania modelowania
danych pozwala uwzględnić te aspekty).
 Model danych stanowi szkic bazy danych, a nie bazę jako taką.

9
 17.10.2023

Rodzaje modeli danych

19

 MD to technika służąca do rejestrowania inwentarza, kształtu, rozmiaru,

zawartości oraz reguł dotyczących elementów danych używanych w
zakresie procesu biznesowego.
Zakres procesu biznesowego może być tak rozległy jak wielobranżowa globalna
korporacja lub tak niewielki jak przyjmowanie kontenerów na nabrzeżu.
Produkt końcowy stanowi niejako mapę uzupełnioną o dokumentację potrzebną
do zinterpretowania go z wystarczającą jasnością.
 Pewne modele są tworzone w celu dokumentowania
wysokopoziomowych idei i określa się je mianem modeli koncepcyjnych
(ang. conceptual).
 Inne są tworzone w celu dokumentowania teoretycznej czystości reguł i
struktur elementów danych i określa się je nazwą modeli logicznych
(ang. logical).
 Być może najlepiej znanym typem modeli danych jest określający
faktyczny projekt bazy danych model fizyczny (ang. Phsical).
Model taki stanowi podstawę kodu pisanego w celu tworzenia tabel, perspektyw
i więzów integralności.

Modele - przykłady
20

 Model konceptualny (bardziej ogólny), model logiczny (bardziej szczegółowy)

reprezentacja obiektów w uniwersalnym modelu niezależnym od modelu
implementacyjnego
np. model związków-encji, model UML
 Model fizyczny (implementacyjny model danych)
modele wykorzystywane do implementacji modeli logicznych
 odzwierciedla on model logiczny w konkretne struktury danych
np.. relacyjne, obiektowe, obiektowo-relacyjne, semistrukturalne itp.)

10
 17.10.2023

Model związków-encji
21

 Model związków-encji (entity-relationship model - ER)

jeden z fundamentalnych modeli konceptualnych, logicznych
wykorzystywany w projektowaniu relacyjnych baz danych
obiekty świata rzeczywistego reprezentowane za pomocą encji (entities)
powiązania między obiektami świata rzeczywistego reprezentowane za
pomocą związków (relationships) pomiędzy encjami
 Notacje modelu
Chen
Barker (wykorzystywana w produktach Oracle) - stosowana na wykładzie

Encja
22

 Encja (ang. entity) w projekcie logicznym to typ obiektu świata

rzeczywistego: materialny (np. czytelnik, książka, samochód) lub
abstrakcyjny (np. zdarzenie, pojęcie), którego opis właściwości będzie
przechowywany w projektowanym systemie.
Każdy element analizowanej rzeczywistości musi być reprezentowany przez jedną
encję — podczas wprowadzania opisu takiego obiektu do gotowego już systemu
nie może być wątpliwości, gdzie zaklasyfikować daną informację.
Stopień uszczegółowienia analizowanej rzeczywistości, a tym samym liczba encji
pozyskanych w trakcie analizy, zależy od przeznaczenia projektowanego systemu.
Encja posiada unikalną nazwę — jest to rzeczownik liczby pojedynczej.
 Encja reprezentuje pewien zbiór wystąpień obiektów tego samego typu (minimum
dwóch), mających takie same właściwości (atrybuty).
 Podczas modelowania danych dowolny obiekt ze świata rzeczywistego jest
reprezentowany jako wystąpienie encji.
 Każde wystąpienie encji (instancja encji) musi być wyraźnie odróżnialne od wszystkich
innych instancji tego typu encji.
 Prawidłowa identyfikacja encji jest jednym z najważniejszych zadań w trakcie
projektowania bazy danych.
Konkretny obiekt świata rzeczywistego jest reprezentowany jako wystąpienie
encji (instancja encji).

11
 17.10.2023

Modelowanie encji
23

 Przykład
Firma zatrudnia pracowników. Chcemy przechowywać informacje nt. danych
personalnych pracowników (imię, nazwisko, adres i numer telefonu).
 Model
Ponieważ wszyscy pracownicy firmy mają takie same cechy, więc encja
będzie posiadała 4 atrybuty: imię, nazwisko, adres, nr_telefonu

Modelowanie encji
24

 Przykład
Parking firmy jest przeznaczony do parkowania wielu różnych samochodów.
Chcemy przechowywać informacje o samochodach (marka, model, numer
rejestracyjny), które mogą parkować na parkingu firmy
 Model
Najważniejszym obiektem modelu w opisie jest samochód opisany marką,
modelem i numerem rejestracyjnym. Każdy samochód będzie więc
reprezentowany za pomocą encji o nazwie Samochód z 3 atrybutami: marka,
model, nr_rejestracyjny.

12
 17.10.2023

Atrybuty
25

 Właściwości encji są opisywane za pomocą atrybutów.

 Liczba atrybutów w opisie encji może być różna — w wypadku
encji zwanych słownikami mogą to być tylko dwa atrybuty.
Mogą jednak wystąpić encje mające bardzo rozbudowany opis sięgający
kilkuset atrybutów, np. encje odpowiadające rozbudowanym raportom.

Każdy atrybut musi mieć:

• unikalną nazwę w ramach jednej encji,
• określoną dziedzinę definiującą typ danych,
maksymalny rozmiar, zbiór dozwolonych
wartości lub zakres wartości,
• informację NULL/NOT NULL określającą, czy
dozwolone lub niedozwolone są wartości
puste, tzn. czy atrybut musi mieć podane
wartości, czy może być pominięty podczas
wprowadzania danych do bazy,
• atrybut może też mieć unikalne wartości.

Atrybut cd.
26

 Atrybut musi spełniać określone zadanie, tzn. identyfikować, opisywać, klasyfikować, określać
ilość lub wyrażać stan encji.
 Atrybuty można podzielić na atrybuty identyfikacyjne i opisowe.
 Identyfikator to atrybut lub zbiór atrybutów jednoznacznie identyfikujący wystąpienie encji.
Mogą być identyfikatory naturalne, pochodzące z rzeczywistości, zweryfikowane już w innych
systemach — np. w opisie pracownika będą to PESEL, NIP, REGON czy nr dowodu osobistego.
Identyfikatorem sztucznym jest atrybut numeryczny dodany do opisu w celu numerowania
kolejnego wystąpienia encji, np. Nr pracownika, Nr katalogowy itp.
 Deskryptor - atrybut opisowy (deskrypcyjny) to każdy atrybut poza identyfikatorem.
Reprezentuje podstawowe własności encji przechowywane w bazie.
Wartości deskryptorów mogą być opcjonalne
lub obowiązkowe.
 W notacji Barkera stosuje się następujące znaki
dla oznaczenia rodzaju atrybutu:
# — oznacza identyfikator, atrybut taki ma unikalne
i obligatoryjne wartości,
* — oznacza atrybut z wartościami obligatoryjnymi,
o — oznacza atrybut z wartościami opcjonalnymi.

13
 17.10.2023

Definicja atrybutu encji

27

 Definicja pojedynczego atrybutu encji obejmuje następujące

elementy
Nazwa
Dziedzina
 typ danych i maksymalny rozmiar
 zbiór dozwolonych wartości
 zakres dozwolonych wartości
Dozwolone / niedozwolone wartości puste
Opcjonalnie -> unikalność wartości

Atrybuty
28

 Przykład
Pracownicy firmy są opisani imieniem i nazwiskiem, numerem PESEL,
adresem zamieszkania, pensją i opcjonalnie numerem telefonu
 Model

Identyfikator encji

Atrybuty z wartościami
obowiązkowymi

Atrybut z wartością opcjonalną

14
 17.10.2023

Atrybuty
29

 Przykład
Pracownicy firmy są opisani imieniem i nazwiskiem, numerem PESEL,
adresem zamieszkania, pensją i opcjonalnie numerem telefonu
 Model

Identyfikator encji

Atrybuty z wartościami
obowiązkowymi

Atrybut z wartością opcjonalną

Uwaga1 - PESEL – dana wrażliwa, teraz jest identyfikatorem, jeżeli tak pozostanie to w bazie relacyjnej
jako klucz główny będzie w zdecydowanej większości 99% zapytań i jako klucz obcy
Uwaga2 – adres, zgodnie z zasadami normalizacji powinien być bardziej szczegółowy; na diagramie
encji może pozostać, jednak później w diagramie relacyjnym powinien być rozbudowany

Typy związków
30

 Związek, zwany asocjacją, reprezentuje powiązania pomiędzy encjami i

modeluje zależności występujące między obiektami świata rzeczywistego.
Wnosi do projektu określone informacje, np. Klient posiada Rachunek, Rachunek należy do
Klienta; studenci otrzymują oceny z egzaminów
 Związek jest przedstawiony graficznie za pomocą linii łączącej encje — i
dodatkowo zawierającej oznaczenia ułatwiające interpretację związku.
Graficzny sposób przedstawienia związku jest różny w zależności od przyjętej notacji, musi
jednak jednoznacznie określać trzy cechy związku: stopień związku, typ związku i jego
istnienie.
 Istnienie (znane również jako klasa przynależności lub uczestnictwo) określa, czy
związek jest opcjonalny, czy obligatoryjny.
Jeśli jest chociaż jedno wystąpienie encji danego typu nie biorące udziału w powiązaniu, to
ta encja jest w związku opcjonalnym.
Jeśli wszystkie wystąpienia encji danego typu muszą brać udział w powiązaniu, to związek
jest obligatoryjny.
W notacji Barkera uczestnictwo opcjonalne jest oznaczone linią przerywaną, uczestnictwo
obligatoryjne — linią ciągłą.

15
 17.10.2023

Typy związków
31

 Stopień związku określa liczbę encji połączonych związkiem.

 Wyróżnia się związki:
unarne (inaczej binarny rekursywny) (łączące encję samą ze sobą),
binarne (łączące dwie encje),
ternarne (łączące trzy encje),
n-arne (łączące n encji).

 Typ związku, zwany licznością związku, określa, ile wystąpień

jednej encji może wchodzić w powiązania z różnymi wystąpieniami
innej encji.
 Wyróżnia się następujące typy związków:
jeden do jeden, oznaczane jako 1:1 (związek jedno-jednoznaczny),
jeden do wielu, oznaczane jako 1:N (związek jednoznaczny),
wiele do wielu, oznaczane jako N:M (związek złożony lub wieloznaczny).

Modelowanie związków
32

 Przykład
Pracownicy firmy posiadają różne samochody. Chcemy przechować
informację na temat faktu posiadania samochodu przez pracownika.

związek

opis związku

16
 17.10.2023

Przykład
33

 Przykład
Pracownicy firmy posiadają samochody. W celu udostępnienia miejsca
parkingowego należy zarejestrować pracownika i jego samochód. Każdy
pracownik ma prawo parkować tylko jeden konkretny samochód. Nie każdy
pracownik ma samochód. Zarejestrowany w rejestrze parkingowym
samochód na pewno jest własnością jednego pracownika.
 Wiemy, że istnieje związek pomiędzy pracownikami a
samochodami i potrafimy to zamodelować, ale ….
 …. z modelu chcielibyśmy wiedzieć:
Ile samochodów może posiadać pracownik?
Ilu pracowników może posiadać ten sam samochód?
Czy każdy samochód musi do kogoś należeć?
Czy każdy pracownik musi posiadać samochód?

Przykład cd.
34

17
 17.10.2023

Przykład cd.
35

Związek Pracownik-Samochód
Typ asocjacji
Stopień związku: binarny
Pracownik (1):Samochód (1)

Związek opcjonalny Związek obowiązkowy

Pracownik może posiadać Samochód musi być własnością

Związek binarny (łączy dwie encje)

Związek opcjonalny od strony pracownika (linia przerywana)
Związek obowiązkowy od strony samochodu (linia ciągła)
Związek 1:1 (1 pracownik posiada 1 samochód)

Związek binarny jeden-do-jeden (1:1)

36

 Przykład
Każdy dział musi mieć kierownika, natomiast pracownik może być
kierownikiem co najwyżej jednego działu.

18
 17.10.2023

Związek binarny typu jeden-do-wiele (1:M)

37

 Przykład
Każdy pracownik pracuje dokładnie w jednym dziale. Dział może zatrudniać
(ale nie koniecznie) wielu pracowników.

Związek binarny 1:M obustronnie obowiązkowy

38

 Przykład
Drużyna piłkarska musi być złożona z zawodników
 nie ma drużyny bez zawodników
Każdy piłkarz należy do dokładnie jednej drużyny
 piłkarz, który nie należy do drużyny (nie gra) nie jest piłkarzem

19
 17.10.2023

Związek binarny 1:M obustronnie obowiązkowy

39

 Przykład
Z każdym rachunkiem bankowym musi być związana historia operacji na nim
 istniejąca operacja została wykonana na konkretnym rachunku
Nie istnieją operacje nie związanych z rachunkiem

Związek binarny typu wiele-do-wiele (M:N)

40

 Przykład
Pracownik może brać udział w jednym lub wielu projektach; może też nie
brać udziału w żadnym projekcie. Każdy projekt realizuje przynajmniej jeden
pracownik.

20
 17.10.2023

Związek binarny M:N obustronnie opcjonalny

41

 Przykład
każdy student może należeć do jednej lub wielu organizacji studenckich
 mogą istnieć studenci nie należący do żadnej organizacji
dana organizacja może zrzeszać jednego lub wielu studentów
 mogą istnieć organizacje, które nie zrzeszają żadnego studenta

Atrybuty związku
42

 Przykład
Związek binarny typu wiele-do-wiele (M:N)
Pracownik może brać udział w jednym lub wielu projektach; może też nie
brać udziału w żadnym projekcie. Każdy projekt realizuje przynajmniej jeden
pracownik. Dla pracowników, którzy biorą udział w projektach należy
zapamiętać ich funkcję, wynagrodzenie oraz daty początku i końca ich udziału
w projekcie.

21
 17.10.2023

Atrybuty związku
43

 Omawiana notacja Barkera umożliwia wiązanie atrybutów ze związkami.

Encja słaba
44

 Innym sposobem zamodelowania powiązania, np. w sytuacji gdyby

notacja nie pozwalała na zamieszczenie atrybutów związków jest
dodatkowa encja pośrednia pomiędzy oryginalnym encjiami.
 Do encji tej dochodzą obowiązkowe związki typu wiele
 Encja słaba (weak entity)
nie posiada swojego identyfikatora
wystąpienia encji mogą istnieć tylko w kontekście wystąpień encji
powiązanych z encją słabą
konkretne wystąpienie encji Realizacja może wystąpić wyłącznie w
kontekście konkretnego pracownika i konkretnego projektu

22
 17.10.2023

Identyfikator encji słabej

45

 Identyfikatorem encji słabej mogą być wszystkie związki, w które wchodzi ta

encja
 Związek wchodzący w skład identyfikatora encji jest oznaczany na diagramie
jako krótka linia prostopadła do związku umieszczona przy końcu związku.
 W przykładzie ze slajdu, w skład identyfikatora encji Realizacja wchodzą związki
z encją Pracownik i Projekt.

Związek binarny rekursywny

46

 Określa powiązanie pomiędzy wystąpieniem encji a innym

wystąpieniem tej samej encji
Tego typu związek modelujący zależności hierarchiczne musi być
opcjonalnym z obu stron. W przeciwnym przypadku, powstałaby hierarchia
nieskończona.
 Przykład: Modelowanie zależności służbowych
Pracownicy posiadają swoich kierowników. Istnieją pracownicy, którzy nie są
kierownikami.

23
 17.10.2023

Związek binarny rekursywny

47

 Modelowanie elementów złożonych

 Przykład
Istnieją podzespoły elementarne, niedekomponowalne i podzespoły złożone.
Podzespół złożony składa się z kolejnych podzespołów. Każdy z kolejnych
podzespołów może być złożony z innych podzespołów. Poziom złożoności
podzespołów nie może być dowolny.

Encja Podzespół jest powiązana sama z sobą

związkiem 1:M opcjonalnym z obu stron.

Związki ternarne
48

 Związek ternarny łączy 3 encje.

 Przykład
Kierowca może otrzymać mandat za popełnione wykroczenie. Mandat jest
wystawiany przez konkretnego policjanta.

24
 17.10.2023

Związki ternarne
49

 W omawianej notacji Barkera związek ternarny jest reprezentowany jako encja

(Mandat)
 Do encji Mandat dochodzą związki obowiązkowe o kardynalności "wiele"
jeśli wystawiono mandat to jest on dla konkretnej osoby, został wystawiony przez
konkretnego policjanta i dotyczy konkretnego wykroczenia

Związki ternarne przykład rozszerzony

50

 Poprzedni przykład, został rozszerzony o atrybuty encji

 Encja mandat posiada swoje atrybuty, tj. kwota i data wystawienia
mandatu.

25
 17.10.2023

Związki wyłączne
51

 Związki wyłączne (exclusive relationships)

konkretne wystąpienie encji może w danym momencie wchodzić tylko w jeden z ze
związków
w notacji Barkera oznacza się jako łuk łączący związki wyłączne
 Przykład
Encja "Rachunek bankowy" wchodzi w związek z encją "Osoba fizyczna" lub "Osoba
prawna".
Oznacza to, że konkretny rachunek może być własnością albo osoby fizycznej albo
osoby prawnej, ale nigdy nie będzie własnością obu tych osób jednocześnie.

Hierarchia encji / generalizacji /specjalizacji

52

 Związek generalizacji
określa, że pewne encje o wspólnym zbiorze atrybutów można uogólnić i
stworzyć encję wyższego poziomu tj. encję generalizacji, , zwaną często
nadencją
Encje niższego poziomu w hierarchii generalizacji to encje specjalizacji, ,
zwane również podencjami
Relacja opisująca związki typu generalizacja/specjalizacja pomiędzy encjami
to hierarchia generalizacji/specjalizacji lub hierarchia encji

26
 17.10.2023

Hierarchia encji
53

 Dziedziczenie atrybutów
 Przykład
Firma zatrudnia pracowników kontraktowych i godzinowych. Wszyscy pracownicy
posiadają pewien zbiór wspólnych atrybutów (PESEL, imię, nazwisko, adres).
Pracownicy kontraktowi i godzinowi posiadają specyficzne dla siebie atrybuty. Dla
pracowników kontraktowych jest to numer kontraktu, a dla pracowników
godzinowych są to: liczba godzin pracy w tygodniu i stawka godzinowa.

Hierarchia encji
54

 Interpretacja
podencje dziedziczą wszystkie atrybuty swojej
nadencji
każde wystąpienie nadencji jest zawsze
wystąpieniem jednej podencji
semantyka związku generalizacji oznacza, że każde
wystąpienie podencji JEST wystąpieniem nadencji
 pracownik kontraktowy JEST pracownikiem
 pracownik godzinowy JEST pracownikiem
identyfikator nadencji jest wspólny dla wszystkich jej
podencji
 podencje nie posiadają swoich identyfikatorów

27
 17.10.2023

Hierarchia encji
55

 Oprócz atrybutów, nadencja może posiadać związki wspólne dla wszystkich jej podencji.
Związek encji KLIENT z encją DYSPONENT dotyczy zarówno klientów osoby fizyczne jak i klientów
osoby prawne.
Podobnie jest w przypadku związku encji RACHUNEK z encją DYSPONENT.
 Podencje mogą wchodzić w związki specyficzne wyłącznie dla siebie.
Związek podencji ROR z encją HIST_OPERACJI jest związkiem specyficznym dla ROR, tj. obowiązuje tylko dla tej
podencji.

Związki niedozwolone
56

 W modelu ER związki przedstawione poniżej nie występują

związek M:N obustronnie obowiązkowy w praktyce nie występuje

związek rekursywny 1:M obustronnie obowiązkowy jest niepoprawny ponieważ

modeluje hierarchię nieskończoną "w górę" i "w dół".
 Gdyby zamodelować hierarchię jednostek organizacyjnych w taki sposób, wówczas każda
jednostka musiałaby mieć jednostkę nadrzędną i podrzędną.
 Każda z jednostek nadrzędnych musiałaby mieć kolejną jednostkę nadrzędną itd.
 Podobnie byłoby w przypadku jednostek podrzędnych.

błędny model hierarchii nieskończonej „w dół”

błędny model hierarchii nieskończonej „w górę”

28
 17.10.2023

Relacyjna baza danych

57

 Model diagramu związków encji można wykorzystać do utworzenia

modelu fizycznego np. relacyjnej bazy danych
 Relacyjna baza danych przechowuje dane w relacjach, które są
przez użytkowników postrzegane jako tabele.
 Każda relacja składa się z:
krotek, zwanych rekordami
atrybutów, zwanych polami.
 Fizyczny układ rekordów lub pól jest zupełnie niematerialny, a
każdy rekord w tabeli jest możliwy do zidentyfikowania poprzez
pole zawierające unikatową wartość.
To są dwie cechy charakterystyczne relacyjnej bazy danych, które pozwalają,
by dane istniały niezależnie od sposobu ich fizycznego przechowywania w
komputerze.

Zalety relacyjnych baz danych

58

 Wbudowana, wielopoziomowa integralność.

Integralność danych jest wbudowana w model:
 na poziomie pola, aby zapewnić dokładność danych;
 na poziomie tabeli, by upewnić się, że rekordy nie są duplikowane oraz by wykryć
brakujące wartości klucza głównego;
 na poziomie zależności, by upewnić się, że zależność pomiędzy dwiema tabelami
jest ważna; na poziomie firmy, by przekonać się, że dane są dokładne w sensie
biznesowym. Temat integralności będzie poruszany w miarę omawiania procesu
projektowego.
 Logiczna i fizyczna niezależność danych od aplikacji baz danych.
Ani zmiany poczynione przez użytkownika na poziomie logicznego projektu
bazy danych, ani też zmiany oprogramowania wprowadzane przez
producenta na poziomie fizycznej implementacji nie wpłyną niekorzystnie na
aplikacje zbudowane w oparciu o bazę danych.

29
 17.10.2023

Zalety relacyjnych baz danych cd.

59

 Gwarantowana konsekwencja i dokładność danych.

Dane są podawane konsekwentnie i dokładnie dzięki wielu poziomom
integralności, które możesz narzucić bazie danych.
Ten temat stanie się jasny w miarę omawiania procesu projektowego.
 Łatwe pozyskiwanie danych.
Dane mogą być pozyskane z konkretnej tabeli lub z dowolnej liczby tabel
powiązanych w bazie danych przy wykorzystaniu komend użytkownika.
To pomaga użytkownikowi przeglądać informacje na wiele różnych sposobów.

Transformacja modelu ERD do RDB

60

 Celem kolejnych slajdów jest omówienie technik transformacji

modelu związków-encji do modelu relacyjnego.
Transformacja modelu ERD jest konieczna, ponieważ jak pamiętamy jest on
modelem abstrakcyjnym niezależnym od implementacji.
Modelem relacyjny jest modelem implementacyjnym baz danych.
Transformacji podlegają wszystkie obiekty modelu ERD, czyli encje z
atrybutami, związki i hierarchie encji.
 Zostaną omówione podstawowe techniki transformacji encji do
modelu relacyjnego, transformacji związków i transformacji
hierarchii encji.

30
 17.10.2023

Pojęcia podstawowe
61

 Schemat bazy danych - zbiór schematów relacji

 Relacja (tabela) - dwu-wymiarowa tablica
kolumny -> atrybuty
wiersze -> krotki, rekordy
 każda krotka reprezentuje wystąpienie encji
 Klucz podstawowy – atrybut lub zbiór atrybutów - wybrany
spośród kluczy potencjalnych
 Klucz obcy – atrybut lub zbiór atrybutów wskazujący na klucz
podstawowy innej relacji (atrybut lub zbiór atrybutów w relacji B,
będący jednocześnie kluczem podstawowym w relacji A)
należy zaznaczyć, że klucz obcy może odnosić się do klucza podstawowego
samej relacji, w której został on zdefiniowany

Reguły transformacji encji

62

Model ER Model relacyjny

Encja relacja
Atrybut encji atrybut relacji
Typ danych atrybutu encji typ danych atrybutu relacji
Identyfikator encji klucz podstawowy relacji
Obowiązkowość atrybutów encji ograniczenie NOT NULL
Opcjonalność atrybutów encji ograniczenie NULL
Pozostałe ograniczenia integr. atrybutów encji ograniczenia integr. atrybutów relacji

Pracownicy (
PESEL PRIMARY KEY,
adres NOT NULL,
pensja NOT NULL,
telefon NULL )

31
 17.10.2023

Reguły transformacji związków

63

Model ER Model relacyjny

Związek binarny 1:1
Związek unarny 1:1
Związek binarny 1:M
Związek binarny M:N
Związek unarny M:N
klucz obcy we wskazanej tabeli
klucz obcy w tej samej tabeli
klucz obcy w tabeli po stronie "wiele"
tabela
tabela

Związek binarny 1:1

64

 Związek binarny 1:1 jednostronnie obowiązkowy transformuje się do klucza

obcego w tabeli po stronie związku obowiązkowego.
 Ograniczenie integralnościowe jest definiowane dla atrybutu klucza obcego.
 Klucz ten nie może przyjmować wartości pustych.

32
 17.10.2023

Związek binarny 1:1

65

 Związek binarny 1:1 obustronnie opcjonalny transformuje się do klucza obcego

w tabeli o mniejszym rozmiarze.
 Ograniczenie integralnościowe jest definiowane dla atrybutu klucza obcego.
 Atrybut ten może przyjmować wartości puste, ponieważ związek jest opcjonalny.

Uwagi
66

Przypadek 1 stosowany niezwykle rzadko. Polega on na umieszczeniu kluczy obcych w obu

tabelach wynikowych.

Przypadek 2
został
omówiony na
poprzednim
slajdzie

Przypadek trzeci polega na umieszczeniu

klucza obcego w tabeli Pracownicy

33
 17.10.2023

Związek binarny 1:M

67

 Klucz obcy jest dodawany do relacji po stronie "wiele" niezależnie

od opcjonalności, czy obowiązkowości tego związku.
1. Ograniczenia integralnościowe referencyjne (tj. definiujące klucz
obcy) są definiowane dla atrybutu reprezentującego klucz obcy.
2. Obowiązkowość związku po stronie "wiele" jest reprezentowana
przez ograniczenie integralnościowe NOT NULL definiowane na
kluczu obcym relacji.
3. Opcjonalność związku po stronie "wiele" jest reprezentowana
przez ograniczenie integralnościowe NULL definiowaną na kluczu
obcym relacji.
4. Opcjonalność lub obowiązkowość związku po stronie "jeden" nie

jest odwzorowywana w modelu relacyjnym.

Przykład (związek 1:M)

68

 Przykład sposobu transformacji binarnego związku 1:M jednostronnie

obowiązkowego.
 Klucz obcy jest dodawany do tabeli Pracownicy (strona "wiele") i wskazuje on na
klucz podstawowy tabeli Działy, czyli IdDziału.
 Klucz obcy IdDziału posiada ograniczenie NOT NULL ponieważ związek jest
obowiązkowy od strony "wiele".

34
 17.10.2023

Związek binarny M:N

69

 Reguły transformacji związku M:N są identyczne zarówno dla

związków jednostronnie obowiązkowych, jak i obustronnie
opcjonalnych.
 Związek M:N jest reprezentowany w modelu relacyjnym poprzez
dodatkową relację.
 Nazwa relacji reprezentującej związek M:N jest złączeniem nazw
relacji powstałych z encji połączonych tym związkiem.
 Relacja dodatkowa zawiera klucze obce wskazujące na klucze
podstawowe relacji powstałych z powiązanych encji.
 Ograniczenia referencyjne są definiowane dla kluczy obcych.
 Klucze obce tworzą klucz podstawowy relacji. W konsekwencji, ich
wartości nigdy nie będą puste.

Przykład
70

 Sposób transformacji binarnego związku M:N jednostronnie obowiązkowego.

 Ze związku powstaje tabela pośrednia o nazwie Pracownicy_Projekty.
Zawiera ona dwa klucze obce.
Jeden wskazuje na klucz podstawowy tabeli Pracownicy, czyli IdPracownika, a drugi - na klucz
podstawowy tabeli Projekty, czyli NrProjektu.
Oba klucze obce stanowią klucz podstawowy tabeli Pracownicy_Projekty.
 Oznacza to, że ich wartości nigdy nie mogą być puste.

35
 17.10.2023

Związek unarny
71

 Związek unarny 1:1 lub 1:M obustronnie opcjonalny transformuje

się do klucza obcego w tej samej tabeli.
 Z encji Pracownik powstaje tabela Pracownicy.
Zawiera ona klucz obcy IdKierownika wskazujący na IdPracownika w tej
samej tabeli.
Należy zwrócić uwagę, że wartość klucza obcego może być pusta ponieważ
związek jest opcjonalny od strony "wiele".

Przykład – związek unarny

72

 W tabeli Osoby powstaje klucz obcy IdWspółmałżonka wskazujący

na IdOsoby w tej samej tabeli.
Ponieważ związek jest opcjonalny, więc klucz obcy może przyjmować
wartości puste.

36
 17.10.2023

Przykład
73

 Związek unarny M:N obustronnie opcjonalny jest transformowany do tabeli pośredniej.

 Z encji Lek powstaje tabela Leki, a związek jest transformowany do tabeli o nazwie
Zastępniki.
 Tabela ta posiada dwa klucze obce (atrybut IdLeku1 i IdLeku2), oba wskazują na klucz
podstawowy tabeli Leki, czyli na atrybut IdLeku.
 Oba klucze obce wchodzą w skład klucza podstawowego tabeli Zastępniki.

Związki ternarne
74

 Związek ternarny transformuje się w sposób identyczny jak związek 1:M.

 Z encji Mandat powstaje tabela Mandaty.
 Zawiera ona 3 klucze obce: IdKierowcy, NrSłużbowy, NrWykroczenia wskazujące
odpwiednio na klucze główne tabel występujących w związku.

Te trzy klucze obce

wchodzą w skład
klucza podstawowego
tabeli Mandaty,
ponieważ
transformowana encja
Mandat była słaba.

37
 17.10.2023

Hierarchia encji
75

 Hierarchię encji do modelu relacyjnego można przetransformować

na 3 sposoby.
Schemat 1: jedna wspólna tabela ze wszystkimi atrybutami i kluczami
obcymi, tj. wspólnymi i specyficznymi dla podencji
Schemat 2:
 dla każdej podencji tworzona osobna tabela ;
 Każda z tabel zawiera atrybuty wspólne i specyficzne dla określonej encji.
Schemat 3:
 dla atrybutów wspólnych tworzona tabela wspólna
 dla każdej podencji tworzona osobna tabela z kluczem i atrybutami specyficznymi
 tabela wspólna i tabele powstałe z podencji powiązane ograniczeniami
referencyjnymi

Transformacja hierarchii generalizacji - schemat 1

76

 Powstała tabela Klienci zawiera wszystkie atrybuty wspólne i wszystkie atrybuty

specyficzne dla wszystkich podencji.
 Atrybuty specyficzne w tabeli mogą przyjmować wartości puste zawsze,
niezależnie od ich definicji w pod-encjach.
 rekord w tabeli klienci opisuje albo klienta fizycznego albo prawnego.
Jeśli rekord opisuje klienta fizycznego, to atrybuty klienta prawnego pozostają puste i
odwrotnie.
Dodatkowo, w tabeli
Klienci jest tworzony
atrybut z wartością
obowiązkową
(KL_TYPE), którego
wartościami mogą
być albo 'F' albo 'P'.
Atrybut ten jest
przydatny przy
wyszukiwaniu
klientów określonego
typu.

38
 17.10.2023

Transformacja hierarchii generalizacji - schemat 2

77

 Z encji OS_FIZYCZNA powstaje tabela OS_FIZYCZNE.

Zawiera ona wszystkie atrybuty wspólne encji Klient i wszystkie atrybuty specyficzne
encji OS_FIZYCZNA.
Opcjonalność/obowiązkowość wartości atrybutów encji przenosi się bezpośrednio na
opcjonalność/obowiązkowość atrybutów tabeli OS_FIZYCZNE.
 W podobny sposób jest transformowana encja OS_PRAWNA.

Transformacja hierarchii generalizacji - schemat 3

78

 Z encji OS_FIZYCZNA powstaje tabela OS_FIZYCZNE, która zawiera wszystkie

atrybuty specyficzne ze swojej encji i atrybut OFI_ID, który jest kluczem
podstawowym tabeli OS_FIZYCZNE.
 Z encji OS_PRAWNA powstaje tabela OS_PRAWNE, która zawiera wszystkie
atrybuty specyficzne ze swojej encji i atrybut OPR_ID, który jest kluczem
podstawowym tabeli OS_PRAWNE.

39
 17.10.2023

CD.
79

 Z atrybutów wspólnych encji Klient powstaje tabela KLIENCI.

 Dodatkowo, tabela ta posiada dwa klucze obce OFI_OFI_ID i OPR_OPR_ID, z
wartościami opcjonalnymi.
Pierwszy z nich wskazuje na klucz podstawowy tabeli OS_FIZYCZNE, a drugi - na klucz
podstawowy tabeli OS_PRAWNE.
Dla danego rekordu w tabeli KLIENCI, tylko jeden klucz obcy może przyjąć wartość, ponieważ
rekord w tabeli KLIENCI opisuje albo osobę prawną albo fizyczną

Transformacja związków wyłącznych - schemat 1

80

 Transformacja związków wyłącznych jest podobna do transformacji związku 1:M.

Z tą tylko różnicą, że klucze obce mogą przyjmować wartości puste.
 Z encji Rachunek bankowy powstaje tabela Rachunki_Bankowe, która posiada
dwa klucze obce, jeden wskazuje na klucz podstawowy tabeli Osoby_Fizyczne, a
drugi - na klucz podstawowy tabeli Osoby_Prawne.
 Oba klucze obce mogą przyjmować wartości puste, pomimo, że związki z których
powstały są obowiązkowe od strony "wiele".
 Dzieje się tak dla tego, że
dany rekord rachunku
bankowego jest albo
związany z osobą fizyczną
albo z osobą prawną, więc
tylko jeden klucz obcy
przyjmie wartość.

40
 17.10.2023

Transformacja związków wyłącznych - schemat 2

81

 Alternatywny sposób różni się on od poprzedniego tym, że w tabeli

Rachunki_Bankowe jest atrybut Właściciel, który może przyjąć wartość klucza
podstawowego rekordu albo z tabeli Osoby_Ficzyzne albo z tabeli
Osoby_Prawne;
dla atrybutu tego zdefiniowanie ograniczenia referencyjnego jest niemożliwe.
 Ponadto, w tabeli Rachunki_Bankowe jest atrybut RodzajWłaściciela, który może
przyjąć jedną z dwóch
wartości 'F' lub 'P'.
Służy on do określania
rodzaju osoby, na którą
wskazuje wartość
atrybutu Właściciel. Oba
atrybuty nie mogą
przyjmować wartości
pustych.

Literatura
82

 Antywzorce języka SQL. Bill Karwin, Helion 2012.

41