Ведение клиентов

Ведение клиентов

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

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

Автоматизированное ведение базы клиентов

Сегодня компаниям, которые хотят идти в ногу со временем и наладить безупречные рабочие процессы, доступно специальное программное обеспечение для ведения клиентской базы - система управления взаимоотношениями с клиентами - CRM (от англ. «Customer Relationship Management»). CRM призвана значительно упростить учет и обслуживание всех клиентов компании посредством автоматизации работы с клиентской информацией.

Клиентская CRM база данных для ведения клиентов онлайн

Удобная CRM база Приведите клиентскую базу в порядок

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

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

Анализируйте своих клиентов

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

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

Повышайте продажи и качество клиентского сервиса

Удобная CRM база для клиентов сэкономит ваше время на лидогенерацию благодаря интеграции с сервисами email-, sms-рассылок и ip-телефонии. Также amoCRM поможет сохранить и обработать лиды.

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

База данных Access - Сведения о клиентах и заказах

База данных Access "Сведения о клиентах и заказах"

1) Спроектировать базу данных (БД) согласно варианту задания.

2) Написать запросы SQL на создание всех спроектированных таблиц.

3) С помощью 2-х запросов SQL изменить структуру двух таблиц (например, добавить или удалить какой-либо атрибут), показать результаты изменения.

4) Внести данные в таблицы в режиме Таблица -> Открыть (не менее 10 кортежей в каждой таблице).

5) Создайте запросы SQL, которые будут использоваться для манипулирования данными:

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

8) Сформулировать 2 многотабличных запроса, создать их на SQL и показать результаты их выполнения.

Проектирование базы данных

Рассмотрим основное отношение, соответствующее базе данных "Сведения о клиентах и заказах".

Код клиента, Название, Имя, Фамилия, Адрес счета, Город, Регион, Индекс, Страна, Должность, Телефон, Факс, Сумма долга, Код заказа, Код клиента, Код сотрудника, Номер заказа, Дата заказа, Модель, Серийный номер, Описание, Дата завершения, Ставка налога.

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

Программа учета Клиентов

Доклад-исследование: CRM-Система "Тренинг-Семинар-Конференция"

Руководитель IT-отдела

консалтинговой компании "ТРИЗ-ШАНС" (Санкт-Петербург),

кандидат физико-математических наук

Данный материал подготовлен в формате Доклада-исследования и преследует 2 цели: с одной стороны - рассказать о нашей работе над компьютерной программой по взаимодействию тренингово-консалтинговых компаний с их Клиентами, а с другой - получить ответы уважаемых Специалистов на вопросы о том, что ещё нужно учесть в создаваемой программе?… В текст Доклада встроены формы для Ваших ответов.

1. Тенденции-2008

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

ПРИМЕР-1. "Сегодня развитые российские организации (прошедшие фазы экспансии и минимизации издержек) уже ощущают потребность в обеспечении наценки выше среднерыночной и лояльности за счет индивидуализации Клиентских отношений. И хотя задача опережающего наращивания Клиентской базы и завоевания доли рынка не снята с повестки дня, необходимо "смещать фокус" с операций на собственно продажи и обслуживание, то есть в сторону CRM (Customer Relationship Management - управление взаимоотношениями с Клиентами)".

Павлов А. Рост: и благо, и беда, журнал "Менеджмент роста", 2008 г. N 1-2, с. 10.

ПРИМЕР-2. "В сетях потребители, которые потребляют много, платят больше. Джеймс Уордер Паттен так характеризует эту ситуацию в пулах: "Верные потребители тратят в тринадцать раз больше, чем случайные в ресторанах, в двенадцать раз больше в авиакомпаниях и в пять раз больше в гостиничном бизнесе".

Молино П. Технологии CRM, М. "Фаир-пресс", 2004 г. с. 92.

Чтобы удержать Клиента, сделать его лояльным, с ним нужно работать более точно, прицельно. Это означает, что компания должна больше знать о каждом своем Клиенте. При этом:

"Информация должна принадлежать всей организации и никому в отдельности (отчуждение от носителя)".

Павлов А. Рост: и благо, и беда, журнал "Менеджмент роста", 2008 г. N 1-2, с. 10.

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

1.2. С другой стороны, если количество Клиентов измеряется хотя бы десятками, то нужна технология:

