+1 för Matt Fenwick. Jag vill tillägga att du vill vara lite försiktig med dina främmande nyckelbegränsningar. Du har i princip två alternativ, som båda kan se ganska lika ut, beroende på ditt val av primärnycklar.
Alternativ ett är:Glöm den enkla skärningspunkten mellan TEACHER och INSTRUMENT och ersätt den med en komplex skärningspunkt som inkluderar teacher_id , instrument_id och level_id . Alla dessa tre kolumner skulle vara den (sammansatta) primärnyckeln för denna skärningstabell. I det här alternativet har du begränsningar för främmande nyckel definierade på teacher_id och instrument_id (och level_id om detta faktiskt är en främmande nyckel till en LEVEL tabell och inte bara ett heltal eller strängkod).
Alternativ två är:Behåll den enkla skärningspunkten mellan TEACHER och INSTRUMENT (låt oss kalla det TEACHER_INSTRUMENT även om det är fantasilöst) och lägg till en underordnad tabell som definierar de nivåer som kan läras ut. Denna underordnade tabell (låt oss kalla den SKILL ) har ett level_id och en främmande nyckel till TEACHER_INSTRUMENT . Om primärnyckeln för TEACHER_INSTRUMENT är kombinationen av teacher_id och instrument_id sedan SKILL Tabellen kommer att ha samma tre kolumner som i alternativ ett. Vad gör det här alternativet annorlunda? Begränsningen för främmande nyckel från SKILL måste vara till skärningstabellen, inte till TEACHER och INSTRUMENT .
Varför är detta viktigt? Om du väljer alternativ ett, kan du behöva ha lite extra frågelogik för att få ett fullt fyllt rutnät av färdigheter, eftersom det inte finns någon referensintegritetsbegränsning som du kan definiera som säkerställer att alla färdighetsnivåer fylls i för varje lärare/instrumentkombination.
Å andra sidan, om du väljer alternativ två, har du fördelen av separation av bekymmer mellan vem som kan använda vad och hur väl de kan lära ut det.
Vad du vill undvika är att ha en tabell som bara innehåller relationen lärare/instrument och sedan en andra som (oberoende) upprepar den relationen men lägger till detaljnivån för färdighetsnivån. Om du gör det riskerar du att dessa två saker inte är synkroniserade.