Коболе), которая содержит все известные подробности о любом заказе — заказанные товары, местонахождение их на складе, данные об отгрузке и полученных платежах.
Такие составные структуры данных (записи) были обычным явлением на ранних этапах компьютеризации, поскольку существовали веские причины для их использования в системах того времени. Эффективных механизмов индексированного доступа в этих системах не было, поэтому требовалось чтение всего "объекта", а его обработка осуществлялась за одну операцию (как правило, чтение осуществлялось с последовательного устройства — устройства ввода с перфокарт, а позже — с накопителя на ленте). Однако возможности ранних языков программирования не обеспечивали должной обработки этих объектов, поэтому большинство разработчиков были рады перейти к другим технологиям, основанным на декомпозиции данных, в частности к третьей нормальной форме (3NF).
Сторонники объектного подхода чаще всего используют следующую аналогию. Ставя машину в гараж (если вам повезло и у вас есть и машина, и гараж, в котором достаточно места для машины), вы паркуете ее как объект, который уже собран и готов к повторному использованию. Вы же не разбираете машину на части, маркируя каждую часть и расставляя их на полках только для того, чтобы вновь собрать их на следующее утро.
Если вы (как и мы) чувствуете, что есть еще "порох в пороховницах" третьей нормальной формы, и все-таки стремитесь выполнять декомпозицию своих объектов для хранения даже в мире, который все больше и больше завоевывается языком Java, то можете задать стороннику объектных технологий встречный вопрос: "Будете ли вы хранить свою одежду комплектно, сшив предметы вместе (например, прикрепив носки намертво к туфлям), или же поставите обувь в одно место, носки положите в другое, а галстуки повесите в третье?" Сторонник объектов может посмотреть на вас, как на сумасшедшего, и спросить, какое же это имеет отношение к предмету спора. (Ответ, который лучше не произносить, звучит примерно так: "Такое же самое, что и ваш пример, то есть — никакого".)
Аргументы за и против декомпозиции
Давайте рассмотрим аргументы за и против декомпозиции данных несколько серьезнее. Используя наш пример с заказами, мы могли бы построить табличную модель, изображенную на рис. 5.1.
Применительно к этой модели существует несколько способов выделения объектов. Если бы мы выписывали счета-фактуры, то могли бы просмотреть совокупность объектов, описывающих покупателей, проверяя в каждом наличие заказов, для которых еще не выписан счет-фактура. Можно также рассматривать каждый заказ (с его строками) как объект и полагать, что этот объект Order будет содержать связь или ссылку на объект Customers, описывающий лицо, которому мы продали этот набор товаров (рис. 5.2).
90	Oracle 8