Соответствие имен таблиц бд объектам метаданным

Добавил чуть-чуть библиотекарш и шахматы 🙂
В обработку RMih добавил вкладку SQL Create View

Раньше пользовался другими инструментами, а тут понадобилась эта обработка для работы и понял: неудобно и есть косяки.
Углубил и расширил: добавил поиск по подстроке среди объектов и убрал косяки в генерации SQL Create View.

Спасибо огромнейшее за обработку!
Спасает меня уже не первый раз.

Я не сильно понимаю в коде 1С, но вот приходится разбираться.
Мне необходимо вместе с «ИмяПоляХранения» и «ИмяПоля» вывести еще и «Синоним» поля.
столбец в таблице в форме я добавил, а вот что написать в «Данные» я не знаю. 🙁 попробовал уже куча всего, но это как гулять в лесу с завязанными глазами — везде деревья.

Направьте на путь истенный пожалуйста.

Спасибо огромнейшее за обработку!
Спасает меня уже не первый раз.

Направьте на путь истенный пожалуйста.

Сейчас задача несколько иная, у клиента есть своя конфигурация пиленая-перепиленая из УПП. Делалась лет 10 исходя из требований, которые возникали достаточно хаотично. И теперь никто уже не понимает где и что лежит и как работает. Моя-же задача описать все это в графическом виде. БольшУю часть я уже сделал, но есть много моментов которые называются сильно по разному. Например ИмяПоля «Родитель», а выводится в формы как «Аутсорсер». т.е. у поля «Родитель» в справочнике есть свойство «Синоним» : «Аутсорсер». И без этого свойства очень грустно каждое поле перепроверять в конфигураторе.

имя справочника из пофигуратора.

все имена знает коллекция справочников из метаданных

а что это даст. ER на уровне всей упп — это будет малопонятное «месиво». особенно доставлять будут реквизиты составного типа

надо разбивать все по подсистемам, но и тогда.

не верю я особо в reverse от базы для упп.

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

Обработку допилили немного.

«НайтиПоПолномуИмени» это как раз функция, которая выдает объект по его метаданным. И тогда можно обратится к его синониму.

Спасибо всем за советы-подсказки.

Допилили немного обработку. теперь выводит и представление объекта. вроде все учел и у меня работает. Надеюсь кому еще поможет.

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

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

Источник

Получение информации о структуре хранения базы данных в терминах 1С:Предприятие и СУБД

Часто возникает необходимость определить в какой таблице СУБД хранится тот или иной объект метаданных. Или наоборот, какой объект метаданных соответствует определенной таблице СУБД. Здесь стоит упомянуть, что имена таблиц и полей СУБД, в которых хранятся объекты метаданных 1С:Предприятия, не соответствуют именам объектов метаданных, их реквизитам, измерениям, ресурсам. Получение такой информации не представляет особой сложности, тем не менее, если Вы никогда этого не делали, данная статья будет Вам полезна.

Получение структуры хранения базы данных

В целом, эту статью можно было бы изложить в одном коротком предложении: для получения информации о структуре хранения базы данных, а также соответствие имен объектов в терминах 1С:Предприятие и СУБД необходимо воспользоваться методом ПолучитьСтруктуруХраненияБазыДанных () . Но мы пойдем дальше и попробуем разобраться с областью применимости этого метода, а также организуем удобную работу с возвращаемыми методом данными.

Давайте, для начала, посмотрим что же возвращает данный метод. Результатом вычисления данной функции будет таблица значений, в которой каждая строка таблицы определяет одну таблицу СУБД. В первых двух колонках указано имя таблицы в терминах СУБД и в терминах 1С:Предприятия. Далее идут колонки описывающие к какому метаданному относится таблица и назначение этой таблицы СУБД. Последние две колонки содержат вложенные таблицы значений полей и индексов таблицы СУБД. В таблице полей содержится соответствие имен полей в терминах СУБД и терминах 1С:Предприятие, а так же связь поля с объектом метаданного (какой реквизит/ресурс/измерение). Таблица индексов содержит набор имен индексов, а так же вложенную таблицу значений, содержащую поля таблицы СУБД, включенные в состав индекса, и соответствие их имен в терминах СУБД и 1С:Предприятие.

Структура хранения базы данных

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

Обработка «Структура хранения базы данных»

Область применимости

Давайте попробуем проанализировать ту информацию, которую нам предоставляет платформа с помощью метода ПолучитьСтруктуруХраненияБазыДанных () и сопоставим ее с реальной структурой СУБД (рассмотрим на примере MS SQL Server). Сразу оговорюсь что метод имеет 2 параметра: первый устанавливает отбор на метаданные по которым необходимо получить информацию; второй устанавливает режим вывода информации: «В терминах СУБД» или «В терминах 1С:Предприятие» (данная опция так же присутствует в обработке). Представленный ниже текст относится к режиму вывода «В терминах 1С:Предприятие» если не указано иного.

