Базы данных (Проектирование реестра недвижимости)

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

Перечень находящихся в распоряжении органов государственной власти и органов местного самоуправления сведений, подлежащих представлению с использованием координат, утвержден РП РФ №232-р от 09.02.2017, например:

• места нахождения остановочных пунктов общественного транспорта (наименование межмуниципального маршрута, вид транспорта, номер маршрута);
• места нахождения многофункциональных центров предоставления государственных и муниципальных услуг (наименование, режим работы).

В октябре 2023 года представлен на обсуждение проект нового перечня.

В соответствии с Приказом Минэкономразвития России от 29.03.2017 №142 пространственные метаданные формируются в электронном виде в виде файлов в формате XML и содержат информацию:

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

Есть разные способы обеспечения уникальности идентификаторов:

• на основе счетчика (порядкового номера записи):
  • общая сквозная нумерация. Если номера присваивают несколько органов независимо, то во избежание коллизий им могут выделяться диапазоны допустимых значений;
  • составной ключ, например «Порядковый номер здания + Порядковый номер помещения в здании»;
• на основе местоположения, например:
  • URL;
  • кадастровый номер;
• статистически, например:
  • UUID;
• с указанием данных, например:
  • Snowflake ID (метка времени + ID машины + порядковый номер для этой метки и машины);
• с хэшированием, например:
  • urn:sha1:3I42H3S6NNFQ2MSVX7XZKYAYSCX5QBYJ

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

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

Одним из первых языков разметки был SGML, предназначавшийся для машинной обработки документов в правительственных проектах США. На его основе позже были созданы языки HTML и XML.

Язык HTML сегодня используется как основа для построения веб-страниц. Он завоевал свою популярность благодаря простоте — в первой версии было всего 18 тегов. Современная версия, которая называется HTML5, поддерживает разнообразные интерактивные и мультимедиа-технологии.

В отличие от HTML, теги XML не предопределены. XML разрешает создавать любые теги, какие необходимы разработчику, поэтому он и называется «расширяемый» (eXtensible Markup Language). 

Рассмотрим пример xml-документа (см. рисунок). Первая строка — это XML декларация (пролог). Здесь определяется версия XML (1.0). Он необязателен, но если он есть, то это должна быть первая строка XML документа. На следующей строке описывается корневой элемент документа: <MP>. Следующие строки описывают дочерние элементы корневого элемента. И, наконец, последняя строка определяет конец корневого элемента: </MP>.

В XML документе могут присутствовать международные символы, вроде русских букв, и чтобы не возникало ошибок необходимо указать кодировку, либо сохранить XML файл в формате UTF-8 — это кодировка XML документов по-умолчанию.

XML документ должен содержать корневой элемент. Этот элемент является родительским для всех других элементов. Таким образом все элементы в XML документе формируют иерархическое дерево. Это дерево начинается с корневого элемента и разветвляется на более низкие уровни элементов.

Все элементы могут иметь подэлементы (дочерние элементы). Для описания взаимоотношений между элементами обычно используют термины «родитель» (parent), «потомок» и «брат/сестра». У родительского элемента есть потомки или дочерние элементы (child). Потомки на одном и том же уровне называются братья или сестры (siblings).

В отличие от HTML, где некоторые теги могут быть одинарными (<br> — перевод строки, <img> — рисунок), в XML нельзя опускать закрывающий тег. Но при написании элементов без контента можно использовать альтернативный краткий синтаксис: вместо <OldNumber></OldNumber> можно написать <OldNumber />

XML элементы должны следовать следующим правилам написания имен:

• имена могут содержать буквы, числа и другие символы;
• имена не могут начинаться с цифры или символа пунктуации;
• имена не могут начинаться с сочетания «xml» (или XML, или Xml и т.п.);
• имена не могут содержать пробельные символы.

Рекомендуется не использовать в названиях нелатинские символы, а также . — : и спецсимволы.

Теги XML являются регистрозависимыми. Так, тег <NewParcel> не то же самое, что тег <newparcel>.

В XML все элементы обязаны соблюдать корректную вложенность, то есть нельзя написать: <Area><Unit></Area></Unit>.

Каждый элемент может содержать:

• другие элементы;
• текст;
• атрибуты.

Атрибуты часто предоставляют дополнительную информацию, которая может быть важна при обработки данных:

<SpelementUnit TypeUnit="Точка">

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

В XML имена элементов определяет разработчик. Чтобы избежать конфликты имен, используются префиксы имени элемента:

<html:table>Таблица</h:table>
<furniture:table>Стол</f:table>

Пространство имен определяется в виде xmlns:префикс="URI" в атрибуте xmlns в начальном теге элемента либо в корневом элементе XML документа:

<root xmlns:html="http://www.w3.org/TR/html4/" xmlns:furniture="http://www.w3schools.com/furniture">

Итак, валидный XML документ:

• должен быть синтаксически верным:
• XML документ должен иметь корневой элемент;
• XML элемент должен иметь закрывающий тег;
• XML теги регистрозависимы;
• XML элементы должны соблюдать последовательность вложенности;
• значения XML атрибутов должны заключаться в кавычки;
• должен соответствовать определенному типу документов.

Правила, определяющие допустимые элементы и атрибуты для XML документа описываются с помощью:

• определения типа документа (DTD) (устаревающая технология);
• XML-схемы (современная технология).

Раздел официального сайта Росреестра, на котором размещены XML-­схемы, используемые для формирования XML-­документов: https://rosreestr.gov.ru/activity/okazanie-gosudarstvennykh-uslug/vedenie-egrn/xml-skhemy/ 

Ранее помимо действующих схем заявлений, выписок и кадастровых документов на сайте выложены и проекты новых схем. Для каждого документа можно скачать архив с текстовым описанием и схемой в виде XSD файла документа и отдельных XSD с сложными элементами и классификаторами.

Также в соответствии с планом мероприятий по ускоренному внедрению онлайн-технологий в финансовый сектор Росреестр ведет работу по переводу форм договоров в XML-формат.

Рассмотрим для примера схему, предназначенную для формирования межевого плана. В соответствии с ней XML-файл должен представляться в кодировке Unicode (UTF-8) и иметь имя вида GKUZU_*.xml.

Документ состоит из набора файлов, упакованных в один ZIP-архив (пакет). Один документ соответствует одному пакету. Имя пакета должно иметь вид GKUZU_*.zip, где

• GKUZU — префикс, обозначающий тип документа;
• * — уникальный набор символов, соответствующий GUID, указанный в XML-файле (MP/@GUID).

В пакет должен всегда входить XML-файл (в корневом каталоге), содержащий семантические сведения документа, а также один или несколько файлов (можно в подкаталогах) с расширением PDF, XML, ZIP (графические разделы, документы Приложения):

• документы приложения, подготовленные на бумажном носителе, оформляются в форме электронных образов бумажных документов в виде файлов в формате PDF;
• документы приложения, подготовленные в форме электронного документа, оформляются в виде файлов в формате XML;
• архивы документов приложения оформляются в формате ZIP.

XML-файл документа, файлы графических разделов межевого плана и документов приложения должны быть подписаны усиленной квалифицированной электронной подписью. Файл электронной подписи должен размещаться в том же каталоге, что и подписываемый файл. Имя файла электронной подписи должно иметь вид <имя подписываемого файла>.sig

В случае, если документ приложения подготовлен в виде архива документа (ZIP-файл), файл электронной подписи должен размещаться внутри этого архива документа. Сам архив (ZIP-файл) не удостоверяется.

Описание структуры XML-схемы файла в описывающем документе приводится в табличной форме для каждого элемента или атрибута:

• код; 
• содержание элемента (коды входящих элементов или атрибутов);
• тип (обязательный или необязательный, один из, множественность);
• формат (текст, число, дата, код по классификатору, булево значение истина/ложь, целое неотрицательное число, дробное число);
• наименование;
• дополнительная информация.

Стоит заметить, что некоторые сведения, предусмотренные нормативными правовыми актами, но отсутствующие в соответствующих элементах актуальных XML-схем, указываются в разделе «Заключение кадастрового инженера» кадастрового документа, например:

• информация о договоре на выполнение кадастровых работ;
• именование саморегулируемой организации, членом которой является кадастровый инженер.

XML документы не содержат в себе информации о том, каким образом следует отображать данные визуально. Браузер не понимает, что скрывается за тегом <table> — таблица или обеденный стол. тем не менее, необходимый внешний вид документу можно придать:

• с помощью CSS (Cascading Style Sheets, каскадные таблицы стилей);
• с помощью парсера (своя программа, распознающая теги и генерирующая на их основе некий документ);
• с помощью XSLT-преобразования.

Примечание — О нумерации версий XML-схем

Кадастровые инженеры с помощью специализированного программного обеспечения формируют электронные документы в виде XML-файлов. Требования к их структуре задаются тоже в виде XML-документов, но особенных, сформированных на языке XML-схем (Schema). Такая стандартизация обеспечивает возможность автоматизации импорта данных из документации и их проверки

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

Во-первых, не всегда сами схемы полностью реализуют НПА. В этих случаях некоторые характеристики объектов недвижимости невозможно корректно описать по действующей схеме. В таких случаях приходится либо вписывать что-то близкое («нежилое здание» вместо «садовый дом»), либо указывать пояснения в непредназначенных для этого полях («садовый дом» в поле «наименование»), либо описывать ситуацию в заключении в простом текстовом виде. Все это, конечно, не способствует повышению качества данных ЕГРН.

Во-вторых, не всегда программное обеспечение способно работать с данными по актуальной схеме. Например, ФГИС ЕГРН так и не научилась считывать межевые планы, оформленные по схеме версии 9, утвержденной Приказом Росреестра №П/0341 от 16.09.2022.

В 2023 году Росреестр утвердил новые XML-схемы межевого, технического плана, акта обследования, и они, кажется, привнесли новую потенциальную путаницу. Дело в том, что ими утверждены вроде как обновленные схемы, но под теми же номерами версий. Зачем на ровном месте устраивать новую проблему — неясно. Если изменений нет, то зачем новый приказ. А если есть, то как теперь определять версию схемы, в соответствии с которой сделан документ? Указывать номер релиза версии или реквизиты приказа?

XSLT — это XML язык, который может использоваться для преобразования документов XML в другие форматы, например, HTML. К XML-документу применяются таблицы стилей XSLT, состоящие из набора шаблонов. Правила выбора и преобразования данных из XML пишутся на языке запросов XPath. В простейшем случае XSLT-процессор получает на входе два документа — входной XML-документ и таблицу стилей XSLT — и создаёт на их основе выходной документ.

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

Реляционной, то есть основанной на «отношениях», базу данных можно назвать по двум причинам:

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

Предварительное проектирование обязательно нужно в следующих ситуациях:

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

Перед проектированием следует установить алгоритм выполняемой задачи, участников действий. Для этого стоит составлять диаграммы и блок-схемы, например в нотации BPMN или UML.

Более современным общемировым стандартом описания алгоритмов процессов является Business Process Model and Notation (BPMN) — нотация и модель бизнес-процессов. Это система условных обозначений (нотация) для моделирования бизнес-процессов.

Базовые условные обозначения здесь всё те же, отдельно можно обратить внимание на условное обозначение документа или данных в виде листа бумаги. Процессы описываются на языке XML по стандартизированной схеме. Таким образом обеспечивается чтение файлов в различном программном обеспечении. 

Ресурсы по BPMN: 

• официальный сайт с образцами http://www.bpmn.org/ 
• спецификация формата http://www.omg.org/spec/BPMN/2.0/  
• подсказки по условным обозначениям http://www.bpmb.de/images/BPMN2_0_Poster_RU.pdf 
• онлайн-редактор https://bpmn.io 

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

