СОДЕРЖАНИЕ
Введение
1. Концептуальная модель базы данных «Чемпионат авто»
1.1 Основные понятия
1.2 Описание предметной области
1.3 Каталог задач
1.4 Описание таблиц
1.5 Схема данных
1.6 ER-диаграмма
2. Реляционная модель базы данных «Спортивный комплекс»
2.1 Выбор логической модели
2.2 Основные понятия
2.3 Проектирование реляционной модели
2.3.1 Нормализация отношений
2.3.2 Описание ключей
2.3.3 Правила целостности
3. Реализация базы данных «Чемпионат авто»
4. Результат работы базы данных «Чемпионат авто»
ВВЕДЕНИЕ
Выбор предметной области «Чемпионат авто» обусловлен личным интересом и возможностью распространения базы данных среди специалистов и интересующихся. При проектировании программ выясняются запросы и пожелания пользователя, и определяется возможный подход к решению задачи. Задача анализируется. На основе этого анализа реализуется конкретная модель в конкретной программной среде. Результаты каждого этапа проектирования используются в качестве исходного материала следующего этапа. Анализируется текущая организация «Чемпионат авто», выделяются проблемы для решения, определяются объекты отношения между ними, разрабатывается модель с учетом конкретных условий ее функционирования. База данных ориентирована на определенную предметную область и организована на основе некоторого подмножества данных. Возможности баз данных полезны в областях, связанных с долговременным управлением информацией, таких как электронные библиотеки и хранилища данных. При проектировании системы обработки данных больше всего нас интересует организация данных. Требования отдельных пользователей должны быть представлены в едином “обобщенном представлении”. Последнее называют концептуальной моделью. В процессе проектирования необходимо: Описать предметную область ;определить состав и содержание информации, используемой в данной предметной области; выявить сущности; выявить связи между сущностями; представить модель в виде схемы данных и ER-диаграммы; проанализировать модель с учётом информационных потребностей пользователей; создать спроектированную БД в среде Delphi; разработать приложения реализации запросов и решения задач; реализовать возможность сортировки и поиска; представить несколько отчетов и диаграмм.
1. КОНЦЕПТУАЛЬНАЯ МОДЕЛЬ БАЗЫ ДАННЫХ «ЧЕМПИОНАТ АВТО»
1.1 Основные понятия
При разработке базы данных мы будем пользоваться следующими понятиями:
Сущность
–
личности, факты, объекты реального мира, имеющие отношение к некоторой проблемной области.
Атрибут
– это информационное отображение свойств объекта. При реализации информационной модели на каком-либо носителе информации, атрибут часто называют элементом данных, полем данных или просто полем.
Экземпляр сущности
– это один набор значений его элементов данных.
Домен
– семантическое понятие, которое можно рассматривать как подмножество значений некоторого типа данных, имеющих определенный смысл.
Связь
- это функциональная зависимость между сущностями.
Концептуальная модель
- представляет интегрированные концептуальные требования всех пользователей к базе данных данной предметной области.
1.2 Описание предметной области
В данном подразделе дается краткое описание предметной области, в которой функционирует система «Чемпионат авто». Описываются среда функционирования, цели и задачи разработанной базы данных. При проектировании базы данных все усилия разработчика должны были направлены в основном на структуризацию данных и выявление взаимосвязей между ними. Проектирование схемы данных и ER-диаграммы основано на анализе решаемых в спортивном комплексе по обработке данных. Схема данных включает описания объектов и их взаимосвязей, представляющих интерес в рассматриваемой предметной области и выявляемых в результате анализа данных.
Все чемпионаты по автогонкам, проводимые в отдельном городе, информация об участниках, спонсорах, мастерах по ремонту и т.д. хранится в базе данных «Чемпионат авто». Также в данной системе регистрируются все результаты заездов для каждого гонщика, в том числе время, место, и название чемпионата. Существует возможность редактирования информации. К данным возможностям относятся добавление, удаление и изменение записей. Кроме того в данной базе данных хранится информация, не только о чемпионатах, но и о гонщиках, мастерах автомастерской и автомобилях, участвующих в гонках. Данная информация также может удаляться, добавляться, редактироваться.
1.3 Каталог задач
Основываясь на описании предметной области, определим круг запросов и задач, которые предполагается решать с использованием базы данных «Чемпионат авто».
Задачи:
· сведения о гонщиках;
· сведения о автомобилях;
· сведения о чемпионатах;
· сведения о работающем персонале;
· сведения о спонсорах;
· имеющиеся сроки ремонте автомобилей;
· информация о местах проведения чемпионатов;
· список заездов, время и место участников
Вследствие большого объема информации хранящегося в базе данных пользователь должен иметь быстрый доступ к интересующим ему данным. Простой и понятный интерфейс позволяет ускорить работу с базой.
1.4 Описание таблиц
1) Мастерская
| *
ID мастерской |
idmaster | + |
| Автомобиль | avtomast | S |
| Стоимость Ремонта | stoim | I |
| Дата Окончания Ремонта | daterem | D |
| Номер Бокса | nbox | I |
| Фамилия Мастера | familmast | S |
2)Работники Мастерской
| *
ID мастера |
idworker | + |
| Фамилия | familwork | S |
| Имя | namework | S |
| Отчество | fathwork | S |
| Дата Рождения | datework | D |
| Стаж | stag | I |
3)Cписок Автомобилей
| * Марка
|
CodeWork | + |
| Модель | model | S |
| Год Выпуска | yearvyp | I |
| Пробег | probeg | I |
| Цвет | color | S |
| IDмастерской | idmast | I |
4)УчастникиЧемпионата
| *
ID участника |
iduch | + |
| Автомобиль | avto | I |
| Гонщик | racer | S |
| Результат | result | I |
| IDгонщика | idracer | I |
база данный реляционный модель
5)Гонщики
| *
ID гонщика |
idracer | + |
| Фамилия | familracer | S |
| Имя | nameraser | S |
| Отчество | fathracer | S |
| Дата Рождения | dateracer | D |
| Количество Участий | kolvo | I |
| Наличие Приз Мест | priz | B |
6)Результаты Заезда
| *
ID результата |
idresult | + |
| Чемпионат | champ | I |
| Время | time | I |
| Место | mesto | I |
7)Чемпионаты
| *
ID чемпионата |
idchamp | + |
| Название Чемпионата | nazchamp | S |
| Спонсор Чемпионата | sponschamp | I |
| Место Проведения | mestochamp | I |
| Год Проведения | yearchamp | D |
8)Спонсоры
| *
ID спонсора |
idspons | + |
| Спонсор | sponsor | S |
| Вознаграждение Спонсора | voznagr | I |
| IDчемпионата | idchamp | I |
9)Место Проведения
| *
ID места |
idmesta | + |
| Название Места | nazmesta | S |
| Тип Трассы | tiproad | S |
| IDчемпионата | idchamp | I |
1.5 Схема данных
1.6
ER-
диаграмма
2. РЕЛЯЦИОННАЯ МОДЕЛЬ БАЗЫ ДАННЫХ «ЧЕМПИОНАТ АВТО»
2.1 Выбор логической модели
Хранимые в базе данные имеют определённую логическую структуру, то есть модель. Различают следующие основные модели представления данных в базе данных:
- иерархическую
- сетевую
- реляционную
- объектно-ориентированную
В иерархической
модели данные представляются в виде древовидной иерархической структуры. Достоинством данной модели является возможность реализовать очень быстрый поиск, когда условия запроса соответствуют иерархии в схеме БД, однако при работе с данными со сложными логическими связями иерархическая модель оказывается слишком громоздкой.
В сетевой
модели данные организуются в виде произвольного графа. Достоинством этой модели является высокая скорость поиска и возможность адекватно представлять данные для решения множества задач в самых различных предметных областях. Высокая скорость поиска основывается на классическом способе реализации сетевой модели - на основе списков. Недостатком сетевой модели является жесткость структуры и высокая сложность ее организации.
Кроме того, существенным недостатком иерархической и сетевой моделей является то, что структура данных задается на этапе проектирования БД и не может быть изменена при организации доступа к данным.
Реляционная
модель получила свое название от английского термина relation (отношение) и была предложена в 1970-х годах сотрудником фирмы IBM Эдгаром Коддом. Реляционная БД представляет собой совокупность таблиц, связанных отношениями. Разница между таблицей в привычном смысле и понятием отношения заключается в том, что в отношении нет порядка - это неупорядоченное множество записей. Порядок определяется не отношением, а конкретной выборкой из отношения. Связь между таблицами существует на логическом уровне и определяется предметной областью. Практически связь между таблицами устанавливается путем использования логически связанных данных в разных таблицах.
Для работы с реляционными СУБД используется стандартизированный язык структурированных запросов SQL.
Достоинствами реляционной модели данных являются простот
К недостаткам можно отнести атомарность, ограниченность и предопределенность набора возможных типов данных. Это затрудняет использование реляционных моделей для некоторых современных приложений. Названная проблема решается расширением реляционных моделей в объектно-реляционные.
В объектно-реляционной
модели отдельные записи база данных представляются в виде объектов. Между записями базы данных и функциями их обработки устанавливаются взаимосвязи с помощью механизмов, подобных соответствующим средствам в объектно-ориентированных языках программирования. Объектно-ориентированные модели сочетают особенности сетевой и реляционной моделей и используются для создания крупных БД со сложными структурами данных.
Перейти к иерархической модели данных сложно, ввиду сложности реализации сложных связей через древовидные структуры (хотя реализация части сущностей и связей иерархии через данную логическую модель достаточно просто). Гораздо больше подходит сетевая модель данных, однако мы выбираем реляционную модель, потому что :
· представление данных в виде двухмерных таблиц проще, чем виде списков;
· реляционная модель проста, обладает гибкой структурой, удобна для реализации на компьютере.
· 2.2 Основные понятия
Реляционная модель данных
– это представление данных в виде совокупности двумерных таблиц:
1)
каждый элемент таблицы представляет собой один элемент данных, т.е. список не может быть значением;
2)
все столбцы в таблице однородные, т.е. элементы столбца одной природы;
3)
столбцам однозначно присвоены имена;
4)
в таблице нет двух одинаковых строк;
5)
строки и столбцы таблиц могут просматриваться в любом порядке, без учета их содержания и смысла.
Для математического описания реляционной модели нам понадобятся следующие понятия
Атомарные данные
– это наименьшие единицы данных неразложимые с точки зрения модели.
Домен
– это множество атомарных значений одного и того же типа.
Атрибут
– это некоторое подмножество домена, имеющее уникальное имя.
Отношение
на доменах D1
, D2
, ..Dn
состоит из заголовка и тела.
R (A1
, A2
, ..An
) ÍD1
´D2
´D3
Заголовок
состоит из такого фиксированного множества атрибутов
А1
, A2,
..An
, что существует отношение между атрибутами и их доменами.
Тело
состоит из меняющихся во времени множества кортежей.
Кортеж
состоит из значений каждого атрибута по одному значению на атрибут.
Таблица в реляционной теории соответствует отношению.
Строке соответствует кортеж.
Столбцу – атрибут.
Введем понятие ключа отношения.
Пусть А – множество атрибутов отношения
А = {A1
, A2
,..An
} и пусть k – это подмножество А
kÍA
Возможным ключом отношения R является такое подмножество k, которое удовлетворяет следующему условию:
1)
в произвольный момент времени никакие два различных картежа не имеют одного и того же значения для k
2)
ни один из атрибутов не может быть исключен из k без нарушения первого условия.
2.3 Проектирование реляционной модели
Существует два основных метода проектирования реляционной модели:
1.
метод декомпозиции (используется при количестве ключевых атрибутов не более 20);
2.
на основе концептуальной модели.
Так как концептуальная модель уже построена, то воспользуемся вторым методом
. Для этого выполним нормализацию отношений.
2.3.1 Нормализация отношений
Очевидно, что качество разработанной базы данных всецело зависит от качества выполнения отдельных этапов её проектирования. Огромное значение имеет качественная разработка логической модели базы данных, так как она, с одной стороны, обеспечивает адекватность базы данных предметной области, а с другой стороны, определяет структуру физической базы данных и, следовательно, её эксплуатационные характеристики. Одни и те же данные могут группироваться в таблицы-отношения, различными способами, то есть, возможна организация различных наборов отношений взаимосвязанных информационных объектов предметной области. Группировка атрибутов в отношениях должна быть рациональной, предельно сокращающей дублирование данных и упрощающей процедуры их обработки и обновления. Определенный набор отношений обладает лучшими свойствами при включении, модификации и удалении данных, если он отвечает определенным требованиям нормализации отношений.
Нормализация отношений
— это формальный аппарат ограничений на их формирование, который позволяет устранить дублирование данных, обеспечить их непротиворечивость и уменьшить затраты на поддержание базы данных.
Отношение называется нормализованным или приведенным к первой нормальной форме (1НФ)
, если все его атрибуты простые или атомарные – далее неделимые. Разработанная база данных «Чемпионат авто» соответствует данной НФ, а именно выполнены следующие требования:
-в отношении нет одинаковых кортежей;
-кортежи не упорядочены;
-атрибуты не упорядочены и различаются по наименованиям;
-все значения атрибутов атомарные.
Как видно из перечисленных свойств, любое отношение автоматически находится в первой нормальной форме. Чтобы рассмотреть вопрос приведения отношений ко второй нормальной форме, необходимо дать пояснение понятию функциональной зависимости
. Пусть имеется отношение R. Множество атрибутов Y функционально зависимо от множества атрибутов X, если для любого состояния отношения R для любых кортежей r1,r2 О R из того, что r1X = r2X следует, что r1Y = r2Y, то есть во всех кортежах, имеющих одинаковые значения атрибутов X, значения атрибутов Y также совпадают в любом состоянии отношения R.
Для разработанной базы данных выполнено и требование 2НФ. Множество атрибутов X называется детерминантом
функциональной зависимости, а множество атрибутов Y называется зависимой частью. Отношение находится во второй нормальной форме (2НФ)
, если оно находится в первой нормальной форме (1НФ) и нет не ключевых атрибутов, зависящих от части составного ключа.
Отношение находится в третьей нормальной форме (3НФ)
, если оно находится в 2НФ и все неключевые атрибуты взаимно независимы. Таким образом, разработку логической модели реляционной базы данных можно представить как определение отношений, отображающих понятия предметной области, и приведение их к третьей нормальной форме. Таким образом разработанная база данных полностью соответствует всем 3НФ, т.е. требование нормализации отношений выполнено, что представлено на схеме данных и ER- диаграмме.
2.3.2 Описание ключей
Первичный ключ уникально определяет отношение.
После выбора первичного ключа из набора потенциальных ключей, оставшиеся ключи называются альтернативными.
Пусть даны отношения R1
и R2
. Пусть k1
, - это первичный ключ отношения R1
.
Если в отношении R2
присутствуют атрибуты k1
, то для отношения R2
, k1
– это внешний ключ.
2.3.3 Правила целостности
Пусть даны отношения R1
и R2
. Пусть k1
, - это первичный ключ отношения R1
.
Если в отношении R2
присутствуют атрибуты k1
, то для отношения R2
, k1
– это внешний ключ. Если базовое отношение R2
содержит внешний ключ k1
, то каждое значение k1
в R2
должно быть либо равным какому-либо значению R1
, либо полностью неопределенным.
Рассмотрим математическое представление целостности данных
Целостность имеет место, так как первичные ключи всех отношений не принимают и не могут принимать неопределённые значения.
По описанным выше алгоритмам получаем реляционную модель
3. РЕАЛИЗАЦИЯ БАЗЫ ДАННЫХ «ЧЕМПИОНАТ АВТО»
Рассмотрим реализацию базы данных на одной таблице «Мастерская». На главной форме кнопки вызова соответствующих таблиц.
Событие для кнопки Мастерская:
procedure Tmainform.btnmasterskClick(Sender: TObject);
begin
masterform.Show;
end;
На форму соответствующую таблице Мастерская помещаем элементы: ADOConnection, ADOQuery, DataSource, ADODataSet, DBNavigator. При помощи этих элементов подключаем БД и отображаем её в DBGrid. Затем добавляем кнопки для добавления, удаления, редактирования записей и соответствующие поля для ввода данных.
Событиедлякнопки «Добавить»:
procedure Tmasterform.btnaddmastClick(Sender: TObject);
begin
qrymaster.SQL.Clear;
try
qrymaster.SQL.Add('INSERT INTO Мастерская');
qrymaster.SQL.Add('( ID, Автомобиль, СтоимостьРемонта,
ДатаОкончанияРемонта, НомерБокса, ФамилияМастера) VALUES');
qrymaster.SQL.Add('( :IDmast, :Avtomast, :Stoimmast, :Datemast,
:Boxmast, :Fammast)');
qrymaster.Parameters.ParamByName('IDmast').Value:=edtidmast.Text;
qrymaster.Parameters.ParamByName('Avtomast').Value:=edtavtomast.Text;
qrymaster.Parameters.ParamByName('Stoimmast').Value:=edtstoimmast.Te
xt;
qrymaster.Parameters.ParamByName('Datemast').Value:=edtdatemast.Text;
qrymaster.Parameters.ParamByName('Boxmast').Value:=edtboxmast.Text;
qrymaster.Parameters.ParamByName('Fammast').Value:=edtfammaster.Text
;
qrymaster.ExecSQL;
ShowMessage('Добавлено!');
except
ShowMessage('Ошибка!');
end;
end;
Событие для кнопки «Удалить»:
procedure Tmasterform.btndellmastClick(Sender: TObject);
begin
dbnvgrmaster.BtnClick(nbDelete);
end;
Событиедлякнопки «Выделить»:
procedure Tmasterform.btnpastemastClick(Sender: TObject);
begin
masterform.edtidmast.Text:=dbgrdmaster.Fields[0].AsString;
masterform.edtavtomast.Text:=dbgrdmaster.Fields[1].AsString;
masterform.edtstoimmast.Text:=dbgrdmaster.Fields[2].AsString;
masterform.edtdatemast.Text:=dbgrdmaster.Fields[3].AsString;
masterform.edtboxmast.Text:=dbgrdmaster.Fields[4].AsString;
masterform.edtfammaster.Text:=dbgrdmaster.Fields[5].AsString;
end;
Событие для кнопки «Изменить»:
procedure Tmasterform.btneditmastClick(Sender: TObject);
begin
btndellmast.Click;
btnaddmast.Click;
end;
Примечание: прежде чем нажимать кнопку «Изменить» нужно сначала выделить значения в поля для редактирования и изменить необходимые значения.
Для замены в DBGrid уникальных номеров мастеров на фамилии используется следующее:
procedure Tmasterform.FormCreate(Sender: TObject);
begin
qrymaster.SQL.add('SELECT
IDмастера,РаботникиМастерской.[Фамилия] AS ФИО FROM
РаботникиМастерской ORDERBY РаботникиМастерской.Фамилия');
dbgrdmaster.Columns[5].PickList.Add('ФИО');
end;
Результат работы базы данных «Чемпионат авто»
Мы реализовали базу данных всех чемпионатов отдельного города. В базе данных храниться полный перечень всех проводимых чемпионатов. Также в базе данных «Чемпионат авто» ведется учет о сотрудниках мастерской, гонщиках и автомобилях. Существует возможность редактирования содержащейся информации. К данным возможностям относятся добавление, удаление и изменение записей.
Кроме того, посредством простого интерфейса база данных всегда может предоставить любую интересующую информацию, вплоть до даты окончания ремонта автомобиля в мастерской. Также в базе хранятся и легко редактируются данные о спонсорах, местах проведения заездов и соответственно результаты всех участников.
База данных «Чемпионат авто» полностью закончена и работоспособна