Банк даних і його компоненти

ЛЕКЦІЯ 1.

Введення. Основні поняття БД

Введение

Банк данных и его компоненты

Модели данных

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

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

 

У розвитку АІС можна виділити два покоління.

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

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

 

Походження термінів «база даних» і «управління базами даних» остаточно не встановлено. Можливо, вперше поняття бази даних було введено в червні 1963 р., коли з ініціативи військово-повітряних сил і служби аерокосмічної розвідки США в м. Санта-Моніка був організований симпозіум на тему «Розробка та використання машинокерованих баз даних».

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

1. Фактори, що визначають вимоги до вмісту баз даних.
2. Критерії, що впливають на структуру та проектування баз даних.
3. Методика збору даних та підтримання баз даних.
4. Економічні аспекти управління базами даних.

 

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

Банк даних і його компоненти

Існує безліч визначень банку даних.
Наприклад, в «Тлумачному словнику з обчислювальних систем» [13] дається наступне визначення:

Банк даних - це система, яка надає послуги зі зберігання й пошуку даних певній групі користувачів і з певної тематики (наприклад, біологічні види, статистика торгівлі, ціни на товари).

Визначення банку даних, опубліковане в галузевих керівних матеріалах по створенню банків даних Державного комітету з науки і техніки (ДКНТ) [13]:

Банк даних - це система спеціальним чином організованих даних (баз даних), програмних, технічних, мовних, організаційно-методичних засобів, призначених для забезпечення централізованого накопичення та колективного багатоцільового використання даних.

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

 

Основними функціями банку даних (БНД) є:
1. Зберігання інформації, її захист і відновлення після збоїв в роботі.
2. Періодична зміна збережених даних.
3. Пошук і відбір необхідних даних по запитам користувачів і прикладних програм.
4. Обробка знайдених даних і виведення результатів в заданій формі.

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

 

Структуру банку даних можна представити у вигляді рис. 1:

 

Рис. 1. Схема банка даних

 

 

Отже, банк даних складається з наступних компонентів:

1. Бази даних - іменована сукупність даних, організованих за певними правилами, що передбачають загальні принципи опису, зберігання і маніпулювання даними.
2. Системи управління базами даних (СКБД) - комплексу програмних і мовних засобів, призначених для створення, ведення і використання баз даних.
3. Словника (довідника) бази даних - інформації про базу даних, використовуваної СУБД для доступу до збереженої в ній інформації.

 

 

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

 

Користувачі не працюють з базою даних безпосередньо. Процес взаємодії між ними реалізується через систему управління базами даних (див. рис. 1).

 

При цьому можливі два варіанти організації цього процесу:

1. користувач працює з СУБД в інтерактивному режимі, використовуючи систему меню;

2. взаємодія здійснюється за допомогою прикладних програм, званих додатками.

 

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

 

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

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

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

В якості прикладів СУБД можна привести MS Access, Paradox, FoxPro, Clarion, Clipper, MS SQL Server, Oracle, Informix і т. д.

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

 

Словник бази даних може зберігатися в окремому файлі або безпосередньо у файлі бази даних (MS Access).

Користувачів банків даних можна розділити на три великі групи.

1. Кінцеві користувачі. Це найбільш численна група користувачів, для обслуговування професійних завдань яких створюється конкретна база даних (менеджери, торгові працівники, фінансисти і т. д.). Важливо, щоб СУБД надавала цієї категорії користувачів досить зручні, прості та ефективні засоби роботи з базою даних, що не вимагають від користувачів освіти в галузі інформаційних технологій або тривалого етапу спеціальних підготовки і навчання.
2. Прикладні програмісти. В обов'язки цієї групи користувачів входить написання, налагодження та впровадження прикладних програм (додатків), що використовують інформацію з бази даних. В основному для цього використовуються універсальні мови програмування: С + +, Pasсal, Delphi та ін
3. Адміністратори банку даних (АБД). Користувачі цієї групи реалізують складні завдання проектування, створення, організації та підтримки роботи банків даних.

 

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

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

Моделі даних

Дані, що зберігаються в БД, повинні бути організовані за певними правилами.

 

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

Існуючі бази даних розроблені на основі ієрархічної, мережевої, реляційної, об'єктно-орієнтованої моделей даних або їх підмножин.

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

 

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

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

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

Сукупність конкретних значень полів сегмента називається екземпляром сегмента або записом: м. Амурська - вул. Перемоги, 3 - 18-67-53. Отже, один блок на схемі відображає безліч фактичних записів (примірників сегмента).

 

Рис. 2. Ієрархічна база даних

 

 

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

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

Основні властивості ієрархічної моделі даних.
1. Кожен з підлеглих сегментів пов'язаний тільки з одним сегментом вищого рівня ієрархії. Зв'язки між сегментами одного рівня не допускаються.
2. Між сегментами двох рівнів можуть підтримуватися тільки зв'язки «один до багатьох» (одна філія - ​​багато магазинів, один склад - багато товарів) або «один до одного» (одна філія - ​​один директор).

Недоліки ієрархічної моделі даних:

