Основа реляционной бд. Манипулирование реляционными данными

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

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

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

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

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

Данные создают проблемы

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

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

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

Мощные связи

Эдгар Кодд, сотрудник исследовательской лаборатории корпорации IBM в Сан-Хосе, по существу, создал и описал концепцию реляционных баз данных в своей основополагающей работе «Реляционная модель для крупных, совместно используемых банков данных» (A Relational Model of Data for Large Shared Data Banks. Communications of the ACM, июнь 1970).

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

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

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

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

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

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

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

Для работы с огромным количеством активно используемых баз данных применяются программные системы управления реляционными базами данных, созданные такими авторитетными производителями, как Oracle, Sybase, IBM, Informix и Microsoft.

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

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

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

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

Фундаментальные модели

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

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

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

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

Процесс моделирования и составления основных элементов

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

Моделирование таблиц и проектирование реляционных баз данных производится посредством бесплатных инструментов, таких как Workbench, PhpMyAdmin, Case Studio, dbForge Studio. После детальной проектировки следует сохранить графически готовую реляционную модель и перевести ее в готовый SQL-код. На этом этапе можно начинать работу с сортировкой данных, их обработку и систематизацию.

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

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

реляционная табличка = сущность;
макет = атрибуты = наименование полей = заголовок столбцов сущности;
экземпляр сущности = кортеж = запись = строка таблички;
значение атрибута = ячейка сущности= поле.

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

Сущность. Таблица реляционной базы данных может быть одна, а может быть целый набор из таблиц, которые характеризируют описанные объекты благодаря хранящимся в них данным. У них фиксированное количество полей и переменное число записей. Таблица реляционной модели баз данных составляется из строк, атрибутов и макета.
Запись - переменное число строк, отображающих данные, что характеризируют описываемый объект. Нумерация записей производится системой автоматически.
Атрибуты - данные, демонстрирующие собой описание столбцов сущности.
Поле. Представляет собой столбец сущности. Их количество - фиксированная величина, устанавливаемая во время создания или изменения таблицы.

Теперь, зная составляющие элементы таблицы, можно переходить к свойствам реляционной модели database:

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

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

Основные характеристики полей реляционных БД

Названия полей должны быть уникальными в рамках одной сущности. Типы атрибутов или полей реляционных баз данных описывают, данные какой категории хранятся в полях сущностей. Поле реляционной базы данных должно иметь фиксированный размер, исчисляемый в символах. Параметры и формат значений атрибутов определяют манеру исправления в них данных. Еще есть такое понятие, как "маска", или "шаблон ввода". Оно предназначено для определения конфигурации ввода данных в значение атрибута. Непременно при записи неправильного в поле должно выдаваться извещение об ошибке. Также на элементы полей накладываются некоторые ограничения - условия проверки точности и безошибочности ввода данных. Существует некоторое обязательное значение атрибута, которое однозначно должно быть заполнено данными. Некоторые строки атрибутов могут быть заполнены NULL-значениями. Разрешается ввод пустых данных в атрибуты полей. Как и извещение об ошибке, есть значения, которые заполняются системой автоматически - это данные по умолчанию. Для ускорения поиска любых данных предназначено индексированное поле.

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

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

Базовые правила нормализации реляционной сущности

1. Значение названия поля для реляционной таблицы должно быть уникальным, единственным в своем роде (первая нормальная форма - 1НФ).

2. Для таблицы, которая уже приведена к 1НФ, наименование любого неидентифицирующего столбца должно быть зависимым от уникального идентификатора таблицы (2НФ).

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

Базы данных: реляционные связи между таблицами

Существует 2 основных реляционных табличек:

«Один-многие». Возникает при соответствии одной ключевой записи таблицы №1 нескольким экземплярам второй сущности. Значок ключа на одном из концов проведенной линии говорит о том, что сущность находится на стороне «один», второй конец линии зачастую отмечают символом бесконечности.

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

Существование ключей в реляционной базе данных

Первичный и вторичный ключи определяют потенциальные отношения базы данных. Реляционные связи модели данных могут иметь только один потенциальный ключ, это и будет primary key. Что же он собой представляет? Первичный ключ - это столбец сущности или набор атрибутов, благодаря которому можно получить доступ к данным конкретной строки. Он должен быть уникальным, единственным, а его поля не могут содержать пустых значений. Если первичный ключ состоит всего из одного атрибута, тогда он называется простым, в ином случае будет составляющим.

