Объектно реляционные базы данных реферат

Обновлено: 05.07.2024

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

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

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

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

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

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

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

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

Подробности

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

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

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

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

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


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

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

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

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

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

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

SQLite

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

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

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

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.

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

Типология баз данных.

Базы данных можно классифицировать по разным признакам:


  • по организации информации (реляционные, объектно-ориентированные)

  • по способу хранения информации (централизованные, распределенные)

  • по способу доступа к хранимым данным (настольные, серверные)

  • по характеру хранимой информации (фактографические, документальные)

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

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

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

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

Другой значимый недостаток - при добавлении нового поля или записи требуется переопределение всей базы данных.
К преимуществам иерархических БД относится быстрый доступ и обновление.
Структура иерархической системы баз данных была разработана IBM в начале 1960-х годов. Иерархические базы данных широко используются для создания приложений высокой производительности и доступности, обычно в банковской и телекоммуникационной отраслях. Например, известные базы данных IBM Information Management System (IMS) и реестр Windows относятся к иерархическим БД.

Сетевые базы данных.

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

Структура базы данных сети была изобретена Чарльзом Бахманом. Некоторые из популярных сетевых баз данных: интегрированное хранилище данных (IDS), IDMS (интегрированная система управления базами данных), менеджер баз данных Raima, TurboIMAGE и Univac DMS-1100.
Реляционные базы данных.

Реляционная БД впервые была предложена исследователем из IBM Эдгаром Фрэнком Коддом в 1969 году.

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

Язык структурированных запросов (SQL) - это язык, используемый для запросов к СУБД, включая вставку, обновление, удаление и поиск записей. Реляционные базы данных работают с каждой таблицей, в которой есть ключевое поле, однозначно указывающее на каждую строку. Эти ключевые поля можно использовать для соединения одной таблицы данных с другой.
Реляционные базы данных являются наиболее популярными и широко используемыми базами данных. Некоторые из популярных DDBMS - это Oracle, SQL Server, MySQL, SQLite и IBM DB2.


  • Реляционные базы данных легки в освоении.

  • Записи базы данных могут быть изменены без указания всего тела таблицы.

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


  • Атрибуты являются атомарными

  • Каждая строка уникальна.

  • Поля не упорядочены.

  • Последовательность строк незначительна.

  • Каждое поле имеет уникальное имя.

Графовые базы данных.

Графовые базы данных являются базами данных NoSQL и используют структуру графов для семантических запросов. Данные хранятся в виде узлов, ребер и свойств. В графической базе данных узел представляет собой объект или экземпляр, такой как клиент, человек или автомобиль. Узел эквивалентен записи в системе реляционной базы данных. Ребро в базе данных графа представляет отношение, которое соединяет узлы, то есть определяет связи между узлами. Свойства – атрибуты, которые представляются в виде пары ключ-значение, и предназначены для хранения дополнительной информации, которая может быть ассоциирована как с узлами, так и со связями.
Язык запросов, СУБД для графовых баз, оптимизация производительности нацелены на оптимальный, в терминах скорости, способ обхода узлов по связям. Например, поиск в ширину, нахождение подграфов.

К самым популярным графовым базам данных относятся Neo4j, DEX, Azure Cosmos DB, SAP HANA. Структура базы данных графов также поддерживается некоторыми реляционными СУБД, включая Oracle и SQL Server 2017 и более поздние версии.

Базы данных NoSQL.

Базы данных NoSQL - это базы данных, которые не используют SQL в качестве основного языка доступа к данным. Графические, сетевые, объектно-ориентированные БД и базы данных документов относятся к NoSQL БД.

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

К популярным NoSQL базам данных относятся Космос БД, ArangoDB, CouchDB, Amazon DocumentDB, MongoDB, SAP HANA.


  • Сущности представляются как объекты

  • Объекты имеют свойства (атрибуты) и методы

  • Объекты хранятся в памяти

  • Механизмы наследования и полиморфизма

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

В ООБД данные можно представить в виде любой структуры, которую можно описать с помощью выбранного для разработки языка программирования. Также можно создавать произвольное сложные отношения между объектами.

Сущности представляются как объекты, которые хранятся в оперативной памяти. ООБД управляет кэш-буфером объектов, перемещая объекты между буфером и дисковым хранилищем по мере необходимости. Дополнительный интерфейсный уровень абстракции обеспечивает перехват запросов, обращающихся к тем частям базы данных, которые находятся в постоянном хранилище на диске. Изменения, вносимые в объекты, оптимальным образом переносятся из памяти на диск. [4]

Любой объект описывается состоянием и поведением. Состояние объекта – набор значений его свойств (атрибутов). Значение атрибута объекта также может являться объектом. Тогда как поведение объектов задается его методами, реализованными в программах.
Атрибуты объекта могут быть заданы элементарными значениями (числовой и строковый типы) или неэлементарными объектами, которые в свою очередь также состоят из набора свойств. То есть одни объекты могут быть рекурсивно определены через другие объекты.
Объекты, имеющие один набор атрибутов, объединяются в классы. Каждый объект может принадлежать только одному классу (не учитывая механизм наследования).
Объектные базы данных обычно используются в приложениях, которые требуют высокой производительности, сложных расчетов и быстрых результатов, а также для описания модели данных со сложной структурой. К приложениям, которые используют объектные базы данных, относятся системы реального времени, архитектура и инженерия для трехмерного моделирования, телекоммуникации и научные продукты, молекулярная наука и астрономия.
Преимущества объектно-ориентированных баз данных

