Смекни!
smekni.com

База данных "Чемпионат авто" (стр. 2 из 3)

Для работы с реляционными СУБД используется стандартизированный язык структурированных запросов 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;

Событиедлякнопки «Выделить»: