Файл: Реляционные СУБД.pdf

В 1974 году компания IBM начала исследовательский проект по разработке РСУБД, получивший название System R[5]. Её первым коммерческий продуктом был IBM SQL/DS, выпущенный в 1982 году[6]^.

Однако первой коммерчески успешной РСУБД стала Oracle, выпущенная в 1979 году компанией Relational Software, которая впоследствии была переименована в Oracle Corporation[7]^.

В 1970-е годы, когда уже были получены почти все основные теоретические результаты и даже существовали первые прототипы реляционных СУБД, многие авторитетные специалисты отрицали возможность добиться эффективной реализации таких систем. Однако преимущества реляционного подхода и развитие методов и алгоритмов организации и управления реляционными базами данных привели к тому, что к концу 1980-х годов реляционные системы заняли на мировом рынке СУБД доминирующее положение.[8]^:37

В связи с резким ростом популярности РСУБД в 1980-х годах многие компании стали позиционировать свои СУБД как «реляционные» в рекламных целях, иногда не имея для этого достаточных оснований, вследствие чего автор реляционной модели данных Эдгар Кодд в 1985 году опубликовал свои знаменитые «12 правил Кодда», которым должна удовлетворять каждая РСУБД.

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

Эдгар Франк «Тед» Кодд (англ. Edgar Frank Codd; 23 августа 1923 — 18 апреля 2003) — британский учёный, работы которого заложили основы теории реляционных баз данных.

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

Важные события в жизни

Обучался математике и химии в Оксфордском университете (Exeter College).В 1948 переехал в Нью-Йорк, чтобы работать в IBM как математик-программист. В 1953, из-за преследований со стороны сенатора Джозефа Маккарти (Joseph McCarthy), Кодд переехал в Оттаву (Канада). В 1963 он вернулся в США и получил докторскую степень по информатике и вычислительной технике в Университете Мичигана (University of Michigan, Ann Arbor). В 1965 он переехал в Сан-Хосе (Калифорния), чтобы работать в Альмаденском Исследовательском Центре IBM.

В 60-х — 70-х годах он работал над своими теориями хранения данных. В 1970 издал работу «A Relational Model of Data for Large Shared Data Banks», которая считается первой работой по реляционной модели данных.

Кодд продолжил разрабатывать и расширять реляционную модель. Одна из нормальных форм названа в его честь (Нормальная форма Бойса — Кодда).

Подробности

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

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

Реляционные СУБД, ориентированные на реализацию систем операционной обработки данных, менее эффективны в задачах аналитической обработки, чем многомерные базы данных. Это связано, во-первых, с наличием достаточно жестких ограничений накладываемых существующей реализацией языка SQL. Примером такого реально существующего ограничения является предположение о том, что данные в реляционной базе неупорядочены (или более точно, упорядочены случайным образом). При этом их упорядочивание требует дополнительных затрат времени на сортировку при каждом обращении к базе данных. В аналитических системах ввод и выборка данных осуществляется большими порциями. В свою очередь данные, после того как они попадают в базу данных, остаются неизменными в течение длительного периода времени. И здесь более эффективным оказывается хранение данных в форме частично денормализованных таблиц, в которых для увеличения производительности могут храниться не только детализированные, но и предварительно вычисленные агрегированные значения. А для навигации и выборки могут использоваться специализированные, основанные на предположении о малой изменчивости и малоподвижности данных в базе данных, методы адресации и индексации. Такой способ организации данных, иногда называют предвычисленным, подчеркивая тем самым, его отличие от нормализованного реляционного подхода, предполагающего динамическое вычисление различного вида итогов (агрегация) и установление связей между реквизитами из разных таблиц (операции соединения).

Основные недостатки

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

Реляционные СУБД, возможно, никогда не уйдут со сцены, но дни их господства определенно сочтены, полагает Пол Крил, опубликовавший в сентябре 2011 года статью об этом в InfoWorld. Он цитирует аналитика Робина Блора, который утверждает, что архитектура реляционных СУБД морально устарела, так как была создана еще в прошлую эпоху и не отвечает современным требованиям.

Реляционные СУБД все еще доминируют в системах обработки финансовых транзакций, но сегодня компании все шире применяют СУБД новой архитектуры NoSQL — горизонтально масштабируемые, распределенные и разрабатываемые в открытых кодах. Примеры таких систем — Hadoop, MapReduce и VoltDB. По оценкам аналитиков Forrester, около 75% данных на предприятиях это либо полуструктурированная информация (XML, электронная почта и EDI), либо неструктурированная (текст, изображения, аудио и видео), и лишь 5% от этих данных хранится в реляционных СУБД, а остальное — в базах других типов или в виде файлов, и неподвластно обработке реляционными системами.

По мнению Блора, реляционные СУБД «могут умереть так, что этого никто не заметит» — например, если Oracle в своей СУБД попросту заменит SQL-механизм на NoSQL. Таким механизмом, считает аналитик, могла бы стать одна из существующих сегодня столбцовых СУБД.

Виды связей таблиц

Существует три виды связей таблиц.

Связь с отношением «один-ко-многим». Является наиболее часто используемым типом связи между таблицами. В такой связи каждой записи в таблице A могут соответствовать несколько записей в таблице B, а запись в таблице B не может иметь более одной соответствующей ей записи в таблице A. Например, в одном подразделение может работать несколько сотрудников, но ни один сотрудник не может работать сразу в нескольких подразделениях. Принятое обозначение (1 – ∞).

Отношение «многие-ко-многим». При этом отношении одной записи в таблице A могут соответствовать несколько записей в таблице B, а одной записи в таблице B несколько записей в таблице A. Такая схема реализуется только с помощью третьей (связующей) таблицы, ключ которой состоит по крайней мере из двух полей, которые являются полями внешнего ключа в таблицах A и B. Например, между таблицами инспекторов и лиц, пересекающих границу, связь определяется отношением «многие-ко-многим». Один декларант может обсуживаться у нескольких инспекторов, в то же время инспектор может обслуживать несколько лиц. Такая связь определяется путем создания двух связей с отношением «один-ко-многим» для таблицы Инспектор_Декларант, в которой обязательно должны быть поля КлючИнспектора и КлючДекларанта.

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

Популярные СУБД

SQLite: очень мощная встраиваемая РСУБД.
MySQL: самая популярная и часто используемая РСУБД.
PostgreSQL: самая продвинутая и гибкая РСУБД.

SQLite

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

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

Поддерживаемые типы данных

NULL: NULL-значение.
INTEGER: целое со знаком, хранящееся в 1, 2, 3, 4, 6, или 8 байтах.
REAL: число с плавающей запятой, хранящееся в 8-байтовом формате IEEE.
TEXT: текстовая строка с кодировкойUTF-8, UTF-16BE или UTF-16LE.
BLOB: тип данных, хранящийся точно в таком же виде, в каком и был получен.

Note: для получения более подробной информации ознакомьтесь с документацией.

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

Файловая: вся база данных хранится в одном файле, что облегчает перемещение.
Стандартизированная: SQLite использует SQL; некоторые функции опущены (RIGHT OUTER JOIN или FOR EACH STATEMENT), однако, есть и некоторые новые.
Отлично подходит для разработки и даже тестирования: во время этапа разработки большинству требуется масштабируемое решение. SQLite, со своим богатым набором функций, может предоставить более чем достаточный функционал, при этом будучи достаточно простой для работы с одним файлом и связанной сишной библиотекой.

Недостатки

Отсутствие пользовательского управления: продвинутые БД предоставляют пользователям возможность управлять связями в таблицах в соответствии с привилегиями, но у SQLite такой функции нет.
Невозможность дополнительной настройки: опять-таки, SQLite нельзя сделать более производительной, поковырявшись в настройках — так уж она устроена.

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

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

Когда не стоит использовать SQLite

Многопользовательские приложения: если вы работаете над приложением, доступом к БД в котором будут одновременно пользоваться несколько человек, лучше выбрать полнофункциональную РСУБД — например, MySQL.
Приложения, записывающие большие объёмы данных: одним из ограничений SQLite являются операции записи. Эта РСУБД допускает единовременное исполнение лишь одной операции записи.

MySQL

MySQL — это самая популярная из всех крупных серверных БД. Разобраться в ней очень просто, да и в сети о ней можно найти большое количество информации. Хотя MySQL и не пытается полностью реализовать SQL-стандарты, она предлагает широкий функционал. Приложения общаются с базой данных через процесс-демон.

Поддерживаемые типы данных

TINYINT: очень маленькое целое.
SMALLINT: маленькое целое.
MEDIUMINT: целое среднего размера.
INT или INTEGER: целое нормального размера.
BIGINT: большое целое.
FLOAT: знаковое число с плавающей запятой одинарной точности.
DOUBLE, DOUBLE PRECISION, REAL: знаковое число с плавающей запятой двойной точности.
DECIMAL, NUMERIC: знаковое число с плавающей запятой.
DATE: дата.
DATETIME: комбинация даты и времени.
TIMESTAMP: отметка времени.
TIME: время.
YEAR: год в формате YY или YYYY.
CHAR: строка фиксированного размера, дополняемая справа пробелами до максимальной длины.
VARCHAR: строка переменной длины.
TINYBLOB, TINYTEXT: BLOB- или TEXT-столбец длиной максимум 255 (2^8 — 1) символов.
BLOB, TEXT: BLOB- или TEXT-столбец длиной максимум 65535 (2^16 — 1) символов.
MEDIUMBLOB, MEDIUMTEXT: BLOB- или TEXT-столбец длиной максимум 16777215 (2^24 — 1) символов.
LONGBLOB, LONGTEXT: BLOB- или TEXT-столбец длиной максимум 4294967295 (2^32 — 1) символов.
ENUM: перечисление.
SET: множества.