2013-07-14 17 views
17

Obecnie projektuję strukturę bazy danych dla projektu naszego zespołu. Mam teraz na myśli to pytanie: czy jest możliwe, aby klucz obcy działał jako klucz podstawowy przy innym stole?Czy klucz obcy może działać jako klucz podstawowy?

Oto niektóre z tabelami projektowania baz danych naszego systemu:

user_accounts 
students 
guidance_counselors 

Chciałem zdarzyć się, że tabela user_accounts powinien zawierać identyfikatory (podobno logowania poświadczeń do systemu) i haseł zarówno użytkownicy studentów i doradcy zawodowi. W skrócie, klucze podstawowe obu tabel: students i guidance_counselors są również kluczami obcymi z tabeli user_accounts. Ale nie jestem pewien, czy jest to dozwolone.

Inną kwestią jest: student_rec tabela istnieje również, co wymaga student_number (który jest user_id w tabeli user_accounts) i guidance_counsellor_id (który jest również user_id w user_accounts) do każdego z jego zapisu. Jeśli oba identyfikatory ucznia i doradcy zawodowego pochodzą z user_accounts table, jak zaprojektowałbym tabelę student_rec? I na przyszłość, jak ręcznie napisać to jako kod SQL?

To mnie wkurzyło i nie mogę znaleźć żadnej konkretnej ani pewnej odpowiedzi na moje pytania.

+1

Podczas gdy odpowiedź na twoje pytanie brzmi "tak, klucz podstawowy może również działać jako klucz obcy", moim zaleceniem byłoby uniknięcie tego. Ta sama relacja może być wyrażona za pomocą dyskretnych kluczy podstawowych i kluczy obcych, a przeciążenie kolumny z wieloma obowiązkami może spowodować trudności na drodze. Na przykład, jeśli klucz podstawowy jest również kolumną tożsamości lub jest automatycznie przypisywany za pomocą strategii GuidComb przez ORM, prawdopodobnie będziesz szukał dwóch lub więcej transakcji zamiast jednego. Zasada pojedynczej odpowiedzialności jest również dobra dla projektowania baz danych. –

Odpowiedz

21

Oczywiście. Jest to powszechna technika znana jako tabele supertyping. Podobnie jak w twoim przykładzie, idea polega na tym, że jedna tabela zawiera nadzbiór jednostek i ma wspólne atrybuty opisujące jednostkę ogólną, a inne tabele zawierają podzbiory tych jednostek o określonych atrybutach. Nie różni się niczym od prostej hierarchii klas w projektowaniu obiektowym.

Dla twojego drugiego pytania, jedna tabela może mieć dwie kolumny, które są oddzielnymi kluczami obcymi do tej samej drugiej tabeli. Gdy baza danych tworzy zapytanie, łączy się z nią dwukrotnie. Aby zilustrować w zapytaniu SQL (nie mam pewności co do składni MySQL, nie używałem go od dłuższego czasu, więc jest to składnia MS SQL), dałbyś tej tabeli dwa różne aliasy przy wybieraniu danych. Coś takiego:

SELECT 
    student_accounts.name AS student_name, 
    counselor_accounts.name AS counselor_name 
FROM 
    student_rec 
    INNER JOIN user_accounts AS student_accounts 
     ON student_rec.student_number = student_accounts.user_id 
    INNER JOIN user_accounts AS counselor_accounts 
     ON student_rec.guidance_counselor_id = counselor_accounts.user_id 

ten zasadniczo bierze tabelę student_rec i łączy ją z tabelą user_accounts dwa razy, raz w każdej kolumnie, i przypisuje dwa różne aliasy gdy łącząc je tak, aby odróżnić je od siebie.

+0

To tylko jedna sytuacja, w której zestaw kolumn to zarówno FK, jak i PK. Każdy rodzaj klucza jest definiowany niezależnie od drugiego. – philipxy

2

Tak, nie powinno być problemu. Klucze obce i klucze podstawowe są wzajemnie ortogonalne, więc kolumna lub zestaw kolumn może być jednocześnie kluczem podstawowym dla tej tabeli (co wymaga, aby były unikatowe), a także być powiązane z kluczem głównym/unikalnym ograniczeniem. w innej tabeli.