1С типы данных: Система типов

Система типов

Система типов — это особая система, по которой организуются данные, используемые прикладными решениями. Система типов позволяет представить информацию реального мира в терминах, «понятных» для «1С:Предприятия 8».

Система типов предоставляет широкие возможности как для описания непосредственно бизнес-логики прикладных решений, так и для выполнения задач промежуточной обработки данных.

Описание системы типов содержится в синтакс-помощнике, во встроенной справке и в документации.

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

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

Типы данных, определенные на уровне платформы

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

Примитивные типы

Примитивные типы данных — это такие типы как Строка, Число, Дата, Булево и другие. Эти типы не являются чем-то особенным для «1С:Предприятия 8». Как правило, такие типы данных существуют и в других программных системах.

Значения примитивных типов являются простыми неделимыми значениями, в которых нельзя выделить отдельные составляющие.

Например, значениями типа Число могут быть 1, 8, 15 и др. Чтобы создать значение примитивного типа, в тексте программы нужно указать его литерал — символьный идентификатор значения.

Универсальные коллекции значений

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

Общие типы

Кроме этого в платформе реализованы специфические типы данных, реализующие ту или иную функциональность прикладных решений: ТекстовыйДокумент, ТабличныйДокумент, ХранилищеЗначения, ПостроительЗапроса

и другие.

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

Экземпляры объектов создаются с помощью специального оператора встроенного языка — Новый.

Интерфейсные типы

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

Типы данных, образуемые в прикладном решении

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

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

На уровне платформы поддерживается несколько классов (шаблонов) прикладных объектов, которые сами по себе не могут быть использованы в конкретном прикладном решении. Например, можно перечислить такие классы прикладных объектов как Справочники, Документы, Регистры сведений, Планы видов характеристик

и пр.

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

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

Например, разработчик может добавить в свое прикладное решение новый справочник Номенклатура, который будет наследовать функциональность класса Справочники, или новый документ КассовыйОтчет, который будет наследовать функциональность класса Документы.

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

Например, после создания нового справочника Номенклатура, становятся доступны следующие типы данных:

• СправочникМенеджер.Номенклатура;
• СправочникСсылка.Номенклатура;
• СправочникОбъект.Номенклатура;
• СправочникВыборка.Номенклатура;
• СправочникСписок.Номенклатура.

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

В то же время, после создания нового регистра накопления

ПродажиКомпании, состав новых типов данных будет уже другим:

• РегистрНакопленияМенеджер. ПродажиКомпании,
• РегистрНакопленияВыборка.ПродажиКомпании,
• РегистрНакопленияСписок.ПродажиКомпании,
• РегистрНакопленияНаборЗаписей.ПродажиКомпании,
• РегистрНакопленияЗапись.ПродажиКомпании,
• РегистрНакопленияКлючЗаписи.ПродажиКомпании.

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

Еще один момент, на котором следует акцентировать внимание, проще всего продемонстрировать на примере.

Допустим, в прикладном решении созданы два новых справочника: Номенклатура и Цены. Несмотря на то, что оба эти объекта унаследовали функциональность соответствующего класса

Справочники, и для них в прикладном решении был создан один и тот же состав типов данных, «одноименные» типы данных будут являться различными типами данных. Например, СправочникОбъект. Номенклатура и СправочникОбъект.Цены — это различные типы данных.

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

СправочникОбъект.Номенклатура будет значительно отличаться от структуры хранения данных типа СправочникОбъект.Цены.

Платформа 1С:Предприятия 8. Предопределенные типы данных

Предопределенные типы данных

Платформа 1С:Предприятия 8.0 позволяет разработчику использовать различные типы данных. Существует большое количество типов данных, которые определены на уровне самой платформы. Например, это примитивные типы данных, такие как строка, число, дата и пр.:

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

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

Типы данных, образуемые в прикладном решении

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

Как правило, появление новых типов данных в прикладном решении связано с использованием прикладных объектов. На уровне технологической платформы поддерживается несколько классов прикладных объектов, которые сами по себе не могут быть использованы в конкретном прикладном решении. Например, можно перечислить такие классы прикладных объектов как Справочники, Документы, Регистры сведений, Планы видов характеристик и пр.

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

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

Например, разработчик может добавить в свое прикладное решение новый справочник Номенклатура, который будет наследовать функциональность класса Справочники, или новый документ КассовыйОтчет, который будет наследовать функциональность класса Документы.

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

Например, после создания нового справочника Номенклатура, становятся доступны следующие типы данных:

• СправочникМенеджер.Номенклатура;
• СправочникСсылка.Номенклатура;
• СправочникОбъект.Номенклатура;
• СправочникВыборка.Номенклатура;
• СправочникСписок.Номенклатура.

