Co jest nie tak z tą strukturą danych?

Question

Zostałem poproszony o opisanie, co jest nie tak z tą strukturą danych i jak ją ulepszyć.

Oto struktura danych:

Oto co mam do tej pory:

cena

• samochód jest ustawiony tylko wtedy, gdy samochód znajduje się w salonie, byłoby bardziej sensowne jest umieszczenie ceny samochodu w stoliku samochodowym

• Nie ma sensu przechowywać danych NULL w tabeli samochodów, to byłby zakład ter mieć układ podobny do tego:

  

• Tam musi być wielkością pozycji, aby pokazać, jak wiele z tego konkretnego samochodu są w salonie, jak niektóre salony mają wiele takich samych samochodów

Nowy stół, który sporządziłem, wciąż ma powtarzające się dane, które niejasno pamiętam, że nie jest nie, gdy sporządzam strukturę danych, więc myślę, że muszę zrobić trzeci stolik? Naprawdę nie jestem pewien ...

Po prostu potrzebuję trochę pomocy, co jest nie tak z aktualną strukturą danych i jeśli jest jakiś sposób, aby ją poprawić, każda pomoc jest doceniana.

Answer 1

Jednym z problemów jest to, że stolik samochodowy przechowuje dwie różne rzeczy - przechowuje marki i przechowuje modele.

Więc należy podzielić, że się coś jak:

Sprawia: Kolumny makename, makecode

modele: kolumny makecode (klucz obcy dla marek), MODELNAME, modelcode

I teraz showroom stół będzie odnosić się tylko do modeli, więc nie może przez przypadek odwoływać się do marki.

Ponieważ jeden model może mieć wiele wierszy tabeli showroom, które są z nim powiązane, nie można scalić dwóch tabel w sposób znaczący, dlatego należy je oddzielić i przejść od tego miejsca.

Answer 2

Masz rację, że powtarzanie danych jest verboten.

Zmieniłbym "salon wystawowy" na "model", ponieważ mogą występować różne podkategorie modeli. IE Golf TDI vs GTI i takie. ... a cena bazowa (MSRP) miałaby zastosowanie do modelu. Pokaż status pokoju nie ma sensu dla cen - jest wiele reklamowanych, ale nie w showroomie lub na parkingu.

Nie sądzę, że jest jakiś problem z posiadaniem kolumny NULLable, jeśli takie są dane. Wszystko jest w porządku i możesz sprawdzić, kiedy masz przyzwoitą ilość danych, aby zobaczyć, co Ci najbardziej służy. Ale optymalizuj po, a nie wcześniej.

Answer 3

Wygląda na to, że struktura samochodów zawiera zarówno modele samochodów, jak i modele samochodów. To powinno przynajmniej wywołać alarm. Samochód sprawia, że ​​Ford, VW i Peugeot mają swoje własne MakeCode. Modele samochodów, takie jak Fiesta i Golf, mają własne ModelCode.

W oryginalnej struktury, modele samochodów odnoszą się do ich marki przez ParentCarId i powielać Ich MakeCode. Marki samochodów nie są specyficznymi modelami i mają przypisane wartości null dla ich ModelCode i ParentCarId.

Nie ma żadnego sensu, co oznacza, że ​​samochód jest dzieckiem innego? Zamiast tego samochód należy do marki, która jest inną jednostką reprezentowaną przez inną tabelę. Ponadto samochody nie powinny mieć wartości MakeCode, ponieważ jest to atrybut marki, do której należą. Oczywiście modele i modele są bardzo wyraźne i powinny być reprezentowane w różnych tabelach.

Rozsądne byłoby podzielenie tego stołu na dwa: jeden dla marek i jeden dla modeli. Sprawia, że ​​będą miały ID, Name i MakeCode. Modele miałyby ID, , ModelCode i (obcy klucz do ID z Make).