2012-08-02 19 views
6

Ich erstelle eine Datenbank von Studenten in einer school.Here ist, was ich habe, so weit: enter image description hereWie macht man einen zusammengesetzten Schlüssel einzigartig?

Wenn Sie nicht mögen, Sprung zum „Kurz gesagt“ -Teil Lesen

Das Problem ist, dass ich mit diesem Design nicht glücklich bin. Ich möchte, dass die Kombination grade, subgrade und id_class eindeutig ist und als Primärschlüssel für die Studententabelle dient. Ich kann die student_id entfernen und einen zusammengesetzten Schlüssel aus der 3 machen, aber das will ich auch nicht. Vielleicht sollte ich eine andere Tabelle machen, sagen combination_idgrade, subgrade und id_class sind Fremdschlüssel und es gibt eine zusätzliche Spalte comb_id, die als ID für die Tabelle dient. Und alle Spalten werden Primärschlüssel sein. Aber das Problem ist, dass diese 3 Spalten wegen dieser zusätzlichen Spalte immer noch wiederholt werden können (comb_id). Zum Beispiel kann ich die gleichen haben grade, subgrade und class_id, aber verschiedene comb_id, die die Zeile wegen der zusammengesetzten Schlüssel der 4 Spalten der Tabelle (combination_id) gültig machen wird.

Kurz gesagt möchte ich students_id die einzige Primärschlüssel der Tabelle bleiben aber ein Fremdschlüssel an einen anderen Tisch zu sein, die von grades, subgrade und class_id irgendwie einzigartige Kombination ist.

Wenn ich nicht klar genug war, fragen Sie in den Kommentaren unten und danke im Voraus.

PS Ich bin für den indescriptive Titel leid, aber ich bin schlecht

EDIT 1 Benennung: Um mehr klar: grade sein kann 1 bis 12 subgrade sein kann, ein zu j id_class kann 1 bis 30, und es ist Ihre Nummer in der Klasse

So kann ein Student aus 7b Klasse sein und seine Nummer in der Klasse - 5

+0

Ich verstehe nicht, sind alle Schüler in einer Klasse garaunteed verschiedene Qualitäten zu haben? – Jodrell

+0

Was machen Sie, wenn Schüler den Unterricht wechseln, oder passiert das nie? – Jodrell

+0

Was ist falsch an einer Spalte 'student_id'? – Jodrell

Antwort

17

Mischen Sie nicht die Konzepte eindeutige Schlüssel und Primärschlüssel. Sie können sehr gut einen unique key hinzufügen, der die drei Spalten grades, subgrade und class_id überspannt. Auf diese Weise, keine zwei Zeilen could have die gleichen Werte für diese drei Spalten. Während Sie schreiben, dass Sie diese drei nicht als zusammengesetzten Primärschlüssel haben wollen, bin ich mir nicht sicher, ob ein zusammengesetzter eindeutiger Zusatzschlüssel besser wäre. Wenn nicht, müssen Sie klären, wann zusammengesetzte Schlüssel akzeptabel sind.

einen eindeutigen Schlüssel zu erstellen, können Sie die folgende SQL-statement verwenden:

ALTER TABLE students ADD UNIQUE gsc (grades, subgrade, class_id); 

Das Wort gsc es ist nur ein Name, den ich aus den Initialen der Schlüsselspalten besteht; Verwenden Sie den von Ihnen gewünschten Namen, da dies kaum eine Rolle spielt, es sei denn, Sie möchten den Schlüssel in einer Ausgabe von EXPLAIN o.ä. identifizieren.

+0

Danke, ich werde das versuchen und ich habe wahrscheinlich die Leute mit den Namen 'grade',' subgrade' und 'id_class' verwechselt, aber in meinem Land ist das Bildungssystem anders. – Bosak

+0

OK Ich habe das versucht, aber als ich alle 3 Spalten 'UNIQUE' gemacht habe, habe ich einen Fehler für doppelte Einträge bekommen. Ich hatte viele "Grade" 3, aber sie hatten unterschiedliche "Subgrade", also behandelten sie sie als separate "eindeutige" Schlüssel. Auch was ist ergänzend? – Bosak

+0

Machen Sie nicht alle thre Spalten für sich einzigartig, aber zusammen: 'ALTER TABLE Studenten ADD Unique gsc (Noten, Unterstufen, class_id)'. 'gsc' ist nur ein Name, benutze was immer du magst. Dann treten Duplikate nur auf, wenn alle drei gleich sind. Ich habe den Begriff * ergänzend * im Gegensatz zu * primär * verwendet: Ein mit diesem Befehl definierter Schlüssel ist nicht primär, aber immer noch einzigartig. – MvG

