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

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

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

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

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

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

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

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

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

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

Атрибут(або це)- це деякий показник, який характеризує якийсь об'єкт і приймає для конкретного екземпляра об'єкта деяке числове, текстове чи інше значення. Інформаційна системаоперує наборами об'єктів, спроектованими стосовно даної предметної області, використовуючи при цьому конкретні значення атрибутів(даних) тих чи інших об'єктах. Наприклад, візьмемо в якості набору об'єктів класи у школі. Число учнів у класі - це дане, яке приймає числове значення(в одного класу 28, в іншого-32). Назва класу - це дана, яка приймає текстове значення(в одного – 10А, в іншого – 9Б і т. д.).

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

Основоположником теорії реляційних баз даних вважається співробітник фірми IBM доктор Е. Кодд, який опублікував 6 (червень 1970 статтю A Relational Model of Data для Великої Shared Data Banks(Реляційна модель даних великих колективних банків даних). У цій статті вперше використано термін «реляційна модель даних. Теорія реляційних баз даних, розроблена в 70-х роках США доктором Е. Коддом, має під собою потужну математичну основу, що описує правила ефективної організації даних. Розроблена Е. Коддом теоретична база стала основою розробки теорії проектування баз даних.

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

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

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

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

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

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

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

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

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

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

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

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

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

При описі моделі реляційної бази даних для одного і того ж поняття часто вживають різні терміни, що залежить від рівня опису (теорія чи практика) та системи (Access, SQL Server, dBase). У табл. 2.3 наведено зведену інформацію про терміни, що використовуються.

Таблиця 2.3.Термінологія баз даних

Теорія БД____________ Реляційні БД_________ SQL Server __________

Відношення (Relation) Таблиця (Table) Таблиця (Table)

Кортеж (Tuple) Запис (Record) Рядок (Row)

Атрибут (Attribute) Поле (Field) _______________ Стовпець або колонка (Column)

Реляційні бази даних

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

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

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

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

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

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

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

Реляційна база даних – основні поняття

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

Справді, у вузькому значенні слова, база даних - це певний набір даних, необхідні роботи (актуальні дані). Однак дані – це абстракція; ніхто ніколи не бачив "просто дані"; вони не виникають і не існують власними силами. Дані суть відображення об'єктів реального світу. Нехай, наприклад, потрібно зберігати відомості про деталі, що надійшли на склад. Як об'єкт реального світу – деталь – буде відображено у базі даних? Щоб відповісти на це питання, необхідно знати, які ознаки або сторони деталі будуть актуальні, необхідні для роботи. Серед них можуть бути назва деталі, її вага, розміри, колір, дата виготовлення, матеріал, з якого вона виготовлена ​​і т.д. У традиційній термінології об'єкти реального світу, відомості про які зберігаються в базі даних, називаються сутностями – entities (нехай це слово не лякає читача – це загальноприйнятий термін), а їх актуальні ознаки – атрибутами (attributes).

Кожна ознака конкретного об'єкта має значення атрибута. Так, деталь "двигун" має значення атрибута "вага", що дорівнює "50", що відображає той факт, що даний двигун важить 50 кілограмів.

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

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

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

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

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

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

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

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

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

Ці значення не виникають із повітря. Вони вибираються з багатьох можливих значень атрибута об'єкта, яке називається доменом (domain). Так, значення у стовпці матеріал вибираються з безлічі імен усіх можливих матеріалів – пластмас, деревини, металів тощо. Отже, у стовпці Матеріал принципово неможлива поява значення, якого немає у відповідному домені, наприклад, "вода" або "пісок".

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

1. Основні поняття бази даних.

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

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

Малюнок 2. Взаємозв'язок таблиць бази даних.

Таблиці неможливо зберігати і обробляти, якщо в базі даних відсутні дані про дані, наприклад, описувачі таблиць, стовпців і т.д. Їх називають зазвичай метаданими. Метадані також представлені в табличній формі та зберігаються у словнику даних (data dictionary).

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

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

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

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

Мова SQL

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

Поява та розвитку цієї мови як засобу опису доступу до бази даних пов'язано зі створенням теорії реляційних баз даних. Прообраз мови SQLвиник у 1970 році у рамках науково-дослідного проекту System/R, робота над яким велася в лабораторії Санта-Тереза ​​фірми IBM. Нині SQL – це стандарт інтерфейсу з реляційними СУБД. Популярність його настільки велика, що розробники нереляційних СУБД (наприклад, Adabas) постачають свої системи SQL-інтерейсом.

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

SQL не є мовою програмування у традиційному поданні. На ньому пишуться не програми, а запити до бази даних. Тому SQL – декларативна мова. Це означає, що з його допомогою можна сформулювати, що необхідно отримати, але не можна вказати, як це зробити. Зокрема, на відміну процедурних мов програмування (Сі, Паскаль, Ада), у мові SQL відсутні такі оператори, як if-then-else, for, while тощо.

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

Запит на мові SQL складається з одного або декількох операторів, які йдуть один за одним і розділені крапкою з комою. Нижче в таблиці 1перераховані найважливіші оператори, які входять до стандарту ANSI/ISO SQL.

Таблиця 1. Основні оператори мови SQL.

У запитах на мові SQL використовують імена, які однозначно ідентифікують об'єкти бази даних. Зокрема це - ім'я таблиці (Деталь), ім'я стовпця (Назва), а також імена інших об'єктів у базі, які відносяться до додаткових типів (наприклад, імена процедур та правил), про які йтиметься Розд.Сервер бази даних . Поряд із простими, використовуються також складні імена - наприклад, кваліфікаційне ім'я стовпця (qualified column name) визначає ім'я стовпця та ім'я таблиці, якій він належить (Деталь.Вага). Для простоти в прикладах імена будуть записані російською мовою, хоча на практиці цього робити не рекомендується.

Кожен стовпець у будь-якій таблиці зберігає дані певних типів. Розрізняють базові типиданих - рядки символів фіксованої довжини, цілі та речові числа, і додаткові типи даних - рядки символів змінної довжини, грошові одиниці, дату і час, логічні дані (два значення - "ІСТИНА" та "БРЕХНЯ"). У мові SQL можна використовувати числові, рядкові, символьні константи та константи типу "дата" та "час".

Розглянемо кілька прикладів.

Запит "визначити кількість деталей складі всім типів деталей" реалізується так:

SELECT Назва, Кількість

FROM Деталь;

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

Запит "які деталі, виготовлені зі сталі, зберігаються на складі?", сформульований мовою SQL, виглядає так:

FROM Деталь

WHERE Матеріал = "Сталь";

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

Запит "визначити назву та кількість деталей на складі, які виготовлені з пластмаси та важать менше п'яти кілограмів" буде записано наступним чином:

SELECT Назва, Кількість

FROM Деталь

WHERE Матеріал = "Пластмаса"

AND Вага< 5;

Результат запиту - таблиця з двох стовпців - Назва, Кількість, яка містить назву та кількість деталей, виготовлених з пластмаси та важать менше 5 кг. По суті, операція вибірки є операцією утворення спочатку горизонтальної проекції (знайти всі рядки таблиці Деталь, у яких Матеріал = "Пластмаса" та Вага< 5), а затем вертикальной проекции (извлечь Название и Количество из выбранных ранее строк).

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

Припустимо, що сформульовано запит до бази даних.

SELECT Назва Кількість, Матеріал

FROM Деталь

WHERE Номер = "Т145-А8";

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

Якщо ж було попередньо створено індекс по стовпцю Номер таблиці Деталь, час пошуку у таблиці буде скорочено до мінімуму. Індекс міститиме значення зі стовпця Номер та посилання на рядок із цим значенням у таблиці Деталь. При виконанні запиту СУБД спочатку знайде в індексі значення "Т145-А8" (і зробить це швидко, оскільки індекс упорядкований, а його рядки невеликі), а потім за посиланням в індексі визначить фізичне розташування рядка, що шукається.

Індекс створюється оператором SQL CREATE INDEX (СТВОРТИ ІНДЕКС). У даному прикладіоператор

CREATE UNIQUE INDEX Індекс деталі

ON Деталь (Номер);

дозволить створити індекс з ім'ям "Індекс деталі" за стовпцем Номер таблиці Деталь.

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

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

Обробка транзакцій спирається на журнал, який використовується для відкату транзакцій та відновлення стану бази даних. Докладніше про транзакції буде сказано в Розд.Обробка транзакцій .

Завершуючи обговорення мови SQL, ще раз наголосимо, що це - мова запитів. На ньому не можна написати складну прикладну програму, яка працює з базою даних. Для цієї мети в сучасних СУБД використовується мова четвертого покоління (Forth Generation Language - 4GL), що має як основні можливості процедурних мов третього покоління (3GL), таких як Сі, Паскаль, Ада, так і можливістю вбудувати в текст програми оператори SQL, а також засобами управління інтерфейсом користувача (меню, формами, введенням користувача тощо). Сьогодні мова 4GL – це один із фактичних стандартів засобів розробки додатків, що працюють з базами даних.

Реляційні БД

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

У реляційних базахданих прийнято такі позначення:

Ставлення – таблиця;

Поле-набір однотипних записів для кількох об'єктів (стовпець);

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

Атрибут – запис у рядку одного поля.

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

Ключові поля

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

Розрізняють наступні видиключів:

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

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

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

Залежно кількості полів утворюючих ключ виділяють:

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

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

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

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

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

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

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

ІІ. Мережева модель

ІІІ. Реляційна модель

записполе

ієрархічнихі мережевих моделей зовнішніх ключів

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

Реляційна БД

* Ставлення

* Атрибут стовпця (поля)таблиці.

* Тип даних

* Зв'язок ключем.

* Об'єднання

Основними функціямиРСУБД є:

· Визначення даних

· Обробка даних

· Управління даними

Microsoft Access

Вікно БД в Access

Режими роботи з об'єктами

Кнопки для роботи з об'єктами БД розташовані на панелі інструментів вікна БД:

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

Конструктор– Перехід до режиму налаштування вибраного об'єкта.

Створити– дозволяє розпочати створення нового об'єкта вибраного типу.

7. Робота з таблицями

Щоб створити таблицю, потрібно перейти до списку таблиць та натиснути кнопку Створити . З'явиться нове діалогове вікно Нова таблиця:

Таблицю в Access можна створити кількома способами:

· побудувати нову таблицю«з нуля», скориставшись Конструктором;

· запустити Майстер таблиць – спеціальну програму, що пропонує створити таблицю в покроковому режиміна базі типових рішень, що є в Access;

· Імпортувати таблицю БД з файлу будь-якої програми, наприклад, FoxPro або Excel.

Завдання імені поля

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

Визначення типу даних

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

Ø Текстовий- для зберігання звичайного текстуз максимальною кількістюсимволів 255.

Ø Поле MEMO- для зберігання великих обсягівтексту до 65535 символів.

Ø Числовий– для зберігання дійсних чисел.

Ø Дата час- для зберігання календарних датта поточного часу.

Ø Грошовий- Ці поля містять грошові суми.

Ø Лічильник– для визначення унікального системного ключатаблиці. Зазвичай використовується для порядкової нумераціїзаписів. При додаванні до таблиці нового записузначення цього поля збільшується на 1 (одиницю). Значення у таких полях не оновлюються.

Ø Логічний – для зберігання даних, що приймають значення: Так або Ні.

Ø Поле об'єкту OLE– для зберігання об'єктів, створених в інших програмах.

Опис властивостей полів

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

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

Якщо тип даних – числовий, допустимі наступні значеннявластивості Розмір поля:

Зауваження. У разі перетворення поля на менше за розміром, може статися втрата даних.

Ø Формат поля– формат відображення даних на екрані чи друку. Як правило, використовується формат, заданий за умовчанням.

Ø Число десяткових знаків- Задає для числового та грошового типу даних число десяткових знаків після коми.

Ø Маска введення- Визначає форму, в якій дані вводяться в поле (засіб автоматизації введення даних).

Ø Підпис– позначення поля, яке буде використовуватися для відображення поля в таблиці, формі або звіті. Якщо це значення не визначено, як підпис буде взято ім'я поля.

Ø Значення за замовчуванням – стандартне значення, що автоматично вводиться в поле при формуванні нового запису даних.

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

Ø Повідомлення про помилку– задає текст повідомлення, що виводиться на екран у разі порушення умови на значення.

Ø Обов'язкове поле- Визначає, чи може дане поле містити значення Null (тобто залишатися порожнім), або потрібно обов'язково вводити в це поле дані.

Ø Індексоване поле– використовується для операцій пошуку та сортування записів за значенням, що зберігається в даному полі, а також для автоматичного виключеннядублювання записів. Поля типу MEMO, Об'єкт OLE і Гіперпосиланняне можуть індексуватись.

Визначення ключового поля

Після завдання характеристик всіх полів слід вибрати принаймні одне ключове поле. Як правило, як ключові поля вказуються поля, які мають неповторні дані або створюються поля з типом даних Лічильник . У будь-якому випадку, поле ключа не повинно містити даних, що повторюються. Щоб визначити ключ, необхідно виділити потрібне поле (або поля) та натиснути кнопку Ключове поле Виправлення . Ліворуч від маркера з'явиться зображення ключа.

Збереження таблиці

Перед введенням інформації спроектовану таблицю необхідно зберегти: натиснути кнопку Зберегти на панелі інструментів або відповідну команду в п.м. Файл і ввести назву таблиці, після чого на екрані постає питання «Створити ключове поле зараз?» (Так чи ні)

Якщо вибирається відповідь Так», то Access створить автоматично поле з ім'ям «Код» та типом даних Лічильник , якщо « Ні», - то таблиця буде створена без ключового поля. В цьому випадку необхідно відкрити створену таблицю в режимі Конструктората визначити «вручну» ключове поле.

Ввід данних

Щоб перевести таблицю в режим введення інформації, необхідно перейти в режим Таблиці. Поля заповнюються послідовно. Перехід від одного поля до іншого зручно виконувати клавішею Tab(або комбінацією Shift+Tab– у зворотному напрямку). Якщо при проектуванні таблиці для деяких полів були передбачені стандартні значення, ці значення автоматично з'являться у відповідних полях. Записи в таблиці можна переміщати, копіювати і видаляти тими самими способами, що і електронних таблицях, тобто спочатку виділити рядки, а потім виконати необхідну операцію. Стовпець можна виділити клацанням миші по заголовку. Стовпці можна переміщати вправо та вліво, користуючись методом drag and drop(перетягнути та кинути).

За потреби можна повернутися до режиму Конструктора. Це дає можливість щось підправити у структурі таблиці.

Сортування даних у таблиці

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

8. Створення зв'язків між таблицями БД

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

Зауваження.

Ø Обидва зв'язувані поля повинні мати однаковий тип даних.

Ø Властивості Розмір полядля обох зв'язуваних полів числового типу мають бути однаковими.

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

Цілісність даних

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

Ці правила включають:

Ø У підпорядкованій таблиці не можна вводити записи, які пов'язані із записом головної таблиці.

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

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

Каскадні операції

Цілісність даних у зв'язаних таблицях забезпечують каскадні операції двох видів:

Ø операції каскадного поновлення;

Ø операції каскадного видалення.

Ці операції можна вмикати та вимикати шляхом встановлення відповідних прапорців: «Каскадне оновлення пов'язаних полів» та « Каскадне видаленняпов'язаних полів».

Якщо встановлено прапорець "Каскадне оновлення пов'язаних полів", то будь-які зміни у значенні ключового поля в головній таблиці, яка стоїть на стороні "один" у відносинах 1:М, ведуть до автоматичному оновленнювідповідних значень у всіх пов'язаних записах.

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

Видалення (зміна) зв'язків

Ø Відкрити вікно Схема даних;

Ø активізувати лівою кнопкою миші зв'язок, який необхідно видалити (змінити);

Ø правою кнопкоюмиші викликати контекстно-залежне меню та вибрати команду видалити (Змінити) відповідно.

9. Типи відносин між таблицями

Існує три типи відносин між таблицями:

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

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

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

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

10. Формування запитів

Запуск запиту

Для запуску запиту на виконання з вікна Конструкторатреба на панелі інструментів натиснути кнопку « Запуск» ! або виконати команду Запит/Запуск. Результати вибірки даних на запит виводяться на екран у режимі таблиці.

Формування умов відбору

Список операторів, що використовуються при заданні виразів наступний:

Ø оператори порівняння:

= (Рівно)

<> (не дорівнює)

> (більше)

>= (не менше)

< (менше)

<= (не більше)

BETWEEN– дозволяє встановити діапазон значень. Синтаксис: Between«Вираз» And"Вираз" (наприклад: BETWEEN 10 And 20 означає також, що і логічний вираз >= 10 AND<= 20).

IN– дозволяє задавати список значень, що використовується для порівняння (операндом є список, укладений у круглі дужки). Наприклад: IN("Брест", "Мінськ", "Гродно") означає те саме, що і логічне вираження "Брест" OR"Мінськ" OR"Гродно".

Ø логічніоператори:

АND(наприклад: >=10 AND<=20)

OR(наприклад:<50 OR >100)

NOT(наприклад: Is Not Null – поле, яке містить будь-яке значення).

Ø оператор LIKE– перевіряє відповідність текстовогоабо Memo поляза заданим шаблоном символів.

Таблиця символів шаблону

Приклади використання оператора Like:

LIKE "З *"- Рядки, що починаються з символу С;

LIKE "[ A - Z ] #"– будь-який символ від А до Z та цифра;

LIKE "[! 0 - 9 ABC] * # #"– рядки, що починаються з будь-якого символу, окрім цифри або літер А, В, С та закінчуються на 2 цифри;

Складні критерії вибірки

Часто доводиться вибирати записи за умовою, що задається для кількох полів таблиці або кількома умовами для одного поля. У цьому випадку застосовуються «І-запити»(вибір записів тільки за умови виконання всіх умов) та «АБО-запити»(Вибір записів при виконанні хоча б однієї з умов).

При завданні « АБО-запиту» кожна умова вибірки повинна розміщуватися на окремому рядку Бланка запиту.

При завданні « І-запитукожна умова вибірки повинна розміщуватися на одному рядку, але в різних полях Бланка запиту.

Ці операції можуть бути задані за допомогою операторів ORі ANDвідповідно.

Функції Iif() та Format()

Функція IIf (умова; якщо Істина; якщо Брехня)– повертає один із двох аргументів залежно від результату обчислення виразу.

Функція Format (вираз; інструкція форматування)– повертає рядок, що містить вираз, відформатований згідно з інструкціями форматування.

Для виразів дати/часу можна використовувати такі символи в інструкції форматування:

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

ІІ. Мережева модель

ІІІ. Реляційна модель

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

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

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

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

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

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

Базові поняття реляційних баз даних (РБД)

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

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

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

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

* Об'єднання– процес об'єднання таблиць або запитів на основі відповідних значень певних атрибутів.

Правила (нормалізації) побудови реляційної БД

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

1. Кожне поле будь-якої таблиці має бути унікальним.

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

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

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

5. Системи управління базами даних (СУБД)

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

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

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

Реляційна система управління базами даних (РСУБД)

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

Основними функціямиРСУБД є:

· Визначення даних- Яка інформація буде зберігатися, задати структуру БД та їх тип.

· Обробка даних– можна вибирати будь-які поля, сортувати та фільтрувати дані. Можна об'єднувати дані та підбивати підсумки.

· Управління даними– коригувати та додавати дані.

6. Загальна характеристика СУБД ACCESS

Microsoft Access- Це функціонально повна реляційна СУБД, в якій передбачені всі необхідні засоби для визначення та обробки даних, а також для управління ними під час роботи з великими обсягами інформації. Різні її версії входять до складу програмного пакета MS Office та працюють у середовищі Windows (3.11/95/98/2000/XP).

Вікно БД в Access

Після створення нового файлу БД або відкриття вікна Access, що існує в робочій області, з'являється вікно бази даних:

• Переклад

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

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

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

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

Почнемо з основ

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

Доступ до реляційних баз даних здійснюється через реляційні системи управління базами даних (РСУБД). Майже всі системи баз даних, які ми використовуємо є реляційними, такі як Oracle, SQL Server, MySQL, Sybase, DB2, TeraData і так далі.

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

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

Проблеми реляційних БД

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

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

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

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

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

Нова хвиля

Такий тип баз даних прийнято називати сховище типу ключ-значення (key-value store). Фактично, жодної офіційної назви не існує, тому ви можете зустріти її в контексті документо-орієнтованих, атрибутно-орієнтованих, розподілених баз даних (хоча вони також можуть бути реляційними), шардованих упорядкованих масивів (sharded sorted arrays), розподілених хеш-таблиць та сховищ типу ключ-значення. І хоча кожна з цих назв вказує на конкретні особливості системи, всі вони є варіаціями на тему, яку ми назватимемо сховище типу ключ-значення.

Втім, як би ви його не називали, цей «новий» тип баз даних не такий вже й новий і завжди застосовувався переважно для додатків, для яких використання реляційних БД було б непридатним. Однак без потреби Інтернету та «хмари» в масштабованості ці системи залишалися не дуже затребуваними. Тепер завдання полягає в тому, щоб визначити, який тип сховища більше підходить для конкретної системи.
Реляційні БД та сховища типу ключ-значення відрізняються докорінно і призначені для вирішення різних завдань. Порівняння характеристик дозволить лише зрозуміти різницю між ними, проте почнемо з цього:

Характеристики сховищ

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

Жодних join'ів

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

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

Доступ до даних

Реляційна БД	Сховище типу ключ-значення
Дані створюються, оновлюються, видаляються та запитуються з використанням мови структурованих запитів (SQL).	Дані створюються, оновлюються, видаляються та запитуються за допомогою виклику API методів.
SQL-запити можуть отримувати дані як з одиночної таблиці, так і з декількох таблиць, використовуючи при цьому з'єднання (join'и).	Деякі реалізації надають SQL-подібний синтаксис завдання умов фільтрації.
SQL-запити можуть містити агрегації та складні фільтри.	Найчастіше можна використовувати лише базові оператори порівнянь (=, !=,<, >, <= и =>).
Реляційна БД зазвичай містить вбудовану логіку, таку як тригери, процедури, що зберігаються і функції.	Вся бізнес-логіка і логіка підтримки цілісності даних міститься у коді додатків.

