что такое реляционные системы

Краткий обзор реляционных систем управления базами данных

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

Данная статья анализирует различия между наиболее популярными реляционными системами управления базами данных (СУБД): SQLite, MySQL и PostgreSQL.

Системы управления базами данных

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

Примечание: Чтобы узнать больше о СУБД, читайте статью SQL, NoSQL и другие модели баз данных.

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

Реляционные СУБД для работы с данными используют реляционную модель. Эта модель хранит любую информацию в таблицах в виде связанных записей с атрибутами.

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

Отношения и типы данных

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

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

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

Примечание: Базы данных NoSQL не имеют таких строгих ограничений, поскольку они не выстраивают таких отношений между данными. Чтобы узнать больше о NoSQL, читайте эту статью.

Популярные реляционные базы данных

В данной статье мы рассмотрим три наиболее важные и популярные СУБД с открытым исходным кодом.

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

SQLite

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

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

Типы данных SQLite

Примечание: Больше о типах данных SQLite можно узнать в официальной документации.

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

Недостатки SQLite

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

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

MySQL

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

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

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

Типы данных MySQL

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

Недостатки MySQL

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

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

PostgreSQL

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

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

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

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

Источник

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

Реляционная СУБД (РСУБД; иначе Система управления реляционными базами данных, СУРБД) — СУБД, управляющая реляционными базами данных.

Понятие реляционный (англ. relation — отношение) связано с разработками известного английского специалиста в области систем баз данных Эдгара Кодда (Edgar Codd).

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

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

Базовыми понятиями реляционных СУБД являются:

См. также

Литература

Полезное

Смотреть что такое «Реляционная СУБД» в других словарях:

реляционная СУБД, разработанная фирмой MicroRim для IBM PC-совместимых ПЭВМ — — [Е.С.Алексеев, А.А.Мячев. Англо русский толковый словарь по системотехнике ЭВМ. Москва 1993] Тематики информационные технологии в целом EN R:base … Справочник технического переводчика

Объектно-реляционная СУБД — Эта статья должна быть полностью переписана. На странице обсуждения могут быть пояснения. Объектно реляционная СУБД (ОРСУБД) реляционная СУБД (РСУБД), поддерживающая неко … Википедия

Реляционная модель данных — (РМД) логическая модель данных, прикладная теория построения баз данных, которая является приложением к задачам обработки данных таких разделов математики как теории множеств и логика первого порядка. На реляционной модели данных строятся… … Википедия

Реляционная алгебра — Реляционная алгебра замкнутая система операций над отношениями в реляционной модели данных. Операции реляционной алгебры также называют реляционными операциями. Первоначальный набор из 8 операций был предложен Э. Коддом в 1970 е годы и… … Википедия

Реляционная база данных — Реляционная база данных база данных, основанная на реляционной модели данных. Слово «реляционный» происходит от англ. relation (отношение[1]). Для работы с реляционными БД применяют реляционные СУБД. Использование реляционных баз… … Википедия

реляционная база данных — База данных, реализованная в соответствии с реляционной моделью данных. [ГОСТ 20886 85] реляционная БД База данных, логически организованная в виде набора отношений ее компонентов. Характерной особенностью реляционной базы данных является… … Справочник технического переводчика

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

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

Реляционные СУБД — Реляционная СУБД (РСУБД; иначе Система управления реляционными базами данных, СУРБД) СУБД, управляющая реляционными базами данных. Понятие реляционный (англ. relation отношение) связано с разработками известного английского специалиста в… … Википедия

Источник

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

Каталог СУБД-решений и проектов доступен на TAdviser.

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

Реляционные базы данных занимают сейчас доминирующее положение. Иерархическая и сетевая структуры баз данных ушли в прошлое, уступив свое место реляционным базам, под которые постороено большинство современных СУБД (MS SQL Server, MS Access, InterBase, FoxPro, PostgreSQL, Paradox и другие).

Подробности

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

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

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

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

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

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

Источник

Какую СУБД выбрать и почему? (Статья 1)

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

Нужно обязательно сделать ремарку, что некоторые крупные производители, имеют в своем арсенале несколько типов СУБД, как в виде отдельных продуктов, так и в виде внутренней реализации. Например, у Oracle на самом деле чего только нет, начиная с классической реляционной СУБД, продолжая с отдельным продуктом Oracle NoSQL Database, который может использоваться и как документная, и как колоночная, и как ключ-значение. Отдельное решение от того же Oracle, Autonomous Data Warehouse – это уже специализированное решение для хранилищ данных. Еще один отдельный продукт от Oracle – Oracle Graph Server для работы с графами, и еще много другого. Этому можно посвятить отдельную серию статей.

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

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