• снижающая время, расходуемое на работу с каждым Клиентом;

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

ПРИМЕР-3. Несколько лет назад телекоммуникационная компания "Рас Bell" приказала своим операторам перестать говорить "пожалуйста", чтобы сэкономить время. ПРИМЕР-4. При организации даже небольшого мероприятия, например, на 20 человек, необходимо сделать большое количество мелких однообразных (повторяющихся) действий… и, по возможности, не совершать ошибок. Так, при решении такой простой задачи, как формировании счетов для участников небольшого семинара, нужно учесть, что:

• один участник оплатил участие до оговоренной заранее даты и должен получить скидку…

3 участника представляют одну организацию и также должны получить скидку, но другую…

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

1 участник оплатил свое участие от компании, но хочет приобрести книгу ведущущего семинара "для себя" и оплатить её непременно Яндекс-деньгами.

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

2 участника просят поселить их отдельно от остальных в 5-звездочном отеле, причем хотят заехать за 3 дня до начала семинара…

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

3 участника просят внести изменения в Договор и счет, так как иначе "наша бухгалтерия не пропустит"…

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

• сама искать информацию
• принимать решения

- то ошибки неизбежны. Проверено многократно…

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

И в этот момент может прийти понимание: хороша та Технология, которая - вопреки утверждениям тренинговых компаний - не повышает, а снижает требования к квалификации Сотрудников. См. подробнее: Викентьев И.Л. Бизнес-процесс.RU: 5 = 2 = 0

2. CRM-системы

На столкновении указанных выше тенденций индивидуализации и автоматизации родились так называемые CRM-системы, цель которых:

• Прежде всего - исключить воспроизводящиеся ошибки;

Аккумулировать информацию о Клиентах, вести списки Клиентов;

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

CRM - это аббревиатура от английского "Customer Relationship Management", что означает "управление отношениями с Клиентами". С технической точки зрения CRM представляет собой множество взаимосвязанных электронных таблиц, содержащих информацию о:

• компании;
• ее товарах, услугах, мероприятиях;

• ее Сотрудниках;

• типовых письмах, Договорах;

• скидках и бонусах;

• и - самое главное - базу данных о Клиентах: как потенциальных, так и реально существующих.

3. Грехи CRM

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

Ошибка-1. Программисты детальнейшим образом описывают абсолютно все действия идеальных менеджеров компании так, как это удобно им (программистам), а не так, как это было бы удобно несовершенным менеджерам… При внедрении CRM-систем, которое порой длится месяцами, менеджеры компании успешно саботируют процесс "внедрения" новой технологии…

Ошибка-2. Абсолютно понятно желание софтверных компаний заработать, но - как известно - не все способы хороши для заработка. Известны случаи, когда зарубежные CRM-системы были столь масштабны и их внедрение было столь сложным и трудоемким, что весь проект обходился в сотни миллионов долларов (!) и годы "внедрений"… Понятно, что в больших и громоздких системах всегда есть ошибки, и их отладка может длиться неограниченно долго.

4. Наш подход

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

• выбрали одно из направлений, которыми мы интенсивно занимаемся уже более 15 лет: тренинги, семинары, конференции, консалтинг;

предварительно провели опрос ряда отечественных тренинговых и консалтинговых компаний (как устно, так и online).

Результаты проведенного опроса можно свести к следующим пунктам:

4.1. Подавляющее большинство тренингово-консалтинговых компаний - это небольшие компании, которые, как правило, включают не более пары десятков штатных Сотрудников (другое дело, что по Договору с этими компаниями могут работать десятки внештатников, а число Клиентов исчисляться тысячами и десятками тысяч).

Сколько Клиентов проходит через Вашу компанию в год?

5000…10000

больше 10000

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

Если речь идет о начинающем Сотруднике, ожидать от него качественной работы наивно…

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

4.3. Часто подобные компании ведут списки своих Клиентов либо в таблицах Microsoft Excel, либо вообще в Word… Иногда используются "самописные" базы данных, в которых хорошо разбирается только программист, их написавший.

Как хранится информация о Клиентах в Вашей компании?

Таблицы Microsoft Excel

Таблицы в документах Microsoft Word

Базы данных Microsoft Access

Написанное на заказ ПО

Иное ПО. Укажите:

Сколько сотрудников Вашей Компании должны иметь доступ к этой информации? Укажите количество:

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

