="justify">     У данной модели есть следующие связи:

• Провайдер – Договор: У одного провайдера может быть много клиентов, А у каждого клиента может быть только один провайдер.
• Договор – Дебит: Под дебитом здесь понимается списание средств. И таким образом: по одному договору может быть несколько списаний средств. И одно списание средств может быть только у одного договора.
• Договор – Клиент: Клиент может заключить только один договор. И один договор оформляется только на одного клиента.(Но тем не менее в сущность договор идет внешним ключом 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)