Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Минобрнауки России

Федеральное государственное образовательное учреждение высшего профессионального образования

Государственный университет - учебно-научно-производственный комплекс

Учебно-научно-исследовательский институт информационных технологий

Специальность 230201 «Информационные системы и технологии»

Кафедра «Информационные системы»

КУРСОВАЯ РАБОТА

по дисциплине «Управление данными»

на тему:

Проектирование и реализация базы данных для обслуживания абонентов оператора сотовой связи

Студент группы 21-ИТ

Пыхонин А.К.

Руководитель Олькина Е.В.

Орел 2012

Содержание

Введение

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

2. Модель процессов предметной области

3. Концептуальное проектирование

4. Построение запросов к базе данных

5. Безопасность и целостность данных

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

5.2 Безопасность данных

Заключение

Список используемой литературы

Приложение А (обязательное) Структура базы данных

Приложение Б (обязательное) Триггеры к базе данных

Введение

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

База Данных (БД) - структурированный организованный набор данных, описывающих характеристики каких-либо физических или виртуальных систем. (Поименованная совокупность структурированных данных предметной области). Работа с базами данных осуществляется при помощи СУБД.

Система управления базами данных (СУБД) - специализированная программа (чаще комплекс программ), предназначенная для организации и ведения базы данных. Для создания и управления информационной системой СУБД необходима в той же степени, как для разработки программы на алгоритмическом языке необходим транслятор.

Цель данной курсовой работы - проектирование и создание базы данных для автоматизирования работы оператора сотовой связи.

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

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

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

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

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

Информация об абонентах содержит следующие данные: ФИО абонента, адрес, и его номера счетов.

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

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

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

2. Модель процессов предметной области

Модель процессов предметной области реализована при помощи системы BРwin. Основное назначение данной модели состоит в представлении информации для обоснования выбора модели и структуры данных, используемых в созданной информационной системе.

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

Методология IDEF0 предписывает построение иерархической системы диаграмм. На верхнем уровне произведем описание системы в целом и её взаимодействие с окружающим миром. На рисунке 1 изображена контекстная диаграмма, отображающая основной процесс.

Рисунок 1 - Контекстная диаграмма

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

Более детальное описание процессов предметной области приведено на рисунке 2 - декомпозиционной диаграмме «Обслуживание абонентов оператора сотовой связи».

Рисунок 2 - Декомпозиционная диаграмма «Обслуживание абонентов оператора сотовой связи»

На данной диаграмме представлены следующие процессы: «Регистрация счёта», «Отказ в использовании услуг», «Обслуживание номера», «Отказ от услуг».

Входными данными для блока «Регистрация счёта» будут информация о абоненте, информация о неплатильщиках. Выходными данными из этого блока будут Sim-карта, которая будет являться управлением для блоков «Отказ в использовании услуг», «Обслуживание номера», изменённая информация о счетах и изменённый список абонентов.

Входными данными для блока «Отказ в использовании услуг» будут информация о абоненте, информация о неплатильщиках и информация о счетах. Выходными данными из этого блока будут список заблокированных, изменённая информация о счетах.

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

Входными данными для блока «Отказ от услуг» будут список абонентов, информация о счетах. Выходными данными из этого блока будут Sim изменённая информация о счетах и изменённый список абонентов.

Для блоков «Регистрация счёта» и «Отказ от услуг» потоками управления будут являться «Документы абонента».

Для блоков «Отказ в использовании услуг» и «Обслуживание номера» потоками управления будут являться «Sim-карта».

Механизмы «работник компании» и «абонент» используется для обеспечения работы «Регистрация счёта» и «Отказ от услуг», а механизм «система обслуживания счетов» для работы процессов «Отказ в использовании услуг» и «Обслуживание номера».

Следующий уровень декомпозиции, представленный на рисунках 3-6, содержит в себе более подробное рассмотрение всех вышеуказанных процессов.

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

Рисунок 3 - Декомпозиционная диаграмма «Регистрация счёта»



Рисунок 4 - Декомпозиционная диаграмма «Отказ в использовании услуг»

Рисунок 5 - Декомпозиционная диаграмма «Обслуживание номера»

Рисунок 6 - Декомпозиционная диаграмма «отказ от услуг»

