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

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

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

Повертаючись до виникнення баз даних, варто сказати, що цей процес був досить складним, він бере свій початок разом з розвитком програмованого обладнання обробки інформації. Тому не дивно, що кількість їх моделей на даний момент сягає понад 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-номера студентів не стали загально відомими, цілком реально існування двох таблиць.