Подтип и супертип Mysql — моделирование базы данных

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

Бизнес правила:

  • Пользователь зарегистрирован.
  • У пользователя есть одна роль и только одна роль (пользователь, администратор, …).
  • Роль принадлежит многим пользователям (роль по умолчанию для каждого пользователя — пользователь).
  • У пользователя есть одно местоположение и только одно местоположение (местоположение относится к адресу).
  • Местоположение принадлежит многим Пользователям.
  • Пользователь имеет много объектов недвижимости (либо для аренды, либо для продажи).
  • Собственность принадлежит одному Пользователю.
  • Недвижимость принадлежит одному местоположению (местоположение относится к адресу).
  • Файл принадлежит собственности.
  • Свойство имеет много файлов (в основном изображения).

введите здесь описание изображения

Я так много искал в Google, видел некоторые модели баз данных на databaseanswers.org, но я m застрял на типе/функциях собственности, я не могу понять это, я не знаю лучшего решения для этого!! Поскольку каждый тип собственности имеет разные характеристики, например, квартира имеет комнаты, ванные комнаты... но земли нет, для земель мы могли бы сказать, что они находятся в городе или за его пределами. городок…

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

Я был бы признателен, если бы вы могли дать мне несколько советов по моей «маленькой» проблеме.

Должен ли я разделять Тип каждого Недвижимости на свою собственную Сущность (таблицу), например таблицу Квартиры, Таблица Lands, таблица Houses… Таким образом, я могу прикрепить к ним собственные Features.

Или мне нужно объединить их в одну таблицу "Свойства" со всеми Функциями и иметь другую таблицу "Тип", чтобы связать каждое свойство? к его типу (как в сообщениях и категориях).

Или мне нужно создать четыре таблицы "Свойства" "Тип" "Функции" и сводную таблицу "feature_property".

  • Недвижимость относится к одному типу (Квартира, Земля, Дом, …).
  • Тип имеет много свойств.
  • Функция имеет много свойств.
  • Недвижимость имеет множество функций.

mysql database-design subtype supertype class-table-inheritance
person chebaby    schedule 19.12.2016    source источник
comment
Многие похожие вопросы сгруппированы по следующему принципу: class-table-inheritance   -  person Walter Mitty    schedule 19.12.2016

Ответы (1)


arrow_upward
1
arrow_downward

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

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

Тем не менее, мы можем сравнить различные физические подходы:

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

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

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

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

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

person reaanb    schedule 19.12.2016