Далее произведём количественный анализ IDEF0 диаграммы. Количество блоков на диаграммах нижних уровней должно быть ниже количества блоков на родительских диаграммах, т.е. с увеличением уровня декомпозиции коэффициент N/L должен убывать. Итак, проверим выполнение этого условия.

Декомпозиционная диаграмма «Обслуживание абонентов оператора сотовой связи»:

N = 4, L = 1; N/L = 4,

где N - количество блоков на диаграмме;

L - уровень декомпозиции диаграммы.

Декомпозиционная диаграмма «Регистрация счёта»:

N = 3, L = 2; N/L = 1.5.

Декомпозиционная диаграмма «Отказ в использовании услуг»:

N = 3, L = 2; N/L = 1.5.

Декомпозиционная диаграмма «Обслуживание номера»:

N = 3, L = 2; N/L = 1.5.

Декомпозиционная диаграмма «отказ от услуг»:

N = 3, L = 2; N/L = 1.5.

Итак, N/L₁ > N/L₂, условие выполняется. Убывание данного коэффициента говорит о том, что по мере декомпозиции модели функции упрощаются.

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

, (1)

где A_i - количество стрелок, соединяющихся с i-м блоком;

N - количество блоков на диаграмме;

L - уровень декомпозиции диаграммы.

Для декомпозиционной диаграммы «Обслуживание абонентов оператора сотовой связи»:

N = 4, A₁ = 8, A₂ = 7, A₃ = 4, A₄= 7, K_b = 1.5.

Декомпозиционная диаграмма «Регистрация счёта»:

N = 3, A₁ = 5, A₂ = 5, A₃ = 5, K_b= 0.

Декомпозиционная диаграмма «Отказ в использовании услуг»:

N = 3, A₁ = 5, A₂ = 5, A₃ = 5, K_b = 0.

Декомпозиционная диаграмма «Обслуживание номера»:

N = 3, A₁ = 4, A₂ = 4, A₃ = 5, K_b = 0.66.

Декомпозиционная диаграмма «отказ от услуг»:

N = 3, A₁ = 5, A₂ = 4, A₃ = 7, K_b = 1.66.

Как видно из расчётов, коэффициент сбалансированности убывает с увеличением уровня декомпозиции. На нижнем уровне декомпозиции коэффициент сбалансированности равен 0, следовательно, функции упрощаются до тривиальных, и модель не содержит узкие места.



3. Концептуальное проектирование

Данный этап проектирования служит для разработки концептуальной модели, которая описывает структуру данных при помощи средств ERwin. Для построения базы данных была выбрана реляционная модель данных.

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

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

Рисунок 7 - Логический уровень концептуальной схемы



Рисунок 8 - Физический уровень концептуальной схемы

Далее рассмотрим подробно каждую из сущностей.

Сущность «Polzovatel» - пользователи, абоненты сотовой связи, содержит поля:

- «Nomer_pasporta» - номер паспорта абонемента;

- «FIO» - ФИО абонента;

- «Adres» - адрес пользователя.

Сущность «Info_Schet» - информация о счетах абонента, включающая информацию о договорах заключенных с пользователями сотовой связи:

- «Nomer_dogovora» - номер заключенного договора;

- «Nomer_pasporta» - номер паспорта абонета;

- «Data_podpisaniya_dogovora» - дата подписания договора;

- «Status» - статус пользователя (пользователь может использовать

услуги сотовой связи, либо временно или навсегда быть отключенным);

- «Data_otkluchenia» - дата отключения, либо временного, либо безвозвратно (может не иметь значения);

- «Nomer_telefona» - номер телефона, который обслуживается по

этому договору;

- «Balans_scheta» - текущее количество средств на счету абонента.

Сущность «Prihod» содержит поля:

- «Nomer_platega» - номер платежа;

- «Nomer_dogovora» - номер пользовательского договора;

- «Data_platega» - дата пополнения счёта;

- «Summa» - количество средств, внесённых при данном платеже.

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

Каждая сущность в данной концептуальной схеме имеет свои первичные ключи. Для сущности «Пользователь» первичным является ключ «Номер_паспорта», который уникально определяет каждого абонента сотовой связи. Для сущности «Информация о счете» первичный ключ - «Номер договора». Сущность «Приход» (приход средств) имеет первичный ключ: «Номер платежа».

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

