WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     || 2 | 3 | 4 | 5 |   ...   | 7 |
-- [ Страница 1 ] --

Содержит примеры проектирования и систем корпоративного уровня и подробные объяснения к ним главы по вопросам хранения распределенных баз и другим

сложным темам Леоном ведущим специалистом с кодом Леон Аткинсон MySQL БИБЛИОТЕКА ПРОФЕССИОНАЛА ЛЕОН АТКИНСОН Москва • Санкт Петербург • Киев 2002 ББК 32.973.26 018.2.75 А92 УДК 681.3.07 Издательский дом "Вильяме" Зав. редакцией С.Н. Тригуб Перевод с английс кого и редакция В.Р. Гинзбурга По общим вопросам обращайтесь в Издательский дом "Вильяме" по адресу:

info@williamspublishing.com, http://www.williamspublishing.com Аткинсон, Леон.

А92 MySQL. Библиотека профессионала.: Пер. с англ. — М.: Издательский дом "Вильяме", 2002. — 624 с.: ил. — Парал. тит. англ.

ISBN 5 8459 0291 6 (рус.) В данной книге описана программа MySQL версии 3.23 — самый последний стабиль ный выпуск, доступный на момент написания книги. Сначала излагаются основы MySQL: запросы, модели баз данных, вопросы нормализации и организации много пользовательской работы, а также транзакции. Затем систематически анализируются все ключевые аспекты программы и демонстрируются эффективные методики взаимо действия с базами данных MySQL посредством языков С, Java, PHP, Perl, Python и др.

Внимательно проверенная ведущим разработчиком MySQL Микаэлем Видениу сом, данная книга дает профессионалам именно то, что они ищут: авторитетное, подробное, богатое примерами руководство по разработке приложений MySQL кор поративного уровня.

ББК 32.973.26 018.2. Все названия программных продуктов являются зарегистрированными торговыми марками со ответствующих фирм.

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

ISBN 5 8459 0291 6 (рус.) © Издательский дом "Вильяме", ISBN 0 13 066190 2 (англ.) © Prentice Hall, Inc., Оглавление ВВЕДЕНИЕ ЧАСТЬ I. MYSQL И РЕЛЯЦИОННАЯ МОДЕЛЬ ДАННЫХ Глава 1. Введение в MYSQL Глава 2. ИнсталляцияMYSQL Глава 3. Взаимодействие с MYSQL Глава 4. Концепции баз данных Глава 5. Реляционная модель Глава 6. ЯзыкSQL Глава 7. Проектирование баз данных Глава 8. Нормализация Глава 9. Транзакции и параллельные вычисления ЧАСТЬ II. СПРАВОЧНИКMYSQL Глава 10. Типы данных, переменные и выражения Глава 11. Типы столбцов и индексов Глава 12. Встроенные функции Глава 13. Инструкции SQL Глава 14. Утилиты командной строки Глава 15. Библиотека функций языка С ЧАСТЬ III. СОЗДАНИЕ КЛИЕНТОВ MYSQL Глава 16. Использование библиотеки языка С Глава 17. JDBC Глава 18. VBSCRIPT и ODBC Глава 19. РНР Глава 20. PERL Глава 21. PYTHON Глава 22. Библиотека MYSQL++ ЧАСТЬ IV. Сложные темы Глава 23. Администрирование баз данных Глава 24. Физическое хранение данных Глава 25. Устранение последствий катастроф 6 Оглавление Глава 26. Оптимизация Глава 27. Безопасность Глава 28. Перенос данных в разные СУБД Глава 29. Распределенные базы данных Глава 30. Работа с объектами Глава 31. Расширение возможностей MYSQL Приложение А. Ресурсы в Internet Приложение Б. Правовые аспекты Приложение В. Зарезервированные слова Приложение Г. Коды ошибок MYSQL Приложение Д. Руководство по оформлению SQL сценариев Приложение E. Пример базы данных Содержание Содержание ВВЕДЕНИЕ ЧАСТЬ I. MYSQL И РЕЛЯЦИОННАЯ МОДЕЛЬ ДАННЫХ Глава 1. Введение в MYSQL Принципы использования баз данных Преимущества баз данных Недостатки баз данных Зачем нужна программа MySQL История MySQL Глава 2. Инсталляция MYSQL Загрузка дистрибутива Инсталляция с помощью менеджера пакетов RedHat Linux Инсталляция в Windows Инсталляция вручную Компиляция программы Предоставление привилегий Глава 3. Взаимодействие с MYSQL Клиент серверное взаимодействие средствами TCP/IP Утилиты командной строки Графические клиенты ODBC Web интерфейсы Глава 4. Концепции баз данных История Терминология СУБД Системы управления файлами Иерархические базы данных Сетевые базы данных Реляционные базы данных Объектно ориентированные базы данных Объектно реляционные базы данных Глава 5. Реляционная модель Реляционная алгебра Таблицы, строки и столбцы Ключи Отношения 8 Содержание Реляционные операции Является ли MySQL настоящей реляционнойСУБД Глава 6. Язык SQL SQL — языкчетвертого поколения Определение данных Вставка записей Обновление записей Удаление записей Запросы Объединения Упорядочение результатов запроса Группировка результатов запроса Ограничение числа возвращаемых записей Изменение определения таблицы Глава 7. Проектирование баз данных Спецификация требований Спецификация проекта Составление схемы базы данных Реализация модели Тестирование Планирование жизненного цикла Глава 8. Нормализация Зачем нужна нормализация Первая нормальная форма Вторая нормальная форма Третья нормальная форма Нормальная форма Бойса Кодда Четвертая нормальная форма Денормализация Глава 9. Транзакции и параллельные вычисления Параллельные запросы ПО Транзакции Блокировки Последовательности ЧАСТЬ П. СПРАВОЧНИК MYSQL Глава 10. Типы данных, переменные и выражения Типы данных Переменные Операторы Выражения Имена с пробелами Содержание Глава 11. Типы столбцов и индексов Числа Строки Значения даты/времени Альтернативные типы данных Индексы Глава 12. Встроенные функции Отладка и конфигурирование Управляющие функции Статистические функции Математические функции Строки Функции работы с датой и временем Прочие функции Процедуры Глава 13. Инструкции SQL Комментарии Полный список инструкций Глава 14. Утилиты командной строки Переменные среды Конфигурационные файлы Полный список утилит Глава 15. Библиотека функций языка С Типы данных Клиентские функции Функции работы с массивами Функции работы с наборами символов Функции работы с файлами Функции обработки ошибок Функции работы с хэш таблицами Функции работы со списками Функции управления памятью Функции работы с опциями Функции обработки паролей Функции обработки строк Функции работы с потоками ЧАСТЬ III. СОЗДАНИЕ КЛИЕНТОВ MYSQL Глава 16. Использование библиотеки языка С Подготовка программы Извлечение данных Изменение данных 10 Содержание Глава 17. JDBC Подготовка программы Извлечение данных Изменение данных Глава 18. VBSCRIPT и ODBC Подготовка программы Извлечение данных Изменение данных Глава 19. РНР Подготовка программы Извлечение данных Изменение данных Глава 20. PERL Подготовка программы Извлечение данных Изменение данных Глава 21. PYTHON Подготовка программы Извлечение данных Изменение данных Глава 22. Библиотека MYSQL++ Подготовка программы Извлечение данных Изменение данных ЧАСТЬ IV. Сложные темы Глава 23. Администрирование баз данных Ответственность Обеспечение доступности данных Поддержание целостности данных Подготовка к катастрофе Поддержка пользователей Разработка и внедрение стандартов Глава 24. Физическое хранение данных Способ хранения таблиц и баз данных Выделенные разделы Типы таблиц Столбцы Блокировки таблиц Индексы Дескрипторы файлов Содержание Системная память Журнальные файлы Глава 25. Устранение последствий катастроф Проверка и восстановление таблиц Резервное копирование и восстановление Глава 26. Оптимизация Предварительные действия Тесты производительности Оптимизация проекта Оптимизация приложений Оптимизация запросов Оптимизация инструкций Обслуживание таблиц Настройка конфигурации сервера Перекомпиляция MySQL Глава 27. Безопасность Схема привилегий Задание привилегий Обеспечение безопасности Глава 28. Перенос данных в разные СУБД Переключение между СУБД Устранение несовместимостей Использование режима ANSI Уникальные свойстваMySQL Глава 29. Распределенные базы данных Концепции распределенных баз данных Отложенная синхронизация Репликация в MySQL Запуск нескольких серверов Глава 30. Работа с объектами Объектно ориентированная модель Сериализация объектов Объектно реляционные связи Глава 31. Расширение возможностей MYSQL Библиотека функций отладки Создание наборов символов Создание функций Создание процедур Приложение А. Ресурсы в Internet Официальные списки рассылки Архивы списков рассылки 12 Содержание Web узлы Отчеты об ошибках Приложение Б. Правовые аспекты Лицензирование программы MySQL Общая лицензия GNU Стабильность Поддержка Приложение В. Зарезервированные слова Приложение Г. Коды ошибок MYSQL Приложение Д. Руководство по оформлению SQL сценариев Общие правила Идентификаторы Таблицы Инструкции Приложение E. Пример базы данных Диаграммы Схема базы данных Предметный указатель Благодарности Я бы не смог закончить эту книгу без поддержки моей жены Викки. Помимо того что она прекрасный технический редактор, она постоянно вдохновляла, поддержи вала и просто понимала меня.

