A major contributor to this article appears to have a close connection with its subject. (September 2023) |
Моделирование якорей — это гибкая техника моделирования баз данных , подходящая для информации, которая со временем меняется как по структуре, так и по содержанию. Она предоставляет графическую нотацию, используемую для концептуального моделирования, аналогичную моделированию сущности-связи , с расширениями для работы с временными данными . Техника моделирования включает четыре конструкта моделирования: якорь, атрибут, галстук и узел, каждый из которых фиксирует различные аспекты моделируемой области. [1] Полученные модели можно преобразовать в физические проекты баз данных с использованием формализованных правил. Когда такой перевод выполняется, таблицы в реляционной базе данных в основном будут находиться в шестой нормальной форме .
В отличие от схемы «звезда» ( многомерное моделирование ) и классической реляционной модели (3NF), моделирование хранилищ данных и якорей хорошо подходят для фиксации изменений, которые происходят при изменении или добавлении исходной системы, но считаются передовыми методами, требующими опытных архитекторов данных . [2] И хранилища данных, и якорные модели являются моделями на основе сущностей , [3] но якорные модели имеют более нормализованный подход. [ требуется ссылка ]
Моделирование якорей было создано для того, чтобы воспользоваться преимуществами высокой степени нормализации , избежав при этом недостатков, которые имеют более высокие нормальные формы в отношении читабельности человеком. Получаются такие преимущества, как возможность неразрушающего развития модели, избегание нулевых значений и сохранение информации свободной от избыточности. Проблемы с производительностью из-за дополнительных соединений в значительной степени избегаются благодаря функции в современных движках баз данных [ когда? ], называемой устранением соединений или устранением таблиц. Для обработки изменений в информационном содержании моделирование якорей эмулирует аспекты временной базы данных в результирующей схеме реляционной базы данных .
Первые инсталляции с использованием якорного моделирования были осуществлены в 2004 году в Швеции, когда с использованием этой технологии было создано хранилище данных для страховой компании.
В 2007 году эта техника использовалась в нескольких хранилищах данных и одной системе обработки онлайн-транзакций (OLTP), а на международном уровне она была представлена Ларсом Рённбеком на конференции 2007 Transforming Data with Intelligence (TDWI) в Амстердаме . [4] Это вызвало достаточный интерес, чтобы техника заслуживала более формального описания. С тех пор исследования, касающиеся моделирования якорей, проводятся в сотрудничестве между создателями Олле Регардтом и Ларсом Рённбеком и командой из Департамента компьютерных и системных наук Стокгольмского университета .
Первая статья, в которой формализовано якорное моделирование, была представлена в 2008 году на 28-й Международной конференции по концептуальному моделированию и получила награду за лучшую статью. [5]
Коммерческий веб-сайт предоставляет материал по моделированию якорей, который можно использовать бесплатно по лицензии Creative Commons . Также доступен инструмент онлайн-моделирования, который можно использовать бесплатно и с открытым исходным кодом . [6]
Моделирование якорей имеет четыре основных концепции моделирования: якоря, атрибуты, связи и узлы. Якоря используются для моделирования сущностей и событий, атрибуты используются для моделирования свойств якорей, связи моделируют отношения между якорями, а узлы используются для моделирования общих свойств, таких как состояния. Атрибуты и связи могут быть сохранены, когда изменения в информации, которую они моделируют, необходимо сохранить.
Ниже приведен пример модели, демонстрирующей различные графические символы для всех концепций. Символы напоминают те, которые используются в моделировании сущности–связи , с парой расширений. Двойной контур атрибута или связи указывает на то, что сохраняется история изменений. Символ узла (очерченный квадрат с закругленными краями) также доступен, но узлы не могут быть историзированы. Символ якоря — сплошной квадрат.
Моделирование якорей обрабатывает два типа информационной эволюции: структурные изменения и изменения контента. Изменения структуры информации представлены через расширения. Высокая степень нормализации позволяет неразрушающим образом добавлять необходимые концепции моделирования, необходимые для фиксации изменения , таким образом, что каждая предыдущая схема всегда остается подмножеством текущей схемы. Поскольку существующая схема не затрагивается, это дает преимущество возможности развивать базу данных в высокой степени итеративным образом и без простоя.
Изменения в содержании информации выполняются путем эмуляции аналогичных особенностей временной базы данных в реляционной базе данных . В якорном моделировании фрагменты информации могут быть привязаны к точкам во времени или к интервалам времени (как открытым, так и закрытым). Моменты времени, когда происходят события, моделируются с использованием атрибутов, например, даты рождения людей или время покупки. Интервалы времени, в течение которых значение является действительным, фиксируются посредством историзации атрибутов и связей, например, изменения цвета волос человека или периода времени, в течение которого человек был женат. В реляционной базе данных это достигается путем добавления одного столбца с типом данных , достаточно детализированным, чтобы зафиксировать скорость изменений, в таблицу, соответствующую историзированному атрибуту или связи. Это добавляет небольшую сложность, поскольку необходимо проверить более одной строки в таблице, чтобы узнать, закрыт ли интервал или нет.
Точки или интервалы времени, не связанные напрямую с моделируемой областью, такие как информация о точках времени, введенная в базу данных, обрабатываются с помощью метаданных в моделировании якорей, а не с помощью каких-либо из вышеупомянутых конструкций. Если необходимо сохранить информацию о таких изменениях в базе данных, можно использовать битемпоральное моделирование якорей, где в дополнение к обновлениям также операторы удаления становятся неразрушающими.
В моделировании якорей существует однозначное соответствие между символами, используемыми в концептуальной модели, и таблицами в реляционной базе данных. Каждый якорь, атрибут, галстук и узел имеют соответствующую таблицу в базе данных с однозначно определенной структурой. Таким образом, концептуальная модель может быть переведена в схему реляционной базы данных с использованием простых автоматизированных правил и наоборот. Это отличается от многих других методов моделирования, в которых существуют сложные и иногда субъективные этапы перевода между концептуальным, логическим и физическим уровнями.
Таблицы привязки содержат один столбец, в котором хранятся идентификаторы. Идентификатор предполагается единственным свойством сущности, которое всегда присутствует и неизменяемо. Поскольку идентификаторы редко доступны из моделируемой области, они вместо этого технически генерируются, например, из возрастающей числовой последовательности.
Примером якоря для идентичностей племянников Дональда Дака является набор 1-кортежей:{⟨#42⟩, ⟨#43⟩, ⟨#44⟩}
Узлы можно рассматривать как комбинацию якоря и одного атрибута. Таблицы узлов содержат два столбца: один для идентификатора и один для значения. Из-за совместного хранения идентификаторов и значений узлы не могут быть историзированы. Их полезность заключается в возможности снизить требования к хранению и повысить производительность, поскольку таблицы, ссылающиеся на узлы, могут хранить короткое значение, а не длинную строку.
Примером узла для родов является набор из 2-х кортежей:{⟨#1, 'Male'⟩, ⟨#2, 'Female'⟩}
Статические таблицы атрибутов содержат два столбца: один для идентификатора сущности, к которой принадлежит значение, и один для фактического значения свойства. Исторические таблицы атрибутов имеют дополнительный столбец для хранения начальной точки временного интервала. В узловой таблице атрибутов столбец значения является идентификатором, который ссылается на таблицу узлов.
Примером статического атрибута для их имен является набор из 2-х кортежей:{⟨#42, 'Huey'⟩, ⟨#43, 'Dewey'⟩, ⟨#44, 'Louie'⟩}
Примером связанного статического атрибута для их пола является набор из 2-кортежей:{⟨#42, #1⟩, ⟨#43, #1⟩, ⟨#44, #1⟩}
Примером историзированного атрибута для (меняющихся) цветов их одежды является набор из 3-х кортежей:{⟨#44, 'Orange', 1938-04-15⟩, ⟨#44, 'Green', 1939-04-28⟩, ⟨#44, 'Blue', 1940-12-13⟩}
Статические таблицы связей связывают два или более якорей друг с другом и содержат два или более столбцов для хранения идентификаторов. Исторические таблицы связей имеют дополнительный столбец для хранения начальной точки временного интервала. Узловатые таблицы связей имеют дополнительный столбец для каждого указанного узла.
Примером статической связи для родственных отношений является набор из 2-кортежей:{⟨#42, #43⟩, ⟨#42, #44⟩, ⟨#43, #42⟩, ⟨#43, #44⟩, ⟨#44, #42⟩, ⟨#44, #43⟩}
Все полученные таблицы будут находиться в шестой нормальной форме, за исключением связей, в которых не все столбцы являются частью первичного ключа.
В 2000-х годах было введено несколько шаблонов моделирования данных хранилищ данных с целью создания гибких хранилищ данных, включая формы ансамблевого моделирования, такие как моделирование якорей, моделирование хранилищ данных, моделирование фокальных точек и другие. [7]
В 2013 году на конференции по моделированию данных BI Podium в Нидерландах Ларс Рённбек представил сравнение моделирования якорей и моделирования хранилищ данных. [8]
Сравненная характеристика | Хранилище данных | Преимущество* | Моделирование якоря |
---|---|---|---|
Семья | Моделирование ансамбля | - | Моделирование ансамбля |
Парадигма | Приоритет отдается аудиту на основе данных | - | Потребности , основанные на данных, имеют приоритет |
Архитектура | Гибрид (несколько объектов обслуживания) | - | Реплицированные (отдельные объекты обслуживания) |
Группировка | Насколько это возможно | - | Как можно меньше |
Основная временная шкала | Время записи | - | Время меняется |
Обнаружение изменений | Доступ к нескольким строкам/столбцам | ЯВЛЯЮСЬ | Доступ к одной строке/столбцу |
Строгость | Слабо формализовано. Нет соглашения об именовании. | - | Строго формализован. Имеет соглашение об именовании. |
Эволюция схемы | Разрушительный | ЯВЛЯЮСЬ | Неразрушающий |
Темпорализация | Любое время вручную, конечная дата необязательна (не рекомендуется) | ЯВЛЯЮСЬ | Одновременно-временной по замыслу, без конечной даты |
Затягивание | Могут потребоваться обновления | ЯВЛЯЮСЬ | Вставить только |
Поддержка инструментов | Множество инструментов В основном коммерческие | ДВ | Мало инструментов Только с открытым исходным кодом |
Адаптация к изменениям | Все еще громоздко | ЯВЛЯЮСЬ | Почти без усилий |
Обмен моделями | Чистый SQL с напечатанными диаграммами некоторого вида | ЯВЛЯЮСЬ | Стандартизированный формат XML и графическое обозначение |
Неизменность | Суррогатная личность и естественный ключ | ЯВЛЯЮСЬ | Только суррогатная личность |
Естественно суррогатное материнство | Один к одному, статический Физически реализованный (концентратор) | ЯВЛЯЮСЬ | Логическое представление данных «многие к одному» с возможностью ведения истории |
Оптимизация запроса | Несколько важных Недавние базы данных | ДВ | Очень важно Последняя версия базы данных |
Возможность написания сценариев | С некоторыми усилиями | ЯВЛЯЮСЬ | Формализовано, автоматизировано для всего |
Виды и триггеры | Упомянутый, сделанный вручную и индивидуальный | ЯВЛЯЮСЬ | Формализовано, автоматизировано для всего |
Предположения | Создано на века Потребности предположения | ЯВЛЯЮСЬ | Создан для изменений. Никаких предположений. |
Доля рынка | Малый <1000 установок (2013) | ДВ | Очень мало <100 установок (2013) |