Бизнес-глоссарий¶

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

Глоссарий — это онтология: граф понятий, их определений и связей между ними. Provisa сопоставляет его со структурами базы данных, где лежат значения, и именно это позволяет отвечать на вопросы о ваших данных. Понятие остаётся черновиком, пока не достигнет данных — напрямую или через другие понятия. Глоссарий отделён от метрик: термин говорит, что такое понятие, метрика говорит, как считается число.

Этот общий словарь связывает язык бизнеса с физическими данными. ИИ-агенту, который знает, что «customer» обозначает каждый столбец с идентификатором клиента, не нужно гадать, какой из cust_id, customerId и CUSTOMER_KEY правильный. Все они сопоставлены одному термину, а определение несёт термин.

Как выводятся термины¶

Provisa выводит термин из каждого имени колонки автоматически, по детерминированному правилу нормализации: приведение регистра, токенизация по разделителям и camelCase, раскрытие сокращений и отсечение хвостовых прокси-токенов.

Расширение сокращений сопоставляет распространённые корпоративные сокращения с полными формами: cust → customer, txn → transaction, qty → quantity и так далее. И id, и key расширяются до identifier. Таблица фиксированная и осторожная: неоднозначные сокращения вроде st, min и no остаются как есть, чтобы не угадать неверно.

Отсечение прокси-токенов убирает хвостовой токен identifier, code, index или reference. Колонка с именем cust_id не называет сам идентификатор; она называет клиента через суррогатное значение. Отсечение прокси приводит и cust_id, и customerId к термину customer. Отсекаются только хвостовые токены и никогда — последний оставшийся: голая колонка id раскрывается в identifier и там и остаётся.

Смысл именно в дедупликации. Правило нормализации детерминировано, поэтому cust_id, customerId и CUSTOMER_KEY дают customer. Каждый столбец получает ссылку на этот один термин, и у курирования одно место для определения вместо трёх.

Обобщённые фразы¶

Некоторые нормализованные фразы слишком общие, чтобы быть понятием сами по себе. Голый столбец name, date или identifier называет атрибут понятия своей таблицы, которого нет отдельно от неё. У сотрудников есть имена, у товаров есть названия, но это не одно и то же.

Когда фраза попадает в обобщённый набор и доступен контекст таблицы, термин уточняется до <table concept> <phrase>: employees.first_name нормализуется в employee first name, а orders.id нормализуется в order, потому что отсечение прокси затем схлопывает уточнённую фразу в понятие, которое она идентифицирует. Этот последний случай важен: первичный ключ orders и любой внешний ключ order_id на других таблицах — все приходят к order, без дополнительного курирования.

Обобщённый набор покрывает атрибутивные существительные (name, date, status, type, amount, quantity), фразы аудиторского следа (created_at, modified_by, submitted_timestamp) и ещё несколько, встречающихся почти в каждой таблице.

Бизнес-имя, а не физическое имя¶

Выведенный термин следует бизнес-имени столбца: его псевдониму, если моделировщик его задал, а иначе физическому имени. Если у usr_nm псевдоним user name, выведенный термин будет user name, тогда как расширение usr_nm могло бы дать user number.

Задать столбцу псевдоним является более сильной правкой. Псевдоним доходит до каждой поверхности, которая читает столбец (SQL, GraphQL, ИИ-агенты, каталог), так что модель везде описывает себя верно. Переименование термина исправляет одну запись каталога, а столбец для следующего читателя по-прежнему называется usr_nm. Баннер предложенного термина в интерфейсе говорит прямо: сначала задайте псевдоним столбцу, а термин переименовывайте, только если имя столбца верно, а словарь нет.

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

Имена таблиц как путь доступа¶

Некоторые имена таблиц описывают путь доступа, а не понятие: user_by_name означает пользователя, найденного поиском по имени, а не отдельный вид сущности. Когда Provisa выводит понятие таблицы для уточнения общих фраз, он обрезает имя по связующему слову, так что user_by_name становится user, а orders_by_customer становится order.

Без обрезки суррогатный ключ user_by_name нормализовался бы в user name и столкнулся бы с настоящим атрибутом users.name: один термин обозначал бы и сущность, и одно из её собственных полей. Обрезка применяется только к понятиям таблиц. В имени столбца by входит в составное существительное, поэтому pet_by_name и pet_name нормализуются в один термин, pet name.

Что делает термин курируемым¶

Термин, рождённый нормализацией столбцов, начинается пустым: это предложение, ещё не ставшее словарём. Курированным он становится, когда выполняется любое из условий:

Сохранено определение.
Добавлено ребро связи.
Назначен профильный эксперт.
Куратор вручную вывел его из обращения.

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

Повторная синхронизация с таблицами¶

Каждый раз, когда таблица сохраняется или перезагружается, sync_table_refs сверяет колонки этой таблицы с существующими ref. Новые колонки создают термины или связываются с ними; ушедшие колонки снимают свои ref; а правило «удалить или объявить устаревшим» разрешает судьбу любого термина, потерявшего последний ref.

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

Абстрактный термин, чей единственный путь к физическим данным шёл через уходящий термин, объявляется устаревшим, а не удаляется, — так понятийная структура сохраняется до тех пор, пока её не перекоммутируют.

Связи¶

Термины соотносятся с другими терминами через типизированные рёбра. Поддерживаются такие типы связей:

