MySQL. Библиотека профессионала - Аткинсон Л

52 Глава 4. Концепции баз данных

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

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

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

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

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

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

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

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

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

На рис. 4.1 изображена простая иерархическая база данных, в которой фиксирует ся деятельность независимого подрядчика. Корень дерева представляет собой запись о клиенте. Ее потомками являются две записи о счет фактурах и три записи об опла тах счетов. Структура счета номер 17 уточняется в трех дочерних записях, у счета но мер 23 одна такаязапись.

Рис. 4.1. Иерархическая база данных

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

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

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

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

54 Глава 4. Концепции баз данных

Следуя спецификации CODASYL, сетевая модель поддерживает DDL (Data Defini tion Language— язык определения данных) и DML (Data Manipulation Language — язык обработки данных). Это специальные языки, предназначенные для определения структуры базы данных и составления запросов. Несмотря на их наличие програм мист по прежнему должен знать структуру базы данных.

Всетевой модели допускаются отношения "многие ко многим", а записи не зависят друг от друга. При удалениизаписиудаляются и все ее связи, но не сами связанные записи.

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

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

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

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

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

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

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

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

производитель, модель, год выпуска, пробег и т.д. Такие таблицы легко изображать в графическом виде.

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

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

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

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

Объектно ориентированные базы данных

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

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

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

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

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

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

56 Глава 4. Концепции баз данных

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

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

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

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

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

РЕЛЯЦИОННАЯ

МОДЕЛЬ

В этой главе...

Реляционная алгебра

Таблицы, строки и столбцы Ключи Отношения

Реляционные операции

Является ли MySQL настоящей реляционной СУБД

60 Глава 5. Реляционная модель

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

Таблица состоит из строк (записей) и столбцов (полей). В столбце хранятся соот ветствующие значения каждой строки; каких либо "пропусков" или коротких столб цов быть не может. Запись является отдельной сущностью, а поля представляют со бой атрибуты записей.

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

У каждого столбца есть название и тип. Типы данных будутрассматриваться в гла ве 11, "Типы столбцов и индексов", а пока лишь скажем, что базовыми типами счита ются строковый, числовой и дата/время. В табл. 5.1 столбцы "Фамилия" и "Позиция" имеют строковый тип, а в столбце "Дата рождения" находятся значения даты.

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

Порядок строк в таблице произволен и не имеет никакого значения. По сути, он отражает очередность записи строк на диск и может быть разным. Как будет показано в главе 6, "Язык SQL", есть способы указания порядка записей, возвращаемых в ре зультате запроса.

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

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

Ключи 61

Предположим, в команде появляется новый игрок, позиция которого на поле еще не определена. В этом случае в поле "Позиция" следует занести значение NULL. Это специальная константа, не равная пустой строке. Она означает отсутствие значения.

Ключи

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

Давайте расширим таблицу бейсболистов, добавив в нее столбец "Команда" (табл. 5.2). В этом столбце хранится идентификатор команды, а не ее название. Соответствия между идентификаторами и названиями находятся в другой таблице (табл. 5.3).

Столбец "Идентификатор" в табл. 5.3 является первичным ключом. Значение первич ного ключа уникальным образом идентифицирует каждую строку. Толькозначения пер вичного ключа могут встречаться в столбце "Команда" табл. 5.2. Последний, в свою оче редь, называется внешним ключом, так как его значенияберутся из внешней таблицы.

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