Описание реляционных Баз Данных

Author: Tatyana Milkina

1. База данных и СУБД

База данных — это один или несколько файлов данных, предназначенных для хранения, изменения и обработки больших объемов взаимосвязанной информации. Базы данных используются под управлением систем управления базами данных (СУБД).

СУБД представляет собой программное обеспечение, которое используется для создания и работы с базами данных.

SQL - язык структурированных запросов, основной задачей которого является предоставление простого способа считывания и записи информации в базу данных.

2. Простейшая схема работы с базой данных

Простейшая схема работы с базой данных фото

3. Реляционная СУБД

Реляционная модель ориентирована на организацию данных в виде двумерных таблиц. Каждая реляционная таблица представляет собой двумерный массив и обладает следующими свойствами:

  • Каждый элемент таблицы является одним элементом данных.
  • Каждый столбец обладает своим уникальным именем.
  • Одинаковые строки в таблице отсутствуют.
  • Все столбцы в таблице однородные, то есть все элементы в столбце имеют одинаковый тип.
  • Порядок следования строк может быть произвольным.
  • На пересечении каждого столбца и строки может находиться только атомарное значение (одно значение, не состоящее из группы значений). Таблицы, удовлетворяющие этому условию, называют нормализованными.

Пример таблицы city

Пример реляционной таблицы фото

4. Пример создания БД

Предположим, мы захотели создать базу данных для форума. У форума есть зарегистрированные пользователи, которые создают темы и оставляют сообщения в этих темах. Эта информация и должна храниться в базе данных.

Теоретически (на бумаге) мы можем все это расположить в одной таблице, например, так:

Данные форума
Имя Email Пароль Созданные темы Созданные сообщения
Кирилл kirill@gmail.com qwqwq О рыбалке Думаю надо сделать так…
Вася vasya@gmail.com dsd Велосипеды; О рыбалке Согласен; Согласен
Семен semen@gmail.com dfd Ночные клубы А еще можно сделать так…

Несколько значений в ячейке колонки “Созданные темы” противоречат свойству атомарности (одно значение в одной ячейке). Поэтому разбиваем таблицу на три:

Пользователи
Имя Email Пароль
Кирилл kirill@gmail.com qwqwq
Вася vasya@gmail.com dsd
Семен semen@gmail.com dfd

 

Темы
Наименование Автор
О рыбалке Кирилл
Велосипеды Вася
О рыбалке Вася
Ночные клубы Семен
Сообщения
Текст Автор
Думаю надо сделать так… Кирилл
Согласен Вася
Согласен Вася
А еще можно сделать так… Семен

Таблицы Пользователи, Темы удовлетворяют всем условиям. А вот таблица Сообщения - нет. Ведь в таблице не может быть двух одинаковых строк, а где гарантия, что один пользователь не оставит два одинаковых сообщения. Кроме того, мы знаем, что каждое сообщение обязательно относится к какой-либо теме. А как это можно узнать из наших таблиц? Никак. Для решения этих проблем, в реляционных базах данных существуют ключи.

5. Первичный ключ

Первичный ключ (сокращенно РК - primary key) - столбец, значения которого во всех строках различны.

Первичные ключи могут быть:

  • логическими (естественными) и
  • суррогатными (искусственными).

Так, для таблицы Пользователи первичным ключом может стать столбец e-mail (ведь теоретически не может быть двух пользователей с одинаковым e-mail). На практике лучше использовать суррогатные ключи, т.к. их применение позволяет абстрагировать ключи от реальных данных. Кроме того, первичные ключи менять нельзя, а что если у пользователя сменится e-mail

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

Пользователи
id пользователя Имя Email Пароль
1 Кирилл kirill@gmail.com qwqwq
2 Вася vasya@gmail.com dsd
3 Семен semen@gmail.com dfd
Темы
id темы Наименование Автор
1 О рыбалке Кирилл
2 Велосипеды Вася
3 О рыбалке Вася
4 Ночные клубы Семен
Сообщения
id сообщения Текст Автор
1 Думаю надо сделать так… Кирилл
2 Согласен Вася
3 Согласен Вася
4 А еще можно сделать так… Семен

Теперь каждая запись в наших таблицах уникальна. Нам осталось установить соответствие между темами и сообщениями в них. Делается это также при помощи первичных ключей. В таблицу Сообщения мы добавим еще одно поле:

Сообщения
id сообщения Текст Автор id темы
1 Думаю надо сделать так… Кирилл 1
2 Согласен Вася 4
3 Согласен Вася 1
4 А еще можно сделать так… Семен 1

6. Внешний ключ

Поле “id темы” называется внешний ключ (сокращенно FK - foreign key). Каждое значение этого поля соответствует какому-либо первичному ключу из таблицы "Темы". Так устанавливается однозначное соответствие между сообщениями и темами, к которым они относятся.

Предположим, у нас добавился новый пользователь, и зовут его тоже Вася. Как мы узнаем, какой именно Вася оставил сообщения? Для этого поля автор в таблицах "Темы" и "Сообщения" мы сделаем также внешними ключами:

Пользователи
id пользователя Имя Email Пароль
1 Кирилл kirill@gmail.com qwqwq
2 Вася vasya@gmail.com dsd
3 Семен semen@gmail.com dfd
4 Вася vasya@rambler.ru vasya
Темы
id темы Наименование id автора
1 О рыбалке 1
2 Велосипеды 2
3 О рыбалке 2
4 Ночные клубы 3
5 К кому обратиться 4
Сообщения
id сообщения Текст id автора id темы
1 Думаю надо сделать так… 1 1
2 Согласен 2 4
3 Согласен 2 1
4 А еще можно сделать так… 3 1

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

База данных для форума фото

Курс 'Java для начинающих' на Udemy Курс 'Java для начинающих' на Udemy
Читайте также:
Комментарии
ryan
Dec 31, 2012
There is mistake in Object-Relational Mapping question number 57. The answer should be YES because annotation @Embeddable is not mandatory.
ryan
Dec 31, 2012
@Embedded not @Embeddable :-)
sysadmin
Jan 4, 2013
Ryan, thanks that you noticed it. The answer to this question is updated now.