Наиболее распространенная, более широкая нотация, используемая при составлении различных схем, это UML (Unified Modeling Language, унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения, моделирования бизнес-процессов, системного проектирования и отображения организационных структур.

С помощью UML можно составлять самые разнообразные диаграммы. К примеру, близкий аналог BPMN — это диаграмма деятельности (activity diagram), которая позволяет описывать некое поведение на основе указания потоков управления и потоков данных.

Другая удобная для формализации процессов диаграмма — это диаграмма последовательности (sequence diagram), на которой для некоторого набора объектов на единой временной оси показано их взаимодействие в виде запросов и ответов.

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

Диаграммы последовательности можно создавать в различных графических и специализированных редакторах вроде https://draw.io или, например, в Google Документах непосредственно в текстовом редакторе. Для этого установите дополнение “WebSequenceDiagrams” и вы можете описывать последовательность работ простым текстом, по которому автоматически генерируется диаграмма.

В ER-диаграмме сущности изображают в виде прямоугольника с указанным внутри названием. Так как в таблице обычно содержатся сведения о множестве объектов, то логично называть сущности во множественном числе.

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

В простой ER-диаграмме названия атрибутов пишутся в столбик под именем сущности. Имена характеристикам стоит давать простые, короткие и однозначные. Не надо уточнять, про какой объект идет речь, вроде «Адрес участка» для сущности «Участки», ведь и так ясно, что это свойство участка.

Позже, в рабочей таблице атрибуты превратятся в ее колонки.

Сразу стоит отмечать, какие из атрибутов являются первичными ключами. Это можно сделать, например, указав «ПК» перед названием атрибута. Во многих СУБД первичные ключи отмечаются символом ключа.

Также имеет смысл подписывать справа от названий атрибутов форматы данных, например, int для целочисленных значений, text — для текстовых и так далее.

Здесь стоит заметить, что «один-к-одному» это частный случай «один-ко-многим» и встречается очень редко.

В простой ER-диаграмме связи показываются линиями от одной сущности до другой или, если более точно, от внешнего ключа в одной таблицы до соответствующего первичного ключа в другой. На каждом конце линии указывают соответствующую степень — один или много. В качестве обозначения «много» рекомендуется писать «n», но в примерах можно встретить «*», «∞» или трезубец.

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

Первое время кажется сложным определить вид связи, но это очень легко сделать, задав себе вслух для каждой пары сущностей вопросы вида «С одним А сколько Б связано?» и  «С одним Б сколько А связано?»

Например, у нас есть Здания и Помещения. Зададим вопросы:

1. «С одним Зданием сколько Помещений связано? Много!»
   На конце связи, подходящей к Помещениям отмечаем «n».
2. «С одним Помещением сколько Зданий связано? Одно!» 
   На конце связи, подходящей к Зданиям отмечаем «1».

Для начала стоит доработать диаграмму, чтобы убедиться, что все готово для создания таблиц в точности по ней:

1. расставить первичные и внешние ключи;
2. избавиться от типичных ошибок проектирования путем нормализации.

Можно сказать, что это уникальный идентификатор каждой строки в таблице. В большинстве случаев можно просто в каждую таблицу добавить (обычно первым) атрибут с общепринятым именем «ID» и типом int — целочисленный. Это будет просто номер строки в порядке добавления.

Тем не менее, никто не запрещает называть первичные ключи, да и любые другие атрибуты, как угодно иначе. Более того, первичные ключи могут быть составными, например для помещения это могут быть два атрибута: «Здание» и «Номер». По-отдельности они не уникальны, но их совокупность будет однозначно идентифицировать каждую строку.

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

Именовать внешние ключи лучше так, как называется другая соответствующая (внешняя) таблица, но в единственном числе, например, «здание». Нет нужды писать что-то вроде «ID здания», так как это несколько визуально «захламляет» структуру базы данных. Keep it simple.

Когда мы будем описывать конкретное помещение, мы не будем писать адрес здания или другую его характеристику, чтобы понять о каком объекте капитального строительства идет речь. Вместо этого мы во внешнем ключе с именем «здание» в таблице «Помещения» просто напишем идентификатор нужного здания (грубо говоря — номер строки).

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

• если связь «один-ко-многим»:
  1. в таблице, где «один» создайте первичный ключ, если его нет;
     
  2. в таблице, где «много» создайте внешний ключ и назовите его так, как называется другая таблица в единственном числе;
     
• если «многие-ко-многим»:
  1. в обоих таблицах создайте первичные ключи, если их нет;
     
  2. создайте промежуточную таблицу со своим первичным и двумя внешними ключами, соответствующими первичным ключам связанных таблиц. Назовите внешние ключи так, как называются другие соответствующие таблицы в единственном числе;
  3. при необходимости в промежуточную таблицу можно добавить и другие атрибуты, которые описывают эту связь. В примере это поле right, в котором содержится описание права персоны на недвижимость.

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

По мере выполнения проверок считается, что база данных находится в той или иной нормальной форме:

1. первая форма:
   • в одной ячейке нет нескольких внешних ключей;
   • расположение строк не имеет значения;
   • расположение колонок не имеет значения;
   • определен первичный ключ;
2. вторая форма:
   • нет атрибута, который бы являлся на самом деле характеристикой другой сущности, на которую стоит ссылка в составном первичном ключе, например:
     [Номер здания] [Номер помещения] Назначение помещения Назначение здания
3. третья форма:
   1. нет атрибута, который бы являлся на самом деле характеристикой другой сущности, например:
      [Номер помещения] Назначение помещения Площадь Минимальная площадь

Есть и другие нормальные формы, но рассматриваемые в них случаи весьма нетривиальны. Первых трех достаточно в большинстве случаев.

Существует несколько «стандартных» подходов к построению реляционной базы данных. Как минимум, мы можем выделить следующие:

• «классическая» (отдельные таблицы для каждой сущности);
• «универсальная» (общие таблицы сущностей и характеристик);
• «таблица фактов» (OLAP).

Проекция — это операция в реляционной алгебре, при которой из таблицы выбираются нужные столбцы, например:

• Выбор одного столбца из таблицы
  SELECT area FROM rooms;

• Выбор нескольких произвольных столбцов в одной таблице
  SELECT id, area FROM rooms;

• Выбор всех столбцов в одной таблице
  SELECT * FROM rooms;

• Создание псевдонимов столбцов
  SELECT area AS Площадь FROM rooms;

• Удаление дубликатов строк (без удаления данных)
  SELECT DISTINCT area FROM rooms;

• Выполнение сортировки по одному произвольному столбцу
  SELECT area FROM rooms ORDER BY area ASC/DESC;

• Сортировка по нескольким столбцам
  SELECT area FROM rooms ORDER BY building ASC/DESC, area ASC/DESC; 

Выборка — это операция в реляционной алгебре, при которой из таблицы выбираются нужные строки, например:

• Фильтрация строк с помощью произвольного сравнения

  SELECT * FROM rooms WHERE area > 100;

• Комбинирование условий с помощью логических операторов AND, OR и NOT
  SELECT * FROM rooms WHERE area > 100 AND building = 1; 
  

• Фильтрация строк по произвольному списку

  SELECT * FROM rooms WHERE id IN (1, 4, 35);

• Проверка на значение null с помощью оператора IS NULL / IS NOT NULL

  SELECT * FROM rooms WHERE area IS NULL;

В запросе можно для каждой строки выполнять как простые, так и достаточно сложные математические операции. Принцип составления формул похож на применяемый в MS Excel, например:

• Просто калькулятор
  SELECT 2+2;
• Расчет с выводом результата в отдельном столбце
  SELECT area*100 AS Стоимость FROM rooms;
• Расчет в условии
  SELECT * FROM rooms WHERE area*100 > 10000;

Для расчетов по столбцам используются агрегатные функции, например:

• Подсчет строк
  SELECT COUNT(*) FROM rooms WHERE area > 100;

• Обобщенное значение
  SELECT MIN/MAX/AVG(area) FROM rooms;

• Группирование строк

  SELECT floor, COUNT(*) FROM rooms GROUP BY floor;

• Фильтрация групп

  SELECT floor, COUNT(*) FROM rooms GROUP BY floor HAVING COUNT(*) > 3;

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

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

1. существующие в виде первичных и внешних ключей связи в виде выражения:
   FROM tableA LEFT/RIGHT/INNER JOIN tableB ON foreign key = primary key;
2. условия выборки нужных строк после WHERE (если надо).

Так как в таблицах могут быть совпадающие имена атрибутов, следует перед ними указывать имя таблицы или ее псевдоним, заявленный с помощью AS, например:

• Помещения площадью более 100 и адреса зданий, в которых они расположены
  SELECT r.id, b.address
  FROM rooms AS r INNER JOIN buildings AS b ON r.building = b.id
  WHERE r.area > 100;

Есть несколько видов соединений, например для предыдущего примера:

• внутреннее (INNER JOIN), если нужно отобрать только такие помещения, отвечающие условию выборки, у которых в атрибуте r.building указаны идентификаторы существующих в таблице buildings зданий. Если нужного здания нет, то строки с этим помещением в результате запроса просто не будет;
• внешнее (LEFT JOIN или LEFT OUTER JOIN), если нужно показать все помещения, отвечающие условию выборки, независимо от того, есть ли в таблице buildings соответствующие здания или нет. Для помещений с отсутствующими в базе данных зданиями в поле b.address отобразится NULL.

Есть и реже используемый RIGHT JOIN, при котором в первую очередь отберутся все здания независимо от наличия помещений. Однако, в рассматриваемом примере у нас нет зданий без помещений.

Добавляя нужные условия, мы можем составлять самые разнообразные запросы, например:

• Помещения, для которых нет соответствующих зданий (так называемое вычитание)
  SELECT r.id
  FROM rooms AS r LEFT JOIN buildings AS b ON r.building = b.id
  WHERE b.id IS NULL;

Мы можем хранить в любой базе данных информацию в двух видах:

• записи о состоянии объекта, то есть значения его характеристик, на момент времени;
• записи об изменениях характеристик. Такие записи называют транзакциями.

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

Нам нужно быть уверенными, что никто не изменил сохраненные данные. В случае с блокчейном это задача решается так: в каждую последующую запись включается хэш от предыдущей. Что такое хэш? Хэш — это выглядящий беспорядочным набор символов. Он получается из исходных данных посредством односторонней математической функции и обладает весьма интересными особенностями:

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

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

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

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

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

В российском законодательстве блокчейн относится к технологиям распределенного реестра.

Наиболее распространены стандарты описания онтологий RDF и OWL. Ключевыми понятиями являются «субъект», «предикат», «объект», «триплет», «класс», «отношение», «экземпляр», «суждение».

В качестве примера можно привести онтологию ФНС, предназначенную для описания выписок из реестров ЕГРЮЛ и ЕГРИП.

Последние события:

• 06.2022 — ФГБУ «Центр геодезии, картографии и ИПД» объявил конкурс на 39,75 млн руб. на предоставление права использования программной платформы онтологического проектирования (в целях разработки НСПД);
• 12.2022 — ФГБУ «Центр геодезии, картографии и ИПД» выполнил первый этап работ по созданию отраслевой онтологии.

Стандартом SFA OGS предусмотрены типы объектов:

• Geometry (корневой абстрактный класс):
  • Point (размерность 0, одна позиция в пространстве);
  • Curve (размерность 1, последовательность Point):
    • LineString (Curve с линейной интерполяцией между точками. Каждая последовательная пара точек определяет объект Line):
      • Line;
      • LineRing;
  • Surface (размерность 2);
    • Polygon (плоская поверхность, задаваемая при помощи одной внешней границы и 0 или более внутренних);
    • PolyhedralSurface (многогранная поверхность является набором граничащих по внешней границе полигонов);
      
  • GeomCollection (объект, содержащий несколько других объектов):
    • MultiCurve (сейчас не используется):
      • MultiLineString;
    • MultiSurface:
      
      • MultiPolygon;
    • MultiPoint (состоит из Point, которые не соединены между собой и порядок их следования не важен).

Согласно Приказу Минэкономразвития России от 28.02.2023 №123 в документах территориального планирования объектов федерального, регионального и местного значения при описании пространственных данных могут применяться следующие типы геометрий:

• точка (Point);
• линия (Line);
• кривая (Curve);
• полигон (Polygon);
• мультиточка (Multipoint);
• мультикривая (MultiCurve);
• мультиполигон (MultiPolygon).

Для хранения данные из текстового вида часто преобразуются в двоичное представление в шестнадцатеричных строках в формате WKB (Well-known binary), например:

• WKT: POINT(2.0 4.0);
• WKB: 000000000140000000000000004010000000000000, где:
  • 1-byte integer 00 или 0: прямой порядок байт;
  • 4-byte integer 00000001 или 1: POINT (2D);
  • 8-byte float 4000000000000000 или 2.0: x-координата;
  • 8-byte float 4010000000000000 или 4.0: y-координата.

Существуют расширенные версии формата:

• EWKT (Extended) используется в PostGIS и включает до 4-х значений координат (XYZM);

• AGF используется в продуктах Autodesk и включает кривые.

В MySQL описание геометрии в формате WKT преобразуется для использование в запросах в сооветствующее выражение на SQL с помощью специальных функций, так:

Point(15, 20) — это то же самое, что ST_GeomFromText('POINT(15 20)')

Каждый объект обладает свойствами:

• тип;
• идентификатор пространственной привязки SRID:
  • 0 - бесконечная плоскость;
• координаты;
• минимальный ограничивающий прямоугольник MBR ((MINX MINY, MAXX MINY, MAXX MAXY, MINX MAXY, MINX MINY));
• является ли пустой (нет точек, площадь 0);
• размерность:

  • -1 для пустой геометрии;

  • 0 для геометрии без длины и без области;

  • 1 для геометрии с ненулевой длиной и нулевой площадью;

  • 2 для геометрии с ненулевой площадью;

• внутренняя область, границы и внешняя область.

Требования к геометрии для корректной работы функций:

• линия имеет как минимум две точки;
• полигоны имеют как минимум одно кольцо;
• кольца многоугольника замкнуты (первая и последняя точки совпадают);
• кольца многоугольника имеют как минимум 4 точки;
• коллекции не пусты (кроме GeometryCollection);

• полигоны не являются самопересекающимися;

• внутренние кольца многоугольника находятся внутри внешнего кольца;

• мультиполигоны не имеют перекрывающихся полигонов.
  

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

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

Полученные пространственные отношения классифицируются при помощи полученной матрицы пересечений размерности 3 на 3, которую именуют DE-9IM.

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

Для более удобной работы предусмотрены именованные случаи матрицы в виде операций (методов) определения отношений между объектами: equals, intersects и другие.

О пересечениях в 3D см. работу Zlatanova S. (2015) Topological Relationships and Their Use. In: Shekhar S., Xiong H., Zhou X. (eds) Encyclopedia of GIS. Springer, Cham. https://doi.org/10.1007/978-3-319-23519-6_1548-1

В Бразилии исследователи предложили включать координаты центроида в кадастровый номер.

Примеры SQL запросов для СУБД MySQL:

• INSERT INTO t1 (pt_col) VALUES(Point(1,2));
• INSERT INTO geom VALUES (ST_GeomFromText('POINT(1 1)'));
• SELECT ST_AsText(g) FROM geom;
• SELECT ST_Contains(polygon, point) FROM geom;
• SELECT ST_Area(poly) FROM `buildings`;

Для запросов следует создавать индексы типа SPATIAL.