- полям «Nomer_pasporta», «Nomer_dogovora», «Nomer_telefona», «Balans_scheta», «Nomer_platega», «Summa» был присвоен тип INTEGER, так как все они содержат целочисленные значения.

- полям «FIO», «Adres», «Status» был присвоен тип VARCHAR, однако в зависимости от необходимой длины определенного поля размер VARCHAR варьировался от 10 до 100.

- полю «Data_platega», «Data_podpisania_dogovora», «Data_otkluchenia» был присвоен тип DATE, с помощью которого описываются любые необходимые даты.

4. Построение запросов к базе данных

Сгенерированный скрипт базы данных на языке SQL представлен в приложении А - Структура базы данных. Ниже приводится пояснение команд из скрипта базы.

Команда CREATE TABLE Polzovatel создает таблицу «Пользователь» с атрибутами «Номер_паспорта», «ФИО», «Адрес». Ключевой атрибут - «Номер_паспорта», который добавляется командой ALTER TABLE Polzovatel ADD (PRIMARY KEY (Nomer_pasporta)).

Команда CREATE TABLE Info_Schet создает таблицу «Информация о счете» с атрибутами «Номер договора», «Номер паспорта» (неидентифицирующий мигрирующий ключ из таблицы «Пользователь», который создается командой ALTER TABLE Info_Schet ADD (FOREIGN KEY (Nomer_pasporta) REFERENCES Polzovatel)), «Дата подписания договора», «Статус», «Дата отключения», «Номер телефона», «Баланс счета». Ключевой атрибут - «Номер договора», который создается командой ALTER TABLE Info_Schet ADD (PRIMARY KEY(Nomer_dogovora)).

Команда CREATE TABLE Prihod создает таблицу «Приход» с атрибутами «Номер_договора» (неидентифицирующий мигрирующий ключ из таблицы «Информация о счете», который создается командой ALTER TABLE Prihod ADD (FOREIGN KEY (Nomer_dogovora) REFERENCES Info_schet)), «Номер платежа», «Дата_платежа» и «Сумма». Ключевой атрибут - «Номер_платежа», создаваемый командой ALTER TABLE Prihod ADD (PRIMARY KEY (Nomer_platega)).

На рисунках 9, 10, 11 представлена полученная база данных, заполненная реальными данными.

Рисунок 9 - Таблица «Пользователь»

Рисунок 10 - Таблица «Информация о счете»

Рисунок 11 - Таблица «Приход»

Ниже приведены запросы, демонстрирующие работоспособность базы данных:

а) Удалить из базы платежи на сумму менее 50 рублей (результат работы запроса показан на рисунке 12).

delete from prihod where summa < 50;

Рисунок 12



б) Изменить баланс пользователя с номером паспорта 131 223 на 200, так как ему были возвращены 50 рублей после ошибки в системе (результат работы запроса представлен на рисунке 13)

update info_schet set balans_scheta = 200 where nomer_pasporta = 131 223;

Рисунок 13

в) Вывести номер телефона и статус пользователя с данным договором, если баланс меньше 0 рублей (результат работы запроса показан на рисунке 14).

р _{nomer_telefona, status, balans_scheta} (у _{balans_scheta < 0} (info_schet));

{t (nomer_telefona, status, balans_scheta) | x (info_schet (x) /\

(x(balans_scheta) < 0)) /\ t = (x (nomer_telefona, status, balans_scheta))};

Рисунок 14

г) Выбрать всю информацию о платежах и сортировать по дате оплаты (результат работы запроса отображен на рисунке 15).

ф _{data_platega} (р _{nomer_dogovora, nomer_platega, data_platega, summa} (prihod));

{t|t(prihod)};

Рисунок 15

д) Вывести ФИО и текущий баланс пользователей, если в базе данных хранится информация больше чем об одном платеже (результат работы запроса отображен на рисунке 16).

р distinct (_{FIO, balans_scheta} (у 1 < (р _{count (nomer_dogovora)} (prihod))(info_schet

prihodpolzovatel)));

{t (FIO, balans_scheta) |xyz (polzovatel (x) /\ prihod (y) /\

info_scheta (z) /\ (y (nomer_dogovora) = z (nomer_dogovora)) /\

(x(nomer_pasporta) = z (nomer_pasporta)) /\ (1 < count (y

(nomer_dogovora)))) /\ (t = distinct (x (FIO) /\ z (balans_scheta))))};

