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

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

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

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

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

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

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

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

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

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

проектування реляційних баз даних

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

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

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

реляційна база даних запис

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

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

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

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

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

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

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

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

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

Схема реляційної БД
Назва атрибуту 1Назва атрибуту 2Назва атрибуту 3Назва атрибуту 4Назва атрибуту 5
Елемент_1_1Елемент_1_2Елемент_1_3Елемент_1_4Елемент_1_5
Елемент_2_1Елемент_2_2Елемент_2_3Елемент_2_4Елемент_2_5
Елемент_3_1Елемент_3_2Елемент_3_3Елемент_3_4Елемент_3_5

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

Сутність "Деканат"

ID студента

ПІБ

Група

111

Іванов Олег Петрович

ІН-41

222



Лазарєв Ілля Олександрович

ІН-72

333

Конопльов Петро Васильович

ІН-41

444

Кушнерева Наталія Ігорівна

ІН-72

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

Таблиця "Студенти"

ПІБ

Група

Середній бал

Телефон

Іванов Олег Петрович

ІН-41

3,0

2-27-36

Лазарєв Ілля Олександрович

ІН-72

3,8

2-36-82

Конопльов Петро Васильович

ІН-41

3,9

2-54-78

Кушнерева Наталія Ігорівна

ІН-72

4,7

2-65-25

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




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