Кроме Викки я общался с несколькими профессиональными техническими редак торами. Дан Статен (Dan Staten) и Дан Ливингстон (Dan Livingston) дали мне советы с точки зрения общих вопросов редактирования. Микаэль Видениус (Michael Widenius) и Кай Арнё (Kaj Arno), несмотря на свою занятость, внимательно просмотрели текст книги. Благодарю также Синишу Миливоевича (SiniSa MilivojeviC), который обсуждал со мной вопросы библиотеки MySQL++ API.

Я признателен редактору Марку Таубу (Mark Taub) и издательству Prentice Hall.

В частности, я благодарен за предоставленную мне свободу в выборе структуры кни ги. Кроме того, мне было очень приятно, что Марк одобрил мое соглашение с компа нией MySQL AB, выразив таким образом свою поддержку сообществу разработчиков открытого программного обеспечения.

Наконец, спасибо всем вам за то, что купили эту книгу!

ВВЕДЕНИЕ Трудно сделать выбор между теми программными продуктами, которые любишь больше всего. Я много лет с удовольствием занимался Web программированием на языке РНР с использованием программы MySQL, но сначала решил написать книгу Core PHP Programming. Через два года настал черед и книги по MySQL. Оба этих средст ва — MySQL и РНР — идут рука об руку друг с другом, поэтому я надеюсь, что читатели найдут данную книгу полезным дополнением к упомянутому вышеизданию.

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

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

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

В данной книге описаны реляционные базы данных вообще и MySQL в частности.

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

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

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

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

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

В третьей части описываются механизмы взаимодействия с сервером MySQL в разных языках программирования, включая С, C++,Java, VBScript, PHP, Perl и Python.

От читателей предполагается знакомство с этими языками.

В четвертой части рассматриваются сложные вопросы работы с базами данных.

Здесь рассказывается о том, как использовать ресурсы системы и администрировать.

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

Во всей книге различные ключевые слова и вообще текст, который может появиться на экране компьютера, набраны моноширинным шрифтом. Internet адреса и адреса электронной почты записываются курсивом, например caremysql@leonatkinson.com.

В книге рассмотрена программа MySQL версии 3.23 — ее самый последний ста бильный выпуск, доступный на момент написания книги. Возможно, к тому врем ени, когда вы будете читать книгу, версия 4.0 уже будет объявлена стабильной. Соответст венно, я старался помечать те места, где функции версии 3.23 могут подвергнуться изменениям.

MYSQL И РЕЛЯЦИОННАЯ МОДЕЛЬ ДАННЫХ этой части книги представлены основные концепции реляцион ных баз данных. Глава 1, "Введение в MySQL", содержит краткий обзор функциональных возможностей сервера баз данных. В гла ве 2, "Инсталляция MySQL", рассказывается об инсталляции программы MySQL. В главе 3, "Взаимодействие с MySQL", речь идет о программах, посредством которых осуществляется взаимодействие с сервером. Сюда входят утилиты командной строки, программы с графическим интер фейсом, а также приложения ODBC.

В главе 4, "Концепции баз данных", обсуждается эволюция баз данных и вводятся основные пон ятия. Из этой главы читатели узнают о том, ка кие модели баз данных предшествовали реляционной модели, а какие — придут ей на смену. В главе 5, "Реляционная модель", содержится описа ние реляционной модели и особенностей ее реализации в MySQL. В гла ве 6, "Язык SQL", рассматривается язык SQL, применяемый для манипу лирования данными в MySQL ибольшинстве других реляционных СУБД.

В главе 7, "Проектирование баз данных", рассказывается о проекти ровании баз данных, начиная от составления спецификации и заканчи вая построением диаграмм отношений между объектами. В главе 8, "Нормализация", обсуждаются особенности процесса нормализации, вследствие которого устраняется ненужная избыточность данных. В гла ве 9, "Транзакции и параллельные вычисления", рассматриваются во просы, связанные с одновременным доступом к базе данных множества пользователей. Излагаются методики устранения возникающих при этом проблем за счет транзакций и блокировок.

ВВЕДЕНИЕ В MYSQL В этой главе...

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

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

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

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

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

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

20 Глава 1. Введение в MySQL Давайте рассмотрим работу с базами данных на примере автосалона. Кен, торго вец автомобилями, владеет более чем 100 машинами. Естественно, Кен не может помнить детальное описание каждой из них, поэтому он решает создать базу данных.

В ней будет содержаться таблица с описанием каждого автомобиля, включая произво дителя, модель, год выпуска и ряд других параметров. В США у каждого автомобиля есть уникальныйидентификационный номер (VIN, Vehicle Identification Number). Он также занесен в таблицу, чтобы можно было различать модели с одинаковыми пара метрами.

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

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

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

MySQL, как и многие другие СУБД, функционирует по модели "клиент/сервер".

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

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

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

Есть и графические клиенты, например MySQL GUI. О них пойдет речь в главе 3, "Взаимодействие с MySQL".

Принципы использования баз данных Язык баз данных MySQL взаимодействует с базой данных на языке, называемом SQL (Structured Query Language — язык структурированных запросов). Одни люди произносят эту аб бревиатуру как "сиквел", другие, и я в том числе, — как "эскюэль". Последний вариант, похоже, нравится и разработчикам MySQL. Они заявляют, что название программы должно произноситься так: "май эскюэль".

Первое, что нужно сделать Кену, разобравшись с полями записей, — это создать таблицу. Данной цели служит команда, показанная в листинге 1.1.

CREATE TABLE car ( VIN VARCHAR(17) NOT NULL, Make VARCHAR(16) NOT NULL, Model VARCHAR(16) NOT NULL, ModelYear INT(16) NOT NULL, WholesalePrice FLOAT(6,2) NOT NULL, Color VARCHAR(S) NOT NULL, Mileage INT (11) NOT NULL, Comments TEXT, PRIMARY KEY(VIN) );

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

Первое поле называется VIN и его тип — VARCHAR, т.е. строка символов перемен ной длины. Максимальное число символов в строке — 17. Спецификатор NOT NULL говорит о том, что строка не может быть пустой, т.е. пользователь обязательно дол жен ввести в эту строку какие то данные.

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

Последняя строка списка представляет собой определение не поля, а индекса.

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

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

Запросы к базам данных На языке баз данных команды, обращающиеся к базе, называются инструкциями либо запросами. Инструкция это более общий термин. Запросом обычно считается такая инструкция, которая возвращает информацию (их еще называют запросами на выборку). Запрос можно рассматривать как вопрос, задаваемый базе данных, напри 22 Глава 1. Введение в MySQL мер: "Существуют ли записи, в которых цве т автомобиля указан белым?" Если такие записи имеются, они будут выданы в виде результатов запроса.

Запрос, показанный в листинге 1.2, представляет собой инструкцию SELECT. Она отбирает записи, соответствующие следующему критерию: поле Color записи содер жит строку ' W h i t e '. Н о возвращается не вся запись целиком, а лишь четыре поля:

VIN,Make,Model и ModelYear.

SELECT VIN, Make, Model, ModelYear FROM car WHERE Color = ' W h i t e ' ;

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

Второе поколение — это ассемблерные языки. Языки третьего поколения считаются высокоуровневыми, и на них работают большинство программистов. В качестве при мера можно привести С и РНР. Языки четвертого поколения еще на шаг приближены к естественным человеческим языкам.

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

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

В листинге 1.3 показана инструкция, которая добавляет запись в таблицу саr. По рядок значений соответствует порядку столбцов в таблице.

