-
Om modellerna inte delar färggrupper så skulle designen vara en tabell:
model [model] comes in color [color]
-
Om modeller delar färggrupper så har två tabeller:
model [model] comes in the colors of group [group] group [group] has color [color]
Dessa tabeller förenas med projektion till den första tabellen:
SELECT model, color FROM model_group NATURAL JOIN group_color
-
Om en modell kan ha exceptionella tillgängliga och/eller otillgängliga färger utöver eller istället för en grupp, ha undantagstabeller. En tabells grupp är nu dess standard färger (om några):
model [model] has default color group [group] group [group] has color [color] model [model] is exceptionally available in color [color] model [model] is exceptionally unavailable in color [color]
Undantagstabellerna är sedan UNIONerade med respektive MINUSerade/EXCEPTerade från ett JOIN-plus-PROJECT/SELECT för att ge den första tabellen:
SELECT group, color FROM model_default NATURAL JOIN group_colour EXCEPT SELECT * FROM model_unavailable UNION SELECT * FROM model_available
"Redundans" handlar inte om värden som visas på flera ställen. Det handlar om flera rader som anger samma sak om applikationen.
Varje tabell (och frågeuttryck) har en associerad fill-in-the-(named-)blanks-satsmall (alias predikat). De rader som gör ett sant uttalande går i tabellen. Om du har två oberoende predikat behöver du två tabeller. De relevanta värdena finns i raderna för var och en.
Re rader som gör uttalanden om applikationen ser detta. (Och sök i mina andra svar om en tabells "påstående" eller "kriterium".) Normalisering hjälper eftersom den ersätter tabeller vars rader anger saker av formen "... OCH ..." med andra tabeller som anger "... " separat. Se detta och det här.
Om du delar grupper och bara använder en enskild tabell med två kolumner för modell och färg är dess predikat:
FOR SOME group
model [model] comes in the colors of group [group]
AND group [group] has color [color]
Så den andra kulan tar bort ett enda "AND" från detta predikat, dvs källan till ett "multivalued dependency". Annars om du ändrar en modells grupp eller en grupps färger måste du samtidigt ändra flera rader. (Poängen är att minska fel och komplexitet från redundans, inte spara utrymme.)
Om du inte vill upprepa strängarna av implementeringsskäl (beroende) (uttaget utrymme eller operationshastighet på bekostnad av fler kopplingar) lägg sedan till en tabell med namn-ID och strängar och ersätt dina gamla namnkolumner och -värden med id-kolumner och -värden. (Det är inte normalisering, det komplicerar ditt schema för implementeringsberoende dataoptimeringsavvägningar. Och du bör demonstrera detta behövs och fungerar.)