Объясните что означает понятие реляционная база данных

Объясните что означает понятие реляционная база данных

По Вашему запросу ничего не найдено.

Рекомендуем сделать следующее:

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

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

Пример реляционной базы данных

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

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

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

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

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

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

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

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

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

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

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

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

Реляционные базы данных появились в 1970-х годах. На сегодняшний день преимущества реляционного подхода сделали его самой распространенной моделью для баз данных в мире.

Целостность данных

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

Другие типы баз данных не могут одновременно поддерживать целостность больших объемов данных. Некоторые современные типы баз данных, такие как NoSQL, обеспечивают только так называемую “окончательную целостность.” Это значит, что, когда выполняется масштабирование данных или несколько пользователей одновременно используют одни и те же данные, необходимо некоторое время на “внесение изменений”. В некоторых случаях окончательная целостность вполне приемлема (например, для обновления позиций в товарном каталоге), однако для критически важной операционной деятельности бизнеса (например, транзакций с использованием корзины) реляционные базы представляют собой фундаментальный стандарт.

Фиксация изменений и атомарность

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

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

Транзакции в реляционной базе данных имеют четыре важные характеристики: неразрывность (atomicity), целостность (consistency), изолированность (isolation) и неизменность (durability). Это сочетание получило название ACID.

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

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

Блокировки базы данных и параллельный доступ

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

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

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

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

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

При выборе типа базы данных и продуктов на основе реляционных баз данных необходимо учитывать несколько факторов. Выбор СУРБД зависит от потребностей Вашей компании. Задайте себе следующие вопросы.

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

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

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

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

Источник

Объясните что означает понятие реляционная база данных

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

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

Установление связи между таблицами

Давайте используем пример адресной книги для того, чтобы обсудить базу данных, которую можно реально использовать в деловой жизни. Предположим, что индивидуумы первой таблицы являются пациентами больницы. Дополнительную информацию о них можно хранить в другой таблице. Столбцы второй таблицы могут быть поименованы таким образом: Patient (Пациент), Doctor (Врач), Insurer (Страховка), Balance (Баланс).

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

Предположим, Dr.Halben желает получить номера телефонов всех своих Пациентов. Для того чтобы извлечь эту информацию, он должен связать таблицу с номерами телефонов пациентов (адресную книгу) с таблицей, определяющей его пациентов. В данном простом примере он может мысленно проделать эту операцию и узнать телефонные номера своих пациентов Grillet и Brock, в действительности же эти таблицы вполне могут быть больше и намного сложнее.

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

Порядок строк произволен

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

Рассмотрим вторую таблицу. Содержащуюся в ней информацию иногда удобно рассматривать упорядоченной по имени, иногда — в порядке возрастания или убывания баланса (Balance), а иногда — сгруппированной по доктору. Внушительное множество возможных порядков строк помешало бы пользователю проявить гибкость в работе с данными, поэтому строки предполагаются неупорядоченными. Именно по этой причине вы не можете просто сказать: «Меня интересует пятая строка таблицы». Независимо от порядка включения данных или какого-либо другого критерия, этой пятой строки не существует по определению. Итак, строки таблицы предполагаются расположенными в произвольном порядке.

Идентификация строк (первичный ключ)

По этой и ряду других причин, необходимо иметь столбец таблицы, который однозначно идентифицирует каждую строку. Обычно этот столбец содержит номер, например, приписанный каждому пациенту. Конечно, можно использовать для идентификации строк имя пациента, но ведь может случиться так, что имеется несколько пациентов с именем Mary Smith. В подобном случае нет простого способа их различить. Именно по этой причине обычно используются номера. Такой уникальный столбец (или их группа), используемый для идентификации каждой строки и обеспечивающий различимость всех строк, называется первичным ключом таблицы (primary key of the table).

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

Столбцы поименованы и пронумерованы

В отличие от строк, столбцы таблицы (также называемые полями (fields) упорядочены и поименованы. Следовательно, в нашей таблице, соответствующей адресной книге, можно сослаться на столбец «Address» как на «столбец номер три». Естественно, это означает, что каждый столбец данной таблицы должен иметь имя, отличное от других имен, для того, чтобы не возникло путаницы. Лучше всего, когда имена определяют содержимое поля. В этой книге мы будем использовать аббревиатуру для именования столбцов в простых таблицах, например: cname — для имени покупателя (customer name), odate — для даты поступления (order date). Предположим также, что таблица содержит единственный цифровой столбец, используемый как первичный ключ.

Пример базы данных

Таблицы 1.1, 1. 2, 1.3 образуют реляционную базу данных, которая достаточно мала для того, чтобы можно было понять ее смысл, но и достаточно сложна для того, чтобы иллюстрировать на ее примере важные понятия и практические выводы, связанные с применением SQL.

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

Например, поле snum в таблице Customers определяет, каким продавцом (salespeople) обслуживается конкретный покупатель (customer). Номер поля snum устанавливает связь с таблицей Salespeople, которая дает информацию об этом продавце (salespeople). Очевидно, что продавец, который обслуживает данного покупателя, существует, т.е. значение поля snum в таблице Customers присутствует также и в таблице Salespeople. В этом случае мы говорим, что система находится в состоянии ссылочной целостности (referential integrity).

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

Перед вами объяснение столбцов таблицы 1.1:

Таблица 1.2 содержит следующие столбцы:

И, наконец, столбцы таблицы 1.3:

Источник: SQL для простых смертных / Мартинн Грабер

Источник

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

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

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 основан на реляционной модели данных, в которой данные организованы в виде коллекции таблиц.

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

Источник