INSERT INTO car VALUES ( '12345678901234567', 'Plymouth', 'Roadrunner', 1969, 5500.00, 'Blue', 148123, 'Unrestored' );

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

Имея заполненную таблицу, Кен может производить в ней более предметный по иск. Например, если клиент спросит, есть ли в продаже автомобили "Форд" по цене меньше $10000, Кен сможет проверить это с помощью показанного ниже запроса (листинг 1.4).

Принципы использования баз данных SELECT * FROM car WHERE Make = 'Ford' AND WholesalePrice < 9 0 0 0. 0 0 ;

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

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

UPDATE car SET Color = 'White' WHERE VIN = ' 1 0 2 0 3 0 4 0 5 0 6 0 7 0 8 0 9 ' ;

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

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

DELETE FROM car WHERE VIN IN ( ' 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 ', ' 1 0 2 0 3 0 4 0 5 0 6 0 7 0 8 0 9 ' ) ;

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

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

В таблицах баз данных можно хранить не только скалярные значения, но и абст рактные указатели на другие таблицы. Кен находит выход: при своить каждому цвету 24 Глава 1. Введение в MySQL номер. Для этого нужно создать еще одну таблицу с двумя полями: в одном хранится код цвета, во втором — его название. В листинге 1.7 показана инструкция, создающая такую таблицу.

CREATE TABLE car_color ( ColorCode I N T ( 6 ) NOT NULL AUTO_INCREMENT, Name V A R C H A R ( 1 6 ), PRIMARY KEY(ColorCode) );

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

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

SELECT DISTINCT Color FROM car;

Ключевое слово DISTINCT заставляет MySQL удалить из таблицы результатов дуб лирующиеся значения. Теперь можно ввести серию запросов, вставляющих записи в таблицу car_color по одной за раз. Но это очень неуклюжий подход. Более эффек подчиненный за тивное решение — объединить инструкции INSERT и SELECT, создав прос. Результаты инструкции SELECT будут непосредственно вставляться в таблицу car_color (листинг 1.9).

INSERT INTO car_color (Name) SELECT DISTINCT Color FROM car;

После названия таблицы car_color в круглых скобках указан столбец, куда зано сятся данные (Name). Обычно в пропущенные поля вставляется специальная констан та NULL, обозначающая отсутствующее значение. Но поле ColorCode помечено спе цификатором NOT NULL, т.е. значения NULL в нем недопустимы. С другой стороны, в определении поля стоит ключевое слово AUTO_INCREMENT, а это означает, что в поле будут автоматически вставляться целые числа: в первой записи это будет число 1, во второй — 2 и т.д.

Принципы использования баз данных На следующем этапе требуется перестроить таблицу саr, модифицировав опреде ление столбца Color (листинг 1.10).

ALTER TABLE car CHANGE Color ColorCode INT(6) NOT NULL;

К сожалению, подобная модификация означает удаление всей информации из столбца Color. MySQL поменяет тип столбца, подставив во все поля значение 0. Да лее Кену придется ввести последовательность инструкций UPDATE, чтобы создать в таблице саr правильные ссылки на новую таблицу car_color.

После обновления таблицы саr в ней будут храниться не названия цветов, а их ко ды (в поле ColorCode). Белый цвет будет иметь, к примеру, код 1, а темно синий цвет — код 13. Запомнить соответствие между номерами и названиями цветов едва ли возможно. Необходимо, чтобы при выполнении запросов к таблице саr отобража лись именно названия цветов, а не их коды.

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

SELECT c a r. V I N, car_color.Name FROM car LEFT JOIN car_color ON car.ColorCode = car_color.ColorCode WHERE car.Make = ' P l y m o u t h ' ;

Возможные результаты такого запроса представлены в листинге 1.12.

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

26 Глава 1. В ведение в MySQL 1) Каждая запись таблицы саr сравнивается с каждой записью таблицы car_color.

2) Если поле ColorCode таблицы саr совпадает с полем ColorCode таблицы car_color (объединение по равенству), создается итоговая запись, состоящая из полей первой таблицы, к которым присоединены поля второй таблицы.

3) Для каждой записи таблицы саr, полю ColorCode которой не найдено соот ветствие в таблице car_color, создается итоговая запись, состоящая из полей первой таблицы, к которым вместо полей второй таблицы присоединены зна чения NULL (левое объединение).

4) Из объединенной таблицы отбираются записи, соответствующие условию WHERE.

5) В результаты запроса включаются поля, заданные в предложении SELECT.

Между таблицами саr и car_color нет отношения "один к одному", так как может быть несколько автомобилей одинакового цвета. Подробнее о сос тавлении такого рода объединений речь пойдет в последующих главах.

В листинге 1.11 несложно заметить одну особенность многотабличных запросов:

при ссылке на поля таблиц следует избегать неоднозначности. Например, обе таблицы содержат поле ColorCode. Чтобы явно указать, к какой таблице относится поле, нужно задать полное имя поля. Синтаксис полного имени таков: имя_ таблицы..имя_поля.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Зачем нужна программа MySQL Прежде чем рассматривать особенности использования программы MySQL, необ ходимо понять, почему есть смысл работать именно с ней, а не сOracle, к примеру, или PostgreSQL, или любой другой известной СУБД. Многие находят программу MySQL особенно привлекательной из за того, что ее легко изучить. Она также оказы вается достаточно гибкой в самых разных ситуациях. Там, где другие СУБД навязы вают одну модель данных, MySQL предлагает варианты.

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

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

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

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

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

Стоимость приобретения и эксплуатации MySQL очень невелика, как и у всякого открытого ПО. Программу можно бесплатно загрузить с нескольких Web узлов, к тому же она входит во многие дистрибутивы Linux. Существуют многочисленные теле конференции, посвященные вопросам поддержки пользователей MySQL. Сотрудники компании MySQL AB постоянно проверяют сообщения, поступающие в список рас сылки bugs@lists.mysql.com, и бесплатно устраняют возникающие проблемы. Кроме то го, за умеренную плату компания оказывает гарантированную, персональную под держку всем желающим.

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

Другим следствием открытости кода стала доступность MySQL для множества платформ. Эта программа может работать в большинстве версий UNIX, Linux, Win dows и даже в менее популярных операционных системах, например в OS/2.

История MySQL Однажды Микаэлю "Монти" Видениусу пришла в голову мысль добавить SQL модуль в качестве интерфейса к своей старой базе данных, которую он на протяже нии 15 лет вел в компании ТСХ DataKonsult AB. Он решил использовать для этой цели открытую реляционную СУБД mSQL, но ему не удалось заинтересовать ее автора, Дэ вида Хьюза (David Hughes). Тогда Монти начал создавать собственную реляционную СУБД, клиентский интерфейс которой был смоделирован на основе API функций mSQL, чтобы в новую систему можно было перенести приложения, написанные для mSQL. В планы Монти никогда не входило реализовывать стандарт языка SQL цели ком, но после того как он поделился исходными кодами программы с сообществом разработчиков, ответная реакция оказалась ошеломляющей.

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

Компанию ТСХ DataKonsult AB впоследствии переименовали в MySQL AB, и с его дня Монти является руководителем ее технического отдела. Эта шведская компания целиком посвятила себя разработке и поддержке программы MySQL. С самого начала компания стала прибыльной за счет оказания платной поддержки, предоставления платных консультаций и продажи лицензий на встроенную версию MySQL. Это пре красный пример того, что модель распространения программ с открытыми кодами является вполне жизнеспособной.

В июне 2000 г. программа MySQL стала доступна на условиях общей лицензии GNU (GNU General Public License, GPL). Это дает возможность каждому пользовате лю улучшать программу и передавать ее своим коллегам без каких либо лицензионных отчислений.

ИНСТАЛЛЯЦИЯ MYSQL В этой главе.

Загрузка дистрибутива Инсталляция с помощью менеджера пакетов RedHat Linux Инсталляция в Windows Инсталляция вручную Компиляция программы Предоставление привилегий ользователю базы данных необязательно знать, как инсталлировать MySQL.

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

Загрузка дистрибутива MySQL можно инсталлировать двумя способами: скомпилировав исходные коды программы или воспользовавшись предварительно скомпилированными двоичными файлами. Первый вариант допускает больше возможностей в плане конфигурации, но более продолжителен. Второй вариант удобнее, так как есть готовые дистрибутивы для многих операционных систем. На момент написания книги существовали версии MySQL для FreeBSD, HP UX, IBM AIX, Linux, MacOS X, SCO, SGI Irix, Solaris и многих вариантов Microsoft Windows.

Информацию обо всех дистрибутивах можно получить на Web узле www.mysql.com.

Там же публикуются последние новости о программе.

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

34 Глава 2. Инсталляция MySQL Современные операционные системы поддерживают стандарт POSIX. Если вы все же не уверены, проверьте в интерактивной документации, будет ли программа MySQL работать в данной версии операционной системы.

Выбор версии Команда разработчиков MySQL публикует тестовые и стабильные версии дистри бутивов отдельно. Информацию о статусе той или иной версии программы можно найти на Web узле. Эти же сведения закодированы в названии дистрибутива. На мо мент написания книги последняя стабильная версия имела номер 3.23.39.

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

Инсталляция с помощью менеджера пакетов RedHat Linux Если программа MySQL инсталлируется в Linux, то лучше всего воспользоваться мо дулем RPM (RedHat Packet Manager— менеджер пакетов RedHat). MySQL работает в Linux версий 2.0 и выше. Тестирование программы выполнялось в RedHat 6.2. В про грамме используется библиотека glibc, подключаемая статически. Если в системе уста новлена более старая версия библиотеки, программу придется скомпилировать заново.

Ниже приведено описание доступных модулей RPM.

• MySQL 3.23.39 1.1386.rpm Содержит все файлы, необходимые для запуска сервера MySQL, включая кли ентские программы.

• MySQL 3.23.39 l.src.rpm Содержит все исходные коды MySQL.

• MySQL bench 3.23.39 1.1386.rpm Содержит программы, предназначенные для тестирования производительно сти MySQL. Для запуска тестов необходим основной дистрибутив, а также ин терпретатор Perl.

• MySQL client 3.23.39 1.1386.rpm Содержит лишь клиентские программы.

• MySQL devel З.23.39 1.1386.rpm Содержит библиотеки и файлы заголовков, необходимые для компиляции кли ентских программ.

• MySQL shared 3.23.39 1.1386.rpm Содержит совместно используемые библиотеки для клиентских программ.

Опытные пользователи Linux знают, что флаг i служит программе rpm указани ем инсталлировать пакет. Таким образом, основной модуль MySQL инсталлируется следующей командой:

Инсталляция в Windows rpm i MySQL 3.23.39 1.1386.rpm В результате инсталляции в каталог /etc/rc.d добавляется файл сценария, со держащий команду запуска сервера MySQL после перезагрузки компьютера. Однако сам серверный демон запускается немедленно.

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

Можно также инсталлировать модуль RPM с исходными кодами программы. В этом случае воспользуйтесь опцией rebuild, чтобы подготовить бинарный модуль.

Обычно пользователи инсталлируют лишь модули MySQL 3.23.39 1.i386.rpm и MySQL client 3.23.39 l.i386.rpm. Для тех, ктособираются писать собственные клиентские программы, потребуется также модуль MySQL devel 3.23.39 1.i386.rpm.

Инсталляция в Windows Программа MySQL распространяется и в виде ZIP архива, содержащего набор ин сталляционных файлов. Перед извлечением файлов из архива создайте отдельный каталог, например с:\windows\Desktop\mysql, так как в архиве нет информации о путевых именах файлов.

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

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

Далее начнется собственно установка программы. Если инсталляционный каталог называется не с:\mysql, то поокончании инсталляции нужно будет дополнительно установить файл my. ini. Для этого перейдите в каталог программы и найдите файл my example.cnf. Скопируйте его в системный каталог (с:\windows или с:\winnt) и переименуйте в my. ini. Можно поступить и по другому: скопировать файл в корне вой раздел диска С: и назвать егоmy.cnf.

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

basedir = d:\mysql Если программа MySQL инсталлируется в Windows NT или Windows 2000, то, воз можно, ее нужно запустить в виде сервиса. Для этого требуется перейти в режим ко мандной строки и ввести следующую команду:

c:\mysql\bin\mysqld nt install 36 Глава 2. Инсталляция MySQL Название сервиса появится в окне сервисов панели управления, где можно будет настроить программу на автоматический запуск. Утилита winmysqladmin, входящая в Windows дистрибутив, позволяет автоматизировать множество задач, включая кон фигурацию.

Инсталляция вручную Если программа MySQL инсталлируется не в Linux или Windows либо еслиуслуги менеджера пакетов не нужны, можно инсталлировать двоичные файлы вручную. Со ответствующий дистрибутив распространяется в виде tar архива, сжатого с помо щью программыgzip.

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

Программе MySQL нельзя предоставлять права суперпользователя, и никакие ком промиссы здесь недопустимы. Можно, например, создать группу mysql и одноимен ного пользователя с помощью команд addgroup и adduser либо groupadd и useradd, в зависимости от версии UNIX. Ниже показан пример для RedHat Linux:

groupadd mysql useradd g mysql mysql Обычно начальным каталогом MySQL выбирают /usr/local/mysql. Послераспа ковки архива будет создан каталог, имя которого совпадает с именем дистрибутива, по этому удобнее всего просто создать символическую ссылку mysql. Вот как этоделается:

cd /usr/local tar xvfz mysql 3.23.35 pc linux gnu i686.tar.gz ln s mysql 3.23.35 pc linux gnu i686 mysql cd mysql Далее необходимо запустить сценарий mysql_install_db, находящийся в ката логе scripts. Он создаст базу данных с описанием существующих привилегий и тес товую базу данных.

Как правило, программа MySQL инсталлируется от имени пользователя root, по этому следующий шаг заключается в изменении владельца всех файлов программы:

chown R mysql / u s r / l o c a l / m y s q l chgrp R mysql /usr/local/mysql Теперь можно запустить демон MySQL с помощью сценария safe_mysqld. Сле дующая команда запускает демон от имени пользователя mysql:

/usr/local/mysql/bin/safe_mysqld user=mysql & Если нужно, чтобы сервер MySQL запускался всякий раз после перезагрузки компью тера, добавьте соответствующую строку в файл /etc/rc.d/rc. local или же скопи руйте сценарий mysql. server в каталог /etc/init.d и создайте правильные симво лические ссылки на него. В комментариях к файлу support files/mysql. server ре комендуются такие ссылки: /etc/rc3.d/S99mysqlи/etc/rcO.d/SOlmysql.

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

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

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

В главе 26, "Оптимизация", описан процесс перекомпиляции MySQL в целях по вышения производительности программы, поэтому мы не будем здесь вдаваться в тонкости компиляции.

Чтобы получить список всех опций конфигурирования, введите команду conf igure help.

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

Программа MySQL не ра ботает со списком пользователей, который есть у опера ционной системы. У нее своя таблица пользователей. Тем не менее если при работе с имеющимися клиентскими программами не ввести имя пользователя в процессе ре гистрации на сервере, будет подставлено системное имя пользователя.

Чтобы поменять пароль пользователя root, нужно запустить интерпретатор команд MySQL от имени суперпользователя. Данный интерпретатор представляет собой про грамму mysql,путь к которой должен быть указан в переменной среды PATH. Пользова телям Windows придется вводить путевое имя целиком, например c:\mysql\bin\ mysql. С помощью опции user задается имя для регистрации. В нашем случае ин терпретатор запускается с помощью такой команды:

mysql user=root mysql Вызвав интерпретатор, необходимо обновить две строки в таблице user, касаю щиеся пользователя root. Это делает следующая инструкция:

UPDATE user SET Password = P A S S W O R D ( ' s e c r e t ' ) WHERE User = ' r o o t ' ;

В ответ на эту инструкцию интерпретатор отобразит две модифицируемые запи си. Естественно, вместо строки 'secret' следует выбрать более надежный пароль.

Этот пароль должен применяться лишь в административных целях.

38 Глава 2. Инсталляция MySQL Далее нужно сообщить серверу об изменении привилегий. Для этого предназна чена такая инструкция:

FLUSH PRIVILEGES;

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

CREATE DATABASE leon;

GRANT ALL ON leon.* TO leon@'%' IDENTIFIED BY PASSWORD('secret');

Первая инструкция создает базу данных leon. Вторая инструкция создает учетную запись пользователя leon и предоставляет ему доступ к одноименной базе данных.

Пароль для доступа — 'secret'. Пользователь leon может подключаться к базе дан ных с любого компьютера, даже если он расположен в сети Internet.

ВЗАИМОДЕЙСТВИЕ С MYSQL В этой главе...

