30.03.17 3.4K

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

Процес проектування бази даних

Належним чином структурована база даних:

• Допомагає заощадити дискове місце за рахунок виключення зайвих даних;
• Підтримує точність та цілісність даних;
• Забезпечує зручний доступ до даних.

Розробка БД включає наступні етапи:

1. Аналіз вимог чи визначення мети бази даних;
2. Організація даних у таблицях;
3. Вказівка ​​первинних ключів та аналіз зв'язків;
4. Нормалізація таблиць.

Розглянемо кожен етап проектування баз данихДетальніше. Зверніть увагу, що в цьому посібнику розглядається реляційна модель бази даних Едгара Кодда, написана на мові SQL ( а не ієрархічна, мережева чи об'єктна моделі).

Аналіз вимог: визначення мети бази даних

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

Ось кілька способів збирання інформації перед створенням бази даних:

• Опитування людей, які її використовуватимуть;
• Аналіз бізнес-форм, таких як рахунки-фактури, розклади, опитування;
• Розгляд всіх існуючих систем даних ( включаючи фізичні та цифрові файли).

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

Клієнти

• Адреса;
• Місто, штат, поштовий індекс;
• Адреса електронної пошти.

Товари

• Назва;
• Ціна;
• Кількість у наявності;
• Кількість на замовлення.

Замовлення

• Номер замовлення;
• Торговий представник;
• Дата;
• Товар;
• Кількість;
• Ціна;
• Вартість.

При проектуванні реляційної бази даних ця інформація пізніше стане частиною словника даних, в якому описані таблиці та поля БД. Розбийте інформацію на мінімально можливі частини. Наприклад, подумайте про те, щоб розділити поле поштової адреси та штату, щоб можна було фільтрувати людей за штатом, де вони проживають.

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

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

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

Щоб перетворити списки даних на таблиці, почніть із створення таблиці для кожного типу об'єктів, таких як товари, продажі, клієнти та замовлення. Ось приклад:

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

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

• CHAR – конкретна довжина тексту;
• VARCHAR - текст різної довжини;
• TEXT – великий обсяг тексту;
• INT - позитивне або негативне ціле число;
• FLOAT, DOUBLE - числа з плаваючою комою;
• BLOB – двійкові дані.

Деякі СУБД також пропонують тип даних Autonumber, який автоматично генерує унікальний номер у кожному рядку.

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

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

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

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

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

Створення зв'язків між сутностями

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

Кожен об'єкт може бути взаємопов'язаний з іншим за допомогою одного із трьох типів зв'язку:

Зв'язок «один-до одного»

Коли існує лише один екземпляр об'єкта A для кожного екземпляра об'єкта B, кажуть, що між ними існує зв'язок один до одного » ( часто позначається 1:1). Можна вказати цей тип зв'язку в ER-діаграмі з тире на кожному кінці:

Якщо при проектуванні та розробці баз даних у вас немає підстав розділяти ці дані, зв'язок 1:1 зазвичай вказує на те, що краще об'єднати ці таблиці в одну.

Але за певних обставин доцільніше створювати таблиці зі зв'язками 1:1. Якщо є поле з необов'язковими даними, наприклад «опис», який не заповнений для багатьох записів, можна перемістити всі описи в окрему таблицю, за винятком порожніх полів і поліпшення продуктивності бази даних.

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

Зв'язок «один-багатьом»

Ці зв'язки виникають, коли запис в одній таблиці пов'язаний з декількома записами в іншій. Наприклад, один клієнт міг розмістити багато замовлень, або читач може мати відразу кілька книг, взятих у бібліотеці. Зв'язки «один-багатьом» (1:M) позначаються так званою «міткою ноги ворони», як у цьому прикладі:

Щоб реалізувати зв'язок 1:M, додайте первинний ключ з «однієї» таблиці як атрибут до іншої таблиці. Якщо первинний ключ у такий спосіб вказаний в іншій таблиці, він називається зовнішнім ключем. Таблиця з боку зв'язку «1» є батьківською таблицею для дочірньої таблиці з іншого боку.

Зв'язок «багатьом-багатьом»

Коли кілька об'єктів таблиці можуть бути пов'язані з кількома іншими об'єктами. Кажуть, що вони мають зв'язок багато хто до багатьох» ( M:N). Наприклад, у випадку студентів та курсів, оскільки студент може відвідувати багато курсів і кожен курс можуть відвідувати багато студентів.

На ER-діаграмі ці зв'язки відображаються за допомогою наступних рядків:

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

Для цього потрібно створити між цими двома таблицями нову сутність. Якщо між продажами та продуктами існує зв'язок M:N, можна назвати цей новий об'єкт « sold_products», оскільки він міститиме дані для кожного продажу. І таблиця продажів, і таблиця товарів матимуть зв'язок 1:M із sold_products . Цей вид проміжного об'єкта у різних моделях називається таблицею посилань, асоціативним об'єктом чи таблицею зв'язків.

Кожен запис у таблиці зв'язків буде відповідати двом сутностям із сусідніх таблиць. Наприклад, таблиця зв'язків між студентами та курсами може виглядати так:

Обов'язково чи ні?

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

Два об'єкти можуть бути взаємозалежними ( один не може існувати без іншого).

Рекурсивні зв'язки

Іноді під час проектування бази даних таблиця свідчить про саму. Наприклад, таблиця співробітників може мати атрибут «керівник», який посилається на іншу особу у цій же таблиці. Це називається рекурсивними зв'язками.

Зайві зв'язки

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

Нормалізація бази даних

Після попереднього проектування бази даних можна застосувати правила нормалізації, щоб переконатися, що таблиці правильно структуровані.

У той самий час в повному обсязі бази даних потрібно нормалізувати. В цілому, бази з обробкою транзакцій у реальному часі ( OLTP), мають бути нормалізовані.

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

Перша форма нормалізації

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

Можливо, у вас виникне бажання обійти це обмеження, розділивши дані на додаткові стовпці. Але це також суперечить правилам: таблиця з групами атрибутів, що повторюються або тісно пов'язані, не відповідає першій формі нормалізації. Наприклад, наведена нижче таблиця не відповідає 1NF :
Замість цього під час фізичного проектування бази даних розділіть дані на кілька таблиць або записів, доки кожна комірка не міститиме лише одне значення, і додаткових стовпців не буде. Такі дані вважаються розбитими до найменшого корисного розміру. У наведеній таблиці можна створити додаткову таблицю « Реквізити продажу», яка відповідатиме конкретним продуктам із продажами. «Продажі» матимуть зв'язок 1:M із « Реквізитами продажу».

Друга форма нормалізації

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

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

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

Таким чином, таблиця з цими полями не відповідатиме другій формі нормалізації, оскільки атрибут «назва товару» залежить від ідентифікатора продукту, але не від номера замовлення:

• Номер замовлення (первинний ключ);
• ID товару (первинний ключ);
• Назва товару.

Третя форма нормалізації

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

Відповідно до 3NF , не можна зберігати в таблиці будь-які похідні дані, такі як стовпець «Податок», який у наведеному нижче прикладі безпосередньо залежить від загальної вартості замовлення:

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

Багатовимірні дані

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

Правила цілісності даних

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

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

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

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

Додавання індексів та уявлень

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

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

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

Розширені властивості

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

SQL та UML

Уніфікована мова моделювання ( UML) — це ще один візуальний спосіб вираження складних систем, створених об'єктно-орієнтованою мовою. Деякі з концепцій, згаданих у цьому посібнику, відомі в UML під різними назвами. Наприклад, об'єкт у UML відомий як клас.

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

Добре погано

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

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

Чи знаєте ви, що?
"База даних Інтеграція" призвела до революції в бізнесі, ІТ, та освітньому секторі, надаючи широкий спектр можливостей для управління та аналізу даних.

Структура бази даних

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

Таблиці:Дані зберігаються у рядках (записи) та стовпцях (поля).

Форми:Форми розроблені для введення нових даних. Щоб можна було легко і без помилок додавати інформацію до бази даних через форму, а чи не вводити дані у таблицю.

Запити:Запити написані для вилучення рядків та/або стовпців на основі заздалегідь визначеного стану.

Найбільш відомі бази даних: MySQL, SAP, Oracle, IBM DB2 і т.д. СУБД або "система управління бази даних" використовується як інтерфейс для зв'язку між користувачем і базою даних.

Що таке бази даних і де вони використовуються?

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

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

Дані модифікації / Updation:Статичні дані не потребують оновлення. Тим не менш, динамічні дані потребують постійної модифікації. Розглянемо вік співробітників у створенні. Вона має оновлюватись щороку (періодичне оновлення).

приклад

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

Переваги баз даних

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

Асоціація даних:записи даних із окремих таблиць можуть бути пов'язані. Це необхідно, коли певний фрагмент даних існує більш ніж у одній таблиці. Наприклад, ідентифікатори працівників можуть існувати у таких даних як «Заробітна плата», а також «працівники». Зв'язок має важливе значення для того, щоб мати єдині зміни в декількох місцях і тих самих даних.

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

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

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

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

Експорт:У цьому випадку таблиці або запити імпортуються іншими базами даних.

Зв'язки даних:Це робиться для того, щоб уникнути створення копії об'єкта в базі. Посилання визначається до об'єкта вихідної бази даних.

Сортування даних / Фільтрування:Фільтри можуть застосовуватися до даних, які мають однакові значення даних. Прикладом однакових даних може бути імена співробітників організації з аналогічними прізвищами чи іменами. Аналогічним чином дані можуть бути відсортовані як за зростанням, так і за спаданням. Це допомагає переглядати або роздрукувати результати в потрібному порядку.

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

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

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

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

Цілі використання баз даних

Використання БД переважно забезпечує:

1. незалежність даних та програм;

2. реалізацію відносин між даними;

3. сумісність компонентів БД;

4. простоту зміни логічної та фізичної структур БД;

5. цілісність, відновлення та захист БД та ін.

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

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

Незалежність даних та програм пояснюється двома основними причинами.

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

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

Відносини між даними. Дані про об'єкти в БД пов'язані між собою відносинами (зв'язками). Відношення між об'єктами Аі Упозначимо так:

де F(х)- вид зв'язку об'єкта А зоб'єктом В; G(х) -вид зв'язку об'єкта У соб'єктом А.Функції F(х) та G(х)можуть приймати значення U та N- одиничний і множинний зв'язок відповідно. Зазвичай розглядають чотири типи відносин.

1. Відношення

(один до одного) означає, що кожному екземпляру об'єкта А Уі, навпаки, будь-якому екземпляру об'єкта Уможе відповідати лише один екземпляр об'єкта А.Наприклад:

ПІДПРИЄМСТВО - ДИРЕКТОР

2. Відношення

A - B (1: N)

(один до багатьох) означає, що можуть існувати екземпляри об'єкта А,яким відповідає більше одного екземпляра об'єкта В,але кожному екземпляру об'єкта Уможе відповідати лише один екземпляр об'єкта А.Наприклад:

ОРГАНІЗАЦІЯ - ПІДРОЗДІЛ (1:N)

3. Відношення

A - B (1: N)

(багато до одного) означає, що кожному екземпляру об'єкта Аможе відповідати лише один екземпляр об'єкта Ута серед екземплярів об'єкту Уможуть бути такі, яким відповідає кілька екземплярів об'єкта А.Очевидно, що якщо 1: N- тип відносин між А і В,то N: 1 - тип відносин між Уі A. Наприклад:

РОБОЧИЙ - ПІДПРИЄМСТВО

4. Відношення

A - B ( M: N)

(багато хто до багатьох, або груповий) означає, що може існувати екземпляр об'єкта А,якому відповідає кілька екземплярів об'єкта В,і, навпаки, одному екземпляру об'єкта Уможе відповідати кілька екземплярів об'єкта А.Очевидно, що якщо М: N Аі В,то N:М- тип відносин між об'єктами В та А.Наприклад:

ПОСТАЧАЛЬНИК - ПРОДУКТ

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

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

Програмне забезпечення СУБД зазвичай є надбудовою, розширенням можливостей ОС щодо управління даними.

Перерахуємо основні компоненти БД, які мають бути сумісні, починаючи з рівня подання даних: дані, технічне забезпечення, ОС, програмне забезпечення методів доступу до даних, СУБД, додатки. Зміна будь-якого компонента не повинна впливати на наступні компоненти. Так, заміна версії ОС не повинна спричинити заміни СУБД або зміни у додатку.

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

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

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

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

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

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

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

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

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

p align="justify"> Інформаційні системи, засновані на використанні БД, зазвичай функціонують в архітектурі клієнт-сервер. І тут БД розміщується на комп'ютері-сервері, і до неї здійснюється спільний доступ.

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

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

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

Вирізняють такі види СУБД:

* повнофункціональні СУБД;

* сервери БД;

* Засоби розробки програм роботи з БД.

Повнофункціональні СУБД є традиційними СУБД. До них відносяться dBaseIV, Microsoft Access, Microsoft FoxPro та ін.

Сервери БД призначені в організацію центрів обробки даних у мережах ЕОМ. Сервери БД забезпечують обробку запитів клієнтських програм, зазвичай, за допомогою операторів SQL. Прикладами серверів БД є: Microsoft SQL Server, InterBase та ін.

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

Засоби розробки програм роботи з БД можуть використовуватись для створення таких програм:

* клієнтських програм;

* серверів БД та їх окремих компонентів;

* Додатків користувача.

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

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

* Можливість організації спільної паралельної роботи багатьох користувачів;

* масштабованість;

* Перенесення на різні апаратні та програмні платформи;

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

* забезпечення безпеки даних і розвиненої структурованої системи доступу до них.

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

* відносна простота експлуатації, що дозволяє створювати на їх основі працездатні користувацькі додатки;

* щодо обмежені вимоги до апаратних ресурсів.

По моделі даних СУБД поділяють на ієрархічні, мережеві, реляційні, объектно-ориентированные та інших. Деякі СУБД можуть одночасно підтримувати кілька моделей даних.

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

· Мова опису даних - високорівневий непроцедурний мова структури даних;

· Мова маніпулювання даними - сукупність конструкцій, що забезпечують виконання основних операцій по роботі з даними: введення, модифікацію та вибірку даних за запитами.

Названі мови у різних СУБД можуть мати відмінності. Найбільшого поширення набули дві стандартизовані мови: QBE - мова запитів за зразком і SQL - структурована мова запитів. QBE переважно володіє властивостями мови маніпулювання даними, SQL поєднує у собі властивості мов обох типів.

СУБД реалізує такі основні функції низького рівня:

* управління даними у зовнішній пам'яті;

* управління буферами оперативної пам'яті;

* Управління транзакціями;

* ведення журналу змін у БД;

* забезпечення цілісності та безпеки БД.

Реалізація функції управління даними зовнішньої пам'яті забезпечує організацію управління ресурсами у файловій системі ОС.

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

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

Транзакції притаманні три основні властивості:

* атомарність (виконуються всі операції, що входять в транзакцію, або жодна);

* Серіалізуемість (відсутня взаємний вплив виконуваних в один і той же час транзакцій);

* Довговічність (навіть крах системи не призводить до втрати результатів зафіксованої транзакції).

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

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

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

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

Вступ

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

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

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

1. Організація баз даних

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

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

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

Схеми та підсхеми бази даних часто зображують у вигляді діаграм. На рис. 1 наведена загальна схема логічної структури бази даних та підсхеми двох прикладних програмістів, які мають різні уявлення про дані. Суцільні лінії позначають зв'язку на схемі. Прості зв'язки позначаються однією стрілкою, зв'язку один до багатьох - подвійний стрілкою. Штрихові лінії відображають перехресні посилання. Наявність перехресних посилань дозволяє уникнути повторення записів ПОСТАЧАЛЬНИК та СПЕЦИФІКАЦІЇ - ПАРТІЇ-ТОВАРУ у кожному запису СТАТТЯ ЗАКУПІВЛІ.

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

2. Системи управління базами даних

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

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

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

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

Для роботи з системою управління базою даних необхідно кілька мов: мови програмування, мови опису схем та підсхем, мови опису фізичних даних. Прикладний програміст використовує мови програмування для написання програм (КОБОЛ, ФОРТРАН, ПЛ/1, АССЕМБЛЕР) та засоби для опису даних - мова опису підсхем. Мова опису підсхем може являти собою засіб опису даних у мові програмування, засіб, що забезпечується СУБД, а також незалежну мову опису даних. Багато СУБД використовують засоби опису даних мов програмування. Для прикладного програміста СУБД має забезпечити засоби передачі команд та інтерпретації повідомлень, що видаються системою. Інтерфейс між прикладною програмою та СУБД – мова маніпулювання даними – вбудовується у мову програмування. Запис запитується мовою маніпулювання даними та зчитується в робочу область прикладної програми; аналогічно при включенні запису до бази даних прикладна програма поміщає їх у робочу область і видає команду мовою маніпулювання даними. Типовими командами мови маніпулювання даними є: відкрити файл чи набір записів; закрити файл чи набір записів; визначити місцезнаходження та рахувати зазначений екземпляр запису; передати вміст зазначених елементів даних із певного екземпляра запису; замінити значення певних елементів зазначеного екземпляра запису величинами з робочої області програми; вставити в набір записів запис із робочої області; видалити певний екземпляр запису із послідовності записів; запам'ятати новий екземпляр запису у базі даних; видалити певний екземпляр запису з бази даних; переупорядкувати записи в групі у спадній або зростаючій послідовності за вказаним ключем.

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

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

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

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

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

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

Існуючі СУБД забезпечують три основні підходи в управлінні даними: ієрархічний, мережевий та реляційний (рис. 3). Ієрархічний підхід ґрунтується на поданні ієрархії об'єктів. Ієрархічні взаємозв'язки безпосередньо підтримуються у фізичних конструкціях СУБД. Ієрархічні взаємозв'язки є окремим випадком мережевих взаємозв'язків. Наприклад, постачальник може постачати кілька видів товарів, кожен вид товару може мати кілька постачальників. Реляційні системи не вводять різницю між об'єктами і взаємозв'язками. Мережеві та ієрархічні взаємозв'язки можуть бути представлені у вигляді двомірних таблиць, званих відносинами і які мають наступні властивості: кожен елемент таблиці являє собою один елемент даних (повторювані групи відсутні); елементи стовпця мають однакову природу, стовпцям однозначно надано імена; у таблиці немає двох однакових рядків; рядки та стовпці можуть переглядатися у будь-якому порядку незалежно від їх інформаційного змісту. База даних, побудована за допомогою відносин, називається реляційною та в ідеалі має наступні переваги: ​​можливістю використання непідготовленими користувачами; простотою системи захисту (до кожного відносини задається правомірність доступу); незалежністю даних; можливістю побудови простої мови маніпулювання даними за допомогою алгебри відносин.

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

3. Вибір СУБД

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

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

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

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

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

Нижче наведено короткі характеристики деяких універсальних СУБД.

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

У системі допускається звернення до даних прикладних програм користувача, написаних мовою АССЕМБЛЕР, ПЛ/1, КОБОЛ, АЛГОЛ-60, ФОРТРАН-4.

Використовуються спеціальні вхідні мови (мова введення економічних показників, мова введення документів) та мова запитів, які задовольняють основним вимогам, що висуваються до мов опису даних та мов маніпулювання даними.

p align="justify"> Для роботи з даними, що мають ієрархічну структуру, служить спеціальний метод доступу. СУБД ІНЕС має систему формування вихідних повідомлень та систему візуалізації повідомлень, які дозволяють користувачеві задавати структуру документа та його реквізити, здійснювати пошук, зміну та коригування даних та виведення їх на дисплей.

СУБД КВАНТ-М являє собою систему реального часу, призначену для роботи на міні-ЕОМ і використовувану для вирішення завдань в інформаційно-пошукових та довідкових системах (фактографічних, бібліографічних, резервування замовлень тощо).

Програми користувача можуть бути написані мовами КОБОЛ, ФОРТРАН, БЕЙСІК-2 і звертаються до бази даних за допомогою САМ-інтерфейсу.

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

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

Мовою маніпулювання даними є мова КВАНТ СКРИПТ-М. Це англоподібна діалогова мова, призначена для ефективного пошуку та виділення записів у базі даних та виведення їх на дисплей.

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

4. Спеціалізовані бази даних

p align="justify"> Процес проектування спеціалізованої бази даних включає: логічне проектування, фізичне проектування, розробку спеціалізованої СУБД.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5. Розподілені бази даних

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

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

Проектування РБД може відбуватися за умов:

а) створення АСУ тільки починається і стоїть завдання вибору оптимальної структури РБД та розміщення окремих ЛБД;

б) існує певна кількість ЛБД та ВЦ і стоїть завдання розміщення додаткового числа ЛБД та оптимальної зміни структури зв'язків у системі;

