Patrząc na buty, masz jeden podmiot:buty. Ma dwa bezpośrednie atrybuty:rozmiar i kolor. Domena każdego z tych atrybutów musi być ściśle określona, co wskazuje dla nich tabele przeglądowe. Istnieją dwa pośrednie atrybuty, cena i ilość, ale są to bardziej atrybuty każdej kombinacji rozmiaru/koloru niż samego buta.
Sugeruje to jedną tabelę encji:Buty; dwie tabele przeglądowe:Rozmiary i Kolory; i jedną tabelę skrzyżowań trójstronnych:Style butów:
create table ShoeStyles(
ShoeID int not null,
SizeID smallint not null,
ColorID char( 1 ) not null,
Price currency,
Qty int not null default 0,
constraint FK_ShoeStyles_Shoe foreign key references Shoes( ID ),
constraint FK_ShoeStyles_Size foreign key references Sizes( ID ),
constraint FK_ShoeStyles_Color foreign key references Colors( ID ),
constraint PK_ShoeStyles primary key( ShoeID, SizeID, ColorID )
);
Na przykład kombinacja („Penny Loafer”, „10 1/2”, „Tan”) będzie miała pod ręką określoną cenę i ilość. Rozmiar 11 Tan będzie miał swoją cenę i ilość, podobnie jak 10 1/2 Burgandy.
Polecam widok, który łączy tabele i prezentuje wyniki w bardziej użytecznej formie, jak pokazano powyżej, a nie powiedzmy (15, 4, 3, 45.00, 175). Wyzwalacze w widoku mogą zezwolić aplikacji na cały dostęp za pośrednictwem widoku, dzięki czemu aplikacja pozostaje niezależna od fizycznego układu danych. Takie widoki są niezwykle potężnym narzędziem, które znacznie zwiększa niezawodność i łatwość konserwacji podstawowych danych i samej aplikacji, ale które są żałośnie niedostatecznie wykorzystywane.