В то же время, после создания нового регистра накопления ПродажиКомпании, состав новых типов данных будет уже другим:

• РегистрНакопленияМенеджер.ПродажиКомпании;
• РегистрНакопленияВыборка.ПродажиКомпании;
• РегистрНакопленияСписок.ПродажиКомпании;
• РегистрНакопленияНаборЗаписей.ПродажиКомпании;
• РегистрНакопленияЗапись.ПродажиКомпании;
• РегистрНакопленияКлючЗаписи.ПродажиКомпании.

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

Еще один момент, на котором следует акцентировать внимание, проще всего продемонстрировать на примере.

Допустим, в прикладном решении созданы два новых справочника: Номенклатура и Цены. Несмотря на то, что оба эти объекта унаследовали функциональность соответствующего класса Справочники, и для них в прикладном решении был создан один и тот же состав типов данных, одноименные типы данных будут являться различными типами данных. Например, СправочникОбъект.Номенклатура и СправочникОбъект.Цены — это различные типы данных.

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

Руководства пользователя — Sentinel-2 MSI — Типы продуктов — Sentinel Online

Руководство пользователя Sentinel-2 MSI — Типы продуктов

Продукты SENTINEL-2, доступные для Пользователей, перечислены в Таблицах 1 и 2.

Таблица 1: Типы продуктов Sentinel-2

Продукт пользователя	Уровень-1B	Яркость верхней части атмосферы в геометрии датчика	Опытные пользователи	Систематическая генерация и онлайн-распространение
	Уровень-1С	Отражение верхних слоев атмосферы в картографической геометрии	Все пользователи	Систематическая генерация и онлайн-распространение
	Уровень-2А	Поверхностная отражательная способность с поправкой на атмосферу в картографической геометрии

 

Дополнительно по запросу создаются следующие пилотные продукты:

Таблица 2: Типы пилотных продуктов Sentinel-2

Пилотные продукты	Уровень-2H	Гармонизированные коэффициенты отражения поверхности Sentinel-2 + Landsat-8/9 в картографической геометрии	Все пользователи	Пилотное производство по запросу
	Уровень-2F	Fused Sentinel-2 + Landsat-8/9 отражения поверхности в картографической геометрии

 

Непрерывный сбор данных изображения SENTINEL-2 в заданном режиме MSI называется «сбором данных». Максимальная длина набора изображений составляет 15 000 км (например, непрерывное наблюдение от севера России до юга Африки). Все продукты содержат гранулы/плитки из одного набора данных. Сбор данных представлен внутри продукта в виде набора одной или нескольких полос данных (соответствующих сегментам сбора данных, переданным по нисходящей линии связи с различными наземными станциями).

Продукты представляют собой элементарные гранулы фиксированного размера на одной орбите. Гранула – это минимальная неделимая часть продукта (содержащая все возможные спектральные полосы).

Гранулы уровня 1B представляют собой небольшие изображения в геометрии сенсора, воспринимаемые каждым из двенадцати детекторов MSI, размером 23×25 км ² .

Для уровней 1C и 2A гранулы, также называемые тайлами, представляют собой ортоизображения размером 110×110 км² в проекции UTM/WGS84. Земля разделена на предопределенный набор плиток, заданных в проекции UTM/WGS84 с шагом 100 км. Однако каждая плитка имеет площадь 110×110 км², чтобы обеспечить большое перекрытие с соседней. Система UTM (Universal Transverse Mercator) делит поверхность Земли на 60 зон. Каждая зона UTM имеет ширину по вертикали 6° долготы и ширину по горизонтали 8° широты (см. рисунок 1).

Рисунок 1: Мозаика продукта уровня 1C

Мозаика может быть полностью или частично покрыта данными изображения. Частично покрытые плитки соответствуют плиткам на краю или вверху/внизу полосы данных.

Загрузите сетку листов Sentinel-2 kml.

Sentinel-2 Руководство пользователя MSI Ключевые ресурсы

7.4 Тип элемента данных

7.4 Тип элемента данных

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

Тип элемента данных атрибута определения информационного объекта или атрибута определения класса SOP используется для указания, является ли этот атрибут обязательным или необязательным. Тип элемента данных также указывает, является ли атрибут условным (обязательным только при определенных условиях). Типы элементов данных атрибутов составных IOD указаны в PS3.3. Типы элементов данных атрибутов нормализованных IOD указаны как атрибуты классов SOP в PS3.4.

7.4.1 Обязательные элементы данных типа 1

Классы IOD и SOP

определяют элементы данных типа 1, которые должны быть включены и являются обязательными элементами. Поле значения должно содержать действительные данные, определенные элементами VR и VM, как указано в PS3.6. Длина поля значения не должна быть равна нулю. Отсутствие допустимого значения в элементе данных типа 1 является нарушением протокола.