С учетом запросов тренинговых и консалтинговых компаний и типовых проблем, мы приступили к разработке CRM-системы "Тренинг-Семинар-Конференция".

Стоимость CRM-системы "Тренинг-Семинар-Конференция" может составлять:

2 зарплаты менеджера-продаж

2 зарплаты бизнес-тренера / консультанта

2 зарплаты ведущего бизнес-тренера / консультанта

Ваше мнение в свободной форме:

5. Дальнейшее изложение построено как описание действий менеджера хронологически: от планирования мероприятия до подведения его итогов

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

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

5.2. Перед организацией мероприятия нужно выполнить ряд действий:

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

договориться с ведущим (это может быть как свой, так и приглашенный Специалист);

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

определить цену и скидки;

согласовать все это с Руководителем компании;

проинформировать всех Сотрудников компании, участвующих в организации мероприятия;

разместить подробную информацию на своем сайте;

разместить подробную информацию в сети, например, на портале TREKO.RU

Для занесения результатов всех этих действий в базу программы предназначена форма "Мероприятия":

Важный момент: программа интегрирована с Интернет-порталом TREKO.RU и позволяет автоматически разместить информацию о мероприятии на портале

Какие еще действия нужно выполнить при планировании мероприятия? Ваше мнение в свободной форме:

5.3. Планиование

Программа позволяет планировать различные подготовительные этапы мероприятия, например:

• Переписку с ведущим / тренером либо Докладчиками (если речь идет о Конференции);

Переписку с Клиентами.

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

Контакты с Подрядчиками (помещение для проведения мероприятия, организация питания, размещение Участников, оборудование)

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

Какие данные программа должна сообщать Руководителю? О каких событиях, действиях?

С какой периодичностью?

Несколько раз в день

Непосредственно через CRM-систему

Письмом по e-mail

5.4. Далее наступает этап продвижения и продаж:

Очевидно, что Клиенты привлекаются разными способами. Это могут быть:

• телефонные звонки,

электронные рассылки,

публикации в прессе,

распространение листовок на выставках и т.п.

Понятно, что CRM-система не может сама распространять листовки и звонить (хотя может помочь подготовить персонализированные обращения для факса)… Об этом подробнее написано здесь: Соколов Г. Б. 30 проверенных способов продвижения тренинговых и консалтинговых услуг Что же она может?

• По 1 щелчку мыши сформировать список потенциальных Клиентов из тех, которые уже проходили обучение по сходной тематике либо оставили заявку "на тему" или "на бизнес-тренера";

При этом она должна учитывать, что есть ТОП-менеджмент, есть Специалисты, есть начинающие Сотрудники, а также, что существуют Конкуренты, которые тоже могут прийти, и существует "черный список".

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

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

Впрочем, вот более забавный пример:

ПРИМЕР-5. "В июле 2001 года Сотрудники сафари-парка Blair Drummond в Шотландии были завалены беспрерывной чередой телефонных звонков, где на том конце кто-то только тяжело дышал в трубку. Оказалось, что это выходка Чиппи, местного шимпанзе, стащившего мобильный телефон у смотрителя. Да, вот до чего дошло - даже у шимпанзе теперь есть мобильные телефоны!"

Хилл Сэм, Шестьдесят трендов за шестьдесят минут, СПб, "Крылов", 2004 г. с. 188.

• Программа также позволяет подготовить текст персонального приглашения и разослать его по e-mail, факсом или обычной почтой всем потенциальным Клиентам.

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

ПРИМЕР-6. Недавно я получил письмо от одного из банков, в котором ко мне обращались так: "Дорогая Георгий Борисович!"

Не является секретом, что в тренинговых фирмах часть общения с Клиентами осуществляется по телефону, часть по e-mail. Даже начинающему менеджеру при телефонном разговоре несложно вежливо обратиться по телефону, скажем, к Александру Ивановичу либо Александре Ивановне . Другое дело, если речь идет об отправке нескольких десятков или сотен писем разным людям, с которыми менеджер не знаком, при этом не перепутать их ФИО, пол (!), должности, названия фирм и т.п. Поэтому в программе встроен блок персонализации, которого мы к своему удивлению не обнаружили в других программах… Этот блок автоматически (!) определяет пол Клиента, правильно склоняет его ФИО в зависимости от пола и добавляет в текст письма любые его персональные данные.