Кроме первичного ключа, существует и внешний (foreign key). Многие не понимают, какая между ними разница. Разберем их более детально на примере. Итак, существует 2 таблицы: «Деканат» и «Студенты». Сущность «Деканат» содержит поля: «ID студента», «ФИО» и «Группа». Таблица «Студенты» имеет такие значения атрибутов, как «ФИО», «Группа» и «Средний бал». Так как ID студента не может быть одинаковым для нескольких студентов, это поле и будет первичным ключом. «ФИО» и «Группа» из таблицы «Студенты» могут быть одинаковыми для нескольких человек, они ссылаются на ID номер студента из сущности «Деканат», поэтому могут быть использованы в качестве внешнего ключа.

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

Для наглядности приведем простой пример реляционной модели базы данных, состоящей из двух сущностей. Существует таблица с названием «Деканат».

Необходимо провести связи, чтобы получилась полноценная реляционная база данных. Запись "ИН-41", как и "ИН-72", может присутствовать не единожды в табличке "Деканат", также фамилия, имя и отчество студентов в редких случаях могут совпадать, поэтому данные поля никак нельзя сделать первичным ключом. Покажем сущность «Студенты».

Как мы видим, типы полей реляционных баз данных совершенно различаются. Присутствуют как цифровые записи, так и символьные. Поэтому в настройках атрибутов следует указывать значения integer, char, vachar, date и другие. В таблице "Деканат" уникальным значением является только ID студента. Данное поле можно взять за первичный ключ. ФИО, группа и телефон из сущности "Студенты" могут быть взяты как внешний ключ, ссылающийся на ID студента. Связь установлена. Это пример модели со связью «один к одному». Гипотетически одна из таблиц лишняя, их можно легко объединить в одну сущность. Чтобы ID-номера студентов не стали всеобще известными, вполне реально существование двух таблиц.

Перевод

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

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

Если это правда, значит ли это, что могучие реляционные БД стали уязвимы? Значит ли это, что дни реляционных БД проходят и скоро совсем пройдут? В этой статье мы рассмотрим популярное течение нереляционных баз данных применительно к различным ситуациям и посмотрим, повлияет ли это на будущее реляционных БД.

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

Начнем с основ

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

Доступ к реляционным базам данных осуществляется через реляционные системы управления базами данных (РСУБД). Почти все системы баз данных, которые мы используем, являются реляционными, такие как Oracle, SQL Server, MySQL, Sybase, DB2, TeraData и так далее.

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

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

Проблемы реляционных БД

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

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

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

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

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

Новая волна

Такой тип баз данных принято называть хранилище типа ключ-значение (key-value store). Фактически, никакого официального названия не существует, поэтому вы можете встретить его в контексте документо-ориентированных, атрибутно-ориентированных, распределенных баз данных (хотя они также могут быть реляционными), шардированных упорядоченных массивов (sharded sorted arrays), распределенных хэш-таблиц и хранилищ типа ключ-значения. И хотя каждое из этих названий указывает на конкретные особенности системы, все они являются вариациями на тему, которую мы будем назвать хранилище типа ключ-значение.

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

Характеристики хранилищ

Реляционная БД	Хранилище типа ключ-значение
База данных состоит из таблиц, таблицы содержат колонки и строки, а строки состоят из значений колонок. Все строки одной таблицы имеют единую структуру.	Для доменов можно провести аналогию с таблицами, однако в отличие от таблиц для доменов не определяется структура данных. Домен – это такая коробка, в которую вы можете складывать все что угодно. Записи внутри одного домена могут иметь разную структуру.
Модель данных 1 определена заранее. Является строго типизированной, содержит ограничения и отношения для обеспечения целостности данных.	Записи идентифицируются по ключу, при этом каждая запись имеет динамический набор атрибутов, связанных с ней.
Модель данных основана на естественном представлении содержащихся данных, а не на функциональности приложения.	В некоторых реализация атрибуты могут быть только строковыми. В других реализациях атрибуты имеют простые типы данных, которые отражают типы, использующиеся в программировании: целые числа, массива строк и списки.
Модель данных подвергается нормализации, чтобы избежать дублирования данных. Нормализация порождает отношения между таблицами. Отношения связывают данные разных таблиц.	Между доменами, также как и внутри одного домена, отношения явно не определены.

Никаких join’ов

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

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

Доступ к данным