Примечание

1. Для элементов данных со строкой (CS, SH, LO), а не двоичным, текстовым или последовательным представлением значения, и для которых разрешено несколько значений, наличие одного значения достаточно для удовлетворения требования типа 1, если не указано иное. в описании Атрибута и другие Значения могут быть пустыми, если иное не указано IOD. Присутствия только одного или нескольких символов-разделителей (BACKSLASH) без каких-либо значений недостаточно для удовлетворения требования типа 1, поскольку даже если длина значения больше нуля, действительное значение отсутствует.

2. Элемент данных последовательности типа 1 будет содержать один или несколько элементов, как определено в IOD (независимо от VM последовательности, которая всегда одна (раздел 7.5)). Могут ли эти элементы быть пустыми (не содержать элементов данных) зависит от определения IOD набора данных для каждого элемента.

7.4.2 Элементы условных данных типа 1C

Классы IOD и SOP определяют элементы данных, которые должны быть включены при определенных условиях. Элементы типа 1C имеют те же требования, что и элементы типа 1 в этих условиях. Нарушение протокола, если выполняются указанные условия, а элемент данных не включен.

При невыполнении указанных условий элементы типа 1C не включаются в набор данных.

7.4.3 Обязательные элементы данных типа 2

Классы IOD и SOP

определяют элементы данных типа 2, которые должны быть включены и являются обязательными элементами данных. Однако допустимо, что если значение для элемента типа 2 неизвестно, оно может быть закодировано с нулевой длиной значения и без значения. Если значение известно, поле значения должно содержать это значение, определенное элементами VR и VM, как указано в PS3.6. Эти элементы данных должны быть включены в набор данных, и их отсутствие является нарушением протокола.

Примечание

1. Назначение элементов данных типа 2 состоит в том, чтобы обеспечить передачу нулевой длины, когда оператор или приложение не знает ее значения или имеет конкретную причину не указывать ее значение. Предполагается, что устройство должно поддерживать эти элементы данных.

2. Элемент данных последовательности типа 2 будет содержать ноль или более элементов, как определено IOD (независимо от VM последовательности, который всегда равен единице (раздел 7.5)). Пустая последовательность Типа 2 — это последовательность без элементов, в отличие от элемента, который присутствует, но пуст. Могут ли элементы быть пустыми (не содержать элементов данных) зависит от определения IOD набора данных для каждого элемента, а не от типа включающего его элемента данных последовательности.

7.4.4 Элементы условных данных типа 2C

Классы IOD и SOP

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

Если указанные условия не выполняются, элементы типа 2C не включаются в набор данных.

Примечание

Примером элемента данных типа 2C является время инверсии (0018,0082). Для нескольких определений классов SOP этот элемент данных требуется только в том случае, если последовательность сканирования (0018,0020) имеет значение «IR». В противном случае это не требуется. См. PS3.3.

7.4.5 Необязательные элементы данных типа 3

Классы IOD и SOP

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

7.

4.6 Типы элементов данных в последовательности

Когда IOD определяет элемент данных последовательности (см. раздел 7.5), тип атрибута последовательности определяет, должен ли присутствовать сам атрибут последовательности, а описание атрибута атрибута последовательности может определять, должны ли присутствовать и сколько элементов в последовательности. Типы атрибутов набора данных, включенного в последовательность, включая любые условия, указываются в рамках каждого набора данных, т. е. для каждого элемента, присутствующего в последовательности.

Примечание

1. Описание типа и атрибута последовательности определяет наличие элементов; Ограничения обусловленности для элементов данных элементов не могут принуждать наличие элемента.

2. Исторически сложилось так, что многие IOD объявляли элементы данных типа 1 и типа 2 в последовательности как относящиеся к типу 1C и типу 2C соответственно при условии наличия элемента. Это то же самое, что просто определить их как Тип 1 и Тип 2.

3. В частности, ограничение условности «Требуется, если последовательность отправлена» для элементов данных типа 1C или типа 2C, дочерних по отношению к атрибуту последовательности типа 2 или 3, не означает, что элемент должен присутствовать в последовательности. Эти условия должны быть эквивалентны «Требуется, если присутствует элемент последовательности», и условность не является строго обязательной. Любой атрибут последовательности типа 2 или типа 3 может быть отправлен с нулевой длиной.

4. В частности, ограничение условности «Требуется, если <имя-родительского-атрибута-последовательности> отправляется» для дочерних элементов данных типа 1C или типа 2C для атрибута последовательности типа 2 или 3 не означает, что элемент должен быть присутствует в Последовательности.