База данных

Отношения или таблицы

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

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

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

Шаг 2. Избавляемся от дубликатов в столбцах

Как было оговорено выше, столбцы “username” и “following_username” содержат дубликаты данных. Они возникли в результате того, что я хотел отобразить отношения между твиттами и пользователями. Давайте улучшим нашу структуру БД, разделив существующую таблицу на две: в одной будем хранить информацию, а в другой — отношения между записями.

Поскольку @Brett_Englebert подписан на @RealSkipBayless, то в таблице “following” отобразим это следующим образом: имя @Brett_Englebert поместим в колонку “from_user”, а @RealSkipBayless в “to_user.” Давайте посмотрим, как будет выглядеть таблица “following” после разделения Таблицы 1:

Таблица 2. following

from_user	to_user
_DreamLead	Scootmedia
_DreamLead	MetiersInternet
GunnarSvalander	klout
GunnarSvalander	zillow
GEsoftware	DayJobDoc
GEsoftware	byosko
adrianburch	CindyCrawford
adrianburch	Arjantim
AndyRyder	MichaelDell
AndyRyder	Yahoo
Brett_Englebert	RealSkipBayless
Brett_Englebert	stephenasmith
NimbusData	dellock6
NimbusData	rohitkilam
SSWUGorg	drsql
SSWUGorg	steam_games

Таблица 3. users

full_name	username	text	created_at
Boris Hadjur	_DreamLead	What do you think about #emailing #campaigns #traffic in #USA? Is it a good market nowadays? do you have #databases?	Tue, 12 Feb 2013 08:43:09 +0000
Gunnar Svalander	GunnarSvalander	Bill Gates Talks Databases, Free Software on Reddit http://t.co/ShX4hZlA #billgates #databases	Tue, 12 Feb 2013 07:31:06 +0000
GE Software	GEsoftware	RT @KirkDBorne: Readings in #Databases: excellent reading list, many categories: http://t.co/S6RBUNxq via @rxin Fascinating.	Tue, 12 Feb 2013 07:30:24 +0000
Adrian Burch	adrianburch	RT @tisakovich: @NimbusData at the @Barclays Big Data conference in San Francisco today, talking #virtualization, #databases, and #flash memory.	Tue, 12 Feb 2013 06:58:22 +0000
Andy Ryder	AndyRyder5	http://t.co/D3KOJIvF article about Madden 2013 using AI to prodict the super bowl #databases #bus311	Tue, 12 Feb 2013 05:29:41 +0000
Andy Ryder	AndyRyder5	http://t.co/rBhBXjma an article about privacy settings and facebook #databases #bus311	Tue, 12 Feb 2013 05:24:17 +0000
Brett Englebert	Brett_Englebert	#BUS311 University of Minnesota’s NCFPD is creating #databases to prevent “food fraud.” http://t.co/0LsAbKqJ	Tue, 12 Feb 2013 01:49:19 +0000
Brett Englebert	Brett_Englebert	#BUS311 companies might be protecting their production #databases, but what about their backup files? http://t.co/okJjV3Bm	Tue, 12 Feb 2013 01:31:52 +0000
Nimbus Data Systems	NimbusData	@NimbusData CEO @tisakovich @BarclaysOnline Big Data conference in San Francisco today, talking #virtualization, #databases,& #flash memory	Mon, 11 Feb 2013 23:15:05 +0000
SSWUG.ORG	SSWUGorg	Don’t forget to sign up for our FREE expo this Friday: #Databases, #BI, and #Sharepoint: What You Need to Know! http://t.co/Ijrqrz29	Mon, 11 Feb 2013 22:15:37 +0000

Уже лучше. Теперь в таблице “users” (Таблица 3) у нас хранится только информация о твиттах, а в таблице following (Таблица 2) — зависимость пользователей.

Основатель теории реляционных баз данных, Эдгар Кодд, назвал бы этот процесс (удаления повторений из столбцов таблиц) приведением БД к первой нормальной форме.

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

Для встроенных в облако микрослужб, требующих реляционных данных, Azure предлагает четыре управляемых предложения в виде услуги (DBaaS), показанные на рисунке 5-11.

Рис. 5-11. Управляемые реляционные базы данных, доступные в Azure

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

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

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

Столбчатые хранилища данных

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

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

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

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

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

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

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

Соответствующие службы Azure:

