Дійсність - любий розрізняючий об’єкт (об’єкт, який ми можемо відрізнити від іншого), інформацію про який треба зберігати в базі даних. Дійсністю можуть бути люди, місця, смак, колір та ін. Необхідно розрізняти такі поняття як тип дійсності та екземпляр дійсності. Поняття тип дійсності відноситься до набору однорідних особистостей, предметів, подій або ідей, виступаючих як єдине ціле. Екземпляр дійсності відноситься до певної речі в наборі. Наприклад, типом дійсності може бути ім’я, а атрибутом - Сергій, Марина та ін.
Атрибут - поіменована характеристика дійсності. Його ім’я повинно бути унікальне для певного типу дійсності, але може бути однаковим для різних типів дійсності. Атрибути використовуються для визначення того, яка інформація повинна бути зібрана про дійсність. Прикладами атрибутів для дійсності автомобіль є тип, марка, номерний знак, колір. Тут також існують різноманіття між типом та екземпляром. Тип атрибуту колір має багато екземплярів чи значень: червоний, синій, зелений та ін., однак кожному екземпляру дійсності привласнюється тільки одне значення атрибуту.
Абсолютна різниця між типами дійсності та атрибутами відсутня. Атрибут є таким тільки в зв’язку з типом дійсності. В іншому контексті атрибут може виступати як самостійна дійсність. Наприклад, для автомобільного заводу колір - тільки атрибут продукту виробництва, а для лакофарбуючої фабрики колір - тип дійсності.
Ключ - мінімальний набір атрибутів, за значеннями яких можна однозначно знайти потрібний екземпляр дійсності. Мінімальність означає, що виключення із набору будь - якого атрибуту не дозволяє ідентифікувати дійсність по тим, що залишились. Для дійсності розклад ключем є атрибут номер_рейсу та пункт призначення.
Зв’язок - асоціювання двох чи більше дійсностей. Якщо б призначенням бази даних було тільки зберігання відокремлених, не зв’язаних між собою даних, то її структура могла бути досить простою. Однак одне з основних вимагань до організації баз даних - це забезпечення можливості пошуку одних дійсностей за значеннями інших, для чого необхідно встановити між ними певні зв’язки. А так як в реальних базах даних нерідко міститься сотні чи навіть тисячі дійсностей, то теоретично між ними може бути встановлено більше мільйона зв’язків. Наявність такої множини зв’язків і визначає тяжкість інфологічних моделей.
Інфологічна модель являється початковим етапом в проектуванні баз даних, вона допомагає наявно представити роботу АРМ робітника бібліотеки та в подальшому побудувати таблиці та зв’язки між ними.
При створенні інфологічної моделі можна використовувати мову ER - діаграм, Microsoft Visio і т.д. АРМ працівника бібліотеки змодельований в Microsoft Visio (Рис.2.1).
Рис.2.1 Інфологічна модель БД бібліотечного фонду Тальнівського будівельно-економічного коледжу УДАУ
При розробці даталогічної моделі даних на основі аналізу функціональних залежностей між атрибутами відношень потрібно використовувати теорію нормалізації.
Нормалізація - це розбивка таблиці на двоє чи більше, що володіють кращими властивостями при включенні, зміні і видаленні даних. Остаточна мета нормалізації зводиться до одержання такого проекту бази даних, у якому кожен факт з’являється лише в одному місці, тобто виключена надмірність інформації. Це робиться не тільки з метою економії пам’яті, скільки для виключення можливої суперечності збережених даних.
По іншому процес нормалізації можна пояснити як декомпозиція початкового відношення на декілька простіших.
Правила декомпозиції:
Між атрибутами не повинно бути функціональної залежності.
Групування атрибутів не повинно супроводжуватися надмірним дублюванням даних.
Склад атрибутів повинен забезпечувати обробку та поновлення їх без ускладнень.
В даній базі даних „Бібліотека" використовуються такі зв’язки:
Один до одного (1:
1) - у кожен момент часу кожному екземпляру чи атрибуту об’єкта Х відповідає 1 чи 0 екземплярів чи атрибутів об’єкта Y.
Наприклад: У базі даних „Бібліотека" можна отримати анотацію про книгу тільки за кодом видання цієї книги. Атрибут Код видання є ключовим атрибутом обох об’єктів бази даних, Видання, Анотації.
Один до багатьох (1: ∞) - одному екземпляру об’єкта Х відповідає 0,1 чи декілька атрибутів об’єкта Y.
Цей зв’язок найпоширеніший в базі даних „Бібліотека", так як в основному це є база даних по обліку видань, які беруть в користування багато користувачів. Видання може бути в одному екземплярі, а може бути декілька.
Наприклад: Видавництво може видавати багато видань, різними мовами, різної теми та класифікації. Це є 1: ∞ об’єктів Видавництва, Видання. Такий зв’язок може мати об’єкт Назви, Вид видання (1) до Видання (∞). Так як одну назву може мати багато книг; вид видання (методичка, підручник довідник) зроблений з одного видання.
Багато до багатьох (∞: ∞). Даний зв’язок розшифровується як такий зв’язок, що створюється ще додатковий об’єкт, який називається асоціативним. Асоціативний зв’язок виникає при формалізації багато до багатьох.
Аналіз визначених вище об’єктів і атрибутів дозволяє виділити об’єкти проектованої бази даних і, прийнявши рішення про створення реляційної бази даних, побудувати її даталогічну модель мовою „Таблиці-зв’язку”:
Рис.2.1 Даталогічна модель бази даних „Бібліотека"
Схема БД бібліотечного фонду представлена з 19 таблиць: “Розробники", “Мови”, “Місце”, “Читачі", “Автори", “Упорядники”, “Редактори", “Художники", “Перекладачі", “Розміщення”, “Видача", “Перевидання", “Плетіння", “Видання”, “Характери", “Назви", “Вид видання", “Видавництва", “Анотації" та зв’язків між ними.
Назва таблиці | Ім’я поля | Тип поля |
Автори | Код розробника | Текстовий |
Код видання | Текстовий | |
Анотація | Код видання | Текстовий |
Анотація | Текстовий | |
Вид видання | Вид видання | Текстовий |
Назва виду | Текстовий | |
Видавництва | Код видавництва | Текстовий |
Назва | Текстовий | |
Місто | Текстовий | |
Видання | Код видання | Текстовий |
Код заголовка | Текстовий | |
Вид видання | Текстовий | |
Номер тому | Числовий | |
Авторський знак | Текстовий | |
Бібліотечний шифр | Текстовий | |
Повторюваність | Числовий | |
Код видавництва | Текстовий | |
Рік видання | Числовий | |
Анотації | Текстовий | |
Видача | Номер квитка | Числовий |
Номер плетіння | Числовий | |
Дата видачі | Дата/время | |
Термін | Числовий | |
Дата повернення | Дата/время | |
Місце | Код місця | Текстовий |
Номер кімнати | Числовий | |
Номер стелажу | Числовий | |
Номер полки | Числовий | |
Мова | Код мови | Текстовий |
Мова | Текстовий | |
Скорочення | Текстовий | |
Назва | Код назви | Текстовий |
Назва | Текстовий | |
Перевидання | Код характеру | Текстовий |
Код видання | Текстовий | |
Перекладачі | Код розробника | Текстовий |
Код видання | Текстовий | |
Мова | Текстовий | |
Плетіння | Номер плетіння | Числовий |
Код видання | Текстовий | |
Ціна | Денежний | |
Дата придбання | Дата/время | |
Редактори | Код розробника | Текстовий |
Код видання | Текстовий | |
Розміщення | Код місця | Текстовий |
Номер плетіння | Числовий | |
Дата розміщення | Дата/время | |
Дата вилучення | Дата/время | |
Розробники | Код розробника | Текстовий |
Розробник | Текстовий | |
Упорядники | Код розробника | Текстовий |
Код видання | Текстовий | |
Характери | Код характеру | Текстовий |
Характер перевидання | Текстовий | |
Художники | Код розробника | Текстовий |
Код видання | Текстовий | |
Читачі | Номер білету | Числовий |
Прізвище | Текстовий | |
Ім’я | Текстовий | |
По батькові | Текстовий | |
Адреса | Текстовий | |
Телефон | Текстовий |
Для нормальної роботи бази даних усі таблиці зв’язані між собою, це забезпечує формування запитів, форм звітів до бази даних.
Змоделювавши даталогічну модель БД бібліотечного фонду Тальнівського будівельно-економічного коледжу УДАУ, в якій помічена кількість потрібних таблиць, полів та зв’язків між ними визначається програмний продукт, де буде створюватись БД.
Важливою категорією є системи обробки інформації від яких залежить ефективність роботи будь - якого підприємства.
Така система повинна:
виконувати повний і точний аналіз даних;
забезпечувати отримання інформації без затримок;