Реляционная БД	Хранилище типа ключ-значение
Данные создаются, обновляются, удаляются и запрашиваются с использованием языка структурированных запросов (SQL).	Данные создаются, обновляются, удаляются и запрашиваются с использованием вызова API методов.
SQL-запросы могут извлекать данные как из одиночной таблица, так и из нескольких таблиц, используя при этом соединения (join’ы).	Некоторые реализации предоставляют SQL-подобный синтаксис для задания условий фильтрации.
SQL-запросы могут включать агрегации и сложные фильтры.	Зачастую можно использовать только базовые операторы сравнений (=, !=, <, >, <= и =>).
Реляционная БД обычно содержит встроенную логику, такую как триггеры, хранимые процедуры и функции.	Вся бизнес-логика и логика для поддержки целостности данных содержится в коде приложений.

Взаимодействие с приложениями

Хранилища типа ключ-значение: преимущества

Есть два четких преимущества таких систем перед реляционными хранилищами.

Подходят для облачных сервисов

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

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

Более естественная интеграция с кодом

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

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

Хранилища типа ключ-значение: недостатки

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

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

И не забудьте о совместимости. В отличие от реляционных БД, хранилища, ориентированные на использование в «облаке», имеют гораздо меньше общих стандартов. Хоть концептуально они и не отличаются, они все имеют разные API, интерфейсы запросов и свою специфику. Поэтому вам лучше доверять вашему вендору, потому что в случае чего, вы не сможете легко переключиться на другого поставщика услуг. А учитывая тот факт, что почти все современные хранилища типа ключ-значение находятся в стадии бета-версий 2 , доверять становится еще рискованнее, чем в случае использования реляционных БД.

Ограниченная аналитика данных

Обычно все облачные хранилища строятся по типу множественной аренды , что означает, что одну и ту же систему использует большое количество пользователей и приложений. Чтобы предотвратить «захват» общей системы, вендоры обычно каким-то образом ограничивают выполнение запросов. Например, в SimpleDB запрос не может выполняться дольше 5 секунд. В Google AppEngine Datastore за один запрос нельзя получить больше, чем 1000 записей 3 .

Эти ограничения не страшны для простой логики (создание, обновление, удаление и извлечение небольшого количества записей). Но что если ваше приложение становится популярным? Вы получили много новых пользователей и много новых данных, и теперь хотите сделать новые возможности для пользователей или каким-то образом извлечь выгоду из данных. Тут вы можете жестко обломаться с выполнением даже простых запросов для анализа данных. Фичи наподобие отслеживания шаблонов использования приложения или системы рекомендаций, основанной на истории пользователя, в лучшем случае могут оказаться сложны в реализации. А в худшем - просто невозможны.

В таком случае для аналитики лучше сделать отдельную базу данных, которая будет заполняться данными из вашего хранилища типа ключ-значение. Продумайте заранее, каким образом это можно будет сделать. Будете ли вы размещать сервер в облаке или у себя? Не будет ли проблем из-за задержек сигнала между вами и вашим провайдером? Поддерживает ли ваше хранилище такой перенос данных? Если у вас 100 миллионов записей, а за один раз вы можете взять 1000 записей, сколько потребуется на перенос всех данных?

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

Облачные хранилища

Множество поставщиков веб-сервисов предлагают многопользовательские хранилища типа ключ-значение. Большинство из них удовлетворяют критериям, перечисленным выше, однако каждое обладает своими отличительными фичами и отличается от стандартов, описанных выше. Давайте взглянем на конкретные пример хранилищ, такие как SimpleDB, Google AppEngine Datastore и SQL Data Services.

Amazon: SimpleDB

SimpleDB - это атрибутно-ориентированное хранилище типа ключ-значение, входящее в состав Amazon WebServices. SimpleDB находится в стадии бета-версии; пользователи могут пользовать ей бесплатно - до тех пор пока их потребности не превысят определенный предел.

У SimpleDB есть несколько ограничений. Первое - время выполнения запроса ограничено 5-ю секундами. Второе - нет никаких типов данных, кроме строк. Все хранится, извлекается и сравнивается как строка, поэтому для того, чтобы сравнить даты, вам нужно будет преобразовать их в формат ISO8601. Третье - максимальные размер любой строки составляет 1024 байта, что ограничивает размер текста (например, описание товара), который вы можете хранить в качестве атрибута. Однако поскольку структура данных гибкая, вы можете обойти это ограничения, добавляя атрибуты «ОписаниеТовара1», «Описание товара2» и т.д. Но количество атрибутов также ограничено - максимум 256 атрибутов. Пока SimpleDB находится в стадии бета-версии, размер домена ограничен 10-ю гигабайтами, а вся база не может занимать больше 1-го терабайта.