• Cosmos API Cassandra базы данных
• Использование HBase в HDInsight

Сравниваем три модели баз данных

Первая, иерархическая модель данных, имеет древовидную структуру («родитель-потомок»), и поддерживает только отношения типа «один к одному» или «один ко многим». Эта модель позволяет быстро получать данные, но не отличается гибкостью. Иногда роль элемента (родителя или потомка) неясна и не подходит для иерархической модели.

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

Третья модель — реляционная — более гибкая, чем иерархическая и проще для управления, чем сетевая. Реляционная модель сегодня используется чаще всего.

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

Объекты связываются отношениями, основные типы которых можно определить следующим образом:

«Один к одному»

В этом виде отношений один объект связан с другим. Например, Менеджер -> Отдел.

У каждого менеджера может быть только один отдел, и наоборот.

«Один ко многим»

В моделях данных отношение одного объекта с несколькими. Например, Сотрудник -> Отдел.

Каждый сотрудник может быть только в одном отделе, но в самом отделе может быть больше одного сотрудника.

«Многие ко многим»

В заданный момент времени объект может быть связан с любым другим. Например, Сотрудник -> Проект.

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

В реляционной модели объекты и их отношения представлены двухмерным массивом или таблицей.

Каждая таблица представляет объект.

Каждая таблица состоит из рядов и столбцов.

Отношения между объектами представлены столбцами.

Каждый столбец представляет атрибут объекта.

Значения столбцов выбираются из области или набора всех возможных значений.

Столбцы, которые используются для связи объектов, называются ключевыми. Есть два типа ключей — первичные и внешние.

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

Преимущества реляционной модели данных:

1. Простота использования.
2. Гибкость.
3. Независимость данных.
4. Безопасность.
5. Простота практического применения.
6. Слияние данных.
7. Целостность данных.

Недостатки:

1. Избыточность данных.
2. Низкая производительность.

Другие модели баз данных (ООСУБД)

В последнее время на рынке СУБД появились продукты, представленные объектными и объектно-ориентированной моделью данных, такие как Gem Stone и Versant ОСУБД. Также производятся исследования в области многомерных и логических моделей данных.

Особенности объектно-ориентированных систем управления базами данных (ООСУБД):

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

А также поддержку классов объектов и наследование свойств и методов классов подклассами и их объектами.

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

Примеры ООСУБД:

• D Gemstone;
• IRS;
• ORION;
• ONTOS.

Применение ООСУБД:

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

Пожалуйста, оставляйте ваши отзывы по текущей теме статьи. За комментарии, отклики, дизлайки, лайки, подписки низкий вам поклон!

PostgreSQL

PostgreSQL – это продвинутая открытая объектно-ориентированная СУБД. PostgreSQL реализует SQL-стандарты ANSI/ISO.

В отличие от других СУБД, PostgreSQL поддерживает очень важные объектно-ориентированные и реляционные функции баз данных: надежные транзакции ACID (атомарность, согласованность, изолированность, долговечность) и т.п.

Основанная на надёжной технологии СУБД PostgreSQL может одновременно обрабатывать большое количество задач. Поддержка согласованности достигается без блокирования операций чтения благодаря MVCC.

Хотя СУБД PostgreSQL не так популярна, как MySQL, для неё тоже разработано большое количество дополнительных инструментов и библиотек, которые упрощают работу с данными и увеличивают производительность СУБД.

Типы данных PostgreSQL

• bigint: знаковое восьмибайтное целое число.
• bigserial: восьмибайтное целое число с автоинкрементом.
• bit : битовая строка фиксированной длины.
• bit varying : битовая строка с переменной длиной.
• boolean: логическое значение (true/false).
• box: четырёхугольник на плоскости.
• bytea: бинарные данные.
• character varying : строка символов с переменной длиной.
• character : строка символов с фиксированной длиной
• cidr: адрес сети IPv4 или IPv6.
• circle: круг на плоскости.
• date: дата (год, месяц, день).
• double precision: число с плавающей точкой двойной точности (8 байт).
• inet: адрес хоста IPv4 или IPv6.
• integer: знаковое четырёхбайтовое целое число.
• interval : промежуток времени.
• line: бесконечная линия на плоскости.
• lseg: сегмент линии на плоскости.
• macaddr: MAC (Media Access Control) адрес.
• money: валюта.
• numeric : точное числовое значение с выбранной точностью.
• path: геометрический путь на плоскости.
• point: геометрическая точка на плоскости.
• polygon: закрытый геометрический путь на плоскости (полигон)
• real: число с плавающей точкой одинарной точности (4 байта).
• smallint: знаковое двухбайтное целое число.
• serial: четырёхбайтное целое число с автоинкрементом.
• text: строка символов с переменной длиной.
• time : время дня (без часового пояса).
• time with time zone: время дня и часовой пояс.
• timestamp : временная метка (дата и время) без часового пояса.
• timestamp with time zone: временная метка с часовым поясом.
• tsquery: запрос текстового поиска.
• tsvector: документ текстового поиска.
• txid_snapshot: снапшот ID-транзакции уровня пользователя.
• uuid: универсальный уникальный идентификатор.
• xml: данные XML.

