3. Організація даних у внутримашинной сфері

Існує два рівні організації даних під внутримашинной сфері - логічний і фізичний. Фізична організація даних визначає спосіб розміщення інформації безпосередньо на машинних носіях і виконується програмними інструментаріями автоматично (без участі людини). Розробники внутрішньомашинної інформаційної бази АСУ оперують у програмах тільки представ-леніямі про логічної організації даних, яка визначається видом моделі даних. Під моделлю даних розуміється сукупність взаємопов'язаних структур даних та операцій над цими структурами.

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

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

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

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

Опис логічної організації даних файлової моделі полягає в присвоєнні кожному файлу унікального імені, а також в описі структури його записів. При цьому кожному полю задається скорочене позначення (ім'я поля) і вказується формат поля (тип зберігається даного, довжина поля і точність числових даних). Для полів, що виконують роль унікального (першого) ключа запису, вказується ознака ключа. Структура файлу зазвичай описується таблицею, в якій зазначаються первинні і вторинні ключі. Файлові інформаційні бази обробляються системами управління файлами (Q & A, Reflex, FFS File та ін), які не вважаються системами управління базами даних. Файлові системи легко освоюються, досить прості й ефективні у використанні. Для роботи з ними використовуються прості мови запитів, або і зовсім обмежуються набором програм-утиліт. Такі системи зазвичай підтримують роботу з невеликим числом файлів, що містять обмежену кількість записів з невеликою кількістю полів.

Крім файлових моделей організації даних внутримашинной сфери існують ієрархічні, мережні і реляційні моделі. Ці типи моделей є більш складними і, на відміну від файлової організації даних, підтримуються СУБД відповідного типу. Відмінності між цими класами моделей поступово стираються. Проте деякі особливості перерахованих типів моделей слід відзначити. Для ієрархічних і мережевих моделей їх структура не може бути змінена після введення даних, тоді як структура реляційних моделей може змінюватися в будь-який час. З іншого боку, ієрархічні та мережні моделі забезпечують більш швидкий доступ до інформації, ніж реляційні моделі. Ієрархічні моделі мають деревоподібну структуру, коли кожному вузлу структури відповідає один сегмент, який представляє собою пойменований лінійний кортеж даних. Кожному сегменту, крім кореневого, відповідає один вхідний і кілька вихідних сегментів (рис. 5).

Рис. 5. Структура ієрархічної бази даних

Кожен сегмент лежить на єдиному ієрархічному шляху, що починається з кореневого сегмента. При описі такої логічної організації даних достатньо для кожного сегмента вказати його вхідний сегмент. Так як в ієрархічній моделі кожному вхідному сегменту даних відповідає N вихідних, то такі моделі дуже зручні для подання відносин типу 1: L в предметної області.

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

Рис. 6. Структура мережевої бази даних

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

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

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

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

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

Рис. 7. Частковий реляційної моделі бази даних

У даному фрагменті бази даних визначено два відносини (файлу), що мають загальний елемент значення поля Виріб. Операції реляційної алгебри можуть об'єднати два типи записів по цьому загальному елементу. Наприклад, в результаті з'єднання запис ПС може представитися в наступному вигляді: ПС <Об'єм (м3)> <Витрата арм. (Кг)> <Витрата цем. (Кг)> <ЖБІ5> <К-сть> <Дата поставки >.....

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

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