Дайте визначення автоматизованого робочого місця бухгалтера та охарактеризуйте його призначення 6 страница

Особливу категорію становлять файли для коригування інших файлів. Джерелом їх формування служать «Відомості про зміни». Кожен запис файлу для коригування містить спеціаль­ну ознаку включення, ліквідації або зміни запису [4].

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

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

Глава 5.2. Особливості розміщення інформації на машинних носіях

План

5.2.1. Поняття файлу, масивів даних і програмних масивів

5.2.2. Класифікація масивів даних

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

Пофайлова організація інформаційного забезпечення - це формування різних масивів. Класифікувати їх можна за різними ознаками: за змістом, способами використання, призначення, методом організації [3].

Файл - це сукупність однорідної інформації складу та послідовності полів, записаної на магнітному диску з присвоєнням імені. Термінологічно поняття «масив» і «файл» близькі за змістом. Це - сукупність однорідної жорстко організованої та пойменованої інформації. Для ідентифікації кожному файлу під час його запису присвоюється ім’я та розширення, що уточнює різновид­ність файлу [3].

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

За роллю обробки й технології використання масиви класифікуються так:

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

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

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

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

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

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

7. Службові масиви містять допоміжну інформацію, потрібну для обробки всіх видів масивів [3].

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

За внутрішньою організацією файли даних складають сукупність записів однакової структури. Структура запису файлу складається із заданої послідовності полів певного типу даних і довжини. Така структура файлу визначається на етапі постановки задач [3].

Глава 5.3. Основи організації баз і банків даних автоматизованої інформаційної системи. Ресурси баз даних

План

5.3.1. Поняття та складові компоненти автоматизованого банку даних

5.3.2. Ресурси баз даних

5.3.3. Моделі баз даних

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

Основними складовими компонентами автоматизованого банку даних є база даних і система керування базами даних. База даних - це поіменована, структурована сукупність взаємопов’язаних даних, які характеризують окрему предметну область і перебувають під управлінням системи керування базами даних. Система керування базами даних є програмно-логічним апаратом, який організує си­стему створення, оновлення і розв’язку основного компо­нента інтегрованої інформаційної бази - системи баз даних. Крім цього, система керування базами даних забезпечує вибірку даних із баз [4].

Крім баз даних і системи керування базами даних, до складу автоматизованого банку даних входять мовні, технічні та організаційні засоби [4].

Мовні засоби потрібні для опису даних, організації спілкування та виконання процедур пошуку і різних перетворень з даними. У сучасних системах керування базами даних для спрощення процедур пошуку даних у базі даних передбачена мова запитів. Найпоширенішими мо­вами запитів є дві мови: SQL та QBE. SQL (Structured English Query Language) - це структуро­вана англійська мова запитів, яку було створено фірмою ІВМ в межах роботи над проектом побудови системи керування реляційними БД на початку 70-х років XX ст. Мова запитів QBE (Query By Example) - це реалізація за­питів за зразком у вигляді таблиць. Для визначення запиту до бази даних користувач повинен заповнити таблицю QBE, яка надається системою, і визначити в ній критерій пошуку, вибору та перетворення даних [4].

До технічних засобів автоматизованого банку даних належать процесори, пристрої вводу і виводу даних, запам’ятовувальні пристрої, модеми, канали зв’язку [4].

Організаційні засоби автоматизованого банку даних охоплюють персонал, який пов’язаний із створенням і веденням бази даних, а також систему нормативно-технологічної та інструктивно-методичної документації з організації та експлуатації бази даних [4].

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

Вирішення проблеми багаторівневого представлення предметної області в базах даних вирішується введенням трьох рівнів: зовнішнього, концептуального і внутрішнього (рис. 11) [4].

Зовнішня модель - це частина множини структурованих об’єктів предметної області, які становлять інтерес для окремого користувача. Кожному користувачеві відповідає пев­на зовнішня модель. Під час розробки зовнішньої моделі підприємства визначають сферу застосування та загальний зміст баз даних. Ця модель створюється як складова частина планування інформаційної системи для організації, але не для проектування кон­кретної бази даних. Зовнішня модель даних, як правило, по­казує об’єкти високого рівня в організації та зв’язки між ними в графічній формі [4].

