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

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

Согласно теории реляционных баз данных, в качестве первичного ключа должны выбираться одно или несколько полей, уникальных в своей совокупности. Для отношения «Годы» таковым очевидно будет атрибут «год». Для отношений «Турниры» – атрибут «тур», а для «Результаты» – атрибут «команда» (для краткости имена отношений сокращены до ключевого слова: «Предварительные турниры» – просто «Турниры» и т. п.).

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

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

Рисунок 4 – Функциональные зависимости (показаны стрелкой) между ключами и атрибутами отношений «Турниры» (а) и «Результаты» (б)

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

Для полной картины определимся с типами данных атрибутов отношений. Результаты представлены в таблицах 1, 2 и 3 ключевые поля выделены полужирным шрифтом).

Таблица 1 – Отношение «Годы»

Атрибут	тип данных
год чемпионата	числовой целый

Таблица 2 – Отношение «Турниры»

Атрибут	тип данных
тур	числовой целый
год чемпионата	числовой целый

Таблица 3 – Отношение «Результаты»

Атрибут	тип данных
команда
тур	числовой целый
забито	числовой целый
пропущено	числовой целый

Руководствуясь результатами проведённых исследований, построим даталогическую модель базы данных (рисунок 5).

Рисунок 5 – Даталогическая модель (PK – первичный ключ, FK – внешний ключ)

3 Практическая реализация базы данных

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

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

Данные требования диктуют выбор в качестве среды разработки и функционирования СУБД локального типа. На эту роль лучше всего подходит Microsoft Access. Его выбор объясняется широким распространением на территории Российской Федерации и стран СНГ. Access последних версий предоставляет пользователю обширный инструментарий создания локальных баз данных и приложений для работы с ними. А так же даёт возможность подключения других баз данных, включая сетевые, работающие на платформе клиент-сервер (Oracle, Microsoft SQL Server, Firebird, MySQL) с помощью технологий доступа данных ODBC, OLE DB и моделей доступа ADO, ADO .NET. Кроме того, имеется механизм, позволяющий конвертировать базы данных Access в базы данных SQL Server с поддержкой технологии OLE DB. Данный сервис позволит в дальнейшем конвертировать локальную базу данных в сетевую базу для СУБД SQL Server в случае перехода на клиент-серверную платформу.