Что такое схемы базы данных? 5-минутное руководство с примерами

Специфика базы данных Oracle

В контексте баз данных Oracle , A объект схемы представляет собой логическую структуру хранения данных .

База данных Oracle связывает отдельную схему с каждым пользователем базы данных . Схема состоит из набора объектов схемы. Примеры объектов схемы включают:

• столы
• Просмотры
• последовательности
• синонимы
• индексы
• кластеры
• ссылки на базу данных
• снимки
• процедуры
• функции
• пакеты

С другой стороны, объекты, не относящиеся к схеме, могут включать:

• пользователи
• роли
• контексты
• объекты каталога

Объекты схемы не имеют однозначного соответствия физическим файлам на диске, в которых хранится их информация. Однако базы данных Oracle логически хранят объекты схемы в табличном пространстве базы данных. Данные каждого объекта физически содержатся в одном или нескольких файлах данных табличного пространства . Для некоторых объектов (таких как таблицы, индексы и кластеры) администратор базы данных может указать, сколько дискового пространства Oracle RDBMS выделяет для объекта в файлах данных табличного пространства.

Нет необходимой взаимосвязи между схемами и табличными пространствами: табличное пространство может содержать объекты из разных схем, а объекты для одной схемы могут находиться в разных табличных пространствах. Однако специфика базы данных Oracle заставляет платформу распознавать негомогенизированные различия последовательностей, что считается решающим ограничивающим фактором в виртуализированных приложениях.

Один-к-одному (1 — 1)

Связь один-ко-многим связывает одну запись из
основной таблицы с одной записью из подчинённой таблицы, у которых значения
связанных полей совпадают. Этот тип связи используется редко и применяется в
том случае, когда программист хочет по каким-либо причинам разбить одну таблицу
на две и более таблиц.

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

1 Анализ предметной области

Зачастую, кинотеатр состоит из нескольких залов разной конфигурации, а посетителю предоставляется возможность выбора билета, для этого ему отображается текущее состояние зала. Выбранные места посетитель сообщает кассиру, который вводит их в систему и места помечаются как «проданные». Это «основной» сценарий использования информационной системы, однако надо учесть следующее:

1. репертуар и расписание проката кинотеатра должен кто-то вносить в систему — соответствующую роль назовем «Менеджер»;
2. посетитель и кассир должны иметь возможность просматривать расписание, при этом интересно расписание, начиная с некоторого момента времени (например, текущего времени). Составлять оно может по-разному:
   1. расписание показа всех фильмов, упорядоченное по времени;
   2. расписание прокатов в отдельных залах кинотеатра;
   3. расписание проката определенного фильма.

Из этого описания понятны основные функции системы, изображенные на рисунке с помощью нотации диаграммы прецедентов UML. На диаграмме не отображена роль администратора базы данных, так как администратор обычно взаимодействует с системой не через интерфейс, а через выполнение SQL-запросов.

Несмотря на то, что мы не будет разрабатывать интерфейс информационной системы и текстовые описания прецедентов, дальше нас будут интересовать данные, необходимые для выполнения того или иного прецедента, а для этого надо выделить и описать сущности. Иначе, невозможно определить «какие данные должен вводить менеджер при добавлении фильма». Основные сущности, данные которых потребуются во время работы, показаны на рисунке, при этом используется нотация диаграммы классов UML. Каждый прямоугольник соответствует одной сущности, внутри записаны поля и типы данных.

Каждая сущность, кроме hall_row содержит поле id, которое идентифицирует объект. У сущности hall_row поле id не нужно, так как в одном и том же зале кинотеатра (id_hall) не могут повторяться номера рядов (number).

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

Сохранение, добавление, удаление

В Microsoft Access изменения сохраняются автоматически при следующих действиях:

• Переход к следующей записи
• Закрытие режима таблицы или формы

Добавление и удаление записей

Для добавления данных в новую запись:

1. Перейдите на пустое поле новой записи
2. Введите новую группу с количеством студентов и проходным баллом, нажимая TabилиEnter для перехода к следующему полю

Для удаления записей:

1. Выделите записи для удаления, щелкнув курсором на серой кнопке слева от первой удаляемой записи и переместив указатель вдоль требуемых записей.
2. Нажмите Del или выберите команду Правка|Удалить записи

Примечание:

Нельзя удалить данные из блокированного поля, вычисляемого поля или поля типа счетчик.

2 Построение концептуальной модели

Выше были отображены основные сущности, но не отображены роли пользователей, хотя их тоже должна хранить система. Они показаны ниже на ER-диаграмме в нотации Чена .

На диаграмме выделены роли кассира и менеджера, а также основные отношения между сущностями. На диаграмме нет роли администратора, но его роль заключается в:

1. создании всех таблиц базы;
2. добавлении залов и рядов в них;
3. добавлении кассиров и менеджеров.

На диаграмме не отражена роль посетителя, так как:

1. билет не содержит информации о том, кто его купил (посетитель может подарить билет другу);
2. система вообще не хранит информацию о посетителях;
3. покупку билета он осуществляет через общение с кассиром вне системы;
4. никакие данные в базе посетитель самостоятельно изменить не может.

На диаграмме проставлены кратности связей, например, видно, что один менеджер может добавить много (N) прокатов. В этой базе не оказалось связей типа N:M, сложных или рекурсивных связей — такие связи являются препятствиями в проектировании и решаются изменением ее структуры.

Для формирования схемы данных необходимо сначала дополнить ER-диаграмму реквизитами сущностей (уточнить ее) — результат приведен на рисунке.

• система не должна позволять продавать несколько билетов на одно и то же место при одном показе фильма. Это значит, что вторичным ключем для Билета должен быть кортеж (id_screening, row, seat). Однако, тогда нет необходимости в id билета — на билеты не ссылается ни одна таблица, это поле может быть удалено. Изначально id был добавлен потому, что обычно на билетах в кинотеатрах печатается номер;
• билет хранит поле id_hall, это было сделано для того, чтобы посетитель кинотеатра мог найти свой кинозал. Однако, билет, выдаваемый пользователю — это не тоже самое, что информация о билетах, хранимая в базе данных. Билет базы данных хранит также поле id_screening, а Показ уже ссылается на id_hall. Таким образом, в базе нет смысла хранить id_hall в таблице билетов.

Исправленная ER-диаграмма приведена ниже:

Таблица менеджеров и кассиров не объединены в таблицу Users так как вопросы разграничения прав доступа в различных СУБД решаются по-разному. Так, в MS SQL пользователи добавляются с помощью специальных запросов типа:

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

Вставка рисунка или объекта

Создание других таблиц для этой базы данных — аналогичное. 

Создайте еще 5 таблиц самостоятельно.

Вставка в запись рисунка или объекта

Рисунок или объект добавляется из имеющегося файла либо создается в приложении OLE (например, в MS Paint), а затем вставляется в текущую запись.

Рассмотрим размещение объекта OLE на примере поля Фотография начальника в таблице Преподаватели. Фотографии хранятся в формате графического редактора Paint в файлах с расширением .bmp. Если рисунка в вашем файле нет, то создайте его самостоятельно и сохраните.

1. В окне базы данных установите курсор на таблице Преподаватели и нажмите кнопку Открыть
2. Заполните строки (записи) открывшейся таблицы данными в соответствии с названиями столбцов (полей)
3. Для размещения поля Фотография начальника выполните внедрение объекта OLE в файл базы данных. Установите курсор в соответствующее поле таблицы. Выполните команду меню Вставка|Объект
4. В окне Вставка объекта выберите тип объекта Paintbrush Picture и установите флажок Создать из файла
5. В этом окне можно ввести имя файла, содержащего фотографию.
6. Для просмотра внедренного объекта установите курсор в соответствующее поле и дважды щелкните кнопкой мыши
7. Чтобы вернуться из программы Paint, выполните команду Файл|Выход и возврат к таблице Преподаватели.

Размещение данных типа МЕМО в таблице

В таблице ПРЕДМЕТ предусмотрено поле ПРОГРАММА, которое будет содержать длинный текст – краткую программу курса. Для такого поля выберите тип данных ПолеМЕМО.

Идеальные требования для интеграции схемы

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

Сохранение перекрытия

Каждый из перекрывающихся элементов, указанных во входном отображении, также находится в отношении схемы базы данных.

Расширенное сохранение перекрытия

Элементы, зависящие от источника, связанные с перекрывающимися элементами источника, передаются в схему базы данных.

Нормализация

Независимые сущности и отношения в исходных данных не должны группироваться вместе в одном отношении в схеме базы данных. В частности, элементы схемы, зависящие от источника, не должны группироваться с перекрывающимися элементами схемы, если при группировании совместно размещаются независимые объекты или отношения.

Минимальность

Если какие-либо элементы схемы базы данных отброшены, схема базы данных не идеальна.

Схема данных

Основная таблица используется в качестве
источника строк для значений какого-либо поля в подчинённой таблице. Например,
в подчинённой таблице Специальности
поле КодФакультета использует в
качестве источника строк таблицу Факультеты,
которая в данном случае является основной.

Для правильного функционирования базы данных
необходимо связать данные из основных и подчинённых таблиц для обеспечения
целостности данных. Таблицы можно связать только в том случае, если

Ø поля, по значению которых осуществляется
связь, имеют одинаковый тип данных

Ø одно из полей, по значению
которых осуществляется связь, является уникальным в таблице

Ø рекомендуется давать полям,
по которым вы предполагаете связать таблицы, одинаковые имена

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

Как правило, связь между таблицами осуществляют
по значению полей, которые имеют тип данных Числовой
(Длинное целое) или Счётчик.
Числовой тип данных занимает меньше оперативной памяти и обрабатывается с
большей скоростью, чем, например, текстовый.

Если заранее ясно, что основная таблица будет
содержать несколько записей, а значение ключевого поля будет использовано во
многих записях подчинённой таблицы, целесообразно использовать числовой тип
ключевого поля минимальной длины – Байт.
Это позволит значительно сократить объем необходимой памяти, но потребует либо
ручного ввода значения ключевого поля пользователем, либо добавления одной
строки кода в текст программы разработчиком.

Как хранится информация в БД

В основе всей структуры хранения лежат три понятия:

• База данных;
• Таблица;
• Запись.

База данных

База данных — это высокоуровневное понятие, которое означает объединение совокупности данных, хранимых для выполнения одной цели.
Если мы делаем современный сайт, то все его данные будут храниться внутри одной базы данных. Для сайта онлайн-дневника наблюдений за погодой тоже понадобится создать отдельную базу данных.

Таблица

По отношению к базе данных таблица является вложенным объеком. То есть одна БД может содержать в себе множество таблиц.
Аналогией из реального мира может быть шкаф (база данных) внутри которого лежит множество коробок (таблиц).
Таблицы нужны для хранения данных одного типа, например, списка городов, пользователей сайта, или библиотечного каталога.
Таблицу можно представить как обычный лист в Excel-таблице, то есть совокупность строк и столбцов.
Наверняка каждый хоть раз имел дело с электронными таблицами (MS Excel).
Заполняя такую таблицу, пользователь определяет столбцы, у каждого из которых есть заголовок. В строках хранится информация.
В БД точно также: создавая новую таблицу, необходимо описать, из каких столбцов она состоит, и дать им имена.

Запись