Подготовка базы

Давайте создадим пустую информационную базу в режиме совместимости с 8.2.16, основной режим запуска установим «обычное приложение». В конфигурацию добавим 2 документа (со значениями по умолчанию) и регистр сведений «АнализСтруктурыХранения» (периодичность в пределах дня). У регистра добавим реквизиты:

«Число»: тип число
«Строка»: тип строка
«ДокументСсылка»: тип ДокументСсылка1
«СоставнойЧислоСтрока»: составной тип Число и Строка
«СоставнойДокументСсылка»: составной тип ДокументСсылка1 и ДокументСсылка2
«СоставнойЧислоСтрокаДокументСсылки»: составной тип Число, Строка, ДокументСсылка1, ДокументСсылка2

Далее добавим общий реквизит «Разделитель» (тип Число), в состав включим наши документы и регистр сведений. Установим «Разделение данных» в «разделять» и разрешим создать параметры сеансов, «Использование разделяемых данных» установим в значение «независимо и совместно». Обновим конфигурацию.

Набор таблиц базы данных в СУБД и методе платформы

Откроем обработку в 1С:Предприятие, а также откроем список таблиц базы данных в СУБД и сравним их. Как видно, метод ПолучитьСтруктуруХраненияБазыДанных () вернул не полный список таблиц базы, который мы можем увидеть на уровне СУБД, а набор таблиц за исключением системных таблиц, таких как Config, ConfigSave, v8users и другие.

Структура базы данных на уровне СУБД и платформы

Набор полей (колонок) в таблице

Перейдем теперь к нашему регистру сведений. Получим набор полей таблицы регистра с помощью обработки, а так же получим набор колонок в СУБД и сравним их. Как видно, для не составных типов (вне зависимости от типа) в СУБД используется 1 колонка таблицы, структура хранения 1С:Предприятия отражает аналогичную информацию. Если же мы перейдем к полям составного типа, то в обработке все так же выводится информация только об 1 поле, как мы его и задавали в конфигурации, а в СУБД это поле хранится в нескольких колонках и их количество может быть различно в зависимости от состава типа поля, определенного в конфигурации. Это связано со способом хранения информации платформой и более подробно можно прочесть на сайте ИТС. Замечу, что при анализе запроса в СУБД или анализе плана запроса необходимо учитывать этот факт и правильно интерпретировать имена колонок.
Структура полей (колонок) в таблице базы данных

Состав индексов

Проведем аналогичное сравнение индексов и их состава, полученных обработкой и реально существующих в СУБД. Первое что бросается в глаза, это 12 индексов в таблице СУБД, в то время как обработка выводит только 2. По своей сути все верно, если индексы разделить по «назначению» («ByDims» — по измерениям, и «ByPeriod» — по периоду). Размножение произошло по причине того что в составных типах включено более 1 примитивного типа или примитивный тип включен вместе с ссылочным — в этом случае платформа создает для каждой комбинации свой индекс. Так, в нашем примере реквизит «СоставнойЧислоСтрока» включает 2 примитивных типа, а «СоставнойЧислоСтрокаДокументСсылки» включает 2 примитивных типа и ссылочные (их количество не важно, важно наличие хотя бы одного). Таким образом, платформа создала комбинации индексов: ЧислоЧисло, ЧислоСтрока, ЧислоСсылка, СтрокаЧисло, СтрокаСтрока, СтрокаСсылка.

Откроем состав одного из индексов и сопоставим поля. Как видно, в СУБД первым полем индекса стоит «Fld12», (по таблице полей можно определить что это «Разделитель«) и оно отсутствует составе индекса, выведенного в обработке.

Структура и состав индексов на уровне СУБД и платформы

Продолжаем эксперименты

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

Сделаем следующие вещи:

Откроем в СУБД индекс «ByDocNum» объекта Документ1 и поменяем порядок следования полей Number и IDRRef
Удалим в СУБД индекс «ByDocDate» объекта Документ1
Добавим в СУБД колонку, например, «MyColumn» с числовым типом в таблицу регистра сведений
Добавим в СУБД в нашу базу данных новую таблицу, например, «MyTable»

Откроем нашу обработку и проверим что получилось:

Платформа не знает о том что порядок полей в индексе был изменен
Платформа не знает о том что индекс удален
Платформа не видит добавленную колонку
Платформа не видит добавленную таблицу

Задание для самостоятельной работы

Как ранее было сказано, вышеприведенное исследование выполнено для режима «В терминах 1С:Предприятие». Предлагаю проделать всю вышеприведенную работу для режима «В терминах СУБД» самостоятельно и сделать соответствующие выводы. Оговорюсь лишь о том, что большая часть расхождений между реальной структурой в СУБД и структурой возвращенной методом платформы — исчезают.

Выводы

