Является ли файл информационной моделью

Обновлено: 21.11.2024

В озере данных папка Common Data Model – это коллекция, распределенная по подпапкам или учетным записям, файлов данных и файлов описания схемы, составляющих набор связанных сущностей. Сущности были организованы для какой-то цели, например, для поддержки приложения или выполнения анализа. Этот набор связанных данных иногда называют решением. Объект манифеста Common Data Model и содержащий его документ (*.manifest.cdm.json) — это организующий документ, действующий как точка входа, тип каталога, который указывает на части, составляющие папку Common Data Model. Манифест описывает список сущностей в решении, документ с подробным описанием схемы для каждой сущности, набор файлов данных разделов для каждой сущности, список известных взаимосвязей между сущностями и, возможно, другие объекты вложенного манифеста, которые вложенные решения.

Те, кто знаком с файлом model.json и форматом описания папки Common Data Model, увидят в манифесте эквивалентную, но расширенную концепцию. Фактически объектная модель для Common Data Model обеспечивает обратную совместимость с форматом model.json.

Манифест также можно использовать для организации чисто абстрактных определений сущностей в качестве способа совместного использования стандартных схем. В этой форме (домен Common Data Model) в манифесте перечислены объекты с документами схемы, известными отношениями и вложенными манифестами, но не указаны местоположения файлов данных разделов для объектов.

Одна папка с файлами может содержать множество файлов манифеста. Каждый из них может представлять альтернативный вид или организацию сущностей. Эти представления можно использовать, чтобы скрыть, упростить или сфокусировать сущности решения для разных пользователей или показать разные бизнес-перспективы. По соглашению, когда в папке существует несколько файлов манифеста, используется файл с именем default.manifest.cdm.json, если не указано конкретное имя манифеста.

Декларация местного объекта

Список шаблонов разделов

Объявление ссылочного объекта

Импорт в манифест

Как описано ранее, манифест может импортировать другие документы определения файла. Поскольку в манифесте используются трейты Common Data Model, обычно одного импорта документа cdm:/foundations.cdm.json достаточно, чтобы получить стандартные определения для этих трейтов.

Общие концепции внутри манифеста

Объект Manifest и содержащиеся в нем объекты имеют общие свойства, наборы и возможности (методы в объектной модели).

Списки объектов в манифесте

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

Объявление местного объекта

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

< td>Имя принадлежащего объекта

Свойство/метод	Описание
entityName
entityPath	Корпусный путь к определению объекта в содержащем его документе, например, local:/MyEntity. cdm.json/MyEntity. По соглашению это определение сущности должно быть "разрешенной" формой определения. Больше информации. Это схема по умолчанию, которую следует использовать для любого файла раздела, который не предлагает специализированную альтернативную схему.
dataPartitions	Объекты dataPartitions в этом каждая коллекция описывает местоположение, формат и, возможно, конкретные сведения об одном файле, содержащем записи данных для локального объекта.
dataPartitionPatterns	Объект dataPartitionPatterns описывает пространство поиска в наборе файлов, которое можно использовать для вывода или обнаружения и списка новых файлов раздела данных. Эти шаблоны используются в ситуациях, когда регулярно добавляется множество новых файлов разделов каким-либо структурированным образом, и поиск или перечисление их по отдельности нецелесообразно.

Определения разделов данных в коллекции dataPartitions

Объект dataPartitionDefinition описывает и указывает на один конкретный файл данных для объекта. Черты Common Data Model для этого объекта предоставляют подробную информацию о формате файла и параметрах синтаксического анализа. По умолчанию данные должны интерпретироваться с использованием описания схемы, указанного в соответствующем объявлении локального объекта. Однако, поскольку схемы могут меняться со временем, а старые файлы могут иметь другое содержимое, чем новые файлы, схема объекта по умолчанию может быть переопределена для определенного файла раздела.

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

< td>Необязательное имя раздела. < /таблица>

Свойства, относящиеся к разделу данных

Коллекция Traits для раздела используется для хранения настроек и поведения, специфичных для раздела.