2

Ich bin nicht ganz klar, warum Sie wollen, was Sie beschrieben haben, aber ich würde das Modell auf folgende Weise betrachten ...

Sie haben Studenten
- Sie sind getrennte Einheiten, nicht ein Verbund aus anderen Einheiten
- Sie haben ihre eigenen Eigenschaften haben; Name, Geburtsdatum, etc.

Sie haben Klassen
- Dies sind Gruppen von Studenten
- Jedes accademic Jahr die gleiche „Klasse“ verschiedene Schüler darin
hat - sie ihre eigenen Eigenschaften hat auch; Klasse, Planum, etc

Sie haben eine zusätzliche Eigenschaft in Ihrem Modell, das ich normalerweise nicht
verwenden würde - Wenn eine Klasse hat 20 Schüler, von denen jedes mit einer sekundären ID von 1 bis 20 identifiziert wird


Dies würde mich folgende Maßtabellen

Student     Class      Grade    SubGrade 
----------------------- ------------------------ ----------------- ----------------- 
id   INT PK  id   INT PK  id INT PK  id INT PK 
first_name VARCHAR(45) name   VARCHAR(45) name VARCHAR(45) name VARCHAR(45) 
last_name VARCHAR(45) grade_id  INT FK  desc VARCHAR(45) desc VARCHAR(45) 
etc, etc     subgrade_id INT FK  etc, etc   etc, etc 

Die Class Tabelle geben w hätte eine eindeutige Einschränkung auf (grade_id, subgrade_id), so dass nur eine Klasse jemals 7b sein könnte.

Dann müssen Sie die Schüler ihre Klassen beziehen sich eine Faktentabelle mit ...

Class_Membership 
----------------------- 
id    INT PK 
student_id  INT FK 
class_id   INT FK 
academic_year INT 

Wenn ein Schüler immer nur in einer Klasse in jedem Studienjahr sein sollte, würden Sie eine eindeutige Einschränkung setzen auf (student_id, academic_year).

Alternativ können Sie das akademische Jahr in der Class Tisch. Das würde bedeuten, dass Sie dieselbe Klasse für jedes Jahr wiederholen müssten, aber dass in einigen Jahren die Klasse 7g möglicherweise nicht existiert (da es weniger Studenten in diesem Jahr gibt, zum Beispiel).

Ebenso könnten Sie Studenten haben, die Mitte des Jahres von 7b zu 7c wechseln. In diesem Fall könnte die Tabelle Class_Membership ein Feld start_date und möglicherweise ein Feld end_date enthalten.


Nichts davon erzeugt jedoch direkt das id_class Feld (1-20 für eine Klasse mit 20 Schülern). Persönlich hätte ich kein solches Feld, das id Feld aus der Class_Membership Tabelle kann fast die gleiche Funktionalität und wahrscheinlich zusätzliche Funktionalität bieten. Wo es ist jedoch notwendig, können Sie einfach an die Class_Membership Tabelle hinzufügen ...

Class_Membership 
----------------------- 
id    INT PK 
student_id  INT FK 
class_id   INT FK 
academic_year INT 
class_member_id INT 

Dann könnten Sie auch eine eindeutige Einschränkung auf (academic_year, class_id, class_member_id) haben.


Es gibt ziemlich viel Flexibilität hier, je nach Ihren genauen realen Welt-Modell und Ihre speziellen Bedürfnisse.Aber hoffentlich ist dieses Beispiel ein guter Anfang für Sie; Dimensionstabellen, die Entitäten auflisten, und eine Fakttabelle (oder Tabellen), die diese Entitäten zusammenführen und/oder die Entitäten weiter beschreiben.

+1

Während Sie das Schema in der jetzigen Form anfragen, füge ich hier meine Gedanken hinzu. @Bosak, in meinem Verständnis ist das "Subgrade" nur ein Brief, um verschiedene Klassen in der gleichen Klasse zu unterscheiden. Während Klasse und Unterbau eine Klasse identifizieren, ist ein Unterbau an sich nicht wirklich eine Entität. Sie werden sich selten für "alle Klassen mit Subgrad b" interessieren und noch weniger daran interessiert sein, allgemeine Attribute für all diese Klassen zu speichern, oder? In diesem Fall würde ich die SubGrade-Tabelle löschen. – MvG

0
alter table <TableName> add constraint <ConstraintName> unique(<col1>, <col2>) 

Modified the answer due to syntax mistakes. Mentioned above is correct. 
Verwandte Themen