Метод ПолучитьСтруктуруХраненияБазыДанных () предоставляет достаточно полную и корректную информацию о структуре хранения базы данных, а так же выводит соответствия имен таблиц, их колонок, и индексов в терминах СУБД и 1С:Предприятие. Но, при этом есть некоторые ограничения при работе с этим методом:

Нет информации о системных таблицах (но она особо и не нужна)
Состав полей отражается с точки зрения 1С, а не с точки зрения хранения в СУБД (только в терминах 1С:Предприятие)
Набор индексов так же отражается с точки хранения 1С, а не с точки зрения СУБД (только в терминах 1С:Предприятие)
Некоторые существующие поля индекса могут быть не отражены в составе индекса на уровне платформы (только в терминах 1С:Предприятие)
Информация, видимо, строится не по структуре базы данных, а по некому представлению платформы о структуре базы на основании метаданных конфигурации и их свойств
Необходимо иметь ввиду что механизм работы метода может быть изменен в другой версии платформы

Таким образом, если необходимо получить точную информацию о структуре базы данных, необходимо получать эту информацию с помощью СУБД, а при получении данных методом ПолучитьСтруктуруХраненияБазыДанных () лучше использовать режим «В терминах СУБД»

Источник

Извлечение данных из БД 1С: проблемы с перечислениями

Решил написать статью о том, как вытягивать данные из 1С путем SQL запросов. Все нижесказанное касается 1С версии 8.2, оно также должно работать и в 1С версии 8.1. Особое внимание уделено проблеме с извлечением заголовков перечислений.

Культурный способ

В идеале выборку данных из 1С должен делать 1С-программист. Хорошо, если он создаст обработку, которая выдаст данные в так называемую «буферную базу»: csv файлы, таблицы в SQL – что угодно. Проектировщик ХД и ETL должен брать данные из буфера.

В этом случае все работает предельно хорошо: зоны ответственности разделены, если найдена ошибка в данных отчета – ее вначале ищут в кубе, если в кубе все ОК – ищут в ХД, если в ХД все ОК – ищут в ETL, если в ETL все хорошо – значит пускай 1С-программист сам разбирается где у него ошибка в обработке, заполняющей «буферную БД».

Но не всегда такой способ доступен. Бывает, что 1С-специалиста либо вообще нет, либо слишком занят, либо мощностей железа не хватает, чтобы «выталкивать» данные из 1С с помощью обработки. И остается одно – делать извлечение данных с помощью SQL запросов.

Не очень культурный способ

Вот это собственно и есть этот способ – «сделать SQL запрос на 1С-базу». Главная задача – корректно написать сами запросы. Я думаю, ни для кого не есть секретом, что в 1С структура данных «хитрая», и что поля и таблицы имеют замысловатые названия. Задача проектировщика ETL – вытянуть данные из этой структуры.

Просмотр метаданных

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

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

Таким образом, начинаем исследовать нужные нам документы:

Дальше открываем любой из них, и находим то, куда он записывается – в какие регистры:

Ну а дальше найти этот регистр и сгенерировать SQL запрос с помощью показанных выше обработок (как на первом рисунке) не составляет труда.

Мы делаем как правило два уровня SQL запросов: «нижний уровень» — вьюхи для переименования полей, «верхний уровень» – вьюхи, которые берут данные из нижнего уровня, и уже они делают необходимые джойны.

Перечисления

Есть одна большая проблема – это перечисления. Пример:

И теперь если попытаться вытянуть это поле из базы напрямую, то получим вот что:

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

Поэтому мы нашли другой способ. Мы сделали на C# небольшую программку, которая использует COM-объект 1С-ки для того, чтобы установить с ней соединение, и вытянуть все значения всех перечислений в одну таблицу.

Вы можете скачать ее отсюда.

Запускается вот так:

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

Дальше понятно, что SSIS-пакет (или другой механизм) может запустить этот код перед тем, как извлекать данные фактов/справочников, и мы получим заполненную таблицу

и дальше вы уже можете строить джойн по полю _EnumOrder: справочник ссылается на _Enum таблицу по IDRRef, в ней поле _EnumOrder которое ссылается на поле EnumOrder вашей таблицы, которую только что вытянул C# код.

Если у Вас будут замечания или дополнительные идеи – все они с радостью принимаются, пишите на ibobak at bitimpulse dot com.

Источник

SQL для чайников. Реляционные БД. Типы данных

Всем доброго дня, пикабушники и пикабушницы.

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

Для начала, надо разобрать, что же такое SQL, а так же, где, как и зачем применяется.

Тут надо понимать, что SQL — это язык запросов, который дает возможность работать в реляционных базах данных.

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

Такая адресная книга называется двухмерной (строка и столбец) таблицей информации.

Еще проще говоря — у нас есть Петров Иван, и ему будет соответствовать номер телефона и адрес — они «привязаны» к нему. Это позволяет хранить информацию систематизировано, в порядке.

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

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

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

В SQL типы данных разделяются на три группы: строковые, с плавающей точкой (дробные числа) и целые числа, дата и время.

Источник