1. Асиметричність запитів. У цьому можна переконатися, порівнюючи два запити. За допомогою першого з них вибирається запис з інформацією про партії товарів, для якої відомі назви філії, магазину та складу. У рамках другого запиту за відомостями про партії товарів потрібно визначити назву філії, в якому вона знаходиться.
2. Складність змін. Наприклад, при закритті деякого складу товари перерозподіляються між іншими складами. Ця операція зажадає кардинальної зміни структури бази даних.
3. Жорсткість структури, що не дозволяє врахувати в базі даних окремі реальні ситуації. Наприклад, товари, що зберігаються на одному складі, призначені декільком магазинам.
4. Складність експлуатації. Робота з ієрархічними базами даних потребує значної кваліфікації користувачів в області програмування. Зокрема, в СУБД IMS фірми IBM для опису загальної схеми бази даних і блоку зв'язку кожного користувача з базою даних використовувалася мова програмування Assembler. Для вибірки даних з БД - спеціалізована мову DL / 1, для обробки отриманої інформації - мови PL / 1 або Кобол.
Перелічені причини призвели до того, що ієрархічна модель даних в даний час практично не використовується.

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

Стандарт мережевої моделі даних вперше був визначений у 1975 р. організацією CODASYL (Conference of Data System Languages).

 

У мережній моделі даних не накладається ніяких обмежень на кількість зв'язків, що входять в одну вершину.

Отже, зв'язки можна встановлювати не тільки між вузлами сусідніх по підпорядкованості рівнів, але і різних рівнів (рис. 3):

 

Рис. 3 Мережева база даних

 

Зв'язки, зображені на рис. 3 і відсутні на рис. 2, можуть характеризувати цілком реальні взаємини в роботі торгового підприємства: представники дирекції можуть курирувати роботу конкретних підрозділів, підрозділу підприємства (автогосподарство, ремонтна служба) забезпечують роботу складів, співробітники підрозділів (бухгалтери, торгові агенти) взаємодіють з магазинами. Таких зв'язків можна визначити дуже багато.

 

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

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

 

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

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

З наведених причин СУБД, побудовані на основі мережної моделі (IDMS, db_VistaIII та ін), не набули широкого поширення.

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

 

Реляційна модель даних (РМД) покладена в основу більшості сучасних СУБД. Достоїнствами моделі є простота розміщення даних та зручність їх інтерпретації.

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

 

Кожна таблиця реляційної бази даних має ім'я і рядок заголовків.
Розглянемо таблицю бази даних торговельного підприємства, в якій зберігаються відомості про постачальників товарів (табл. 1.1):

Таблица 1.1 Поставщики

Код	Название	Город
	Волна	Хабаровск
	Парус	Владивосток
	Звезда	Хабаровск
	Парус	Иркутск

 

Таблиця має ім'я Постачальники, назви стовпців таблиці Код, Назва, Місто являють собою рядок заголовків.

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

 

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

 

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

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

 

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

 

Первинним ключем таблиці Постачальники є поле Код. Поля Назва і Місто не можуть бути первинними ключами, так як в них є повторювані значення (див. табл. 1.1). Первинний ключ, визначений по одному полю таблиці, називається простим.

 

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

Таблица 1.2 Поставки товаров

Название товара	Артикул	Количество	Дата поставки	Шифр поставщика
Костюм			10.12.05
Сапоги			10.12.05
Туфли			11.12.05
Костюм			11.12.05
Костюм			12.12.05
Костюм			12.12.05
Туфли			12.12.05

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

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

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

Таблица 1.3 Дополнительные сведения

Поставщик	Директор	Телефон	Адрес	№ договора
	Иванов П. Л.	64-12-83	Мира, 4
	Сеидов О. А.	22-17-12	Победы, 18
	Цой О. М.	39-18-34	Блюхера, 1
	Лодис С. С.	46-19-23	Пушкина, 1

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

Зв'яжемо таблиці Постачальники і Додаткові відомості за допомогою полів Код та Постачальник. Порівнюючи значення даних у цих полях і вибираючи поєднання записів, для яких вони збігаються, можна отримати відповіді, наприклад, на такі запити: «Хто є директором організації«Парус»з Владивостока?» (Сеїд О.А.); «Яка адреса у організації «Хвиля»?»(Миру, 4).

Наведений приклад демонструє зв'язок між таблицями «один до одного» - одного запису в таблиці Постачальники відповідає один запис у таблиці Додаткові відомості.

Зв'яжемо тепер таблиці Постачальники і Поставки товарів за допомогою полів Код та Шифр ​​постачальника. Виникає питання про правомірність виконаних дій. Так як значення даних у полі Шифр ​​постачальника повторюються, це поле не може бути первинним ключем таблиці Поставки товарів.

Насправді ніякої суперечності не існує - поле Шифр ​​постачальника є зовнішнім ключем таблиці Поставки товарів. Зовнішній ключ - це поле або група полів таблиці, які не є первинним ключем в даній таблиці, але є первинним ключем в іншій таблиці.

За допомогою зв'язування таблиць Постачальники і Поставки товарів по ключових полях, можна отримати відповіді на запити: «Яка організація поставила костюми 10 грудня 2005?» (Хвиля); «З яких міст були привезені туфлі?» (Хабаровськ, Іркутськ).

Пов'язуючи таблиці Поставки товарів та Додаткові відомості, можна отримати відповіді на запити: «Який номер телефону у організації, яка поставила костюми з артикулом 500?» (64-12-83); «Відповідно до якого договором поставлялися костюми з артикулом 400?» (№ 35).

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

Для зв'язування таблиць, дані в зв'язуючих полях обов'язково повинні бути отримані з одного домену. Імена зв'язуючих полів можуть відрізнятися один від одного (Код, Шифр ​​постачальника, Постачальник), розташування сполучних полів в таблицях може бути довільним (див. табл. 1.1 - 1.3).