Структури баз даних для управління даними 


Мы поможем в написании ваших работ!



ЗНАЕТЕ ЛИ ВЫ?

Структури баз даних для управління даними



 

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

Ієрархічна структура даних

У багатьох випадках існує взаємозв'язок між даними, що має назву відношенням "один до багатьох" [Р.А. Виrrоиgh, 1983]. Це відношення має на увазі, що кожен елемент даних має прямий зв'язок з деяким числом так званих "нащадків", і, звичайно кожен такий нащадок, у свою чергу, може мати зв'язок зі своїми нащадками і т.д. Як випливає з назви, предки і нащадки прямо зв'язані між собою, що робить доступ до даних простим і ефективним. Така система добре ілюструється ієрархічною системою класифікації рослин і тварин, називаною таксономією.

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

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

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

Реляційні бази даних

Недоліків великої кількості покажчиків можна уникнути використовуючи ще одну структуру баз даних - реляційну. В ній дані зберігаються як упорядковані записи або рядки значень атрибутів. Атрибути об'єктів групуються в окремих рядках у виді так званих відносин, оскільки вони зберігають свої положення в кожнім рядку і виразно зв'язані один з одним [Pr.G. Неаlеу, 1991]. Кожний стовпчик містить значення одного атрибута для всього набору об'єктів.

Реляційні системи засновані на наборі математичних принципів, називаних реляційною алгеброю або алгеброю відносин [J.D. Ullman, 1982], що встановлює правила проектування і функціонування таких систем. Оскільки реляційна алгебра ґрунтується на теорії множин, кожна таблиця відносин функціонує як безліч, і перше правило говорить, що таблиця не може мати рядок, що цілком збігається з яким-небудь іншим рядком. Оскільки кожний з рядків унікальний, одна або трохи колонок можуть використовуватися для визначення критерію пошуку, визначеного імені з першого стовпчика. Такий критерій пошуку називається первинним ключем для пошуку значень в інших колонках бази даних [11].

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

Для визначення виду, який таблиці повинні мати, встановлений набір правил, називаних нормальними формами [E.F. Соdd, 1970]. Перша нормальна форма затверджує, що таблиця повинна складатися з рядків і стовпчиків і, оскільки стовпчики будуть використовуватися як ключі пошуку, у кожній з них на кожнім рядку повинне знаходитися тільки одне значення. Друга нормальна форма вимагає, щоб кожен стовпчик, що не є первинним ключем, цілком залежав від первинного ключа. Це спрощує таблиці і зменшує надмірність обмеженням, що кожен рядок даних може бути знайдений тільки через його первинний ключ. Третя нормальна форма, зв'язана з другою, вимагає, щоб стовпчики, що не є первинним ключем, "залежали" від первинного ключа, у той час, як первинний ключ не залежить від якого-небудь не первинного ключа. Правила нормальних форм були підсумовані Кентом [W. Кеnt, 1983]. Ці правила досить корисні і повинні строго виконуватися.

 



Поделиться:


Последнее изменение этой страницы: 2019-05-20; просмотров: 184; Нарушение авторского права страницы; Мы поможем в написании вашей работы!

infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 3.144.248.165 (0.004 с.)