Запись — это строка электронной таблицы.
Это неделимая сущность, которая хранится в таблице. Когда мы сохраняем данные веб-формы с сайта, то на самом деле добавляем новую запись в какую-то из таблиц базы данных. Запись состоит из полей (столбцов) и их значений. Но значения не могут быть какими угодно.
Определяя столбец, программист должен указать тип данных, который будет храниться в этом столбце: текстовый, числовой, логический, файловый и т.д. Это нужно для того, чтобы в будущем в базу не были записаны данные неверного типа.

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

1. Создадим для сайта новую БД и дадим ей название «weather_diary».
2. Создадим в БД новую таблицу с именем «weather_log» и определим там следующие столбцы:
   • Город (тип: текст);
   • День (тип: дата);
   • Температура (тип: число);
   • Облачность (тип: число; от 0 (нет облачности) до 4 (полная облачность));
   • Были ли осадки (тип: истина или ложь);
   • Комментарий (тип: текст).
3. При сохранении формы будем добавлять в таблицу weather_log новую запись, и заполнять в ней все поля информацией из полей формы.

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

Реляционная база данных

Английское слово „relation“ можно перевести как связь, отношение.
А определение «реляционные базы данных» означает, что таблицы в этой БД могут вступать в отношения и находиться в связи между собой.
Что это за связи?
Например, одна таблица может ссылаться на другую таблицу. Это часто требуется, чтобы сократить объём и избежать дублирования информации.
В сценарии с дневником погоды пользователь вводит название своего города. Это название сохраняется вместе с погодными данными.
Но можно поступить иначе:

1. Создать новую таблицу с именем „cities“.
2. Все города в России известны, поэтому их все можно добавить в одну таблицу.
3. Переделать форму, изменив поле ввода города с текстового на поле типа «select», чтобы пользователь не вписывал город, а выбирал его из списка.
4. При сохранении погодной записи, в поле для города поставить ссылку на соответствующую запись из таблицы городов.

Так мы решим сразу две задачи:

• Сократим объём хранимой информации, так как погодные записи больше не будут содержать название города;
• Избежим дублирования: все пользователи будут выбирать один из заранее определённых городов, что исключит опечатки.

Связи между таблицами в БД бывают разных видов.
В примере выше использовалась связь типа «один-ко-многим», так как одному городу может соответствовать множество погодных записей, но не наоборот!
Бывают связи и других типов: «один-к-одному» и «многие-ко-многим», но они используются значительно реже.

Создание таблиц и ключей с помощью конструктор таблиц

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

Создание таблицы Customers

1. В Обозреватель сервера разверните узел подключения к данным , а затем узел сампледатабасе. mdf .

   если не удается развернуть узел подключения к данным или отсутствует подключение сампледатабасе. mdf, нажмите кнопку Подключение к базе данных на панели инструментов обозреватель сервера. в диалоговом окне добавление соединения убедитесь, что в поле источник данных выбран Microsoft SQL Server файл базы данных , а затем найдите и выберите файл сампледатабасе. mdf. Завершите добавление подключения, нажав кнопку ОК.

2. Щелкните правой кнопкой мыши таблицы и выберите команду Добавить новую таблицу.

   Будет открыт Конструктор таблиц, отобразится сетка с одной строкой по умолчанию, которая представляет один столбец в создаваемой таблице. Путем добавления строк в сетку будут добавлены столбцы в таблицу.

3. В сетке добавьте строку для каждой из следующих записей.

   Имя столбца	Тип данных	Разрешить значения null
   		False (не установлен)
   		False (не установлен)
   		True (установлен)
   		True (установлен)

4. Щелкните строку правой кнопкой мыши и выберите пункт Задать первичный ключ.

5. Щелкните строку по умолчанию () правой кнопкой мыши и выберите пункт Удалить.

6. Назовите таблицу «Клиенты» путем обновления первой строки в области скриптов, как показано в следующем примере:

   Отобразятся примерно следующие сведения:

7. В левом верхнем углу Конструктор таблиц выберите Обновить.

