Внедрение обобщений на этапе логического проектирования базы данных?

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

В моей концептуальной модели у меня есть объект, известный как «Автомобиль», который клиент заказывает, а складская система отслеживает. Этот супертип имеет два подтипа «Автомобиль» и «Мотоцикл». Пользователь может заказать один или другой или даже оба.

Теперь, когда я нахожусь на этапе логического проектирования, мне нужно знать, как я могу сделать так, чтобы система позволяла использовать два разных типа продуктов. У меня проблема в том, что если я помещу каждый из отдельных атрибутов объектов в одно и то же отношение, то у меня будут столбцы, которые бесполезны для некоторых объектов.

Например, если у меня просто есть общая таблица, содержащая как «Автомобили», так и «Мотоциклы», которые я называю «Транспортные средства» и все их атрибуты, автомобилям не потребуются некоторые атрибуты мотоциклов, а мотоциклу не потребуются все атрибуты. атрибуты автомобиля.

Есть ли способ решить эту проблему?


database relational-database database-design normalization redundancy
person Mike Smith    schedule 14.08.2011    source источник
comment
возможный дубликат Что-то вроде наследования в дизайне базы данных   -  person Merlyn Morgan-Graham    schedule 14.08.2011

Ответы (1)


arrow_upward
3
arrow_downward

При принятии решения необходимо будет руководствоваться объемом передаваемой информации. Я бы начал с определения всех атрибутов и правил, касающихся их.

Если большая часть информации является общей, вы можете не разделить ее на несколько таблиц. С другой стороны, вы всегда можете разделить таблицы, а затем объединить их в представление для простоты использования.

Например, у вас может быть таблица транспортных средств только с общей информацией, а затем таблица автомобилей с внешним ключом к таблице транспортных средств и таблица мотоциклов с внешним ключом к таблице транспортных средств. Существует определенная трудность в том, чтобы убедиться, что у вас нет ряда автомобилей И мотоциклов, относящихся к одному и тому же транспортному средству, и поэтому есть другие возможности смягчить это - но все это не нужно, если большая часть информации является общей, вы просто иметь неиспользуемые столбцы в одной таблице транспортных средств. Вы даже можете применить ограничения, чтобы гарантировать, что столбцы имеют значение NULL для типов, где они не должны быть заполнены.

person Cade Roux    schedule 14.08.2011
comment
Согласованный. Чистый подход состоит в том, чтобы использовать таблицу VEHICLE для всех общих атрибутов, а также атрибут разделения и таблицы MOTORCAR и MOTORCYCLE для отдельных атрибутов. У вас также могут быть представления (MOTORCAR_VIEW и MOTORCYCLE_VIEW?), которые объединяют супертип и подтипы, чтобы дать вам полную картину любого экземпляра того или иного типа. Вы также можете смоделировать ее таким же образом как свою концептуальную модель, но свести ее к одной таблице в вашей физической модели. Использование ограничений, определяемых вашим атрибутом секционирования, сохранит чистоту ваших физических таблиц. - person Joel Brown; 14.08.2011