Тип	Значение
`KIND_OF`	Исходный термин — разновидность целевого термина.
`PART_OF`	Исходный термин — составная часть целевого термина.
`SYNONYM_OF`	Два термина взаимозаменяемы в этой предметной области.
`RELATED_TO`	Свободная ассоциация — более сильное утверждение не подходит.
`VALID_VALUE_OF`	Исходный термин — допустимое значение целевого перечисления или домена.
`DERIVED_FROM`	Исходный термин вычисляется или берётся из целевого.
`REPLACES`	Исходный термин приходит на смену устаревшему целевому.
`PREFERRED_TERM_FOR`	Исходный термин предпочтителен по сравнению с нежелательным целевым.
`TRANSLATION_OF`	Исходный термин — перевод целевого на другой язык или локаль.
`ANTONYM_OF`	Исходный термин — семантическая противоположность целевого.

Связи направленные. UI показывает и исходящие рёбра (этот термин → другой), и входящие рёбра (другой термин → этот), помечая каждое направление собственной формулировкой на обычном языке.

Рёбра хранятся в glossary_term_edges, ассоциативной таблице, объявленной как связь через junction: её колонка rel_type служит дискриминатором, поэтому каждый из перечисленных выше типов является отдельным типом связи Cypher между двумя узлами GlossaryTerm, а не свойством реифицированного узла. Таблица разворачивается вместе с остальной схемой метаданных и не показывается как узел в графовых клиентах: она и есть ребро. Ничего специфичного для глоссария в ней нет: она объявляется так же, как вы объявили бы junction над своими таблицами, и читается тем же кодом.

Абстрактные термины¶

У абстрактного термина нет собственных ref на физические колонки. Используйте такой для бизнес- понятия, охватывающего несколько конкретных терминов: зонтик, который вы затем связываете с конкретными терминами, у которых колонки есть. Например, revenue может быть абстрактным, с рёбрами PART_OF, направленными на него от order amount, adjustment amount и refund amount.

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

Правило допуска для потребляющих поверхностей¶

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

В обращении — не выведен из обращения (куратор снял его) и не устарел (он потерял последнюю колонку и удерживался лишь потому, что его удаление оставило бы что-то висящим).
Определён — он несёт определение. Термин, выведенный из имени колонки, — это токен, а не смысл. Без определения это предложение, ожидающее куратора, но никак не словарь, на который агент может опереть вопрос.
Заземлён — соединён, через термины в обращении, хотя бы с одним термином, держащим ref на физическую колонку. Глоссарий — это точка входа в данные, поэтому каждая цепочка должна оканчиваться колонкой.

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

Экспорт метаданных¶

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

Рёбра связей публикуются только тогда, когда публикуются оба термина-конца.

Активы колонок экспортируются независимо. Исключение термина не прячет лежащие под ним данные.

Исключение термина из экспорта¶

Некоторые колонки несут служебную обвязку, а не бизнес-данные: идентификаторы ETL-пакетов, версии строк, отметки времени загрузки. У термина, выведенного из такой колонки, может быть совершенно точное определение, которое просто не является бизнес-словарём. Управляющий элемент Exclude from metadata export удерживает термин и любые рёбра связей, оканчивающиеся на нём, от каталогов, куда публикует Provisa, тогда как сами колонки по-прежнему экспортируются как активы.

Важно, пользуется ли бизнес этим словом; качество определения этого не решает. У идентификатора пакета ETL ясный смысл, которому место в глоссарии для инженеров, но не в бизнес-каталоге рядом с customer и revenue.

Работа с глоссарием¶

Откройте Admin → Glossary в UI. Левая панель перечисляет все термины; щёлкните по одному, чтобы открыть его детальное представление. Оттуда:

Rename — переименовать термин, изменив формулировку, но не перемещая его колонки.
Add a definition — ввести определение или нажать кнопку AI-черновика, чтобы сгенерировать отправную точку из имени термина, его физических колонок и его связей. Черновик не сохраняется, пока вы его не подтвердите.
Move a ref — объединить два термина: выберите целевой термин из выпадающего списка рядом с любым физическим ref. Если исходный термин теряет последний ref, его судьба автоматически решается правилом «удалить или объявить устаревшим».
Add a relationship — добавить связь между этим термином и другим, выбрав тип из закрытого набора. Переназначайте тип существующего ребра на месте, а не удаляйте и добавляйте заново.
Assign experts — назначить экспертов по идентификатору пользователя, с видом expert или author.
Retire — вывести термин из обращения. Он сохраняет свои колонки и остаётся редактируемым здесь, но и поиск терминов агентом, и экспорт метаданных его пропускают. Позже восстановите его, если понятие вернётся.
Bulk-generate definitions — заполнить все пустые определения за один проход. Записываются только пустые определения; человеческий текст никогда не перезаписывается.
Bulk-generate relationships — предложить типизированные рёбра по всему списку терминов. Некорректные предложения — неизвестные имена терминов, петли, нераспознанные типы — отбрасываются автоматически.

Баннер Proposed на термине без определения сообщает вам, является ли термин неопределённым (задайте псевдоним колонке или добавьте определение) или незаземлённым (свяжите его с термином, у которого есть колонки). Когда вы его видите, термин ещё не достижим для агентов или каталогов.

Смотрите также¶

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