Гранулярность (granularity)

Рассмотрим ситуацию, когда нам надо представить в объектном виде и сохранять в БД следующий класс.

Эта сущность представляет собой пользователя в системе. Помимо традиционного имени и фамилии она так же содержит адрес пользователя. Такая сущность тривиально отображается на таблицу в БД. Каждому полю класса соответствует колонка в таблице. Такой подход весьма прост и хорошо работает, но только в примитивных случаях. Рассмотрим ситуацию, когда у пользователя может быть несколько адресов, например: домашний и рабочий.

При таком подходе имеет место дублирование кода, не только кода отражающего колонки таблицы и поля класса, но и кода, который обрабатывает эти колонки. Проблема ещё более усугубляется когда приходиться вносить изменение, например добавить к адресу номер телефона. С точки зрения ООП имеет смысл выделить адрес в отдельную структуру, или, с т.з. языка Java – класс. Аналогичный подход – нормализация – можно применить и к таблице User, выделив адрес в отдельную таблицу. Однако, такой подход не всегда является оправданным с точки зрения производительности, но кроме того, нарушает естественную инкапсуляцию, так как адрес не является отдельной сущностью. Имеет место несоответствие гранулярности между объектной моделью и реляционной.

То, что является наиболее удобным и естественным в объектной модели, может быть неуместным в реляционной модели и наоборот. Хорошее ORM решение позволяет абстрагироваться от этой проблемы и использовать обе модели, прозрачно преобразуя классы в таблицы. Стоит отметить, что одним из решений, могущих оказать помощь в данном случае является использование типов определяемых пользователем (User Defined Types, UDT), поддержка которых предлагается во многих современных СУБД. Однако, такое решение может оказаться неудачным, ввиду того, что поддержка UDT реализована по-разному в разных СУБД, а кроме того язык SQL не предоставляет достаточно удобного способа для работы с UDT.

Дата добавления: 2015-10-24