Свойство/Метод	Описание
dataPartitionName
Местоположение	Путь корпуса к местоположению и имени файла данных.
Предполагаемый	Логический. Установите значение True, если объект раздела был создан с использованием объекта dataPartitionPatterns и существует только в памяти объектной модели. Если установлено значение False, информация о разделе будет сохранена вместе с папкой и переопределит любые идентичные разделы, которые появятся в будущем.
specializedSchema	An необязательный путь к корпусу, указывающий на определение сущности в содержащем документе. Цель этого документа — описать этот раздел как переопределение формы данных по умолчанию, которая обычно берется из свойства entitySchema для объявления объекта, содержащего этот раздел.
refreshTime< /td>	Место для приложения, которому принадлежит манифест, для хранения «времени обновления» для данных в файле.
Аргументы	Сопоставление имен аргументов со значением или значениями, связанными с этим аргументом. Массив объектов dataPartitionArgument, содержащих набор пар имя/значение. Если раздел создается из объекта dataPartitionPatterns, имена этих аргументов будут соответствовать параметрам, указанным в объекте шаблона, а значения будут найдены из регулярного выражения шаблона.

< /tr>

Признак/параметр	Описание
is.partition.format. CSV	Обозначает текстовый файл с фиксированным набором столбцов с разделителями столбцов, квалификаторами текста и т. д.
columnHeaders	Истина, если первая строка файла содержит имена столбцов.
csvStyle	Или CsvStyle.QuoteAlways или < em>CsvStyle.QuoteAfterDelimiter. Значение по умолчанию: Csv.QuoteAlways.
delimiter	Тип разделителя в файле CSV.
quoteStyle	Либо QuoteStyle.Csv, либо QuoteStyle.None. Значение по умолчанию — QuoteStyle.Csv, что означает, что текстовые значения заключаются в кавычки.
is.partition.format.parquet	Значение представляет собой настройки формата файла файла паркета раздела.
is.partition.culture	Культура для форматов данных в файле .
culture	Значение по умолчанию — us-en.

Шаблоны разделов данных

Объявление сущности может указывать один или несколько объектов dataPartitionPatterns, по одному для каждого шаблона поиска, который можно использовать для обнаружения и описания файлов разделов. В объектной модели для Common Data Model использование шаблона может привести к динамически обнаруженным объектам dataPartitions в коллекции dataPartitions.

< td>Путь к корпусу, выступающий в качестве начального местоположения, из которого должны сопоставляться шаблоны, упомянутые в свойстве RegularExpression, или из которого должна начинаться объектная модель при поиске предполагаемых разделов данных.

Свойство/Метод	Описание
rootLocation
regularExpression	Регулярное выражение, которое может содержать (захватывать) подвыражения для искомых папок и файлов. Это регулярное выражение должно описывать местоположения относительно местоположения, указанного в свойстве rootLocation. Все захваченные значения должны иметь соответствующие имена в списке параметров в том же порядке.
globPattern	Шаблон glob, соответствующий набору файлов и папки. Шаблон glob можно использовать в качестве альтернативы регулярному выражению, а также он должен описывать местоположения относительно местоположения, указанного в свойстве rootLocation.Набор поддерживаемых символов универсального шаблона можно найти здесь.
Параметры	Массив строк, которые задают имена для замещающих значений, извлеченных из регулярного выражения. . Порядок строк соответствует порядку (замещения) выражений захвата в регулярном выражении. Если шаблон раздела данных используется для создания предполагаемых разделов, каждый результирующий предполагаемый раздел будет иметь набор аргументов, соответствующих этим именам параметров и обнаруженным значениям.
specializedSchema	Необязательно. Путь корпуса, указывающий на определение объекта. Путь будет использоваться для свойства specialSchema для любых разделов, созданных на основе этого шаблона. Используется, когда данные раздела будут иметь схему, отличную от схемы, используемой по умолчанию для содержащего объекта.

В следующих примерах показано взаимодействие rootLocation, RegularExpression и Parameters.

Все файлы CSV в определенной папке

Создайте раздел для каждого файла данных CSV клиента, находящегося в папке Customer/dataFiles/ (относительно папки, в которой находится документ манифеста). Предположим, что подкаталогов нет.

