Design spørgsmål - best practice

Mit spørgsmål går på hvordan jeg bedst designer min database således at jeg uafhængigt af GUI/input-validerende applikationer kan håndhæve "data-regler" for data i min database.

Jeg vil så vidt muligt undgå at bruge triggers, og primært lade relationer bestemme hvilke data der er "lovlige".

Her er et fiktivt eksempel på min problemstilling:

Jeg har en tabel "Biler" der indeholder stamdata for biler, eksempelvis registreringsnummer og farve. "Biler" indeholder også en fremmednøgle til tabellen "Bilmærker" som indeholder rækker med værdierne "Opel", "Ford" og "Limousine".

Det er i min mini-verden underforstået at en bil har 4 hjul, medmindre bilen er af typen "Limousine", som kan have 4 eller 6 hjul.

Hvis jeg i tabellen "Biler" laver et felt der hedder "AntalHjul" vil det være muligt at have en Ford eller en Opel med 6 hjul.

Hvis jeg laver en ny tabel der er en klon af "Biler" og kalder den "Limousiner", kan jeg tilføje "AntalHjul" feltet til denne tabel alene, og det vil umiddelbart løse mit problem. Men det er jo ikke nogen køn løsning - det vil kræve en ny tabel når der kommer en biltype med 8 hjul o.s.v.

Jeg kan selvfølgelig validere data via triggers og de stored procedures der indsætter/opdaterer data, således at man ikke indsætter typen "Opel" og 6 hjul til samme række, men findes der en måde at løse problemstillingen på rent designmæssigt, således at det også vil fungere for databaser der ikke tilbyder triggers/stored procedures?