• Гідрологія і Гідрометрія
• Господарське право
• Економіка будівництва
• Економіка природокористування
• Економічна теорія
• Земельне право
• Історія України
• Кримінально виконавче право
• Медична радіологія
• Методи аналізу
• Міжнародне приватне право
• Міжнародний маркетинг
• Основи екології
• Предмет Політологія
• Соціальне страхування
• Технічні засоби організації дорожнього руху
• Товарознавство продовольчих товарів

Мережева модель даних

СУБД.

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

Здійснювати ці операції з великими БД, а саме такі і існують в реальному світі, досить складно. Тому цю рутинну роботу вирішили автоматизувати, перекласти на плечі ПК.

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

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

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

3. Класифікація баз даних

За типом зв’язку між даними: ієрархічні, мережеві, реляційні, або їх комбінація (мішані).

Ієрархічна БД

Ієрархічна структура представляє сукупність елементів, пов‘язаних між собою за визначеними правилами. Об‘єкти, які пов'язані ієрархічними відношеннями, створюють орієнтовний граф (перевернуте дерево) (рис. 1.5).

До основних понять ієрархічної структури відносять: рівень, елемент (вузол), зв‘язок. Вузол — це сукупність атрибутів даних, які описують деякий об‘єкт. На схемі ієрархічного дерева вузли представлені вершинами графа. Кожен вузол на більш низькому рівні пов'язаний лише з одним вузлом, який знаходиться на більш високому рівні. Ієрархічне дерево має тільки одну вершину (корінь дерева), яка непідвладна ніякій іншій вершині, вона знаходиться на самому верхньому (першому) рівні. Всі інші вершини залежні.

У кожному записі бази даних існує тільки один (ієрархічний) шлях від кореневого запису.

Рівень 1

Рівень 2

Рівень 3

Рис.1.5. Графічне відображення ієрархічної структури БД

Приклад 3. Приклад представлений на рис 1.6., ілюструє використання ієрархічної моделі бази даних.

Інститут (спеціальність, назва, директор)

Група (номер, староста)

Студент (номер залікової книжки, прізвище, ім‘я, по батькові)

Рис. 1.6. Приклад ієрархічної структури БД

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

У мережевій структурі, при тих самих основних поняттях (рівень, вузол, зв‘язок) кожен елемент цієї БД може бути пов'язаним з будь–яким іншим елементом.

На рис. 1.7. відображена мережева структура бази даних у вигляді графа.

Студент (номер залікової книжки, прізвище, група)

Рис.1.8. Приклад мережевої структури БД

Приклад 4.Прикладом складної мережевої структури може служити структура БД, яка містить відомості про студентів які приймають участь у науково–дослідних роботах. Тут можлива участь одного студента в декількох науково–дослідних роботах, а також участь декількох студентів у розробці однієї науково–дослідної роботи. Графічне відображення описаної мережевої структури відображено на рис 1.8. Ця структура складається тільки з двох типів записів. Єдине відношення являє собою складний зв‘язок між записами в обох напрямках.

Реляційна модель даних

Поняття реляційної (relation — відношення) БД пов‘язане з розробками відомого американського спеціаліста в області баз даних Е.Кодда.

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

Реляційна модель орієнтована на організацію даних у вигляді двовимірних таблиць. Будь–яка реляційна таблиця представляє собою двовимірний масив та володіє наступними властивостями:

§ кожен елемент таблиці — це один, неподільний елемент даних;

§ всі стовпчики таблиці однорідні, тобто всі елементи в стовпчику мають однаковий тип (числовий, символьний і т.д.) і довжину;

§ кожен стовпчик має унікальне ім‘я;

§ однакові рядки у таблиці відсутні;

§ порядок послідовності рядків і стовпців може бути довільний.

Приклад 5. Реляційною таблицею можливо уявити інформацію про студентів (рис1.9)

Рис.1.9. Приклад реляційної таблиці

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

4. Структурні елементи бази даних

Поняття бази даних тісно пов‘язані з такими поняттями структурних елементів, як поле, запис, файл (таблиця) (рис. 1.10).

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

ім‘я, наприклад, Прізвище, Ім‘я, По батькові, Дата народження;

тип, наприклад, символьний, числовий, календарний, логічний;

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

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

Рис.1.10. Основні структурні елементи БД

Поле, кожне значення якого однозначно визначає відповідний запис, називається простим ключем (ключовим полем). Якщо запис однозначно визначається значенням декількох полів, то така таблиця бази даних має складений ключ (тобто складений з декількох частин). В прикладі 5 (рис.1.9), ключовим полем таблиці є "№ особової справи".

Щоб зв‘язати дві реляційні таблиці, необхідно ключ першої таблиці ввести до складу ключа другої таблиці (можливий збіг ключів); в іншому випадку потрібно ввести в структуру першої таблиці зовнішній ключ — ключ другої таблиці.

Приклад 6.На рис.1.11 відображено приклад реляційної моделі, побудовано на основі відношень: СТУДЕНТ, СЕСІЯ, СТИПЕНДІЯ.

Студент(Номер, Прізвище, Ім‘я, По батькові, Стать, Дата народження, Група);

Сесія (Номер, Оценка1, Оценка2, Оценка3, Оценка4, Результат);

Стипендія (Результат, відсоток).

Рис.1.11. Приклад реляційної моделі