Какие персональные данные Клиента, кроме его ФИО, чаще всего используются в переписке?

5.5. Важный этап - это регистрация Участников и внесение информации о них в базу данных программы. На этом этапе программа позволяет:

• Разместить на портале TREKO.RU регистрационную форму мероприятия;

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

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

Какую информацию о Клиенте нужно заносить в базу при регистрации (кроме традиционных контактных данных)?

5.6. Работа с документацией

На этом этапе программа позволяет подготовить Договора и Счета и отправить их Клиентам по e-mail. Естественно, как этого требуют правила бухгалтерского учета, оригиналы документов будут подготовлены уже непосредственно к мероприятию.

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

5.7. Непосредственно перед мероприятием

Программа позволяет подготовить и распечатать различные документы, например:

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

Списки всех участников с их контактными данными

Списки обедающих

Списки участвующих в вечернем фуршете

Именные бэджи всех Участников

Дипломы, сертификаты и т.п.

Конверты, наклейки (например, для рассылки Каталогов компании)и т.п.

Какие еще документы необходимо подготовить к мероприятию?

5.8. После мероприятия

По окончании мероприятия программа позволяет:

• Подсчитать, сколько Участников фактически присутствовали

Программа для ведения Клиентской базы данных - SoftWare

Preslilvs 18 Ноя 2012

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

oldbay 18 Ноя 2012

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

kenika 19 Ноя 2012

SaltCRM круче

Ladomir 19 Ноя 2012

Могу предложить "Клиенты" - программу для ведения клиентской базы предприятия.

Учет информации о клиентах организации, товаров/услуг, заказанных клиентами, контактах с клиентами. "Карточка клиента" содержит информацию клиенте, отображает все товары клиента, состояние учетных документов, историю контактов.

Оповещение по дате контроля контакта.

Оповещение по дню рождения сотрудников клиента.

Быстрый ввод заказа из меню.

Загрузка клиентской базы из файла MS Excel.

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

Предусмотрено разделение прав доступа, пользователю можно назначить один из четырех интерфейсов: Администратор, Старший менеджер, Менеджер, Просмотр. Имеется возможность установить для пользователя реквизит "Видеть только своих клиентов".

Программа бесплатная. Подробности в личку.

Программа «База Клиентов 2

Программы / Программа «База Клиентов 2.0» / Программа «База Клиентов 2.0»

Бесплатная, сетевая, многопользовательская версия простой CRM-системы. Скачайте, установите и работайте без помощи программиста - очень просто!

Основные особенности бесплатной программы «База Клиентов 2.0»

• Назначение каждому менеджеру различных прав доступа для работы с базой клиентов
• Печать списка организаций на принтере и экспорт их в Microsoft Excel
• Протоколирование контактов с организацией
• Вход в базу данных каждого менеджера по личному паролю

Следует отметить простоту установки и обслуживания данной программы (программист не нужен), удобное интерфейсное решение и возможность расширения функционала. Полноценная структура «Клиент-Сервер» совершенно бесплатно!

Установите программу «Базу Клиентов 2.0» на своем компьютере и оцените ее богатые возможности – потратив 10 минут времени, вы навсегда откажитесь от сохранения данных о своих клиентах в Microsoft ® Excel.

Преимущества нашей программы перед аналогами

• Абсолютно бесплатная – вы можете абсолютно бесплатно пользоваться этой программой или копировать ее инсталляционный пакет на любом носителе информации кому угодно.

Очень удобно – база клиентов представляет собой один файл (файл customers.fdb) – который вы можете периодически сохранять на компакт-диске или на flash-носителе. В этом файле хранятся все данные о ваших клиентах.

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

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

Нет ограничений – в этой программы нет ограничений ни по количеству сетевых рабочих мест, ни по функционалу. Для работы программе не нужен Интернет. Мы гарантируем, что внутри программы нет скрытых функций и возможностей.

Распределение доступа – каждому менеджеру можно назначить права пользования базой клиентов – добавлять данные, редактировать их или удалять данные из базы. Менеджер может просматривать только свои организации или организации и других менеджеров. Менеджер может экспортировать список клиентов в Microsoft ® Excel и печатать его на принтере, или может быть лишен такой возможности.

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

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

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

