Оглавление

     1 Анализ предметной области 2

     1.1 Деловой регламент 2

     1.2 Функциональная структура 4

     1.3 Диаграмма потоков данных 4

     1.4 Выделение информационных объектов и их атрибутов 8

     2 Концептуальная модель 10

     3 Логическое моделирование 12

     3.1 Построение логической модели 12

     3.3 Целостность данных 13

     3.3.1 Целостность объекта 13

     3.3.2 Целостность приложения 14

     3.3.3 Ссылочная целостность 14

     4 Выбор СУБД 16

     5  Физическая модель 18

     5.1 Нормализация……………………………………………………..18

     6 Проектирование и реализация информационной системы 21

     6.1 Описание средств, использованных при реализации 21

     6.2 Тексты SQL-запросов и результаты их выполнения 21

     6.3 Клиентская часть 30

     7 Заключение 38

     8 Список литературы 39

     9 Приложения 40

     Приложение A Макетные данные 40

     Приложение B Код клиентской части 46 

1 Анализ предметной  области

1.1 Деловой регламент

     Заключается договор провайдера с пользователем.

     Интернет-провайдер, иногда просто Провайдер, (англ. Internet Service Provider, ISP, букв. "поставщик Интернет-услуги") — организация, предоставляющая услуги доступа к Интернету и иные связанные с Интернетом услуги.

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

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

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

     Тарифный  план это совокупность цен и предоставляемых  услуг.

     Есть  возможность выбрать следующие  тарифные планы:

     Без лимитный 256 - стоимость 350 руб. Ограничение скорости 256 кбит/сек

     Без лимитный 512 - стоимость 500 руб. Ограничение скорости 512 кбит/сек

     Без лимитный 768 - стоимость 600 руб. Ограничение скорости 768 кбит/сек

     Без лимитный 1000 - стоимость 700 руб. Ограничение скорости 1024 кбит/сек

     Без лимитный 2000 - стоимость 1200руб. Ограничение скорости 2048 кбит/сек

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

     Списание  денежных средств по договору происходит в конце месяца.

     Трафиком  считается объем переданной информации. Трафик делиться на:

     - Внешний (входящий, исходящий)

     - Локальный (входящий, исходящий)

     Локальным трафиком считается весь трафик проходящий в диапазоне IP адресов провайдера.

     Локальный трафик не ограничивается в скорости. А так же не тарифицируется (бесплатен).

     Внешним трафиком считается весь трафик кроме  локального.

     Тарифицируется  только входящий трафик. Исходящий  является бесплатным.

     Пополнение  баланса выполняется при помощи карт оплаты.

     Карта оплаты содержит  пароль и уникальный номер. Есть вариации карт оплаты:

     - На 100 руб.

     - На 200 руб.

     - На 500 руб.

     Для активации карты следует ввести номер и пароль карты на сайте  статистики.

     После активации карта становиться  не действительной.

     Номера и пароли всех карт хранятся на сервере провайдера.

1.2 Функциональная структура

     Кратко  функции БД изображены на функциональной структуре (рис.1.1)

     Как видно из рис.1.1 , БД «Провайдер» имеет возможности:

     -Заключение  договора

     - Просмотр клиентов

     - Пополнение баланса

     - Редактирование договора

     - Статистика оплат

     - Активность портов

     - Полезная информация

1.3 Диаграмма потоков данных

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

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

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

    Хранилище данных - это пассивный объект в  составе ДПД, в котором данные сохраняются для последующего доступа. Хранилище данных допускает доступ к хранимым в нем данным в порядке, отличном от того, в котором они  были туда помещены. Агрегатные хранилища  данных, как например, списки и таблицы, обеспечивают доступ к данным в порядке  их поступления, либо по ключам. Диаграмма ПД моего проекта представлена на (рис1.2).

     На  функциональной диаграмме листовыми  будут являться функции:

     -Заключение  договора

     - Просмотр клиентов

     - Пополнение баланса

     - Редактирование договора

     - Статистика оплат (Выводит данные  об оплатах, совершенных пользователем)

     - Активность портов (Выводит суммарный  объем информации принятый на  каждый порт)

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

Рисунок 1.1  Функциональная структура 
 

Рисунок 1.2 Диаграмма потоков данных

1.4 Выделение информационных объектов и их атрибутов

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

     1. Клиент

                 1.1Номер

                 1.2 Ф.И.О.

                 1.3 Паспорт

     1.4 Регистрация

     2. Договор

                 2.1 Номер

     2.2 Дата приёма на работу

     2.3 Контактный телефон

     2.4 Место нахождения

     3. Карта

                 3.1 Номер

                 3.2 Сумма

                 3.3 Пароль

                 3.4 Состояние

     4. История оплат

                 4.1 Дата, время

                 4.2 Номер карты

                 4.3 Сумма

     5. Дебит

                 5.1Сумма

                 5.2Дата время

     6. Услуга

           6.1 Шифр

           6.2 Название

           6.3 Стоимость

           6.4 Описание

     7 IP

           7.1 С порта

           7.2 На порт

           7.3 С адреса

           7.4 На адрес

           7.5 С интерфейса

           7.6 На интерфейс

     7.7 Трафик

     7.8 Дата, время 