Преимущества PostgreSQL

• Система управления базами данных PostgreSQL открытая, SQL-совместимая, свободная.
• Активное сообщество PostgreSQL поможет найти решение любой проблемы, связанной с СУБД, в любое время суток.
• Поддержка сторонних инструментов: помимо встроенных продвинутых функций, PostgreSQL поддерживает множество открытых сторонних инструментов для проектирования, управления данными и т.п.
• Масштабируемость и расширяемость.
• Объектно-ориентированность.

Недостатки PostgreSQL

• Производительность: в некоторых ситуациях производительность PostgreSQL ниже, чем у MySQL.
• Невысокая популярность.
• В связи с вышеперечисленными недостатками не все хостинг-провайдеры поддерживают PostgreSQL.

Когда использовать PostgreSQL

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

Когда лучше не использовать PostgreSQL

• Если приложению нужны быстрые операции чтения.
• Если приложению не нужна абсолютная целостность данных, ACID или сложная структура, PostgreSQL может стать слишком сложным решением.
• Репликация данных сложнее, чем в MySQL, потому в кластерах PostgreSQL лучше не использовать.

MySQLPostgreSQLSQLSQLite

Создание структуры таблицы БД Access командой CREATE TABLE языка SQL

Инструкция SQL (SELECT) или запрос на выборку данных из таблиц БД Access рассмотрена в работе SQL — язык доступа и управления СУБД Access. В этой статье рассмотрим инструкцию SQL (CREATE TABLE) запроса на изменение.

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

Рассмотрим создание структуры таблиц базы данных БД «Деканат» на основе модели «сущность – связь» в СУБД Access с помощью запросов SQL. Для этого создадим новую базу данных sql_training_st.mdb в приложении Access 2007.

Следует отметить, что файл новой базы данных сохраним в формате Access 2002-2003. После создания новой БД, в окне приложения будет отображаться окно БД на вкладке Режим таблицы и новая пустая таблица с именем Таблица 1 в режиме таблица.

Закрываем Таблицу1, щелкнув правой кнопкой мыши на Таблица1 в окне редактирования, и в контекстном меню выбрав команду Закрыть. Далее создадим структуру таблицы Группы аналогичную структуре таблицы Группы, созданной в Конструкторе, используя команду SQL create table.

Для этого в окне БД щелкаем левой кнопкой мыши на вкладке Создание и выбираем команду «Конструктор запросов». В результате в окне редактирования откроется объект «Запрос1» и окно диалога «Добавление таблицы». Закроем окно диалога, щелкнув левой кнопкой мыши на пиктограмме «Закрыть» в правом верхнем углу этого окна.

Затем создаем структуру таблицы «Группы», для этого выберем режим SQL, выполнив команду Вид/ Режим SQL. Удаляем появившуюся в окне запроса команду SELECT и вводим с клавиатуры следующую команду:

create table Группы (КодГруппы COUNTER CONSTRAINT PrimaryKey PRIMARY KEY, Название char(6), Курс int, Семестр int);

Сохраняем запрос с именем «Создание Группы». В результате в «Области переходов» появится несвязанный объект — «Создание Группы». После сохранения запроса необходимо выполнить этот запрос, щелкая на пиктограмме «Выполнить». В результате выполнения команды «create table Группы» в «Области переходов» появится объект — «Группы: таблицы».

Закроем окно «Создание Группы» и откроем объект – «Группы: таблица» в режиме конструктора.

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