Преимущества объектно-ориентированных баз данных (ООБД) неоспоримы.

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

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

В реляционных СУБД (РСУБД) размерность значений типа целых чисел составляет 11 цифр, а в используемом для разработки языке – 15. Разработчикам необходимо отслеживать подобные ситуации в РСУБД.

Недостатки объектно-ориентированных баз данных.


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

  2. Объектно-ориентированные СУБД не так популярны, как, например реляционные СУБД. Сложно найти разработчиков объектно-ориентированных БД. Следовательно разработка ООСУБД требует больших затрат.

  3. Не многие языки программирования поддерживают объектные базы данных.

  4. Большинство СУБД используют SQL в качестве стандартного языка запросов.

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

Объектно-ориентированные системы управления базами данных.
Ниже представлены популярные объектно-ориентированные баз данных и их возможности.

InterSystems Caché

InterSystems Caché - это высокопроизводительная объектная база данных. Ядро базы данных Caché - это набор сервисов, включающий хранение данных, управление параллелизмом, транзакции и управление процессами.

Caché также является полнофункциональной реляционной базой данных. Все данные в базе данных Caché доступны в виде настоящих реляционных таблиц и могут быть запрошены и изменены с использованием стандартного SQL через ODBC, JDBC или объектные методы. Caché - одна из самых быстрых, надежных и масштабируемых реляционных баз данных.

Caché предоставляет следующие возможности и функции:

ConceptBase.

ConceptBase.cc - это многопользовательская система баз данных с объектно-ориентированным подходом, который делает ее мощным инструментом для метамоделирования и разработки пользовательских языков моделирования. Система сопровождается настраиваемым графическим интерфейсом пользователя, который основан на логических возможностях сервера ConceptBase.cc.

ConceptBase.cc разработан командой ConceptBase из Университета Скёвде (HIS) и Университета Аахена (RWTH). ConceptBase.cc доступен для Linux, Windows и Mac OS-X. Существует также предварительно настроенное виртуальное устройство, которое содержит исполняемую систему, а также ее источники и инструменты для их компиляции. Система распространяется под лицензией в стиле FreeBSD.

ObjectDB Object Database.

ObjectDB - это мощная объектно-ориентированная система управления базами данных (ODBMS). ObjectDB предоставляет все стандартные сервисы управления базами данных (хранение и извлечение, транзакции, управление блокировками, обработка запросов). Но таким образом, чтобы упростить разработку и ускорить работу приложений.


(текст реферата разделен на две части, так как в данном сервисе возможно проверять процент оригинальности текста, состоящего менее чем из 10000 символов)

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

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

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

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

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

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

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

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

Подробности

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

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

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

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

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


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

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

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

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

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

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

SQLite

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

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

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

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.

Автор реляционной модели данных Э. Ф. Кода первоначально сформулировал 12 требований к БД, чтобы она могла называться реляционной. В дальнейшем этот перечень увеличился до 333 требований. Им, несмотря на широкое распространение реляционных баз данных, не удовлетворяет ни одна из известных СУБД. В 1991 г. была сформирована группа Object Database Management Group (ODMG), перед которой была… Читать ещё >

Объектно-ориентированные базы данных ( реферат , курсовая , диплом , контрольная )

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

В ней собственно база данных, интерфейс пользователя и алгоритм приложения построены с использованием объектно-ориентированного подхода.

Суть объектно-ориентированных баз данных иллюстрируется на СУБД CACHE, получившей распространение в России. В этой СУБД, чтобы получать данные из многочисленных реляционных БД, предусмотрен объектный доступ (объектно-ориентированная модель) и SQL-доступ (реляционная модель с использованием языка SQL2). Хранение данных в CACHE осуществляется с помощью многомерной модели данных, позволяющей уменьшить объем потребной памяти при одновременном увеличении скорости доступа к данным.

Недостатки реляционных баз данных

Автор реляционной модели данных Э. Ф. Кода первоначально сформулировал 12 требований к БД, чтобы она могла называться реляционной. В дальнейшем этот перечень увеличился до 333 требований. Им, несмотря на широкое распространение реляционных баз данных, не удовлетворяет ни одна из известных СУБД.

Одним из способов устранения указанных недостатков является построение объектно-ориентированной базы данных (ООБД). Ее появление стимулировано и требованиями большой быстродействующей памяти (свыше 20 Гбайт) для систем конструирования/производства (CAD/CAM).

Состояние развития ООБД

В 1991 г. была сформирована группа Object Database Management Group (ODMG), перед которой была поставлена цель построить стандарты для ООБД хотя бы на уровне стандартов для реляционных БД. В 1993 г. эта группа предложила своеобразный стандарт для ООБД, названный ODMG-3, который включал:

  • 1) объектную модель Object Data Model (ODM);
  • 2) язык определения объектов Object Definition Language (ODL);
  • 3) объектный язык запроса Object Query Language (OQL);
  • 4) интерфейсы языков программирования (C++ и других).

В настоящее время насчитывается свыше 300 объектно-ориентированных СУБД (ООСУБД), данные некоторых приведены в табл. 7.1. Сфера их применения указана в табл. 7.2.

Читайте также: