Регистр сведений
Регистры сведений — это прикладные объекты конфигурации. Они позволяют хранить в прикладном решении произвольные данные в разрезе нескольких измерений. Например, в регистре сведений можно хранить курсы валют в разрезе валют, или цены предприятия в разрезе номенклатуры и типа цен.
Структура
Информация в регистре сведений хранится в виде записей, каждая из которых содержит значения измерений и соответствующие им значения ресурсов.
Измерения регистра описывают разрезы, в которых хранится информация, а ресурсы регистра непосредственно содержат хранимую информацию. Например, для регистра сведений Цены товаров, который имеет следующую структуру:
записи, хранимые в базе данных, будут выглядеть следующим образом:
Вместе с каждой записью, находящейся в регистре сведений, можно хранить дополнительную произвольную информацию. Для этого служат реквизиты регистра сведений.
Периодичность
Одной из возможностей регистра сведений является хранение данных не только в разрезе указанных измерений, но и в разрезе времени. Разработчик может указать минимальную периодичность, с которой записи будут заноситься в регистр:
В этом случае к каждой записи регистра будет добавляться поле Период, хранящее дату, которой были внесены записи в регистр. Использование периодичности регистра сведений позволяет не просто хранить статические данные, но и отслеживать их изменение во времени.
Например, периодический регистр сведений Цены товаров может не только хранить информацию о том, какова цена на определенную номенклатуру сейчас, но и о том, как она изменялась в прошлом (или будет изменяться в будущем):
Подчинение регистратору
Внесение изменений в регистр сведений может выполняться как вручную, так и при помощи документов. В случае, когда изменения в регистр сведений вносятся с помощью документов, к каждой записи регистра добавляется специальное поле, в котором хранится информация о регистраторе — документе, с которым связана эта запись. В процессе создания прикладного решения разработчик указывает, какой именно режим записи будет использоваться данным регистром сведений:
Использование режима записи Подчинение регистратору может потребоваться в случае, когда логика работы прикладного решения требует того, чтобы изменения, выполняемые в регистре сведений, были жестко связаны с документами, фиксирующими факты хозяйственной деятельности.
Например, изменение цен компании может производиться только определенным кругом лиц, и каждое такое изменение должно сопровождаться «бумажным» документом. В этом случае можно использовать режим подчинения регистратору, при котором изменение цен может быть выполнено только специальным документом — Изменение цен товаров.
Уникальность записей
Система обеспечивает контроль уникальности записей, хранящихся в регистре сведений. Таким образом, в регистре сведений не может находиться двух одинаковых записей. Одинаковыми считаются записи, у которых совпадает ключ записи. Ключ записи формируется системой автоматически, на основании значений, содержащихся в полях записи, и зависит от вида регистра сведений.
В общем случае в формировании ключа записи будут участвовать значения регистратора, периода и значения измерений. Таким образом, например, в непериодическом регистре сведений Цены товаров с независимым режимом записи не может существовать двух записей о розничной цене конфет ассорти. Точно так же, как в периодическом регистре сведений Цены товаров, подчиненном регистратору, не может существовать двух записей о розничной цене конфет ассорти, внесенных одной и той же датой, одним и тем же документом Изменение цен товаров.
Формы
Для того чтобы пользователь мог просматривать и изменять данные, содержащиеся в регистре сведений, система поддерживает несколько форм представления регистра. Система может автоматически генерировать все нужные формы регистра. Наряду с этим разработчик имеет возможность создать собственные формы, которые система будет использовать вместо форм по умолчанию:
Форма списка
Для просмотра данных, содержащихся в регистре сведений, используется форма списка. Она позволяет выполнять навигацию по регистру, добавлять, помечать на удаление и удалять записи регистра. Форма списка позволяет выполнять сортировку и отбор отображаемой информации по нескольким критериям:
Форма записи
Для просмотра и изменения отдельных записей регистра сведений используется форма записи. Как правило, она представляет данные в удобном для восприятия и редактирования виде:
Функциональные возможности регистра сведений
Основными функциональными возможностями, которые предоставляет регистр сведений разработчику, являются:
- создание, изменение и удаление записей;
- выбор записей в заданном интервале по заданным критериям;
- выбор записей по регистратору;
- получение значений ресурсов записей, соответствующих указанному периоду и значениям измерений;
- получение значений ресурсов наиболее ранних и наиболее поздних записей регистра, соответствующих указанному периоду и значениям измерений.
Примеры проектирования регистра сведений
И измерения, и ресурсы, и реквизиты регистра сведений являются в широком смысле этого слова. Это составная часть , описывающая одну колонку таблицы базы данных (подробнее). Однако существует ряд дополнительных ограничений на типы значений, которые могут храниться в этих реквизитах.
Общее ограничение — ни измерения, ни ресурсы, ни реквизиты не могут быть множественными. То есть они не могут иметь тип Массив .
Другие ограничения касаются только измерений:
- Измерения типа Строка и Байты должны иметь ограничения по длине.
- Измерения не могут иметь тип ДвоичныйОбъект.Ссылка .
В регистре сведений должно быть хотя бы одно измерение, при этом он может не иметь ни ресурсов, ни реквизитов. Измерения автоматически включаются в основной отбор регистра сведений. Чтобы исключить измерения из основного отбора, следует установить свойство ИспользоватьВОсновномОтборе : Ложь .
Наличие/отсутствие чего-либо
В тех случаях когда в ресурсе требуется хранить значения типа Булево («есть»/«нет», «включено»/«выключено», «используется»/«не используется»), можно обойтись вообще без ресурса. Благодаря тому, что регистр обеспечивает уникальность записей по набору значений измерений, вы не сможете добавить в регистр две записи с одними и теми же «координатами».
Поэтому, например, для учета уборки помещений можно использовать регистр с измерениями Помещение и ДатаУборки . Есть запись на эту дату про это помещение — значит оно убрано. Нет записи — значит помещение не убрано.
Регистр-флажок
Существуют задачи, в которых необходимо иметь в базе данных флажок — переключатель, который не привязан к каким-либо данным, а важен только фактом своего существования.
Для таких задач можно использовать регистр сведений, который может содержать одну единственную запись. Есть запись в этом регистре — «флажок установлен», нет записи — «флажок снят».
Такой регистр будет иметь единственное измерение с типом Неопределено . Тип Неопределено имеет единственное значение — Неопределено . Поэтому в таком регистре может быть всего одна запись.
Регистры с датой и периодические регистры
При проектировании регистров важно понимать разницу между периодическим регистром и регистром, хранящим дату добавления записи.
Если вам просто хочется хранить время или дату, говорящие о том, когда данная запись добавлена или изменена, для этого лучше использовать реквизит типа Дата , Время или ДатаВремя . В этом случае вы не будете связаны никакими ограничениями на указание этих значений: они могут повторяться, могут не иметь никакой периодичности.
- контроль за периодичностью изменения ресурсов, «не чаще, чем раз в . »;
- получение значения ресурсов на указанную дату, «цены товаров на . ».
Самодостаточность регистров
В тех случаях когда регистр хранит ссылочные данные, например типа имя-справочника.Ссылка , нужно стремиться к тому, чтобы регистр был независим от экземпляров, на которые ссылаются эти данные (от элементов этих справочников).
Любая логика, опирающаяся или анализирующая данные регистра, а также любые отчеты по этому регистру не должны обращаться к полям справочника: им должно быть достаточно данных самого регистра.
Обращение к полям справочника «через точку» приводит к неявному соединению с дополнительными таблицами. Кроме того, в узлах распределенной системы такого справочника может и не быть, если записи регистров мигрируют между узлами, а справочники — нет.
Для чего нужны измерения регистра ресурсы и реквизиты
Подскажите, пожалуйста, в чем различия назначения использования в регистре сведений Реквизита и Измерения?
Тема по 1С:Предприятию 8.х
Текст вопроса, тоже другой: Подскажите, пожалуйста, в чем различия назначения использования в регистре сведений Реквизита и Ресурса?
(2) Так скоро и сам себе ответишь
(2) Только логический. В ресурсы нужно пихать то что является результатом, а в реквизиты то что характеризует саму запись. Но реально и то и то получается одинаково.
(0) Инфа в рс хранится в виде ресурса, а тот разрез по которому ты ее хочешь получать — в измерении. Разница между реквизитом и ресурсом на практике — никакой. Только в словоблудии
(5)
если верить СП, то есть разница.
РегистрСведенийМенеджер. (InformationRegisterManager.)
Выбрать (Select)
Вариант синтаксиса: Для периодического регистра
Синтаксис:
Выбрать(, , , )
Параметры:
(необязательный)
Тип: Дата, МоментВремени, Граница. Начало интервала, за который будут выдаваться записи периодического регистра сведений. Если не указан, то будут выдаваться записи с самого ранней включительно. Может задаваться значениями типа Дата, МоментВремени или Граница.
(необязательный)
Тип: Дата, МоментВремени, Граница. Конец интервала, за который будут выдаваться записи периодического регистра сведений. Если не указан, то будут выдаваться записи до самой поздней включительно. Может задаваться значениями типа Дата, МоментВремени или Граница.
(необязательный)
Тип: Структура. Задает поле и значение отбора открываемой выборки. Ключ структуры описывает имя поля, а значение структуры — значение отбора по этому полю. В качестве полей для отбора могут задаваться измерения или реквизиты, для которых в конфигураторе признак индексирования установлен в значение «Индексировать» или установлен признак «Ведущее». Вид сравнения может быть только Равно.
Важно! Структура может содержать только один элемент.
Если параметр не указан, то отбор не используется.
(необязательный)
Тип: Строка. Может содержать слово «Возр» или «Убыв», тогда стандартный порядок будет использоваться с указанным направлением.
Может содержать имя поля (реквизита или измерения, для которых указано индексирование) и слово «Возр» или «Убыв», тогда упорядочивание будет производится по указанному полю в указанном порядке.
Значение по умолчанию: «Возр»
Вариант синтаксиса: Для непериодического регистра
Описание:
Используется только для непериодического регистра
Синтаксис:
Выбрать(, )
Параметры:
(необязательный)
Тип: Структура. Задает поле и значение отбора открываемой выборки. Ключ структуры описывает имя поля, а значение структуры — значение отбора по этому полю. В качестве полей для отбора могут задаваться измерения или реквизиты, для которых в конфигураторе признак индексирования установлен в значение «Индексировать» или установлен признак «Ведущее».
Важно! Структура может содержать только один элемент.
Если параметр не указан, то отбор не используется.
(необязательный)
Тип: Строка. Может содержать слово «Возр» или «Убыв», тогда стандартный порядок будет использоваться с указанным направлением.
Может содержать имя поля (реквизита или измерения для которых указано индексирование) и через пробел слово «Возр» или «Убыв», тогда упорядочивание будет производится по указанному полю в указанном порядке.
В качестве значения параметра может быть задана строка «» («»). Это будет означать, что система выберет наиболее оптимальный порядок обхода такой выборки, который в общем случае не будет соответствовать порядку обхода по умолчанию.
Значение по умолчанию: «Возр»
Возвращаемое значение:
Тип: РегистрСведенийВыборка.
Описание:
Формирует выборку записей регистра сведений.
Пример:
Курсы = РегистрыСведений.КурсыВалют;
ОтборВалют = Новый Структура(«Валюта»);
ОтборВалют.Валюта = ВыбВалюта;
ВыборкаКурсовВалют = Курсы.Выбрать(,,ОтборВалют);
Пока ВыборкаКурсовВалют.Следующий() Цикл
Сообщить(«Дата » + ВыборкаКурсовВалют.Период +
» Валюта «+СокрЛП(ВыборкаКурсовВалют.Валюта) +
«, Курс «+ ВыборкаКурсовВалют.Курс );
КонецЦикла;
(5)+ справедливо только для РС.
(8) почти согласен, но не знаю насчет построения индексов.
ну и из (7) нельзя (почему-то) делать отбор по ресурсам.
В ресурсе может быть периодическая инфа по измерениям. А вот периодичские измерения по ресурсу — это мистика, имхо. Как я понимаю, измерения — это заголовки колонок и строк, а ресурсы — это их содержимое.
(10) тогда почему можно по реквизитам? они-то, вроде, по логике, вообще «довесок».
(11) Не ко мне вопрос. Как я понял, регистр сведений вообще мало отличается от справочника, только в нем есть периодические ресурсы, а в справочнике нет. А вообще, я тут думаю, что при логической конструкции: регистр(а,б).ресурс, где а и б — это реквизиты, мы получим ресурс «1». При конструкции регистр(а,с).ресурс, мы можем получить другой ресурс, например, «2». При этом по ресурсу «2» мы, наверное, получим а и с. Но в том случае, если нет ресурсов с таким же значением. Гы, сам стал запутываться )))
4. Конкретизируйте для чего нужны измерения, ресурсы и реквизиты в регистрах, для чего предназначен объект конфигурации Регистр сведений, и в чем его главное отличие от Регистра накопления?
5. Поясните, для чего предназначен объект конфигурации Регистр накопления, зачем его используют, хотя необходимая информация уже хранится в других объектах?
6. Поясните, как связаны стандартные прототипы прикладных объектов и механизмы их реализации на примере характеристик и бизнес процессов.
механизм бизнес)процессов (work)flow), позволяющий разработчику организовать совместную работу пользователей при выполнении типовых последовательностей деловых операций. Во многих существующих информационных системах для решения задач work)flow используются специализированные продукты, которые приходится интегрировать с приложениями, решающими экономические задачи. В платформе «1С:Предприятие» механизм бизнес)процессов полностью интегрирован в систему таким образом, что ни разработчик ни пользователь не видят «швов» разделяющих этот механизм и другую функциональность. Этот механизм включает средства для описания в прикладном решении схем бизнес)процессов, и их ролевой маршрутизации, для формирования заданий , выполняющихся в каждой точке маршрута, для управления бизнес)процессом и организации его связи с другими функциями прикладного решения. Данный механизм предоставляет разработчику гибкие возможности управления ветвлением процесса и формирования задач. Например, кроме обычного условного ветвления разработчик может визуально описать параллельное прохождение нескольких веток маршрута, и указать точку их слияния. Допускается направление одного задания группе потенциальных исполнителей, например, если выписать счет должен один из менеджеров отдела. И наоборот, в некоторой точке маршрута можно инициировать несколько заданий, например, если финансовые отчеты должны представить все руководители отделов. Ролевая маршрутизация позволяет формировать задачу не только не) посредственно конкретному сотруднику, но и распределять задачи по ролям, подразделениям и другим критериям, которые может описать разработчик прикладного решения. При осуществлении ролевой маршрутизации разрешается указывать текущее распределение обязанностей сотрудников с учетом временных замещений, совмещений нескольких должностей и т.д. Важно отметить, что данный механизм предлагает готовую стратегию автоматизации совместной деятельности работников предприятия. Для описания простейших бизнес)процессов достаточно визуального задания схемы маршрута и указания условий ветвления в их узловых точках. Все остальные действия выполняются системой автоматически. При реализации сложных бизнес)процессов усилия разработчика требуются в основном для тесной их увязки с функциями прикладного решения. Механизм характеристик, предназначенный для решения задач, которые плохо согласуются с классической реляционной моделью базы данных. Одной из таких задач, является построение структуры для отражения разнообразных свойств (характеристик) номенклатуры товаров или изделий. Если создается решение для одной организации с четкой ориентацией на определенную группу товаров, то все необходимые реквизиты можно заложить непосредственно в структуру каталога товаров. Например, для дилерской фирмы по продаже автомобилей ими будут цвет, объем двигателя и т.д. Однако если создается тиражное бизнес)приложение, или решение для организации, занимающейся производством или продажей разнообразной номенклатуры, этот вариант не подходит, так как очевидно, что состав характеристик должен зависеть от конкретной группы номенклатуры и добавление каждой новой группы не должно сопровождаться доработкой прикладного решения. Очевидно, что реализация такого решения плохо ложится в реляционную структуру и требует особого подхода. Реализованный в «1С:Предприятии» механизм характеристик предоставляет разработчику типовое средство решения подобных задач. Специализированный прототип предназначен для организации хранения списка видов характеристик. При этом каждому такому виду приписывается свой тип данных. Например, объем двигателя будет задаваться числом, а цвет выбираться из справочника. Важно, что конкретные виды характеристик могут не только определяться в самом приложении, но и добавляться пользователем в процессе эксплуатации системы без изменения прикладного решения. При этом разработчик может задействовать данный механизм в самых различных ситуациях, например, для хранения логически связанных комбинаций характеристик номенклатуры и расчета себестоимости в разрезе имеющихся комбинаций. 7. Покажите, как именно реализована высокоуровневая модель интерфейса на примерах механизма ввода на основании, механизма форм и WEB расширений. Объясните, как строятся распределенные интегрированные информационные системы Наличие у объектов, описанных метаданными, стандартной функциональности и предопределенной роли позволяет системе автоматически решать гораздо более широкий круг задач, возлагаемых как непосредственно на эти объекты, так и на общие механизмы, работающие с ними. Фактически, зная о назначении (роли в прикладном решении) того или иного объекта, платформа сама, без какого)либо участия программиста, обеспечивает для него в любой ситуации соответствующий «индивидуальный подход». Например, механизм форм «знает», как лучше редактировать те или иные данные, а стандартный механизм отчетов может автоматически «подстроиться» с тем, чтобы проводить анализ информации наиболее эффективно. Механизм форм обеспечивает стратегию смысловой идентификации форм, позволяющую не открывать повторно уже открытые формы, а активизировать отрытые ранее формы при обращении пользователя к той или иной информации. Web)расширении ) механизме, позволяющем реализовывать Web)интерфейс к прикладным решениям «1С:Предприятия». Мы не будем рассказывать о деталях технологического устройстве этого механизма. Наиболее интересным в его реализации,на наш взгляд является то, что он также как и основной (rich) интерфейс максимально использует для автоматического формирования Web)форм информацию из метаданных, а также знания о назначении и устройстве прототипов прикладных объектов. Форма для редактирования любого объекта или просмотра списка объектов создается Web)расширением автоматически или может быть определена разработчиком вручную в проекте. Если разработчик описывает форму самостоятельно, то в его распоряжении специализированные элементы управления, которые не только позволяют организовать связь с теми или иными данными, но и предоставляют всю необходимую функциональность по просмотру и редактированию. Например, в полях ввода поддерживается выбор из форм)списков и подбор по первым буквам, в списках поддерживается иерархический просмотр, настройка пользователем фильтрации и сортировки. Система предоставляет большой набор стандартных действий по «обслуживанию» данных и самостоятельно организует связь между формами приложения. Таким образом обеспечивается единообразие двух вариантов пользовательского интерфейса (разумеется, с поправкой на особенности среды Web), а также максимальная автоматизация их разработки, основанная на использовании информации из метаданных. Изначально решение о создании механизма обмена данными, предназначенного для территориально распределенных информационных баз и не требующего постоянного соединения, было обусловлено в большей степени отсутствием в распоряжении отечественных предприятий качественных высокоскоростных телекоммуникационных каналов. Однако некоторое время спустя стало очевидно, что разработка таких механизмов лежит в русле одного из наиболее перспективных направлений мировой инженерной мысли. Сегодня в распоряжении разработчика приложений имеется мощный набор механизмов обмена, способный решать самые разнообразные задачи. Кроме традиционной поддержки территориально распределенных информационных систем, с его помощью осуществляется интеграция с другими прикладными программами, а также строятся сложные гетерогенные информационные системы, включающие наряду с решениями на платформе «1С:Предприятие» еще и внешние приложения. Использование технологий обмена для решения столь широкого спектра задач объясняется тем, что в распоряжении разработчика не монолитное решение, а набор механизмов, которые могут применяться как по отдельности, так и совместно, в любых сочетаниях. Эти механизмы поддерживают работу с XML документами, XML)сериализацию данных, инфраструктуру сообщений, службу регистрации изменений, планы обмена, управление распределенной информационной базой: Практически уникальным , по нашему мнению, качеством данного набора механизмов является то, что он обеспечивает очень высокий уровень готовности системы к работе в распределенной среде ) организация обмена практически не требует дополнительных затрат на разработку. Нужно просто задать в интерактивном режиме состав данных, участвующих в обмене, а механизм обеспечит формирование сообщений и их загрузку. При этом система автоматически организует обмен только измененной информацией, отслеживает получение сообщений, определяет необходимость повторной отправки данных, разрешает коллизии и проверяет целостность загружаемой информации. Гибкие возможности настройки позволяют сформировать практически любую топологию схемы узлов обмена (звезда, снежинка, схемыбез центрального узла). Состав данных, участвующих в обмене, и правила разрешения коллизий могут задаваться произвольно. При этом механизмы обмена с одной стороны минимизируют объем передаваемых данных (пересылаются только измененные данные), а с другой ) гарантируют устойчивость к потере сообщений. Иными словами, система способна функционировать как в условиях гарантированной доставки сообщений, так и без таковой. Наличие в платформе эффективных, не требующих сложной настройки механизмов обмена обязано, прежде всего, общей архитектуре построения прикладных решений, реализованной в платформе «1С:Предприятие». Мы уже говорили, о том, что органичный переход к распределенным и интегрированным системам обеспечивается объектной техникой манипулирования данными, используемой в «1С:Предприятии». Система соответствующих объектов обеспечивает штатные возможности сохранения (persistence) любых прикладных данных в формате XML. Кроме того, благодаря наличию стандартных прототипов прикладных объектов платформа способна автоматически задавать для каждого объекта необходимую гранулярность передачи изменений и стратегию обмена в соответствии с его назначением. Основной проблемой большинства известных систем обмена и репликации является то, что в заложенной в них семантике описания данных не содержится сведений о том, какими порциями выполнять обмен, как разрешать коллизии, как обеспечивать логическую целостность и непротиворечивость данных. Из за этого разработчику при использовании подобных механизмов обычно приходится детально описывать процедуры обмена для каждого информационного массива. Механизмы обмена «1С:Предприятия» функционируют на уровне стандартных прототипов прикладных объектов и поэтому имеют в своем распоряжении всю необходимую информацию такого рода изначально. Разработчику необходимо только указать, что в обмене участвуют объекты определенного вида. Далее все действия, по регистрации изменений, формированию сообщений, загрузке данных и разрешению коллизий будут выполняться автоматически. Разработчик, конечно, имеет возможность вручную выполнить «тонкую настройку», но она потребуется только в отдельных случаях. Другая важная особенность механизмов обмена «1С:Предприятия» ) их соответствие передовым мировым концепциям интеграции информационных систем. Мы прекрасно понимаем, что сегодня ни один разработчик экономического софта не может считать себя «царем горы», которому нет необходимости заботиться о тесном взаимодействии с системами других вендоров. В данном контексте взаимодействие ) не просто умение вызвать какую)то функцию из другой программы или экспортировать в нее какие)либо данные. Речь идет о построении сложных гетерогенных систем, в которых несколько разнородных прикладных решений образуют слаженно действующий ансамбль. Очевидно, что эта тенденция станет в обозримом будущем одной из доминирующих на рынке экономических систем. Механизмы обмена «1С:Предприятия» имеют вы) сокую готовность к работе в гетерогенных системах сегодняшнего и завтрашнего дня не только за счет того, что весь обмен производится на формате XML, но, что еще более важно, в силу идеологического соответствия реализованных решений указанной тенденции. Уже сегодня механизмы обмена «1С:Предприятия» позволяют осуществлять взаимодействие не только с отдельными приложениями, но и с перспективными интеграционными платформами.