Hare.ru @ Коллективный разум / Hare.ru @ Дикое место |
Архив hare.ru | |||||
Мысли, конвертированные в текст | ||||||
Концептуальные работыДоступ к данным V7 из других систем. Импорт данных. Документы.Андрей Малкин (где-то в 2001) Импорт данных из документов
ПРИЛАГАЕМЫЙ СОФТ
Издатель этой статьи, а я далее буду именовать WildHare именно так, назвал эту публикацию «концептуальной». Он попал в самую точку! Исследование структуры V7, которая, в свою очередь, отражает движение абстракций, да ещё и вводит собственные есть не что иное, как самый махровый концептуализм (представителем которого, кстати, был цитируемый мною ранее Оккам). Для того, чтобы продолжить строительство модели доступа к системе хранения информации в V7, придётся вернуться немного назад. Итак, что получено в результате предыдущей работы? Главное, на мой взгляд, это возможность представить метаданные, описывающие хранимую информацию, в виде таблиц с которыми можно работать стандартными методами той или иной среды. В первой (MetaObjects) хранится список объектов хранения (наименования, внутренние и десятичные идентификаторы, наименование класса). Во второй (metaObjectsProps), связанной с первой отношением 1:M свойства (properties) каждого объекта. Функция, отдающая значение PropertyValue свойства с именем PropertyName объекта ObjectID, может тогда выглядеть примерно так:
Получить иерархию самих объектов можно с помощью ссылки на
Фактически, эти запросы и есть тот мост между метаданными (которые и определяют структуру хранения) и данными из DBF (SQL). Остаётся только надеяться, что данных из MD хватит для имитации (повторения) действий V7 при построении 1cv7.dd (dds) и использовании его в работе. В качестве первого примера для доступа я решил выбрать класс Документы. Из всего того, что есть в метаданных, он явно выделяется своей логической стройностью (продуманностью?). В самом деле:
Ещё раз уточним требования к методике доступа и к виду получаемых данных. Требование к методике и процессу преобразования только одно: он должен быть воспроизводим. Речь идет о том, что алгоритмы и методика доступа к данным V7 не должны использовать никаких специфических свойств системы (инструмента) преобразования. Это обязательное условие я ставлю на первое место.
Если речь идет о «Доступе к данным V7 из других систем», то этой другой системой
совершенно не обязательно должен быть MS Access (он используется только для отработки
технологии). Более того, совершенно необязательно, чтобы эта другая система работала под Win32!
Нет никаких видимых препятствий тому, чтобы, предположим, реализовать задуманное на связке
Именно по этой причине избрана методика, при которой данные V7 будут «выгребаться» автоматически формируемыми на основе метаданных запросами. Ну а сами запросы естественно будут написаны на «родном» языке структурированных запросов, т.е. на SQL. Требования к данным тоже достаточно аскетичны: они должны быть представлены в виде таблиц, удовлетворяющих следующим условиям:
Сначала размежеваться а потом соединиться. Сначала денормализовать, а уж потом приводить к первой, второй, и т.п. нормальным формам. Небольшие комментарии к модели. Первым делом импортируем файлы 1SJOURN, DHxxx и DTxxx. На этом этапе не рассматривается окончательная технология (импорт или присоединение таблиц). В дальнейшем будет показано какой метод и по каким причинам предпочтителен (оптимален), а пока скажу, что для разных версий системы (7.5 и 7.7) он не одинаков.
Проблемы с кодировкой, с которыми сталкиваются многие при импорте данных V7, используя Jet
ISAM (dbf в OEM в 7.5 и в ANSI в 7.7), решаются изменением значения параметра DataCodePage
в Список DH (DT) файлов с их именами (как в V7) получается с помощью запроса:
Для формирования запросов к файлам DH (DT) нужно знать имена полей этих файлов, типы
хранящихся в них данных, настоящие имена полей, и некоторую другую информацию.
Эту информацию можно получить используя запросы (Q3) или в более общем виде, одним
запросом типа Для документа с ключом [DocKey] этот запрос будет выглядеть так:
Класс GenJrnlFldDef (общие реквизиты) включен
По-другому, думаю, и невозможно сделать по принципиальным соображениям. Если значения поля типа «определенный справочник» (справочник контрагентов, например) можно представить как множество значений, определенных на домене «организации», а поле типа «справочник сотрудников« на домене «люди», то как быть со справочником «вообще«? Там всё смешалось, кони, люди Нет уже никакой предметной области. О полях типа типа «неопределенный вообще»,
где могут успешно сосуществовать не только объектные, но и скалярные типы, и говорить нечего.
Это замечательно придумано и реализовано для реализации задач на V7, но является самым главным
препятствием для решения поставленной задачи осмысленного доступа к данным. Строгости
определений явно не хватает
В общем, такие поля будут исключительно текстовыми и будут содержать, помимо значения, ещё и
Правила преобразования, применяющиеся при доступе к данным:
Реализация преобразования (доступа) очень сильно зависит от версии V7 и инструмента, с помощью
которого это преобразование выполняется. Смысл вышесказанного заключается в коренном отличии
ключей DBF в этих версиях: если в 7.5 они Но не все из существующих сегодня систем (по крайней мере настольных) могут использовать регистрозависимые первичные ключи. По крайней мере те, которые базируются на механизме Microsoft JET не могут. А таких среди настольных систем немало. Подробности, возможно, позже, а пока ограничичусь только замечанием, что «поля вообще» в 7.7 преобразовываются как указано выше, а в 7.5 As Is. То же относится к неопределенным полям в 7.7. Их преобразование не представляет принципиальных сложностей, трудности связаны с достижением оптимальной производительности при работе с ними на настольных системах. К наименованиям полей в формируемых запросах добавляется префикс символ, соответствующий типу поля (B,T, ): строчный в случае поля опредёленного типа, и прописной в случае неопределенного типа. Это сделано исключительно в целях наглядности и не несет никакой другой нагрузки. Запросы формируются по одному на каждый документ и сохраняются под именем соответствующей таблицы DBF DHxxxx. Внутри каждого запроса стандартные конструкции SQL. Все таблицы в запросах под alias'ами. В запросах фактически отсутствуют конструкции WHERE, и максимально (может быть, даже избыточно) применяется JOIN. Связано это как с тем, что в V7 отсутствует поддержка неопределенных значений (NULL), так и с тем, что генерацию кода для реализации левого внешнего объединения на составных ключах (типа IDDOC+OBJID) проще реализовать через LEFT JOIN + дополнительный unique key.
Кроме этого, есть некоторые отличия в реализации последовательности применения JOIN и WHERE на
внешних объединениях в разных
На самом деле, сам код проще, чем его описание
В прилагаемой версии модели, помимо разбора MD и чтения DBF, реализован экспорт прочитанной
структуры метаданных в
В нём же содержится структура классов, на основе которой разбирается MD. А для доступа к данным
ALS из других систем (ведь ALS это тоже часть V7), я рекомендую воспользоваться
конвертером als2html Дениса Абросимова. Кстати, по
структуре и особенностям работы И это наводит на очень грустные размышления: ведь визуальная структура ALS очень похожа на структуру MMS (а внутренняя совпадает один в один), и его использование в качестве средства визуализации конфигураций просто напрашивается само собой. В следующей части работа со справочниками. |
Партнеры: Также может быть интересно: Канал Россия 1 на http://spbtvonline.ru/ |
|||||
Сайт поддерживается за счет партнеров: | ||||||
:::... Сайт содержит архив двух версий hare.ru | Карта сайта |