Разработка прикладной информационной системы "Соревнования по многоборью"

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

Министерство Образования и Науки РФ

Рязанский Государственный Радиотехнический университет

РГРТУ

Кафедра ИБ

Пояснительная записка к курсовой работе

по дисциплине

«Системы управления базами данных»

на тему:

«Разработка прикладной информационной системы «Соревнования по многоборью»

Рязань 2014



Оглавление

Введение

1.Задание на курсовое проектирование и исходные данные

1.1Описание предметной области «Спортивные соревнования»

1.2Вариант задания

2.Проектирование концептуальной и логической модели данных

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

2.2Определение сущностей и связей

2.3Построение ER - диаграммы

2.4Формирование отношений

2.5Добавление не вошедших в ER - диаграмму атрибутов

2.6Распределение атрибутов по отношениям

2.7Нормализация отношений

3.Проектирование физической модели данных

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

3.2Создание таблиц базы данных

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

5.Описание работы клиентского приложения

5.1Выбор среды программирования

5.2Разработка клиентского приложения

5.3Тестирование приложения

Литература

Приложение

предметное приложение запрос данные



Введение

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

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

Для создания программной клиентской части используется среда разработки Delphi 7, для создания базы данных - MS SQL SERVER 2008.

Microsoft SQL Server система управления реляционными базами данных (СУБД), разработанная корпорацией Microsoft. Основной используемый язык запросов -- Transact-SQL. Используется для работы с небольшими и средними по размеру базами данных, а также крупными базами данных масштаба предприятия; конкурирует с другими СУБД в этом сегменте рынка.



1. Задание на курсовое проектирование и исходные данные

1.1 Описание предметной области «Спортивные соревнования»

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

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

менее 11.0 с- 5 очков;

от 11.0 до 11.5 с- 4 очка;

от 11.5 до 12.0 с- 3 очка;

от 12.0 до 12.5 с- 2 очка;

от 12.5 до 13.5 с- 1 очко;

более 13.5 с- 0 очков.

В связи с этим атрибут Результат в таблице пересчет участвует дважды: как РезультатОт и как РезультатДо.

1.2 Вариант задания

Вывести информацию о спортсменах и набранных ими очках по видам спорта.



2. Проектирование концептуальной и логической модели данных

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

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

вывод информации о спортсменах;

вывод информации о видах спорта;

вывод таблицы пересчета;

вывод результатов спортсменов

вывод набранных очков и информации о каждом спортсмене по видам спорта.

В базе данных необходимо хранить следующую информацию:

фамилию каждого спортсмена и его порядковый номер;

наименование вида спорта и его порядковый номер;

в таблице пересчета такие значения как РезультатОТ и РезультатДО и количество очков соответственно;

результат каждого спортсмена по каждому виду спорта;

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



2.2 Определение сущностей и связей

После анализа предметной области выделим следующие сущности:

Таблица 1 - Набор сущностей

Сущность	Ключевой атрибут	Описание
Спортсмен	Номер спортсмена	Участник соревнования
Спорт	Номер вида спорта	Вид спорта, в котором соревнуются спортсмены
Результат	Номер спортсмена, номер вида спорта	Результат в метрах, секундах и прочее
Очки	Номер вида спорта, результат	Количество очков по показанным результатам

Выделим следующие связи между сущностями:

каждый спортсмен может участвовать в нескольких видах спорта;

в каждом виде спорта могут соревноваться несколько спортсменов;

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

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

2.3 Построение ER - диаграммы

ER-диаграмма классов имеет следующий вид:

каждый спортсмен может участвовать в нескольких видах спорта (рисунок 1):

Рисунок 1 - Связь классов сущностей «Спортсмен» и «Вид спорта»

Таким образом связь между классами сущностей «Спортсмены» и «Вид спорта» 1:N (один ко многим). Спортсмен может существовать без результата, результат без спортсмена нет.

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

Рисунок 2 - Связь классов сущностей «Вид спорта» и «Результат»

Таким образом связь между классами сущностей «Вид спорта» и «Результат» 1:N (один ко многим).

результаты по каждому виду спорта могут быть пересчитаны в число очков и они являются уникальными для каждого вида спорта и диапазона результатов (рисунок 3):

