Бази даних реляційні. Поняття реляційної бази даних

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

Фундаментальні моделі

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

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

Основне поняття реляційної бази даних

Така модель була розроблена в 1970-х роках доктором науки Едгаром Коддом. Вона являє собою логічно структуровану таблицю з полями, що описує дані, їх відносини між собою, операції, вироблені над ними, а головне - правила, які гарантують їх цілісність. Чому модель називається реляційною? В її основі лежать відносини (від лат. Relatio) між даними. Існує безліч визначень цього типу бази даних. Реляційні таблиці з інформацією набагато простіше систематизувати і надати обробці, ніж в мережевий або ієрархічній моделі. Як же це зробити? Достатньо знати особливості, структуру моделі і властивості реляційних таблиць.

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

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

Моделювання таблиць і проектування реляційних баз даних проводиться за допомогою безкоштовних інструментів, таких як Workbench, PhpMyAdmin, Case Studio, dbForge Studio. Після детальної проектування слід зберегти графічно готову реляційну модель і перевести її в готовий SQL-код. На цьому етапі можна починати роботу з сортуванням даних, їх обробку та систематизацію.

Особливості, структура та терміни, пов`язані з реляційною моделлю

Кожен джерело по-своєму описує її елементи, тому для меншої плутанини хотілося б привести невелику підказку:

• реляционная табличка = сущность;
• макет = атрибути = найменування полів = заголовок стовпців сущності;
• екземпляр сутності = кортеж = запис = рядок таблічкі;
• значення атрибута = осередок сутності = полі.

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

1. Сутність. Таблиця реляційної бази даних може бути одна, а може бути цілий набір з таблиць, які характеризують описані об`єкти завдяки зберігаються в них даними. У них фіксовану кількість полів і змінне число записів. Таблиця реляційної моделі баз даних складається з рядків, атрибутів і макета.
2. Запис - змінне число рядків, що відображають дані, що характеризують описуваний об`єкт. Нумерація записів проводиться системою автоматично.
3. Атрибути - дані, що демонструють собою опис стовпців сутності.
4. Полі. Являє собою стовпець сутності. Їх кількість - фіксована величина, що встановлюється під час створення або зміни таблиці.

Тепер, знаючи складові елементи таблиці, можна переходити до властивостей реляційної моделі database:

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

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

Основні характеристики полів реляційних БД

Назви полів повинні бути унікальними в рамках однієї сутності. Типи атрибутів або полів реляційних баз даних описують, дані якої категорії зберігаються в полях сутностей. Поле реляційної бази даних повинне мати фіксований розмір, обчислюваний в символах. Параметри і формат значень атрибутів визначають манеру виправлення в них даних. Ще є таке поняття, як "маска", або "шаблон введення". Воно призначене для визначення конфігурації введення даних в значення атрибута. Неодмінно при записі неправильного типу даних в поле має видаватися повідомлення про помилку. Також на елементи полів накладаються деякі обмеження - умови перевірки точності і безпомилковості введення даних. Існує деякий обов`язкове значення атрибута, яке однозначно має бути заповнено даними. Деякі рядки атрибутів можуть бути заповнені NULL-значеннями. Дозволяється введення порожніх даних в атрибути полів. Як і повідомлення про помилку, є значення, які заповнюються системою автоматично - це дані за замовчуванням. Для прискорення пошуку будь-яких даних призначено индексированное поле.

Схема двовимірної реляційної таблиці бази даних

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

Базові правила нормалізації реляційної сутності

1. Значення назви поля для реляційної таблиці має бути унікальним, єдиним у своєму роді (перша нормальна форма - 1НФ).

2. Для таблиці, яка вже приведена до 1НФ, найменування будь-якого неідентіфіцірующей шпальти має бути залежним від унікального ідентифікатора таблиці (2НФ).

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

Бази даних: реляційні зв`язки між таблицями

Існує 2 основних виду зв`язків реляційних табличок:

• «Один-багато». Виникає при відповідності однією ключовою записи таблиці №1 декількох екземплярах другий сутності. Значок ключа на одному з кінців проведеної лінії говорить про те, що сутність знаходиться на боці «один», другий кінець лінії часто відзначають символом нескінченності.

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

Існування ключів в реляційній базі даних

Первинний і вторинний ключі визначають потенційні відносини бази даних. Реляційні зв`язку моделі даних можуть мати тільки один потенційний ключ, це і буде primary key. Що ж він собою являє? Первинний ключ - це стовпець сутності або набір атрибутів, завдяки якому можна отримати доступ до даних конкретної рядка. Він повинен бути унікальним, єдиним, а його поля не можуть містити порожніх значень. Якщо первинний ключ складається всього з одного атрибута, тоді він називається простим, в іншому випадку буде складовим.

Крім первинного ключа, існує і зовнішній (foreign key). Багато хто не розуміє, яка між ними різниця. Розберемо їх більш детально на прикладі. Отже, існує 2 таблиці: «Деканат» і «Студенти». Сутність «Деканат» містить поля: «ID студента», «ПІБ» і «Група». Таблиця «Студенти» має такі значення атрибутів, як «ПІБ», «Група» і «Середній бал». Так як ID студента не може бути однаковим для кількох студентів, це поле і буде первинним ключем. «ПІБ» і «Група» з таблиці «Студенти» можуть бути однаковими для кількох людей, вони посилаються на ID номер студента із сутності «Деканат», тому можуть бути використані в якості зовнішнього ключа.

Приклад моделі реляційної бази даних

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

Необхідно провести зв`язку, щоб вийшла повноцінна реляційна база даних. Запис "ІН-41", як і "ІН-72", може бути присутнім не одного разу в табличці "Деканат", також прізвище, ім`я та по батькові студентів в рідкісних випадках можуть збігатися, тому дані поля ніяк не можна зробити первинним ключем. Покажемо сутність «Студенти».

Як ми бачимо, типи полів реляційних баз даних абсолютно різняться. Присутні як цифрові записи, так і символьні. Тому в налаштуваннях атрибутів слід вказувати значення integer, char, vachar, date та інші. У таблиці "Деканат" унікальним значенням є тільки ID студента. Дане поле можна взяти за первинний ключ. ПІБ, група і телефон із сутності "Студенти" можуть бути взяті як зовнішній ключ, що посилається на ID студента. Зв`язок встановлено. Це приклад моделі зі зв`язком «один до одного». Гіпотетично одна з таблиць зайва, їх можна легко об`єднати в одну сутність. Щоб ID-номера студентів не стали загально відомими, цілком реально існування двох таблиць.