в) формування географії та структури системи закінчено та стоїть завдання оптимального перерозміщення масивів та зміни топології зв'язків.

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

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

Вибір топології мережі ЛБД визначається характером їх інформаційних взаємозв'язків, напрямом та інтенсивністю інформаційних потоків, необхідною надійністю та достовірністю передачі інформації. Зазвичай користувачі прикріплюються до однієї ЛБД і через цю ЛБД зв'язуються з іншими базами даних РБД. Розрізняють такі типи структур зв'язків ЛБД в РБД: радіальну, радіально-вузлову, кільцеву, кожну з кожним, комбіновану (рис. 4, а - г). Найбільш надійною, зі швидким пошуком інформації є система зі структурою "кожен з кожним". p align="justify"> Інформаційні зв'язки такого типу характерні для об'єктів, підпорядкованих один одному тільки функціонально.

Стратегія пошуку впливає на кількість та розміщення структурної та потоки запитної інформації. За відсутності інформації, затребуваної користувачем у найближчій ЛБД, можуть бути запропоновані такі стратегії пошуку:

1) за структурною інформацією про розміщення даних у РБД відбувається пошук необхідної ЛБД та звернення до цієї ЛБД;

2) здійснюється пошук у ЛБД вищого рангу; якщо необхідна інформація відсутня, аналізується структурна інформація зміст всіх підлеглих ЛБД; якщо необхідної інформації немає, переходять до ЛБД вищого рівня ієрархії;

3) здійснюється звернення до керуючої ЛБД, де зберігається структурна інформація про всіх ЛБД;

4) здійснюється опитування всіх ЛБД або паралельно, або послідовно.

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

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

Стратегія 3 мінімізує структурну інформацію.

Стратегія 4 відрізняється великими потоками запитної інформації.

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