function Room{$name= unnamed ) {

$this->name = $name;

метод для определения названия комнаты

function getNameO

return{$this->name);

создание объекта здания $home = new Bui1ding;

добавление комнат

$home->addRoom(new Room( kitchen )); $home->addRoom(new Room( bedroom ));

установление соединения

if(!($dbLink = mysql pconnect( localhost , httpd , ))) {

print( Could not connect to server!<br>\n ) print(mysql errno() . : . mysql error() exit 0 ;

<br>\n );

выбор базы данных test

if( !mysql select db( test , $dbLink))

print( Could not select database!<br>\n ); print(mysql errno() . : . mysql error()

exit 0 ;

<br>\n );

/ / выполнение запроса

$Query = INSERT INTO object (Data) .

VALUES ( . serialize($home) . ) ; if(!($dbResult = mysql query($Query, $dbLink)))

print( Could not execute query!<br>\n ); print(mysql errno() . : . mysql error() exitO;

<br>\n );

определение идентификатора объекта $oid = mysql insert id();

извлечение объекта из базы данных

$Query = SELECT Data FROM object WHERE lD=$oid ;

if(!($dbResult = mysql query($Query, $dbLink)))

not execute

print (mysql errno () . : . mysql e.rror () . <br>\n ); exitO ;

Объектно-реляционные связи 529

?>

$row = inysql fetch row ($dbResult) ;

$h = unserialize($row[0]);

добавление еще одной комнаты $h->addRooni(new Room ( bathroom ) ) ;

определение названия второй комнаты $г = $h->getRoom(l); print($r->getName());

После того как объект был сохранен в базе данных, он немедленно извлекается и в него добавляются сведения еще об одной комнате. Последние несколько строк сценария демонстрируют, что методы объекта остались неизменными. Если запустить сценарий, то можно убедиться, что функция print () отображает строку bedroom . Интерпретатор РНР не кодирует методы в сериализованном объекте. Кодируются лишь свойства, а также имя класса. После восстановления объекта интерпретатор проверяет имя класса и делает доступными его методы.

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

Объектно-реляционные связи

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

Методы классов не имеют эквивалентов в базеданных. Они остаются элементами программного кода, что создает тесную связь между информацией, хранимой в базе данных, и классами приложения. Это не проблема, если все приложения придерживаются единого интерфейса доступа к данным. Проблема возникает при непосредственном обновлении данных с помощью SQL или другой программной среды. Например, объект может ограничивать значения числового свойства диапазоном от 0,0 до 100,0, но в MySQL столбцы типа FLOAT имеют гораздо более широкий диапазон. Если забыть о существующем ограничении, то, выполняя инструкцию UPDATE, можно легко нарушить целостность столбца. Необходимость учитывать подобного рода ограничения приводит к существенному усложнению работы с объектами.

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

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

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

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

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

Рис. ЗО.2. Диаграмма классов

На рис. 30.3 изображена диаграмма отношений между таблицами классов. Руководствуясь принципами, изложенными в главе 7, Проектирование баз данных , несложно догадаться, что таблицы Building и Room должны содержать це лочисленные первичные ключи, а таблица Room- еще и внешний ключ. Эти идентификаторы не важны с точки зрения использования объектов, но они необходимы для связи таблиц базы данных. Они также позволят приложению ассоциировать друг с другом объекты и записи таблиц. В листинге 30.3 показаны инструкции, требуемые для создания упомянутых таблиц.

Рис. 30.3. Диаграмма базы данных