Customer/dataFiles/last-year.csv.backup (не соответствует)

< tbody>

rootLocation	regularExpression	объяснение	параметры
Customer/dataFiles/	.+\.csv$	Один или несколько любых символов, за которыми следует только .csv	Нет необходимости

Все файлы CSV в структурированных папках с информацией в пути к файлу

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

dataFiles/2016/June/cohort001.csv

dataFiles/2016/June/cohort002.csv

dataFiles/2017/April/cohort001.csv

< tbody>

rootLocation	regularExpression	объяснение	параметры
dataFiles/	(\d)/(\w+)/ cohort(\d+)\.csv$	Захват четырех цифр/Захват слова / Захватить одну или несколько цифр после слова когорта, но до .csv	Год, месяц, номер когорты

Все файлы в любой подпапке

Извлеките расширение имени файла.

dataFiles/2017/April/cohort001.txt

dataFiles/2017/May/cohort001.csv.save

< tbody>

rootLocation	regularExpression	объяснение	параметры
dataFiles/	.+\.(\w+)$	Один или несколько символов, за которыми следует только точка (.) и захваченное слово< /td>	расширение

Порядок обработки разделов и разрешения конфликтов

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

Выведенные разделы никогда не перезапишут существующие, не выведенные разделы в том же объекте.

Последний обработанный шаблон будет иметь приоритет.

Объявление ссылочного объекта

Ссылка на объект, принадлежащий другому манифесту, представляет собой не что иное, как имя и местоположение.

< td>Имя объекта, на который ссылаются.

Свойство/метод	Описание
entityName
entityPath	Корпусный путь к объявлению объекта в указанном документе манифеста, например, remote:/otherSolution /default.manifest.cdm.json/ThatEntity

Объект subManifest

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

Манифест содержит набор объявлений манифеста с именами subManifests.

< td>Путь корпуса к документу *.manifest.cdm.json вложенного манифеста

Свойство/Метод	Описание
Определение

Отношения объектов

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

Эти описания отношений между объектами можно извлечь из внешнего хранилища метаданных и сохранить в манифесте с помощью автоматизации или просто перечислить в документе с помощью других средств. В качестве альтернативы объектная модель для Common Data Model предлагает функции, которые анализируют логические метаданные сущностей в корпусе и заполняют обнаруженные связи для манифеста.

В настоящее время поддерживаются только отношения с одним атрибутом. Все отношения моделируются от стороны «многие» к стороне «одна»; то есть от ссылочного объекта к одной ссылочной записи в другом объекте. Отношение "многие ко многим" моделируется на основе объекта пересечения, который связывает два отношения "многие к одному".

< tr>

Свойство	Описание
fromEntity	Путь корпуса к документу или объекту на "многих" сторонах отношения.
fromEntityAttribute	Имя атрибута ссылки, внешний ключ .
toEntity	Корпусный путь к документу или сущности на "одной" стороне отношения.
toEntityAttribute	Имя ссылочного атрибута, часто первичный ключ этого объекта.
имя	Имя отношения.
exhibitsTraits	Набор признаков, который первоначально применяется к целевому объекту в атрибуте ссылки, а затем повышается до отношения как значения отношений.
Corpus.CalculateEntityGraph(ICommon Data ModelManifestDef rootManifest);	Заставляет корпус вычислять и кэшировать знания обо всех объектах отношения между объектами находится в описаниях логических объектов для данного манифеста и всех подманифестов, на которые он указывает.
Manifest. PopulateManifestRelationships()	Манифест будет использовать граф взаимосвязей, хранящийся в корпусе, для создания набора описаний взаимосвязей для любой сущности, которая находится либо на стороне «одна», либо на стороне «многих» известного отношения .

Время проверки и модификации файла

Объект Manifest и содержащиеся в нем объекты собирают и сообщают информацию о времени изменения файлов, на которые они ссылаются.

< td>Время последней проверки состояния файлов и дочерних объектов. Это устанавливается напрямую с помощью логики приложения или косвенно с помощью метода fileStatusCheck.

