Объектное
представление о реляционной модели
Предположим, что имеется некоторая система управления молочным магазином или сетью магазинов. В качестве одной из её составных частей выступает подсистема учёта товаров. Молочные продукты характеризуются следующим набором атрибутов:
По тем или иным причинам произошло изменение инфологической модели и теперь требуется регистрировать не только молочные продукты, но, допустим, и мебель. Предположим, что для мебели характерен следующий набор атрибутов:
Можно отметить, что первые семь атрибутов являются общими для каждого вида товара, в то время как остальные атрибуты у них уникальны. Нам необходимо создать такую схему хранения информации, которая бы в соответствовала условиям примера.
Попробуем найти решение проблемы в рамках современных РСУБД. Можно предложить три варианта решения:
Примечание: Ситуация хранения только общих атрибутов не рассматривается, поскольку противоречит условиям примера. Рассмотрим достоинства и недостатки каждого решения.
Такое решение практиковалось в подавляющем большинстве случаев, которые мне приходилось наблюдать. Но можно ли назвать такое решение хорошим? Действительно, такие показатели, как “конечная дата реализации” и “жирность” являются обязательными для вида товара “Молочные продукты”, но они бессмысленны при описании вида товара “Мебель”. Аналогично можно сказать, что атрибуты “габариты”, “тип покрытия” и “цвет”, полезны только при описании “Мебели”, а при работе с “Молочными продуктами” их значения становятся неопределёнными. То есть, мы не можем объявить обязательными те атрибуты, которые являются характерными только для отдельных видов товаров, хотя это, безусловно, необходимо. Следовательно, наша система не сможет отследить ввод “Молочных продуктов” без указания срока реализации или жирности. Это может привести к нежелательным последствиям. Попробуем наоборот, пусть атрибуты станут обязательными. Тогда потребуется ввод показателей “жирность” для мебели и “тип покрытия” для молока, но в реальности такой информации не существует. Возникает ситуация, когда пользователи в ответ на бессмысленный запрос могут ввести не менее бессмысленный ответ. В результате становится возможным, что на запрос выдать товар с наибольшим показателем жирности, мы получим в ответ: спальный гарнитур “Зима”. Кроме того, отношение “ТОВАРЫ” будет обладать тенденцией к бесконечному росту при увеличении номенклатуры продаваемых товаров. Однако только незначительная часть атрибутов будет полезной в каждом конкретном случае. Рано или поздно отношение “ТОВАРЫ” превратится в монстра, который будет беспощаден к ресурсам сервера.
Такой способ решения позволяет избежать тех проблем, которые свойственны первому варианту. На самом деле, поскольку атрибуты свойственные каждой конкретной сущности разнесены по разным отношениям, то на них можно накладывать любые ограничения и проверки. С другой стороны, не происходит бесконтрольного увеличения отношения “ТОВАРЫ”, так как там хранятся только те атрибуты, которые являются общими для всех видов товаров. Но является ли это решение хорошим? Одно из незыблемых правил реляционной теории гласит, что поле (группа полей) одного отношения не могут быть другим отношением или ссылкой (прямой или косвенной) на другое отношение. Нам же придётся в отношение “ТОВАРЫ” ввести атрибут “вид товара” и по значению, сохранённому в этом поле, переходить либо к отношению “Молочные продукты”, либо к отношению “Мебель”. Такое решение проблемы приводит к нарушению принципов реляционной модели и лишает нас возможности полноценно использовать SQL, поскольку в нём не предусмотрена обработка подобных ситуаций.
Теперь сущности: “Молочные продукты” и “Мебель” хранят свои атрибуты в отдельных отношениях. Это решение лучше первого варианта, поскольку не имеет его недостатков, и лучше второго, так как не приводит к нарушению правил использования реляционной модели. Но! Теперь утрачена такая сущность как “ТОВАРЫ”. Если у нас есть отношения, поддерживающие ссылочную целостность с отношением “ТОВАРЫ” (например, “Ведомость на списание”), то куда они будут ссылаться?
Прежде всего, нельзя не отметить то, что переход на любую постреляционную модель (объектную или объектно-реляционную) влечёт за собой большие накладные расходы. Значительная часть расходов будет направлена на то, чтобы обеспечить перенос информации из существующей базы данных, модификацию программного обеспечения и обучение персонала. Кроме того, при использовании постреляционных баз данных возникают специфические трудности как при проектировании и создании базы данных, как и при её модификации и эксплуатации. Однако обсуждение этих вопросов выходит за рамки данной статьи.
Приведённый пример - это лишь частный случай и с подобными проблемами можно столкнуться в любой предметной области: банковские вклады; номера в гостиницах; места в транспорте; специальности; должности; наконец, структурные подразделения на предприятии. Ни одно из решений, доступных в рамках существующих РСУБД, нельзя признать удовлетворительным. Означает ли это ограниченность самой реляционной модели или это ограниченность её реализаций? Можно ли найти качественное решение для подобных задач или следует подумать об иной модели, например, постреляционной или объектной? Решение, которое предлагается ниже, позволяет не только остаться в рамках реляционной модели, но и сохранить всё то, что сделано: и структуру базы данных, и программное обеспечение, а, следовательно, сохранить время и инвестиции в программное обеспечение. |
|||||||