Побудова реляційної схеми.

Практична робота №2.

Побудова реляційної схеми.

Мета роботи:

Отримання практичних навичок проектування баз даних за допомогою методу суть - зв'язок.

Побудова реляційної схеми БД "Сесія"

Мінімальний набір характеристик:

ФИО студента	Семестр	Дисциплина	Форма отчетности	Оценка	Коли­чество часов	ФИО преподавателя
Иванов В.П.		БД	зачет			Преподаватель 1
Иванов В.П.		БД	экзамен			Преподаватель 1
Иванов В.П.		ООП	экзамен			Преподаватель 2
Иванов В.П.		ООП	зачет			Преподаватель 2
Петрова В.П.		БД	зачет			Преподаватель 1
Петрова В.П.		БД	экзамен			Преподаватель 1
Петрова В.П.		ООП	экзамен			Преподаватель 2
Петрова В.П.		ООП	зачет			Преподаватель 2

Опис предметної області:

Нехай необхідно забезпечити збір і обробку даних за результатами здачі іспитів і заліків студентами факультету.

Організація даних повинна підтримувати:

- виконання поточного учбового плану;

- формування відомостей по окремих дисциплінах для груп студентів;

- формування листів залікових книжок студентів;

- формування звідної відомості курсу;

- розрахунок середнього балу по дисциплінах і тому подібне

Побудова ER - діаграми

Етапи проектування:

I. Виділення сутей і зв'язків між ними.

Кожний студент складає іспит або залік по деякій дисципліні учбового плану і отримує оцінку. Представимо предметну область як взаємодія двох сутностей - "Дисципліна учбового плану" і "Студент":

Виділення зв'язків:

СТУДЕНТ СДАЕТ ДИСЦИПЛИНА

Виділення сутностей:

СТУДЕНТ <ФИО, …>

ПІБ не може однозначно характеризувати екземпляр сутності, оскільки можна припускати наявність в одній групі повних тезків, тому введемо код студента КОДС.

СТУДЕНТ < КОДС, ФИО, …>

ДИСЦИПЛИНА УЧЕБНОГО ПЛАНА < Наименование, Семестр, Форма отчетности …>

II. Побудова діаграми ER -типа.

студент

Сдает

дисциплина

М

М

III. Формування набору попередніх таблиць з вказівкою передбачуваного первинного ключа.

Зв'язок ЗДАЄ. Тип зв'язку – М: М. Для цього виду зв'язку клас приналежності не має значення.

Застосуємо правило 6: сформуємо 3 таблиці.

СТУДЕНТ < КОДС, ФИО, …>

ДИСЦИПЛИНА УЧЕБНОГО ПЛАНА < Наим_дисц, Семестр, Форма отчетности …>

СДАЕТ < КОДС, Наим_дисц, Семестр, Форма отчетности, …>

IV. Додавання неключових атрибутів.

1. СТУДЕНТ < КОДС, ФИО, Номер группы, Домашний адрес, Телефон>

Властивість "Домашня адреса", будучи по суті складеним, розглядатиметься в контексті задачі як просте, а властивість "Номер телефону" - як умовне (може бути відсутнім).

2. ДИСЦИПЛИНА УЧЕБНОГО ПЛАНА < Наим_дисц, Семестр, Форма отчетности, Количество часов, Преподаватель>

3. СДАЕТ < КОДС, Наим_дисц, Семестр, Форма отчетности, Оценка, Дата сдачи>

Студент складає іспит (залік) по Дисципліні учбового плану і отримує оцінку.

V. Перевірка таблиць на відповідність вимогам III нормальної форми Бойса - Кодда.

a. Аналіз на відповідність 1НФ.

Усі сутності не мають груп властивостей, що повторюються.

b. Аналіз на відповідність 2НФ.

У сутності "Дисципліна учбового плану" властивість "Викладач" залежить тільки від частини ключових властивостей, - а саме від властивостей "Найменування дисципліни" і, можливо, "Форма звітності". Отже, необхідно выде-лить "Викладач" в окрему суть.

ПРЕПОДАВАТЕЛЬ <ФИО, должность, кафедра, Домашний адрес, Телефон>

Для забезпечення унікальності кожного екземпляра запису, введемо додаткову (ключову) властивість – код викладача.

ПРЕПОДАВАТЕЛЬ < КОДП, ФИО, должность, кафедра, Домашний адрес, Телефон>

Взаємодія нової суті з суттю "Дисципліна учбового плану" здійснюється за допомогою нового зв'язку "Читає".

Дисципліну учбового плану читає викладач.

Дисциплина

читает

преподаватель

М

М

Тепер необхідно повернутися назад до 3 пункту етапу проектування: формування набору попередніх таблиць з вказівкою передбачуваного первинного ключа.

ПРЕПОДАВАТЕЛЬ < КОДП, ФИО, должность, кафедра, Домашний адрес, Телефон>

ДИСЦИПЛИНА УЧЕБНОГО ПЛАНА < Наим_дисц, Семестр, Форма отчетности, Количество часов>

На підставі правила 6 отримаємо ще одну таблицю

ЧИТАЕТ < Наим_дисц, Семестр, Форма отчетности, КОДП >

Для ліквідації надмірності і потенційної суперечності даних додамо в таблицю "Учбовий план" стовпець КОДДУ, вміст якого буде однозначний ідентифікувати кожен рядок таблиці.

Назу СДАЕТ замінемо на СВОДНАЯ ВЕДОМОСТЬ.

Назву ЧИТАЕТ - на ДИСЦИПЛИНА_ПРЕПОДАВАТЕЛЬ

В результаті отримуємо наступні таблиці.

СТУДЕНТ < КОДС, ФИО, Номер группы, Домашний адрес, Телефон>

СВОДНАЯ ВЕДОМОСТЬ < КОДС, КОДП, Оценка, Дата сдачи>

ПРЕПОДАВАТЕЛЬ < КОДП, ФИО, должность, кафедра, Домашний адрес, Телефон>

ДИСЦИПЛИНА УЧЕБНОГО ПЛАНА < КОДДУ, Наим_дисц, Семестр, Форма отчетности,Количество часов>

ДИСЦИПЛИНА_ПРЕПОДАВАТЕЛЬ < КОДДУ, КОДП, >

Перевірка на відповідність нормальним формам

1НФ.

Усі побудовані таблиці знаходяться в першій нормальною формі, оскільки кожен стовпець таблиці неділимий і у рамках однієї таблиці немає стовпців з однаковими по сенсу значеннями.

2НФ.

Таблиця "Звідна відомість" через стовпці КОДС і КОДП зв'язує інформацію про студента з інформацією про конкретну дисципліну і фіксує оцінку, отриману студентом. Оцінка і дата складання іспиту (заліку) однозначно залежать від вмісту стовпців КОДС і КОДДУ, які є складеним первинним ключем. Таким чином, усі таблиці мають первинні ключі, які однозначно визначають рядки і ненадлишкові, і можна говорити про те, що таблиці знаходяться в другій нормальній формі.

3НФ.

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

Реляційна схема БД "Сесія":

КОДП,

ФИО,

должность,

кафедра,

Домашний адрес,

Телефон

Дисциплина_Препод

КОДДУ

КОДП,

Учебный план

КОДДУ,

Дисциплина

Семестр,

Форма отчетности,

Количество часов

Преподаватели

Сводная_ведомость

КОДС

КОДДУ

Оценка,

Дата сдачи

КОДС,

ФИО,

Номер группы,

Домашний адрес,

Телефон

Студенты

М

М

М

М

Дата добавления: 2015-11-04