Взаємодія з програмами

Сховища типу ключ-значення: переваги

Є дві чіткі переваги таких систем перед реляційними сховищами.

Підходять для хмарних сервісів

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

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

Більш природна інтеграція з кодом

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

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

Сховища типу ключ-значення: недоліки

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

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

І не забудьте про сумісність. На відміну від реляційних БД, сховища, орієнтовані використання у «хмарі», мають набагато менше загальних стандартів. Хоча концептуально вони й не відрізняються, вони мають різні API, інтерфейси запитів і свою специфіку. Тому вам краще довіряти вашому вендору, тому що в разі чого ви не зможете легко переключитися на іншого постачальника послуг. А враховуючи той факт, що майже всі сучасні сховища типу ключ-значення знаходяться на стадії бета-версій 2 , довіряти стає ще ризикованішим, ніж у разі використання реляційних БД.

Обмежена аналітика даних

Зазвичай усі хмарні сховища будуються за типом множинної оренди, що означає, що ту саму систему використовує велику кількість користувачів і додатків. Щоб запобігти «захопленню» загальної системи, вендори зазвичай якимось чином обмежують виконання запитів. Наприклад, у SimpleDB запит не може виконуватися довше 5 секунд. У Google AppEngine Datastore за один запит не можна отримати більше 1000 записів 3 .

