web - tec / PHP 5 для начинающи

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

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

Теперь в таблице нет дублирующейся информации, таблица представляет только связанную информацию (информацию об игроках). Что можно сказать по поводу уникального идентификатора? Каждая запись должна иметь (по крайней мере, одно) уникальное поле, иначе говоря, поле, в котором нет повторяющихся значений. Ввиду исключительной природы данного поля каждое значение в нем уникально идентифи+ цирует каждую запись таблицы. Поле, которое используется для идентификации за+ писей, называется первичным ключом (primary key). В каждой таблице допускается толь+ ко один первичный ключ.

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

384 Глава 9

Можно было бы добавить уникальный ключ, который присваивал бы каждой запи+ си уникальный номер, но для начала стоит внимательно изучить информацию в таб+ лице игроков. В каждом виде спорта номер игрока должен быть уникальным, таким образом, известно, что все значения в поле Player_Id уникальны. Кроме этого зна+ чения в поле Nickname также уникальны, поскольку в определенный момент времени у каждого игрока есть только одно прозвище. Какое из двух этих полей выбрать? По+ скольку прозвища могут изменяться в зависимости от ‘‘эффективности’’ игрока, поле Player_Id является наиболее подходящим вариантом для первичного ключа.

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

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

Вторая нормальная форма (2NF)

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

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

Обе таблицы содержат общее поле (Player_Id), значения в котором совпадают в двух таблицах, поэтому можно связать эти таблицы вместе. Фактически для этого внешний ключ не требуется, однако использование внешних ключей определенно имеет свои преимущества (более глубокое их обсуждение представлено на странице www.mysql.com/doc/en/ANSI_diff_Foreign_Keys.html). Это означает, что записи

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

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

Третья нормальная форма (3NF)

Цель третьей нормальной формы ++++++ устранить поля, которые не зависят от пер+ вичного ключа.

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

386 Глава 9

388 Глава 9

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

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

Рассмотрим случай, когда приходится выполнять поиск одновременно в несколь+ ких таблицах. Это тот случай, когда можно получить реальный выигрыш от использо+ вания индекса. Поиск возможных совпадений в объединенных таблицах без индек+ сов ++++++ очень плохая идея. СУБД должна будет проверить все возможные комбинации строк в одной таблице со строками в другой. Обработка двух таблиц по 500 записей в каждой потребовала бы 500×500=250 000 комбинаций. Индексирование значительно ускоряет поиск. СУБД проверяет индекс первой таблицы в поисках позиции совпаде+ ний с критериями первой части запроса, а затем, используя данный индекс для вто+ рой таблицы, ищет в ней совпадения со второй частью запроса. Иными словами, ре+ левантные записи выбираются непосредственно.

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

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

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

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

Запросы

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

390 Глава 9

INSERT: вставляет данные в базу;

REPLACE: заменяет данные в базе; если же такая запись в таблице существует, то в нее будут внесены новые данные;

UPDATE: обновляет данные в таблице.

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

CREATE: создает базу данных, таблицу или индекс;

ALTER: модифицирует структуру таблицы;

DROP: уничтожает базу данных или таблицу.

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

mysql> SELECT поле1, поле2, ... , полеn FROM имя_таблицы WHERE условие;

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

mysql> SELECT last_name, first_name -> FROM user

-> WHERE first_name = 'John'

Рассмотрим подробнее предложения FROM, WHERE и ORDER BY данного запроса. Запрос возвращает все записи из таблицы user, в которых значением поля first_name является строка John. Если такая таблица и записи, удовлетворяющие данному запросу, существуют, то результатом запроса будет следующее:

Simpleton John

Smith John

Thomas John

Рассмотрим теперь практические примеры работы с MySQL.

Практическое применение MySQL

Для начала изучим работу с MySQL+сервером посредством клиентской программы mysql и несколько простых запросов к базе данных. Этот раздел познакомит читателя с настройками баз данных и созданием нескольких новых пользователей (не имеющих прав пользователя root), а практические примеры продемонстрируют работу запросов.

Запуск клиентской программы mysql

Запустите клиент mysql, введя в командной строке следующую команду:

> mysql -uUSER -pPASSWORD -hHOST

Аргументы USER, PASSWORD и HOST необходимо заменить соответствующими зна+ чениями, отражающими персональные настройки. Например, если в используемой системе имя пользователя и пароль равны phpuser и phppass соответственно, а сер+ вер баз данных имеет адрес db.whatever.com, то команда будет следующей:

> mysql -uphpuser -pphppass -hdb.whatever.com

392 Глава 9

Чтобы выбрать определенную базу, можно использовать команду вида USE

имябазыданных:

mysql> USE mysql; Database changed

Теперь MySQL+сервер готов к работе с базой данных mysql. Предупреждение: таб+ лицу user в этой базе данных следует использовать с особой осторожностью ++++++ она содержит важную информацию, удалять которую нежелательно.

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

к регистру символов: Mysql, MYSQL и mysql ****** имена абсолютно разных баз данных.

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

Для получения списка существующих в текущей базе данных таблиц используется команда SHOW TABLES:

mysql> SHOW TABLES;

6 rows in set (0.00 sec)

В данном случае также выводится больший объем информации, чем при использо+ вании mysqlshow. Теперь можно подробнее изучить таблицы. Например, чтобы про+ смотреть структуру таблицы user, можно использовать команду DESCRIBE (или DESC):