Клиент серверное взаимодействие средствами TCP/IP Утилиты командной строки Графические клиенты ODBC Web интерфейсы этой главе рассматриваются различные способы взаимодействия с сервером MySQL. Допускаются клиентские подключения по протоколу IP, а также через сокеты UNIX и именованные каналы. Имеется ряд готовых клиентов. Про стейшие из них— это утилиты командной строки, являющиеся частью проекта MySQL. Кроме них есть графические клиенты для различных операционных систем.

Те, кто работают в Windows, могут пользоваться специальным драйвером ODBC, a любой, у кого есть Web броузер, сможет получить в свое распоряжение Web клиенты.

Различные утилиты командной строки, входящие в состав MySQL, описаны в гла ве 14, "Утилиты командной строки".

Клиент серверное взаимодействие средствами TCP/IP Программа MySQL работает по пр отоколам TCP/IP, как и другие Internet сервисы. Соединения различаются по имени узла и номеру порта. По умолчанию ис пользуется порт 3306, но это конфигурируемый параметр.

В MySQL при меняется архитектура "клиент/сервер". Выделенный сервер способен принимать запросы от множества клиентов. На сервер ложится достаточно большая на грузка, тогда как клиенты представляют собой всего лишь программные оболочки.

Имя клиентского компьютера, с которого устанавливается соединение, преобра зуется в IP адрес: четыре числа, разделенных точками. Например, специальному име ни localhost соответствует адрес 127.0.0.1. Иногда такое преобразование выполня ется на основании записей локальных таблиц ядра, но чаще всего — с помощьюсерве ра DNS (Domain Name System — система доменных имен).

По умолчанию запрос на подключение поступает через порт 3306. Этот порт ПО СТОЯННО прослушивается сервером MySQL. При ответе на запрос сервер создает сеанс связи с клиентом. За сеансом закрепляются два порта: один будет использоваться для отправки данных, а другой — для их приема.

42 Глава 3. Взаимодействие с MySQL В ходе сеанса клиент посылает серверу команды, имеющие вид инструкций SQL.

В ответ на некоторые инструкции сервер возвращает данные, а клиент форматирует их для отображения на экране.

Утилиты командной строки В проект MySQL входит много специальных клиентов, а также один клиент общего назначения, называемый mysql. Именно с ним мы познакомимся в данной главе, а рас смотрение остальных клиентов отложим до главы 14, "Утилиты командной строки".

Если программа MySQL инсталлирована правильно, то путь к утилите mysql будет указан в переменной среды PATH. Напомним, что по умолчанию в UNIX утилита будет записана в каталог /usr/local/bin, а в Windows — в каталог с:\mysql\bin.

Если не заданы другие установки, утилитаmysql пытается подключиться к серверу MySQL на узле localhost (порт 3306), используя для доступа к базе данных регист рационное имя текущего пользователя. Как уже говорилось в предыдущей главе, стандартные привилегии доступа программы MySQL разрешают любому пользовате лю локального узла обращаться к серверу.

В листинге 3.1 показан сеанс работы с утилитой mysql. Строка приглашения ~> выдается интерпретатором bash.

> mysql test Welcome to the MySQL monitor. Commands end with ;

or \g.

Your MySQL connection id is 6 to server version: 3.23. Type 'help;

' or '\h' for help. Type '\c' to clear the buffer mysql> create table book ( > title varchar(32), > author varchar(64) > );

Query OK, 0 rows affected (0.03 sec) mysql> insert into book values ('Core MySQL', 'Leon Atkinson');

Query OK, 1 row affected (0.07 sec) mysql> select * from book;