8. В диалоговом окне Предварительный просмотр обновлений базы данных выберите обновить базу данных.

   Таблица Customers создается в файле локальной базы данных.

Создание таблицы Orders

1. Создайте еще одну таблицу, а затем добавьте строку для каждой записи следующей таблицы.

   Имя столбца	Тип данных	Разрешить значения null
   		False (не установлен)
   		False (не установлен)
   		True (установлен)
   		True (установлен)

2. Задайте OrderID в качестве первичного ключа, а затем удалите строку по умолчанию.

3. Назовите таблицу «Заказы» путем обновления первой строки в области скриптов, как показано в следующем примере:

4. В левом верхнем углу Конструктор таблиц выберите Обновить.

5. В диалоговом окне Предварительный просмотр обновлений базы данных выберите обновить базу данных.

   Таблица Orders создается в файле локальной базы данных. Если развернуть узел таблицы в обозреватель сервера, отобразятся две таблицы:

Создание внешнего ключа

1. В контекстной области в правой части сетки конструктор таблиц для таблицы Orders щелкните правой кнопкой мыши внешние ключи и выберите Добавить новый внешний ключ.

2. В появившемся текстовом поле замените текст ToTable на Customers.

3. в области T-SQL обновите последнюю строку, чтобы она соответствовала следующему примеру:

4. В левом верхнем углу Конструктор таблиц выберите Обновить.

5. В диалоговом окне Предварительный просмотр обновлений базы данных выберите обновить базу данных.

   Создается внешний ключ.

Создание связей между сущностями

Теперь, когда данные преобразованы в таблицы, нужно проанализировать связи между ними. Сложность базы данных определяется количеством элементов, взаимодействующих между двумя связанными таблицами. Определение сложности помогает убедиться, что вы разделили данные на таблицы наиболее эффективно.

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

Связь «один-к одному»

Когда существует только один экземпляр объекта A для каждого экземпляра объекта B, говорят, что между ними существует связь «один-к одному» (часто обозначается 1:1). Можно указать этот тип связи в ER-диаграмме линией с тире на каждом конце:

Если при проектировании и разработке баз данных у вас нет оснований разделять эти данные, связь 1:1 обычно указывает на то, что в лучше объединить эти таблицы в одну.

Но при определенных обстоятельствах целесообразнее создавать таблицы со связями 1:1. Если есть поле с необязательными данными, например «описание», которое не заполнено для многих записей, можно переместить все описания в отдельную таблицу, исключая пустые поля и улучшая производительность базы данных.

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

Связь «один-ко-многим»

Эта связи возникают, когда запись в одной таблице связана с несколькими записями в другой. Например, один клиент мог разместить много заказов, или у читателя может быть сразу несколько книг, взятых в библиотеке. Связи «один- ко-многим» (1:M) обозначаются так называемой «меткой ноги вороны», как в этом примере:

Чтобы реализовать связь 1:M, добавьте первичный ключ из «одной» таблицы в качестве атрибута в другую таблицу. Если первичный ключ таким образом указан в другой таблице, он называется внешним ключом. Таблица со стороны связи «1» представляет собой родительскую таблицу для дочерней таблицы на другой стороне.

Связь «многие-ко-многим»

Когда несколько объектов таблицы могут быть связаны с несколькими объектами другой. Говорят, что они имеют связь «многие-ко-многим» (M:N). Например, в случае студентов и курсов, поскольку студент может посещать много курсов, и каждый курс могут посещать много студентов.

На ER-диаграмме эти связи отображаются с помощью следующих строк:

При проектировании структуры базы данных реализовать такого рода связи невозможно. Вместо этого нужно разбить их на две связи «один-ко-многим».

Для этого нужно создать между этими двумя таблицами новую сущность. Если между продажами и продуктами существует связь M:N, можно назвать этот новый объект «sold_products», так как он будет содержать данные для каждой продажи. И таблица продаж, и таблица товаров будут иметь связь 1:M с sold_products. Этот вид промежуточного объекта в различных моделях называется таблицей ссылок, ассоциативным объектом или таблицей связей.

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

