Теория и практика построения баз данных (1088289), страница 151
Текст из файла (страница 151)
Фактически, метод Назначить здесь является примером того, что называется обрааяыж вызовом (са!!Ьас!с). Объект ЗАКАЗ в методе Создать передает указатель на себя объекту КЛИЕНТ, в результате чего клиент может отслеживать свои заказы. Это делается, в частности, для того, чтобы объект КЛИЕНТ перед своим уничтожением мог вызвать все связанные с ним объекты ЗАКАЗ. Таким образом, объекты ЗАКАЗ смогут уничтожить указатель на объект КЛИЕНТ, когда этот указатель станет недействительным. Обратные вызовы имеют также много других применений. Далее метод ЗАКАЗ!Создать записывает в переменную Продавец указатель на объект ПРОДАВЕЦ. Этому методу передается почтовый индекс клиента (атрпбут Индекс), и это подсказывает нам, что индекс имеет какое-то отношение к распределению клиентов между продавцами.
Опять-таки, из-за инкапсуляции мы не знаем, как это делается. Так как методология приложения скрыта, способ распределения клиентов между продавцами в объекте ПРОДАВЕЦ может быть изменен, но это никак не повлияет на логику этой пли какой-либо другой программы. Таким образом, если метод ПРОДАВЕЦ!Назначить будет назначать клиентов продавцам в соответствии с фазами Луны, нн одну строку кода листинга 18.1 менять не потребуется! Следующий раздел кода заполняет строки заказа. Обратите внимание, что локальные элементы данных адресуются с помощью ключевого слова Ме. (На са- мом деле, в большинстве объектно-ориентированных языков программирования Ме подразумевается и не является обязательным; здесь мы помешаем его для ясност~.) В начале каждого повторения цикла ВЬ1!е с помощью метода СтрокаЗаказа! Создать выделяется память для следующей строки заказа. Метод ТОВАР!Взять забирает тонары со склада.
Обратите внимание; логика работы метода предполагает, что если число единиц товара на складе меньше, чем заказанное количество единиц товара, то недостающее количество должно быть оформлено как отложенный заказ. Также обратите внимание, что измененный обьект ТОВАР сохраняется после обработки каждой строки заказа. Кроме того, в отличие от объектов КЛИЕНТ и ПРОДАВЕЦ, объектам ТОВАР не передается указатель для обратного вызова. Это означает, что объекты ТОВАР не зна|от, с какими объектами ЗАКАЗ они связаны. Понятно, что в данном приложении для объектов ТОВАР несущественно, в каких заказах онп фигурируют.
Цикл продолжается, пока все требуемые товары пе будут пе!зечнслсны в заказе. После этого обновляются итоговые суммы в объектах ПРОДАВЕЦ и КЛИЕНТ, и оба эти объекта сохраняются владеете с Ме. Фрагмент кода, приведенного в листинге 18.1, представляет собой типичный пример объектно-ориентированной программы и выявляет несколько важных вопросов, имеющих значение для объектно-ориентированных систем баз данных. Один из этих вопросов гаков: каким образом обьекты делаются постоянныъщ? Постоянное хранение объектов На рис.
18.2 изображены структуры данных, существуюшце после создания заказа. Объект ЗАКАЗ содержи~ базовые данные заказа, такие как ЗАКАЗ. Номер, ЗАКАЗ. Дата, ЗАКАЗ. Сумма, а также повторяющуюся группу строк заказа, имеющих такие атрибуты, как НомерТовара, НазваниеТовара, Количество, ОтложенноеКоличество и Стоимость. Кроме того, базовые данные заказа включают указатели па обьекты КЛИЕНТ и ПРОДАВЕЦ, с которыип связан этот заказ, а также указатели на каждьш из объектов ТОВАР, фигурирующий в строке заказа.
Эти указатели являются частью данных объекта ЗАКАЗ. Чтобы сделать атот объект постоянным, необходимо сохранить все эти данные. Кроме того, нужно сохранить каждый из объектов КЛИЕНТ, ПРОДАВЕЦ и ТОВАР, хотя их структура и неизвестна. В объектах КЛИЕНТ и ПРОДАВЕЦ сохраняется также указатель на объект ЗАКАЗ в результате обратных вызовов, сделанных в методах! Назначить. Этп указатели вызывают особенные трудности. В большинстве объектно-ориентированных языков программирования указатели являют собой ту или иную форму адреса в памяти. Такие адреса действительны только в период выполнения программы; при повторном ес запуске адреса объектов уже другие. Следовательно, сохраняя объект, необходимо преобразовать указатели на объекты в памяти в постоянные уникальные идентификаторы, которые будут действительны в течение всего времени существования объекта, независимо от того, находится Постоянное хранение объектов 701 НомерЗаписи КодЗаписи Содержимое Ссылка ЗАКАЗ ПРОДАВЕЦ КЛИЕНТ СТРОКА ЗАКАЗА СТРОКА ЗАКАЗА Данные заказа 100 Данные продавца Джонса Данные клиента 10000 Данные строки заказа 100 Данные строки заказа 100 4 пщ1 лий 5 пцй Рис.
18.2. Пример структуры данных объекта 700 Глава 18. Объектно-ориентированные базы данных ли оп в памяти. Процесс преобразования постоянных идентификаторов в адреса в памяти называется настройкой по адресам (зъу1гг11п8). Наконец, вспомните, что объект определяется как значения данных плюс метолы. Таким образом, чтобы сделать объект постоянным, необходимо сохранить и методы, и данные экземпляров объектов. Но в отличие от элементов данных, методы каждого объекта данного класса остаются одними и теми же, поэтому методы требуется сохранить лишь однажды — для всех экземпляров данного объектного класса. Действия, которые необходимо выполнить для обеспечения постоянного хранения объектов, перечислены на рис. 18.3. ° Сохранить данные экземпляра объекта ° Преобразовать указатели на обьекты, находящиеся в оперативной памяти, в постоянные уникальные идентификаторы (настройка по адресам) ° Сохранить методы объектного класса Рис.
18.3. Действия, которые необходимо выполнить для обеспечения постоянного хранения обьекта Постоянное хранение объектов может осуществляться с помощью традиционной файловой сгистемы, реляционной СУБД или объектно-ориентированной СУБД, Рассмотрим каждый из этих способов. Постоянное хранение обьектов в традиционной файловой системе Объекты можно хранить в традиционной файловой системе, но это возлагает на плечи программиста тяжелое бремя. Рассмотрим данные на рис.
18.2. Разработчику может прийти в голову мысль создать один файл для методов всех объектов и второй файл для данных всех объектов. Для этого необходимо будет разработать обобщенную структуру данных, которая позволит записывать методы и данные в файлы и считывать их оттуда при необходимости. В табл, 18.2 показан пример файла, в котором хранятся элементы данных. (Для хранения методов необходимо создать еще один подобный файл.) Таблица 18.2.
Хранение данных объекта в файле фиксированной длины Для работы с таким файлом программист должен будет написать метод, который будет записывать и считывать содержащиеся в нем данные объектов, находить объекты по запросу, организовывать неиспользуемое файловое пространство и т. д. Далее разработчику придется разработать и реализовать алгоритмы настройки по адресам и обратной операции. Кроме того, существует еще проблема начальной загрузки. Ведь все методы хранятся в файлах, вклгочая методы, выполняющие сохранение и чтение методов. Как должен загружаться метод, который считывает первый метод? Все эти трудности были преодолены еще много лет назад в файловых подсистемах операпионных систем.
Но в атом-то все и дело: такое программирование медленно, утомительно, рискованно и трудно, и оно уже было выполнено в традиционных системах обработки файлов. Зачем проделывать все то же самое еще раз? Из-за этих проблем храненве объектов в традиционных файловых системах имеет смысл лишь тогда, когда приложение имеет несколько простых объектов, структура которых не меняется. Немногие бизнес-приложения удовлетворяют атому критерию. Постоянное хранение обьектов с помощью СУБД Другой подход к постоянному хранению объектов заключается в использовании коммерческих реляционных СУБД. При этом подходе бремя, ложащееся на плечи программиста, оказывается неньше, чем при использовании традиционной обработки файлов, поскольку основные задачи управления файлами — размепхение 702 Глава 18.
Обьектно-ориентированные базы данных Постоянное хранение объектов 703 записей, индексирование, управление файловым пространством и т. д. — берет на себя СУБД. Программисту остается определить реляционные структуры для представления объектов и написать код, выполняющий посредническую функцию между программой и СУБД при чтении-записи об ьектов и настройке по адресам. Далее приведены таблицы, необходимые для хранения объектов ЗАКАЗ, СТРОКА ЗАКАЗА, КЛИЕНТ, ПРОДАВЕЦ и ТОВАР. Мы уже встречали эту структуру ранее.
Единственный новый элемент в ней — это таблица, где хранятся методы объектов; она имеет текстовое поле большой длины, в котором и хранится код методов. СОТРУДНИК (Номер, Имя, ...) ПРОДАВЕЦ (Номер, ВсегоКомиссионных, СуммаПродаж, ...) КЛИЕНТ (Имя, Телефон, Инлекс, ТекушийБаланс, ...) ТОВАР (Номер, Название, Описание, Цена, ...) ЗАКАЗ (Номер, Дата, Сумма, НРОДАВЕЦНомер, КЛИЕНТИмл, ...) СТРОКА ЗАКАЗА (ЗАКАЗ.
Номер, ТОВАР.Ноиер, НазваниеТовара, КоличествоТовара, ОтложенноеКоличество, Стоимость, ...) МЕТОДЫ (ИмяОбъекта, ИмяМетода, КодМетода) В реляционных базах данных связи представляются через внешние кл|очи. Это означает, что программист должен реализовать некоторый способ постоянного хранения связей с помощью внешних ключей. Наиболее распространенный способ — обеспечить в конструкторе объекта создание уникалыюго идентификатора. Этот идентификатор может храниться в базовой таблице объекта и показываться объектом как свойство только для чтения. Объекты, которым требуется ссылка на этот объект, могут хранить у себя значение этого идентификатора.
Такая стратегия создает одну проблему: когда объект уничтожается, он должен уведомить об этом все объекты, имеющие ссылку на него, чтобы они могли удалить эту ссылку и предпринять другие необходимые действия. Это одна нз причин, по которой используются обратные вызовы, как в листинге 18.1. Объектно-ориентированное мышление хоронит саму концепцию связи. Так, например, когда обьект ЗАКАЗ устанавливает связь с объектом ПРОДАВЕЦ, он интересуется только своей стороной этой связи. Если объект ЗАКАЗ захочет установить связь с несколькими объектами ПРОДАВЕЦ, он сможет это сделать. Объект ЗАКАЗ не знает, со сколькими объектами ЗАКАЗ имеет связь объект ПРОДАВЕЦ.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