I title | author | I Core MySQL | Leon Atkinson I 1 row in set (0.02 sec) exit Bye ~> Графические клиенты Для подключения к удаленному серверу необходимо указать его адрес с помощью опции Альтернативный порт задается опцией имя пользователя — опцией пароль — опцией Значение опции указывается после знака равенства (листинг ~> Enter password:

Welcome to the MySQL monitor. Commands end with or \g.

Your MySQL connection id is 5 to server version: 3.23. Type or for help. Type to clear the buffer mysql Последним параметром утилиты mysql является имя базы данных. В листинге 3. утилита сразу загрузила базу test. Это позволило не вводить команду use.

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

~> mysqladmin root create Графические клиенты Команда разработчиков MySQL ведет список программного обеспечения, напи санного для MySQL. Его можно найти по адресу www.mysql.com/dffwnloads/contrib.htmL Многие из приложений являются но некоторые вполне под ходят для общего взаимодействия с базами данных.

Уже упоминавшийся чле н команды разработчиков, отвечает за сопровождение программы MySQL GUI. Существуют версии для Linux, Win32, и Solaris, которые можно найти по адресу На момент написания книги программа проходила стадию Рис. 3.1 иллюстрирует работу программы, подключенной к тестовой базе данных.

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

Программа MySQL Maker (рис. 3.2) является условно бесплатным приложением, в котором база данных представлена в виде дерева, что упрощает навигацию по ней.

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

44 Глава 3. Взаимодействие с MySQL Рис. Программа MySQL GUI в Windows Рис. З.2. Программа MySQL Maker ODBC ODBC Драйверы ODBC доступн не только в Windows, но также в Linux и прочих разно ы видностях UNIX. Конечно, производительность будет выше при работе с утилитами командной строки, использующими "родные" функции MySQL, но многие приложе ния Windows ориентируются на более универсальный интерфейс ODBC.

В некоторые версии пакета Microsoft Office входит программа Microsoft Query, которая позволяет взаимодействовать с любым источником данных ODBC (рис. 3.3). Это не самое удобное средство для ввода запросов, но и оно может оказаться полезным. Драйвер ODBC для программы MySQL доступен по адресу Рис. 3.3. Программа MS Query Web интерфейсы К серверу MySQL м ожно обращаться и через Существует несколько Web клиентов, среди которых один из (рис. 3.4). Эта программа мне особенно нравится, так как она написана на самом популярном языке созда Клиент phpMyAdmin доступен по адресу 46 Глава 3. Взаимодействие с MySQL Рис. 3.4. Программа КОНЦЕПЦИИ БАЗ ДАННЫХ В этой главе...

История Терминология СУБД Системы управления файлами Иерархические базы данных Сетевые базы данных Реляционные базы данных Объектно ориентированные базы данных Объектно реляционные базы данных этой главе рассказывается об истории баз данных и их основных концепциях.

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

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

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

Столкнувшись с задачей координации заказов на миллионы деталей, компания Rockwell в сотрудничестве с IBM в 1968 г. разработала автоматизированную систему заказов. Названная IMS (Information Management System — система управления ин формацией), она заложила основу концепции СУБД.

Ключевым новшеством IMS было разделение данных и функций деловой логики.

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

Еще одним изобретением стал язык (Data Это был специализи рованный язык составления нерегламентированных запросов к базе данных. Его по 50 Глава 4. Концепции баз данных явление сделало ненужным дорогостоящее программирование на таких языках, как COBOL и FORTRAN, популярных в то время.

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

В 1971 г. состоялась конференция по языкам обработки данных (Conference on Data Systems Languages, в задачу которой входила разработка стандартов баз данных. Ранее эта конференция уже стандартизировала язык COBOL. Новый стандарт был расширен на иерархическую модель данных, применяемую в IMS. Ре зультатом стало появление сетевой модели В сетевой модели любая запись может участвовать в нескольких отношениях пре док/потомок. Это позволяло обходить целый ряд ограничений иерархической моде ли. Разработкой сетевой модели занимался Чарльз (Charles в то время руководитель проекта IDS (Integrated Data System — интегрированная система обработки данных) в компании General Electric. Он же изобрел "диаграммы описывающие сетевые базы данных. За свой труд в 1973 г. Бейчман получил на граду Тьюринга.

Тем временем научный сотрудник компании IBM доктор Эдгар Кодд (Edgar работал над эпохальным документом для Ассоциации производителей вычислитель ной техники (Association for Computing Machinery, ACM). В июне 1970 г. этот доку мент был опубликован в названием "Реляционная модель для больших банков совместно используемых данных" ("A Relational Model of Data for Large Shared Data Banks"). Этот документ в корне изменил теорию баз данных и принес доктору награду Тьюринга в 1981 году.

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

В результате появились две СУБД: System R компании IBM и Ingres Калифорний ского университета в Беркли. В обеих был реализован реляционный модуль и язык запросов. Последний в СУБД System R первоначально назывался SEQUEL (Structured English Query структурированный английский язык запросов). Позднее появилось название SQL (Structured Query Language). В организация ANSI опубликовала официальный стандарт языка SQL.

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

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

Строки таблиц могут быть связаны друг с другом одним из трех способов. Про стейшее отношение — "один к одному". В этом случае строка первой таблицы соответ ствует одной единственной строке второй таблицы. На диаграммах такое отношение выражается записью 1:1.

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

Наконец, при отношении "многие ко многим" строки первой таблицы могут быть связаны с произвольным числом строк во второй таблице. Такое отношение записы вается как N:M.

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

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

Язык четвертого поколения позволяет создавать схемы— точные определения данных и отношений между ними. Схема хранится как часть базы Данных и может быть изменена без ущерба для данных.

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

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

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

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

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

Фамилия Дата рождения Позиция Tejada 1976 05 25 Шорт стоп Giambi 1971 01 08 Первая база Hudson 1975 07 14 Питчер Seanz 1970 10 08 Лучший отбивающий У каждого столбца есть название и тип. Типы данных будутрассматриваться в гла ве 11, "Типы столбцов и индексов", а пока лишь скажем, что базовыми типами счита ются строковый, числовой и дата/время. В табл. 5.1 столбцы "Фамилия" и "Позиция" имеют строковый тип, а в столбце "Дата рождения" находятся значения даты.

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

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

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

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

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

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

Давайте расширим таблицу бейсболистов, добавив в нее столбец "Команда" (табл. 5.2).

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

Фамилия Дата рождения Позиция Команда Tejada 1976 05 25 Шорт стоп Giambi 1971 01 08 Первая база Hudson 1975 07 14 Питчер Seanz 1970 10 08 Лучший отбивающий Bonds 1964 07 24 Внешнее поле Giambi 1974 09 30 Внешнее поле Snow 1968 02 26 Первая база Столбец "Идентификатор" в табл. 5.3 является первичным ключом. Значение первич ного ключа уникальным образом идентифицирует каждую строку. Только значения пер вичного ключа могут встречаться в столбце "Команда" табл. 5.2. Последний, в свою оче редь, называется внешним ключом, так как его значенияберутся из внешней таблицы.

Идентификатор Название 1 Oakland Athletics 2 San Francisco Giants Повторять названия команд в первой таблице нежелательно, поскольку это пря мой путь к нарушению целостности. Ничто не мешает пользователю добавить строку, в которой имя команды будет записано неправильно. Как следствие, в последующих запросах на выборку будет отображаться неверное число команд.

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

Подобная задача возлагается на приложения.

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

Пока что речь шла только о первичных и внешних ключах. Но помимо них есть еще несколько типов ключей.

Суперключ— это совокупность атрибутов, уникальным образом идентифицирую щих каждую запись. Например, в табл. 5.2 в качестве суперключа можно использовать объединение всех атрибутов или же, к примеру, столбцов "Фамилия" и "Дата рожде ния". А вот сочетание столбцов "Фамилия" и "Команда" не подойдет, так как в коман де "Oakland Athletics" есть два игрока однофамильца.

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

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

Первичный ключ является важным средством обеспечения целостности данных.

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

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

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

В реляционной модели все ключи, кроме первичного, считаются вторичными.

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

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

Отношение "один ко многим" (1:N) является естественным типом отношений в ре ляционной базе данных. Оно реализуется с помощью внешних ключей, рассмотрен ных выше. При отношении 1:N любой строке первой таблицы может соответствовать несколько записей второй таблицы. Если проанализировать связь в противополож ном отношении, то окажется, что строке второй таблицы соответствует всего одна запись первой таблицы.

В идеально спроектированной реляционной базе данных отношение "один к одно му" (1:1) не нужно. Если каждой строке одной таблицы соответствует одна строка дру гой таблицы, то это обычно свидетельствует о том, что обе таблицы нужно объеди нить в единое целое. Исключение из правила— необычный случай, когда число столбцов таблицы превышает предел, установленный в СУБД. В MySQL этот предел равен 3000, так что маловероятно, чтобы кому то пришло в голову его превысить.

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

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

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

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

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

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

64 Глава 5. Реляционная модель Имя Игрок Позиция Название Рис. 5.1. Формирование отношения M:N посредством промежуточной таблицы Реляционные операции Как уже упоминалось, реляционная модель основана на реляционной алгебре док тора Кодда. В свою очередь, за реляционной алгеброй стоит теория множеств, в ко торой определен целый ряд операций над множествами. Как писал сам доктор Кодд, для реляционной модели представляют интерес только те операции, результатом ко торых являются множества. Отсюда имеем восемь простейших операций: выборка, проекция, пересечение, сложение, вычитание, умножение, деление и переименова ние. На их основе строятся более сложные операции, называемые объединениями. В языке SQL большинство перечисленных операций реализуется с помощью инструк ции SELECT.

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

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

Фамилия Дата рождения Позиция Команда Giambi 1971 01 08 Первая база Seanz 1970 10 08 Лучший отбивающий Bonds 1964 07 24 Внешнее поле Giambi 1974 09 30 Вне шнее поле Snow 1968 02 26 Первая база Реляционные операции Операция проекции возвращает все записи исходной таблицы, но, возможно, не все столбцы. Это, по сути, фильтрация столбцов. Предположим, требуется получить список фамилий бейсболистов. На рис. 5.2 изображена исходная таблица и результат ее проекции. Результирующая таблица содержит шесть фамилий, а не семь, так как дубликаты недопустимы.

Имя День рождения Позиция Команда Имя Рис. 5.2. Проекция фамилий игроков Операция пересечения выполняется над двумя таблицами идентичной структуры.

В результате возвращаются только те записи, которые встречаются в обеих исходных таблицах. Предположим, нам необходимо узнать, какие игроки принимали участие в матче "Всех звезд" как в 1999, так и в 2000 году. Результат соответствующей операции пересечения представлен на рис. 5.3.

Матч "Всех звезд" 1999 г. Матч "Всех звезд" 2000 г. Пересечение Рис. 5.З. Операция пересечения Операция сложения также выполняется над двумя таблицами идентичной структу ры. При этом в результирующую таблицу попадают все записи исходных таблиц. На пример, с помощью данной операции можно получить объединенный список участ ников матчей "Всех звезд" в 1999 и 2000 году (рис. 5.4). Результирующая таблица будет содержать 16 строк, а не 18, поскольку два игрока принимали участие в обоих матчах и их имена повторяются.

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

66 Глава 5. Реляционная модель Рис. 5.4. Операция сложения Рис. 5.5. Операция вычитания Операция умножения объединяет каждую строку первой таблицы с каждой строкой второй таблицы. Эта операцию еще называют декартовым произведением. Количество строк результирующей таблицы равно произведению числа строк исходных таблиц.

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

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

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

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

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

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

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

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

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

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

Рассмотрим внутреннее объединение, схема которого представлена на рис. 5.8.

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

по столбцу "Номер команды" Рис. 5.8. Внутреннее объединение Внешнее объединение является расширением внутреннего. Существуют три типа внешних объединений: левое, правое и полное. В левое внешнее объединение включаются все строки первой таблицы, в правое внешнее объединение— все строки второй таблицы, а в полное внешнее объединение— все строки обеих исходных таблиц. Но внешнее объе динение — это не то жесамое, что и операция произведения. Строки, которым не на ходится соответствия в левой или правой таблице, дополняются значениями NULL.

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

Является ли MySQL настоящей реляционной СУБД Рис. 5.9. Левое внешнее объединение Правое внешнее объединение строится аналогично левому, только по отношению к строкам правой таблицы. Некоторые СУБД не поддерживают данный тип объеди нения, поскольку его всегда можно преобразовать в левое внешнее объединение. Тем не менее в MySQL такая поддержка имеется.

Полное внешнее объединение реализуется так, как если бы правое и левое объе динения выполнялись одновременно. Поддержка данного типа объединений отсутст вует в MySQL версии 3.23, но должна появиться в версии 4.1.

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

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

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

MySQL 3.23 не выполняет проверку внешних ключей. Не поддерживаются также некоторые реляционные операции, например полное внешнее объединение и деле ние. Тем не менее MySQL является настоящей реляционной СУБД.

ЯЗЫК SQL В этой главе...

SQL — язык четвертого поколения Определение данных Вставка записей Обновление записей Удаление записей Запросы Объединения Упорядочение результатов запроса Группировка результатов запроса Ограничение числа возвращаемых записей Изменение определения таблицы QL— это язык взаимодействия с базами данных, применяемый в большинстве реляционных СУБД, включая MySQL. Основной стандарт языка был принят в 1992 г. и называется SQL2 или SQL 92. Продолжается также работа над наиболее современным стандартом SQL3.

В MySQL команды SQL вводятся с помощью одного из клиентов, описанных в гла ве 3, "Взаимодействие с MySQL". В настоящей же главе будут рассмотрены основные возможности языка. Подробное знакомство со всеми поддерживаемыми инструкция ми SQL произойдет в главе 13, "Инструкции SQL".

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

Второе поколение — это ассемблерные языки. Языки третьего поколения считаются высокоуровневыми, и на них работают большинство программистов.

Одна из задач SQL — быть понятным непрограммистам. Поэтому запросы читают ся как обычные предложения. Словарь SQL относительно невелик, а его команды яв ляются словами английского языка. Таким образом, SQL несложно изучить.

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

Часто для удобства восприятия инструкции SQL записывают в нескольких стро ках, что допускается синтаксическим анализатором. В программе mysql конец инст рукции помечается специальной командой. Проще всего ввести точку с запятой (;

), но можно также на брать \д или до. Все эти команды не являются частью языка, они необходимы лишь интерпретатору mysql.

72 Глава 6. Язык SQL Определение данных Для определения структуры базы данных предназначена команда CREATE. Если ба за данных еще не была создана посредством утилиты mysqladmin, то это можно сде лать с помощью инструкции CREATE DATABASE. Единственным ее аргументом явля ется имя базы данных (она создается пустой). Естественно, если база с таким именем уже существует, будет выдано сообщение об ошибке. В листинге 6.1 демонстрируется создание базы store.

CREATE DATABASE store Инструкция DROP DATABASE удаляет базу данных вместе со всеми таблицами. Это необратимое действие, так что будьте осторожны.

Таблица создается с помощью инструкции CREATE TABLE. Ей нужно указать не только имя таблицы, но и ее полно е определение, состоящее из определений отдель ных полей.

Имя таблицы может быть полным либо неполным. К полному имени добавляется имя базы данных, например store.item. Точно так же полное имя столбца включает в себя имена базы данных и таблицы: store.item.price. Но гораздо удобнее назна чить стандартную базу данных, тогда отпадет необходимость в полных именах. Для этого предназначена инструкция USE. Имя базы данных можно задать и при вызове программы mysql. Подробнее об этом рассказывается в главе 14, "Утилиты команд ной строки".

Общий формат инструкции CREATE TABLE таков:

CREATE TABLE имя_таблицы (определение столбца,...) Определение столбца включает в себя имя столбца и спецификацию его типа.

Таблица, создаваемая в листинге 6.2, содержит четыре столбца: ID, Name, Price и Description.

CREATE TABLE item ( ID INT(6) NOT NULL AUTO_INCREMENT, Name CHAR(32) NOT NULL, Price DECIMAL(4,2) NOT NULL, Description CHAR(255) DEFAULT 'No Description', PRIMARY KEY(ID), KEY (Name) Определение данных Определение существующей таблицы можно узнать с помощью инструкции DESCRIBE (сокращенный вариант— DESC). В листинге 6.3 показан результат, выда ваемый этой инструкцией в случае таблицы item.

Аналогичную информацию выдает инструкция SHOW COLUMNS, общий формат ко торой таков:

SHOW COLUMNS FROM имя_таблицы Существует много разных инструкций семейства SHOW. Например, инструкция SHOW DATABASES выдает список всех баз данных, доступных текущему пользователю.

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

Столбец ID созданной выше таблицы item содержит целые числа в диапазоне от О до 999999. Значения NULL в нем недопустимы, на что указывает спецификатор NOT NULL. Кроме того, столбец работает в режиме счетчика (флаг AUTO_INCREMENT). Это означает, что при вставке в таблицу новой строки значение ее столбца ID будет вы числено автоматически на основании значения в предыдущей строке. Нумерация на чинается с единицы. Это хороший способ присвоения записям уникальных иденти фикаторов.

У читателей может возникнуть вопрос: почему MySQL сообщает, что по умолча нию значение столбца ID равно NULL? Ведь в инструкции CREATE TABLE стандартное значение не было задано, более того, явно указано, что столбец не может содержать значения NULL. На самом деле значение по умолчанию есть у каждого столбца. Если оно не указано, MySQL сделает выбор самостоятельно. В случае столбцов счетчиков NULL — это хороший выбор, так как при вставке самой первой строки в столбец будет записано значение 1.

Столбец Name содержит строку из 32 х символов. У каждого элемента таблицы должно быть имя, поэтому столбец помечен спецификатором NOT NULL.

Столбец Price хранит значение стоимости в десятичном формате: четыре цифры до запятой и две — после. Тип с плавающей запятой в данном случае не подходит, по тому что он не обеспечивает точность вычислений.

Столбец Description представляет собой текстовое поле максимальной длины:

255 символов. Он может принимать значения NULL, но благодаря наличию предло жения DEFAULT они будут преобразовываться в строку ' No Description '.

74 Глава 6. Язык SQL В конце инструкции CREATE TABLE определяются первичный и вторичный клю чи. MySQL проследит, чтобы в столбец ID помещались уникальные значения, а кроме того, для столбцов ID и Name будут созданы индексы, что ускорит поиск в них.

На имена баз данных, таблиц и столбцов накладывается ряд ограничений. Если за глянуть "за кулисы", то окажется, что базы данных представляются в виде каталогов файловой системы сервера, а таблицы являются файлами этих каталогов. Из практи ческих соображений длина имен ограничена 64 мя символами. Если в операционной системе, где установлена СУБД MySQL, в именах файлов учитывается регистр, то имена баз данных и таблиц в MySQL тоже будут чувствительными к регистру. Имена столбцов всегда не зависят от регистра.

Все имена могут состоять из букв, чисел, знаков подчеркивания (_) и символов доллара ($). Из соображений удобочитаемости желательно, чтобы имена начинались с буквы.

Вставка записей Инструкция INSERT добавляет строку в таблицу. Общий формат ее таков:

INSERT INTO имя_таблицы VALUES (значение,... ) Необходимо задать значения всех столбцов, причем в том порядке, в котором оп ределения столбцов указывались в инструкции CREATE TABLE. В главе 13, "Инструкции SQL", будут описаны разновидности инструкции INSERT, позволяющие указывать подмножество столбцов, а также вставлять в таблицу записи, возвращаемые подчиненной инструкцией SELECT.

Инструкция, показанная в листинге 6.4, создает новую строку в таблице item. В столбец ID будет записано ближайшее доступное число. Обратите внимание на то, что строковые значения берутся в одинарные кавычки.

INSERT INTO item VALUES( NULL, 'toothbrush', 1.25, 'A deluxe toothbrush' ) Обновление записей Для изменения полей существующих записей предназначена инструкция UPDATE, общий формат которой следующий:

UPDATE имя_таблицы SET выражение,...

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

Предложение WHERE задает правило отбора обновляемых строк. Если оно отсутству ет, изменению подвергнутся все строки таблицы. Инструкция, показанная в листин ге 6.5, обновляет значения столбцов Name и Price элемента с идентификатором 1. Дру гие строки остаются нетронутыми.

UPDATE item SET Name='Toothbrush', Price=1. WHERE ID= Условия отбора строк необходимо тщательно проверять, чтобы по ошибке не уда лить тысячу строк вместо одной. На всякий случай можно воспользоваться опцией safe updates программы mysql, указав в ней максимальное число удаляемых строк. Но еще лучше перед выполнением инструкции UPDATE ввести эквивалентную инструкцию SELECT, чтобы проверить, какие записи соответствуют условию отбора.

Удаление записей Инструкция DELETE удаляет строку из таблицы. Общий формат инструкции таков:

DELETE FROM имя_таблицы условие_отбора WHERE Если предложение WHERE отсутствует, будут удалены все строки таблицы. В лис тинге 6.6 демонстрируется удаление отдельной строки.

DELETE FROM item WHERE ID= Запросы Инструкция SELECT извлекает строки из одной или нескольких таблиц. С ее помо щью можно реализовать большинство реляционных операций, описанных в главе 5, "Реляционная модель". Формат этой инструкции сложнее, чем у других инструкций:

имя_столбца,...

SELECT имя_таблицы,...

FROM WHERE условие_отбора GROUP BY имя_столбца,...

ORDER BY имя_столбца,...

LIMIT лимит 76 Глава 6. Язык SQL Правда, многие предложения инструкции являются необязательными.

SELECT * FROM item В листинге 6.7 представлен простейший вариант инструкции SELECT. В данном случае отображаются все столбцы всех строк таблицы item. Символ звездочки (*) за меняет собой имена всех столбцов. Запрос, показанный в листинге 6.8, возвращает тот же результат, но имена столбцов на этот раз перечислены явно. Порядок имен важен, так как именно в этом порядке столбцы войдут в результирующую таблицу.

SELECT ID, Name, Price, Description FROM item Если указаны не все столбцы, операция выборки превратится в операцию проек ции (см. главу 5, "Р еляционная модель"). Дополнительный фильтр записей задается с помощью предложения WHERE (листинг 6.9).

SELECT ID, Name FROM item WHERE ID > 2 AND ID < Показанное в листинге 6.9 предложение WHERE состоит из двух операций сравне ния. В условиях отбора могут присутствовать многие операторы языков третьего по коления, а также целый ряд встроенных функций. Обо всех них пойдет речь в гла вах 10, "Типы данных, переменные и выражения", и 12, " строенные функции".

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

mysql> SELECT N O W ( ) ;

NOW() 2001 04 13 11:54: 1 row in set ( 0. 0 0 sec) Объединения Объединения Объединение создается путем указания нескольких таблиц в предложении FROM.

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

Для примера создадим вторую таблицу it em_option, которая будет участвовать в операциях объединения с таблицей item. В листинге 6.11 показаны инструкции, соз дающие обе таблицы и заносящие в них данные. В таблице item_option хранятся опи сания возможных вариантов изготовления товаров, перечисленных в таблице item.

CREATE TABLE item ( I D I N T ( 6 ) NOT NULL AUTO_INCREMENT, Name CHAR(32) NOT NULL, Price DECIMAL(4,2) NOT NULL, Description CHAR(255) DEFAULT 'No Description', PRIMARY K E Y ( I D ), KEY (Name) );

INSERT INTO item VALUES (1, 'Toothbrush', 1.25, N U L L ) ;

INSERT INTO item VALUES (2, 'Comb', 2. 5 0, N U L L ) ;

INSERT INTO item VALUES (3, 'Brush', 3.00, N U L L ) ;

INSERT INTO item VALUES (4, 'Toothpaste', 0.75, N U L L ) ;

CREATE TABLE item_option ( I D I N T ( 6 ) NOT N U L L AUTO_INCREMENT, Item I N T ( 6 ) NOT NULL, Name CHAR(32) NOT NULL, PRIMARY K E Y ( I D ), FOREIGN KEY(Item) REFERENCES I t e m ( I D ) );

INSERT INTO item_pption VALUES (1, 2, 'Red P l a s t i c ' ) ;

INSERT INTO item_option VALUES (2, 2, 'Blue P l a s t i c 1 ) ;

Чтобы создать внутреннее объединение таблиц, достаточно указать их имена в предложении FROM инструкции SELECT. При отсутствии предложения WHERE полу чится самый общий вариант такого объединения — декартово произведение, в кото ром каждая строка первой таблицы объединена с каждой строкой второй таблицы.

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

78 Глава 6. Язык SQL В листинге 6.12 выполняется объединение двух таблиц по равенству столбцов item. ID и item_option. Item, т.е. для каждой строки первой таблицы находится со ответствующий элемент второй таблицы. Из объединенной таблицы отбираются три столбца: с названием и ценой товара, а также с названием варианта его изготовления.

В листинге 6.12 содержатся примеры псевдонимов таблиц и столбцов. Третий столбец результатов запроса называется так же, как и первый, поэтому во избежание путаницы он переименуется в Option Name. На псевдонимы столбцов можно ссы латься в предложениях GROUP BY и ORDER BY, рассматриваемых ниже.

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

В листинге 6.13 показано то же самое внутреннее объединение, что и в листин ге 6.12, но на этот раз в предложении FROM присутствует операция INNER JOIN. В по добном случае условие отбора переносится из предложения WHERE в предложение ON.

SELECT i.Name, i.Price, o.Name AS 'Option Name' FROM item i INNER JOIN item_option о ON i.ID = o.Item Иногда внутреннее объединение не дает нужных результатов. Оно формирует пары только тех строк, между которыми найдено соответствие. Все остальные строки исклю чаются. Чтобы включить в полученные выше результаты названия все товаров, нам по требуется выполнить внешнее объединение, в данном случае левое (листинг 6.14).

Упорядочение результатов запроса mysql> SELECT i.Name, i.Price, o.Name AS 'Option Name' > FROM item i LEFT JOIN item_option о 5 rows in set ( 0. 0 0 sec) Как видите, отображаются пять строк. В объединенную таблицу вошли все строки таблицы item, даже те, которым не найдено соответствие. Строка, не имеющая "пары", дополняется значениями NULL.

Упорядочение результатов запроса Предложение ORDER BY содержит имена столбцов, по которым осуществляется сортировка результатов запроса. На столбец можно сослаться по имени (краткому или полному), псевдониму или порядков ому номеру в предложении SELECT (нумера ция столбцов начинается с единицы). В листинге 6.15 таблица результатов сортирует ся по названию товара.

SELECT i.Name, i.Price, o.Name AS 'Option Name' FROM item i LEFT JOIN item_option о O N i. I D = o.Item ORDER BY i.Name Предложение ORDER BY может содержать не одно имя, а целый список. Столбцы перечисляются в порядке убывания приоритетов. В первую очередь записи сортиру ются по столбцу, указанному первым. Если возникает "конфликт" (две или более строк имеют одинаковое значение в данном поле), проверяется второй столбец, за тем третий и т.д. По умолчанию сортировка всех столбцов ведется по возрастанию.

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

80 Глава 6. Язык SQL SELECT i.Name, i.Price, o.Name AS 'Option Name' FROM item i LEFT JOIN item_option о ON i.ID = o.Item ORDER BY i.Price DESC Группировка результатов запроса Предложение GROUP BY позволяет группировать записи, вошедшие в результаты запроса, с тем чтобы над ними можно было выполнять статистические функции. Все элементы списка возвращаемых столбцов должны иметь одно значение для каждой группы строк. Столбцы, указываемые в предложении GROUP BY, называются столбца ми группировки. Они по определению имеют одинаковое значение во всех строках группы. В предложении SELECT запроса с группировкой разрешается указывать толь ко столбцы группировки истатистические функции, а также выражения с ними.

В листинге 6.17 представлен запрос, в котором записи объединенной таблицы группируются по названию товара и его цене. В принципе, достаточно выполнять группировку только по полю Name, но в этом случае столбец Price нельзя было бы включить в результаты запроса.

mysql> SELECT i.Name, i.Price, COUNT(o.ID) AS 'Options' > FROM item i LEFT JOIN item_option о > ON i.ID = o.Item > GROUP BY i.Name, i.Price > ORDER BY Options;

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

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

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

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

SELECT i.Name, i.Price, count(о.ID) AS 'Options' FROM item i LEFT JOIN itemoption о O N i. I D =o.Item GROUP BY i.Name, i.Price ORDER BY Options DESC, Name LIMIT Изменение определения таблицы Инструкция ALTER TABLE позволяет менять определение табл ицы. Можно добав лять, удалять и модифицировать определения столбцов, а также добавлять и удалять индексы. Допускается переименование таблицы.

Инструкция, показанная в листинге 6.19, добавляет в таблицу item столбец Inventory, в которомбудет указываться количество товара на складе. После выпол нения запроса каждая запись таблицы будет содержать в поле Inventory значение 0.

ALTER TABLE item ADD COLUMN Inventory INT (4) NOT NULL DEFAULT ПРОЕКТИРОВАНИЕ БАЗ ДАННЫХ В этой главе...

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

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

После этапа проектирования приступают к реализации базы данных. Здесь важно правильно выбрать типы столбцов таблиц.

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

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

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

84 Глава 7. Проектирование баз данных Описанная ситуация встречается повсеместно. Будем справедливы: она не обяза тельно означает провал. Зачастую на каждом следующем витке процесса проектирова ния разработчики все яснее начинают представлять себе требования к системе, вслед ствие чего проект "стабилизируется". Но главной проблемой подобного эксперимента торского подхода остается риск того, что проект никогда не стабилизируется.

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

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

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

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

Pages:     || 2 | 3 | 4 | 5 |   ...   | 7 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.