Свойство/Метод	Описание
LastFileStatusCheckTime
LastFileModifiedTime	Время последнего сообщения файловой системы о любых изменениях или сохранении файла.
LastChildFileModifiedTime	Последнее время, сообщаемое любым из дочерних объектов о времени проверки их состояния файла. Поскольку метод fileStatusCheck может вызываться для отдельных объектов, а отдельные файлы могут обновляться в разное время, это свойство помогает найти последний измененный дочерний элемент.

Значение этих значений времени и объем метода проверки статуса зависят от конкретного проверяемого объекта.

Object	fileStatusCheck
Манифест	Проверяет манифест, все объявления сущностей и все вложенные манифесты.
Локальный объект	Проверяет документы схемы и все разделы данных и шаблоны для объекта.
Ссылочный объект	Проверяет статус документа удаленного манифеста.
dataPartition	Проверяет файл, указанный разделами, и необязательный документ alterSchema.
dataPartitionPattern	Вызывает оценку поиска шаблона раздела данных и создание новых разделов.
SubManifest	Проверяет файлы вложенных манифестов.

Пример документа манифеста

Следующий документ манифеста демонстрирует каждую из вышеупомянутых возможностей объекта Manifest.

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

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

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

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

Структура и общий синтаксис

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

Выше мы видим исследование с именем inventory_items в файле модели вместе с объединенными представлениями. Это определение LookML приводит к тому, что элементы инвентаря появляются в меню "Обзор" и объединяют данные из inventory_items с продуктами и центрами распределения .

Дополнительную информацию о структурах LookML в файле модели см. на странице документации по терминам и понятиям LookML.

Создание файлов модели

Большинство разработчиков LookML начинают с одного или нескольких файлов моделей, которые создаются автоматически при создании проекта LookML из набора таблиц в базе данных.

Кроме того, разработчик Looker в режиме разработки может создать пустой файл модели следующими способами:

Использование параметра «Создать файл модели» для создания файла с помощью Looker IDE (процедуру см. в разделе «Создание файлов» на странице документации по файлам проекта LookML).
Использование функции перетаскивания для загрузки файла с вашего компьютера (процедуру см. в разделе Загрузка файлов на странице документации по файлам проекта LookML). Обязательно используйте расширение файла .model.lkml для загружаемого файла.

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

Если вам нужно переименовать модель или любой объект в модели, не переименовывайте файл или сам объект. Вместо этого используйте параметр label или alias, чтобы изменить отображаемое имя файла или объекта. Параметры label и alias изменяют отображаемое имя, сохраняя базовый URL-адрес, используемый для электронной почты или других систем.

В целом следует принять меры предосторожности, чтобы сделать изменения модели как можно более неинвазивными. Если вам нужно переименовать модель или объект, используйте Content Validator, чтобы обновить все ссылки на модель или объект.

Если вы удалите файл модели, модель не будет удалена ни из одного набора моделей, к которому она принадлежала. Если создается новый файл модели с тем же именем, что и у удаленной модели, новая модель включается во все наборы моделей, включающие удаленную модель. Это может привести к нежелательному доступу к новому файлу модели. Администраторы Looker могут редактировать наборы моделей и удалять удаленные модели, чтобы предотвратить эту проблему.

Подробнее о параметрах в файлах моделей

Прочитайте страницы документации по параметрам модели, параметрам исследования и параметрам объединения, чтобы узнать больше о параметрах LookML в файле модели.

Файл представления обычно определяет одно «представление» в Looker. Представление соответствует либо одной таблице в вашей базе данных, либо одной производной таблице.

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

Структура и общий синтаксис

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

Выше мы видим идентификатор измерения, определенный как поле в представлении «Элементы заказа». Это определение предоставляет поле ID для запросов в обзоре элементов заказа.

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

Дополнительную информацию о структурах LookML в файле представления см. на странице документации по терминам и понятиям LookML.

Размеры

Поля в Looker разделены на измерения и меры. Параметр может быть одним из двух:

В Looker измерения всегда появляются в предложении GROUP BY SQL, который генерирует Looker.

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

Меры

