Вторая идея (создать логический атрибут для выбора) имеет много преимуществ :
(Я) он четко документирует, что должно быть помечено,
(ii) он такой же постоянный и переносимый, как и базовый набор данных,
(iii) он предоставляет простой и прямой механизм для определения того, какие ярлыки появятся (который даже переносится в другую ГИС или пакет печати),
(iv) он даже поддается анализу в случае возникновения вопросов о взаимосвязи между этим выбором меток и любыми другими переменными, и
(v) экономно кодируя выбор клиента, он не создает дублирующую информацию.
Здесь есть некоторые общие принципы построения базы данных и принципы управления , как мудро предложено в этом вопросе. Одним из них является то, что любая связная часть информации должна быть уникально представлена в базе данных, если это возможно. (Разумеется, информация, используемая в качестве ключей для реализации объединений и связей, должна появляться в нескольких местах в силу своей функции идентификации соответствующих записей в разных таблицах.) Для этого принципа есть веские причины, так как любой, кто пытался поддерживать ненормализованный Реляционная база данных может засвидетельствовать: если вы не помните, чтобы постоянно обновляли, удаляли или добавляли эту информацию к каждому В таблице, в которой она появляется, ваша база данных вскоре становится внутренне непоследовательной: она повреждена, часто безвозвратно.
Другой принцип заключается в том, что в хорошем дизайне реляционной базы данных каждая таблица должна представлять одну концептуальную «сущность» : нечто, что моделируют данные, или взаимосвязь между этими вещами. Когда клиент указывает, казалось бы, произвольный выбор функций, он фактически указывает подмножество строк в таблице. Математически, по аксиоме разделения это то же самое, что помечать их логическим полем. Таким образом, любое значимое «произвольное» подмножество вещей в базе данных может быть представлено логическим полем, и, наоборот, такое поле является хорошим способом хранения произвольных подмножеств (или выборов).
Еще один принцип заключается в том, что вы предпочитаете использовать базовые возможности управления данными ГИС для хранения информации . Альтернатива какая-то специальнаяметод, основанный на способности ГИС хранить информацию в своих «файлах проекта» или каким-либо другим независимым способом. Типичным примером этого является практика ручного выбора и размещения нужных ярлыков. Часто это быстро и легко сделать. Проблемы возникают всякий раз, когда требуется изменение или работа должна быть воспроизведена; та или другая из этих ситуаций практически неизбежна. Ручное размещение меток равносильно хранению информации (а именно, какое подмножество признаков должно быть помечено) вне СУРБД в чрезвычайно эллиптической форме. А именно, выбор определяется только тем, какие ярлыки появляются, а какие нет. Подумайте, как бы вы могли решить следующие проблемы:
Клиент хочет, чтобы одинаковые метки появлялись на связанной, но другой карте, являющейся частью другого проекта.
Возникает вопрос, связаны ли метки с каким-либо другим атрибутом.
После внесения нескольких изменений в ярлыки с течением времени вас попросят вернуться к исходной версии.
В этих случаях работа по решению проблемы может быть огромной: вам нужно заново повторить маркировку, или выполнить ручную перекрестную проверку таблиц базы данных, или найти и восстановить старый заархивированный файл проекта. Если бы вместо этого метки были представлены логическим полем в базе данных, работа была бы почти тривиальной.