Одной из ключевых особенностей SimpleDB является использование модели (eventual consistency model). Эта модель подходит для многопоточной работы, однако следует иметь в виду, что после того, как вы изменили значение атрибута в какой-то записи, при последующих операциях чтения эти изменения могут быть не видны. Вероятность такого развития событий достаточно низкая, тем не менее, о ней нужно помнить. Вы же не хотите продать последний билет пяти покупателям только потому, что ваши данные были неконсистентны в момент продажи.

Google AppEngine Data Store

Google"s AppEngine Datastore построен на основе BigTable, внутренней системе хранения структурированных данных от Google. AppEngine Datastore не предоставляет прямой доступ к BigTable, но может восприниматься как упрощенный интерфейс взаимодействия с BigTable.

AppEngine Datastore поддерживает большее число типов данных внутри одной записи, нежели SimpleDB. Например, списки, которые могут содержать коллекции внутри записи.

Скорее всего вы будете использовать именно это хранилище данных при разработке с помощью Google AppEngine. Однако в отличии от SimpleDB, вы не сможете использовать AppEngine Datastore (или BigTable) вне веб-сервисов Google.

Microsoft: SQL Data Services

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

Необлачные хранилища

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

CouchDB

CouchDB - это свободно распространяемая документо-ориентированная БД с открытым исходным кодом. В качестве формата хранения данных используется JSON. CouchDB призвана заполнить пробел между документо-ориентированными и реляционными базами данных с помощью «представлений». Такие представления содержат данные из документов в виде, схожим с табличным, и позволяют строить индексы и выполнять запросы.

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

Проект Voldemort

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

Mongo

Mongo - это база данных, разрабатываемая в 10gen Гейром Магнуссоном и Дуайтом Меррименом (которого вы можете знать по DoubleClick). Как и CouchDB, Mongo - это документо-ориентированная база данных, хранящая данные в JSON формате. Однако Mongo скорее является объектной базой, нежели чистым хранилищем типа ключ-значение.

Drizzle

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

Решение

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

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

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

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

1 - по моему мнению, здесь больше подходит термин «структура данных», однако оставил оригинальное data model.
2 - скорее всего, автор имел в виду, что по своим возможностям нереляционные БД уступают реляционным.
3 - возможно, данные уже устарели, статья датируется февралем 2009 года.

voldemort

drizzle

Добавить метки

2. Принципы реляционной модели

Принципы реляционной модели баз данных, отношение (relation), таблица (table), набор результатов (result set), кортеж, мощность, атрибут, размерность, заголовок, тело, домен

Реляционная модель была разработана в конце 1960-х годов Е.Ф.Коддом (сотрудник IBM) и опубликованы в 1970 г. Она определяет способ представления данных (структуру данных), методы защиты данных (целостность данных), и операции, которые можно выполнять с данными (манипулирование данными).

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

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

