Компьютер в бухгалтерском учете и аудите 1998'3
	Home Поиск Издания Контакты k-press.ru

Продолжается подписка на наши издания! Вы не забыли подписаться?

ООО “ПК-СОФТ”

Управление распределенными базами данных в системе Trade Assistant

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

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

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

В этой статье мы рассмотрим основные проблемы, возникающие при обмене данными между распределенными базами и коротко опишем их решения в системе Trade Assistant.

Разрешение конфликтов

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

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

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

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

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

Случай полной синхронизации является относительно простым. Каждая база данных имеет два вспомогательных каталога: выходной каталог OUTBOX, в который записываются все изменения, происшедшие со времени последнего обмена, и входной каталог INBOX, из которого в базу поступают данные во время сессии обмена. Затем данные из выходного каталога первой базы попадают во входной каталог второй, и наоборот. Схема обмена данными изображена на рис. 1.

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

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

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

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

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

Эта проблема в системе Trade Assistant решена путем установки фильтров при обмене данными, причем фильтры можно установить и на входе, и на выходе. Это значит, что пользователь может ограничить как экспорт данных (передавать не всю информацию), так и импорт (принимать не всю информацию). Использование гибкой системы фильтров характерно для программного комплекса Trade Assistant, при обмене эта система может быть применена в полной мере: установкой соответствующих фильтров пользователь может передать любую выборку данных из базы.

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

Разрешение конфликтов при частичной синхронизации происходит таким же образом, как и при полной.

Использование подстановок

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

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

Любимый клиент => Самый любимый клиент.

В этом случае при обмене во всех записях идентификатор “Любимый клиент” будет заменен на “Самый любимый клиент”.

При экспорте данных из второго филиала в первый надо установить обратную подстановку:

Самый любимый клиент => Любимый клиент.

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

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

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

Автоматический запуск обмена

Обмен данными между распределенными базами можно осуществлять с любой периодичностью. Часто достаточно проводить сессии обмена раз в день или даже реже. В этом случае оператору не составляет труда запускать обмен вручную.

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

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

Примеры управления распределенными базами данных

Приведем несколько типовых случаев, в которых необходим обмен данными между удаленными базами и примерные решения возникающих при обмене задач в системе Trade Assistant.

Склад — офис

Пусть компания имеет офис и удаленный склад. В офисе принимаются заказы, которые затем на складе переводятся в накладные. Накладные с пометкой кладовщика об отгрузке возвращаются в офис (см. рис. 2).

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

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

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

Головной офис — филиалы

Пусть компания имеет головной офис, склад и сеть магазинов. Закупки производятся централизованно, в головном офисе, а затем с основного склада распределяются по магазинам. В базе данных головного офиса это распределение отражается как операция перемещения между складами, в то время как в базе данных магазина оно должно отражаться как приход извне (например, закупка от поставщика “Офис”) (см. рис. 3).

Очевидно, что здесь не обойтись без подстановок: операция перемещение Офис=>Магазин при обмене замещается на операцию закупка Офис=>Магазин.

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

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

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

Рассмотрим пример холдинга, состоящего из нескольких относительно независимых компаний. Желательно иметь возможность получать отчеты как по деятельности каждой компании в отдельности, так и всего холдинга в целом (см. рис. 4).

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

При наличии общих клиентов или товаров в различных базах необходимо сделать соответствующие подстановки.

Руководитель — офис

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

Рис. 5

Партнерские отношения

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

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

Рис. 6

Таким образом, при обмене в одну сторону передается только состояние склада, а в другую — только заказы этому конкретному поставщику (см. рис. 6).

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

Е.А. Гамазова

С вопросами и предложениями обращайтесь digraph@rinet.ru

Copyright © 1994-2016 ООО "К-Пресс"