Рисунок 16

база данный сотовый связь



5. Целостность и безопасность данных

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

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

Следует различать понятия «безопасность» и «целостность» баз дынных. Под безопасностью понимают то, что пользователю разрешают выполнить какие-либо действия. А под целостность же понимают то, что эти самые разрешённые действия будут выполнены корректно.

В реляционной модели данных определены два базовых требования обеспечения целостности:

- целостность ссылок;

- целостность сущностей.

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

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

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

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

- RESTRICT - запрещающая;

- CASCADE - каскадная;

- SET NULL - задание значения NULL.

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

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

SET NULL - при удалении родителя устанавливает значения ссылочных полей потомка в Null. При этом данная стратегия не применима для идентифицирующих связей, связей не допускающих null значений и категорий.

Стратегии для каждой связи представлены на рисунке 17.

Между сущностями «Пользователь» - «Информация о счете» предусмотрены следующие стратегии целостности: для «Пользователя» и «Информации о счете» вставка данных не вызовет никакой реакции БД (пользователь может быть записан в базу, даже если был расторгнут договор и договор может храниться без отчетов о расходах), для модификации и удаления данных предусмотрена стратегия restrict, из-за того, что изменять номер пользователя и договора не нужно, а удалять пользователя, имеющего договор или отчет о расходе, не логично.

Рисунок 17 - Стратегии целостности

В связи «Информация о счете» - «Приход» для сущности «Информация о счете» соответственно определены стратегии cascade для добавления (так как при заключении договора на счет обязательно должны поступить деньги) и restrict на модификацию и удаление данных, из-за того, что изменять номер не нужно, а удалять пользователя, имеющего платежи, не логично. Для сущности-потомка «Приход» соответственно определены стратегии restrict для вставки и модификации данных. Это значит, что мы не сможем вставить новые данные, для которых нет соответствия ссылочного поля в потомках со ссылочным полем в родителях. Аналогично для изменения данных. Удаление, как и в предыдущей связи, не приведет к какой-либо исключительной ситуации, так как можно отменить платеж по какой - либо причине.

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

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

Создадим представление, которое включает в себя ФИО абонента и текущий баланс:

create view inform (FIO, Balans_Scheta) as

select FIO, balans_scheta, nazvanie from polzovatel P, info_schet I

where ((P.nomer_pasporta = I.nomer_pasporta));

Созданное представление показано на рисунке 18.

Рисунок 18 - Представление «Inform»

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



create procedure plata (data1 date, data2 date)

returns (familia varchar(30), plategka integer)

as begin

for select p.fio, pr.summa

from polzovatel p, info_schet i, prihod pr

where ((p.nomer_pasporta = i.nomer_pasporta) and (i.nomer_dogovora =

pr.nomer_dogovora) and (data_platega between :data1 and :data2))

into :familia, :plategka

do suspend;

end;

Для демонстрации ее работы выведены ФИО и суммы платежей для периода оплаты с 01.01.2011 по 01.04.2011. Результаты вызова процедуры показаны на рисунке 19.

select * from plata ('01.01.2011', '01.04.2011');

Рисунок 19 - Работа хранимой процедуры «Plata»

Триггер - специальный вид хранимой процедуры, используемый в реляционных БД. Триггер не может вызываться непосредственно пользователем, он привязывается к какой-либо базовой таблице и выполняется автоматически СУБД при вставке, удалении или модификации записей в таблице.

Коды триггеров и исключения, реализующих стратегии ограничения целостности базы данных приведены в приложении Б - Триггеры к базе данных.

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

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

5.2 Безопасность данных

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

Для добавления нового пользователя в БД можно использовать программу IBExpert (так как в InterBase не всегда получается зайти под именем нового созданного пользователя). Нужно щелкнуть мышью по элементу меню Tools и в списке выбрать User Manager. Появится окно User Manager и список учетных записей, представленный на рисунке 20.

Рисунок 20 - Окно просмотра и изменения списка пользователей

Щелкнув по кнопке Add в появившемся окне New User, представленном на рисунке 21, нужно ввести имя пользователя и дважды ввести пароль в поля Password и в Confirm Password.

