Реляционные базы данных, структура реляционных баз данных
Реляционные базы данных получили очень широкое распространение и многие пытаются писать огромные статьи, посвященные вопросу – почему реляционные базы данных получили такое широкое распространение, делают глубокомысленные выводы и замечания. Но на самом деле все очень просто – реляционные базы данных очень легко описываются в математике, то есть, под них очень хорошо написана математика.
Был когда-то такой математик – Эдгар Франк Кодд, умерший в 2003 году, который в восьмидесятых годах очень подробно описал структуру реляционных баз данных математическим языком. А если есть хорошо написанная математика, то соответственно есть и программная реализация. Останавливаться на биографии Э.Ф. Кодда я не буду, для этого есть различные энциклопедии. Именно благодаря Кодду реляционные базы данных стали активно развиваться. Поэтому-то, когда мы говорим базы данных, чаще всего мы подразумеваем именно реляционные базы данных.
ОСОБЕННОСТИ РЕЛЯЦИОННЫХ БАЗ ДАННЫХ
Главной особенностью реляционных баз данных является, то, что объекты внутри таких баз данных хранятся в виденабора двумерных таблиц. То есть, таблица состоит из набора столбцов, в котором может указываться: название, тип данных(дата, число, строка, текст и т.д.). Еще одной важной особенность реляционных БД является, то, что число столбцов фиксировано, то есть, структура базы данных известна заранее, а вот число строк или рядов в реляционных базах данных ничем не ограничено, если говорить грубо, то строки в реляционных базах данных и есть объекты, которые хранятся в базе данных.
На самом деле, базы данных – это абстрактное понятие, таблица – это всего лишь способ хранения информации, набор таблиц может быть связан логически и этот набор называют база данных. Поэтому неправильно говорить, что MySQL это база данных, база данных – это хранящаяся информация. А вот такое понятие, как СУБД – система управления базами данных, это и есть MySQL сервер, именно при помощи него мы управляем хранящимися данными. Или иначе MySQL – это программное воплощение математических идей.
Самой трудной задачей при работе с реляционными базами данных, является проектирование структуры баз данных. Проектирование структуры базы данных, заключается не только в том, чтобы создать таблицу и указать тип данных и наименование столбцов. На самом деле проектирование – это самый сложный этап при работе с базами данных. Потому что мощности ваших компьютеров ограничены. Пока данных мало, мало таблиц и строк в этих таблицах, машина будет их обрабатывать очень и очень быстро. Но, со временем количество информации будет увеличиваться, и мы получим замедление, которое будет увеличиваться, поскольку машине необходимо время на обработку тех или иных запросов(обработка информации). В прошлой статье я уже писал, что реляционные БД прежде всего ориентированы на модификацию(OLTP), то есть, добавить новую запись в таблицу – это очень простая операция для реляционной СУБД, а вот сделать выборку данных, это уже трудоемкая операция. Также есть и изменение данных, это как бы промежуточное звено между чтением и добавлением. Хотя MySQL сервер всегда можно настроить.
49. Распределенные базы данных. Двенадцать правил Дейта для распределенных баз данных.
Распределенная база данных (DDB – distributed database) – это совокупность логически взаимосвязанных баз данных, распределенных в компьютерной сети. Распределенная система управления базой данных определяется как программная система, которая позволяет управлять распределенной базой данных таким образом, чтобы ее распределенность была прозрачна для пользователей [Ozsu and Valduriez, 1991a]. В этом определении следует уточнить две отличительных архитектурных особенности. Первая из них заключается в том, что система состоит из (возможно, пустого) множества узлов приема запросов(query site) и непустого множества узлов данных (data site). Узлы данных обладают средствами для хранения данных, а узлы приема запросов – нет. В узлах приема запросов лишь выполняются программы, реализующие пользовательский интерфейс для доступа к данным, хранящимся в узлах данных. Вторая особенность состоит в том, что узлы логически представляют собой независимые компьютеры. Следовательно, у такого узла имеется собственная основная и внешняя память, установлена собственная операционная система (может быть, одна и та же на всех узлах, а возможно, и нет) и имеется возможность выполнять приложения. Узлы связаны компьютерной сетью, а не входят в мультипроцессорную конфигурацию. Важно подчеркнуть слабую связанность процессоров, которые обладают собственными операционными системами и функционирует независимо.
База данных физически распределяется по узлам данных на основе фрагментации и репликацииданных [Ceri et al., 1987]. При наличии схемы реляционной базы данных каждое отношение фрагментируется на горизонтальные или вертикальные разделы. Горизонтальная фрагментацияреализуется при помощи операции селекции, которая направляет каждый кортеж отношения в один из разделов, руководствуясь предикатом фрагментации. Например, для отношения Employee возможна фрагментация в соответствии с местоположением рабочих мест служащих. При вертикальной фрагментации отношение делится на разделы при помощи операции проекции. Например, один раздел отношения Employee может содержать поля Emp_number, Emp_name и Address, а другой – поля Emp_number,Salary и Manager. За счет фрагментации данные приближаются к месту их наиболее интенсивного использования, что потенциально снижает затраты на пересылки; уменьшаются также размеры отношений, участвующих в пользовательских запросах.
Фрагменты данных могут также реплицироваться на основе характера доступа к ним. Это полезно, если доступ к одним и тем же данным производится из приложений, выполняющихся на разных узлах. В таком случае, с точки зрения экономии затрат, более эффективно дублировать данные в ряде узлов, чем непрерывно пересылать данные между узлами.
При ослаблении отличительных особенностей распределенной СУБД получается параллельная система баз данных. Не существует четкого разграничения между параллельными и распределенными СУБД. В частности, архитектуры параллельных СУБД без совместно используемых ресурсов (sharing-nothing), которые обсуждаются ниже, схожи со слабо связанными распределенными системами. В параллельных СУБД используются новейшие многопроцессорные архитектуры, и на основе этого подхода создаются высокопроизводительные серверы баз данных высокой доступности, стоимость которых значительно ниже эквивалентных систем на мэйнфреймах.
1. Локальная автономность. Локальные данные должны находиться под локальным владением и управлением, включая функции безопасности, целостности, представления данных в памяти. Исключением может быть ситуация, когда ограничения целостности охватывают данные нескольких узлов или когда управление распределенной транзакцией осуществляется некоторым внешним узлом.
2. Никакой конкретный сервис не должен возлагаться на какой-либо специально выделенный центральный узел. Соблюдение этого правила, т.е. принципа децентрализованное™ функций РаСУБД, позволяет избежать узких мест.
3. Непрерывность функционирования. Система не должна останавливаться в случае необходимости добавления нового узла или удаления в распределенной среде некоторых данных, изменения определения метаданных и даже (что довольно сложно) осуществления перехода к новой версии СУБД на отдельном узле.
Характеристики распределенной базы данных определяются рядом основополагающих принципов, однако в коммерческих СУБД большинство этих принципов до сих пор не реализовано Необходимо по меньшей мере найти компромисс между этими принципами, поскольку в рамках существующих технологий многие из (них находятся в противоречии друг с другом. Некоторые среды РаБД/РаСУБД однородны локальные менеджеры данных в них представлены одним и тем же продуктом СУБД. Другие по своей природе разнородны в них используются разные продукты СУБД (иногда даже основанные на разных моделях данных, вплоть до плоских файлов). Некоторые среды создаются «сверху вниз», как говорится, «с чистого листа» Однако более типична ситуация, когда для включения унаследованных систем приходится прибегать к конструированию «снизу вверх» Конструирование «снизу вверх» оказывается значительно более сложным, поскольку при объединении поддерживающих сред обычно возникают характерные проблемы избыточности данных, обеспечения непротиворечивости, структурного несоответствия. В некоторых системах используются различные модели разбиения (называемого также фрагментацией), которые позволяют распределять данные между различными системами, обеспечивая тем не менее возможность трактовать их глобальным образом, как если бы они были централизованы Другие модели распределения предусматривают тиражирование части или всех данных по множеству систем с целью увеличения общей пропускной способности среды и повышения доступности данных
Что может дать эта технология
Учитывая, что распределенность и неоднородность быстро становятся реальностью для информационных систем (ИС) практически любой организации, для Г предотвращения всеобщего хаоса настоятельно необходимо внедрение методов кооперативного управления рассеянной информацией. В этой главе мы опишем фундаментальные принципы, в следующих главах - конкретные технологии, а в гл. 7 рассмотрим соотношения между ними.
4. Независимость от местоположения. Пользователи и приложения не обязаны знать о том, где физически располагаются данные.
5. Независимость от фрагментации. Фрагменты (называемые также разделами) данных должны поддерживаться и обрабатываться средствами РаСУБД таким образом, чтобы пользователи или приложения могли бы вообще ничего не знать об этом. Более того, РаСУБД должна уметь обходить при обработке запросов фрагменты, не имеющие к ним отношения (например, РаСУБД должна быть достаточно интеллектуальной, для того чтобы определять, можно ли исключить при обработке запроса тот или иной фрагмент в силу того, что запрос не содержит ссылок на хранящиеся в этом фрагменте столбцы).
6. Независимость от тиражирования. Те же принципы независимости и прозрачности относятся и к механизму тиражирования, который обсуждается ниже.
7. Распределенная обработка запросов. Обработка запросов должна производиться распределенным образом. В следующем разделе мы рассмотрим некоторые архитектурные принципы реализации РаСУБД и различные модели, в рамках которых возможна распределенная обработка запросов.
8. Управление распределенными транзакциями. На распределенные базы данных необходимо распространить механизмы управления транзакциями и управления одновременным доступом. Эта проблема включает выявление и разрешение тупиковых ситуаций, прерывания по истечении временных интервалов, фиксацию и откат распределенных транзакций, а также ряд других вопросов.
9. Независимость от оборудования. Одно и то же программное обеспечение РаСУБД должно выполняться на различных аппаратных платформах и функционировать в системе в качестве равноправного партнера. Как уже обсуждалось выше, на практике достичь этого исключительно сложно, поскольку многие поставщики поддерживают множество платформ. Это ограничение преодолевается с помощью модели многопродуктовых сред.
10. Независимость от операционных систем. Эта проблема тесно связана с предыдущей, и она также решается аналогичным образом.
11. Независимость от сети. Узлы могут быть связаны между собой с помощью множества разнообразных сетевых и коммуникационных средств. Многоуровневая модель, присущая многим современным информационным системам (например, семиуровневая модель OSI, модель TCP/IP, уровни SNA и DECnet), обеспечивает решение этой проблемы не только в среде РаБД, но и для информационных систем вообще.
12. Независимость от СУБД. Локальные СУБД должны иметь возможность участвовать в функционировании РаСУБД.
Очевидно, что, хотя крайне желательно было бы иметь системы, удовлетворяющие всем 12 правилам, нереально ожидать реализации этих требований в рамках хотя бы одного продукта даже в ближайшие годы. И действительно, за время, прошедшее с момента опубликования правил Дейта, эта цель так и не была достигнута.
Отчасти по этой причине поставщики, ориентирующиеся на рынок распределенных баз данных, придерживаются многоэтапного подхода к внедрению средств распределения в свои продукты. Одним из наиболее известных предложений в этой области является выдвинутая в 1989 г. компанией IBM программа, где определены четыре шага, необходимых для перехода к управлению распределенными базами данных и призванных обеспечить следующие возможности4:
1. Удаленный запрос. Эта парадигма эквивалентна базовой модели удаленного доступа. Выполняется подключение к удаленному узлу и производится чтение или изменение данных на этом узле. Результат поступает на исходный узел, после чего транзакция завершается. Практически любая коммерческая СУБД в настоящее время поддерживает удаленные запросы, и такая возможность предоставляется уже в течение некоторого времени.
2. Удаленная единица работы. Это означает, что на удаленном узле можно выполнить группу запросов как атомарную единицу (транзакцию). Приложение, вообще говоря, может получать и модифицировать данные многих узлов, но каждая транзакция затрагивает данные только одного узла. I
3. Распределённая единица работы при этом каждый запрос относится только к одному узлу, но запросы, составляющие распределенную единицу работы (транзакцию), могут выполняться совместно на нескольких узлах. Вся группа запросов при этом фиксируется или откатывается как одно целое.
4. Распределенный запрос. Этот шаг предусматривает возможность выполнения запросов, охватывающих множество баз данных на разных узлах. Несколько таких распределенных запросов может быть далее сгруппировано в качестве транзакции.
50. Системы «клиент/сервер».
Применительно к системам баз данных архитектура "клиент-сервер" интересна и актуальна главным образом потому, что обеспечивает простое и относительно дешевое решение проблемы коллективного доступа к базам данных в локальной сети. В некотором роде системы баз данных, основанные на архитектуре "клиент-сервер", являются приближением к распределенным системам баз данных, конечно, существенно упрощенным приближением, но зато не требующим решения основного набора проблем действительно распределенных баз данных.
Архитектура клиент-сервер предъявляет специфические требования как к клиенту, так и к серверу. Программа, удовлетворяющая этим требованиям, может считаться клиент-серверным приложением, выполняющим распределенную обработку данных (рис. 6.5).
