Проектирование CRM-системы ОАО «Орбита-Сервис»

• Введение
• 1. Автоматизация рабочего места менеджера салона по ремонту мобильных телефонов
• 1.1 Задачи систем управления взаимодействием с клиентами
• 1.2 Проблемы и перспективы CRM-систем
• 1.3 Необходимость использования CRM-систем
• 1.4 Эффективность внедрения CRM-систем
• 1.5 Этапы разработки информационных систем
• 1.6 СУБД как способ реализации ИС
• 1.6.1 Общие принципы проектирования баз данных
• 1.6.2 Иерархические структуры данных
• 1.6.3 Сетевые структуры данных
• 1.6.4 Реляционная модель
• 1.6.5 Технология клиент-сервер
• 1.7 Цель, назначение и задачи информационной подсистемы
• 1.8 Организационная структура ОАО «Орбита-Сервис»
• 2 Проектирование информационной подсистемы
• 2.1 Основы технологий создания ПО
• 2.1.1 Визуальное моделирование
• 2.1.2 Методы структурного анализа и проектирования ПО
• 2.2 Методы анализа и проектирования ПО
• 2.3 Функциональное моделирование информационной подсистемы
• 2.4 Разработка диаграммы потоков данных для информационной системы
• 2.5 Инфологическая модель предметной области
• 2.6 Даталогическое проектирование базы данных
• 2.7 Разработка математической модели обслуживания заявок автоматизированной подсистемы на основе систем массового обслуживания
• 2.8 Модульная структура подсистемы автоматизации рабочего места менеджера салона по ремонту мобильных телефонов
• 2.9 Описание алгоритма работы программного модуля
• 3 Реализация
• 3.1 Выбор программного средства разработки
• 3.1.1 Borland Delphi
• 3.1.2 MS SQL Server
• 3.2 Описание прикладной программы
• 3.2.1 Назначение программы
• 3.2.2 Системные и программные требования
• 3.2.3 Описание интерфейса и возможностей программы
• 3.2.4 Резервное копирование
• 3.3.5 Пути усовершенствования программной разработки
• 4 Организационно — экономическая часть
• 4.1 Экономическое и социальное обоснование разработки программного продукта
• 4.1.1 Выявление спроса
• 4.1.2 Выбор базового варианта
• 4.1.3 Расчет затрат на разработку ПС и договорной цены
• 4.2 Расчет экономических показателей целесообразности и оценка эффективности предлагаемой разработки
• 4.2.1 Расчет капитальных вложений по сравниваемым вариантам
• 4.2.2 Расчет экономии капитальных вложений на пользователя программы, где используется сравниваемый вариант
• 4.2.3 Расчет эксплуатационных издержек у пользователя
• 4.2.4 Расчет годовой экономии стоимости машинного времени у потребителя программы
• 4.2.5 Расчет относительной экономии капвложений
• 4.2.6 Расчет относительной экономии эксплуатационных издержек потребления
• 4.2.7 Расчет годового экономического эффекта использования ПП
• 4.2.8 Расчет годового экономического потенциала разработки
• 4.2.9 Расчет цены потребления
• 4.3 Оценка конкурентоспособности ПП
• 4.3.1 Расчётный коэффициент экономической эффективности
• 4.4 Организация сервисного обслуживания
• 4.4.1 Смета затрат на выполнение сервисного обслуживания
• 5 Безопасность и экологичность
• 5.1 Опасные и вредные производственные факторы на рабочем местеоператора ЭВМ
• 5.2 Вредные факторы и их воздействие на оператора ЭВМ
• 5.2.1 Воздействие шума на оператора ЭВМ
• 5.2.2 Микроклимат
• 5.2.3 Освещение организаций, разрабатывающих ПП
• 5.2.4 Расчет естественного освещения
• 5.2.5 Защита от электромагнитных полей
• 5.3 Пожарная безопасность
• 5.3.1 Средства первичного пожаротушения и план эвакуации из рабочего помещения
• 5.4 Электробезопасность
• 5.5 Экологическая оценка
• Заключение
• Список использованных источников
• Приложения

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

Система управления взаимодействием с клиентами, или как ее часто называют CRM-система, предназначена для выполнения следующих задач:

­ рациональное использование ресурсов;