Если Вы хотите иметь более широкий спектр возможностей для учета Ваших клиентов - тогда советуем посмотреть информацию о «Базе Клиентов 3.1» - недорогой и качественной CRM-системе.

Программа или человек, обращающийся к базе данных

Программа или человек, обращающийся к базе данных. Запрос

ТЕОРЕТИЧЕСКИЕ ОСНОВЫ ПРОЕКТИРОВАНИЯ УДАЛЕННЫХ БАЗ ДАННЫХ

АРХИТЕКТУРЫ УДАЛЕННЫХ БАЗ ДАННЫХ

1.1. Термины и определения

Системы управления удаленными <распределенными) базами дан­ных — это СУБД (СУРБД), обеспечивающие возможность одно­временного доступа к информации различным пользователям.

Рассмотрим термины, применяемые в системах управления распределенными базами данных.

Архитектура БД — организация взаимодействия аппаратных средств.

Виды архитектуры БД: клиент—сервер, двухуровневая и трех­уровневая клиент-сервер, файл —сервер.

Архитектура ODBC (Open DataBase Connectivity) — откры­тый интерфейс доступа к базам данных, т.е. взаимодействие про­цессора (ядра) базы данных Jet с внешними источниками дан­ных.

Модели данных — схемы, характеризующие базы данных с раз­ных сторон с целью определить оптимальное построение инфор­мационной системы.

Ядро базы данных — внутренняя структура СУБД, обеспечива­ющая доступ ко всем компонентам базы данных. В новых версиях СУБД Access называется Microsoft Data Engine (MSDE); в ранних версиях ядро базы данных называлось машина базы данных Microsoft Jet . Ядро базы данных обеспечивает поддержку символов различ­ных алфавитов, синтаксис языка SQL и другие средства обработ­ки различных типов данных.

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

Запрос — процесс обращения пользователя к БД с целью вве­сти, получить или изменить информацию.

Транзакция — последовательность операций модификации дан­ных в БД, переводящая ее из одного непротиворечивого состоя­ния в другое непротиворечивое состояние.

Логическая структура БД — определение БД на физически не­зависимом уровне, что ближе всего соответствует концептуаль­ной ее модели.

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

Локальная автономность — понятие, означающее, что инфор­мация локальной БД и связанные с ней определения данных при­надлежат локальному владельцу и им управляются.

Удаленный запрос — запрос к базам данных, находящихся на ресурсах локальной сети предприятия или сети Интернет.

Возможность реализации удаленной транзакции — обработка одной транзакции, состоящей из множества SQL-запросов, на одном удаленном узле.

Поддержка распределенной транзакции — обработка транзакции, состоящей из нескольких SQL-запросов, выполняемых на несколь­ких узлах сети (удаленных или локальных), но каждый из которых обрабатывается только на одном узле.

Распределенный запрос — запрос, при обработке которого ис­пользуются данные из БД, расположенные в разных узлах сети.

Системы распределенной обработки данных в основном связа­ны с первым поколением БД, которые строились на мультипрог­раммных операционных системах, хранились на устройствах внеш­ней памяти центральной ЭВМ и использовали терминальный многопользовательский режим доступа. При этом пользователь­ские терминалы не имели собственных ресурсов, т.е. процессоров и памяти, которые могли бы использоваться для хранения и об­работки данных. Первой полностью реляционной системой, рабо­тающей в многопользовательском режиме, была СУБД SYSTEM R фирмы IBM. Именно в ней были реализованы как язык манипу­лирования данными SQL, так и основные принципы синхрони­зации, применяемые при распределенной обработке данных, ко­торые до сих пор являются базисными практически во всех ком­мерческих СУБД.

1.2. Архитектуры клиент—сервер в технологии управления удаленными базами данных

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

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

функции ввода и отображения данных (Presentation Logic);

прикладные функции, определяющие основные алгоритмы решения задач приложения (Business Logic);

функции обработки данных внутри приложения (DataBase Logic);

функции управления информационными ресурсами (DataBase Manager System);

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

Структура типового приложения, работающего с базой дан­ных в архитектуре клиент—сервер, приведена рис. 1.1.

Презентационная логика (Presentation Logic) как часть прило­жения определяется тем, что пользователь видит на своем экра­не, что приложение работает. Сюда относятся все интерфейсные экранные формы, которые пользователь видит или заполняет в ходе работы приложения, а также все то, что выводится пользо­вателю на экран в качестве результатов решения некоторых про-