Таблиці СТУДЕНТ і СЕСІЯ мають ключі, які збігаються (Номер), що дає можливість легко організовувати зв‘язок між ними. Таблиця СЕСІЯ має первинний ключ Номер і має зовнішній ключ Результат, який забезпечує її зв‘язок з таблицею СТИПЕДІЯ.

Запис — сукупність логічно пов‘язаних полів. Екземпляр запису — це окрема реалізація запису, який містить конкретні значення його полів.

Файл (таблиця) — сукупність екземплярів записів однієї структури.

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

Рис.1.12. Опис логічної структури запису файла

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

Приклад 7. На рис. 1.13 наведено приклад описання логічної структури запису файла (таблиці) СТУДЕНТ. Структура запису файла СТУДЕНТ лінійна, вона містить записи фіксованої довжини. Групи значень полів, які повторюються відсутні. Звернення до значення поля відбувається за його номером.

Рис. 1.13. Описання логічної структури запису файла СТУДЕНТ

та

3. ТИПИ ЗВ'ЯЗКІВ

Всі інформаційні об‘єкти предметної області пов‘язані між собою. Розрізняють зв‘язки декількох типів, для яких введені наступні позначення:

§ Один до одного (1:1)

§ Один до багатьох (множини) (1:М)

§ Багато до багатьох (множина до множини) (М:М).

Розглянемо ці типи зв‘язків на прикладі 15.

Приклад 15. Дана сукупність інформаційних об‘єктів, яка відображає учбовий процес у ВУЗі:

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

СЕСІЯ (Номер, Оцінка 1, Оцінка2, Оцінка3, Оцінка4, Результат)

СТИПЕНДІЯ (Результат, Відсоток)

Викладач (Код викладача, Прізвище, Ім‘я, По батькові)

Зв‘язок один до одного (1:1) передбачає, що в кожен момент часу одному екземпляру інформаційного об‘єкта А відповідає не більше одного екземпляра інформаційного об‘єкта В і навпаки.

А1 В1

А2

А3 В2

Рис. 2.19. Графічне представлення реального відношення 1:1

Приклад 16. Прикладом зв'язку 1:1 може служити зв‘язок між інформаційними об‘єктами СТУДЕНТ і СЕСІЯ

СТУДЕНТ ↔ СЕСІЯ

Кожен студент має визначений набір екзаменаційних оцінок за сесію.

При зв‘язку один до багатьох (множини) (1:М) одному екземпляру інформаційного об‘єктів А відповідає 0, 1 або більше екземплярів об‘єкта В, але кожен екземпляр об‘єкту В пов‘язаний не більш чим з одним екземпляром об‘єкта А

А1 В1

А2 B2

А3 В3

Рис.1.2.20. Графічне представлення реального відношення 1:M

Приклад 17. Прикладом зв'язку 1:M може служити зв‘язок між інформаційними об‘єктами СТІПЕНДІЯ і СЕСІЯ

СТІПЕНДІЯ ↔→ СЕСІЯ

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

Зв‘язок багато до багатьох (М:М) передбачає, що в кожну одиницю часу одному екземпляру інформаційного об‘єкта А відповідає 0, 1 або більше екземплярів об‘єкта В і навпаки.

А1 В1

А2 В2

А3 В3

Рис.1.2.21. Графічне представлення реального відношення М:М

Приклад 18.Прикладом зв'язку М:М може служити зв‘язок між інформаційними об‘єктами СТУДЕНТ і ВИКЛАДАЧ

СТУДЕНТ ВИКЛАДАЧ

Один студент навчається у багатьох викладачів, і один викладач навчає багатьох студентів.

4. ПОБУДОВА ІНФОЛОГІЧНОЇ МОДЕЛІ

4.1 Архітектура СУБД

Бази даних і програмні засоби їх створення та ведення (СУБД) мають багаторівневу архітектуру, уявлення про яку можна отримати з рис. 3.22

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

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

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

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

Приклад 19. Співвідношення між концептуальною і зовнішніми моделями бази даних наведені на рис. 2.23.

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

4.1 Поняття інформаційно–логічної моделі

Проектування бази даних полягає в побудові комплексу взаємопов‘язаних моделей даних. На рис. 2.24. умовно відображені етапи процесу проектування бази даних.

Рис. 2.24. Етапи процесу проектування бази даних

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

Інформаційно–логічна (інфологічна) модельпредметної області відображає предметну область у вигляді сукупності інформаційних об‘єктів і їх структурних зв‘язків.

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

Приклад 20. На рис. 2.25. представлена графічна форма інформаційно–логічної моделі, яка пов‘язує інформаційні об‘єкти: Студент, Сесія, Стипендія, Викладач.

Тема 3. Функціональні можливості СУБД

Читайте також:

1. G2G-модель електронного уряду
2. OSI - Базова Еталонна модель взаємодії відкритих систем
3. Абстрактна модель
4. Абстрактна модель
5. Абстрактна модель оптимального планування виробництва
6. Американська модель соціальної відповідальності
7. Аналіз паралельного інтерейсу з DSP-процесорами: запис даних в ЦАП, що під’єднаний до адресного простору пам’яті
8. Аналіз паралельного інтерфейсу з DSP-процесорами: читання даних з АЦП, що під’єднаний до адресного простору пам’яті
9. Аналіз статистичних даних про склад та плинність кадрів, які обіймали керівні
10. Аналіз та інтерпретація одержаних даних
11. Англійський економіст У. Бріджез пропонує модель організаційних змін за такими напрямками.
12. Англо-американська модель

Переглядів: 3559