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

§ Выше производительность информационной системы.

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

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

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

Рисунок 3 «Схема построения информационной системы».

4.2. Выбор модели данных.

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

§ достоинства для пользователя:

o реляционная БД представляет собой набор таблиц, с которыми пользователь привык работать;

o не нужно помнить пути доступа к данным и строить алгоритмы и процедуры обработки своего запроса;

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

§ достоинства обработки данных реляционной БД:

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

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

o Гибкость. Операции проекции и объединения позволяют разрезать и склеивать отношения, так что программист может получать разнообразные файлы в нужной форме;

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

o Простота Внедрения. Физическое размещение однородных (табличных) файлов намного проще, чем размещение иерархических и сетевых структур.

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

4.3. Выбор СУБД и средства разработки базы данных.

В качестве системы управления базами данных (СУБД) для реализации поставленной задачи остановимся на процессоре данных MSDE (Microsoft Data Engine), входящем в состав Microsoft Office 2000. В качестве средства разработки базы данных делаем выбор в пользу Access 2000 также входящего в Microsoft Office 2000. Почему именно такой выбор?

§ Microsoft Office 2000 установлен на каждом компьютере компании Вэб Плас.

§ Решения, созданные в Access легко интегрируются в другие приложения Microsoft Office 2000: MS Word, MS Excel и другие. Подготовленный в проекте Access отчет легко может быть перенесен в другие приложения Office.

§ Решения на базе Access + MSDE легко переносятся под управление MS SQL Server. Это означает, что приложение созданное в Access для использования с MSDE имеет высокий уровень масштабируемости.

4.3.1. Новый формат проектов Access.

По умолчанию Access хранит все объекты данных и интерфейса в одном общем файле MDB. В Access 2000 появилась мощная технология построения приложений – проекты Access (Access Data Project, ADP). В ней используется файл нового формата (ADP), который заменил базу данных Jet в части хранения объектов приложения (форм, отчетов макросов и модулей). Хранение и обработка данных возложены на SQL Server, к которому приложение подключается непосредственно через OLE DB (см. описание ниже).

4.3.2. ODBC и OLE DB

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

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

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

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

Рисунок 4. «Сравнение ODBC и OLE DB»

Технология OLE DB[2] пришла на смену ODBC, с тем, чтобы устранить ее недостатки. OLE DB основана не на API, а на COM[3] Это облегчает разработку не только конечных приложений, но и функциональных эквивалентов драйверов ODBC – средств доступа к данным OLE DB, называемых также провайдерами OLE DB. Ведь теперь в их роли могут выступать любые COM -компоненты.

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

Однако и OLE DB считается довольно сложной технологией. Чтобы упростить выполнение самых стандартных действий, Microsoft разработала библиотеку объектов доступа к данным ActiveX Data Object (ADO) и включила ее в OLE DB в качестве интегрированного компонента.

Именно технологии OLE DB и ADO будут использоваться в разработанном приложении для доступа к данным.

4.4. Проектирование.

4.4.1. Определение сущностей

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

§ Sales – таблица, содержащая информацию о сотрудниках отдела продаж.

§ Services – таблица, содержащая информацию о сервисах компании.

§ Deals – таблица, содержащая информацию о сделках, совершаемых сотрудниками отдела продаж

§ ExtraTrafic – таблица, содержащая информацию о превышении трафика по сделкам

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

4.4.2. Определение взаимосвязей между сущностями