чтение и запись в экранные формы информации;

управление экраном;

обработка движений мыши и нажатие клавиш клавиатуры.

Бизнес-логика, или логика собственно приложений (Business

Processing Logic), — это часть кода приложения, которая опреде­ляет собственно алгоритмы решения конкретных его задач. Обыч­но этот код записывается с использованием различных языков программирования, таких как С, С++, Visual Basic и др.

Логика обработки данных (Data Manipulation Logic) — это часть кода приложения, которая непосредственно связана с обработ­кой данных внутри него. Далными управляет собственно СУБД, а для обеспечения доступа к ним используется язык SQL.

Процессор управления данными (DataBase Manager System Processing) — это собственно СУБД, которая обеспечивает хра­нение и управление базами данных. В идеале функции СУБД дол­жны быть скрыты от бизнес-логики приложения, однако при рас­смотрении архитектуры приложения мы выделим их в отдельную его часть.

Рис. 1.2. Распределение функций компонентов приложения в моделях

клиент—север

В централизованной архитектуре (Host-Based Processing) ука­занные части приложения располагаются в единой среде и ком­бинируются внутри одной исполняемой программы. В децентра­лизованной архитектуре эти части приложения могут быть по-раз­ному распределены между серверным и клиентским процессами.

удаленное представление (Remote Presentation);

распределенная бизнес-логика (Remote Business Logic);

удаленное управление данными (Remote Data Management);

распределенное управление данными (Distributed Data Management).

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

1.3. Двухуровневые модели

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

Модель удаленного управления данными, или модель файлового сервера ( File Server — FS ). В этой модели презентационная логика и бизнес-логика располагаются на клиентской части. На сервере располагаются файлы с данными и поддерживается доступ к этим файлам. Функции управления информационными ресурсами в этой модели находятся на клиентской части.

Распределение функций компонентов приложения в моделях клиент — сервер представлено на рис. 1.3.

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

Рис. 1.3. Модель файлового сервера

Д остоинство данной модели состоит в том, что приложение разделено на два взаимодействующих процесса. При этом сервер

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

Алгоритм выполнения клиентского запроса сводится к следу­ющему.

Запрос формулируется в командах языка манипулирования данными (ЯМД).

СУБД переводит этот запрос в последовательность файловых команд.

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

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

Рассмотренная модель имеет следующие недостатки:

высокий сетевой трафик, который связан с передачей по сети множества блоков и файлов, необходимых приложению;

узкий спектр операций манипулирования с данными, опре­деляемый только файловыми командами;

отсутствие адекватных средств безопасности доступа к дан­ным (защита только на уровне файловой системы).

Рис. 1.4. Структура модели удаленного доступа к данным

Модель удаленного доступа к данным ( Remote Data Access — RDA ). В этой модели база данных хранится на сервере. Там же находится и ядро СУБД. На компьютере клиента располагаются презентационная логика и бизнес-логика приложения. Клиент обращается к серверу с запросами на языке SQL. Структура моде­ли удаленного доступа к данным приведена на рис. 1.4.

Преимущества данной модели состоят в следующем:

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

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

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

Основным достоинством модели RDA является унификация интерфейса клиент—сервер, т.е. стандартным при общении при­ложения клиента и сервера становится язык SQL.

Недостатки данной модели:

запросы на языке SQL при интенсивной работе клиентской части приложения могут существенно загрузить сеть;

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

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

БД в каждый момент времени должна отражать текущее со­стояние предметной области, которое определяется не только соб­ственно данными, но и связями между объектами данных, т.е. данные, которые хранятся в БД, в каждый момент времени дол­жны быть непротиворечивыми.

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

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

Возникновение некоторой ситуации в БД должно четко и оперативно влиять на ход выполнения прикладной задачи.

Совершенствование контроля типов данных СУБД. В насто­ящее время СУБД контролирует синтаксически только стандарт- но-допустимые типы данных, т. е. которые определены в DDL (Data Definition Language) — языке описания данных, являющемся ча­стью SQL. Однако в реальных предметных областях существуют данные, которые несут в себе еще и семантическую составляющую, например координаты объектов или единицы измерений.