Когда выбирать реляционную СУБД

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

Когда не выбирать реляционную СУБД

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

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

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

СУБД типа ключ-значение

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

Когда выбирать СУБД ключ-значение

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

Когда не выбирать СУБД ключ-значение

Если вы предполагаете хранить в базе данных много сущностей (таблиц), а у сущностей будут сложные структуры с разными типами данных. Так же, если вы предполагаете делать из этой таблицы сложные запросы которые возвращают множества строк.

Документные СУБД

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

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

Интересно, что документные СУБД развиваются достаточно активно, и сейчас некоторые из них, в том числе, поддерживают проверку схемы.

Известными представителями таких СУБД являются CouchDB, MongoDB, Amazon DocumentDB.

Когда выбирать документную СУБД

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

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

Когда не выбирать документную СУБД

Не самое лучшее решение для реализации транзакционная модели, и точно не лучший вариант для формирования отчетности.

Графовые СУБД

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

Когда выбирать графовые СУБД

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

Когда не выбирать графовые СУБД

Практически во всех остальных случаях, кроме указанных выше, лучше воздержаться от использования графовых СУБД.

Колоночные СУБД

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

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

Когда выбирать колоночные СУБД

Когда не выбирать колоночные СУБД

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

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

Итоги

Важное замечание – не пытайтесь сразу все задачи решить в рамках одной СУБД. Это более чем нормально иметь несколько разных типов СУБД. Так же, не пытайтесь сразу определиться с производителем СУБД, или связать свою жизнь с одним конкретным брендом.

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

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

Итак, в таблице представленной ниже, кратко собрано то, что описано выше в статье.

Тип СУБД

Когда выбирать

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

Нужна транзакционность; высокая нормализация; большая доля операций на вставку

Oracle, MySQL, Microsoft SQL Server, PostgreSQL

Задачи кэширования и брокеры сообщений

Для хранения объектов в одной сущности, но с разной структурой; хранение структур на основе JSON

CouchDB, MongoDB, Amazon DocumentDB

Задачи подобные социальным сетям; системы оценок и рекомендаций

Neo4j, Amazon Neptune, InfiniteGraph, InfoGrid

Хранилища данных; выборки со сложными аналитическими вычислениями; количество строк в таблице превышает сотни миллионов

Vertica, ClickHouse, Google BigTable, Sybase \ SAP IQ, InfoBright, Cassandra

Надеюсь данная статья оказалась полезной.

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

Источник

Реляционные базы данных: объяснение понятий, вводный обзор

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

SQL представляет собой язык для работы с реляционными базами данных и ос­нован на реляционной модели данных. Что это такое? В каком виде информация хранится в реляционной базе данных? Чем реляционные базы данных отличаются от более ранних баз данных, таких как иерархические и сетевые? Какими пре­имуществами и недостатками обладает реляционная модель? В данной статье опи­сана реляционная модель данных, поддерживаемая языком SQL, и приведено ее сравнение с более ранними стратегиями организации баз данных.

Ранние модели данных

Когда в 1970-80-х годах стали популярны базы данных, появилось множество различных моделей данных. Каждая из них имела свои преимущества и недостат­ки, которые сыграли ключевую роль в развитии реляционной модели данных, появившейся во многом благодаря стремлению упростить и упорядочить ранние модели данных. Чтобы понять роль SQL и реляционных баз данных и оценить их вклад в развитие СУБД, следует кратко изучить ряд моделей данных, предшество­вавших появлению SQL.

Системы управления файлами

До появления СУБД все данные, которые содержались в компьютерной системе постоянно, хранились в виде отдельных файлов. Система управления файлами, ко­торая обычно являлась частью операционной системы, следила за именами фай­лов и их размещением. Системы управления файлами широко используются и се­годня — вероятно, вы знакомы со структурой папок и файлов, предоставляемой файловыми системами операционных систем Microsoft Windows или Macintosh компании Apple. Аналогичные файловые системы используются и в UNIX- серверах и всех коммерческих вычислительных системах.

В системах управления файлами модели данных, как правило, отсутствуют; эти системы ничего не знают о внутреннем содержимом файлов. В лучшем случае фай­ловая система поддерживает информацию о «типе файла» наряду с его именем, по­зволяя отличить документ текстового редактора от файла, содержащего данные о начисленной зарплате. Знание о содержимом файла — какие данные в нем хранятся и как они организованы — удел прикладных программ, использующих этот файл, как показано на рис. 1. В этом приложении начисления зарплаты каждая из про­грамм на языке программирования COBOL, работающая с основным файлом с ин­формацией о сотрудниках, содержит описание файла (file description, FD), в котором указана схема размещения данных в файле. Если структура данных изменяется — например, при решении хранить некоторую дополнительную информацию о каж­дом сотруднике— должны быть соответствующим образом модифицированы все программы, работающие с данным файлом. Это не слишком большая проблема в случае файла с документом текстового редактора или электронных таблиц, кото­рые обычно обрабатываются одной программой. Но при корпоративной работе с данными файлы зачастую совместно используются десятками, а то и сотнями про­грамм (см. рис. 1). При увеличении количества файлов и программ отделу обра­ботки данных придется тратить больше усилий на поддержание работоспособности старых программ, чем на разработку новых.

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

Рис. 1. Приложение для начисления зарплаты, исполь­зующее систему управления файлами

Иерархические базы данных

Одной из наиболее важных сфер применения первых СУБД было планирова­ние производства для компаний, занимающихся выпуском продукции. Например, если автомобильная компания хотела выпустить 10000 машин одной модели и 5000 машин другой модели, ей необходимо было знать, сколько деталей следует заказать у своих поставщиков. Чтобы ответить на этот вопрос, необходимо выяс­нить, из каких частей состоит изделие, затем определить, из каких деталей состоят эти части, и т.д. Например, машина состоит из двигателя, корпуса и ходовой час­ти; двигатель состоит из клапанов, цилиндров, свечей и т.д. Для обработки таких списков частей идеально подходят компьютеры.

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

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

Рис. 2. Иерархическая база данных, содержащая информацию о составных частях

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

Одной из наиболее популярных иерархических СУБД была Information Management System (IMS) компании IBM, появившаяся в 1968 году. Ниже пере­числены преимущества IMS и реализованной в ней иерархической модели.

СУБД IMS все еще остается одной из распространенных СУБД для мэйнфрей­мов компании IBM. Обладающая очень высокой производительностью, она иде­ально подходит для приложений, связанных с обработкой большого числа тран­закций, таких как транзакции с кредитными карточками или резервирование авиабилетов. Хотя за последние пару десятилетий производительность реляцион­ных баз данных возросла столь существенно, что описанное преимущество IMS стало не столь важным, большое количество корпоративных данных, хранящихся в базах данных IMS, и множество старых приложений, работающих с этими дан­ными, гарантируют, что СУБД IMS будет использоваться еще много лет.

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

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

Рис. 3. Множественные отношения “предок-потомок”

В связи с этим для таких приложений, как обработка заказов, была разработана новая, сетевая, модель данных. Она расширила иерархическую модель, позволяя одной записи участвовать в нескольких отношениях «предок-потомок», именуе­мых множествами (set) (рис. 4). В 1971 году на конференции по языкам обработки данных (Conference on Data Systems Languages, CODASYL) был опубликован офи­циальный стандарт сетевых баз данных, который известен как модель CODASYL. Компания IBM не стала разрабатывать собственную сетевую СУБД, но в 1970-х го­дах независимые производители программного обеспечения реализовали сетевую модель в таких продуктах, как IDMS компании Cullinet, Total компании Cincom и СУБД Adabas, которые приобрели большую популярность. Однако IBM усовер­шенствовала IMS, обеспечив путь обхода правила единственного предка в класси­ческих иерархических структурах, в котором дополнительные предки рассматри­ваются как логические. Эта модель данных, ставшая известной как расширенная иерархическая модель, сделала базу данных IMS конкурентом сетевых СУБД.

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

Рис. 4. Сетевая (CODASYL) база данных для работы с заказами

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

Сетевые базы данных обладали рядом преимуществ.

Конечно, у сетевых баз данных имелись недостатки. Подобно своим иерархиче­ским предкам, сетевые базы данных были очень «жесткими». Наборы отношений и структура записей должны были быть заданы наперед. Изменение структуры ба­зы данных обычно означало полную перестройку последней.

