Kilka klucz głównych ?

Mam problem z połączeniem tabel, w jednej przydałyby mi się dwa klucze główne (a nie jeden podwójny).

create table Pracownicy
(
ID int identity,
Nazwisko varchar(50) NOT NULL,
Imię varchar(25) NOT NULL,
Stanowisko varchar(25) NOT NULL,
Specjalizacja varchar(50),
Oddział varchar(40),
PESEL char(11) NOT NULL CHECK (PESEL like '[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]'),
[Nr pozwolenia] char(7) CHECK ([Nr pozwolenia] LIKE '[0-9][0-9][0-9][0-9][0-9][0-9][0-9]'),
Adres varchar(50) NOT NULL,
Miasto varchar(50) NOT NULL,
[Kod pocztowy] char(6) NOT NULL CHECK ([Kod pocztowy] LIKE '[0-9][0-9]-[0-9][0-9][0-9]'),
primary key (PESEL,[Nr pozwolenia])
)

W ostatniej linijce zrobiłam chyba jeden podwójny klucz, a nie o to mi chodzi. Mianowicie, "nr pozwolenia" powinien być kluczem głównym, bo w tabeli Recepty chcę się do niego odwoływać. Dodatkowo PESEL również powinien być kluczem głównym, bo jest wykorzystywany w innych tabelach. Jak mam to pogodzić? Przy stworzeniu jednego klucza z dwóch kolumn, nie mogę potem np. w tabeli Recepty odwoływać się TYLKO do kolumny "Nr pozwolenia", bo sama w sobie ta kolumna nie ma klucza, tylko w połączeniu z PESELem ;/

klucz główny MUSI JEDNOZNACZNIE identyfikować krotkę, koniec i kropka. Jeśli coś nie identyfikuje każdej krotki to nie może być PK.

BTW dlaczego w receptury nie możesz mieć FK na pesel??

Mi sie zdaje, ze autorka myli pojecie klucza glownego z kluczem obcym.

johny_bravo napisał(a)

Mi sie zdaje, ze autorka myli pojecie klucza glownego z kluczem obcym.

ee, no chyba nie? ;p

chodziło mi o to:
Pracownicy: PESEL (PK), Nr pozwolenia (PK)
Recepty: Nr pozwolenia (FK) odwolujacy sie do pracownikow
Inne tabele: PESEL (FK) odwolujacy sie tez do pracownikow

po prostu receptę może wystawić tylko lekarz, więc nie chcę się odwoływać do PESELu, bo PESEL mają też inni pracownicy i takim sposobem pielęgniarka mogłaby wystawić receptę, bo też ma PESEL ;p dlatego chciałam na recepcie stosować Nr pozwolenia. a w innych tabelach inni pracownicy mieliby połączenie przez PESEL.

Jednak to ID powinno byc kluczem glownym, bo jest unikalne. Ani PESEL, ani nr pozwolenia nie powinny nim byc bo sa potencjalnie nieunikalne - nie sa zalezne od Ciebie, wiec nie mozesz sie opierac na obietnicy unikalnosci. Recepty i inne tabele powinny sie odnosic do ID pracownika, a to logika biznesowa (na poziomie aplikacji czy bazy danych, jak wolisz) powinna sprawdzac czy dany pracownik moze wystawic recepte.

Można też zrobić tabelę Lekarz, wiążącą Pracownika z numerem pozwolenia i to ta tabela byłaby połączona z Recepta.

dzięki za pomoc :) faktycznie, zrobię tak, że już sam program będzie sprawdzał, czy recepta jest wystawiona na pewno przez kogoś z pozwoleniem, a kluczem mimo wszystko zostawię PESEL, bo przecież też jest unikalny tak jak ID ;)

miłego dnia Wszystkim ;)

PESEL jest unikalny, ale co zrobisz jeżeli osoba wprowadzająca dane wpisała błędny PESEL (np. 66121101234) a teraz trzeba dopisać osobę, która właśnie taki PESEL ma? Baza nie pozwoli, wpierw trzeba omyłkowy poprawić, a to może być kłopotliwe.

PESEL powinien byc unikalny, ale byly juz przypadki, ze nie byl. Pomijajac juz takie bledy jak wskazal bo. Generalnie nie powinno sie wymagac unikalnosci, ktorej nie mozesz zagwarantowac sama.

ok, to niech już będzie to ID kluczem głównym :) może faktycznie mniej kłopotów przez to będzie..

Pracowałem ponad 2 lata w urzędzie miejskim... nauczyłem się, że pesel w praktyce bywa nie unikalny :)

Jeżeli zapewnienie unikalności jakiejś wartości nie zależy od Ciebie to załóż, że nie jest unikalna...