Ограничения целостности приложения определяют отношения, в которые пользователь может вносить изменения, связанные с удалением, обновлением и вставкой. Ведь в базе данных существуют и такие отношения, в которые изменения вноситься не должны (по крайней мере, пользователем) – эти отношения формируются один раз при создании базы данных и далее в течение долгого времени данные в них не меняются. Эти отношения называются «справочниками» (точнее, некоторые из них).
В базе данных «Провайдер» это отношения «Usluga» (хотя, возможность изменения этой таблицы реализована в приложении).
Ограничения ссылочной целостности формируются при проектировании приложения (клиентской части) к базе данных.
Ссылочная целостность отражает взаимосвязь между значениями атрибутов, входящих в разные таблицы – родительские и дочерние
Ограничения ссылочной целостности предполагают:
1) Задание пары ключей родительского и внешнего ключей;
2) Родительский и внешний ключи могут быть простыми, либо составными. Для простых ключей должно совпадать количество атрибутов, входящих в родительский и внешний ключи, а также попарно типы и размеры данных.
Требования к родительскому ключу – уникальность, либо неопределённость, поэтому в качестве родительского ключа выбирается либо первичный ключ, либо потенциальный ключ.
Значения внешнего ключа должны совпадать с одним из значений родительского ключа, либо должны быть неопределёнными. Значения внешнего ключа могут повторяться в различных картежах дочерней таблицы (конечно, если это поле не является первичным ключом для этой таблицы).
Таким образом, значения ссылочной целостности защищают базу данных от ошибок, связанных с вставкой, удалением и обновлением данных.
Например, в нашу базу данных в таблицу «Dogovor» нельзя занести информацию о новом клиенте без внесения данных об этом клиенте в таблицу «Useri», т.к. отношение «Useri» является родительским для отношения «Dogovor». А в таблицу «Ip» нельзя внести информацию о работнике, которого нет в отношении «Dogovor» (т.е. нельзя указать расходование трафика не указав причины(пользователя)).
Такая же ситуация обстоит и с удалением и обновлением картежей в отношениях.
Например, нельзя удалить картеж из отношения «Useri», так как у него имеется потомок – отношение «Dogovor», а если возникает необходимость удаления, то соответствующие картежи необходимо удалить и из всех дочерних отношений.
Аналогичная связь прослеживается и в других отношениях.
Для реализации базы данных «Провайдер» я выбрал СУБД 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 как наиболее подходящую для реализации нашей базы данных по предоставляемым возможностям.
Физическая модель данных представлена реляционными таблицами, в которых в виде кортежей реляционных отношений хранится информация. Для хранения информации выбраны Oracle 10g таблицы, как удобные в работе и распространенные. Таблицы Oracle 10g поддерживают многие приложения, что обеспечивает более высокую универсальность системы.
Таблица 5.1 Типы данных
| Тип | Наименование типа | Размер (байты) | Содержание |
| Текстовый | Varchar | каждый символ по 1 | Буквы, цифры, спец. символы(%, &, #) |
| Числовой | Integer | 4 | Планируется выполнять арифме тические операции над значениями из этого поля |
| Денежный | Integer | 8 | Числовое поле, содержимое которого изображается с дробной частью и денежным символом |
| Дата | Date | 8 | Даты до 31 декабря 9999 года. |
Для создания таблиц мы использовали следующие скрипты:
-- Create table
createtable USLUGI
(
shifr INTEGERnotnull,
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
createtable USLUGA_DOGOVOR
(
shifr INTEGERnotnull,
nomer CHAR(7) notnull
)
-- Create/Recreate primary, unique and foreign key constraints
altertable USLUGA_DOGOVOR
addforeignkey (SHIFR)
references USLUGI (SHIFR);
altertable USLUGA_DOGOVOR
addforeignkey (NOMER)
references DOGOVOR (NOMER);
-- Create table
createtable USERI
(
idNUMBERnotnull,
pasport NUMBERnotnull,
fio VARCHAR2(250),
registration VARCHAR2(250),
telephone VARCHAR2(250)
)
-- Create/Recreate primary, unique and foreign key constraints
altertable USERI
addunique (ID);
-- Create table
createtable PROVAIDER
(
inn NUMBERnotnull,
nameorg VARCHAR2(250),
adress VARCHAR2(250),
director VARCHAR2(250),
telephone NUMBER
)
-- Create/Recreate primary, unique and foreign key constraints
altertable PROVAIDER
addprimarykey (INN)
-- Create table
createtable OPLATA
(
id_karti NUMBERnotnull,
data_vremya DATE,
summa FLOAT,
id_d CHAR(7)
)
-- Create/Recreate primary, unique and foreign key constraints
altertable OPLATA
addforeignkey (ID_D)
references DOGOVOR (NOMER);
altertable OPLATA
addforeignkey (ID_KARTI)
references KARTA (NOMER)
disable;
-- Create table
createtable KARTA
(
nomer NUMBERnotnull,
summa FLOAT,
sostoyanie INTEGER,
password_k VARCHAR2(250),
inn NUMBER
)
-- Create/Recreate primary, unique and foreign key constraints
altertable KARTA
addforeignkey (INN)
references PROVAIDER (INN);
-- Create table
createtable IP
(
time1 TIMESTAMP(6),
with_adress VARCHAR2(250),
with_port NUMBER,
on_adress VARCHAR2(250),
on_port VARCHAR2(250),
bait NUMBER,
with_interfase NUMBER,
on_interfase INTEGER,
nomer CHAR(7)
)
-- Create/Recreate primary, unique and foreign key constraints
altertable IP
addforeignkey (NOMER)
references DOGOVOR (NOMER);
-- Create table
createtable DOGOVOR
(
nomer CHAR(7) notnull,
date2 DATE,
date3 DATE,
inn NUMBER,
id_u NUMBER,
money FLOAT,
pass VARCHAR2(250),
status NUMBER
)
-- Create/Recreate primary, unique and foreign key constraints
altertable DOGOVOR
addprimarykey (NOMER)
altertable DOGOVOR
addforeignkey (INN)
references PROVAIDER (INN);
altertable DOGOVOR
addforeignkey (ID_U)
references USERI (ID);
-- Create table
createtable DEBIT
(
time1 DATE,
money FLOAT,
why VARCHAR2(255),
id_d CHAR(7)
)
-- Create/Recreate primary, unique and foreign key constraints
altertable DEBIT
addforeignkey (ID_D)
referencesDOGOVOR (NOMER);
Для создания базы данных, сначала создаются таблицы с помощью средств, предлагаемых СУБД Oracle 10g :
- Создание таблицы помощью графического инструментального средства конфигурирования Oracle Database Configuration Assistant (DBCA);
- Создание таблицы шаблонов баз данных (database templates),;
- Создание таблицы путём ввода данных.
При создании таблиц был использован 1-й вариант, как наиболее удобный из всех предлагаемых. Сначала создаётся каркас таблицы, отмечаются ключевые поля, устанавливаются типы данных для каждого поля, а уже потом таблицы заполняются макетными данными (приведены в приложении A).
После того, как таблицы созданы, необходимо их связать по ключевым полям.
Уже на данном этапе можно сформулировать достаточно большое количество запросов, которые понадобятся в дальнейшем при создании форменного приложения.
При создании запросов в СУБД Oracle 10g был использован режим SQL . Это объясняется удобством и простотой языка SQL, который представляет достаточно богатый набор средств для формирования запросов.
Ниже приведены все SQL-запросы, использованные в процессе создания информационной системы.
| NOMER | DATE2 | DATE3 | INN | ID_U | MONEY | PASS | STATUS |
| npi013 | 17.12.2010 | 17.12.2011 | 7,77778E+11 | 13 | 0 | 5656 | 1 |
2. Какие предоставляются тарифы? Вывести, упорядочив по шифру.