Затем создаем структуру таблицы «Студенты», для этого выберем режим SQL, выполнив команду Вид/ Режим SQL. Удаляем появившуюся в окне запроса команду SELECT и вводим с клавиатуры следующую команду:

create table Студенты (КодСтудента COUNTER CONSTRAINT PrimaryKey PRIMARY KEY, КодГруппы int, Фамилия char(20), Имя char(15), Отчество char(15), Пол char(1), Дата_рождения DATE, Место_рождения MEMO, FOREIGN KEY (КодГруппы) REFERENCES Группы (КодГруппы));

Для описания связей между таблицами «Группы» и «Студенты» через поле «КодГруппы» (отношение «один-ко-многим»), а также обеспечения целостности базы данных применена запись «FOREIGN KEY (КодГруппы) REFERENCES Группы (КодГруппы)».

Сохраняем запрос с именем «Создание Студенты». В результате в «Области переходов» появится несвязанный объект — «Создание Студенты». После сохранения запроса необходимо выполнить этот запрос, щелкая на пиктограмме «Выполнить». В результате выполнения команды «create table Студенты» в «Области переходов» появится объект — «Студенты: таблицы».

Обучение в интернет, . Обратная связь

MergeSort (Сортировка слиянием)

Что вы делаете, когда вам нужно отсортировать коллекцию? Что? Вы вызываете функцию sort ()… Ок, хороший ответ… Но для базы данных вы должны понимать, как работает эта функция sort ().

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

Более того, понимание сортировки слиянием поможет нам позже понять общую операцию join баз данных, называемую merge join (объединение слиянием).

Merge (слияние)

Как и многие полезные алгоритмы, сортировка слиянием основана на хитрости: объединение 2 отсортированных массивов размера N / 2 в N-элементный отсортированный массив стоит всего N операций. Эта операция называется слиянием.

Давайте посмотрим, что это значит на простом примере:

На этом рисунке видно, что для построения окончательного отсортированного массива из 8 элементов вам нужно всего лишь выполнить итерацию один раз в 2х 4-элементных массивах. Поскольку оба 4-элементных массива уже отсортированы:

• 1) вы сравниваете оба текущих элемента в двух массивах (в начале текущий = первому)
• 2) затем возьмите наименьший, чтобы поместить его в массив из 8 элементов
• 3) и переходите к следующему элементу в массиве, где вы взяли самый маленький элемент
• и повторяйте 1,2,3, пока не дойдете до последнего элемента одного из массивов.
• Затем вы берете остальные элементы другого массива, чтобы поместить их в массив из 8 элементов.

Это работает, потому что оба 4-элементных массива отсортированы, и поэтому вам не нужно «возвращаться» в этих массивах.

Теперь, когда мы поняли этот трюк, вот мой псевдокод для merge:

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

• Фаза деления, где массив делится на меньшие массивы
• Фаза сортировки, где маленькие массивы объединяются (используя объединение), чтобы сформировать больший массив.

Division phase (фаза деления)

На этапе деления массив делится на унитарные массивы за 3 шага. Формальное количество шагов — log(N) (поскольку N=8, log(N) = 3).

Откуда я это знаю?

Я гений! Одним словом — математика. Идея состоит в том, что каждый шаг делит размер исходного массива на 2. Количество шагов — это количество раз, которое вы можете разделить исходный массив на два. Это точное определение логарифма (с основанием 2).

Sorting phase (Фаза сортировки)

На этапе сортировки вы начинаете с унитарных (одноэлементных) массивов. В течение каждого этапа вы применяете несколько операций слияния, и общая стоимость составляет N = 8 операций:

• На первом этапе у вас есть 4 слияния, которые стоят 2 операции каждый
• На втором шаге у вас есть 2 слияния, которые стоят 4 операции каждый
• На третьем шаге у вас есть 1 слияние, которое стоит 8 операций

Поскольку существует log (N) шагов, общая стоимость N * log(N) операций.

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

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

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

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

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

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

Достоинства документных баз