И иерархическая, и сетевая база данных были инструментами программистов. Чтобы получить ответ на вопрос какой товар наиболее часто заказывает компания X? или сколько всего заказано единиц товара Y?, программисту приходилось пи­сать программу для навигации по базе данных, выборки нужных записей и под­счета результата. Реализация пользовательских запросов часто затягивалась на не­дели и месяцы, и к моменту появления программы возвращаемая ею информация часто оказывалась бесполезной.

Недостатки иерархической и сетевой моделей привели к повышенному инте­ресу к новой реляционной модели данных, впервые описанной доктором Коддом в 1970 году. Поначалу она представляла лишь академический интерес. Сетевые ба­зы данных продолжали оставаться важной технологией на протяжении 1970-х и в начале 1980-х годов, особенно в мини-компьютерных системах, переживавших пик популярности. Однако в середине 1980-х годов начался взлет реляционной моде­ли. В начале 1990-х годов сетевые базы данных утратили популярность и сегодня не играют значительной роли на рынке баз данных.

Реляционная модель данных

Реляционная модель данных, предложенная Коддом, была попыткой упростить структуру базы данных. В ней отсутствовала явная структура «предок-потомок», а все данные были представлены в виде простых таблиц, разбитых на строки и столбцы. На рис. 5 показана реляционная версия рассмотренной выше сетевой базы данных, содержащей информацию о заказах (рис. 4).

Рис. 5. Реляционная база данных для работы с заказами

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

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

Приведенное определение не оставляет места пользовательским структурам, та­ким как встроенные указатели иерархических и сетевых СУБД. Реляционная СУБД способна реализовать отношения «предок-потомок», однако эти отношения пред­ставлены исключительно значениями, содержащимися в таблицах базы данных.

Учебная база данных

На рис. 6 показана маленькая реляционная база данных для приложения, вы­полняющего обработку заказов. Большинство примеров в данном блоге построено на ее основе. Полное описание структуры и содержимого учебной базы данных, изображенной на рис. 6, приведено в приложении А, «Учебная база данных». Здесь представлено только по нескольку строк каждой таблицы.

Рис. 6. Учебная база данных (представлена частично)

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

Таблицы

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

Рис. 7. Структура реляционной таблицы

Каждый вертикальный столбец таблицы OFFICES представляет один элемент данных для каждого из офисов. Например, в столбце CITY содержатся названия городов, в которых расположены офисы. В столбце SALES содержатся объемы продаж, обеспечиваемые офисами. В столбце MGR содержатся идентификаторы управляющих офисами.

Все значения, содержащиеся в одном и том же столбце, являются данными од­ного типа. Например, в столбце CITY содержатся только слова, в столбце SALES — денежные суммы, а в столбце MGR — целые числа, представляющие идентификаторы служащих. Множество значений, которые могут содержаться в столбце, на­зывается доменом этого столбца. Доменом столбца CITY является множество всех названий городов. Домен столбца SALES — это любая денежная сумма. Домен столбца region состоит всего из двух значений, «Eastern» и «Western», поскольку у компании всего два торговых региона.

У каждого столбца в таблице есть свое имя, которое обычно служит заголовком столбца. Все столбцы в одной таблице должны иметь уникальные имена, однако разрешается присваивать одинаковые имена столбцам, расположенным в различ­ных таблицах. На практике такие имена столбцов, как NAME (имя), ADDRESS (адрес), PRICE (цена) и тому подобные, часто встречаются в различных таблицах одной базы данных.

Столбцы таблицы упорядочены слева направо, и их порядок определяется при создании таблицы. В любой таблице всегда есть как минимум один столбец. В стандарте ANSI/ISO максимально допустимое число столбцов в таблице не ука­зывается; однако почти во всех коммерческих СУБД такой предел существует, но он редко бывает меньше 255 столбцов.

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

В таблице может содержаться любое количество строк. По очевидным причи­нам допускается существование таблицы с нулевым количеством строк. Такая таб­лица называется пустой. Пустая таблица сохраняет структуру, определенную ее столбцами, просто в ней не содержатся данные. Стандарт ANSI/ISO не наклады­вает ограничений на количество строк в таблице, и во многих СУБД размер таб­лиц ограничен лишь свободным дисковым пространством компьютера. В других СУБД имеется максимальный предел, однако обычно он весьма высок, — два мил­лиарда строк, а то и больше.

Первичные ключи

Поскольку строки в реляционной таблице не упорядочены, нельзя выбрать строку по ее номеру в таблице. В таблице нет «первой», «последней» или «тринадцатой» строки. Тогда каким же образом можно выбрать в таблице кон­кретную строку, например строку для офиса, расположенного в Денвере?

