Учебная работа. Курсовая работа: Создание информационной системы Учебные планы Вычитка часов

Учебная работа. Курсовая работа: Создание информационной системы Учебные планы Вычитка часов

Оглавление. 1

Введение. 2

анализ предметной области. 3

Выбор средств реализации. 15

Постановка задачки. 17

Реализация проекта. 19

Перечень применяемой литературы.. 30

Введение

Целью данной курсовой работы является создание информационной системы «Учебные планы. Вычитка часов». Проектируемая информационная система состоит из 3-х составляющих: базы данных, системы управления базой данных и пользовательского приложения. Информационная система соответствует архитектуре клиент-сервер.

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

Анализ предметной области

Основная цель АРМ состоит в том, чтоб предложить юзеру абстрактное идентификации 3-х уровней абстракции, т.е. 3-х разных уровней описания частей данных: наружного, концептуального и внутреннего. Цель трехуровневой архитектуры заключается в отделении пользовательского представления данных от их физического представления. Ниже причислены предпосылки, по которым лучше делать такое разделение:

· любой юзер обязан иметь возможность обращаться к одним и этим же данным, используя свое собственное юзер обязан иметь возможность
изменять свое админ базы данных обязан иметь возможность поменять структуру хранения данных в базе, не оказывая воздействия на пользовательские представления;

· внутренняя структура базы данных не обязана зависеть от физических качеств хранения инфы.

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

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

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

Базы реляционной модели данных были в первый раз изложены в статье Е. Кодда в 1970 г. Эта работа послужила стимулом для огромного количества статей и книжек, в каких реляционная модель получила предстоящее развитие. Более всераспространенная трактовка реляционной модели данных принадлежит К. Дейту [5]. Согласно Дейту, реляционная модель состоит из 3-х частей:

• Структурной части.

• Целостной части.

• Манипуляционной части.

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

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

Манипуляционная часть обрисовывает два эквивалентных метода манипулирования реляционными данными – реляционную алгебру и реляционное исчисление.

В традиционной реляционной модели употребляются лишь обыкновенные (атомарные) типы данных. Обыкновенные типы данных не владеют внутренней структурой.

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

Отношение состоит из 2-ух частей – заголовка дела и тела дела. Заголовок дела – это аналог заголовка таблицы. Заголовок дела состоит из атрибутов. количество атрибутов именуется степенью дела. Тело дела – это аналог тела таблицы. Тело дела состоит из кортежей. Кортеж дела является аналогом строчки таблицы. количество кортежей дела именуется мощностью дела.

Отношение владеет последующими качествами:

• В отношении нет схожих кортежей.

• Кортежи не упорядочены.

• Атрибуты не упорядочены.

• Все значения атрибутов атомарны.

Реляционной базой данных именуется набор отношений.

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

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

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

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

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

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

Наружный ключ дела – это набор атрибутов дела, содержащий ссылки на возможный ключ другого (либо такого же самого) дела. Отношение, содержащее возможный ключ, на который ссылается некий наружный ключ, именуется родительским отношением. Отношение, содержащее наружный ключ, именуется дочерним отношением.

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

Связи типа «много-ко-многим» реализуются внедрением нескольких отношений типа «один-ко-многим».

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

· Целостность сущностей.

· Целостность наружных ключей.

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

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

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

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

RESTRICT (ОГРАНИЧИТЬ) – не разрешать выполнение операции, приводящей к нарушению ссылочной целостности.

CASCADE (КАСКАДИРОВАТЬ) – разрешить выполнение требуемой операции, но внести каскадные конфигурации в остальные дела так, чтоб не допустить нарушения ссылочной целостности.

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

SET NULL (УСТАНОВИТЬ В NULL) – все неправильные значения наружных ключей изменять на null-значения.

SET DEFAULT (УСТАНОВИТЬ ПО УМОЛЧАНИЮ) – все неправильные значения наружных ключей изменять на некое

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

IGNORE (ИГНОРИРОВАТЬ) – делать операции, не обращая внимания на нарушения ссылочной целостности.

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

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

Поначалу (Кодд, 1970) были предложены 1-ые три обычных формы: 1НФ, 2НФ, 3НФ. Потом было сформулированное наиболее серьезное определение третьей обычной формы, которое получило заглавие обычная форма Бойса-Кодда. Потом возникли 4НФ и 5НФ, на практике применяемые очень изредка.

На практике процесс разработки БД сводится к достижению 3НФ. При достаточном опыте проектировщика БД нормализация происходит интуитивно. Или ее можно употреблять в качестве тестов, т.е. повергнуть уже разработанную БД проверке: удовлетворяет ли она требованиям нормализации.

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

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

Нормализация может применяться к таблице, которая представляет собой правильное отношение.

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

В реляционной модели отношение постоянно находится в 1 (либо наиболее высочайшей) обычной форме в том смысле, что другие дела не рассматриваются в реляционной модели. Другими словами само определение понятия отношение заранее предполагает наличие 1NF.

Таблица находится во 2-ой обычной форме
, если она находится в первой обычной форме, и при всем этом хоть какой её атрибут, не входящий в состав первичного ключа, функционально много зависит от первичного ключа. Функционально полная зависимость значит, что атрибут функционально зависит от всего первичного составного ключа, но при всем этом не находится в многофункциональной зависимости от какой-нибудь из входящих в него атрибутов(частей). Либо иными словами: в 2NF нет неключевых атрибутов, зависящих от части составного ключа (+ производятся условия 1NF).

Таблица находится в третьей обычной форме
(3NF), если она находится во 2-ой обычной форме (2NF) и при всем этом хоть какой ее не-ключевой атрибут зависит лишь от первичного ключа (Primary key, PK) (по другому говоря, один факт хранится в одном месте).

Таковым образом, отношение находится в 3NF и тогда лишь тогда, когда оно находится во 2NF и отсутствуют транзитивные зависимости неключевых атрибутов от главных. Транзитивной зависимостью неключевых атрибутов от главных именуется последующая: A → B и B → C, где A – набор главных атрибутов (ключ), B и С – разные огромного количества неключевых атрибутов.

При решении практических задач почти всегда 3-я обычная форма является достаточной. процесс проектирования реляционной базы данных, как правило, завершается приведением к 3NF.

Инфологическая модель

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

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

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

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

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

· применяемых способов анализа предметной области;

· правил именования и обозначения объектов ПО , атрибутов и связей;

· содержания и формата создаваемых ими документов.

База данных содержит четыре таблицы: Учебные планы, Группы, Предметы и Занятия. Таблицы соединены отношениями «один-ко-многим» как показано на ER-диаграмме:

Даталогическая модель

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

На шаге даталогического проектирования строится логическая структура БД. При всем этом происходит преобразование начальной инфологической модели в модель данных, которая поддерживается определенной СУБД. Опосля этого делается проверка адекватности даталогической модели, отображаемой предметной области. Конечным результатом даталогического проектирования является описание структуры БД на языке описания данных определенных СУБД.

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

Не все виды связи имеющиеся в предметной области можно показать даталогической моделью. Так большая часть СУБД не обеспечивают поддержание связи типа М:М. В этом случае в даталогической модели вводится вспомогательный элемент, т.е. M:N разбивается на два дела меж начальными элементами и вспомогательными (1:M, 1:N).

Ниже приведен DDL-скрипт для сотворения базы данных:

SET SQL DIALECT 3;

SET NAMES WIN1251;

CREATE DATABASE ‘LOCALHOST:C:MySoftUPup.gdb’

User ‘SYSDBA’ PASSWORD ‘masterkey’

PAGE_SIZE 16384

DEFAULT CHARACTER SET WIN1251;

CREATE TABLE GROUPS (

ID_G INTEGER NOT NULL,

NAZV VARCHAR(4),

GOD INTEGER,

CHISL INTEGER

);