Мера вычисляет значения по нескольким строкам. Это эквивалентно агрегатным функциям SQL, таким как COUNT(), SUM(), AVG(), MIN() и MAX(). Меры также могут выполнять простые преобразования других мер. Чтобы узнать больше, ознакомьтесь с нашей документацией по типам показателей.

Выше мы видим измерения и меры, определенные в файле представления продуктов.

Создание файлов просмотра

Большинство разработчиков LookML начинают с одного или нескольких файлов представлений, которые создаются автоматически при создании проекта LookML из набора таблиц в базе данных. Однако разработчик Looker в режиме разработки может добавлять файлы представлений в проект LookML разными способами:

Создание файлов представлений на основе таблиц в базе данных:

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

Создание пустых файлов представления:

Использование функции перетаскивания для загрузки файла с вашего компьютера, как описано в разделе "Загрузка файлов" на странице документации по файлам проекта LookML. Обязательно используйте расширение .view.lkml для загружаемого файла.

Создание файла представления для производной таблицы:

Попросите Looker создать производную таблицу LookML из исследования, как описано в разделе «Использование исследования для начала определения собственных производных таблиц» на странице документации «Создание собственных производных таблиц». Заставьте Looker создать производную таблицу LookML из запроса SQL Runner, как описано на странице документации Использование SQL Runner для создания производных таблиц.

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

Добавление нового представления из существующей таблицы базы данных

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

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

Нажмите «Создать представление из таблицы».

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

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

Прокрутите страницу вниз и нажмите "Создать представления".

Looker создает представления, содержащие LookML, для всех столбцов таблицы.

Подробнее о параметрах в файлах представлений

Подробнее о параметрах просмотра можно узнать на странице документации по параметрам просмотра.

Дополнительные сведения о параметрах LookML для измерений, показателей, групп измерений и полей фильтра см. на странице документации по параметрам полей.

Другие ресурсы

help_center Справочный центр

В нашем Справочном центре есть дополнительные короткие статьи о конкретных случаях использования и особых ситуациях.

форум Сообщество

Форумы сообщества Looker — отличное место для обсуждения передового опыта, устранения уникальных проблем и общения с другими пользователями Looker.

школа Подключиться

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

Примеры основаны на гипотетических данных.
© 2012- Looker Data Sciences, Inc.
Политика конфиденциальности | Условия использования

Файл метаданных (или model.json) в папке Common Data Model описывает данные в папке, метаданные и расположение, а также способ создания файла и поставщика данных.

Файл модели позволяет:

Обнаруживаемость на основе метаданных производителя данных.
Получение семантической информации о записях/атрибутах сущностей и ссылок на базовые файлы данных
Указывает на соответствие стандартным объектам Common Data Model
Информация о последних обновлениях объектов.

Загрузите схему файла model.json.

Содержимое файла модели

Содержимое папки Common Data Model описывается стандартным файлом метаданных .json, который содержит следующие ключевые категории метаданных:

Метаданные, применимые ко всем объектам в папке, например описание, время последнего изменения и культура данных

Общие метаданные, такие как тип, описание и т. д.

Атрибуты, включая метаданные, такие как типы данных

[необязательно] Соответствие стандартным формам схемы объектов Common Data Model

Например, данный объект в папке соответствует всем атрибутам, необходимым для «базового» объекта Аккаунта

Расположения файлов данных (разделов) и метаданные о кодировании файлов данных

Существующие объекты и файлы данных, на которые ссылается этот файл model.json

Описывает отношения между сущностями

В дополнение к стандартным элементам можно добавить дополнительные элементы или расширения, зависящие от производителя, с префиксом, например "pbi:mashup", где "pbi:" – это префикс. Потребители могут игнорировать эти поля, но библиотеки проверят поля, чтобы не потерять достоверность.

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

Корневые свойства

Эти свойства перечислены в корне файла model.json и описывают свойства, относящиеся ко всем сущностям, связям и т. д.

Аннотации

Имя свойства: аннотации

