Контракт метрики это то, как выглядит семантический слой, когда что-то действительно его соблюдает. Как определение закрепляется, что происходит с вопросом, называющим поля из двух хранилищ, и почему идентификаторы, попадающие в SQL, берутся из самого контракта.
Обновлено · 6 мин чтения
Опубликованное определение и закреплённое определение выглядят одинаково в браузере каталога. Оба несут имя, выражение и владельца. Разница проявляется в момент, когда кто-то задаёт вопрос.
Закрепление это то, что происходит, когда слой один раз читает собственный объект-контракт платформы и сохраняет найденное: члены, их выражения и объект, из которого они пришли. Каждый последующий вопрос разрешается по сохранённой копии, а не по тому, что набрал спрашивающий.
Сохранённая копия содержит имена и выражения, никогда строки. Она заново выучивается при каждой синхронизации: мера, добавленная в хранилище во вторник, приходит с синхронизацией во вторник, и никому не нужно помнить о том, чтобы набрать её заново.
Выученный контракт это короткий скучный документ, и скука это его достоинство.
Контракт это одновременно описание и список разрешённого. Документ, который говорит человеку, что существует, это тот же документ, который говорит построителю запросов, что можно выполнять. Второй копии, которую нужно поддерживать в согласии, никогда не бывает.
Все четыре платформы позволяют определить одно и то же, и у всех четырёх своё представление о том, как называется член. Словарь стоит уладить до первого запроса, потому что первые сбои почти всегда сбои именования, а не моделирования.
Ключ строится по сущности и имени вместе, а не по одному имени, и это пришло из работы с живой учётной записью, а не из чтения документации. Пять semantic view там определяли одно и то же имя измерения на двух сущностях, одна с гранулярностью документа, другая с гранулярностью раздела. Словарь, ключуемый только по имени, слил близнецов в одну запись, не принадлежавшую ни одному из них. Ничто не выдало ошибку, и каждый ответ, построенный на этом, был бы ошибочен так, что никто бы не увидел.
Вопрос, называющий поля из двух разных хранилищ, это разумное желание и неразумное действие. Два контракта принадлежат двум движкам, и под ними обоими нет третьего.
Слой делает две работы с одними и теми же объектами и держит их порознь. Для инвентаря одна и та же схема и таблица, увиденные в нескольких хранилищах, становятся одним логическим объектом, помнящим каждый источник, откуда он пришёл, и именно это делает отчёт о сравнении вообще возможным. Для выполнения контракт принадлежит тому хранилищу, из которого выучен, и запрос маршрутизируется туда. Вопрос, смешивающий два контракта, возвращается с указанием, что было смешано, и никогда не разрешается тихо в пользу контракта, который случайно оказался первым в списке.
Внутри одного хранилища та же форма появляется уровнем ниже. Модель, не объявляющая связи между двумя сущностями, не может ответить на вопрос, охватывающий обе, и хранилище говорит об этом своими словами. Этот ответ о моделировании стоит прочитать: он сообщает, что соединение, которое все считали существующим, никогда не было объявлено.
Сравнение между хранилищами и вычисление внутри одного это разные работы. Их разделение и позволяет одной таблице появиться один раз в отчёте об управлении и при этом вычисляться ровно в одном движке.
Когда вопрос становится инструкцией, строки, помещаемые в эту инструкцию, это собственные копии контракта. То, что набрал вызывающий, используется для поиска члена. То, что достигает SQL, это то, что сохранила синхронизация.
Это маленькое различие, и оно решает три вещи сразу.
Это свойство архитектурное, а не инструктивное. Модели можно сказать использовать только одобренные имена, и достаточно странный разговор рано или поздно её от этого отговорит. Путь в коде, который никогда не был написан, не от чего отговаривать.
Вопрос, на который контракт не может ответить, возвращается с названием проблемы, и этот ответ более полезная половина функции. Три формы покрывают почти всё, с чем вы столкнётесь.
Эти сообщения приходят от хранилища дословно, а не сглаженные в код состояния. Компилятор, описывающий собственный ответ, почти всегда точнее пересказа, а пересказ как раз и отправляет кого-то отлаживать хост, который всё это время был в порядке.
Последний пункт заслуживает второго взгляда. Хранить форму результата и отбрасывать его содержимое это то, что делает аудиторский след безопасным для хранения годами, а годы это единственная полезная длина для аудиторского следа.
Семантический слой даёт метрике один дом. Каждый инструмент, который вычисляет метрику, читает этот единственный дом. Все получают одно и то же число. Вот что это значит на практике и что меняется, когда у вас больше одного хранилища.
Доступ, который нужен слою управления, узкий, конкретный и стоит того, чтобы назвать его точно. Что читается из каталога, что значит «только для чтения», когда это структурно, а не обещано, почему ваша собственная роль в хранилище остаётся границей и что даёт наследование каталога.
Правило утверждения перед запуском простыми словами. Ассистент читает, объясняет и предлагает, а путь записи принадлежит человеку. Чего это стоит, что это даёт и три вопроса к любой функции ИИ.