CREATE TABLE PREDM (

ID_P INTEGER NOT NULL,

NAZV VARCHAR(25)

);

CREATE TABLE ZAN (

ID_Z INTEGER NOT NULL,

ID_UP INTEGER,

D DATE,

T TIME,

VID_Z CHAR(1),

H SMALLINT DEFAULT 2

);

CREATE TABLE UP (

ID_UP INTEGER NOT NULL,

ID_G INTEGER,

ID_P INTEGER,

SEM INTEGER,

H_L INTEGER,

H_P INTEGER,

H_L_CALC COMPUTED BY ((select sum(H) from zan where zan.id_up=up.id_up and vid_z=’Л’)),

H_P_CALC COMPUTED BY ((select sum(H) from zan where zan.id_up=up.id_up and vid_z=’П’))

);

CREATE TABLE PREPODS (

ID_P INTEGER NOT NULL,

FIO VARCHAR(30),

DR DATE

);

/* Check constraints definition */

ALTER TABLE ZAN ADD CHECK (VID_Z IN (‘Л’, ‘П’));

ALTER TABLE UP ADD CONSTRAINT UNQ1_UP UNIQUE (ID_G, ID_P, SEM);

ALTER TABLE GROUPS ADD CONSTRAINT PK_GROUPS PRIMARY KEY (ID_G);

ALTER TABLE PREDM ADD CONSTRAINT PK_PREDM PRIMARY KEY (ID_P);

ALTER TABLE UP ADD CONSTRAINT PK_UP PRIMARY KEY (ID_UP);

ALTER TABLE ZAN ADD CONSTRAINT PK_ZAN PRIMARY KEY (ID_Z);

ALTER TABLE UP ADD CONSTRAINT FK_UP_1 FOREIGN KEY (ID_G) REFERENCES GROUPS (ID_G) ON UPDATE CASCADE;

ALTER TABLE UP ADD CONSTRAINT FK_UP_2 FOREIGN KEY (ID_P) REFERENCES PREDM (ID_P) ON UPDATE CASCADE;

ALTER TABLE ZAN ADD CONSTRAINT FK_ZAN_1 FOREIGN KEY (ID_UP) REFERENCES UP (ID_UP) ON UPDATE CASCADE;

ALTER PROCEDURE ADD_ZAN (ID_Z INTEGER, N INTEGER) AS

declare variable d date;

declare variable t time;

declare variable vid_z char(1);

declare variable h smallint;

declare variable id_up integer;

begin

select id_up, d, t, vid_z, h from zan where id_z =:id_z

into:id_up,:d,:t,:vid_z,:h;

while (n>0) do

begin

d = d+7;

insert into zan (id_up, d, t, vid_z, h)

values (:id_up,:d,:t,:vid_z,:h);

n=n-1;

end

end

Выбор средств реализации

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

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

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

Но кроме технических средств и СУБД нужно выполнить взаимодействие меж ними и юзером. Этот интерфейс должен быть интуитивно понятен и очень эргономичен, т.е. предоставить юзеру возможность легкой и резвой модификации данных, подборки данных по запросу, баз данных Firebird. Firebird является клоном такового известного продукта конторы Borland, как Interbase. InterBase – баз данных, имеющий 20-летнюю историю (сотворен в 1985 году). Инновации, предложенные в этом сервере, не только лишь остаются животрепещущими до сего времени, да и начинают обширно внедряться в других СУБД. Главный индивидуальностью функциональности InterBase является версионность.

Механизм версионности не считая InterBase фактически нигде не употреблялся, и потихоньку начал внедряться в коммерческих серверах не наиболее 10 лет вспять. На текущий момент в той либо другой степени версионный механизм поддерживают не считая InterBase и Firebird: Oracle, PostgreSQL, также MS SQL 2005. В 2000 году компания Borland в силу специфичных обстоятельств выпустила InterBase 6.0 в OpenSource. Когда начальные коды InterBase были размещены, группа юзеров скопировала начальные тексты и начала новейший проект под заглавием Firebird. Дальше, с версии InterBase 6.5 Borland возвратился к схеме платного сервера с закрытыми начальными текстами, а Firebird продолжил существование как бесплатный для личного и коммерческого использования сервер с открытыми начальными текстами.

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