Рисунок 3 - Связь классов сущностей «Результат» и «Очки»

Таким образом связь между классами сущностей «Результат» и «Очки» 1:1 (один к одному).

2.4 Формирование отношений

Исходя из построенных ER-диаграмм получим следующие отношения:

«Спортсмены» (ID_Sportsmen, Фамилия спортсмена);

«Виды спорта» (ID_Sport, Вид спорта);

«Участие» (ID_Sportsmen, ID_Sport, Результат);

«Пересчет» (ID_Sport, РезультатОТ, РезультатДО, Очки).

2.5 Добавление не вошедших в ER - диаграмму атрибутов

Как было уже выше сказано результаты, которые показывают спортсмены могут соответствовать различным видам спорта. Поэтому целесообразно указать единицы измерения для каждого вида спорта. За этим включим дополнительный атрибут «Единицы измерения». Перечислим все атрибуты, которые будут добавлены в отношениям:

ID_Sportsmen (№ спортсмена по порядку);

фамилия ;

ID_Sport (№ вида спорта);

вид спорта;

результат;

результатОТ;

результатДО;

очки;

единицы измерения.

2.6 Распределение атрибутов по отношениям

Рассмотренные выше атрибуты добавляются к отношениям следующим образом:

«Спортсмены» (ID_Sportsmen, Фамилия спортсмена);

«Виды спорта» (ID_Sport, Вид спорта);

«Участие» (ID_Sportsmen, ID_Sport, Результат);

«Пересчет» (ID_Sport, РезультатОТ, РезультатДО, Очки);

«Система мер» (ID_Sport, Единицы измерения).

2.7 Нормализация отношений

Для начала дадим определения для каждой нормальной формы.

Отношения находятся в первой нормальной форме (1НФ), если на пересечении каждой строки и каждого столбца находится одно значение.

Отношения находятся во второй нормальной форме (2НФ), если они находятся в 1НФ и все неключевые атрибуты функционально полно зависят от потенциального ключа. Другими сло-ва-ми, отношения находятся в 2НФ, если отсутствуют частичные функциональные зависимости.

Отношения находятся в третьей нормальной форме (3НФ), если они находятся в 2НФ, и в них нет транзитивных зависимостей неключевых атрибутов от любого потенциального ключа.

Отношения находятся в БКНФ, т. к. в них существует единственный потенциальный ключ, который является детерминантом всех функциональных зависимостей.

Отношения находятся в четвёртой нормальной форме (4НФ), если она находится в нормальной форме Бойса -- Кодда и не содержит нетривиальных многозначных зависимостей.

Отношения находятся в пятой нормальной форме (5НФ) (иначе -- в проекционно-соединительной нормальной форме) тогда и только тогда, когда каждая нетривиальная зависимость соединения в ней определяется потенциальным ключом (ключами) этого отношения.

Теперь рассмотрим отношение «Спортсмены». Построим диаграмму функциональной зависимости в данном отношении (рисунок 5):

Рисунок 5 - Функциональная зависимость в отношении «Спортсмены»



Проверим отношение «Спортсмены» на соответствие нормальным формам. Отношение удовлетворяет первой нормальной форме (1НФ), т.к. на пересечении каждой строки и каждого столбца находится одно значение. Отношение «Спортсмены» также удовлетворяет условиям второй нормальной формы (2НФ), т.к. видно, что оно находятся в 1НФ и все неключевые атрибуты (Фамилия) функционально полно зависят от потенциального ключа(ID_Sportsmen).

Проверим отношение «Спортсмены» на соответствие третьей нормальной форме (3НФ), т.к. оно находятся в 2НФ, и в нем нет транзитивных зависимостей неключевых атрибутов от любого потенциального ключа. М

Можно сделать вывод, что данное отношение находится в 3НФ и в дальнейшей нормализации не нуждается.

Рассмотрим отношение «Виды спорта». Построим диаграмму функциональной зависимости в данном отношении (рисунок 6):

Рисунок 6- Функциональная зависимость в отношении «Виды спорта»