Ці обмеження не страшні для простої логіки (створення, оновлення, видалення та вилучення невеликої кількості записів). Але що якщо ваш додаток стає популярним? Ви отримали багато нових користувачів і багато нових даних, і тепер хочете створити нові можливості для користувачів або якимось чином отримати вигоду з даних. Тут ви можете жорстко обламатися з виконанням навіть найпростіших запитів для аналізу даних. Фічі на кшталт відстеження шаблонів використання програми чи системи рекомендацій, заснованої на історії користувача, у разі можуть бути складні у реалізації. А в гіршому – просто неможливі.

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

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

Хмарні сховища

Безліч постачальників веб-сервісів пропонують розраховані на багато користувачів сховища типу ключ-значення. Більшість із них задовольняють критеріям, переліченим вище, проте кожне має свої відмінні фічі та відрізняється від стандартів, описаних вище. Давайте поглянемо на конкретні приклади сховищ, такі як SimpleDB, Google AppEngine Datastore і SQL Data Services.

Amazon: SimpleDB

SimpleDB – це атрибутно-орієнтоване сховище типу ключ-значення, що входить до складу Amazon WebServices. SimpleDB знаходиться у стадії бета-версії; користувачі можуть користуватись їй безкоштовно - доти їх потреби не перевищать певну межу.