Рис. 8. Таблица с составным первичным ключом

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

Хотя первичные ключи являются важной частью реляционной модели данных, в первых реляционных СУБД (System/R, DB2, Oracle и других) явная их поддерж­ка обеспечена не была. Как правило, проектировщики базы данных сами следили за тем, чтобы у всех таблиц были первичные ключи; в самих СУБД не было воз­можности задать для таблицы первичный ключ. И только СУБД DB2 Version 2, появившаяся в апреле 1988 года, была первым коммерческим SQL-продуктом с поддержкой первичных ключей. После этого подобная поддержка была добав­лена в стандарт ANSI/ISO, и сегодня практически все СУРБД предоставляют та­кую возможность.

Взаимоотношения

Одним из отличий реляционной модели от ранних моделей представления данных было то, что в ней отсутствовали явные указатели, такие как использовав­шиеся для реализации отношений «предок-потомок» в иерархической модели данных. Однако вполне очевидно, что такие отношения существуют и в реляци­онных базах данных. Например, в нашей учебной базе данных каждый из служа­щих закреплен за конкретным офисом, поэтому ясно, что между строками табли­цы OFFICES и таблицы SALES REPS существует отношение. Не приводит ли отсут­ствие явных указателей в реляционной модели к потере информации?

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

Рис. 9. Отношение “предок-потомок” в реляционной базе данных

Внешние ключи

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

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

Рис. 10. Множественные отношения “предок-потомок” в реляционной базе данных

Внешние ключи являются фундаментальной частью реляционной модели, по­скольку реализуют отношения между таблицами базы данных. К сожалению, как и в случае с первичными ключами, поддержка внешних ключей отсутствовала в первых реляционных СУБД. Она была реализована в DB2 Version 2, а затем добавлена в стандарт ANSI/ISO и теперь имеется во всех основных коммерческих СУБД.

Двенадцать правил Кодда для реляционных баз данных

Когда в средине 1980-х годов реляционная модель стала очень популярной, почти все производители СУБД стали добавлять слово «реляционный» в описание своих продуктов. Но ряд из них был не более чем тонким слоем SQL-подобного языка на поверхности сетевой или иерархической базы данных. Некоторые реали­зовывали только рудиментарную табличную структуру, даже не пытаясь реализо­вать язык запросов. Вскоре вопрос так что же такое настоящая реляционная ба­за данных? стал подниматься все чаще и чаще, а производители СУБД стали ут­верждать, что их продукты «реляционнее», чем продукты их конкурентов.

В 1985 году Тед Кодл (чья статья 15-летней давности определила реляционную модель данных) задался этим вопросом и ответил на него в журнале Compu­terworld (Is Your DBMS Really Relational? (Действительно ли ваша СУБД реляционная?, 14.10.1985) и Does Your DBMS Run By the Rules? (Работает ли ваша СУБД по правилам?, 21.10.1985)). Здесь он изложил двенадцать правил, которым должна соответствовать настоящая реляционная база данных.

Хотя дискуссии по этому вопросу давно завершились, эти 12 правил интересны, как минимум, с исторической точки зрения, поскольку они раз и навсегда разрешили все вопросы и представляют собой хорошее неформальное определение реляционной базы данных. Правило 1 напоминает неформальное определение реляционной базы данных, приведенное ранее; остальные правила уточняют и дополняют его.

Правило 2 указывает на роль первичных ключей при поиске информации в ба­зе данных. Имя таблицы позволяет найти требуемую таблицу, имя столбца — тре­буемый столбец, а первичный ключ — строку, содержащую искомый элемент данных. Правило 3 требует, чтобы отсутствующие данные можно было предста­вить с помощью значения NULL.

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

Правило 5 требует, чтобы СУБД использовала язык реляционной базы данных, например SQL, хотя явно SQL в правиле не упомянут. Такой язык должен под­держивать все основные функции СУБД, а не только выборку данных.

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

Правило 7 акцентирует внимание на том, что реляционные базы данных по своей природе ориентированы на работу с множествами. Оно требует, чтобы опе­рации добавления, удаления и обновления можно было выполнять над множест­вами строк. Это правило предназначено для того, чтобы запретить реализации та­ких СУБД, в которых поддерживаются только операции над одной строкой.

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

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

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

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

Заключение

SQL основан на реляционной модели данных, в которой данные организованы в виде коллекции таблиц.

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

Источник