1. Адаптированная методология моделирования якоря.
Архитектура ядра хранилища данных должна соответствовать адаптированной (не оригинальной) методологии, описанной ниже.
Моделирование якоря (но нет Хранилище данных ).
| Тип стола | Примеры названий таблиц (описание в скобках) | С какими типами таблиц он может быть связан? | Обязательный тип поля | Примеры названий полей |
| Сущности (Якорь, Тип объекта).
Обозначается квадратом | TR_Transaction (полупроводка по дебету или кредиту), AC_Account (синтетический счет) | Отношения, атрибут сущности | Суррогатный ключ сущности | TR_ID, AC_ID |
| Атрибут сущностей (Атрибут).
Обозначено кружком | TR_TDT_TransactionDate (дата транзакции) | Сущности | Суррогатный ключ сущности (является первичным ключом на весь срок существования записи) | TR_ID |
| Дата и время начала действия записи | TR_TDT_FROM | |||
| Дата и время окончания срока действия записи (не включительно) | TR_TDT_BEFORE | |||
| Атрибут сущностей | TR_TDT | |||
| Соединения (Галстук, Отношения).
Обозначается ромбом | TR_AC_DC_Transaction_Account_DrCr (счет главной книги в полупроводниках) | Сущности | Суррогатные ключи каждого связанного объекта (вместе с некоторыми атрибутами отношений, указывающими тип отношений, образуют составной ключ на весь срок действия записи) | TR_ID, AC_ID |
| Дата и время начала действия записи | TR_AC_DC_FROM | |||
| Дата и время окончания срока действия записи (не включительно) | TR_AC_DC_BEFORE | |||
| Необязательный атрибут или несколько атрибутов ссылки | ДЦ (дебет/кредит) |
Пример схемы данных Таблицы связей связывают сущности отношениями «многие ко многим» или «один ко многим».
Таблицы связей должны соединять минимально возможное количество сущностей и атрибутов связей — за счет увеличения количества таблиц связей.
Например, вместо того, чтобы связать полупроводник с синтетическим счетом, с контрагентом, с продуктом или финансовым инструментом и т. д. в одной таблице.
необходимо связать полупроводник с каждым из этих типов объектов отдельной таблицей связей.
Если не следовать этому принципу, то раздутая таблица соединений превратится в таблица фактов в денормализованном звездный узор - со всей ней недостатки .
В оригинальный В методологии моделирования Anchor атрибуты отношений не допускаются, но иногда они могут быть полезны для упрощения структуры данных и повышения ее соответствия реальному миру.
Также в оригинальный Методика моделирования привязки использует более длинные и неудобные имена таблиц и полей.
Ядро хранилища данных не должно использовать значения NULL, за исключением тех атрибутов отношений, которые не включены в составной ключ (обычно имена, символы, коды, ссылки, выбранные значения, флаги).
Если начало и/или окончание срока действия записи неизвестно, то необходимо указать принятые условные даты (например, «0001-01-01», «-бесконечность», «9999-12-31», «бесконечность»).
').
Чтобы облегчить создание полиморфных связей, двухсимвольный код в именах должен совпадать с двумя последними символами в соответствующих суррогатных ключах, обозначающих тип сущности или атрибут связей (см.
ниже).
Поэтому он должен использовать буквенные символы.
Типовые таблицы узел (узел) исключен из адаптированный Методика моделирования якоря.
Однако типовое обозначение узла на схеме в виде квадрата со скругленными углами удобно использовать для обозначения признаков связей.
Скетч базы данных можно сделать (в том числе офлайн) с помощью наглядных и удобных веб-инструментов.
Онлайн-модельер или Онлайн-моделлер (тестовая версия) , но генерируемый ими SQL-код непригоден для использования.
Для генерации SQL-кода (в том числе SQL-запросов) с использованием методологии моделирования Anchor все известные компании используют самостоятельно разработанные инструменты на базе языка программирования Python и Microsoft Excel.
2. Суррогатные ключи в адаптированном формате ULID.
Для связи таблиц следует использовать только суррогатные ключи в адаптированном формате ULID. Для связывания таблиц не следует использовать автоинкремент, составные ключи и хэши бизнес-ключей.Как суррогатный ключ следует использовать адаптированную (не оригинальную) версию УЛИД (но нет UUID ), имеющий любой из двух форматов:
- ттттттттттрррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррхх (пример: 01F5B023PBG3C48TSBDQQ3V9TR)
- ттттттттт ссс ррррррррррррррррррррррррррхх (пример: 01F5B023PB 004 48ЦБДQQ3V5TR)
- Соответствие требуемому формату ULID
- Используйте каждый сгенерированный ULID один раз в качестве суррогатного ключа объекта.
- Использование (достаточно мощного) криптографически безопасного генератора псевдослучайных чисел или генератора истинных случайных чисел.
- Монотонное увеличение ULID в интервале менее миллисекунды (из-за приращения случайного числа - для формата без счетчика, или из-за счетчика - для формата со счетчиком)
- Генерация ULID в формате (текстовом, двоичном, UUID или целочисленном), наиболее эффективном для поисковых операций в используемой СУБД и носителе данных (HDD или SSD).
- Пиковая (в пределах 5 мс) производительность генерации ULID должна быть выше максимальной производительности записи используемой СУБД и носителя информации (HDD или SSD) (например, за счет буферизации заранее вычисленных частей ULID)
В хранилище данных эти ключи не следует изменять, заменять другими ключами или переименовывать.
3. Указание начала и окончания срока действия въезда.
Чтобы сохранить историчность данных, необходимо использовать второй тип медленно меняющихся измерений.
СКД2 с добавлением двух унифицированных полей (столбцов): «Дата и время начала срока действия записи» (название столбца с суффиксом _FROM) и «Дата и время окончания срока действия записи (не включительно)» (имя столбца с суффиксом _BEFORE).
Единственным условием связывания записей в таблицах, помимо суррогатного ключа, должно быть одновременное действие ( действительное время ) связанных записей, определяемых едиными полями начала и окончания срока действия записи, а не датой загрузки в систему или датой создания записи ( время транзакции ).
Данные не следует хранить в виде «срезов» для отчетности ни на текущую дату, ни за календарный период (например, месяц).
4. Указание даты и времени создания записи
Если вам необходимо знать не только изменение состояния реального мира с течением времени, но и изменение состояния самой системы учета (когда в системе учета меняется информация об одном и том же моменте реального мира), то во все таблицы нужно добавить поле с датой и временем создания записи ( время транзакции ), который является частью составного ключа.Чтобы точно воспроизвести отчет, созданный в определенный момент в прошлом, достаточно игнорировать записи, дата и время создания которых позже этого момента в прошлом.
Примеры имени поля: TR_TIMESTAMP, TR_TDT_TIMESTAMP, TR_AC_DC_TIMESTAMP.
5. Только внешние источники элементов классификатора.
В системе учета необходимо использовать статьи классификатора (статьи доходов и расходов, синтетические счета, категории клиентов, виды продукции и т.п.
), полученные непосредственно из реального мира без каких-либо изменений - вместо разработки собственных или объединения их в гибридные классификаторы.
Элементы классификатора можно получить из законодательства, из требований высшего руководства к отчетам и т.п.
Если при загрузке новой версии классификатора элемент классификатора изменился (исчез, появился), то срок окончания предыдущей описи, а также начало и конец действия новой записи должны рассчитываться автоматически и указано.
6. Классификация фасетов
Следует использовать по возможности классификация фасетов вместо иерархическая классификация .Если вам все же придется использовать иерархический каталог из внешнего источника, то вам необходимо создать для него соответствующие каталоги фасетной классификации.
В этом случае каждый элемент из иерархического каталога становится сущностью, а каждый элемент из каталога фасетной классификации становится атрибутом этой сущности.
Например, пятизначные счета второго порядка в план счетов российских кредитных организаций должны быть самостоятельными сущностями, а не атрибутами двадцатизначных лицевых счетов.
К учетным записям второго порядка можно привязать соответствующие значения атрибутов, не образующих составной ключ:
- знак активного/пассивного счета,
- глава,
- глава,
- подсчет первого заказа
- тип контрагента,
- срок.
7. Теги
Если имеется большое количество атрибутов с логическими значениями true и false, то удобнее заменить эти атрибуты соответствующими.теги , который может храниться в одном поле, например множество , тип магазин или введите jsonb .
8. Полиморфные связи
Некоторые системы учета требуют возможности связать конкретную таблицу (назовем ее основной) с большим количеством других таблиц, и эти связи используются редко.Например, таблица полупроводников должна иметь большое количество субконто или измерений, каждое из которых редко используется в отчетах.
Однако использование таблиц связей в таких случаях нежелательно, так как их будет слишком много, и на их обслуживание будет затрачено слишком много ресурсов ИТ-подразделения.
Эту проблему можно решить с помощью полиморфных отношений.
В основной таблице в поле полиморфных отношений осуществляется поиск суррогатного ключа записи, содержащейся в связанной таблице, и последние два символа в этом суррогатном ключе будут определять таблицу с типом «Сущности».
Связь автоматически устанавливается с записью в этой таблице, имеющей соответствующий суррогатный ключ.
Если полиморфные отношения необходимы одновременно в нескольких таблицах, то суррогатные ключи записей в этих связанных таблицах могут храниться в основной таблице в одном поле, например множество , тип магазин или введите jsonb .
9. Устраните витрины данных
Каждый отчет должен создаваться непосредственно из реплики механизма хранилища данных.Не желательно использовать витрины данных , поскольку они сводят на нет все преимущества методологии моделирования Anchor. Универсальные витрины данных, предназначенные для формирования любого типа отчетности, имеют особенно большие недостатки.
10. Типичные SQL-запросы и материализованные представления
Разработка SQL-запросов к базе данных, соответствующей методологии моделирования Anchor, является трудоемкой.Поэтому для облегчения работы системных аналитиков и программистов SQL можно создавать стандартные SQL-запросы или материализованные представления, связывающие сущности с их атрибутами на заданную дату.
Но использование таких SQL-запросов и материализованных представлений может привести к усложнению базы данных и снижению производительности.
Поэтому для производственной системы вместо этого необходимо использовать автоматическую генерацию SQL-запросов (с использованием языка программирования Python и Microsoft Excel).
В качестве источника значений для заполнения полей могут использоваться соответствующие SQL-запросы, материализованные представления или таблицы разрешенных значений, созданные на их основе.
Приемлемые значения для заполнения полей также можно определить по таблице решений (см.
ниже).
Сильная нормализация данных привязочного моделирования предотвращает множество автоматических проверок целостности на уровне таблицы.
Поэтому для проверки целостности и качества данных необходимы соответствующие SQL-запросы, которые автоматически запускаются перед вставкой данных в таблицы.
11. Перенос логики из программного кода в таблицы решений
По возможности логику следует переносить из программного кода на языках программирования, SQL и различных ORM в таблицы решений.Например, таблица решений может кодировать выбор синтетического счета для дебетования в зависимости от типа транзакции, категории контрагента и срока погашения финансового инструмента.
Таблицу решений можно реализовать двумя способами:
- таблица сущностей - правил, к которым прикреплены входные атрибуты и один выходной атрибут,
- таблица отношений, которая соединяет входные сущности и атрибуты с выходной сущностью или выходным атрибутом.
Теги: #Хранилища данных #Финансы в ИТ #Большие данные #Анализ и проектирование систем #ERP-системы #измерения #схема данных #нормализация #ключ #витрины данных #идентификаторы #отношения #атрибут #сущность #полиморфные отношения
-
Анализ Нетбука Asus Eeepc-T101Mt-Eu17-Bk
19 Oct, 24 -
Согласие Внутри Команды
19 Oct, 24 -
2 Проекта Ищут Друзей
19 Oct, 24
