Смекни!
smekni.com

Организация базы данных провайдера (стр. 1 из 8)

Оглавление

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

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

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

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

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

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

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

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

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

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

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

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

4 Выбор СУБД.. 3

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

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

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

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

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

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

7 Заключение. 3

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

9 Приложения. 3

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

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

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», необходимо сначала удалить информацию из вторичных атрибутов, а затем уже удалять значение первичного ключа. Целостность объекта реализуется самой СУБД, и обычно пользователю нет необходимости об этом беспокоиться.