MySQL & mSQL



   Химчистим диваны в Киеве - заказать             

Объектное/реляционное моделирование


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

  • Объекты не хранят только простые данные в своих атрибутах. Там могут храниться также коллекции и связи с другими объектами.

  • В большинстве реляционных баз данных, включая 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? Приведенное выше правило фактически является скорее рекомендацией. В некоторых случаях базовый класс является чисто абстрактным и, следовательно, не имеет в базе связанных с ним данных. В таком случае для этого класса в базе данных не будет объекта.




    Содержание  Назад  Вперед