· все данные на концептуальном уровне представляются в виде упорядоченной организации, определенной в виде строк и столбцов и называемой отношением (relation). Более распространенный синоним слова "отношение" - таблица (или "набор записей", или набор результатов - result set. Именно от этого и происходит термин "реляционные базы данных", а вовсе не от отношений между таблицами;

· все значения являются скалярами. Это значит, что для любой строки и столбца любого отношения существует одно и только одно значение;

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

Теперь - про формальную терминологию:

· отношение (relation ) - это вся структура целиком, набор записей (в обычном понимании - таблица).

· кортеж - это каждая строка, содержащая данные. Более распространенный, но менее формальный термин - запись.

· мощность - число кортежей в отношении (проще говоря, число записей);

· атрибут - это столбец в отношении;

· размерность - это число атрибутов в отношении (в данном случае - 3);

· каждое отношение можно разделить на две части - заголовок и тело . На простом языке заголовок отношения - это список столбцов, а тело - это сами записи (кортежи).

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

· тело отношения состоит из неупорядоченного набора кортежей (его число может быть любым - от 0 до бесконечно большого).

Функции СУБД.

Функции СУБД бывают высокого и низкого уровня.

Функции высокого уровня:

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

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

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

Функции низкого уровня:

1. Управление данными во внешней памяти;

2. Управление буферами оперативной памяти;

3. Управление транзакциями;

4. Введение журнала изменений в БД;

5. Обеспечение целостности и безопасности БД.

Транзакцией называется неделимая последовательность операций, которая отслеживается СУБД от начала и до завершения, и в которой при невыполнении одной операции отменяется вся последовательность.

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

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

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

Классификация СУБД.

СУБД можно классифицировать:

1. По видам программ:

a. Серверы БД (например, MS SQL Server, InterBase (Borland)) – предназначены для организации центров обработки данных в сетях ЭВМ и реализуют функции управления базами данных, запрашиваемые клиентскими программами с помощью операторов SQL (т.е. программы, которые отвечают на запросы);

b. Клиенты БД – программы, которые запрашивают данные. В качестве клиентских программ могут использоваться ПФСУБД, электронные таблицы, текстовые процессоры, программы электронной почты;

c. Полнофункциональные БД (MS Access, MS Fox Pro) – программа, имеющая развитый интерфейс, позволяющий создавать и модифицировать таблицы, вводить данные, создавать и форматировать запросы, разрабатывать отчёты и выводить их на печать.

2. По модели данных СУБД (как и БД):

a. Иерархические – основаны на древовидной структуре хранения информации и напоминают файловую систему компьютера; основной недостаток - невозможность реализовать отношение многие - ко – многим;

b. Сетевые – которые пришли на смену иерархическим и просуществовали недолго т. к. основной недостаток – сложность разработки серьёзных приложений. Основное отличие сетевой от иерархической в том, что в иерархической структура «запись – потомок» имеет только одного предка, а в сетевой потомок может иметь любое количество предков;

c. Реляционные – данные которых размещены в таблицах, между которыми существуют определённые связи;

d. Объектно – ориентированные – в них данные хранятся в виде объектов и основное преимущество при работе с ними в том, что к ним можно применить объектно – ориентированный подход;

e. Гибридные, т. е. объектно – реляционные – совмещают в себе возможности реляционных и объектно – ориентированных баз данных. Примером такой базы данных является Oracle (ранее она была реляционной).

3. В зависимости от расположения отдельных частей СУБД различают:

a. локальные – все части которой располагаются на одном компьютере;

b. сетевые.

К сетевым относятся:

- с организацией файл – сервер ;

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

- с организацией клиент – сервер;

Сервер БД принимает запрос от клиента, отыскивает в данных нужную запись и передаёт её клиенту. Запрос к серверу формируется на языке структурированных запросов SQL, поэтому серверы БД называют SQL – серверами.

- распределённые СУБД содержат несколько десятков и сотен серверов, размещённых на значительной территории.

Основные положения реляционной модели БД.

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

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

1. Данные хранятся в таблицах, состоящих из столбцов и строк;

2. На пересечении каждого столбца и строки находится одно значение;

3. У каждого столбца - поля есть своё имя, которое служит его названием - атрибут, и все значения в одном столбце, имеют один тип;

4. Столбцы располагаются в определённом порядке, который задаётся при создании таблицы, в отличие от строк, которые располагаются в произвольном порядке. В таблице может не быть ни одной строчки, но обязательно должен быть хотя бы один столбец.

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

Элемент реляционной БД	Форма представления
1. База данных	Набор таблиц
2. Схема базы данных	Набор заголовков таблиц
3. Отношение	Таблица
4. Схема отношения	Строка заголовков столбцов таблицы
5. Сущность	Описание свойств объекта
6. Атрибут	Заголовок столбца
7. Домен	Множество допустимых значений атрибута
8. Первичный ключ	Уникальный идентификатор, однозначно определяющий каждую запись в таблице
9. Тип данных	Тип значений элементов в таблице
10. Кортеж	Строка (запись)
11. Кардинальность	Количество строк в таблице
12. Степень отношения	Количество полей
13. Тело отношения	Множество кортежей отношения

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

Существуют следующие виды связей между таблицами:

1. Связь вида 1:1 (один к одному) означает, что каждой записи в основной таблице соответствует одна запись в дополнительной таблице и, наоборот, каждой записи в дополнительной таблице соответствует одна запись в основной таблице.

2. Связь вида 1:М (один ко многим) означает, что каждой записи в основной таблице соответствует несколько записей в дополнительной таблице и, наоборот, каждой записи в дополнительной таблице соответствует только одна запись в основной таблице.

3. Связь вида М:1 (многим к одному) означает, что одной или нескольким записям в основной таблице соответствует только одна запись в дополнительной таблице.

4. Связь вида М:М (многим ко многим) – это, когда нескольким записям основной таблицы соответствует несколько записей дополнительной и наоборот.

5. Основные компоненты MS Access.

Основными компонентами (объектами) MS Access являются:

1. Таблицы;

3. Формы;

4. Отчёты;

5. Макросы:

Модули.

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

Запрос – вопрос о данных, хранящихся в таблицах, или инструкция на отбор записей, подлежащих изменению.

Форма – это объект, в котором можно разместить элементы управления, предназначенные для ввода, изображения и изменения данных в полях таблицах.

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

Макрос – одна или несколько макрокоманд, которые можно использовать для автоматизации конкретной задачи. Макрокоманда – основной строительный блок макроса; самостоятельная инструкция, которая может быть объединена с другими макрокомандами, чтобы автоматизировать выполнение задачи.

Модуль – набор описаний, инструкций и процедур, сохранённых под одним именем. В MS Access имеется три вида модулей:модуль формы, отчёта и общий модуль. Модули формы и отчётов содержат локальную программу для форм и отчётов.

6. Таблицы в MS Access.

В MS Access существуют следующие методы создания таблиц:

1. Режим таблицы;

2. Конструктор;

3. Мастер таблиц;

4. Импорт таблиц;

5. Связь с таблицами.

В режиме таблицы данные вводятся в пустую таблицу. Для ввода данных предоставляется таблица с 30 полями. После её сохранения MS Access сам решает, какой тип данных присвоить каждому полю.

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

Для определения поля в режиме Конструктор задаются:

1. Имя поля , которое в каждой таблице должно иметь уникальное имя, являющееся комбинацией букв, цифр, пробелов и специальных символов, за исключением «.!” “ ». Максимальная длина имени 64 символа.

2. Тип данных определяет вид и диапазон допустимых значений, а также объём памяти, выделенный для этого поля.

Типы данных MS Access

Тип данных	Описание
Текстовый	Текст и числа, например, имена и адреса, номера телефонов, почтовые индексы (до 255 символов).
Поле Memo	Длинный текст и числа, например комментарии и пояснения (до 64000 символов).
Числовой	Общий тип данных для числовых данных, допускающих проведение математических расчётов, за исключением денежных расчётов.
Дата / время	Значения даты и времени. Пользователь может выбирать стандартные формы или создавать специальный формат.
Денежный	Денежные значения. Для денежных расчётов не рекомендуется использовать числовые типы данных, т.к. они могут округляться при расчётах. Значения типа «денежный» всегда выводятся с указанным числом десятичных знаков после запятой.
Счётчик	Автоматически выставляющиеся последовательные номера. Нумерация начинается с 1. Поле счётчика удобно для создания ключа. Это поле является совместимым с полем числового типа, для которого в свойстве Размер указано значение «Длинное целое».
Логический	Значения «Да / Нет», «Истинно / Ложь», «Вкл / Выкл», одно из двух возможных значений.
Поле объекта OLE	Объекты, созданные в других программах, поддерживающие протокол OLE.

3. Наиболее важные свойства полей:

- Размер поля задаёт максимальный размер данных, сохраняемых в поле.

- Формат поля является форматом отображения заданного типа данных и задаёт правила представления данных при выводе их на экран или печать.

- Подпись поля задаёт текст, который выводится в таблицах, формах, отчётах.

- Условие на значение позволяет осуществлять контроль ввода, задаёт ограничения на вводимые значения, при нарушении условий запрещает ввод и выводит текст, заданный свойством Сообщение об ошибке;

- Сообщение об ошибке задаёт текст сообщения, выводимый на экран при нарушении ограничений, заданных Условием на значение.

Тип элемента управления – свойство, которое задаётся на закладке Подстановка в окне конструктора таблиц. Это свойство определяет, будет ли отображаться поле в таблице и в какой форме – в виде поля или поля со списком.

Уникальный (первичный) ключ таблицы может быть простым или составным, включающим несколько полей.

Для определения ключа выделяются поля, составляющие ключ, и на панели инструментов нажимается кнопка ключевое поле или выполняется команда Правка / ключевое поле .

©2015-2019 сайт
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2016-02-16