Рис. 11 Схема взаємозв’язку рівнів подання даних у базу даних

На рис. 12 показано графічне представлення фрагмента бази даних «Продукти» при побудові зовнішньої моделі даних. Найпопулярнішими позначками (нестандартними) для виконання цих схем є такі [4]:

Рис. 12 Графічне представлення фрагмента бази даних «Продукти» в зовнішній моделі даних

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

1. Ієрархічні моделі баз даних.

2. Сіткові моделі баз даних.

3. Реляційні моделі баз даних [4].

Найпоширенішими на сучасному ринку програмних продуктів є реляційні системи керування базою даних [4].

Концептуальна модель описує логічну структуру всієї бази даних, не залежить від конкретної системи керування базою даних, не вимагає докладної інформації фізичного проектування, наведена в схемах «об’єкт - зв’язок» (Entity-Relation - ER) метаданих (опису даних) [4].

У внутрішній моделі бази даних відображається використовувана технологія зберігання і доступу до даних. На внутрішньому (фізичному) рівні формується фізична модель бази даних, яка містить структури зберігання даних у пам’яті електронної обчислювальної машини, включаючи опис форматів даних, порядок їх логічного чи фізичного впорядку­вання, розміщення за типами пристроїв, а також характери­стики і шляхи доступу до даних [4].

При проектуванні фізичних баз даних необхідно вибрати систему керування базою даних, вибрати пристрої пам’яті, визначити методи доступу, спроектувати файли та індекси, визначити стратегію оновлення бази даних [4].

Внутрішня (фізична) модель бази даних описує фізичну структуру всієї бази даних, конкретизує, як дані з концептуальної моделі зберігають­ся у вторинній пам’яті, специфікації включають структури фізичних файлів і да­них, організацію збереження і структури індексів. Від параметрів фізичної моделі залежать обсяг пам’яті ЕОМ і час реакції системи на запити при функціонуванні бази даних. Фізичні параметри бази даних можна змінювати під час її експлуатації (не змінюючи при цьому опису інших рівнів) з метою підвищення ефективності функціонування системи [4].

Структура файлів бази даних визначається на етапах інфологічного і логічного проектування, а формування структури - на етапі фізичного проектування бази даних. Структура файлів - це поіменована сукупність логічно взаємозв’язаних атрибутів [4].

Глава 5.4. Реляційна модель даних

План

5.4.1. Особливості ієрархічної моделі даних

5.4.2. Особливості сіткової моделі даних

5.4.3. Особливості реляційних моделей даних

Модель даних - це система позначень для опису даних та операції щодо обробки даних [4].

Існують такі типи моделей баз даних: ієрархічна, сіткова, реляційна, - об’єктна орієнтована, напівструктурована. Перші три з перерахованих моделей баз даних показано на рис. 13 [4].

а

б

в

Рис. 13 Моделі бази даних: а – ієрархічна, б – сіткова, в - реляційна

Ієрархічна модель (рис. 13, а) визначається двома типами відношень: 1:1 та 1:N і подається у вигляді деревоподібних структур. Перевагою цієї моделі є простота моделювання предметних областей. Але не всі зв’язки можна врахувати за допомогою ієрархічної моделі, що створює певні труднощі при про­грамній реалізації. Наприклад, така модель спричиняє складнощі за наявності так званих симетричних запитів (наприклад, визначення товарів, що доставляються деякими постачальни­ками, і визначення постачальників деякого товару); при ви­ключенні з дерева вузла, що має підпорядковані вузли і введення нових вузлів у модель; за необхідності відображення відно­шень «багато-однозначне» і «багато-багатозначне» [4].

