Файл: Курсовая ИС фитнес-клуба.doc

ВУЗ: Не указан

Категория: Курсовая работа

Дисциплина: Проектирование информационных систем

Добавлен: 21.10.2018

Просмотров: 1542

Скачиваний: 25

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

д) Целостность транзакций. Транзакцией называется единый логический блок работы, например вставка 100 строк, обновление 1000 строк или выполнение логической цепочки обновлений. Качество продукта базы данных зависит от того, насколько его возможности выполнения транзакций соответствуют принципам атомарности, целостности и изолированности. Большая часть архитектуры SQL Server основана именно на этих свойствах.

  • Свойство атомарности подразумевает, что транзакция должна либо выполниться вся, либо не выполниться в целом. В конце транзакции она должна быть либо подтверждена, либо отменена. Если частично выполненная транзакция записывается на диск, то свойство атомарности нарушается.

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

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

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

Архитектура SQL Server поддерживает все свойства целостности транзакций. Это значит, что разработчику нужно понимать их, чтобы при создании баз данных взять на вооружение все возможности SQL Server, а администратору баз данных это поможет реализовать хороший план восстановления. Если объединить возможности SQL Server, аппаратного и программного обеспечения, модели базы данных, планов восстановления и обслуживания базы данных. Когда разработчик и администратор сотрудничают, чтобы правильно организовать эти компоненты, база данных работает отлично, а целостность транзакций высокая.

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


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

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

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


    1. Разработка структуры входных и выходных данных


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

Разрабатываемая модель находится в 3-й нормальной форме, так как:

  1. атрибуты сущностей являются атомарными;

  2. каждый не ключевой атрибут функционально полно зависит от первичного ключа;

  3. в модели отсутствуют транзитивные зависимости не ключевых атрибутов от ключа.

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

Данная база данных состоит из трех таблиц-справочников:

  1. вид услуг (таблица 2.1);

  2. тип абонентской платы (таблица 2.2);

  3. клиент (таблица 2.3).


В таблице «Вид услуг» содержатся наименование услуг предоставляемых фитнес-центром.

Таблица 2.1 «Вид услуг»

ПОЛЕ

ТИП

ID

Integer

Название

Varchar(20)

Описание

Varchar(20)


В таблице «Тип абонентской платы» находится наименования видов оплаты на определенный срок.

Таблица 2.2 «Тип абонентской платы»

ПОЛЕ

ТИП

ID

Integer

Название

Varchar(20)

Количество дней

Integer


В таблице «Клиент» находится все необходимая информация о клиенте.


Таблица 2.3 «Клиент»

ПОЛЕ

ТИП

ID

Integer

FIO

Varchar(20)

Дата рождения

DATA

Номер паспорта

Varchar(20)


Главная таблица 2.4 содержит информацию об всех клиентах оплативших абонемент и также у кого имеется задолжность.


Таблица 2.4 «Оплата»

ПОЛЕ

ТИП

ID

Integer

ID_KLIENT

Integer

DATA_OPLAT

DATA

ID_ANOTENT

Integer

ID_USLUGA

Integer


    1. Вывод

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


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


3 Технологический раздел

3.1 Программный интерфейс программы


При запуске программы откроется главное окно программы представленное на рисунке 3.1.


Рисунок 3.1 - Главная форма программы


Для внесения нового клиента в базу данных, необходимо в пункте меню нажать на "Добавить клиента", после чего откроется вторая форма (рисунок 3.2) в которую необходимо ввести необходимые данные. После ввода данных нажать на кнопку "Добавить".

Рисунок 3.2 - Форма добавления нового клиента


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


Рисунок 3.3 - Виды услуг


Рисунок 3.4 - Абонентская плата


После того как было произведено внесения нового клиента в базу необходимо произвести оплату (рисунок 3.5). В пункте меню выбираем соответствующею вкладку. Откроется новое окно в которое вводим требуемые данные и нажимаем кнопку "Оплатить".

Рисунок 3.5 - Форма оплаты

3.2 Программная реализация БД


При добавлении новой записи создается запрос который вносит данные в две таблицы для дальнейшей работы формирования отчетности по заливным категориям. Код представлен в листинге 3.1.

Листинг 3.1 – Процедура добавления записи в хранилища

begin


insert into cube_data

( tipoper, numoper, date_, time_, id_klient )

select 1, t1.id, t1.date_, t1.time_, t1.id

from prihod_t2 t2

left join prihod_t1 t1 on t2.id1 = t1.id

where t2.id1 = :id ;

suspend;

end


При внесении нового клиента в БД вызывается запрос описанный в листинге 3.2.


Листинг 3.2 – Процедура списания товара

begin


insert into cube_data

(tipoper, numoper, date_, time_, id_klient)

select 2, t1.id, t1.date_, t1.time_

where t2.id1 = :id ;

suspend;

end




Листинг 3.3 – Тригер таблицы Оплата

begin

/*//////////////////////////////////////

//////////// Inserting ////////////

//////////////////////////////////////*/

if (inserting) then

begin

insert into cube_jrn

( TIPOPER, NUMOPER, DATE_, TIME_)

values

( 1, new.id, new.date_, new.time_);

end

/*//////////////////////////////////////

//////////// Updating /////////////

//////////////////////////////////////*/

if (updating) then

begin

delete from cube_jrn

where tipoper = 1 and NUMOPER = old.id ;


insert into cube_jrn

( TIPOPER, NUMOPER, DATE_, TIME_ )

values

( 1, new.id, new.date_, new.time_);


delete from cube_data

where tipoper = 1 and NUMOPER = old.id ;


delete from tovar_ostatki

where tipoper = 1 and NUMOPER = old.id ;


execute procedure proc_prihod(new.id);

end

/*//////////////////////////////////////

//////////// Deleting /////////////

//////////////////////////////////////*/

if (deleting) then

begin

delete from cube_jrn

where tipoper = 1 and NUMOPER = old.id ;

delete from cube_data

where tipoper = 1 and numoper = old.id ;

delete from tovar_ostatki

where tipoper = 1 and NUMOPER = old.id ;

end

end


3.3 Вывод


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



Заключение


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

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

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