Проектування реляційної моделі даних

Багатотабличного модель даних. Перейдемо до наступного етапу розробки інформаційної системи “Класний журнал”. Тепер від інфологічної моделі системи нам потрібно перейти до реляційної моделі даних. Для цього потрібно:

– описати відносини, що визначають структури таблиць бази даних;

– визначити основні ключі;

– реалізувати зв’язку між таблицями.

Якщо в якості імен відносин (таблиць) прийняти імена сутностей ER-діаграми на рис. 1.11, а в якості полів – атрибути сутностей, то отримаємо:

УЧНІ (прізвище, ім’я, ПОЛ, адреса, телефон)

ПРЕДМЕТИ (назви предметів, УЧИТЕЛЬ)

ОЦІНКИ (УЧЕНЬ, ПРЕДМЕТ, ДАТА, ОЦІНКА)

Визначимо первинні ключі таблиць. У таблиці УЧНІ доведеться вибрати складовою ключ ПРІЗВИЩЕ – I – ІМ’Я, оскільки тільки їх поєднання не повторюється в кожному записі. Але уявіть собі, що в класі є два повних тезки, наприклад дві Корольових Андрія. Як їх розрізняти? Вводити поле ОТЧЕСТВО? Але, по-перше, у шкільних журналах це робити не прийнято, по-друге, немає гарантії, що і по батькові не збіжиться. Вирішення цієї проблеми – впровадити спеціальні, унікальні ідентифікатори учнів (коди учнів). Найзручніше зробити їх цілими числами. Такий номер присвоюється учневі один раз – при занесенні запису в базу – і більше ніколи не змінюється.

У таблиці ПРЕДМЕТИ вибір ключа не викликає проблем. Очевидно, що ця назва предмета.

У таблиці ОЦІНКИ атрибут УЧЕНЬ повинен ідентифікувати конкретного учня. В якості такого ідентифікатора в таблиці УЧНІ тепер є поле НОМЕР УЧНЯ. Його і будемо використовувати замість атрибута УЧЕНЬ. А замість атрибута ПРЕДМЕТ будемо використовувати поле НАЗВАНІЕ_ПРЕДМЕТА. У таблиці ОЦІНКИ основний ключ буде складовим: номер_ УЧНЯ + НАЗВА ПРЕДМЕТА + ДАТА. Робиться припущення, що по одному предмету в один день в журнал учневі може бути виставлено не більше однієї оцінки.

У підсумку отримані наступні три відносини, що становлять модель даних:

УЧНІ (НОМЕР УЧНЯ, ПРІЗВИЩЕ, ІМ’Я, ПОЛ, АДРЕСА, ТЕЛЕФОН)

ПРЕДМЕТИ (назви предметів, УЧИТЕЛЬ)

ОЦІНКИ (НОМЕР УЧНЯ, НАЗВАНІЕ_ПРЕДМЕТА,

ДАТА, ОЦІНКА)

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

1. Якщо дві таблиці мають однакові первинні ключі, то між ними діє зв’язок “один-до-одного”.

2. Якщо первинної ключ першої таблиці є частиною складного ключа другої таблиці або неключових полем другої таблиці, то між першою і другою таблицями діє зв’язок “один-до-багатьох”.

У реляційних базах даних зв’язок “багато-до-багатьох” безпосередньо між двома таблицями не реалізується. Для її реалізації доводиться вводити додаткову зв’язує таблицю. Для нашого проекту такої проблеми немає.

На цьому етап проектування бази даних завершений, отримана реляційна модель даних. Її ще називають схемою даних. Наступний етап – створення бази даних на комп’ютері засобами СУБД.

Про нормалізацію даних. У теорії реляційних баз даних існує поняття нормальної форми організації даних. Отримана нами модель даних має властивості третій нормальній форми. Ставлення (таблиця) відповідає третій нормальній формі, якщо:

– всі поля таблиці – атомарні, т. Е. Далі не ділені;

– кожен неключових поле повністю функціонально залежить від первинного ключа;

– між полями таблиці немає транзитивних залежностей.

Щоб пояснити сенс цих умов, покажемо на прикладі нашого завдання, яким чином можна було здійснювати нормалізацію даних. Нехай спочатку ми вирішили зробити базу даних однотаблічной, т. Е. Зібрати всі поля в одній таблиці. Назвемо її УСПІШНІСТЬ:

УСПІШНІСТЬ (НОМЕР_УЧЕНІКА, НАЗВАНІЕ_ПРЕДМЕТА,

ДАТА, ОЦІНКА, УЧИТЕЛЬ, ПРІЗВИЩЕ, ІМ’Я, ПОЛ,

АДРЕСА, ТЕЛЕФОН)

Кожен запис такої таблиці відноситься до однієї оцінкою, отриманої конкретним учнем з даного предмету в конкретний день навчального року. У базі даних буде стільки записів, скільки оцінок варто в журналі. Ця модель задовольняє вимогам першої нормальної форми, згідно з якою всі поля повинні бути атомарними. Атомарну поле далі не ділиться. Наприклад, об’єднання в одне поле ПІБ прізвища, імені та по батькові людини порушує принцип атомарности. Поняття атомарности відносно. Наприклад, якщо в додатках не буде потрібно окремої обробки назви вулиці, номера будинку і квартири, то адресу можна не розбивати на складові і вважати його атомарним.

Вимога другої нормальної форми полягає в тому, щоб кожен неключових поле повністю функціонально залежало від первинного ключа. Функціональна залежність поля В від поля А (або групи полів) означає наступне: значення поля В однозначно визначається значенням поля А (або групи полів).

На малюнку 1.12 стрілками показані всі функціональні залежності полів у таблиці УСПІШНІСТЬ. Повністю від складеного первинного ключа залежить тільки поле ОЦІНКА. Поле УЧИТЕЛЬ функціонально залежить тільки від поля НАЗВАНІЕ_ ПРЕДМЕТА. Поля ПРІЗВИЩЕ, ІМ’Я, ПОЛ, АДРЕСА, ТЕЛЕФОН функціонально залежать від поля НОМЕР УЧНЯ. Розбивши таблицю УСПІШНІСТЬ на три таблиці: УЧНІ, ПРЕДМЕТИ, ОЦІНКИ, отримаємо в кожній з них повну функціональну залежність від основних ключів, що показано на рис. 1.13.

Транзитивної називається залежність між двома полями А і В через третє поле С: А -> С – “В. Таких залежностей ні в одній з трьох побудованих таблиць немає. Значить, отримані таблиці задовольняють вимогам третьої нормальної форми.


1 Star2 Stars3 Stars4 Stars5 Stars (2 votes, average: 3.00 out of 5)

Проектування реляційної моделі даних