Модель сервера баз данных поддерживают большинство совре­менных СУБД: Informix, Ingres, Sybase, Oracle, MS SQL Server. Основу данной модели составляют: механизм хранимых процедур как средство программирования SQL-сервера, механизм тригге­ров как механизм отслеживания текущего состояния информаци­онного хранилища и механизм ограничений на пользовательские типы данных, который иногда называют механизмом поддержки доменной структуры.

Модель активного сервера базы данных представлена на рис. 1.5. В этой модели бизнес-логика разделена между клиентом и серве­ром. На сервере бизнес-логика реализована в виде хранимых про­цедур — специальных программных модулей, которые хранятся в БД и управляются непосредственно СУБД. Клиентское приложе­ние обращается к серверу с командой запуска хранимой процеду­ры, а сервер выполняет эту процедуру и регистрирует все предус-

Рис. 1.5. Модель активного сервера базы данных

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

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

Термин «триггер», взятый из электроники, семантически очень точно характеризует механизм отслеживания специаль­ных событий, связанных с состоянием БД. Триггер является как бы некоторым тумблером, который срабатывает при возникно­вении определенного события в БД. Ядро СУБД проводит мо­ниторинг всех событий, вызывающих созданные и описанные триггеры в БД, и при возникновении такого события сервер запускает соответствующий триггер. Каждый триггер представ­ляет собой также некоторую программу, которая выполняется с базой данных. С помощью триггеров можно вызывать храни­мые процедуры.

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

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

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

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

• осуществляет мониторинг событий, связанных с выполнени­ем разработанных триггеров;

обеспечивает автоматическое срабатывание триггеров при воз­никновении связанных с ними событий;

обеспечивает исполнение внутренней программы каждого триггера;

запускает хранимые процедуры по запросам пользователей;

запускает хранимые процедуры из триггеров;

возвращает требуемые данные клиенту;

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

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

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

Архитектура трехуровневой модели приведена на рис. 1.6. Про­межуточный уровень может содержать один или несколько серве­ров приложений.

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

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

Рис. 1.6. Модель сервера приложений

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

Серверы баз данных в этой модели занимаются исключительно функциями СУБД: обеспечивают функции создания и ведения БД, поддерживают целостность реляционной БД, обеспечивают функции хранилищ данных (warehouse services). Кроме того, на них возлагаются функции создания резервных копий БД и восста­новления БД после сбоев, управления выполнением транзакций и поддержки устаревших (унаследованных) приложений (legacy application).

Данная модель обладает большей гибкостью, чем двухуровне­вые модели. Наиболее заметны преимущества модели сервера приложений в тех случаях, когда выполняются сложные аналити­ческие расчеты в базе данных, относящихся к области OLAP-при- ложений (On-line analytical processing). В этой модели большая часть бизнес-логики клиента изолирована от возможностей встроенно­го языка SQL, реализованного в конкретной СУБД, и может быть выполнена на языках программирования С, С++, Sir.i. Talk, Cobol, что повышает переносимость системы и ее масштабируемость.

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

Рассмотрим эволюцию подобных механизмов. В основном та­кой механизм определяется структурой реализации серверных процессов и часто называется архитектурой сервера баз данных.

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

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

Рис. 1.7. Взаимодействие клиентских и серверных процессов в модели

«один к одному»

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

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

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

Рис. 1.8. Многопотоковая односерверная архитектура

дельной нитью (thread) или потоком, по которому пересылаются запросы. Такая архитектура, получившая название многопотоко­вой односерверной (multi-threaded), позволяет значительно умень­шить нагрузку на операционную систему, возникающую при ра­боте большого числа пользователей (trashing).

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

Однако такое решение имеет свои недостатки. Так как сервер может выполняться только на одном процессоре, возникает есте­ственное ограничение на применение СУБД для мультипроцес­сорных платформ. Если компьютер имеет, например, четыре про­цессора, то СУБД с одним сервером использует только один из них, не загружая другие три.

Контрольные вопросы

Дайте определения следующих терминов: архитектура ODBC, модели данных, транзакция, топология БД (или струк­тура распределенной БД), локальная автономность, удаленный запрос, распределенный запрос, поддержка распределенной транзакции, презентационная логика, биз­нес-логика, логика обработки данных, процессор управления данными.

Какие двухуровневые модели вы знаете? Назовите их достоинства и недостатки.