Обязательно или нет?

Другим способом анализа связей является рассмотрение того, какая сторона связи должна существовать, чтобы существовала другая. Необязательная сторона может быть отмечена кружком на линии. Например, страна должна существовать для того, чтобы иметь представителя в Организации Объединенных Наций, а не наоборот:

Два объекта могут быть взаимозависимыми (один не может существовать без другого).

Рекурсивные связи

Иногда при проектировании базы данных таблица указывает на себя саму. Например, таблица сотрудников может иметь атрибут «руководитель», который ссылается на другое лицо в этой же таблице. Это называется рекурсивными связями.

Лишние связи

Лишние связи — это те, которые выражены более одного раза

Как правило, можно удалить одну из таких связей без потери какой-либо важной информации. Например, если объект «ученики» имеет прямую связь с другим объектом, называемым «учителя», но также имеет косвенные отношения с учителями через «предметы», нужно удалить связь между «учениками» и «учителями»

Так как единственный способ, которым ученикам назначают учителей — это предметы.

Установка первичного ключа

Если вы сразу не установили ключевое поле, то надо это проделать. Для определения первичного ключа выделите поле Код группы и нажмите на панели конструктора таблиц кнопку с изображением ключа или выберите команду Ключевое поле из меню. В Microsoft Access можно выделить три типа ключевых полей:

счетчик, простой ключ и составной ключ.

Если первичный ключ не установлен пользователем до сохранения вновь созданной таблицы, Access выдаст запрос о необходимости включения в таблицу поля первичного ключа. При положительном ответе Access создаст ключевое поле типа счетчикс именем Код, в которое для каждого блока данных будет вводиться уникальный номер.

Простойключ определяется полем, содержащим уникальное значение.

Ключевое поле не позволит вводить в таблицу повторяющиеся или пустые значения, поскольку поле первичного ключа содержит однозначный идентификатор для каждой записи. Ключевое поле помогает Microsoft Access наиболее активно организовать поиск, хранение и объединение данных.

В случаях, когда невозможно гарантировать уникальность значений каждого поля, создают составной ключ, состоящий из нескольких полей. Такая ситуация возникает для таблицы, используемой для связывания двух таблиц в отношении «многие-ко-многим».

Один-ко-многим (1 — ¥)

Связь один-ко-многим связывает одну запись из
основной таблицы с несколькими записями из подчинённой таблицы, у которых
значения связанных полей совпадают. Это наиболее часто используемый тип связи,
который связывает подчинённую таблицу с основной, например, подстановочной
таблицей.

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

Добавление индексов и представлений

Индекс — это отсортированная копия одного или нескольких столбцов со значениями в возрастающем или убывающем порядке. Добавление индекса позволяет быстрее находить записи. Вместо повторной сортировки для каждого запроса система может обращаться к записям в порядке, указанном индексом.

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

Представление — это сохраненный запрос данных. Представления могут включать в себя данные из нескольких таблиц или отображать часть таблицы.

Приведём пример

Допустим, вы хотите создать базу данных для интернет-форума. На форуме есть зарегистрированные пользователи, создающие темы и оставляющие сообщения в данных темах. Вся эта информация и должна размещаться в базе данных.

В теории всё можно расположить в одной таблице, а именно:

Однако такое расположение противоречит атомарности, причём в столбцах «Созданные сообщения» и «Созданные темы» возможно неограниченное число значений. Целесообразнее всего разбить таблицу на три:

Теперь таблица «Пользователи» соответствует правилам. Но вот таблицы «Сообщения» и «Темы» — нет, т. к. не должно быть 2-х одинаковых строк. В нашем же случае один и тот же пользователь может написать 2 одинаковых сообщения:

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