Рисунок 21 - Добавление в список нового пользователя

Был добавлен пользователь с логином User11 и паролем 1234. Он не имеет никаких прав, т.к. в Interbase действует правило - что не разрешено, то запрещено. Чтобы предоставить пользователю права на добавление кортежей в таблицу «Пользователь» нужно использовать конструкцию:

grant insert on Polzovatel to User11.

Теперь данный пользователь сможет добавлять кортежи в таблицу «Пользователь», но при попытке совершить иные действия, произойдет ошибка.



Заключение

Цель данной курсовой была достигнута - была разработана база данных для обслуживания абонентов оператора сотовой связи. Предварительно было выполнено проектирование данной БД в терминах ER-моделирования. Моделирование выполнялось на основании исходных данных предприятия. Использование запросов показало полную работоспособность БД.

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

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

Список используемой литературы

1. Кузнецов С.Д. Основы баз данных [Текст]: Курс лекций. Учебное пособие / С.Д. Кузнецов - 1-е изд. - М.: «Интернет-университет информационных технологий - ИНТУИТ.ру», 2005. - 484 с.: ил.; 16 см - 2000 экз. - ISBN 978-5-94774-736-2.

2. Марков А.С., Лисовский К.Ю. Базы данных. Введение в теорию и методологию: Учебник. [Текст] / А.С. Марков, К.Ю. Лисовский - М.: Финансы и статистика, 2006. - 512 с.: ил.; 24 см - 3000 экз. - ISBN 5-279-02298-5.

3. Хернандес Майкл Дж., Вьескас Джон Л. SQL - запросы для простых смертных [Текст]: практическое руководство по манипулированию данными в SQL / Майкл Дж. Хернандес, Джон Л. Вьескас - М.: Наука, 2003. - 480 с.: ил.; 24 см - 2500 экз. - ISBN: 5-85582-178-1.

4. Википедия [Электронный ресурс]. - Электрон. текстовые граф. данные и прикладная прогр. (546 Мб). - М.: Свободная электронная энциклопедия. - Режим доступа: http://ru.wikipedia.org. - Систем. требования: ПК 486 или выше; 8 Мб ОЗУ; Windows 3.1 или Windows 95; SVGA 32768 и более цв.; 640х480; 16-бит. зв. карта; мышь. - Загл. с экрана.

Приложение А (обязательное)

Структура базы данных

База данных на языке SQL:

CREATE TABLE Polzovatel (

Nomer_pasporta INTEGER NOT NULL,

FIO VARCHAR(30) NOT NULL,

Adres VARCHAR(50) NOT NULL);

ALTER TABLE Polzovatel ADD PRIMARY KEY (Nomer_pasporta);

CREATE TABLE Info_Schet (

Nomer_dogovora INTEGER NOT NULL,

Nomer_pasporta INTEGER NOT NULL,

Data_podpisaniya_dogovora DATE NOT NULL,

Status VARCHAR(20) NOT NULL,

Data_otkluchenia DATE NOT NULL,

Nomer_telefona INTEGER NOT NULL,

Balans_scheta INTEGER NOT NULL);

ALTER TABLE Info_schet ADD PRIMARY KEY (Nomer_dogovora);

CREATE TABLE Prihod (

Nomer_platega INTEGER NOT NULL,

Nomer_dogovora INTEGER NOT NULL,

Data_platega DATE NOT NULL,

Summa INTEGER NOT NULL);

ALTER TABLE Prihod ADD PRIMARY KEY (Nomer_platega);

ALTER TABLE Info_Schet ADD FOREIGN KEY (Nomer_pasporta)

REFERENCES Polzovatel;



Приложение Б (обязательное)

Триггеры к базе данных

create exception except_in 'Извините, вы не можете добавить информацию';

create exception except_up 'Извините, вы не можете изменить данную информацию';

create trigger tI_Schet for Info_schet after insert as

declare variable numrows INTEGER;

begin select count(*) from Prihod

where new.Nomer_dogovora = Prihod.Nomer_dogovora into numrows;

if (numrows = 0) then exception except_in;

end;

create trigger PlusBalans for Prihod after insert as begin

update info_schet set balans_scheta = balans_scheta + new.summa

where info_schet.nomer_dogovora = new.nomer_dogovora;

end;

Размещено на Allbest.ru