Разработка прикладной информационной системы «Соревнования по многоборью»
Предметное приложение запрос данные Введение Разработка программного обеспечения и его сопровождение остается важнейшей функцией компьютерных специалистов, наряду с системным администрированием и проектированием систем управления базами данных (СУБД). Широкое внедрение вычислительных машин во все сферы промышленности, связи, систем управления и документооборота требует массу программного… Читать ещё >
Разработка прикладной информационной системы «Соревнования по многоборью» (реферат, курсовая, диплом, контрольная)
Министерство Образования и Науки РФ Рязанский Государственный Радиотехнический университет РГРТУ Кафедра ИБ Пояснительная записка к курсовой работе по дисциплине
«Системы управления базами данных»
на тему:
«Разработка прикладной информационной системы «Соревнования по многоборью»
Рязань 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.