2 Концептуальная модель

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

     Теперь  построим предварительную концептуальную модель и покажем количественное значение мощностей связей Рисунке 2.1.

• Провайдер – Договор: У одного провайдера может быть много клиентов, А у каждого клиента может быть только один провайдер.
• Договор – Дебит: Под дебитом здесь понимается списание средств. И таким образом: по одному договору может быть несколько списаний средств. И одно списание средств может быть только у одного договора.
• Договор – Клиент: Клиент может заключить только один договор. И один договор оформляется только на одного клиента.(Но тем не менее в сущность договор идет внешним ключом id из таблицы “Клиент” )
• Услуга договор: Одна услуга может предоставляться по нескольким договорам, и один договор может иметь несколько услуг.
• Карта оплаты – Провайдер: Провайдер предоставляет множество карт оплат. И одна карта оплаты принадлежит только одному провайдеру.
• IP – договор: В сущности IP содержатся единичные записи о трафике проходящем от и до клиента. И тогда одна запись Ip принадлежит только одному договору. А у договора может быть много записей о трафике.

Рисунок 2.1 Предварительная концептуальная модель

3 Логическое моделирование

3.1 Построение логической модели

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

     Например, в сущность «Oplata» добавляются атрибуты «Useri» (Id клиента – первичный ключ сущности «Useri»). Таким же образом добавляются атрибуты и в другие сущности.

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

Рисунок 3.1 Логическая модель

3.3 Целостность данных

3.3.1 Целостность объекта

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

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

3.3.2 Целостность приложения

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

     В базе данных «Провайдер» это отношения  «Usluga» (хотя, возможность изменения этой  таблицы реализована в приложении).

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

3.3.3 Ссылочная целостность

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

     Ограничения ссылочной целостности предполагают:

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

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

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

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

     Например, в нашу базу данных в таблицу «Dogovor» нельзя занести информацию о новом клиенте без внесения данных об этом клиенте в таблицу «Useri», т.к. отношение «Useri» является родительским для отношения «Dogovor». А в таблицу «Ip» нельзя внести информацию о работнике, которого нет в отношении «Dogovor» (т.е. нельзя указать расходование трафика не указав причины(пользователя)).

     Такая же ситуация обстоит и с удалением  и обновлением картежей в отношениях.

     Например, нельзя удалить картеж из отношения  «Useri», так как у него имеется потомок – отношение «Dogovor», а если возникает необходимость удаления, то соответствующие картежи необходимо удалить и из всех дочерних отношений.

     Аналогичная связь прослеживается и в других отношениях.

4 Выбор СУБД

     Для реализации базы данных «Провайдер» я выбрал СУБД  Oracle 10g . Это объясняется следующими возможностями данной СУБД:

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

     - Real Application Cluster (RAC) обеспечивает работу одного экземпляра базы данных на нескольких узлах grid, позволяя управлять нагрузкой и гибко масштабировать систему в случае необходимости;

     - Automatic Storage Management (ASM) позволяет автоматически распределять данные между имеющимися ресурсами систем хранения данных, что повышает отказоустойчивость системы и снижает общую стоимость владения (TCO);

     - Производительность. Oracle Database 10g позволяет автоматически управлять уровнями сервиса и тиражировать эталонные конфигурации в рамках всей сети;

     - Простые средства разработки. Новый инструмент разработки приложений HTML DB позволяет простым пользователям создавать эффективные приложения для работы с базами данных в короткие сроки;

     - Самоуправление. Специальные механизмы Oracle Database 10g позволяют самостоятельно перераспределять нагрузку на систему, оптимизировать и корректировать SQL-запросы, выявлять и прогнозировать ошибки;

     - Большие базы данных. Максимальный размер экземпляра базы данных Oracle может достигать 8 экзабайт;

     - Недорогие серверные системы. Oracle Database 10g может использовать недорогие однопроцессорные компьютеры или модульные системы из "серверов-лезвий";

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

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

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

5  Физическая модель

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

Таблица 5.1 Типы данных

Для создания таблиц мы использовали следующие скрипты:

-- Create table

create table USLUGI

(

  shifr    INTEGER not null,

  name1    VARCHAR2(250),

  stoimost FLOAT,

  type_us  VARCHAR2(250)

);

-- Create/Recreate primary, unique and foreign key constraints

alter table USLUGI

  add primary key (SHIFR);

-- Create table

create table USLUGA_DOGOVOR

(

  shifr INTEGER not null,

  nomer CHAR(7) not null

)

-- Create/Recreate primary, unique and foreign key constraints

alter table USLUGA_DOGOVOR

  add foreign key (SHIFR)

  references USLUGI (SHIFR);

alter table USLUGA_DOGOVOR

  add foreign key (NOMER)