Моделирование данных: год выпуска, марка и модель автомобиля? - PullRequest
0 голосов
/ 31 марта 2011

Я пытаюсь моделировать автомобили на базовом уровне.Вот как я вижу данные:

  • "Год" (например, 2010, 2011) имеет 0 или более "make" (например, Nissan, Honda)
  • "Make" имеет0 или более «моделей» (например, в Nissan есть Sentra, Altima, Maxima)

Не имеет смысла иметь таблицу «year», содержащую всего 1 столбец, поэтому я думаю, что она будет объединенас помощью "make" для создания:

TABLE: year_make
- year
- make

Я думаю, что столбцы "year" и "make" составят составной ключ.

Тогда у меня будет таблица "model", котораякак-то связано с таблицей year_make.Проблема в том, что я не знаю, что в "year_make" вставить в "модель", чтобы связать две таблицы.

Я делаю PK: year_make-> year_make_id и использую это?Это означало бы, что столбцы year и make больше не составляют составной ключ, верно?

ОБНОВЛЕНИЕ:

Полагаю, у меня должна быть таблица поиска "lookup_make ", тогда" year_make "будет иметь столбец" lookup_make_id "вместо" make ".

UPDATE 2:

Perate c:

TABLE: make
 - make_id
 - name

TABLE: model
 - model_id
 - make_id
 - name

TABLE: model_year
 - model_id
 - year  

Ответы [ 5 ]

4 голосов
/ 31 марта 2011

Я думаю, что вы будете лучше подготовлены к дизайну, если создадите несколько образцов данных.Цель состоит в том, чтобы получить репрезентативные выборочные данные.Вы можете многому научиться у репрезентативных образцов данных.(И вы можете сделать несколько довольно дорогих ошибок, если ваши данные выборки не являются репрезентативными.)

Year  Make    Model    ??  ?????
--
2011  Honda   Accord   LX  Sedan
2011  Honda   Accord   SE  Sedan
2011  Honda   Accord   EX  Coupe
2011  Toyota  Yaris        3-door liftback
2011  Toyota  Yaris        Sedan
2011  Toyota  Yaris        5-door liftback
2011  Lexus   IS 350       Sedan
2011  Lexus   IS 250       Sedan
  • Как называть?столбцы?
  • Являются ли "Yaris" и "IS 350" в одном столбце?
  • Имеют ли "IS" и "350" два разных столбца?
  • ЧтоВы делаете со столбцами, которые не применимы ко всем моделям?

Не поддавайтесь искушению бросить несколько идентификаторов в такие данные.Сначала определите ключи и функциональные зависимости.Нормализовать на основе ключей и зависимостей.

0 голосов
/ 01 апреля 2011

Посмотрев еще немного, я думаю, что вы правы, чтобы смоделировать год как присоединение многих ко многим.Я привел оба способа, просто чтобы показать в качестве примеров того, о чем я говорю.Если у вас есть атрибут, охватывающий всю модель в течение многих лет, например, класс автомобиля (эконом, грузовик, люкс и т. Д.), Вам потребуется таблица «многие ко многим» для нормализации и во избежание дублирования данных.

    -- id did not use auto-incs as I am just showing the relational model

    create table make(
            makename        varchar                         primary key
    );
    -- 1.  many to many
    create table model(
            modelname       varchar not null,
            makename        varchar not null        references make(makename),
            -- if carclass changes - one update changes every model/year combo
            carclass        varchar not null -- economy, suv, truck etc ...
            primary key (makename, modelname)
    );

    create table model_year(
            year            integer not null,
            modelname       varchar not null        references model(modelname)
            baseprice       integer not null
            primary key (year, modelname)
    );
    -- 2. year /w/ model
    create table model(
            modelname       varchar not null,
            makename        varchar not null        references make(makename),
            year            integer not null,
            -- update anomaly - you would have to update every model/year combo
            carclass        varchar -- economy, suv, truck etc ...
            -- baseprice is OK since it is tied to the year 
            baseprice       integer not null
            primary key (makename, modelname, year)
    );

... Таким образом, # 1 будет более «правильным» и надежным способом, особенно если вы планируете хранить атрибуты в модели, которые не зависят от того, в каком году она была сделана.В любом случае вы получите те же запросы.На самом деле, труднее / больше работать (не совсем после того, как вы его понизили), чтобы присоединиться к таблицам нормализованной таблицы, чем ненормализованной.Но это не главное.Вы помещаете в БД, потому что хотите, чтобы ваши данные были правильными (я надеюсь).

Примечание: это первичные ключи real , даже если вы используете первичные ключи auto-inc.Вы хотели бы изменить первичные ключи на уникальные, чтобы обеспечить согласованность данных и изменить ссылочные внешние ключи на целые.

0 голосов
/ 31 марта 2011

До сих пор выглядит хорошо, как ваше мышление. Однако в таблице автомобилей, если вам нужно ввести Camry 2001, camry 2002 canry 2003, camree 2004. Похоже, что у вас будут избыточные данные вместе с риском целостности данных с ошибкой. IMO, вам также понадобится некоторый вид Entity с makeID и modelID, с modelID он вводится только один раз или модель просто вводится один раз в таблицу. 'Camry' всегда будет 'Camry', представленной с помощью ID модели.

0 голосов
/ 31 марта 2011

ИМО, я бы не стал составлять таблицу на годы. Выполнение SQL в целочисленном столбце (например, в году) невероятно быстро, особенно при наличии правильных индексов. Гораздо быстрее, чем объединение.

Тем не менее, я вижу преимущество в том, чтобы иметь отдельную таблицу для Make и делать соединение на ее основе. Таким образом, вы сможете ввести данные о производителе, такие как история, годы производства, веб-сайт и т. Д.

Так что я бы сделал:

Manufacturers: (or Makes)
  - id
  - name
  - website
  - country

Cars:
  - manufacturer_id (or make_id)
  - model
  - year
  - doors
  - trim_class
0 голосов
/ 31 марта 2011

Если я правильно вас понимаю, вам нужно создать одну make таблицу и одну model таблицу. Таблица model будет иметь столбцы для id, make_id, name, year.

Очевидно, что make_id будет внешним ключом, указывающим на таблицу make.

Это действительно зависит от вашей ситуации и от того, сколько вам потребуется для нормализации ваших данных.

...