Дополнительная, несущественная контекстная информация (пары ключ/значение), которую можно использовать для хранения дополнительного контекста о свойстве в файле модели. Аннотации можно применять на нескольких уровнях, в том числе к объектам и атрибутам. Производители могут добавить префикс, например "pbi:MappingDisplayHint", где "pbi:" – это префикс, если аннотации не обязательно имеют отношение к другим потребителям.

Свойство	Тип	Описание	Обязательно?
name	string	Имя аннотации	Да
value	string	Значение аннотации	Нет

Эталонные модели

Имя свойства: referenceModels

Эталонные модели — это существующие файлы model.json с сущностями и файлами данных, на которые ссылается этот файл model.json. Это позволяет повторно использовать существующие метаданные и данные, не копируя их в эту папку Common Data Model.

Свойство	Тип	Описание	Обязательно?
id	string	Идентификатор модели, на которую ссылаются, для использования в этом файле model.json. Это значение должно быть уникальным в пределах этого файла модели и может использоваться как сокращение свойства местоположения. Конкретное значение зависит от исполнителя.	Да
location	URI	Расположение модель, на которую ссылаются. URI должен включать версию/моментальный снимок модели, с которой согласуется эта модель. (При обновлении этой модели она должна соответствующим образом обновить версию/моментальный снимок.)	Да

Объекты

Имя свойства: сущности

Сущность – это набор атрибутов и метаданных, определяющих понятие (например, "Учетная запись" или "Контакт"), которые могут быть определены любым производителем данных. Сущность может соответствовать схеме стандартной сущности, определенной как часть Common Data Model и указанной в репозитории GitHub. Объекты, не соответствующие одной из стандартных форм, называются пользовательскими объектами.

В файле model.json можно указать локальные или ссылочные объекты. Локальный объект содержит сведения об объекте (например, атрибуты, схемы и разделы), определенные в файле model.json, и ожидается, что файлы данных будут находиться в одной и той же папке Common Data Model. Ссылочный объект — это указатель на объект, определенный ссылочной моделью, в которой определены все метаданные и файлы данных.

В зависимости от типа объекта могут быть определены разные поля:

< td>$type

Свойство	Местный объект	Ссылочный объект
R	R
имя	R	R
описание	O	O
аннотации	O	O
схемы	O
атрибуты	R
разделы	O
источник	R
modelId	R

R - обязательный, O - необязательный, (пусто) - н/д

Свойства уровня сущности

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

Атрибуты

Имя свойства: атрибуты

Атрибуты – это поля внутри объекта, которые соответствуют значениям данных в файле данных. Например, объект «Контакт» может иметь такие атрибуты, как имя и фамилия.

Свойство	Тип	Описание	Обязательно?
имя	строка	имя атрибута	Да
description	string	описание атрибута	No
dataType	enum	Для этого атрибута должно быть установлено одно из следующих значений: строка, int64, double, dateTime, dateTimeOffset, decimal, boolean, GUID или JSON. Если культура указана, ее следует использовать для анализа типа данных. Дополнительная информация	Да
аннотации	Аннотации[]	Массив необязательных аннотаций модели — не- основные пары ключ/значение, которые содержат контекстную информацию, которую можно использовать для хранения дополнительного контекста	Нет

Разделы

Имя свойства: разделы

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

Свойство	Тип	Описание	Обязательно?
имя	string	Имя раздела	Да
description	string	Описание раздела	Нет
refreshTime	datetimeoffset	Самая последняя дата обновления данных раздела в смещении даты и времени согласно ISO 8601	Нет
местоположение	URI	Физическое расположение файла раздела, включая сам файл. Если значение null, это определение сущности предназначено только для целей схемы.	Нет
fileFormatSettings	FileFormatSettings	Дополнительные настройки формата файла.	Нет

Настройки формата файла

Имя свойства: fileFormatSettings

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