Постановка задачки

приложение призвано обеспечить интерфейс юзера и СУБД и обязано удовлетворять последующим требованиям:

· содержательное заглавие.

· ясные и понятные аннотации.

· логическая обоснованность группировки и последовательности полей.

· просто известные наименования полей.

· согласованная терминология и сокращения.

· согласованное внедрение цветов.

· зрительное выделение пространств и границ полей ввода данных.

· комфортные средства перемещения курсора.

· средства исправления отдельных неверных знаков и целых полей.

· средства вывода сообщений о ошибках при вводе недопустимых значений.

· особенное выделение необязательных для ввода полей.

· средства вывода объяснительных сообщений с описанием полей.

· средства вывода сообщения о окончании наполнения формы.

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

В базе хоть какого приложения баз данных лежат наборы данных, которые представляют собой группы записей (их комфортно представить в виде таблиц в памяти), переданных из базы данных в приложение для просмотра и редактирования. Любой набор данных инкапсулирован в особом компоненте доступа к данным. В Delphi реализован набор базисных классов, поддерживающих функциональность наборов данных, и фактически схожие по составу наборы дочерних компонент для технологий доступа к данным. Их общий предок – класс TDataSet.

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

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

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

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

Реализация проекта

На последующем рисунке приведена основная форма приложения:

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

Все невизуальные составляющие: IBDatabase, IBTransaction, IBDataset, DataSource вынесены в особый контейнер DataModule:

Для подборки данных, их конфигурации, удаления и вставки в TIBDataSet употребляется набор параметров, представляющих из себя SQL-запросы для манипулирования данными, – это SelectSQL, DeleteSQL, InsertSQL и ModifySQL.

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

В свойстве SelectSQL указывается запрос на подборку данных (SELECT… FROM…), которые будут доступны для просмотра и, зависимо от содержимого других запросов, для редактирования, удаления и т.д.

В свойствах DeleteSQL, InsertSQL и ModifySQL указываются надлежащие запросы, которые будут вызываться автоматом самим компонентом при вызове способов Delete, Insert и Edit для удаления, вставки и редактирования записей.

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

С помощью IBDatabase приложение подключается к базе данных с внедрением учетной записи админа: SYSDBA.

На последующем рисунке приведен вид окна установки характеристик подключения:

Составляющие IBDataSetGroups и IBDataSetUP, также IBDataSetUP и IBDataSetZanнаходятся с отношении главный-подчиненный (master-detail). Этот режим обеспечивает отбор записей подчиненной таблицы зависимо от значения главного поля текущей записи главной таблицы.

На последующем рисунке представлено окно редактирования текста запроса на подборку компонента IBDataSetUP. Для реализации master-detail употребляется свойство IBDataSetUP. DataSource:= DataSourceGroups и условие отбора по значению текущей группы:

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

При добавлении либо изменении текущей записи раскрывается форма с компонентами редактирования. При всем этом в первом случае соответственный набор данных переводится в режим Insert, во 2-м – в режим Edit.

На формах размещены составляющие редактирования полей текущей записи, т.н. db-aware составляющие. Они все соединены с надлежащими наборами данных, расположенными на главной форме приложения. Внесение конфигураций с помощью этих компонент автоматом переводит набор данных в состояние Edit. При добавлении новейшей записи нужно перевести набор данных в состояние Insert, вызвав соответственный способ.

Управление юзера

Для работы информационной системы нужно наличие файла приложения UP.EXE и файла базы данных UP.GDB. Не считая того, на машине юзера должен быть установлен SQL-сервер Firebird.

На последующем рисунке приведен вид приложения:

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

Приложение дозволяет юзеру:

· добавлять, изменять, удалять учебные группы

· добавлять, изменять, удалять предметы

