храниться также коллекции и связи с другими объектами.
* В большинстве реляционных баз данных, включая MySQL и mSQL, нет средств, 
позволяющих моделировать наследование.
Практические правила для объектно-реляционного моделирования
* У каждого сохраняемого класса в базе данных есть своя таблица.
* Поля объектов с простыми типами данных (целые, символы, строки и т. д.) 
сопоставлены колонкам в соответствующей таблице базы данных.
* Каждая строка таблицы базы данных cоответствует экземпляру соответствующего 
хранимого класса.
* Каждая связь между объектами типа «многие-ко-многим» требует таблицы-связки, 
так же как это требуется для объектов базы данных типа «многие-ко-многим».
* Наследование моделируется с помощью отношения «один-к-одному» между таблицами,
 соответствующими классу и подклассу. Вспомните адресную книгу, о которой мы 
говорили ранее. Допустим, она имеет таблицы address и person, как на рис. 8-2.

Рис. 8-2. Модель данных простого приложения адресной книги
Есть весьма неочевидная проблема, с которой сталкиваются программисты. Основная 
задача объектно-ориентированного подхода к реляционным данным - это, получив 
эти данные, немедленно создать экземпляр объекта. Приложение должно работать с 
данными только через объекты. Большинство традиционных методов программирования,
 включая разработку на С, PowerBuilder и VisualBasic, требует, чтобы 
разработчик извлек из базы данные, а затем их обработал. Главное отличие 
состоит в том, что в объектно-ориентированном программировании баз данных вы 
имеете дело с объектами, а не данными.
Рис. 8-3 показывает объектную модель, соответствующую модели данных на рис. 8-2.
 Каждая строка базы данных преобразуется в программный объект. Таким образом, 
ваше приложение принимает результирующий набор и для каждой возвращаемой строки 
создает новый экземпляр Address или Person. Труднее всего справиться с 
проблемой, о которой уже говорилось: как в приложении установить связь между 
человеком и его адресом? Объект Person, конечно, имеет ссылку на объект Address,
 относящийся к этому человеку, но сохранить объект Address внутри таблицы 
person реляционной базы нельзя. Модель данных предполагает хранение связей 
между объектами с помощью внешних ключей, для чего в таблицу person заносится 
address_id.

Рис. 8-3. Объектная модель, поддерживающая простое приложение адресной книги
Самое незначительное усложнение объектной модели может вызвать бездну проблем 
при установлении соответствия наших объектов и модели данных. Допустим, что 
Person является потомком Entity и класс Company тоже является потомком Entity. 
Как отделить Entity от Person или Company? Приведенное выше правило фактически 
является скорее рекомендацией. В некоторых случаях базовый класс является чисто 
абстрактным и, следовательно, не имеет в базе связанных с ним данных. В таком 
случае для этого класса в базе данных не будет объекта.
Трехзвенная архитектура
До сих пор мы обсуждали самую простую архитектуру для работы с WWW и простыми 
бизнес-приложениями - клиент/сервер. Однако эту архитектуру не так-то просто 
нарастить по мере роста и изменения ваших приложений. В ней также трудно 
использовать преимущества объектно-ориентированного программирования. Первая 
проблема недавно нашла отражение в дискуссиях относительно «тонких клиентов». 
Потребность в тонких клиентах происходит из беспокоящей тенденции в передаче 
клиенту все больших объемов обработки. Эта проблема проявилась в PowerBuilder и 
VisualBasic - инструментах, которые прямо вытаскивают данные из базы в GUI, а 
затем все операции над этими данными проводят в GUI.
Такая тесная привязка интерфейса пользователя к ядру базы данных приводит к 
появлению программ, которые трудно модифицировать и невозможно масштабировать 
при увеличении числа пользователей и объема данных. Если у вас есть опыт 
разработки интерфейсов пользователя, то вы сталкивались с проблемой переработки 
интерфейса в зависимости от каприза пользователя. Чтобы изолировать последствия 
такой переработки, проще всего оставить для GUI только одну задачу- действовать 
в качестве интерфейса пользователя. Такой интерфейс пользователя действительно 
является тонким клиентом.
Влияние на масштабируемость сказывается и с другой стороны. Когда требуется 
переработать приложение, чтобы оно могло справляться с возросшим числом 
пользователей и объемом данных, модификация может быть осуществлена в 
результате изменений, вносимых в базу данных, в том числе таких, которые 
состоят в распределении базы данных по нескольким серверам. Навечно привязав 
свой интерфейс к базе данных, вам приходится делать изменения в этом GUI для 
решения проблем масштабирования - проблем, связанных исключительно с сервером.
Тонкие клиенты - не единственное сегодняшнее поветрие. Другая тенденция - 
повторное использование кода. Общий для разных приложений код тяготеет к 
обработке данных, обычно называемой деловой логикой. Если вся ваша деловая 
логика располагается в интерфейсе пользователя, то добиться повторного 
использования кода будет, по меньшей мере, трудно. Решением этих проблем 
является разбиение приложения на три, а не на две части. Такая архитектура 
называется трехзвенной.
Когда мы говорим об интерфейсе пользователя у клиента, то имеем в виду 
логическое различие. Разновидностью тонкого клиента, иногда называемой 
«сверхтонким клиентом», является то, что обычно всеми воспринимается как 
Web-страница. Web-страница может динамически создаваться на Web-сервере. В этом 
случае большая часть работы клиента происходит на сервере в виде динамической