CADmaster

Введение

Вы умеете варить манную кашу? Тогда можете гордо заявить: «Я обладаю технологией приготовления манной каши».

На практике это означает, что вы можете разложить «по полочкам» последовательность действий (техно — «искусство, мастерство») и знаете, что и в каких пропорциях нужно для приготовления каши (логос — наука). И, что не менее важно, можете поделиться своими знаниями с другими людьми. Описав технологию, вы избавите своих последователей от необходимости проведения экспериментов с поиском правильных пропорций, последовательности смешивания, времени приготовления и т.д. Возможно, каша, изготовленная по вашему рецепту, окажется не такой вкусной — вы «случайно» забудете указать в рецепте то, чем кашу нельзя испортить. Но это будет съедобная каша, и вашим потомкам не придется ее солить, перчить или сдабривать хреном.

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

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

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

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

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

Созданный в 2003 году компанией CSoft Development программный продукт TDMS вобрал в себя богатейший опыт, накопленный предыдущими поколениями разработчиков. Платформа TDMS содержит встроенные средства проектирования информационной системы: конструктор свойств и методов типов информационных объектов (классов), редактор программного кода, инструментарий для настройки пользовательских интерфейсов (профилей), графическую среду для создания запросов, мастер построения отчетов, инструменты для проектирования форм и др. Ряд используемых в TDMS технологий не имеет аналогов в мире или значительно превосходит альтернативные решения.

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

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

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

Первая часть цикла посвящена технологиям, применяемым в TDMS при работе с файлами.

Часть I

Управление файлами в среде TDMS

Лирическое отступление или единство и борьба противоположностей

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

«Подумаешь! — скажете вы. — Худо-бедно и так справляемся. Есть расширение имени файла, по нему с большой степенью вероятности можно определить приложение, которое, скорее всего, сумеет прочитать содержимое».

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

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

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

Давайте посмотрим, что есть в арсенале TDMS. А начнем с технологий хранения файлов в недрах информационных систем.

Технология хранения файлов

Основные принципы

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

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

Хранение файлов в таблицах базы данных

СУБД Microsoft SQL Server и Oracle, используемые в TDMS, позволяют хранить тела файлов непосредственно в таблицах базы. Для представления файлов в СУБД используются различные типы данных, специально предназначенные для хранения больших бинарных объектов (BLOB — Binary Large Objects).

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

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

К недостаткам хранения файлов в СУБД можно отнести повышенные требования к серверу базы данных. Файловые операции практически не используют процессорные мощности сервера, а основная дополнительная нагрузка ложится на подсистемы ввода/вывода. Чтобы обеспечить быстрое одновременное чтение нескольких файлов, необходимо использовать расслоение дисковых массивов и увеличить количество сетевых портов со стандартных двух до четырех-восьми, что, возможно, потребует также замены маршрутизатора. Однако ни одно из этих требований не является чем-то уникальным, и, как минимум, не дороже решений, построенных на отдельных файловых хранилищах.

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

Многие организации, использующие файловые архивы, имеют распределенную структуру, их филиалы и отделения могут быть расположены по всему миру. Файлы, полученные средствами САПР или путем сканирования оригиналов, могут достигать нескольких десятков мегабайт. Обращение к ним по глобальным сетям или удаленным сегментам локальной сети будет существенно тормозить работу. Сгладить эту проблему позволяет распределенное хранение файлов, обеспеченное в TDMS файловыми серверами.

Использование файловых серверов

Файловый сервер — компьютер в сети, на котором ведется файловый архив, доступный для пользователей, зарегистрированных в системе. Это позволяет снять нагрузку с основного сервера базы данных и его каналов связи.

При использовании файловых серверов СУБД по-прежнему хранит все семантические данные, включая записи об имеющихся файлах. Однако сами файлы определенным образом размещаются в классической файловой системе и управляются специальным сервисом.

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

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

• Файловые серверы не обеспечивают необходимого уровня надежности в управлении файловыми данными. Вероятность нарушения целостности в случае отказа одной из распределенных подсистем значительно выше, чем в решении, построенном на централизованном хранении файлов в СУБД.
• Создание единой резервной копии требует синхронизации всех файловых серверов, что в некоторых случаях может быть достигнуто только путем полного отключения пользователей и остановки служб файловых серверов. Впрочем, то же самое необходимо предпринять и для восстановления данных.
• Возможно, службы безопасности или департаменты по информационным технологиям некоторых организаций могут предъявить претензии к ненадлежащему соблюдению таких требований, как безопасность и доступность.