· добавлять, изменять, удалять учебные планы

· редактировать сведения о проведенных упражнениях

В таблице УЧЕБНЫЕ ПЛАНЫ юзер лицезреет планы лишь той группы, которая является текущей в таблице ГРУППЫ, а в таблице ЗАНЯТИЯ – лишь те занятия, которые проведены по текущему плану в таблице УЧЕБНЫЕ ПЛАНЫ.

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

При модификации таблицы ЗАНЯТИЯ, конфигурации автоматом отражаются в таблице УЧЕБНЫЕ ПЛАНЫ.

При нажатии клавиши Удалить возникает окно, в каком нужно подтвердить удаление записи. Это нужно для защиты от ненамеренной утраты данных.

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

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

Окно редактирования данных группы:

В данном окне доступны для редактирования данные о группе:

· Заглавие группы

· Год поступления группы

· Численный состав группы

Окно редактирования предмета:

Окно редактирования данных о педагоге:

В данном окне доступны для редактирования данные о педагоге:

· Фамилия, имя, отчество.

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

В данном окне доступно для редактирования лишь заглавие предмета.

Окно редактирования данных о учебном плане:

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

· Семестр.

· Изучаемый предмет.

· количество лекционных часов.

· Количество практических часов.

· Педагог.

Сведения о группе носят справочный нрав и не доступны для редактирования. При составлении новейшего учебного плана, он автоматом наследует ту группу, которая является текущей в таблице ГРУППЫ.

В окно редактирования данных о проведенном занятии доступны для редактирования данные о проведенном занятии:

· Дата и время проведения занятия.

· Вид занятия (лекционное либо практическое).

· количество часов (по дефлоту = 2).

· Педагог (по дефлоту = педагог по учебному плану).

Сведения о учебном плане носят справочный нрав и не доступны для редактирования. При добавлении новейшего занятия ему присваивается номер учебного плана, который является текущим в таблице УЧЕБНЫЕ ПЛАНЫ.

Опосля внесения конфигураций окно запирается нажатием на одну из клавиш OK либо Cancel. В первом случае все внесенные конфигурации сохраняются, во 2-м – отменяются.

При добавлении записи возникает аналогичное окно с пустыми полями для ввода новейших значений. Клавиша OK закрывает окно с сохранением, клавиша Cancel– без сохранения.

Заключение

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

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

Перечень применяемой литературы

1. Избачков Ю., Петров В. Информационные системы: Учебник для вузов. 2-е издание, Изд.: Питер, 2006.

2. Аппак М.А., «Автоматические рабочие места на базе индивидуальных ЭВМ », М.: ‘Радио и связь’, 1999 г.

3. Борри Х. Firebird: управление разраба баз данных: Пер. с англ. – СПб.: БХВ-Петербург, 2006.

4. Грофф Дж., Вайнберг П. Энциклопедия SQL. 3-е издание. Пер. с англ. – С-Пб.: Питер, 2003.

5. Дейт К. Введение в системы баз данных. – Киев: Диалектика, 1998.

6. Карпова Т.С. Базы данных. Модели, разработка, реализация. – СПб: Питер, 2001.

7. Конноли Т., Бегг К., Страчан А. Базы данных: проектирование, реализация, сопровождение. – М., Вильямс. 2003.

8. Ковязин А., Востриков С. мир Interbase. Архитектура, администрирование и разработка приложений баз данных в Interbase. – М., Кудиц-Образ, 2002.

9. Ульман Д., Уидом Д. Введение в системы баз данных. – Лори. 2000.

10.Фаронов В.В. Delphi 5. Управление программера. Нолидж. 2001.

11.Фаронов В.В. Программирование баз данных в Delphi 7. – СПб: Питер, 2004.

12.Хансен Г., Хансен Д. Базы данных. Разработка и управление. – М., Двучлен. 2000.

13.Голицына О.Л., Максимов Н.В., Попов И.И. Базы данных: учеб. пособие. – М., форум: Инфра-М, 2007.

]]>