­ улучшение обслуживания клиентов;

­ учет бизнес-процедур;

­ эффективная отчетность о результатах;

­ облегчение работы персонала.

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

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

Внедрение информационной подсистемы автоматизации рабочего места менеджера салона по ремонту мобильных телефонов позволит:

­ значительно сократить денежные и трудозатраты;

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

­ повысить качество обслуживания клиентов;

­ оптимизировать процесс учета клиентов и услуг предприятия;

­ сократить время, потраченное на распределение объема работ;

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

­ отслеживать статистику выполненной и текущей работы;

­ облегчить труд инженеров по ремонту оборудования.

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

информационная система база менеджер

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

1.1 Задачи систем управления взаимодействием с клиентами

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

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

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

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

Существуют несколько типов классификации CRM-систем.

Классификация по функциональным возможностям:

Управление продажами (SFA — Sales Force Automation)

Управление маркетингом

Управление сервисом и Call-центры (системы по обработке жалоб от абонентов, фиксация и дальнейшая работа с обращениями клиентов)

Классификация по уровням обработки информации.

Оперативный — регистрация и оперативный доступ к первичной информации по событиям, компаниям, проектам, контактам, документам и т. д.

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

Коллаборационный (англ. collaboration — сотрудничество; совместные, согласованные действия) — уровень организации тесного взаимодействия с конечными потребителями, клиентами, вплоть до влияния клиента на внутренние процессы компании (опросы, для изменения качеств продукта или порядка обслуживания, web-страницы для отслеживания клиентами состояния заказа, уведомление по SMS о проведённых транзакциях по банковскому счету, возможность для клиента самостоятельно скомплектовать и заказать в online, к примеру, автомобиль или компьютер из доступных блоков и опций и др.)

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

В последние годы в мире получили широкое распространение CRM-системы On-demand (или SaaS), снимающие ограничения для использования территориально-распределенными компаниями.

1.2 Проблемы и перспективы CRM-систем

Интернет обладает несравненными возможностями грамотно и подробно рекламировать системы и фиксировать информацию о клиентах, создавая персонализированные базы данных об индивидуальных предпочтениях и требованиях каждого клиента. Интернет воплощает в жизнь концепцию маркетинга «один на один». Но с другой стороны, Интернет увеличивает нагрузку на CRM-архитектуры. Данные перемещения по веб-узлам весьма объемны, и интерпретировать их очень сложно. Создание профилей клиентов на основе этих данных скорее можно назвать искусством, нежели наукой. С другой стороны, обеспечить персонализацию веба для сотен и тысяч посетителей одновременно сегодня не могут даже самые технологически оснащенные компании, разве что какие-то зачатки ее. Более того, интеграция с Интернетом для компании весьма сложна; согласование данных перемещения с данными по продажам и взаимодействиям, получаемыми из традиционных каналов, сегодня практически не осуществляется.

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

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

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

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

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

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

1.3 Необходимость использования CRM-систем

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

Но, если с «бухгалтерией» все, более-менее понятно, то кратко рассмотрим, что может дать интеграция управленческого ПО.

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

В-третьих, действия конкурентов. Мониторинг действий конкурентов, «защита» своих клиентов от их воздействия — это тоже часть CRM-технологии.

И при всем при этом, конечно, желательна интеграция с учетной системой, чтобы не было дублирования ввода данных, чтобы все «накладные-счета-платежки» попадали в CRM-программу автоматически.

Внедрение CRM-программы в которой есть только функции ведения клиентской базы и планирования контактов, мало чем отличается от использования MSOutlookExpress или просто таблицы Excel. Кроме того, это нивелирует саму идею CRM, как средства управления продажами. К сожалению, разработчики CRM-систем в низшем ценовом диапазоне, иногда забывают о принципах построения корпоративной информационной системы (КИС), которые едины и для крупной корпорации и для небольшого бизнеса.

Таким образом, для большинства предприятий МСБ вполне достаточно интегрировать три основных модуля: Учет, Аналитика, CRM.

1.4 Эффективность внедрения CRM-систем

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

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

Для расчета эффективности внедрения IT-решений обычно используются показатели возврата инвестиций (ROI) и расчет совокупной стоимости владения (TCO), а также анализ выгодности затрат (CBA).

