Вопрос моделирования реляционных данных - две разные таблицы нуждаются в одних и тех же «под-данных» - PullRequest
0 голосов
/ 21 февраля 2011

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

У меня есть 2 разные таблицы, которые обе должны ссылаться / содержать списки многоугольников (многоугольник фактически представлен в виде внешнего цикла и любого количества внутренних циклов для представления отверстий на поверхности). Каждая из 2 таблиц представляет собой совершенно другой набор атрибутов.

Вот вид модели только с 1 таблицей, ссылающейся на полигоны:

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

Один из способов - добавить еще один внешний ключ в таблицу многоугольников, и один из них будет нулевым, а другой заполнен. Это показано здесь:

Это просто не кажется правильным. Поэтому я подумал о промежуточной таблице, но отношения кажутся скорее объектно-ориентированными, чем реляционными. Это неразумный способ сделать это, иметь или / или на эти внешние ключи? или я мог бы иметь одно поле, являющееся целым числом, и не добавлять к базе данных никаких ограничений на то, что это внешний ключ для другой таблицы, и использовать его для любой таблицы, используемой в это время? С точки зрения запроса мне придется извлечь все точки в каждом из полигонов для строки в table1 или table2.

Итак, один из вариантов, который я придумал, заключался в следующем, но потом я думаю о том, как выполнять запросы, а что-то просто не выглядит правильным:

enter image description here

Я знаю, что для настоящего разработчика моделей данных это будет очевидный вопрос! Этот сайт мне очень понравился, это мой первый вопрос, и я надеюсь, что он имеет смысл! Так есть ли какие-либо предложения о том, как это должно быть смоделировано?

(Хорошо, я пытался опубликовать, но изображения не появлялись. Попытка заставить кого-то опубликовать их для меня)

Ответы [ 2 ]

1 голос
/ 01 марта 2011

Поэтому я принял решение, посоветовавшись с людьми.

Я пошел с 3-й нормальной формой и сделал промежуточные таблицы, чтобы связать поверхности с полигонами, а сетки - с полигонами.Окончательное решение имеет следующие таблицы:

Поверхность (ID первичного ключа)SensorGrid (идентификатор первичного ключа)

Полигон (идентификатор первичного ключа)Точка (идентификатор первичного ключа, внешний ключ PolygonID)

Surface_Polygon (surfaceID, polygonID: составной первичный ключ)SensorGrid_Polygon (sensorGridID, polygonID: составной первичный ключ)

Таким образом, 2 промежуточные таблицы связывают полигоны с тем, находятся ли они в сетке или на поверхности.Я проверю, чтобы убедиться, что дополнительное объединение не слишком сильно влияет на производительность.Это самое чистое решение, и если в будущем производительность действительно нуждается в оптимизации, я рассмотрю возможность создания отдельных таблиц для SurfacePolygon, SurfacePoint, SensorPolygon и SensorPoint и избавлюсь от промежуточных таблиц.

Спасибоза вашу помощь.

0 голосов
/ 21 февраля 2011

Хорошо, я собираюсь нанести удар в этом. Если это действительно 1 к 1 и что данный PolygonwithHoles не может быть одновременно и поверхностью, и сеткой, то я бы использовал ваш последний пример, но я бы опустил таблицу контейнеров, если она полностью избыточна. Эта таблица всегда может быть создана с использованием объединения SQL, если по какой-то причине вы хотите получить все полигоны с отверстиями в виде поверхностей и сеток.

...