Это продолжение моего предыдущего вопроса о нашем проекте о том, как с экономической точки зрения избежать внедрения кладбища в систему ГИС…
На кладбище мы можем найти
- Обычные могилы: до 2 человек
- Семейные могилы: более 2, некоторые до 20 (сестры из католической общины ...)
- Памятник войны: около 30 человек
- Зона рассеяния пепла: не ограничена, начиная с 100 человек
- Поля с погребальными урнами: до 2 на место
- Стены с погребальными урнами: до 3 в высоту
Итак, каков лучший путь, определяющий:
- каждый человек как объект POINT
- каждая могила как объект POINT, люди являются частью атрибутов
Я бы выбрал для каждого человека в качестве объекта POINT:
- Один простой файл CSV для всех людей.
- Столбцы могут быть, например: FirstName - FamilyName - YearDeceased
- Независимо от количества людей в могиле
- Таким образом, даже ЗОЛА РАССЕЯНИЯ может войти в файл
- В конце концов, необходимо написать код, чтобы добавить к результатам поиска других людей, похороненных в той же могиле.
Осложнения, которые я вижу с каждой могилой как объект POINT:
- Каждому ряду нужны столбцы для максимального количества людей в могиле ...
- Это означает, что многие клетки будут пустыми из-за нескольких могил с большим количеством людей.
- Но что с ЗОНОЙ РАССЕЯНИЯ? 100 человек требуют все дополнительные столбцы в таблице ...
- Разумно иметь все данные в одном файле CSV, но наличие большего количества файлов сильно усложнит ситуацию.
Итак, комментарии приветствуются: человек или могила как объект POINT? Или ничего из этого, и мне нужно сделать это по-другому?
В моем городе 3 года назад у них было бюро, которое делало для них файлы SHP. Мне передали эти файлы, и я заметил, что могилы нарисованы как ПОЛИГОНЫ. Это идет с файлом DBF для «данных могил». Нормальные могилы имеют 4 набора координат, кажется, логика. Но некоторые вещи кажутся мне абсурдными:
- Существует «стена урны» с гексагональной колумбарией, нарисованной в виде набора гексагональных фигур ... Это означает, что каждая фигура имеет 6 наборов координат ...
- В «зоне рассеяния пепла» есть столб с маленькими прямоугольными шильдиками, для каждой шильдики они нарисовали прямоугольный POLYGON с 4 наборами координат… Мне кажется, что использование POLYGONS в этих случаях слишком избыточно в базе данных.
Кроме того, поправьте меня, если я ошибаюсь, используя:
- Для POLYGONS требуются файлы DBF, поэтому редактор DBF (за дополнительную плату)
- ТОЧКИ требуются только файлы CSV, поэтому достаточно EXCEL (без дополнительных затрат)
В большинстве городов данные умерших людей заносятся в файл CSV:
- сделано непосредственно в EXCEL или
- экспортируется из программы на основе DOS, созданной, когда WIN95 был еще рядом ...
Продолжая управлять «данными людей» в одном файле CSV, EXCEL избегает:
- покупка программного обеспечения, которое может редактировать файлы DBF
- беспокоясь об импорте «данных о людях» в файл DBF Кажется, что не всегда можно без проблем импортировать, редактировать и сохранять данные из CSV в файлы DBF и не портить ваши данные. Я читал, что это может иметь место, особенно при работе с ArcGis (ESRI).
Ответы:
Я бы пошел сложным путем: две таблицы в отношении 1: n
Вы можете построить связь между двумя таблицами, чтобы при выборе могилы были выбраны все записи о людях в таблице.
Идея иметь таблицы с полями вроде Person1, Person2 ... ужасна и плоха.
источник
Я бы создал полигон для могилы, так как сама могила является земельным участком и имеет отношение один ко многим для людей; одна могила может иметь ноль (незанятых, доступных или для продажи?) или много людей. Вы также можете использовать точку вместо многоугольника. Полигоны будут делать лучшие презентации для продажи и обслуживания.
источник
Я бы принял предложение DenaliHardtail об использовании полигонов для представления точных размеров графиков. Этот слой может иметь таблицу с Grave_ID, Grave_Type, Grave_Capacity и Grave_Occupancy_Number. Тогда у вас может быть точечный слой с точками, перекрывающими соответствующие могильные полигоны. Столбцы для таблицы точечного слоя могут быть Person-ID, First_Name, Family_Name, Birthdate, Deathdate, Graveowner и Grave_status (Sold, Unoccupied и т. Д.). Затем вы можете включить соответствующий Grave-ID для каждого человека, чтобы вы могли сопоставить персонажа с могилой и позже создать единую таблицу Excel со всей информацией о могиле и отдельном человеке.
источник
Нормализация данных приводит меня к некоторым пропущенным идеям / пунктам. Кроме того, я думаю, что Excel может делать все, что вы хотите для «базы данных», которую вы рассматриваете. Подсказка: используйте листы или несколько файлов и используйте варианты функций поиска. Сохранить в полезные файлы для импорта / поиска из QGIS
Я предполагаю эти дискретные таблицы [или таблицы Excel], чтобы начать ваш набор данных. Каждый лист / файл легко обслуживается начинающими пользователями, если столбцы четко заданы (и заморожены как верхняя строка ...), и новичку напоминают, что идентификаторы уникальны и остаются неизменными после назначения. Листы и колонны:
Для мышления Новичка я не предлагаю вам полностью нормализовать проблемы идентичности и их столбцы в том, как они пересекаются между владельцами и умершими, и это создает ненужные 1-много вспомогательных таблиц без каких-либо иных идентификаторов. Я предполагаю, что 1 к 1 между таблицами заговора и владельца, как компромисс для простоты
Я думаю, что эта обобщенная установка будет решать такие проблемы, как: куча пепла, склепы на стенах, отслеживание владельца / сопровождающего, нескольких погибших на участке и многое другое.
Наконец, не забудьте создать несколько постоянных строк в двух таблицах / листах для владельца и умершего: неизвестный владелец; неизвестный покойник; неизвестный множественный покойник; принадлежит кладбищу; не принадлежит; и т.п.
источник