Физическое проектирование базы данных



ПРИМЕР ВЫПОЛНЕНИЯ ПРОЕКТА

Постановка задачи

Разработать приложение учета посещаемости занятий студентами в течение семестра. Учет посещаемости ведется по следующим критериям: фамилия, имя и отчество студента, группа, факультет, дата, количество часов пропусков за дату, причина пропусков (уваж., неуваж.).

Разработать и использовать собственную иерархию классов, расширение базовых классов, предоставляемых JDK.

Реализовать не менее 2-х паттернов проектирования.

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


Логическое проектирование структуры базы данных

Для логического проектирования структуры базы данных возможно использование одной из нескольких стратегий проектирования:

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

2) Концепция модели «сущность-связь». Начинается этот подход с разработки моделей данных, которые содержат несколько высокоуровневых сущностей и связей, затем работа продолжается в виде серии нисходящих уточнений низкоуровневых сущностей, связей и относящихся к ним атрибутов.

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

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

 Воспользуемся «смешанной» стратегией проектирования.

На первом этапе выделим сущности и опишем их реквизитный состав, на втором – сформируем отношения, уточним количество этих отношений и их атрибутный состав. Затем проверим отношения на соответствие 3 НФ.

a. Выделение сущностей и описание их реквизитного состава.

В задаче учета посещаемости можно выделить следующие сущности:

Сущность «Студент», которая характеризуется реквизитами: фамилия, имя, отчество студента.

Сущность «Группа», которая характеризуется реквизитом: группа.

Сущность «Факультет», которая характеризуется реквизитом: наименование факультета.

Сущность «Пропуск», которая характеризуется реквизитами: дата, количество часов, причина, фамилия, имя, отчество, группа.

b. Подготовка к применению ER-метода логического проектирования.

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

выделены все сущности, информация о которых должна содержаться в искомой БД;

определены основные атрибуты для каждой сущности;

назначен ключевой атрибут для каждой сущности;

сформулированы связи между выделенными сущностями.

Итак, для применения ER-метода назначим ключевые атрибуты для каждой сущности и сформулируем связи между выделенными сущностями:

Студент (КодСтудента, Фамилия, Имя, Отчество);

Факультет (КодФакультета, Факультет);

Группа (КодГруппы, Группа);

Пропуск (Дата, Количество часов, Причина, Фамилия, Имя, Отчество, Группа).

Сущности «Студент» и «Группа» соотносятся с помощью связи Учится.

Сущность «Группа» и сущность «Факультет» соотносятся с помощью связи Относится.

Сущности «Студент» и «Пропуск» соотносятся с помощью связи Имеет.

c. Использование ER-метода логического проектирования.

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

Построим ER-диаграмму для проектируемой задачи (рис. 2.1).

 

 

 

 
Рисунок 2.1. –Диаграмма ER -типа проектируемой базы данных

 

 


На основании правила 4 генерации отношений (см. Приложение А) связь Учится порождает два отношения по одному для каждой сущности, причем ключевой атрибут КодГруппы сущности Группа должен быть включен в число атрибутов отношения Студент. Получаем следующие отношения:

Студент (КодСтудента, Фамилия, Имя, Отчество, Код Группы);

Группа (КодГруппы, Группа).

На основании правила 4 генерации отношений связь Относится  порождает два отношения по одному для каждой сущности, причем ключевой атрибут КодФакультета сущности Факультет должен быть включен в число атрибутов отношения Группа. Таким образом,получаем следующие отношения:

Группа (КодГруппы, Группа, КодФакультета);

Факультет (КодФакультета, Факультет).

На основании правила 4 генерации отношений связь Имеет порождает два отношения по одному для каждой сущности, причем ключевой атрибут КодСтудента сущности Студент должен быть включен в число атрибутов отношения Пропуск. После включения атрибута КодСтудента наличие атрибутов Фамилия, Имя, Отчество, Группа в отношении Пропуск становится избыточным, т. к. значения указанных атрибутов однозначно определяются значением атрибута КодСтудента. В итоге,получаем следующие отношения:

Студент (КодСтудента, Фамилия, Имя, Отчество, Код Группы);

Пропуск (Дата, КодСтудента, Количество, Причина);

Таким образом, искомая БД состоит из четырех отношений:

Студент (КодСтудента, Фамилия, Имя, Отчество, Код Группы);

Группа (КодГруппы, Группа, КодФакультета);

Факультет (КодФакультета, Факультет);

Пропуск (Дата, КодСтудента, Количество, Причина).

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

У таблицы Пропуски первичный ключ — составной, он состоит из двух полей Дата и КодСтудента. Эти два поля вместе однозначно определяют пропуск студента.

Все получившиеся таблицы удовлетворяют требованиям 3НФ (см. Приложение Б). Эта степень нормализации вполне достаточна для разрабатываемой базы данных, поэтому будем считать, что процесс проектирования заданной БД завершен.


Физическое проектирование базы данных

3.1 Опишем структуру таблиц, полученных в ходе логического проектирования, в применении к конкретной СУБД (СУБД MySQL).

Таблица 3.1 – Структура таблиц базы данных


Дата добавления: 2022-12-03; просмотров: 19; Мы поможем в написании вашей работы!

Поделиться с друзьями:






Мы поможем в написании ваших работ!