Призначення баз даних. Переваги БД і їх недоліки.

Призначення баз даних. Переваги БД і їх недоліки.

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

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

Існує три основні моделі баз даних: ієрархічна, мережна та реляційна. Відповідно розрізняють ієрархічні, сіткові і реляційні бази даних. Мережна та ієрархічні бази даних отримали найбільше поширення в 60-80 роках. На теперішній час абсолютна кількість користувачів використовує реляційні бази даних.

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

Сіткова модель - це деревовидна структура, яка не має обмежень на кількість зв’язків у вузлі. Переваги сіткової моделі полягають в наступному:

1. число зв’язків у вузлі не обмежене;

2. найкраща наочність та простота організації структури баз даних;

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

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

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

1. математичним апаратом для роботи цієї моделі є алгебра відношень (реляційна алгебра або алгебра Кодда);

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

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

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

 

Трирівнева архітектура систем баз даних.

У комп'ютерних технологіях трирівнева архітектура, синонім триланкова архітектура (англ. three-tier або Multitier architecture) передбачає наявність наступних компонент програми: клієнтський застосунок (зазвичай говорять «тонкий клієнт» або термінал), підключений до сервера застосунків, який в свою чергу підключений до серверу бази даних.

Огляд архітектури

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

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

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

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

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

Переваги

У порівнянні з клієнт-серверною або файл-серверною архітектурою можна виділити такі переваги трирівневої архітектури:

· масштабованість

· конфігурованість — ізольованість рівнів один від одного дозволяє (при правильному розгортанні архітектури) швидко і простими засобами переконфігурувати систему при виникненні збоїв або при плановому обслуговуванні на одному з рівнів

· високий рівень безпеки

· висока надійність

· низькі вимоги до швидкості каналу (мережі) між терміналами і сервером застосунків

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

Недоліки

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

· вища складність створення застосунків

· складніша у розгортанні і адмініструванні

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

· високі вимоги до швидкості каналу (мережі) між сервером бази даних і серверами застосунків.

Функції СУБД

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

— забезпечувати одержання загальних і/або деталізованих звітів за підсумками роботи;

— дозволяти легко визначати тенденції зміни найважливіших показників;

— забезпечувати одержання оперативної інформації без істотних затримок;

— виконувати точний і повний аналіз даних.

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

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

Основні функції СУБД

Безпосереднє управління даними в зовнішній пам'яті

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

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

 

ПЕРЕВАГИ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

НЕДОЛІКИ

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

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

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

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

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

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

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

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

 

Ієрархічна модель даних

Часто об'єкти перебувають у відношеннях, що називають ієрархічними: відношення «частина — ціле» (наприклад, адміністративна область складається з районів, сільських і міських рад, населених пунктів та ін.); видове відношення (наприклад, будинки бувають житлові, виробничі та ін.); відношення підпорядкованості (наприклад, губернатор — мер міста).

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

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

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

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

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

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