Використання сіткової моделі даних дає змогу представлен­ня зв’язків між реальними об’єктами, складніших порівняно з ієрархічною моделлю (рис. 13, б). За її допомогою можна моделювати відношення таким чином: 1:1, 1:N, N:1, N:N. За допомогою сіткової моделі можна подолати ті труднощі, які виникають при використанні ієрархічної моделі. Однак, оскільки зв’язки між даними в сітковій моделі зазначаються в явному вигляді, то користувач надто близький до фізичного рівня подання даних. Цей недолік ускладнює застосування сіткових моделей [4].

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

Таблиця 13

Дані для формування бази даних «Постачальники»

Домен - набір дозволених значень для певного атрибута (наприклад, тип даних, «стовпець»). Доменами табл. 13 є: код постачальника, назва постачальника, назва групи матеріалів, місцезнаходження постачальника, сума поставки матеріалів [4].

Відношення - обмежена підмножина декартового добутку одного або більше доменів (множина об’єктів, таблиця). Відношення подають у вигляді двовимірної таблиці (у нашому випадку вся табл. 13) [4].

Схема - реляційна назва та сукупність (обмежена) назв атрибутів у відношенні (формально відповідність назв атрибутів доменам). Приклад схеми. Для табл. 13 схема «Постачальники» (код постачальника, назва постачальника, назва групи матеріалів...) [4].

Кортеж - компоненти залежності «рядок». Кортежі у відношенні «Постачальники»:

(1, АТ «Фаркомп», фарби, Полтавська обл., 60000,00)

(2, ЗАТ «Україна», сталь, Донецька обл., 180000,00) тощо [4].

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

Схема в реляційній моделі подається:

1. Графічно, наприклад:

ПОСТАЧАЛЬНИКИ

2. В текстовому вигляді, наприклад:

ПОСТАЧАЛЬНИКИ (код постачальника, назва постачальника, ...) [4].

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

Таблиця 14

Приклад функціональної залежності

Суперключ - атрибут (або сукупність атрибутів), що визна­чає лише рядок у таблиці. У табл. 13 суперключем буде «код постачальника» [4].

Потенційний ключ, якщо один або кілька доменів однознач­но визначають будь-який кортеж у відношенні. Потенційним ключем може бути «Назва постачальника», або «Код постачальника, назва постачальника» [4].

Первинний ключ - потенційний ключ, який однозначно ідентифікує окремий об’єкт (нульові величини не дозволяються). Первинним ключем у відношенні «Постачальники» є «Код постачальника» (він же є і суперключем) [4].

Зовнішній (вторинний) ключ - атрибут (або сукупність атрибутів), який має відповідати первинному ключу в деякій іншій таблиці або дорівнює нулю (цілісність на рівні посилань). Зовнішній ключ допускає більш ніж одну залежність в базі даних [4].

Розглянемо, наприклад, ще одне відношення «Банк» (код банку, назва банку, адреса банку). Зв’язкове відношення «Банк-Постачальники» (код банку, код постачальника) буде сполучним між двома відношеннями «Банк» і «Постачальники». Ключ «код банку» є первинним у відношенні «Банк», а ключ «Код постачальника» - первинним у відношенні «Постачальники». Тому у зв’язковому відношенні «Банк-Постачальники» вони є вторинними або зовнішніми. Крім ключів, за якими встановлюють зв’язок у зв’язковому відношенні, можуть бути ще й інші атрибути, які функціонально залежать від цього складового ключа [4].

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

1. Графічно:

2. В текстовому вигляді:

ПОСТАЧАЛЬНИКИ (код, назва постачальника, місцезнаходження постачальника).

ПОСТАВКА ТОВАРІВ (код товару, назва товару, код постачальника, сума поставки) [4].

До переваг реляційної моделі можна зарахувати простоту розробки мови маніпулювання даних, оскільки пошук даних зводиться до застосування різних операцій над множинами. Недоліком цієї моделі є те, що вона не охоплює весь діапазон відомих структур даних. Наприклад, у ній відсутній еквівалент ієрархічної організації записів, оскільки при заміні відношен­ня вигляду 1:N на N:N необхідно ввести нове відношення [4].

У реляційній базі даних накладається ще одне обмеження - відношення мають бути нормалізованими [4].

Нормалізація - це процедура, в результаті якої ліквідують­ся складні домени (містять інші домени), зв’язані ієрархічним відношенням [4].