Основной показатель расчета эффективности внедрения — TCO, подобно о котором рассказала выше. Несовершенство использования показателя TCO заключается только в том, что он позволяет оценить всего лишь расходы на внедрение и использование CRM-системы, расчет только ТСО не даст целостного понимания о целесообразности применения системы: чем больше пользователей работают в единой системе и чем сложнее процессы, тем выше будет совокупная стоимость владения. Тем не менее, и польза от инсталляции подобной системы будет намного выше. В связи с этим при расчете эффективности необходимо учитывать не только затраты, но и выгоды от внедрения CRM-системы, которые определяются с помощью показателя возврата инвестиций. Данный коэффициент позволяет оценить рентабельность вложений в приобретение и внедрение CRM-системы.

Выгоды от внедрения CRM-системы.

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

повышение точности и адекватности планирования;

повышение оперативности подготовки отчетных данных (например, с 5 до 1 дня);

улучшение взаимоотношений с клиентами, например, повышение лояльности клиентов;

увеличение объема продаж, например, на 5−10 или более %;

сокращение времени исполнения заказов, например, срока формирования предложений и подбора услуги/продукта клиенту;

снижение производственных и операционных затрат, на 5−10 или более %;

уменьшение складских запасов, на 5−10 или более %;

сокращение времени на разработку и вывод новой продукции на рынок и т. д.

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

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

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

1.5 Этапы разработки информационных систем

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

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

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

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

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

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

На этапе программирования разрабатываются автономно тестируемые программы по спецификациям, подготовленным во время системного проектирования.

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

Ввод в эксплуатацию. Этот этап предусматривает перенос новой ИС из тестовой в рабочую среду.

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

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

На этом этапе определяются:

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

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

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

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

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

1.6 СУБД как способ реализации ИС

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

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

1.6.1 Общие принципы проектирования баз данных

Разработка базы данных — поэтапный процесс, в котором можно выделить 6 стадий. Экспертам предприятия приходится участвовать в этом процессе почти на всех его стадиях. Процесс разработки базы данных показан на рисунке 1.

Рисунок 1 — Процесс разработки базы данных

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

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

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

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

­ собираться и храниться должны только полезные и относящиеся к делу данные;

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

­ в базе данных не должно быть ошибок и неточностей;

­ хранимые данные должны быть доступны для всех легальных пользователей в нужное им время;

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

­ затраты на содержание базы данных не должны превышать выгод от ее использования;

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

­ возможные изменения в жизни организации не должны приводить к полной замене базы данных;

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

На этапе логического проектирования завершается разработка внешних схем базы данных. Требования различных пользователей и прикладных программ переводятся на язык концептуальной схемы, используя REA модель и E-R диаграммы. Часто на этом этапе выделяются подсистемы будущей базы данных, отвечающие за различные информационные нужды. Например, подсистемы продаж, закупок, кадров, производства и т. д. Это делается для удобства разработки и эксплуатации. Кроме того, на этом этапе определяются первичные и вторичные ключи, разрабатывается справочник данных.

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

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

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

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

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

­ переносимость;

­ масштабируемость;

­ простота администрирования;

­ минимальные требования к аппаратной части;

­ низкая стоимость ПО или возможность получить его бесплатно.

Кроме перечисленных условий, сервер центра сервисной поддержки должен:

­ соответствовать архитектуре — «клиент-сервер» ;

­ иметь документно-ориентированный способ хранения информации;

­ иметь мультиплатформенность для увеличения гибкости развертывания системы и удешевления внедрения;

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

­ иметь надежную и проверенную временем систему безопасности.

При этом ключевым фактором остается вид базы данных.

На сегодняшний день существуют 2 принципиально разных вида баз данных: реляционный и постреляционный (объектно-ориентированный).

К первому относится подавляющее большинство промышленных БД: MS SQL Server, Oracle, InterBase и т. д. Ко второй группе можно отнести Lotus Notes/Domino и СУБД Cache.

СУБД характеризуются различными логическими моделями, на которых они основаны.

Модель данных — это абстрактное представление о содержимом базы данных.

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

­ позволяют представить систему с точки зрения данных;

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

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

­ выполняют ориентированное на данные секционирование всей системы.

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

