Klucz obcy - pytanie Opcje

[Amakesh]

Witam!
Załóżmy, że mamy dwie przykładowe tabele: Klient i Zamówienie. Tabela Klient ma pola: Id, Nazwisko, PESEL, Adres a tabela Zamówienie ma pola: Id, PESEL_klienta, Nazwa towaru, Cena, Metoda płatności. Pola Id są kluczami głównymi w obu tabelach. Czy w tym przypadku pole PESEL może być kluczem obcym w tabeli Zamówienie czy też klucz obcy w jednej tabeli musi koniecznie być kluczem głównym w innej?

[trueblue]

PESEL może być kluczem obcym, choć nie jest głównym w tabeli Klient.
Ale bardziej popularne jest łączenie relacją klucz główny-klucz obcy. W Twoim przypadku powinieneś założyć klucz obcy w tabeli Zamówienie o nazwie Id_Klient, a pozbyć się pola PESEL_klienta.

[SmokAnalog]

Dlaczego w zamówieniach przechowujesz PESEL klienta, a nie jego ID? Nie zgadzam się z @trueblue, że PESEL może być kluczem. Byłby to błąd projektu bazy danych, bo PESEL wbrew pozorom nie jest wartością stałą. Jeśli zdecydujesz się na zmianę płci, otrzymujesz nowy PESEL (serio) A poważniej, PESEL jest prawie-dobrym kluczem, ale mimo wszystko jest to tylko porcja danych. W numerze PESEL mogą zajść błędy. Klucz z definicji powinien być kompletnie transparentny, dlatego lepiej byłoby zmienić strukturę bazy i używać ID klienta. Albo ewentualnie, jeśli PESEL rzeczywiście jest tą porcją danych, która decyduje u Ciebie o unikalności jednostki, jak na przykład naliczanie podatku dla danego numeru PESEL (w co bardzo wątpię), to wtedy lepiej byłoby utworzyć tabelę z PESEL-ami i przypisywać je do użytkowników, a dany PESEL linkować po ID (nie po PESEL-u) do czego trzeba.

[pianta_d]

I do tego dochodzi jeszcze, tak głośno ostatnimi czasy głoszona, kwestia ochrony danych osobowych.
Nr PESEL jest zestawem danych, który jednoznacznie identyfikuje osobę, więc jej przechowywanie podlega pod ustawę o ODO, a od maja RODO, gdzie sankcje za przetwarzanie bez zgody lub nieodpowiednio chronione dane, są znacznie wyższe. Dlatego w tym przypadku masz już dwa argumenty za tym, żeby nie robić z nr PESEL klucza.

[trueblue]

Klucz nie musi być widoczny dla użytkownika zewnętrznego.

[pianta_d]

Tak, masz rację, ale samo posiadanie w bazie tych danych to już przetwarzanie, a o tym mówi ustawa.

[trueblue]

Tak, masz rację, ale samo posiadanie w bazie tych danych to już przetwarzanie, a o tym mówi ustawa.

Co nie ma związku z tym, czy pole jest kluczem czy nie.

[pianta_d]

Absolutnie masz rację, dyskusja czysto akademicka.
Pozdrawiam

[Pyton_000]

Ja nie widzę przeciwskazania żeby PESEL był FK.

Co do argumentu że PESEL może się zmienić to wtedy jest nowy użytkownik z nowym numerem.

Co do tego że FK powinien mapować na PK... dobrze by było ale nie musi, choć to jest dublowanie informacji, poza tym w zależności od wielkości bazy PESEL przez dłuugi czas może być dużo cięższym indeksem (zajmoać więcej miejsca) niż PK.

Reasumując, Może być.