Проверим отношение «Виды спорта» на соответствие нормальным формам. Отношение удовлетворяет первой нормальной форме (1НФ), т.к. на пересечении каждой строки и каждого столбца находится одно значение. Отношение «Виды спорта» также удовлетворяет условиям второй нормальной формы (2НФ), т.к. видно, что оно находятся в 1НФ и все неключевые атрибуты (Вид спорта) функционально полно зависят от потенциального ключа(ID_Sport).

Проверим отношение «Спортсмены» на соответствие третьей нормальной форме (3НФ), т.к. оно находятся в 2НФ, и в нем нет транзитивных зависимостей неключевых атрибутов от любого потенциального ключа.

Можно сделать вывод, что данное отношение находится в 3НФ и в дальнейшей нормализации не нуждается.

Рассмотри отношение «Участие». Построим диаграмму функциональной зависимости в данном отношении (рисунок 7):

Рисунок 7 - Функциональная зависимость в отношении «Участие»

Проверим отношение «Участие» на соответствие нормальным формам. Отношение удовлетворяет первой нормальной форме (1НФ), т.к. на пересечении каждой строки и каждого столбца находится одно значение. Отношение «Участие» также удовлетворяет условиям второй нормальной формы (2НФ), т.к. видно, что оно находятся в 1НФ и все неключевые атрибуты (Результат) функционально полно зависят от потенциального ключа(ID_Sport,ID_Sportsmen).

Проверим отношение «Участие» на соответствие третьей нормальной форме (3НФ), т.к. оно находятся в 2НФ, и в нем нет транзитивных зависимостей неключевых атрибутов от любого потенциального ключа.

Можно сделать вывод, что данное отношение находится в 3НФ и в дальнейшей нормализации не нуждается.

Рассмотрим отношение «Пересчет». Построим диаграмму функциональной зависимости в данном отношении (рисунок 8):

Рисунок 8 - Функциональная зависимость в отношении «Пересчет»

Проверим отношение «Участие» на соответствие нормальным формам. Отношение удовлетворяет первой нормальной форме (1НФ), т.к. на пересечении каждой строки и каждого столбца находится одно значение. Отношение «Пересчет» также удовлетворяет условиям второй нормальной формы (2НФ), т.к. видно, что оно находятся в 1НФ и все неключевые атрибуты (Результат) функционально полно зависят от потенциального ключа(ID_Sport,РезультаОТ,РезультатДО).

Проверим отношение «Пересчет» на соответствие третьей нормальной форме (3НФ), т.к. оно находятся в 2НФ, и в нем нет транзитивных зависимостей неключевых атрибутов от любого потенциального ключа.

Можно сделать вывод, что данное отношение находится в 3НФ и в дальнейшей нормализации не нуждается.

Рассмотрим отношений «Система мер». Построим диаграмму функциональной зависимости в данном отношении (рисунок 9):

Рисунок 9 - Функциональная зависимость в отношении «Пересчет»

Проверим отношение «Участие» на соответствие нормальным формам. Отношение удовлетворяет первой нормальной форме (1НФ), т.к. на пересечении каждой строки и каждого столбца находится одно значение. Отношение «Пересчет» также удовлетворяет условиям второй нормальной формы (2НФ), т.к. видно, что оно находятся в 1НФ и все неключевые атрибуты (Результат) функционально полно зависят от потенциального ключа(ID_Sport,РезультаОТ,РезультатДО).

Проверим отношение «Пересчет» на соответствие третьей нормальной форме (3НФ), т.к. оно находятся в 2НФ, и в нем нет транзитивных зависимостей неключевых атрибутов от любого потенциального ключа.

Можно сделать вывод, что данное отношение находится в 3НФ и в дальнейшей нормализации не нуждается.

Таким образом все построенные отношения нормализованы по третей нормально форме.



3. Проектирование физической модели данных

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

На рисунке 10 покажем структуру разработанной базы данных "Соревнования по многоборью".

Рисунок 10 - Структура базы данных

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

3.2 Создание таблиц базы данных

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

Таблица 2 - Таблица "Спортсмены"

Ключ	Атрибут	Тип атрибута
Первичный	ID_Sportsmen	int
	Фамилия	nvarchar(50)



Таблица 3 - Таблица "Виды спорта"

Ключ	Атрибут	Тип атрибута
Первичный	ID_Sport	int
	Виды спорта	nvarchar(50)