• Позволяют хранить объекты с разной структурой.
• Могут отображать почти все структуры данных, включая объекты на основе ООП, списки и словари, используя старый добрый JSON.
• Несмотря на то, что NoSQL не схематичны по своей природе, они часто поддерживают проверку схемы. Это значит, что вы можете сделать коллекцию со схемой. Эта схема не будет простой, как таблица: это будет JSON схема со специфическими полями.
• Запросы к NoSQL очень быстрые — каждая запись независима и, следовательно, время запроса не зависит от размера базы. По той же причине эта БД поддерживает параллельность.
• В NoSQL масштабирование БД осуществляется добавлением компьютеров и распределением данных между ними, этот метод называется горизонтальное масштабирование. Оно позволяет автоматически добавлять ресурсы к БД, когда нам нужно, не провоцируя простои.

SQL vs. NoSQL: MySQL или MongoDB

Разобравшись с ключевыми структурными различиями SQL и NoSQL баз данных, стоит внимательно рассмотреть их функциональные особенности на примере MySQL и MongoDB.

MySQL: реляционная СУБД

Преимущества MySQL:

• Проверено временем: MySQL — крайне развитая СУБД, что означает наличие большого сообщества вокруг неё, множество примеров и высокую надёжность;
• Совместимость: MySQL доступна на всех основных платформах, включая Linux, Windows, Mac, BSD и Solaris. Также у неё есть библиотеки для языков вроде Node.js, Ruby, C#, C++, Java, Perl, Python и PHP;
• Окупаемость: Это СУБД с открытым исходным кодом, находящаяся в свободном доступе;
• Реплицируемость: Базу данных MySQL можно распределять между несколькими узлами, таким образом уменьшая нагрузку и улучшая масштабируемость и доступность приложения;
• Шардинг: В то время как шардинг невозможен на большинстве SQL баз данных, MySQL является исключением.

MongoDB: нереляционная СУБД

Преимущества MongoDB:

• Динамическая схема: Как упоминалось выше, эта СУБД позволяет гибко работать со схемой данных без необходимости изменять сами данные;
• Масштабируемость: MongoDB горизонтально масштабируема, что позволяет легко уменьшить нагрузку на сервера при больших объёмах данных;
• Удобство в управлении: СУБД не нуждается в отдельном администраторе базы данных. Благодаря достаточному удобству в использовании, ей легко могут пользоваться как разработчики, так и системные администраторы;
• Скорость: Высокая производительность при выполнении простых запросов;
• Гибкость: В MongoDB можно без вреда для существующих данных, их структуры и производительности СУБД добавлять поля или колонки.

Какую СУБД выбрать?

MySQL — верный выбор для любого проекта, который может положиться на предопределённую структуру и заданные схемы. С другой стороны, MongoDB — отличный вариант для быстрорастущих проектов без определённой схемы данных. В особенности если вы не можете определить схему для своей базы данных, вам не подходит ни одна из предлагаемых другими СУБД или в вашем проекте она постоянно меняется, как, например, в случае с мобильными приложениями, системами аналитики в реальном времени или контент-менеджмента.

Ключи отношения в реляционной модели данных

Ключи отношения могут быть следующми:

• суперключ;
• потенциальный ключ;
• первичный ключ;
• внешний ключ;
• суррогатный ключ.

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

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

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

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

Первичный ключ (primary key, PK) — это один из потенциальных ключей отношения,
выбранный в качестве основного ключа. Допустимо объявление одного и только одного первичного ключа.
Атрибуты первичного ключа не могут принимать значения Null.

Внешний ключ (foreign key, FK) — это ключ, объявленный в базовом отношении,
который при этом ссылается на первичный того же самого или какого-то другого базового отношения.

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

Пример 2. Есть база данных сети аптек. В ней есть таблица «Аптеки», в
которую занесены все аптеки сети, и есть таблица «Препараты». Кроме того, есть таблица «Наличие», в которую
заносятся данные о наличии препаратов в каждой аптеке. В таблице наличие есть поля: «Аптека» (в ней —
идентификаторы аптек), «Препарат» (в ней — идентификаторы препаратов), «Количество». Возникает проблема:
в случае поступления в аптеку некоторого количества препарата можно не заметить, что в той же аптеке тот
же препарат уже содержится в некотором количестве и сделать новую записись в таблице, в которой аптека и
препарат будут повторяться. Как на уровне ключей избежать этой проблемы?

Решение. Можно объявить первичным ключём таблицы «Наличие» составной ключ, состоящий
из идентификатора аптеки и идентификатора препарата. Тогда в таблице невозможно повторение в разных записях
сочетания аптеки и прапарата. Первичный ключ может быть не только простым, но и
составным.

Итоги

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

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