Даталогічна модель

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

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

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

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

Одне з вимог — реляційна база даних повинна бути нормалізована. Процес нормалізації має своєю метою усунення надмірності даних і полягає в приведенні до третьої нормальної форми (або до нормальної форми Бойса-Кодда).

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

Аналіз предметної області звичайно здійснюється на підставі відомих відомостей про неї з урахуванням мет проектування програмної системи.

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

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

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

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

У термінах БД стовпці таблиці називаються полями, а її рядка - записами.

Нормалізація виконується поетапно. Перші три кроки були описані доктором Є.Ф. Коддом у статті "Подальша нормалізація реляційної моделі бази даних" в 1972 р.

Перша нормальна форма (1НФ). Для неї потрібно, щоб таблиця була плоскої й не містила повторюваних груп. У плоскої таблиці є тільки дві характеристики - довжина (кількість записів або рядків) і ширина (кількість полів або стовпців). Така таблиця не повинна містити гнізд, що включають кілька значень.

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

Друга нормальна форма (2НФ). Для 2НФ потрібно, щоб усі поля таблиці залежали від первинного ключа, тобто, щоб первинний ключ однозначно визначав запис і не був надлишковий.

У кожній таблиці БД може існувати первинний ключ - поле або набір полів, що однозначно ідентифікує запис.

Значення первинного ключа в таблиці БД повинне бути унікальним, тобто в таблиці не повинне існувати двох і більш записів з однаковим значенням первинного ключа.

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

Для третьої нормальної форми (ЗНФ) потрібно, щоб усі не ключові стовпці таблиці залежали від первинного ключа таблиці, але були незалежні друг від друга. Для цього потрібно, щоб таблиці були наведені до 1НФ і 2НФ.

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

Якщо у відношенні є багато функціональних залежностей, 4НФ не усуває надмірність, то застосовують п'яту нормальну форму (ЗНФ).

Розкладання відносин з 4НФ у п'яту нормальну форму повинне бути виконане так, щоб кожна проекція, отримана з 4НФ, містила не менш одного можливого ключа й хоча б один не ключовий атрибут з вихідного відношення. Для 5НФ потрібно, щоб можна було відновити вихідну таблицю на основі інформації таблиць, на які вона була розбита. Крім того, необхідно, щоб таблиці відповідали ЗНФ, а при наявності відносин " багато- до- багатьом" - 4НФ.

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

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

При заповненні особистої картки студента використовуються наступні документи: паспорт, трудова книжка, військовий квиток, документ про утвір. У підсумку одержали наступну реляційну схему, наведену до ЗНФ:

Адреса (Код, Індекс, Область_край, Населений пункт, Вулиця, Будинок, Телефон, Фізична особа)

Атестат (Код, Номер, Серія, Що закінчив, Рік закінчення, Фізична особа)

Вид документа (Код, Назва)

Вид іспиту (Код, Назва)

Вкладиш до диплома (Код, Номер, Серія, Університет, Факультет, Спеціальність, Рік закінчення, Фізична особа)

Виписка із зачіткі (Код, Університет, Факультет, Спеціальність, Рік вступу, Фізична особа)

Група (Код, Форма навчання, Спеціальність, Курс, Фізична особа)

Дисципліна (Код, Назва)

Документ (Код, Номер, Дата, Примітка, Вид документа, Група, Фізична особа)

Категорії (Код, Назва)

Курс (Код, Назва курсу, Номер курсу)

Національність (Код, Назва)

Підрозділ (Код, Назва, Власник)

Підрозділ навчає (Код, Підрозділ, Спеціальність)

Семестр (Код, Номер семестру, Назва семестру, Курс)

Семестрова відомість (Код, Фізична особа (студент), Дисципліна, Оцінка, Вид іспиту, Дата здачі, Фізична особа (викладач), Семестр)

Спеціальність (Код, Назва, Коротка назва)

Трудова книжка (Код, Останнє місце роботи, Фізична особа)

Фізичні особи (Код, Прізвище, Ім'я, По батькові, Рік народження, Категорія, Національність)

Фізична особа викладає (Код, Фізична особа, Дисципліна)

Форма навчання (Код, Назва)

Заявка (Код, Заявлене, Оплачене, Дата заявки, Фізична особа, Дисципліна).

Поиск по сайту: