Теперь, когда мы познакомились с основами РНР, настало время приступить к рассмотрению вопроса интегрирования баз данных со ссценариями, реализующими поведение сайта. Мы уже рассматривали преимущества использования реляционных баз данных по сравнению с двумерными файлами. Основными преимуществами можно считать следующее:
Если говорить предметно, то использование реляционных баз данных позволяет быстро и без особых проблем ответить на такие вопросы: "Где проживают клиенты?", "Какие товары продаются наиболее успешно?" или "Какая категория клиентов приносит наибольшую прибыль?". Эта информация может способствоать улучшению работы сайта, преследуя цель не только не потерять клиентов, но и привлечь новых. При этом ее очень трудно получить, имея дело с двумерными файлами.
На сегодняшний день реляционные базы данных являются, наиболее часто используемым типом БД. Они построены на основе строгих законов реляционной алгебры. Чтобы пользоваться реляционными базами данных, вовсе не обязательно досконально разбираться в реляционной теории, однако все же следует овладеть основными понятиями о базах данных.
Реляционные базы данных построены на основе отношений, обычно называемых таблицами. Таблица представляет собой именно то, что и подразумевает этот термин — таблицу с данными.
Так как мы будем в дальнейшем заниматься разработкой Интернет-магазина, торгующим книгами, электронными товарами типа электронных книг, аудио и видео продукцией, то рассмотрим пример таблицы, содержащей имена и адреса клиентов интернет-магазина.
Customers (Клиенты)
| CustomerID (Идентификатор клиента) |
Name (ФИО) | Address (Адрес) | City (Город) |
| 1 | Сидоров Владимир | ул. Гоголя 5 | Пушкин |
| 2 | Пупкин Василий | ул. Полевая 14/2 | Гатчина |
| 3 | Иванов Павел | ул. Сталеваров 52 | Новгород |
Таблица имеет собственное имя — Customers (Клиенты), несколько столбцов, каждый из которых содержит определенного вида данные, а также строки, в которых записаны сведения о клиентах.
Каждый столбец в таблице имеет уникальное имя и содержит разнообразные данные. Каждому столбцу отвечает определенный тип данных. Например, в таблице Customers, которая показана на рисунке, можно видеть, что столбец CustomersID (Идентификатор клиента) хранит целочисленную информацию, а остальные три столбца — строковую. Иногда на столбцы ссылаются также как на поля или атрибуты.
Каждая строка в таблице представляет отдельного клиента. Вследствии использования табличного формата все строки имеют одни и теже атрибуты. Строки также называют записями или кортежами.
Каждая строка состоит из набора отдельных значений, соответствующих столбцам. Тип данных каждого значения должен соответствовать типу данных, заданному столбцом.
Клиентов нужно различать. Обычно имена не очень подходят для этого — если ваше имя достаточно распространенное, думается, вполне понятно, почему так сложно отличить одно какое-то имя от десятков и сотен таких же имен.
Существует несколько способов отличить одинаковые имена. Например, конкретного Васю Пупкина, можно отыскать по его адресу. Однако строка с адресом слишком длинная. К тому же подобный способ идентификации предполагает использование нескольких столбцов таблицы.
В данном случае мы поступили следующим образом — каждому клиенту присвоили уникальный идентификатор клиента (CustomerID). При этом используется тот же принцип, что и в банке, где счетам клиентов присваивают уникальные имена. Такой подход облегчает хранение сведений в базе данных, а исскуственное присвоение идентификационного номера гарантирует его уникальность. Лишь некоторые реальные сведения о клиенте, даже при совместном их использовании, обладают подобным свойством.
Столбец идентификации в таблице называется ключем (key) или первичным ключем (primary key). Ключ может состоять из нескольких столбцов. Например, если бы мы решили идентифицировать Сидорова Владимира по строке "Сидоров Владимир, ул. Гоголя 5, Пушкин", то ключ состоял бы из столбцов Name, Address и City. При этом нельзя было бы гарантировать его уникальность.
Обычно базы данных состоят из нескольких таблиц, для которых ключ служит связующим звеном. На рисунке ниже, показана база данных, в которую добавлена вторая таблица. В ней размещены сведения о заказах, сделанных клиентами. Каждая строка в таблице Orders (Заказы) представляет один заказ, сделанный одним клиентом. Клиента можно установить по хранящейся в таблице идентификатору клиента CustomerID. Например, если взглянуть на заказ с идентификатором заказа OrderID равным 2, видно, что его сделал клиент с CustomerID равным 1. Затем, обратившись к таблице Customers, можно выяснить, что CustomerID = 1 присвоен клиенту Сидоров Владимир.
Customers (Клиенты)
| CustomerID (Идентификатор клиента) |
Name (ФИО) | Address (Адрес) | City (Город) |
| 1 | Сидоров Владимир | ул. Гоголя 5 | Пушкин |
| 2 | Пупкин Василий | ул. Полевая 14/2 | Гатчина |
| 3 | Иванов Павел | ул. Сталеваров 52 | Новгород |
Orders (Заказы)
| OrderID (Идентификатор заказа) |
CustomerID (Идентификатор клиента) |
Amount (Сумма) | Date (Дата) |
| 1 | 3 | 100.00 | 02-Июн-2010 |
| 2 | 1 | 300.00 | 15-Июн-2010 |
| 3 | 2 | 150.00 | 28-Июн-2010 |
| 4 | 4 | 350.00 | 04-Июл-2010 |
Каждый заказ в таблице Orders соответствует клиенту из таблицы Customers.
В соответствии с терминологией реляционных баз данных такая взаимосвязь называется внешним ключем (foreign key). CustomerID —первичный ключ в таблице Customers, однако когда он появляется в другой таблице, например, Orders, его называют внешним ключем.
Не исключено, что наше решение использовать две разные таблицы может вызвать у вас недоумение — почему бы просто не поместить адрес Сидорова Владимира в таблицу Orders? Подробнее это объясняется дальше.
Полный набор эскизов таблиц базы данных называется схемой базы данных. В чем-то схема подобна чертежу. В ней должны быть изображены таблицы вместе с их столбцами, а также указаны первичный ключ и все внешние ключи для каждой таблицы. Схема не содержит никаких конкретных данных, однако в нее можно поместить образцы данных, чтобы назначение тех или иных столбцов было понятнее. Схемы могут быть представлены в виде неформальных диаграмм, в виде диаграмм "сущность-отношение" или в текстовой форме наподобие следующей:
Customers (CustomerID, Name, Address, City)
Orders (OrderID, CustomerID, Amount, Date)
Подчеркнутые элементы в схеме — это первичные ключи того отношения (таблицы), где они подчеркнуты. Элементы, выделенные курсивом, представляют собой внешние ключи соответствующего отношения.
Внешние ключи представляют отношения между данными в двух таблицах. Например, связь между таблицами Orders и Customers представляет отношение между строкой в таблице Orders и строкой в таблице Customres.
В реляционной базе данных существуют три основных типа отношений. Их классифицируют в зависимости от количества элементов по каждую сторону отношения. Различают отношения типа "один к одному", "один ко многим", "многие ко многим".
Отношение "один к одному" означает, что с каждой стороны в отношении учавствуют по одному элементу. Например, если бы адреса были помещены не в таблицу Customers, а какую-нибудь другую, между этими таблицами существовало бы отношение "один к одному". Таблицы Addresses (Адреса) и Customers могли бы быть связаны внешним ключем либо как-то иначе (и то и другое необязательно).
При отношении "один ко многим" одна строка в первой таблице связана с несколькими строками другой таблицы. В нашем примере один клиент может сделать несколько заказов. В таких отношениях таблица, содержащая несколько строк, будет иметь внешний ключ к таблице с одной строкой. В данном случае, чтобы проиллюстрировать это отношение, мы вставили идентификатор клиента в таблицу заказов.
В отношении типа "многие ко многим" нескроко строк одной таблицы связаны с несколькими строками другой. Например, при наличии двух таблиц Books (Книги) и Authors (Авторы) могло бы выясниться, что одна книга была написана несколькими авторами, каждый из которых написал и другие книги, причем некоторые из них могли быть написаны опять-таки в соавторстве с другими. Как правило такой тип отношений полностью замыкает таблицу на саму себя. В результате могли бы существовать таблицы Books, Authors, и Books_Authors. Третья таблица содержала бы только ключи из остальных двух таблиц в качестве парных внешних ключей, показывающие, какие авторы принимали участие в написании той или иной книги.
Веб-инструмент
Обсудить на форуме