Відношення є нормалізованим, якщо всі його елементи скалярні [4].

Глава 5.5. Елементи теорії нормалізації

План

5.5.1. Мета нормалізації

5.5.2. Етапи нормалізації відношень

Основна ідея нормалізації - розбити великий «недобре» спроектований зв’язок на кілька «добре спроектованих» зв’язків. У результаті нормалізації склад атрибутів відношень база даних повинна відповідати таким вимогам:

1. Між атрибутами мають виключатися небажані функціональні залежності.

2. Групування атрибутів не повинно мати збиткового дублю­вання даних.

3. Забезпечувати обробку і поновлення атрибутів без усклад­нень [4].

До значень «поганого проектування» можна зарахувати: введення, вилучення та аномалії оновлення. Хороший проект бази даних:

Клієнт (ім’я, адреса, номер телефону)

Резерви (назва*, адреса*, номер*, дата*)

Рейс (номер, дата, час) [4].

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

Аномалії введення/вилучення. Що буде, якщо ми вилучимо запис про такого клієнта, який вже зробив попереднє замовлення на рейс? Яким повинно бути рішення? [4].

Аномалії оновлення. Що буде, якщо змінюється адреса клієнта в базі даних «Клієнт»? Яким повинно бути рішення? [4].

Апарат нормалізації був розроблений американським вченим Е.Ф.Коддом. Він виділив три нормальні форми (скорочена назва 1НФ, 2НФ, 3НФ). Найдосконаліша з них - 3НФ. Тепер вже відомі і визначені 4НФ, 5НФ [4].

Нормалізація відношень виконується так (рис. 14) [4].

Рис. 14. Схема етапів нормалізації відношень

1-й крок (перша ітерація) - зведення відношень до 1НФ [4].

Відношення в 1НФ мають відповідати таким вимогам:

1. Всі атрибути відношення мають бути атомарними (неподільними).

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

3. Імена стовпців мають бути різними, а значення однорідними (мати однаковий формат).

4. Порядок рядків у таблиці несуттєвий [4].

Кожне відношення бази даних містить структурну (задається схе­мою відношення) і семантичну (функціональні зв’язки між атрибутами) інформацію [4].

Приклад. Заробітна плата є атомарним атрибутом. Перелік авторів не є атомарним атрибутом. Попередня інформація про заробітну плату не є атомарною [4].

2-й крок (друга ітерація). Виявляються ключі-атрибути та аналізуються відповідні залежності з метою вилучення непов­них функціональних залежностей [4].

Означення 1. Атрибут Б функціонально залежить від А у відношенні R тоді, коли в кожний момент часу одному і тому ж значенню А відповідає не більш ніж одне значення Б. Функціональній залежності відповідає відношення 1:1 між атрибутами [4].

Приклад. Продукт (Код продукту, Назва, Кінцева обробка, Приміщення, Ціна).

Код продукту → Назва, Кінцева обробка, Приміщення, Ціна. Назва, Кінцева обробка, Приміщення → Код продукту.

Не може бути два продукти з однаковою назвою, які кінце­во обробляються та використовуються в одному приміщенні [4].

Означення 2. Атрибут перебуває в повній функціональній залежності, якщо він залежить від всього ключа і не залежить від його складових [4].

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

Основна ідея декомпозиції - розкласти на частини великий «недобре спроектований зв’язок» на декілька малих «добре спроектованих» зв’язків так, щоб зберегти властивість розкладення (декомпозиції) без втрат при об’єднанні і зберегти залежності (без втрати функціональних залеж­ностей) [4].

Приклад. Візьмемо відношення Клієнт (Код клієнта, Ім’я, Адреса, № рахунку, Тип, Залишок).

Якщо ми розділимо його на два:

Покупець (Код клієнта, Ім’я, Адреса)

Рахунок (Номер рахунку, Тип, Залишок),

то ми втрачаємо інформацію. Однак, якщо КЛІЄНТ розкласти на:

Покупець (Код клієнта, Ім’я, Адреса) та

