Файл: Образец диплома.doc

Нажатие на кнопку Сохранить приведет к сохранению параметров сообщения в базе данных. Нажатие на кнопку Отправить запустит процесс отправки. Этот процесс отображается в строке загрузки. На рисунке 18 представлена форма сообщения в процессе отправки. В нижнем правом углу рисунка можно видеть, что адресат получает сообщение на указанную почту.

Рис.18 Форма сообщения в процессе отправки

Форма просмотра сообщений

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

Рис.19 Форма просмотра сообщений

Отчеты

Главным отчетом в разработанном приложении является «Карточка абитуриента», направленная на расширение возможностей актуализации. «Карточка абитуриента» показана на рисунке 20. Этот отчет выдается на руки возможному абитуриенту в печатном виде. Абитуриент будет знать какую информацию о себе он оставил в вузе и что с ним обязательно смогут связаться если возникнет такая необходимость. Если его контактные данные изменяться, а карточка абитуриента ему всегда напомнит, какая информация о нем известна Университету, в его интересах будет сообщить о произошедших изменениях. Также на карточке абитуриента отражен его IDв университетской базе данных, которое он может использовать, чтобы сообщить о повторном посещении Университета.IDизображен в виде штрих кода для дальнейшей автоматизации учебного процесса.

Рис.20 «Карточка абитуриента»

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

«Общий» отчет на рисунке 21 дает сводную информацию по всем мероприятиям и зарегистрированным на них абитуриентам. На отчете показана дата его формирования.

«Ваш» отчет на рисунке 22 похож на «Общий» отчет, но формируется только на пользователя авторизованного в системе.

Рис.21 «Общий» отчет

Рис.22 «Ваш» отчет

Отчеты в виде диаграмм дают наглядную статистику по количеству необходимых мест в общежитии – «Общежитие», рисунок 23, по количеству студентов из разных учебных заведений – «Откуда к нам идут», рисунок 24, показывают, кто из сотрудников ЦПК сколько будущих абитуриентов зарегистрировал – «Рейтинг среди сотрудников», рисунок 25.

Рис.23 «Общежитие»

Рис.24 «Откуда к нам идут»

Рис.25 «Рейтинг среди сотрудников»

7.1. Интерфейс – «Галочки»

Для корректной работы Галочек на формах регистрации и создания сообщения в базе данных были реализованы представления. Представление (англ.View) — виртуальная (логическая) таблица, представляющая собой поименованный запрос (алиас к запросу), который будет подставлен как подзапрос при использовании представления. Типичным способом создания представлений дляСУБД, поддерживающих язык запросовSQL, является связывание представления с определённым SQL-запросом. Соответственно, содержимое представления — это результат выполнения этого запроса, а возможности построения представления ограничиваются только степенью сложности диалекта SQL, поддерживаемого конкретной СУБД.

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

Использование представлений не даёт каких-то совершенно новых возможностей в работе с БД, но может быть очень удобно:

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

Первое представление ONE_VIEWотвечает за наличие связки между абитуриентом и выбранными им для поступления факультетами:

CREATE VIEW ONE_VIEW(

ID,

NAME,

CB,

FST_PD_ID)

SELECT

s.id,

s.NAME,

case when pr.id is null then 0 else 1 end as cb,

per.id as pers_id

FROM STU_KL_FACULTY s

left join fst_pers_data per on (1=1)

left join fst_fprof pr on (pr.facult_id = s.id and

pr.fst_pd_id = per.id);

За проставление галочки в данном представлении отвечает параметр CB. По запросу проверяется если в таблице-связке абитуриента с факультетом отсутствует связка, от галочка не ставится, иначе галочка ставится. За создание связки между абитуриентом и факультетами при изменении состояния галочки на форме отвечает триггер базы данныхONE_VIEW_BU0:

begin

if (old.cb != new.cb) then

if (new.cb = 1) then

INSERT INTO FST_FPROF(FST_PD_ID, FACULT_ID)

VALUES (old.fst_pd_id, old.id);

else

DELETE FROM FST_FPROF

WHERE (new.fst_pd_id = fst_fprof.fst_pd_id and

new.id = fst_fprof.facult_id);

end

Данный триггер проверяет, если старое значение параметра (значение галочки) не равно новому, то выполнить следующие действия:

если новое значение равно единице, то создать связь между абитуриентом и факультетом;
иначе удалить связь.

Второе представление TWO_VIEWотвечает за наличие связки между абитуриентом и выбранными им для поступления специальностями:

CREATE VIEW TWO_VIEW(

ID,

NAME,

CB,

PERS_ID)

SELECT

s.id,

s.NAME,

case when pr.id is null then 0 else 1 end as cb,

per.id as pers_id

FROM stu_kl_specialization s

left join fst_pers_data per on (1=1)

left join fst_fprof pr on (pr.spec_id = s.id and

pr.fst_pd_id = per.id);

За проставление галочки в данном представлении отвечает параметр CB. По запросу проверяется, если в таблице-связке абитуриента со специальностью отсутствует связка, то галочка не ставится, иначе галочка ставится. За создание связки между абитуриентом и специальностью при изменении состояния галочки на форме отвечает триггер базы данныхTWO_VIEW_BU0:

begin

if (new.cb != old.cb) then

if (new.cb = 1) then

INSERT INTO FST_FPROF(SPEC_ID, FST_PD_ID)

VALUES (old.id, old.pers_id);

else

DELETE FROM FST_FPROF

WHERE (old.id = fst_fprof.spec_id and old.pers_id =

fst_fprof.fst_pd_id);

end

если новое значение равно единице, то создать связь между абитуриентом и специальностью;
иначе удалить связь.

Третье представление MES_VIEWотвечает за наличие связки между абитуриентом и отправленным ему сообщением:

CREATE VIEW MES_VIEW(

ID,

THEME,

CB,

PERS_ID)

SELECT

m.id,

m.theme,

case when pr.pers_data_id is null then 0 else 1 end

as cb,

per.id as pers_id

FROM FST_MESSAGE m

left join fst_pers_data per on (1=1)

left join fst_l_persdata_message pr on (pr.message_id =

m.id and pr.pers_data_id = per.id);

За проставление галочки в данном представлении отвечает параметр CB. По запросу проверяется, если в таблице-связке абитуриента с отправленным ему сообщением отсутствует связка, то галочка не ставится, иначе галочка ставится. За создание связки между абитуриентом и сообщением при изменении состояния галочки на форме отвечает триггер базы данныхMES:

begin

if (old.cb != new.cb) then

if (new.cb = 1) then

INSERT INTO FST_L_PERSDATA_MESSAGE(PERS_DATA_ID,

MESSAGE_ID)

VALUES (old.PERS_ID, old.ID);

else

DELETE FROM FST_L_PERSDATA_MESSAGE

WHERE(new.PERS_ID =

fst_l_persdata_message.pers_data_id) AND (new.ID

= FST_L_PERSDATA_MESSAGE.message_id);

end