Свойство	Тип	Описание	Требуется ли CsvFormatSetting?
$type	string (enum)	Определяет тип настройки формата файла. На момент написания этой статьи поддерживается только «CsvFormatSettings».	Да
columnHeaders	boolean	Указывает, есть ли заголовки в CSV-файле. Этот атрибут должен быть установлен в значение «true» или «false». Если не указано, это может быть интерпретировано как false.	Нет
delimiter	string	тип разделителя в файле .csv. Если не указано, это может интерпретироваться как «,»	Нет
кодировка	string	Кодировка строки в CSV-файле. Если не указано, это может интерпретироваться как «UTF-8»	No
quoteStyle	string (enum)	Стиль цитаты CSV. Этот атрибут должен иметь значение «QuoteStyle.Csv» или «QuoteStyle.None». Если не указано, это может интерпретироваться как «QuoteStyle.Csv».	Нет
csvStyle	string (enum)< /td>	Стиль CSV, значения: для этого атрибута должно быть установлено значение «CsvStyle.QuoteAlways» или «CsvStyle.QuoteAfterDelimiter». По умолчанию установлено значение «CsvStyle.QuoteAlways»	Нет

Отношения

Имя свойства: отношения

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

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

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

Структура и общий синтаксис

Создание файлов модели

Кроме того, разработчик Looker в режиме разработки может создать пустой файл модели следующими способами:

Использование параметра «Создать файл модели» для создания файла с помощью Looker IDE (процедуру см. в разделе «Создание файлов» на странице документации по файлам проекта LookML).
Использование функции перетаскивания для загрузки файла с вашего компьютера (процедуру см. в разделе Загрузка файлов на странице документации по файлам проекта LookML). Обязательно используйте расширение файла .model.lkml для загружаемого файла.

Если вам нужно переименовать модель или любой объект в модели, не переименовывайте файл или сам объект. Вместо этого используйте параметр label или alias, чтобы изменить отображаемое имя файла или объекта. Параметры label и alias изменяют отображаемое имя, сохраняя базовый URL-адрес, используемый для электронной почты или других систем.

В целом следует принять меры предосторожности, чтобы сделать изменения модели как можно более неинвазивными. Если вам нужно переименовать модель или объект, используйте Content Validator, чтобы обновить все ссылки на модель или объект.

Если вы удалите файл модели, модель не будет удалена ни из одного набора моделей, к которому она принадлежала. Если создается новый файл модели с тем же именем, что и у удаленной модели, новая модель включается во все наборы моделей, включающие удаленную модель. Это может привести к нежелательному доступу к новому файлу модели. Администраторы Looker могут редактировать наборы моделей и удалять удаленные модели, чтобы предотвратить эту проблему.

Подробнее о параметрах в файлах моделей

Структура и общий синтаксис

Размеры

Поля в Looker разделены на измерения и меры. Параметр может быть одним из двух:

В Looker измерения всегда появляются в предложении GROUP BY SQL, который генерирует Looker.

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

Меры

Мера вычисляет значения по нескольким строкам.Это эквивалентно агрегатным функциям SQL, таким как COUNT(), SUM(), AVG(), MIN() и MAX(). Меры также могут выполнять простые преобразования других мер. Чтобы узнать больше, ознакомьтесь с нашей документацией по типам показателей.

Выше мы видим измерения и меры, определенные в файле представления продуктов.

Создание файлов просмотра

Создание файлов представлений на основе таблиц в базе данных:

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

Создание пустых файлов представления:

Использование функции перетаскивания для загрузки файла с вашего компьютера, как описано в разделе "Загрузка файлов" на странице документации по файлам проекта LookML. Обязательно используйте расширение .view.lkml для загружаемого файла.

Создание файла представления для производной таблицы:

Попросите Looker создать производную таблицу LookML из исследования, как описано в разделе «Использование исследования для начала определения собственных производных таблиц» на странице документации «Создание собственных производных таблиц». Заставьте Looker создать производную таблицу LookML из запроса SQL Runner, как описано на странице документации Использование SQL Runner для создания производных таблиц.

Добавление нового представления из существующей таблицы базы данных

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

Нажмите «Создать представление из таблицы».

Прокрутите страницу вниз и нажмите "Создать представления".

Looker создает представления, содержащие LookML, для всех столбцов таблицы.

Подробнее о параметрах в файлах представлений

Подробнее о параметрах просмотра можно узнать на странице документации по параметрам просмотра.