Если недостатки файловых серверов столь очевидны, стоит ли вообще их использовать для работы? Оказывается, да!

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

Хранение файлов в СУБД с кэшированием

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

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

Рис. 1

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

Кроме основных способов TDMS поддерживает хранение файлов в виде внешних ссылок.

Хранение файлов в виде ссылок

Хранение файлов в виде ссылок не предполагает хранения тел файлов, которые могут находиться в произвольном месте локальной или глобальной сети. Система хранит только ссылки на файлы в формате URL (Uniform Resource Locator) — унифицированного указателя информационного ресурса, представленного в виде стандартизованной строки символов, указывающей местонахождение файла в сети.

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

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

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

Итог

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

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

Определение составных документов

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

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

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

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

Абсолютные и относительные ссылочные пути

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

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

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

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

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

Если относительные ссылки настолько удобны, почему не используют только их? Как это ни странно, но все приложения, работающие с составными документами, поддерживают работу с абсолютными путями, и только часть из них — с относительными. Более того, приложения, которые «понимают» относительные пути, далеко не всегда делают это самостоятельно. Во многих случаях требуется использовать средства автоматизации, позволяющие «на лету» обработать и заменить абсолютные ссылки на относительные. А если приложение не обладает средствами автоматизации или возможности этих средств не распространяются на обработку ссылок, иного способа кроме хранения абсолютных ссылок нет.

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

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

Технология выгрузки файлов на рабочее место пользователя

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

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

Рис. 2

Такой подход позволяет:

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

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

Обработка внешних ссылок при помощи программных интерфейсов

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

.\GUID\Имя_Файла

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

Путь_от_корня\GUID\Имя_Файла

Преобразовать абсолютный путь в относительный можно тремя способами:

• настроить приложение на работу с относительными путями (к сожалению, большая часть приложений делать этого не умеет);
• отредактировать пути вручную. Многие приложения, поддерживающие работу с составными документами, обладают встроенными редакторами связей. Главный недостаток такого подхода в том, что рано или поздно вы забудете это сделать, и возникнут проблемы целостности;
• использовать специальное приложение, обеспечивающее синхронизацию работы c TDMS и обработку ссылок в автоматическом режиме. Чтобы создать такое приложение, потребуются средства автоматизации (для программирования «изнутри»). Приложение, выполняющее функцию посредника между двумя программами, называется программным интерфейсом.

Рассмотрим работу такого приложения-посредника на примере интерфейса TDMS к AutoCAD. Этот интерфейс решает две важнейшие задачи совместной работы обоих приложений:

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

Рис. 3

Для решения первой задачи интерфейс осуществляет:

• поддержку связей между атрибутами объекта TDMS и атрибутами блоков на чертеже AutoCAD (перенос данных из карточки объекта TDMS, а также вычисленных на их основе величин в чертеж AutoCAD);
• сохранение файлов AutoCAD в файловом составе объекта TDMS непосредственно из AutoCAD с поддержанием целостности внешних ссылок;
• вставку в чертежи AutoCAD файлов растровых форматов, хранящихся в TDMS, в виде внешних ссылок;
• вставку в чертежи AutoCAD других чертежей AutoCAD, хранящихся в TDMS, в виде блоков или внешних ссылок.

Не менее важная и вторая задача. Для ее решения интерфейс позволяет:

• не прибегая к излишним переключениям между приложениями, работать с Деревом объектов TDMS непосредственно из AutoCAD (просматривать структуру Дерева объектов, создавать новые объекты в Дереве объектов, выполнять команды TDMS, ассоциированные с данным типом объектов);
• открывать чертежи AutoCAD, хранящиеся в объектах TDMS, для просмотра или редактирования;
• выполнять команды сохранения и разблокировки объекта в TDMS непосредственно из AutoCAD;
• создавать чертежи AutoCAD на основе хранящихся в TDMS шаблонов;
• вставлять в чертежи AutoCAD блоки на основе хранящихся в TDMS шаблонов AutoCAD.

Немаловажно, что интерфейс самостоятельно анализирует ссылки, сохраненные в чертеже. При обнаружении новых ссылок пользователю предлагается сохранить в системе ссылочные файлы. Изменение значения путей производится автоматически. Пользователь работает с объектными категориями: чертежами и листами, — а не с файлами и замысловатыми путями. Это не только упрощает работу, но и позволяет избежать механических ошибок.

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

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

(Продолжение следует)

Скачать статью в формате PDF — 255.0 Кбайт