SimpleDB має кілька обмежень. Перше - час виконання запиту обмежено 5 секундами. Друге – немає жодних типів даних, крім рядків. Все зберігається, витягується та порівнюється як рядок, тому для того, щоб порівняти дати, вам потрібно буде перетворити їх у формат ISO8601. Третє - максимальний розмір будь-якого рядка становить 1024 байта, що обмежує розмір тексту (наприклад, опис товару), який ви можете зберігати як атрибут. Однак оскільки структура даних є гнучкою, ви можете обійти це обмеження, додаючи атрибути «ОписТовара1», «Опис товару2» і т.д. Але кількість атрибутів також обмежена – максимум 256 атрибутів. Поки SimpleDB знаходиться в стадії бета-версії, розмір домену обмежений 10 гігабайтами, а вся база не може займати більше одного терабайта.

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

Google AppEngine Data Store

Google"s AppEngine Datastore побудований на основі BigTable, внутрішньої системи зберігання структурованих даних від Google. AppEngine Datastore не надає прямий доступ до BigTable, але може сприйматися як спрощений інтерфейс взаємодії з BigTable.

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

Швидше за все, ви будете використовувати саме це сховище даних при розробці за допомогою Google AppEngine. Однак, на відміну від SimpleDB, ви не зможете використовувати AppEngine Datastore (або BigTable) поза веб-сервісами Google.

