Бази даних - урок 3

Попередня ◈ Наступна

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

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

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

    Теоретично (на папері) ми можемо все це розташувати в одній таблиці, наприклад, так:

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

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

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

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

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

    Тепер зрозуміло, що повідомлення з id = 2 належить темі "Про рибалку" (id теми = 4), створеної Васею, а решта повідомлення належати темі "Про рибалку" (id теми = 1), створеної Кирилом. Таке поле називається зовнішній ключ (скорочено FK - foreign key). Кожне значення цього поля відповідає якомусь первинному ключу з таблиці "Теми". Так встановлюється однозначна відповідність між повідомленнями і темами, до яких вони належать.

    Останній нюанс. Припустимо, у нас додався новий користувач, і звуть його теж Вася:

    Наша база даних готова. Схематично її можна представити так:

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

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

    Схожі статті

    Попередня ◈ Наступна