Реляционные СУБД
Содержание:
Истрия
В 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: множества.
Преимущества
- Простота: MySQL легко устанавливается. Существует много сторонних инструментов, включая визуальные, облегчающих начало работы с БД.
- Много функций: MySQL поддерживает большую часть функционала SQL.
- Безопасность: в MySQL встроено много функций безопасности.
- Мощность и масштабируемость: MySQL может работать с действительно большими объёмами данных, и неплохо походит для масштабируемых приложений.
- Скорость: пренебрежение некоторыми стандартами позволяет MySQL работать производительнее, местами срезая на поворотах.
Недостатки
- Известные ограничения: по определению, MySQL не может сделать всё, что угодно, и в ней присутствуют определённые ограничения функциональности.
- Вопросы надёжности: некоторые операции реализованы менее надёжно, чем в других РСУБД.
- Застой в разработке: хотя MySQL и является open-source продуктом, работа над ней сильно заторможена. Тем не менее, существует несколько БД, полностью основанных на MySQL (например, MariaDB). Кстати, подробнее о родстве MariaDB и MySQL можно из нашего интервью с создателем обеих РСУБД — Джеймсом Боттомли.
Когда стоит использовать MySQL
- Распределённые операции: когда вам нужен функционал бо́льший, чем может предоставить SQLite, стоит использовать MySQL.
- Высокая безопасность: функции безопасности MySQL предоставляют надёжную защиту доступа и использования данных.
- Веб-сайты и приложения: большая часть веб-ресурсов вполне может работать с MySQL, несмотря на ограничения. Этот инструмент весьма гибок и прост в обращении, что только на руку в длительной перспективе.
- Кастомные решения: если вы работаете над очень специфичным продуктом, MySQL подстроится под ваши потребности благодаря широкому спектру настроек и режимов работы.
Когда не стоит использовать MySQL
- SQL-совместимость: поскольку MySQL не пытается полностью реализовать стандарты SQL, она не является полностью совместимой с SQL. Из-за этого могут возникнуть проблемы при интеграции с другими РСУБД.
- Конкурентность: хотя MySQL неплохо справляется с операциями чтения, одновременные операции чтения-записи могут вызвать проблемы.
- Недостаток функций: в зависимости от выбора движка MySQL может недоставать некоторых функций.
PostgreSQL
PostgreSQL — это самая продвинутая РСУБД, ориентирующаяся в первую очередь на полное соответствие стандартам и расширяемость. PostgreSQL, или Postgres, пытается полностью соответствовать SQL-стандартам ANSI/ISO.
PostgreSQL отличается от других РСУБД тем, что обладает объектно-ориентированным функционалом, в том числе полной поддержкой концепта ACID (Atomicity, Consistency, Isolation, Durability).
Будучи основанным на мощной технологии Postgres отлично справляется с одновременной обработкой нескольких заданий. Поддержка конкурентности реализована с использованием MVCC (Multiversion Concurrency Control), что также обеспечивает совместимость с ACID.
Хотя эта РСУБД не так популярна, как MySQL, существует много сторонних инструментов и библиотек для облегчения работы с PostgreSQL.
Поддерживаемые типы данных
- bigint: знаковое 8-байтное целое.
- bigserial: автоматически инкрементируемое 8-битное целое.
- bit [(n)]: битовая строка фиксированной длины.
- bit varying [(n)]: битовая строка переменной длины.
- boolean: булевская величина.
- box: прямоугольник на плоскости.
- bytea: бинарные данные.
- character varying [(n)]: строка символов фиксированной длины.
- character [(n)]: строка символов переменной длины.
- cidr: сетевой адрес IPv4 или IPv6.
- circle: круг на плоскости.
- date: календарная дата.
- double precision: число с плавающей запятой двойной точности.
- inet: адрес хоста IPv4 или IPv6.
- integer: знаковое 4-байтное целое.
- interval [fields] [(p)]: временной промежуток.
- line: бесконечная прямая на плоскости.
- lseg: отрезок на плоскости.
- macaddr: MAC-адрес.
- money: денежная величина.
- path: геометрический путь на плоскости.
- point: геометрическая точка на плоскости.
- polygon: многоугольник на плоскости.
- real: число с плавающей запятой одинарной точности.
- smallint: знаковое 2-байтное целое.
- serial: автоматически инкрементируемое 4-битное целое.
- text: строка символов переменной длины.
- time [(p)] [without time zone]: время суток (без часового пояса).
- time [(p)] with time zone: время суток (с часовым поясом).
- timestamp [(p)] [without time zone]: дата и время (без часового пояса).
- timestamp [(p)] with time zone: дата и время (с часовым поясом).
- tsquery: запрос текстового поиска.
- tsvector: документ текстового поиска.
- txid_snapshot: снэпшот ID пользовательской транзакции.
- uuid: уникальный идентификатор.
- xml: XML-данные.
Преимущества
- Полная SQL-совместимость.
- Сообщество: PostgreSQL поддерживается опытным сообществом 24/7.
- Поддержка сторонними организациями: несмотря на очень продвинутые функции, PostgreSQL используется в многих инструментах, связанных с РСУБД.
- Расширяемость: PostgreSQL можно программно расширить за счёт хранимых процедур.
- Объектно-ориентированность: PostgreSQL — не только реляционная, но и объектно-ориентированная СУБД.
Недостатки
- Производительность: В простых операциях чтения PostgreSQL может уступать своим соперникам.
- Популярность: из-за своей сложности инструмент не очень популярен.
- Хостинг: из-за вышеперечисленных факторов проблематично найти подходящего провайдера.
Когда стоит использовать PostgreSQL
- Целостность данных: если приоритет стоит на надёжность и целостность данных, PostgreSQL — лучший выбор.
- Сложные процедуры: если ваша БД должна выполнять сложные процедуры, стоит выбрать PostgreSQL в силу её расширяемости.
- Интеграция: если в будущем вам предстоит перемещать всю базу на другое решение, меньше всего проблем возникнет с PostgreSQL.
Когда не стоит использовать PostgreSQL
- Скорость: если всё, что нужно — это быстрые операции чтения, не стоит использовать PostgreSQL.
- Простые ситуации: если вам не требуется повышенная надёжность, поддержка ACID и всё такое, использование PostgreSQL — это стрельба из пушки по мухам.
Источники
1 https://ru.wikipedia.org/wiki/%D0%A0%D0%B5%D0%BB%D1%8F%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D0%B0%D1%8F_%D0%A1%D0%A3%D0%91%D0%94
2 http://www.tadviser.ru/index.php/%D0%A1%D1%82%D0%B0%D1%82%D1%8C%D1%8F:%D0%A0%D0%B5%D0%BB%D1%8F%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D0%B0%D1%8F_%D0%A1%D0%A3%D0%91%D0%94
3 https://studfiles.net/preview/2893940/page:8/
4,https://tproger.ru/translations/sqlite-mysql-postgresql-comparison/
- Виды проектного анализа (Сущность проектного анализа.)
- Подразделения и персонал. Предприятия гостеприимства. Основные элементы сервиса в ресторанах различного уровня
- Становление и развитие адвокатуры в России на рубеже XIX - XX вв.
- Виды гражданских правоотношений (Гражданское правоотношение как вид общественных отношений)
- Инновационные проекты
- Досрочного прекращения полномочий Президента РФ
- Общие требования к оригинал-макету
- Основные принципы и механизмы корпоративного управления. (Основные понятия корпоративного управления)
- Носители документов, их развитие
- Поздний модернизм (1940-1980-е гг.)
- Система информации в оценке бизнеса (Требования к классификации информации при оценке стоимости бизнеса)
- Понятие и виды юридических фактов в гражданском праве (Дисциплина: Гражданское право)