Microsoft: SQL Data Services

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

Нехмарні сховища

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

CouchDB

CouchDB - це документо-орієнтована БД, що вільно розповсюджується, з відкритим вихідним кодом. Як формат зберігання даних використовується JSON. CouchDB покликана заповнити пробіл між документоорієнтованими та реляційними базами даних за допомогою «уявлень». Такі уявлення містять дані з документів у вигляді, схожим на табличний, і дозволяють будувати індекси і виконувати запити.

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

Проект Voldemort

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

Mongo

Mongo - це база даних, що розробляється в 10gen Гейром Магнуссоном і Дуайтом Мерріменом (якого ви можете знати по DoubleClick). Як і CouchDB, Mongo - це документоорієнтована база даних, що зберігає дані в JSON форматі. Однак Mongo скоріше є об'єктною базою, ніж чистим сховищем типу ключ-значення.

Drizzle

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

Рішення

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

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

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

Для решти вимог краще вибрати старі добрі реляційні СУБД. То чи приречені вони? Звичайно, ні. Принаймні поки що.

1 - на мою думку, тут найбільше підходить термін «структура даних», проте залишив оригінальне data model.
2 - швидше за все, автор мав на увазі, що за своїми можливостями нереляційні БД поступаються реляційним.
3 – можливо, дані вже застаріли, стаття датується лютим 2009 року.

Додати теги