У мережній моделі даних поняття головних і підлеглих об'єктів дещо розширені. Будь який об'єкт може бути і головним, і підлеглим (у мережній моделі головний об'єкт позначається терміном «власник набору», а підлеглий — терміном «член набору»). Той самий об'єкт може одночасно виконувати і роль власника, і роль члена набору. Це означає, що кожний об'єкт може брати участь у будь-якій кількості взаємозв'язків.

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

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

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

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

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

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

Назва «реляційна» (relational) пов'язана з тим, що кожен запис у таблиці даних містить інформацію, яка стосується (related) якогось конкретного об'єкта. Крім того, зв'язані між собою (тобто такі, що знаходяться в певних відношеннях — relations) дані навіть різних типів в моделі можуть розглядатися як одне ціле.

Таблиця має такі властивості:

· кожний елемент таблиці являє собою один елемент даних;

· повторювані групи відсутні;

· усі стовпці в таблиці однорідні; це означає, що елементи стовпця мають однакову природу;

· стовпцям присвоєні унікальні імена;

· у таблиці немає двох однакових рядків.

Порядок розміщення рядків і стовпців у таблиці довільний; таблиця такого типу називається відношенням. У сучасній практиці для рядка використовується термін «запис», а для стовпця термін «поле».

Основною відмінністю пошуку даних в ієрархічних, мережних і реляційних базах даних є те, що ієрархічні і мережні моделі даних здійснюють зв'язок і пошук між різними об'єктами за структурою, а реляційні — за значенням ключових атрибутів (наприклад, можна знайти всі записи, значення яких у полі «номер будинку» дорівнює 3, але не можна знайти 3-й рядок).

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

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

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

 

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

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

Назва «реляційна» (relational) пов'язана з тим, що кожен запис у таблиці даних містить інформацію, яка стосується (related) якогось конкретного об'єкта. Крім того, зв'язані між собою (тобто такі, що знаходяться в певних відношеннях — relations) дані навіть різних типів в моделі можуть розглядатися як одне ціле.

Таблиця має такі властивості:

· кожний елемент таблиці являє собою один елемент даних;

· повторювані групи відсутні;

· усі стовпці в таблиці однорідні; це означає, що елементи стовпця мають однакову природу;

· стовпцям присвоєні унікальні імена;

· у таблиці немає двох однакових рядків.

Порядок розміщення рядків і стовпців у таблиці довільний; таблиця такого типу називається відношенням. У сучасній практиці для рядка використовується термін «запис», а для стовпця термін «поле».

Основною відмінністю пошуку даних в ієрархічних, мережних і реляційних базах даних є те, що ієрархічні і мережні моделі даних здійснюють зв'язок і пошук між різними об'єктами за структурою, а реляційні — за значенням ключових атрибутів (наприклад, можна знайти всі записи, значення яких у полі «номер будинку» дорівнює 3, але не можна знайти 3-й рядок).

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

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

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

 

12. Основні поняття та визначення нормалізації.

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

 

Можливості СУБД

· Дозволяється створювати БД (здійснюється за допомогою мови визначення даних DDL (Data Definition Language))

· Дозволяється додавання, оновлення, видалення та читання інформації з БД (за допомогою мови маніпулювання даними DML, яку часто називають мовою запитів)

· Можна надавати контрольований доступ до БД за допомогою:

1.Системи забезпечення захисту, яка запобігає несанкціонованому доступу до БД;

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

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

 

Безумовна вибірка

Структура найпростішого запиту на вибірку даних

SELECT список результуючих стовпчиків

FROM список таблиць-джерел даних

WHERE умова виводу стрічок;

Оператор належності IN

Оператори IN (рівний довільному елементу із списку) і NOT IN (не рівний жодному елементу із списку) дозволяють ускладнювати умови відбору результуючих стрічок.
Наприклад, вибрати студентів окремих міст

SELECT * FROM exam_marks WHERE city IN ("Курськ", "Москва");

або тих студентів, які не отримували ніколи деяких оцінок

SELECT * FROM exam_marks WHERE mark NOT IN (3, 5);

Оператор діапазону BETWEEN

Оператор BETWEEN дозволяє перевірити входження елемента в заданий інтервал із його межами включно

SELECT * FROM subject WHERE city BETWEEN "К" AND "М";

Оператор подібності LIKE

Пошук стрічкових значень по заданому зразку, який використовує символи: “_” – наявність, у вказаному місці одного довільного символу, •“%” - наявність, у вказаному місці довільної послідовності символів. Цей засіб часто використовують для вибору слів, що починаються на певну букву

SELECT * FROM student WHERE surname LIKE ”П%”;

Також ми можемо відбирати слова, деякі символи в яких пишуться неоднозначно, наприклад

SELECT * FROM subject WHERE subj_name LIKE ”Комп_ютер%”;

Оператор належності IN

Оператори IN (рівний довільному елементу із списку) і NOT IN (не рівний жодному елементу із списку) дозволяють ускладнювати умови відбору результуючих стрічок.
Наприклад, вибрати студентів окремих міст

SELECT * FROM exam_marks WHERE city IN ("Курськ", "Москва");

або тих студентів, які не отримували ніколи деяких оцінок

SELECT * FROM exam_marks WHERE mark NOT IN (3, 5);

Оператор діапазону BETWEEN

Оператор BETWEEN дозволяє перевірити входження елемента в заданий інтервал із його межами включно

SELECT * FROM subject WHERE city BETWEEN "К" AND "М";

Оператор подібності LIKE

Пошук стрічкових значень по заданому зразку, який використовує символи: “_” – наявність, у вказаному місці одного довільного символу, •“%” - наявність, у вказаному місці довільної послідовності символів. Цей засіб часто використовують для вибору слів, що починаються на певну букву

SELECT * FROM student WHERE surname LIKE ”П%”;

Також ми можемо відбирати слова, деякі символи в яких пишуться неоднозначно, наприклад

SELECT * FROM subject WHERE subj_name LIKE ”Комп_ютер%”;

DROP TABLE

DROP TABLE - данный запрос используется для удаления таблиц.

1	DROP TABLE table_name

DROP DATABASE

DROP DATABASE - данный запрос используется для удаления баз данных.

1	DROP DATABASE database_name

TRUNCATE TABLE

TRUNCATE TABLE - данный запрос используется для удаления данных внутри таблицы, не трогая саму таблицу.

1	TRUNCATE TABLE table_name

 

INNER JOIN - возвращает строки, когда есть хотя бы одно совпадение в обеих таблицах.

Синтаксис SQL INNER JOIN

1234	SELECT column_name(s)FROM table_name1INNER JOIN table_name2ON table_name1.column_name=table_name2.column_name

- Замечание: INNER JOIN это тоже что и JOIN.

 

 

Призначення DataReader?

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

 

Призначення DataAdapter?

Класи, що реалізують інтерфейс IDbDataAdapter, застосовуються для читання даних і подальшої їх завантаження в клас DataSet. Для доступу до даних такі класи повинні вказувати на відповідний клас реалізації IDbConnection. Крім завантаження даних в DataSet інтерфейс IDbDataAdapters визначає запити, що використовуються для роботи з основною базою даних по вилученню та занесенню інформації. Реалізують інтерфейс IDbDataAdapter об’єкти мають багато схожих рис з класом DataSetProvider в Delphi. Класи реалізації інтерфейсу IDbDataAdapter вимагають наявності, принаймні, одного SQL-оператора, а в багатьох випадках не менше чотирьох. Як мінімум, такі класи вимагають SQL-оператора SELECT для ідентифікації записи, призначеної для завантаження. Якщо дані, до яких здійснюють доступ класи реалізації IDbDataAdapter, можуть бути змінені, внесені або видалені, то мають бути присутні відповідні SQL-оператори, які наказують, як ці дані оновлюються, вставляються або видаляються. SQL-оператори, які застосовуються в інтерфейсі IDbDataAdapter, пов’язані з властивостями SelelectCommand, InsertCommand, UpdateCommand і DeleteCommand засоби реалізації IDbDataAdapter. Ці команди є прикладами класів, що реалізують інтерфейс IDbCommand. Всі класи реалізації інтерфейсу IDbDataAdapter можуть приймати SQL-оператор SELECT як параметр, принаймні, одного зі своїх перевантажених конструкторів. Якщо один з цих конструкторів використовується для створення екземпляра IDbDataAdapter, то немає необхідності явно привласнювати клас реалізації IDbCommand властивості SelectCommand. Замість явного привласнення SQL-операторів властивостями InsertCommand, UpdateCommand і DeleteCommand можна використовувати відповідні класи компоновки команд для генерації відповідних SQL-команд. Тому прикладами служать класи SQLCommandBuilder і OleDbCommandBuilder.

 

Призначення DbConnection?

Класи, що реалізують інтерфейс IDbConnection, використовуються для встановлення з’єднання з джерелом даних. У більшості випадків джерелом буде служити база даних, відповідна конкретного сервера баз даних. Проте, завдяки підтримці з’єднань OleDB і ODBC, можна приєднуватися до будь-якого джерела даних, для якого є провайдер OleDb і ODBC-драйвера. Наприклад, до таких джерел відносяться бази даних Paradox, dBase і MS Access. Інші класи, які реалізують інші перераховані на діаграмі інтерфейси, засновані на з’єднанні, що підтримується класом реалізації інтерфейсу IDbConnection. Проте, при використанні класу DataSet, який не заносить свої дані в основну БД (наприклад, коли DataSet отримує дані з XML-файла), немає необхідності використовувати клас, який реалізує інтерфейс IDbConnection. Кожен клас реалізації IDbConnection володіє одним або більше конструкторами, що використовуються для встановлення з’єднання з джерелом даних. Цей інтерфейс також забезпечує контроль над транзакціями бази даних. Інтерфейс IDbConnection визначає властивості, які подібні до тих, що надаються компонентом SQLConnection ADO-методів dbExpress і ADOConnection або компонентом TSession процесора баз даних BDE.

 

Призначення DbCommand?

Реалізують інтерфейс IDbCommand класи використовуються для обробки запитів до основної бази даних. Такі класи повинні бути пов’язані з відповідними класами реалізації інтерфейсу IDbConnection. У рамках інтерфейсу IDbCommand запити можуть містити параметри. Якщо це так, то слід зв’язати дані з індивідуальними параметрами, використовуючи клас, який реалізує інтерфейс IDbDataParameter. Всі параметри, пов’язані з класом реалізації інтерфейсу IDbCommand, перебувають у властивості Parameters відповідного класу реалізації. Ця властивість є прикладом класу, що реалізовує інтерфейс IDataParameterCollection. Кл