Классификация банков данных

Классификация банков данных Банки данных являются сложными системами. и их классификация может быть произведена как для всего банка данных в целом, так и для каждого его компонента отдельно; классификация для каждого компонента может быть проведена по множеству разных признаков. 1.1. Классификация баз данных Центральным компонентом банка данных является БД и большинство классификационных признаков относится именно к ней. По форме представления информации различают визуальные и аудиосистемы, а также системы мультимедиа. Эта классификация показывает, в каком виде информация хранится в БД и выдается пользователям. «Изображение» используется в широком смысле: текст, графика, фото, карты, анимационные изображения. Классификация способов представления информации – это самостоятельная проблема. По характеру организации данных БД могут быть разделены на неструктурированные, частично структурированные и структурированные. Этот классификационный признак относится к информации, представленной в символьном виде. К неструктурированным БД могут быть отнесены БД, организованные в виде семантических сетей. Частично структурированными можно считать БД в виде обычного текста или гипертекстовые системы. Структурированные БД требуют предварительного проектирования и описания структуры БД. Только тогда БД такого типа могут быть заполнены данными. Структурированные БД по типу использованной модели делятся на иерархические, сетевые, реляционные, смешанные и мультимодельные. Классификация по типу модели распространяется не только на БД, но и на СУБД. В структурированных БД различают несколько уровней информационных единиц, входящих одна в другую. Число уровней может быть различным даже для систем, относящихся к одному и тому же классу. Большинство структурированных систем поддерживают уровень поля, записи и файла. Эти информационные единицы могут называться в разных системах по-разному, но суть остается одной и той же: полю соответствует наименьшая семантическая единица информации; совокупность полей или иных более сложных ИЕ, если они допустимы в конкретной СУБД, образует запись, а множество однотипных записей представляет файл базы данных. В последнее время большинство СУБД поддерживают в явном виде и уровень БД как совокупности взаимосвязанных файлов БД. В иерархических и сетевых моделях между информационными единицами (записями разных файлов) могут задаваться связи. Графическое представление иерархической модели представляет граф типа «дерево». Сетевая модель – граф типа «сеть». Входом в такую структуру может являться любая вершина.. Каждая вершина может иметь несколько порожденных и/или несколько исходных вершин. Между парой вершин может быть объявлено несколько связей. Подавляющее большинство СУБД поддерживает простые сетевые структуры, т.е. между каждой парой типов записей поддерживается отношение 1 :М. Направление и характер связи в сетевых моделях не являются очевидными. Как в случае иерархической модели, поэтому при изображении структуры БД направление связи должно быть указано. В сетевой модели с однотипными файлами каждый файл может служить входом в структуру. Пара связанных файлов называется набором. В наборе тот файл, от которого идет связь называется владельцем набора, а файл, к которому направлена эта связь – членом набора. Тип файла жестко не зафиксирован. Кроме сетевых моделей с однотипными файлами существуют модели и с разнотипными файлами. В них различают основные (главные) и зависимые файлы. Вход в структуру возможен только через главные файлы. Связываться могут только записи разных типов. Связи в иерархических и сетевых моделях описываются при проектировании БД. Чаще всего эти связи при хранении данных в БД передаются посредством адресных указателей. Иерархические и сетевые модели БД не накладывают ограничений на тип внутризаписной структуры. в принципе она может быть любой: как простой линейной (состоять из простых полей, следующих в записи друг за другом), так и сложной иерархической. включающей различные составные единицы информации (векторы, повторяющиеся группы и т.д.). Конкретные СУБД накладывают ограничения на допустимые в них информационные единицы, характер связей между ними, порядок их расположения в записи, а также часто имеют количественные ограничения. ИЕ1 СВ1 СВ2 СВ3 ИЕ2 ИЕ3 СВ5 СВ4 ИЕ4 Рис.1.Схема сетевой модели с однотипными файлами Г1 З1 З2 Г2 Рис.2. Схема сетевой модели с разнотипными файлами. (Г- главный файл, Ззависимый файл) В реляционных моделях связи между записями разных таблиц БД определяются динамически в момент выполнения запроса. Эти связи устанавливаются по равенству значений соответствующих полей (полей связи), содержащихся в каждом из связанных файлов/таблиц. Другой отличительной чертой реляционных моделей является ограничение на внутризаписную структуру и могут содержать только простые поля. Эти особенности играют решающую роль при проектировании структуры БД. Третьей отличительной особенностью реляционных моделей является использование теоретико-множественных языковых средств: реляционной алгебры или реляционного исчисления. По типу хранимой информации БД делятся на документальные, фактографические и лексикографические. Среди документальных БД различают библиографические, реферативные и полнотекстовые. К лексикографическим БД относятся различные словари (классификаторы, многоязычные словари, словари основ слов и т.п.) В системах фактографического типа в БД хранится информация об интересующих пользователя объектах предметной области в виде фактов; в ответ на запрос пользователя выдается требуемая информация об интересующем его объекте или сообщение о том, что информация отсутствует. В документальных БД единицей хранения является какой либо документ и пользователю в ответ на запрос выдается либо сам документ либо ссылка на него. БД документального типа могут быть организованы по разному: без хранения и с хранением самого исходного документа на машинных носителях. К системам первого типа можно отнести реферативные и библиографические, а также БД – указатели. Специфической разновидностью БД являются БД форм документов. Они обладают некоторыми чертами документальных систем и специфическими особенностями (документ ищется не с целью извлечь информацию, а с целью использовать его в виде шаблона). В последние годы активно развивается объектно-ориентированный подход к созданию ИС. Объектные БД организованы как объекты и ссылки к объектам. Объект представляет собой данные и правила, по которым осуществляется операция с этими данными. Объект включает метод, который является частью определения объекта и запоминается вместе с объектом. В объектных БД данные запоминаются как объекты, классифицированные по типам классов и организованные в иерархическое семейство классов. Класс – коллекция объектов с одинаковыми свойствами. Объекты принадлежат классу. Классы организованы в иерархии. По характеру организации данных и обращения к ним различают локальные (персональные), общие (интегрированные, централизованные) и распределенные БД. Технологии, хотя и кажутся далекими, на самом деле различаются тем, как поддерживается связь между отдельными частями БД. В локальных системах поддержание связи не является централизованным, а в распределенных связь должна поддерживаться СУБД. Совмещать идеи локальной работы и централизованного поддержания единой БД позволяет технология тиражирования, при которой средства СУБД обеспечивают тиражирование отдельных частей общей БД, локальное их использование, а затем согласование отдельных фрагментов БД в рамках единой БД. Концепции централизованной и распределенной обработки данных не сильно различаются между собой. 2. Классификация СУБД Классификационные признаки: 1. По языкам общения СУБД делятся на открытые, замкнутые и смешанные. Открытые системы – это системы, в которых для обращения к БД используются универсальные языки программирования. Замкнутые системы имеют собственные языки общения с пользователями БнД 2. По числу уровней в архитектуре различают одноуровневые. двухуровневые и трехуровневые системы. Возможно и большее количество уровней. Под архитектурным уровнем СУБД понимают функциональный компонент, механизмы которого служат для поддержки некоторого уровня абстракции данных (логический и физический вровень, а также «взгляд» пользователя – внешний уровень). В литературе используются понятия «внешняя», «концептуальная» и «внутренняя» модель/уровень, «логический» и «физический» уровень, а также «внешняя схема», «подсхема» и т.п.. Понятие «схема» относится обычно к описанию соответствующего уровня описания данных. 3. По выполняемым функциям СУБД делятся на информационные и операционные. Информационные СУБД позволяют организовать хранение информации и доступ к ней. Для выполнения более сложной обработки необходимо писать специальные программы. Операционные СУБД выполняют достаточно сложную обработку (автоматически получать агрегированные показатели, не хранящиеся непосредственно в БД. 4. По сфере возможного применения различают универсальные и специализированные, обычно проблемно-ориентированные СУБД. СУБД поддерживают разные типы данных. Набор данных в разных СУБД отличается. Некоторые СУБД позволяют разработчику добавлять новые типы данных и новые операции над этими данными. Такие системы называются расширяемыми БД (РСБД). Дальнейшим развитием концепции РСБД являются системы объектно-ориентированных БД. 5. По мощности СУБД делятся на настольные и корпоративные. Для настольных характерны невысокие требования к техническим средствам, ориентация на конечного пользователя, низкая стоимость. Корпоративные – обеспечивают работу в распределенной среде, высокую производительность, поддержку коллективной работы при проектировании систем, имеют развитые средства администрирования и более широкие возможности поддержания целостности. Оба типа систем интенсивно развиваются. 6. По ориентации на преобладающую категорию пользователей можно выделить СУБД для разработчиков и для конечных пользователей. Системы первого класса должны иметь качественные компиляторы и позволять отчуждать создаваемые продукты, обладать развитыми средствами отладки и др. Основными требованиями, предъявляемыми к системам для конечного пользователя является удобство интерфейса, высокий уровень языковых средств, наличие интеллектуальных модулей подсказок, повышенная защита от непреднамеренных ошибок и т.п. 7. Разделение СУБД по поколениям. 2.1. Общая характеристика проблемы выбора СУБД Сложная проблема, формализовать практически невозможно. Факторы, влияющие на выбор можно разделить на группы: Факторы, характеризующие саму СУБД и средства ее окружения. Факторы, связанные с инфраструктурой, сложившейся вокруг каждого из программных продуктов Факторы, связанные с особенностями предполагаемого использования. СУБД являются сложными языково-программными продуктами. Для обоснованного выбора СУБД необходимо иметь список СУБД - претендентов с описанием их параметров. Характеристики рассматриваются с разной степенью детализации, в зависимости от стоящих задач. Необходимо определить набор свойств, которыми обязательно обладать выбираемая СУБД. Сначала осуществляется предварительный отбор СУБД по качественным параметрам, а уж потом по количественным. При определении временных характеристик СУБД речь обычно идет о тестах на быстродействие. Формальное тестирование заключается в том, что на некотором заданном наборе данных выполняются некоторые операции или наборы операций. Такое тестирование проводят разработчики либо специальные лаборатории. Функциональное тестирование состоит в том. Что исследуются характеристики СУБД при решении определенной прикладной задачи, для реализации которой и выполняется выбор СУБД. Требуется реализовать заданные функции. 2.2. Факторы влияния на выбор СУБД 1. Платформы, на которых функционирует СУБД 2. Совместимость, открытость, масштабируемость 3. Уровень языковых средств - трудоемкость изучения - трудоемкость создания - гибкость - мощность - наличие языков разного уровня 4. Функциональные возможности 5. Обеспечение безопасности 6. Обеспечение целостности 7. Удобство интерфейса. 8. Требования к техническим средствам, операционной среде 9. Ограничения, накладываемые СУБД 10. Возможность создания «отчуждаемых» приложений 11. Степень универсальности 12. Локализация 13. Качество документации 14. Устойчивость работы, отлаженность системы 15. Наличие средств автоматизации проектирования. Трудоемкость проектирования. 16. Стоимость 17. Мода. Тенденция Сюда же относятся фирма –разработчик, распространенность, условия поддержки. Важную группу составляют факторы, характеризующие предметную область, для которой будет создаваться ИС: масштаб, характер обработки информации, требования к реакции системы, безопасности данных. На выбор СУБД будет влиять квалификация сотрудников и наличие предшествующих наработок. СПИСОК ИНФОРМАЦИОННЫХ СИСТЕМ Компания Названия основных продуктов 1С 1С:Предприятие АиТ АиТ:\Управление персоналом Baan Baan IV Microsoft Axapta, Attain Oracle Oracle Applications 1С:Рарус 1С:Рарус R-Style Software Lab RS-Balance SAP R/3 АйТи БОСС Компания Аплана подразделение АйТи) Галактика Инталев Интеллект-Сервис (бывш. БОСС Корпорация Галактика Инталев:Корпоративные Инталев:Управление финансами БЭСТ-ПРО финансы, Интерфейс Корпоративные финансовые системы Парус iRenaissance.ERP IFS Парус Корпорация Версия Project Expert 5.0 является наиболее мощной и расширенной из семейства систем Project Expert, предназначенных для разработки и финансового анализа стратегического плана развития предприятия.  Наиболее полезные новые функциональные возможности:  возможность построения собственных формул для налогооблагаемой базы;  возможность ввода стартового баланса действующего предприятия;  эмуляция общего склада сырья, материалов, комплектующих изделий, возможность моделирования условий закупок, хранения и использования ресурсов в производстве;  возможность ввода фактических данных;  независимое планирование производства и сбыта продукции;  более гибкие средства формирования и отображения сетевого графика инвестиционного плана;  более гибкие процедуры формирования капитала и моделирования процесса использования свободных денежных средств;  более мощные средства формирования финансовых отчетов, включающие настраиваемые: отчет о финансовых результатах, отчет о движении денежных средств, бухгалтерский баланс, отчет об использовании прибыли, расчет и представление согласования фактических и плановых показателей. Компьютеры, программное обеспечение, базы данных, сетевые технологии, Интернет в разной степени используются практически всеми организациями. Без эффективных ИС и ИТ невозможно обойтись и они могут помочь любой организации добиться радикальных улучшений показателей своей деятельности и своей позиции на рынках, но мало кто может дать квалифицированный ответ на вопрос «Как?» Если рассматривать информацию и информационные технологии как стратегические ресурсы, это позволяет создавать системы управления организацией на основе ИС и ИТ, соответствующие интересам этой организации и ее стратегическим целям. Ключевые показатели деятельности предприятий, практикующих применение принципов стратегического управления ИС, оказываются лучше, чем у их конкурентов, не применяющих этих принципов. По данным IT Governance Institute 32% компаний из списка “Fortunate 500” имели комитеты стратегического управления ИТ и еще 29% компаний стратегический план развития ИТ разрабатывался и утверждался на уровне совета директоров. С другой стороны, средним показателем среди компаний, не использующих современные подходы к управлению ИС, являлся 75% уровень провалов проектов развития ИС. Поскольку с основными понятиями информатики, информационного и сетевого обмена знакомство уже состоялось, больше внимания в курсе будет уделяться оценке роли информационных систем в современной конкурентной бизнес-среде, рассмотрению ИС как с технической точки зрения, так и с точки зрения развития бизнеса, пониманию отличия компьютерной грамотности от знаний в области ИС. Особое место занимают вопросы влияния ИС на трансформацию организации и методов управления, а также вопросы преимущества управленческих структур за счет создания и применения ИС в организациях. Место и задачи ИС в организации можно проиллюстрировать рис.1. На рисунке показаны существующие задачи организации и базовые составляющие информационной системы, обеспечивающие разработку бизнес-решений в соответствии с существующими бизнес-проблемами организации. Известно, что знание информационных систем является существенным для менеджеров, поскольку большинство организаций нуждается в этих системах для своего выживания и дальнейшего процветания. ИС могут помочь компаниям расширить свое присутствие на новых рынках, предложить новые товары и услуги, изменить течение занятий и работы, а также методы, с помощью которых осуществляется бизнес.  Планирование продуктового портфеля  Формулирование целевых показателей продаж  Разработка стратегии изменений  Частные web-сайты  Настольные компьютеры  Сеть Apparel Buing Network  Поставщики  Розничные торговцы  Розничные потребители  Служащие Б и з н е с-п р о б л е м ы Менеджмент Технология Организация  Проблемы координации как следствие быстрого роста  Процессы, выполняемые вручную  Новые инициативы конкурентов Информационная система  Заказ товаров  Отслеживание заказов  Доступ к информации о персональных льготах  Доставка товаров  Распространение сообщений  Улучшение обслуживания  Уменьшение затрат  Рост прибыли Рис. 1. ИС в организации Организация обмена данными между ERP-системами и российскими средствами формирования бухгалтерской отчетности Постановка задачи Все больше отечественных предприятий проявляют интерес к информационным системам, позволяющим автоматизировать процессы планирования и управления ресурсами предприятия. Особенно остро проблема автоматизации стоит для крупных и средних предприятий, для которых сохранение старых управленческих технологий грозит потерей эффективности управления в быстро изменяющихся условиях рыночной конкуренции. Поскольку первыми в формирование нынешнего экономического механизма включилось большое количество малых предприятий, они создали высокий и устойчивый спрос в первую очередь на программные средства автоматизации ведения бухгалтерской отчетности и на средства автоматизированного поиска юридической информации. Разработка же средств автоматизации оперативного и управленческого учета для отечественных производителей программных продуктов оставалась на втором плане, и сейчас ни одна из отечественных систем автоматизации управления предприятиями не признается соответствующей всем международным стандартам для таких систем. В этом одна из основных причин интереса отечественных предприятий к западным ERP-системам. Вторая причина этого интереса состоит в том, что внедрение таких систем способствует повышению привлекательности компании для зарубежных инвесторов. В то же время внедрение подобной западной системы создает и определенные проблемы. Дело в том, что они ориентированы на автоматизацию управленческого оперативного учета и не решают задач формирования бухгалтерской отчетности, которую предприятие по-прежнему должно предоставлять в фискальные органы и которая должна быть выполнена по российским стандартам. Кроме того, существуют определенные проблемы с адаптацией западных подсистем расчета заработной платы к российским реалиям. Проблема формирования фискальной отчетности решается либо при помощи генератора отчетов, который будет формировать требуемую отчетность на основании имеющихся в базе ERP-системы сведений, либо ведением параллельного учета в какойлибо из российских систем. Первый вариант решения оставляет открытым вопрос о расчете заработной платы, а кроме того, стандарты российской отчетности имеют неприятное свойство ежеквартально меняться. Второй вариант позволяет возложить заботы по отслеживанию изменений в формах отчетности на фирму-производителя соответствующей российской системы бухгалтерского учета и решает проблему расчета заработной платы с учетом отечественной специфики. Но этот вариант требует автоматизированного канала обмена данными между двумя системами, так как вряд ли найдутся желающие дважды вводить одну и ту же первичную информацию в две разные системы. Таким образом, возникает задача создания средств, обеспечивающих обмен данными между ERP-системами и российскими системами формирования бухгалтерской отчетности. В качестве системы российского бухгалтерского учета (РБУ), вообще говоря, может выступать любая из использующихся ныне систем, успешно зарекомендовавших себя в этой области. При выборе системы необходимо учитывать следующие характеристики:  открытость системы - доступность информации о форматах хранения данных и возможность создания пользовательских приложений;  уровень соответствия выходных форм фискальной отчетности требованиям нормативов;  регулярность обновления форм отчетности фирмой-производителем;  наличие у пользователя опыта работы с какой-либо определенной системой и соответственно наличие обученного персонала. При разработке системы обмена имеет смысл исходить из некоторых предположений о характере ее предстоящего использования. Во-первых, предполагается, что ввод всех первичных документов выполняется в ERP-системе, а российская система используется для расчета зарплаты и формирования фискальной отчетности. Во-вторых, предполагается, что процедуры формирования фискальной отчетности и расчета заработной платы происходят с определенной периодичностью (1-2 раза в месяц) и не требуют от системы оперативного обмена данными в режиме реального времени. Основные требования к системе Задачи, которые должна решать система обмена данными, и предположения о характере ее использования позволяют сформулировать следующие требования к механизму обмена. 1. Он должен обеспечивать передачу из ERP-системы в систему РБУ всей информации, которая необходима для формирования отчетности в соответствии с российскими стандартами: это проводки хозяйственных операций и все элементы справочников, на которые имеются ссылки в проводках. 2. Он должен обеспечивать передачу из системы РБУ в ERP-систему информации из тех разделов учета, которые по тем или иным причинам ведутся в системе РБУ, а данные из них требуются для работы разделов, обслуживаемых в ERP-системе. 3. Он должен гарантировать полноту передаваемой информации с учетом возможного внесения изменений и дополнений в информационную базу. 4. Он не должен допускать повторной передачи ранее переданных данных, которые после передачи не подвергались изменениям, если пользователь не требует такой передачи сознательно. 5. В нем должна присутствовать процедура верификации переданной информации. 6. Для настройки механизма обмена (в идеале) должно быть достаточно введения соответствующих настроечных параметров; это не должно требовать модификации текстов программных модулей. Варианты реализации В первом из рассматриваемых вариантов используется резидентная программа управления обменом, имеющая доступ к табличному представлению данных обеих взаимодействующих систем. В таблицы ERP-системы, содержащие информацию о проводках и сопутствующую им аналитику, добавляются триггеры, обеспечивающие периодический опрос состояния соответствующих таблиц на предмет наличия или отсутствия изменений. Программа управления обменом резидентно присутствует в памяти, через ODBC-драйвер следя за состоянием этих триггеров; при обнаружении факта модификации данных она передает произошедшие изменения в систему РБУ. Аналогично происходит передача в обратном направлении данных по кадрам и зарплате. Преобразование проводок из формата их хранения в ERP-системе в формат системы РБУ может выполняться как процедурами обслуживания соответствующих триггеров, так и программой управления обменом. Для такого варианта организации обмена данными характерна высокая оперативность. Однако для его успешной реализации требуется подробная информация об организации данных в обеих системах на табличном уровне представления. Далеко не во всех случаях такая информация доступна стороннему разработчику. Поэтому наилучшие результаты при реализации такого варианта будут достигнуты в том гипотетическом случае, если система обмена данными будет создаваться совместными усилиями фирмразработчиков объединяемых ERP-системы и системы РБУ. В большинстве современных систем разработчик приложений может пользоваться языком высокого уровня, который дает ему возможность работать со сложными агрегатными объектами, но при этом скрывает от него табличный уровень представления таких объектов. Если одна из объединяемых систем или обе построены по этому принципу, реализовать рассмотренный выше подход будет достаточно сложно. В этом случае более приемлемым может оказаться подход, который позволит в максимальной степени применить возможности встроенного языка соответствующей системы. Один из таких подходов - использование буфера обмена, представляющего собой каталог для временного хранения промежуточных файлов. Формат файлов выбирается таким, чтобы с ним могли работать обе объединяемые системы. Этот подход реализуется в двух вариантах, первый из которых инициирует процедуру экспорта или импорта данных по запросу пользователя. Он менее оперативен по сравнению с остальными, но не требует резидентного присутствия в памяти каких-либо приложений, а его реализация требует минимальных трудозатрат. Второй вариант осуществляет автоматический обмен данными с заданной периодичностью. Он обеспечивает более высокую оперативность обмена, но требует постоянной активности специально выделенного для этих целей приложения системы РБУ. Еще один подход - использование системы РБУ как OLE-сервера. Естественно, он применим только при условии, что система РБУ может выступать в таком качестве. Этот подход потенциально способен обеспечить максимальную оперативность обмена (вплоть до режима реального времени). Для его функционирования потребуется резидентное присутствие в памяти программы управления обменом и приложения системы РБУ, выступающего в роли OLE-сервера. В тех же случаях, когда ERP-система допускает непосредственное обращение к OLEсерверу, отпадает необходимость в программе управления обменом. Варианты для iRenaissance Применительно к ERP-системе iRenaissance компании Ross Systems, кроме перечисленных вариантов реализации механизма передачи данных, есть еще два способа выборки необходимой информации из базы iRenaissance. Это связано с тем, что данные о проводках одних и тех же хозяйственных операций существуют в iRenaissance в нескольких экземплярах. С момента их возникновения эти данные хранятся в специализированных таблицах того функционального модуля, где они создавались. Далее они поступают в таблицу промежуточного хранения модуля главной книги GL_POSTINGS и после процедуры обновления главной книги попадают собственно в таблицы главной книги. Соответственно и извлечь эти данные можно как из таблиц главной книги, так и из таблиц функциональных модулей. Одна из попыток создания системы обмена данными iRenaissance с системой РБУ принадлежит компании Interface Ltd.. В качестве системы РБУ была выбрана "1С:Предприятие" фирмы 1С. На выбор здесь повлияли следующие факторы:  фирма-разработчик ежеквартально обновляет все формы регламентированной отчетности в соответствии с изменениями российского законодательства;  открытость и хорошая документированность системы "1С:Предприятие" , благодаря чему пользователь при необходимости может вносить в нее необходимые изменения самостоятельно или с привлечением сторонних организаций, не связанных непосредственно с компанией "1С";  широкая распространенность и известность системы. Обмен данными между iRenaissance и "1С:Предприятие" Основные проблемы, с которыми пришлось столкнуться с самого начала разработки, были связаны со сложностями поиска сопутствующей проводкам аналитики в базе iRenaissance. Эти проблемы обусловлены как многовариантностью способов хранения данных аналитического учета для различных типов хозяйственных операций, так и тем, что далеко не все реально существующие связи между таблицами iRenaissance отражены в соответствующей документации. Поскольку таблицы проводок функциональных модулей отличаются большим разнообразием форматов, для обмена был выбран вариант выборки данных из таблиц модуля главной книги. В системе "1С:Предприятие" имеется язык высокого уровня, работающий со сложными агрегатными объектами, но скрывающий табличный уровень представления этих объектов как от пользователя, так и от прикладного программиста. Поэтому способ реализации обмена пришлось выбирать из последних трех вариантов, описанных выше. Исходя из требований минимизации срока разработки и с учетом выделенных на это сил, остановились на варианте передачи данных через буфер обмена в виде текстовых файлов с активизацией процесса передачи данных по запросу пользователя. Однако в дальнейшем отработанные на этом варианте механизмы извлечения данных из базы iRenaissance можно будет использовать для создания системы обмена через OLE-интерфейс в соответствии с третьей или четвертой схемами. Реализованный прототип системы обеспечивает двусторонний обмен данными между iRenaissance и "1С:Предприятие" . В состав передаваемых данных входят проводки хозяйственных операций; аналитика передаваемых проводок по клиентам, поставщикам, подразделениям, товарам; виды и курсы используемых в проводках валют. Протокол обмена данными обеспечивает выполнение следующих функций:  пометку экспортированных данных;  проверку подтверждения приема со стороны получателя;  исключение повторного экспорта уже экспортированных и успешно принятых данных;  повторный экспорт в отсутствие подтверждения получателя;  проверка корректности принимаемых данных и формирование подтверждения приема. Для настройки правил корреспонденции счетов для экспорта хозяйственных операций нужно заполнить соответствующие настроечные таблицы. Исходные данные для заполнения этих таблиц в уже установленной базе iRenaissance можно получить, изучив набор проводок, порождаемых каждой хозяйственной операцией. Если база iRenaissance еще не настроена, исходные данные для настроечных таблиц системы обмена данными можно получить в процессе установки iRenaissance посредством протоколирования задаваемых параметров каждой хозяйственной операции. Прорабатывается возможность создания механизма, обеспечивающего автоматизированную настройку правил корреспонденции и экспорта данных из iRenaissance параллельно с установкой и настройкой соответствующих функциональных модулей этой ERP-системы. В заключение отметим, что отработанные в рамках данного проекта алгоритмы преобразования данных можно использовать при создании систем обмена данными между другими ERP-системами и системами РБУ.