Рахунок (Код клієнта, № рахунку, Тип, Залишок),

то Клієнт можна реконструювати без жодної втрати інформації [4].

3-й крок (третя ітерація) нормалізації - це вилучення транзитивних залежностей, тобто залежностей між неключовими атрибутами [4].

Наприклад, маємо відношення R (А*, В, С), в якому атрибут В не залежить безпосередньо від ключа, а С залежить від неключового атрибута В, який залежить від А, то тоді С транзи­тивно залежить від А [4].

Транзитивні залежності вилучають також за допомогою декомпозиції відношення на інші два чи більше відношень, які не містять транзитивних відношень і об’єднання яких дасть початкове відношення. Внаслідок декомпозиції отримаємо два нових відношення R1 (А*, В) та R2 (В*, С) [4].

Приклад. Продаж (Ціна, Назва товару, Продавець, Область) [4].

Функціональні залежності:

Ціна → Назва товару, Продавець, Область

Продавець → Область

У цьому прикладі транзитивною залежністю є Продавець → Область [4].

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

Багатозначна залежність - це різновид функціональної залежності. Атрибут В перебуває у багатозначній залежності від атрибута А тоді, коли одному значенню атрибута А відповідає багато значень атрибута В. Наприклад, між атрибутами код структурного підрозділу: табельний номер = 1:Б, оскільки в одному підрозділі може працювати багато співробітників. Тобто багатозначній залежності відповідає відношення 1:Б між атрибутами [4].

Приклад. Візьмемо базу даних Заняття (Курс, Викладач, Книжка), де Заняття (С, Т, В) означає, що викладач Т може читати курс С і що В - це необхідний підручник для С [4].

Це означає, що для викладання кожного курсу є перелік викладачів і набір придатних підручників, і що ці два набори є незалежними один від одного [4].

Зважаючи на наведений приклад, багатозначна залежність - це такий тип залежності, який існує, коли в таблиці зв’язків є щонайменше три атрибути (наприклад, А, В та С) і для кож­ного значення А існує чітко визначений набір значень В і чітко визначений набір значень С, і ці два набори (В і С) є незалежними один від одного [4].

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

Може вчити (Курс, Викладач) та

Книжка курсу (Курс, Книжка)

При такому розподілі ми не втрачаємо ніякої інформації (Базу даних Заняття можна реконструювати на основі цих двох таблиць) [4].

Будь-яку таблицю зв’язків можна без втрат розділити на еквівалентний набір таблиць у 4НФ (як це зроблено вище) [4].

Декомпозиція початкового відношення на кілька інших має гарантувати його оборотність, тобто забезпечувати отримання початкового відношення об’єднанням відношень, знайдених унаслідок декомпозиції [4].

Проте, не завжди декомпозиція гарантує оборотність. Відношення, яке містить більш як три багатозначні залежності, потребує спеціальних заходів щодо забезпечення оборотності декомпозиції. Для цього існує 5НФ. При декомпозиції з 4НФ отримують такі проекції, щоб кожна з них містила не менш як один можливий ключ і щонайменше один неключовий атрибут початкового відношення [4].

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

Глава 5.6. SQL: мова структурованих запитів

План

5.6.1. Призначення та особливості мови структурованих запитів SQL

5.6.2. Приклади використання мови структурованих запитів SQL

У сучасних системах керування базами даних для спрощення процедур пошуку даних у базі даних передбачена мова запитів [4].

Мова запитів SQL (Strucured English Query Language - структурована англійська мова запитів) була створена фірмою ІВМ у межах роботи над проектом побудови системи управлін­ня реляційними базами даних на початку 70-х років XX ст. [4].

Робота щодо стандартизації, яка здійснювалася ANSI (Національним інститутом стандартизації США), призвела до створен­ня de facto стандарту запитів для реляційних баз даних. Немає «уні­версального» SQL, існує загальний знаменник. Ядром існуючо­го нині стандарту SQL-86, який часто називають SQL-2 чи SQL-92, є функції, що реалізовані практично в усіх відомих комерційних варіантах мови [4].