Таблица 4 - Таблица "Система мер"

Ключ	Атрибут	Тип атрибута
Первичный	ID_Sport	int
	Единицы измерения	Nvarchar(50)

Таблица 5 - Таблица "Пересчет"

Ключ	Атрибут	Тип атрибута
Внешний 1	ID_Sport	int
Первичный 1	РезультатОТ	float
Первичный 2	РезультатДО	float
	Кол-во очков	int

Таблица 6 - Таблица "Участие"

Ключ	Атрибут	Тип атрибута
Внешний 1	ID_Sportsmen	int
Внешний 2	ID_Sport	int
	Результат	float



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

В соответствие с заданием, указанном в пункте 1.2 был разработан следующий SQL-запрос:

SELECT [Виды спорта].[Вид спорта],

Спортсмены.Фамилия,

Участие.Результат,

Пересчет.[Кол-во очков]

FROM Пересчет

JOIN [Виды спорта] ON [Виды спорта].ID_Sport = Пересчет.ID_Sport

JOIN Участие ON Участие.ID_Sport = [Виды спорта].ID_Sport

JOIN Спортсмены ON Спортсмены.ID_Sportsmen = Участие.ID_Sportsmen

WHERE (Участие.Результат >= Пересчет.[Результат ОТ (>=)]

and Участие.Результат< Пересчет.[Результат ДО (<)])

or (Участие.Результат >= Пересчет.[Результат ОТ (>=)]

and Пересчет.[Результат ДО (<)]='0')

Рисунок 11 - Пример работы SQL-запрос



5. Описание работы клиентского приложения

5.1 Выбор среды программирования

Клиентское приложение "Соревнования по многоборью" было разработано в среде программирования Delphi 7 на языке программирования Delphi.

5.2 Разработка клиентского приложения

Разработка приложения "Соревнования по многоборью" была осуществлена с использование стандартных компонент Delphi. Для соединения с базой данных использовались такие компоненты как ADOConnection (непосредственно для подключения базы данных), ADOTable и DateSource(для работы с таблицами базы данных), ADOQuery (для выполненияSQL запроса в приложении). В качестве запроса использовался статистический запрос - текст запроса полностью формируется на этапе разработки приложения.

5.3 Тестирование приложения

Для начала покажем нормальную работу приложения. Перед запуском приложения на некоторое время появляется заставка следующего вида (рисунок 12):

Рисунок 12 - Заставка приложения

Далее открывается главное окно программы (рисунок 13):

Рисунок 13 - Главное окно программы

Использую панель меню можно просмотреть различные таблицы базы данных (рисунок 14):

Рисунок 14 - Пункт меню Таблицы

Двойным нажатием мыши по ячейке базы данных или вызовом из меню команды Редактировать (Файл -> Редактировать) открывается окно редактирования базы с возможностями изменения, сохранения, удаления записей базы данных, а также создания новой записи (рисунок 15):

Рисунок 16 - Форма редактирования содержимого базы данных

Теперь проверим работу нашего запроса в приложении. Для сортировки по видам спорта в окно вводу необходимо ввести нужный вид спорта учитывая регистр и нажать кнопку "Выполнить запрос" (рисунок 17):



Рисунок 17 - Выполнение запроса

Результат работы можно сравнить с результатом работы запроса, сформированного в MS SQL SERVER 2008 (рис. 11).

Если пользователь попытается ввести какие-то другие данные, то появится сообщение об ошибке следующего вида (рисунок 18):

Рисунок 18 - Сообщение об ошибке



Литература

ГОСТ 2.105 -- 95. ЕСКД. «Общие требования к текстовым документам»

В. Фаронов - Программирование баз данных в Delphi 7. Учебный курс, Питер 2006

А. Зубов - Программирование на DELPHI. Трюки и эффекты , Питер

Методические указания к курсовой работе по курсу СУБД, Калинкина Т. И.



ПРИЛОЖЕНИЕ

unit SUBD;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, Grids, DBGrids, StdCtrls, ExtCtrls, DB, ADODB, Menus;

type

TForm1 = class(TForm) Panel2: TPanel;

DBGrid1: TDBGrid;

Panel3: TPanel;

DBGrid2: TDBGrid;