Все наиболее распространенные методологии структурного подхода базируются на ряде общих принципов. Базовыми принципами являются:

­ принцип «разделяй и властвуй» — принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения;

­ принцип иерархического упорядочения;

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

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

­ принцип абстрагирования — выделение существенных аспектов системы и отвлечение от несущественных;

­ принцип формализации — необходимость строгого методического подхода к решению проблемы;

­ принцип непротиворечивости — обоснованность и согласованность элементов;

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

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

­ DFD (Data Flow Diagrams) — диаграммы потоков данных;

­ SADT (Structured Analysis and Design Technique) — модели и соответствующие функциональные диаграммы;

­ ERD (Entity-Relationship Diagrams) — диаграммы «сущность-связь» .

Диаграммы потоков данных и диаграммы «сущность-связь» — наиболее часто используемые в CASE-средствах виды моделей.

На стадии проектирования ИС модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм.

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

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

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

­ внешние сущности;

­ системы/подсистемы;

­ процессы;

­ накопители данных;

­ потоки данных.

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

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

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

Эти ограничения следующие:

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

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

Это ограничение называют правилом ссылочной целостности.

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

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

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

­ позволяют представить систему с точки зрения данных;

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

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

­ выполняют ориентированное на данные секционирование всей системы.

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

Все наиболее распространенные методологии структурного подхода базируются на ряде общих принципов. Базовыми принципами являются:

­ принцип «разделяй и властвуй» — принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения;

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

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

­ принцип абстрагирования — выделение существенных аспектов системы и отвлечение от несущественных;

­ принцип формализации — необходимость строгого методического подхода к решению проблемы;

­ принцип непротиворечивости — обоснованность и согласованность элементов;

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

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

­ DFD (Data Flow Diagrams) — диаграммы потоков данных;

­ SADT (Structured Analysis and Design Technique) — модели и соответствующие функциональные диаграммы;

­ ERD (Entity-Relationship Diagrams) — диаграммы «сущность-связь» .

Диаграммы потоков данных и диаграммы «сущность-связь» — наиболее часто используемые в CASE-средствах виды моделей.

На стадии проектирования ИС модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм.

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

1.6.2 Иерархические структуры данных

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

1.6.3 Сетевые структуры данных

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

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

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

1.6.4 Реляционная модель

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

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

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

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

1.6.5 Технология клиент-сервер

Создание модели вычислений «клиент-сервер», знаменует собой следующий этап в развитии СУБД. Характерной особенностью архитектуры «клиент-сервер» является перенос вычислительной нагрузки на сервер БД и максимальная разгрузка от нее приложения клиента. Вычисления «клиент-сервер» имеют преимущества модели сетевых вычислений, с доступом к совместно используемым данным, и высокие характеристики производительности, присущие модели вычислений с хостмашиной. Система вычислений «клиент-сервер» состоит из трех различных компонентов, каждый из которых выполняет конкретную работу: сервер базы данных, клиентское приложение и сеть.

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

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

­ управление доступом к БД;

­ защита информации в БД с помощью средств архивации/восстановления и создания резервных копий;

­ централизованное задание для всех клиентских приложений правил глобальной целостности данных.

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

Клиентские приложения в СУБД «клиент-сервер» выполняют следующие задачи:

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

­ управление логикой приложения;

­ выполнение логики приложения;

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

­ запрос и получение информации от сервера базы данных.

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

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

Развитие идей архитектуры «клиент-сервер» привело к появлению многозвенной архитектуры доступа к базам данных. Архитектура «клиент-сервер» является двухзвенной. Одним звеном является приложение клиента, другим — сервер БД и сама БД. В трехзвенной архитектуре наборы данных (группы записей из одной или нескольких таблиц БД), бывшие ранее собственностью клиентских приложений, выделяются в отдельное звено, называемое сервером приложений. На сервере приложений расположены реальные наборы данных. Он разделяется между несколькими клиентами и формирует запросы к удаленной базе данных, то есть к серверу. В клиентском приложении размещается локальная копия данных с сервера приложений. Все изменения, вносимые пользователем, записываются в локальную копию. При обновлении набора данных клиентское приложение посылает серверу приложений только измененные записи. Сервер приложений, в свою очередь, отсылает эти изменения к серверу, который вносит их в БД.

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