Створення журналу відвідуваності занять

Національний університет внутрішніх справ

Факультет управління та інформатики

Кафедра інформаційних систем та технологій у діяльності ОВС

з дисципліни: Організація баз даних та знань

Створення журналу відвідуваності занять

студенти гр. 418-к

Баришанська А.Л., Вакула Т.А.

доц. кав. ІСІТ в ОВС

пп-до міліції Танянський С.С.

1. Аналіз предметної галузі

Обмеження ведення бази даних

2. Проектування структури бази даних

Визначення функціональних залежностей

Розробка структури бази даних.

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

3. Організація ведення бази даних

Висновок

Для побудови БД використовуватимемо СУБД Access, яка є легкою для самостійного освоєння, зручною для створення структури таблиць та визначення властивостей атрибутів. Діалогове середовище СУБД дає можливість користувачеві практично без використання мови програмування встановлювати різні види підтримки цілісності даних.

Поняття структура фізичної БД включає: формат фізичного запису, кластери записів, методи розміщення та доступу до фізичних записів.

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

1. Аналіз предметної області

1.1 Опис задачі

Необхідно створити БД, яка зберігає журнал відвідуваності занять. Як елементи даних у БД повинна міститися така інформація:

Тип занять (лекція, практика, л/р);

Предмет (БД, Інформатика);

Викладач (Танянський, Горєлов, Струков, Лановий);

Дата проведення занять

Ознака відвідуваності занять студентами (була, не була)

В результаті аналізу предметної області виділимо в якості первинного ключа атрибути ПРЕДМЕТ, Викладач, ТИП ЗАНЯТТЯ, так як з кожного предмета один і той же тип занять повинен вести один викладач, кожен викладач відноситься тільки до однієї кафедри. Прізвище, Ім'я, По-батькові також виділимо у вигляді ключа, тому що не може бути повних однофамільців.

Таким чином, база даних, отримана на підставі заданих атрибутів, матиме схему, представлену на малюнку 1, де підкреслені атрибути є первинним ключем.

Тип занятьПредметВикладачТип занятьПрізвищеІм'яПо батьковіДатаОзнака

Малюнок 1. Схема БД журналу відвідуваності занять.

1.2 Обмеження ведення бази даних

У процесі ведення БД необхідно підтримувати відповідність (цілісність) між введеними даними на основі вимог, обумовлених предметною областю.

Для розглянутого завдання визначимо відповідність між атрибутами:

1. Тип занять та предмет визначає викладача;

2. Викладач визначає кафедру;

3. ПІБ, дата, предмет, тип занять визначають ознаку відвідуваності;

ТакимТаким чином, кожен тип занять з одного предмета має вести один викладач. Викладач відноситься до однієї кафедри. Якщо студент у певний час був на певному предметі, то він не міг не бути, він був. Подібно підтримка відповідностей має бути реалізована для кожного заданого обмеження.

Крім цього, зберігання даних в одній таблиці при заданих обмеженнях є надмірною.

Так, наприклад, прізвища будуть повторюватися стільки разів, скільки цей студент відвідував предмети, дата буде повторюватися стільки разів, скільки в даний день було проведено занять, предмети будуть повторюватися залежно від типу занять.

Структура БД, що складається з однієї таблиці, як представлена ​​малюнку 1, це не дає можливість зберігати все дані.

1.3 Постановка задачі

Проведений аналіз предметної області показав, що ведення даних в одній таблиці не відповідає деяким вимогам до реляційних БД з причин, описаних у попередньому розділі.

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

Наприклад, інформація про викладача (ПІБ, кафедра), про завантаження викладача (тип занять, предмет, викладач), та про ознаку відвідуваності (тип занять, предмет, ПІБ, дата, ознака). При цьому БД повинна бути цілісною системою, тобто користувач повинен мати можливість у будь-який момент часу отримати всю (будь-яку) інформацію, яка зберігається в БД.

2. Проектування структури бази даних.

база дана аccess журнал

2.1 Визначення функціональних залежностей

На підставі розглянутих вимог до БД (розділ 1.2) тапоставленої задачі (розділ 1.3) формалізуємо обмеження на дані у вигляді функціональних залежностей.

1. Тип занять, предмет®Викладач

2. Предмет®Кафедра

3. ПІБ, дата, предмет, тип занять®Ознака відвідуваності

2.2 Розробка структури бази даних

Для виключення можливих аномалій, описаних у розділі 1.2, необхідно нормалізувати БД, тобто привести її до нормальної форми. Задані обмеження у вигляді функціональних залежностей (розділ 2.1) дозволяють побудувати третю нормальну форму (3НФ), яка усуне небажані властивості ведення БД.

Очевидно, що представлений набір атрибутів (рисунок 1) відповідає першій нормальній формі (1НФ). Скористаємося визначенням повної функціональної залежності [1,2] та побудуємо другу нормальну форму (2НФ).

Таким чином, БД матиме вигляд, представлений на малюнку 2.

Таблиця 2 Таблиця 1 Таблиця 3

1
ВикладачТип занять1 ¥Тип занять
Кафедра¥Предмет1 ¥Предмет
ВикладачПрізвище
Ім'я
По батькові
Дата
Ознака

Малюнок 2. Структура БД у 2НФ.

При цьому функціональні залежності відповідатимуть таблицям, таким чином:

1.таблиці 1відповідають функціональні залежності

Тип занять, предмет®Викладач

2.таблиці 2відповідають функціональні залежності

3.таблиці 3відповідають функціональні залежності

- ПІБ, дата, предмет, типзанять®Ознака відвідуваності

Ключові атрибути отриманих таблицях визначені з урахуванням заданих функціональних залежностей між атрибутами. При цьому тип зв'язку між усіма таблицями відповідає «один до багатьох», оскільки зв'язкові атрибути в одній таблиці є первинним ключем, а в іншій немає.

Для схеми БД визначимо властивості кожної таблиці (рисунок 3).