MainMenu1: TMainMenu;

N1: TMenuItem;

N2: TMenuItem;

N3: TMenuItem;

N5: TMenuItem;

N6: TMenuItem;

N8: TMenuItem;

N9: TMenuItem;

Panel1: TPanel;

Edit1: TEdit;

Button1: TButton;

Label1: TLabel;

Label2: TLabel;

Label3: TLabel;

N4: TMenuItem;

Label4: TLabel;

N7: TMenuItem;

N10: TMenuItem;

N11: TMenuItem;

N12: TMenuItem;

procedure N2Click(Sender: TObject);

procedure N8Click(Sender: TObject);

procedure N9Click(Sender: TObject);

procedure N6Click(Sender: TObject);

procedure Button1Click(Sender: TObject);

procedure N4Click(Sender: TObject);

procedure N7Click(Sender: TObject);

procedure N10Click(Sender: TObject);

procedure N11Click(Sender: TObject);

procedure N12Click(Sender: TObject);

procedure DBGrid1DblClick(Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

Form1: TForm1;

implementation

uses DM, Editor;

{$R *.dfm}

procedure TForm1.N2Click(Sender: TObject);

begin

close;

end;

procedure TForm1.N8Click(Sender: TObject);

begin

DBGrid1.DataSource:=fDM.DSSportsmen;

end;

procedure TForm1.N9Click(Sender: TObject);

begin

DBGrid1.DataSource:=fDM.DSCount;

end;

procedure TForm1.N4Click(Sender: TObject);

begin

DBGrid1.DataSource:=fDM.DSSports;

end;

procedure TForm1.N7Click(Sender: TObject);

begin

DBGrid1.DataSource:=fDM.DSSM;

end;

procedure TForm1.N10Click(Sender: TObject);

begin

DBGrid1.DataSource:=fDM.DSParticipation;

end;

procedure TForm1.N6Click(Sender: TObject);

var R:Word;

begin

R:=MessageDLG('Курсовой проект по дисциплине'+#13#10#13#10+'СУБД'+#13#10#13#10+'Разработчик Старкова И.А.'+#13#10#13#10+'Рязань 2014',mtInformation,[mbOK],0);

end;

procedure TForm1.Button1Click(Sender: TObject);

var R:Word; s1:string; i:integer; p:boolean;

begin

fDM.TSports.First;

p:=false;

for i:=1 to fDM.TSports.RecordCount do

begin

s1:=fDM.TSports.FieldByName('Вид спорта').asString;

if Edit1.Text = s1

then

begin

p:=true;

fDM.ADOQuery2.Close;

fDM.ADOQuery2.Parameters.ParamByName('name').Value :=Edit1.Text;

fDM.ADOQuery2.Open;

end

else

fDM.TSports.Next;

end;

if p=false then R:=MessageDLG('Такой вид спорта не зарегистрирован',mtError,[mbYes],0);

end;

procedure TForm1.N11Click(Sender: TObject);

begin

fDM.TSportsmen.Append;

fDM.TSports.Append;

fDM.TSM.Append;

fDM.TParticipation.Append;

fDM.TCount.Append;

fEditor.ShowModal;

end;

procedure TForm1.N12Click(Sender: TObject);

begin

fEditor.ShowModal;

end;

procedure TForm1.DBGrid1DblClick(Sender: TObject);

begin

fEditor.ShowModal;

end;

end.

unit DM;

interface

uses

SysUtils, Classes, DB, ADODB;

type

TfDM = class(TDataModule)

ADOConnection1: TADOConnection;

DSSportsmen: TDataSource;

DSSports: TDataSource;

DSCount: TDataSource;

DataSource2: TDataSource;

ADOQuery2: TADOQuery;

TParticipation: TADOTable;

TSM: TADOTable;

DSParticipation: TDataSource;

DSSM: TDataSource;

TSportsmen: TADOTable;

TSports: TADOTable;

TCount: TADOTable;

TSportsmenID_Sportsmen: TIntegerField;

TSportsmenDSDesigner: TWideStringField;

TParticipationID_Sport: TIntegerField;

TParticipationID_Sportsmen: TIntegerField;

TParticipationDSDesigner: TFloatField;

TSportsID_Sport: TIntegerField;

TSportsDSDesigner: TWideStringField;

TCountID_Sport: TIntegerField;

TCountDSDesigner: TFloatField;

TCountDSDesigner2: TFloatField;

TCountDSDesigner3: TIntegerField;

ADOQuery2ID_Sport: TIntegerField;

ADOQuery2DSDesigner: TWideStringField;

ADOQuery2DSDesigner2: TWideStringField;

ADOQuery2DSDesigner3: TFloatField;

ADOQuery2DSDesigner4: TIntegerField;

TSMID_Sport: TIntegerField;

TSMDSDesigner: TWideStringField;

private

{ Private declarations }

public

{ Public declarations }

end;

var

fDM: TfDM;

implementation

uses SUBD;

{$R *.dfm}

end.

unit Editor;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, StdCtrls, Mask, DBCtrls, ExtCtrls;

type

TfEditor = class(TForm)

GroupBox1: TGroupBox;

GroupBox2: TGroupBox;

GroupBox3: TGroupBox;

GroupBox4: TGroupBox;

GroupBox5: TGroupBox;

DBEdit1: TDBEdit;

DBEdit2: TDBEdit;

Label1: TLabel;

Label2: TLabel;

Label3: TLabel;

Label4: TLabel;

DBEdit3: TDBEdit;

DBEdit4: TDBEdit;

DBEdit5: TDBEdit;

DBEdit6: TDBEdit;

Label5: TLabel;

Label6: TLabel;

Label7: TLabel;

DBEdit7: TDBEdit;

Label8: TLabel;

DBEdit8: TDBEdit;

Label9: TLabel;

DBEdit9: TDBEdit;

DBEdit10: TDBEdit;

DBEdit11: TDBEdit;

DBEdit12: TDBEdit;

DBEdit13: TDBEdit;

Label10: TLabel;

Label11: TLabel;

Label12: TLabel;

Label13: TLabel;

Button1: TButton;

Button2: TButton;

DBNavigator1: TDBNavigator;

DBNavigator2: TDBNavigator;

Label14: TLabel;

Label15: TLabel;

DBNavigator3: TDBNavigator;

DBNavigator4: TDBNavigator;

DBNavigator5: TDBNavigator;

Label16: TLabel;

Label17: TLabel;

Label18: TLabel;

procedure Button1Click(Sender: TObject);

procedure Button2Click(Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

fEditor: TfEditor;

implementation

uses DM;

{$R *.dfm}

procedure TfEditor.Button1Click(Sender: TObject);

begin

if fDM.TSportsmen.Modified then

fDM.TSportsmen.Post;

if fDM.TSports.Modified then

fDM.TSports.Post;

if fDM.TSM.Modified then

fDM.TSM.Post;

if fDM.TParticipation.Modified then

fDM.TParticipation.Post;

if fDM.TCount.Modified then

fDM.TCount.Post;

close;

end;

procedure TfEditor.Button2Click(Sender: TObject);

begin

fDM.TSportsmen.Append;

fDM.TSports.Append;

fDM.TSM.Append;

fDM.TParticipation.Append;

fDM.TCount.Append;

DBEdit1.SetFocus;

end;

end.

program SUBD1;

uses

Forms,

SUBD in 'SUBD.pas' {Form1},

DM in 'DM.pas' {fDM: TDataModule},

Editor in 'Editor.pas' {fEditor},

Unit2 in 'Unit2.pas' {Form2};

{$R *.res}

begin

Application.Initialize;

Form2 := TForm2.Create(Application);

Form2.Show;

Form2.Update;

while Form2.Timer1.Enabled do

Application.ProcessMessages;

Application.CreateForm(TForm1, Form1);

Application.CreateForm(TfDM, fDM);

Application.CreateForm(TfEditor, fEditor);

Form2.Hide;

Form2.Free;

Application.Run;

end.

unit Unit2;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, ExtCtrls, jpeg;

type

TForm2 = class(TForm)

Timer1: TTimer;

Image1: TImage;

procedure Timer1Timer(Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

Form2: TForm2;

implementation

{$R *.dfm}

procedure TForm2.Timer1Timer(Sender: TObject);

begin

Timer1.Enabled := false;

end;

end.

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