Створення інфологічної моделі бази даних - студопедія

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

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

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

Побудова БД включає в себе наступні етапи моделювання:

1. Створення інформаційно-логічної моделі БД.

2. Створення даталогіческой моделі.

3. Створення фізичної моделі.

Инфологическая модель БД - це модель, іноді простіше звана інформаційної, що описує структури БД в загальних, не пов'язаних з будь-якої конкретної СУБД поняттях. Найчастіше для такого опису використовується так звана ER-діаграма, або, інакше, модель "сутність - зв'язок", що описує БД за допомогою понять сутності. зв'язків і посилальної цілісності.

Сутність - об'єкт, що характеризує будь-яку сторону описуваного явища, що володіє відносною самостійністю, опис якого (інформація про який) повинна зберігатися на носіях (в постійній пам'яті). Суті описуються атрибутами - пойменованими характеристиками, визначальними яка інформація повинна бути відображена в ній. Найменування атрибута повинно бути унікальним для конкретного типу сутності, але може бути однаковим для різних сутностей. Кожен представник суті називається її екземпляром.

Для нашої задачі відносну самостійність мають такі групи даних, які ми і виділимо в якості сутностей і визначимо їх атрибутами:

- ВИКЛАДАЧІ (Прізвище, Ім'я, По батькові)

- ДИСЦИПЛІНИ (Назва, Вид Заняття, Викладач)

- ГРУПИ (Номер, Кількість студентів, Спеціалізація)

- СТУДЕНТИ (Прізвище, Ім'я, По батькові)

- ЗАНЯТТЯ (Дисципліна, Дата, Номер пари)

- Пропуску (Заняття, Студент)

- УСПІШНІСТЬ (Студент, Результат)

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

Зв'язки визначають або взаємозалежність і взаємодія сутностей всередині БД. Зв'язки описуються за допомогою своїх атрибутів, таких як ім'я. ступінь ( "один до одного", "один до багатьох", "багато до одного" і "багато до багатьох") і ознаки обов'язковості.

Так, по одній дисципліні проводитися багато занять і, тому зв'язок між сутностями ДИСЦИПЛІНИ і ЗАНЯТТЯ повинна бути "один до багатьох" з ознакою обов'язковості на стороні сутності ДИСЦИПЛІНИ (для кожного заняття обов'язково повинна існувати дисципліна, за якою воно було проведено) і необов'язковість на стороні суті зАНЯТТЯ (наявність тієї чи іншої дисципліни не гарантує, що по ній вже були проведені заняття). Ознака обов'язковості на стороні "багато" і необов'язковість на стороні "один", як правило, завжди відповідає зв'язкам "один до багатьох".

Ознаки обов'язково зв'язків між сутностями описуються умовами посилальної цілісності. разрешающими чи ні існування інформації про будь-якому екземплярі в першій суті за відсутності такої в пов'язаної сутності. Умови посилальної цілісності перевіряються засобами СУБД при виконанні наступних операцій:

1) додаванні нових екземплярів. Наприклад: додавання нової групи нічим не обмежується, але нового студента можна ввести тільки для існуючої групи;

2) видаленні примірників з сутностей. Наприклад: видалення пропусків студента не обмежена, але видалення студента має видалити всі пов'язаних з ним пропусків занять;

3) оновленні примірників. Наприклад: редагування номера групи по суті ГРУПИ повинно привести до відповідної зміни даних для всіх студентів цієї групи, зміна номера групи для студентів має спричинити перевірку існування такого номера, і, в разі відсутності такого, заборонити зміну.

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

Але в нашому випадку, для однозначного визначення викладача навіть повного набору певних для нього атрибутів (прізвище, ім'я, по батькові, якого читають предмет) може виявитися мало, тому що взагалі кажучи, можна уявити ситуацію, коли в одній групі заняття по одному і тому ж предмету ведуть двоє людей з однаковими іменами, прізвищами і по батькові. Тим більше що побудова для кожного викладача такого великого ключового висловлювання, яке до того ж має бути продубльовано для кожного відповідного примірника сутності ЗАНЯТТЯ, практично дуже складно. Тому в таких випадках поступають таким чином: по суті ВИКЛАДАЧІ і ЗАНЯТТЯ додається по додатковому атрибуту, який однозначно ідентифікує кожного викладача, наприклад, деякий унікальний номер - код.

Аналогічно, розглянемо інші зв'язку і остаточно отримаємо наступну інфологічну модель:

- ВИКЛАДАЧІ (КодПреподавателя, Прізвище, Ім'я, По батькові);

- ГРУПИ (Група, Кількість, Спеціалізація);

- СТУДЕНТИ (КодСтудента, Група, Прізвище, Ім'я, По батькові);

- Дисципліна (КодДісціпліни, Дисципліна, Група, ВідЗанятій, Часів, ВсегоЧасов, ЧіслоСеместров, КодПреподавателя);

- КОНТРОЛЬ (КодКонтроля, КодДісціпліни, Контроль);

- УСПІШНІСТЬ (КодУспеваемості, КодКонтроля, КодСтудента, Результат);

- ЗАНЯТТЯ (КодЗанятія, КодДісціпліни, Дата, Пара);

- Пропуску (КодПропуска, КодЗанятія, КодСтудента).

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

• в кожній таблиці повинен бути ключ, однозначно характеризує кожну запис;

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

На зв'язку, при необхідності, можуть бути накладені умови посилальної цілісності: каскадне видалення і \ або оновлення - видалення або оновлення в таблиці, що знаходиться на стороні "багато" (підпорядкованої таблиці), всіх записів, які збігаються за значенням поля з відповідним ключовим полем в таблиці , що знаходиться на стороні "один" (головній таблиці), при видаленні всієї записи або зміні цього ключового поля.

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

Схожі статті