Предисловие Системы управления базами данных (субд) – это программные комплексы, предназначенные для работы со специально организованными файлами (массивами данных, долговременно хранимыми во внешней памяти вычислительных систем), которые называются

Вид материала

Документы

Содержание Абстрактные типы данных Сложный объект (complex object) Классификация объектов Свойства объектно-ориентированной модели данных 11.5. ООМД и прежние модели данных: сходство и различие 11.5.1. Объект, сущность и кортеж From invoice, inv_line

Подобный материал:

• Системы управления базами данных (субд). Назначение и основные функции, 30.4kb.
• Программа курса лекций "Базы данных в научных исследованиях", 49.32kb.
• Система управления базами данных это комплекс программных и языковых средств, необходимых, 150.5kb.
• Лекция 2 Базы данных, 241.25kb.
• Любая программа для обработки данных должна выполнять три основных функции: ввод новых, 298.05kb.
• Вопросы к государственному экзамену по специальности «Информационные системы и технологии», 39.93kb.
• Лекция № Технологии баз данных, 92.24kb.
• Проектирование базы данных, 642.58kb.
• Системы управления базами данных, 313.7kb.
• Программа дисциплины Системы управления базами данных Семестры, 22.73kb.

Абстрактные типы данных

Тип данных описывает множество объектов со схожими свойствами. Все традици­онные языки программирования используют набор базовых типов данных (real, integer и string или character). Базовые типы данных подчиняются предопределенно­му набору операций. Например, базовый тип данных integer позволяет выполнять такие операции, как сложение, вычитание, умножение и деление.

В традиционные языки программирования включаются конструкторы типов, самым распространенным из которых является конструктор record (запись). Например, программист может определить запись типа CUSTOMER, определив для нее поля данных. Запись CUSTOMER будет представлять собой новый тип данных, в кото­ром будет храниться информация о клиенте, и программист может напрямую полу­чать доступ к этой структуре данных, ссылаясь на имена полей. Над записью можно выполнять такие операции, как WRITE (запись), READ (чтение) или DELETE (удаление). Для базовых типов данных определить новые операции нельзя. Как и базовые типы данных, абстрактные типы данных, АТД (abstract data types) описывают множество схожих объектов. Однако есть определенные отличия абст­рактного типа от традиционного типа данных:

• операции над АТД определяются пользователем;
  
• АТД не допускают непосредственного доступа к внутреннему представлению
  данных и реализации методов.
  

В некоторых ОО-системах, например, Smalltalk, базовые типы данных реализованы

как абстрактные.

Для создания абстрактного типа данных необходимо обеспечить:

• имя типа;
  
• представление данных или переменные экземпляра объекта, принадлежащего АТД; каждая переменная экземпляра имеет тип данных, который может быть ли­бо базовым типом, либо другим АТД;
  
• операции над абстрактными типами данных и ограничения реализуются с помо­щью методов.
  

Необходимо помнить, что определение абстрактного типа данных перестраивает определение класса. В некоторых ОО-системах для различения классов и типов при ссылке на структуры данных и методы класса используется ключевое слово type, a при ссылке на набор экземпляров объекта — ключевое слово class. Тип (type) — бо­лее статичное понятие, в то время как класс (class) связан в основном с временем выполнения.

Простой пример поможет понять это тонкое отличие ОО-класса от ОО-типа. Пред­положим мы приобрели шаблон для кружевных накидок на подушки. К шаблону прилагается описание его структуры, а также инструкция по его использованию. Этот шаблон и есть описание типа (type definition). Комплект сделанных с помощью шаблона реальных накидок, каждая из которых имеет уникальный номер (или 0ID), составляет класс (class).

Абстрактные типы данных совместно с наследованием позволяют создавать сложные объекты. Сложный объект (complex object) формируется путем комбинации других

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

• стандартные (табличные) данные о сотруднике (имя, телефон, дата рождения
  и т. д.);
  
• битовая карта для хранения фотографии сотрудника;
  
• голосовые данные для хранения образца голоса сотрудника.
  

Возможность относительно просто работать с такой сложной средой данных повы­шает ставки ОО-систем на современном рынке баз данных.

Классификация объектов

Объект можно классифицировать в соответствии с его свойствами (простой, состав­ной, сложный, смешанный и ассоциативный) или атрибутами.

В простом объекте (simple object) содержатся только однозначные атрибуты и нет атрибутов, которые ссылаются на другие объекты. Например, объект, который опи­сывает текущий семестр, может быть определен следующими однозначными атрибу­тами: SEM_ID (идентификатор семестра), SEM_NAME (название семестра), SEM_BEGIN_DATE (дата начала семестра) и SEM_END_DATE (дата окончания семестра).

В составном объекте (composite object) содержится, по крайней мере, один много­значный атрибут, но нет атрибутов, ссылающихся на другие объекты. Например, объект Movie (фильм) может включать в себя следующие атрибуты: MOVIE_ID (идентификатор фильма), MOVIE_NAME (название фильма), MOVIE_PRICE (стоимость фильма), MOVIE_TYPE (жанр фильма) и MOVIE_ACTORS (актеры, за­нятые в фильме). В данном случае атрибут MOVIEACTORS является многознач­ным, описывающим нескольких исполнителей ролей в данной картине. В сложном объекте (compound object) содержится, по крайней мере, один атрибут, который ссылается на другой объект. Примером может служить объект Student (студент) из табл. 11.2. В этом примере атрибут ADVISOR (куратор) ссылается на объект Professor (преподаватель).

В смешанном объекте (hybrid object) содержатся повторяющиеся группы атрибутов, из которых по крайней мере один ссылается на другой объект. Типичный пример сме­шанного объекта это счет-фактура, представленный в на рис. 2.29. В этом случае счет содержит несколько товаров, а каждый товар представлен количеством продан­ных единиц и стоимостью единицы. Счет содержит повторяющиеся группы атрибу­тов (PROD_CODE, LINE_UNITS и LINE_PR1CE) для каждого проданного товара. Поэтому для представления этого объекта (счет) не требуется новый объект Inv_line, как это представлено в ER-модели.

Наконец, ассоциативный объект (associative object) используется для представления связи между двумя или более объектами. В ассоциативном объекте могут содержаться его собственные атрибуты, представляющие специфические свойства связи. Хоро­шим примером ассоциативного объекта является Enroll (см. рис. 2.25). В этом слу­чае объект Enroll связан с объектами Student и Class и включает в себя атрибут ENROLL_GRADE, представляющий собой оценку студента в группе.

В реальных моделях данных вы обнаружите множество примеров простых и состав­ных, смешанных и ассоциативных объектов. Мы подробно обсудим типы объектов далее в этой главе.

Свойства объектно-ориентированной модели данных

Объектно-ориентированные концепции, представленные в предыдущих разделах, представляют собой основные свойства объектно-ориентированной модели данных-ООМД (object-oriented data model, OODM), называемой также объектной моделью данных, ОМД (object data model, ODM). Объектная модель данных должна обладать, как минимум, следующими свойствами:

• поддерживать представление сложных объектов;
  
• обеспечивать расширение, т. е. должна иметься возможность определения новых
  типов данных, а также операций над ними;
  
• поддерживать инкапсуляцию, т. е. представление данных и реализация методов должны быть скрыты от внешних объектов;
  
• поддерживать наследование, т. е. любой объект может наследовать свойства
  (данные и методы) других объектов;
  
• обеспечивать идентификацию объекта (OID), описанную ранее в этой главе.
  

В учебных целях мы будем использовать определение и описание с помощью объ­ектно-ориентированной модели данных (ООМД) компонентов, которые по возмож­ности соответствуют компонентам ER-модели, описанным в гл. 3. Хотя все основ­ные базовые компоненты ООМД нами уже определены, их краткая сводка может оказаться нелишней при дальнейшем изучении материала.

• В ООМД сущности реального мира моделируются объектами.
  П Каждый объект состоит из атрибутов и набора методов.
  
• Каждый атрибут может ссылаться на другой объект или множество объектов.
  
• Атрибуты и реализации методов скрыты (инкапсулированы) от других объектов.
  
• Каждый объект идентифицируется уникальным идентификатором объекта (OID),
  не зависящим от значений атрибутов этого объекта.
  
• Схожие объекты группируются в класс, который содержит описание данных
  (атрибуты или переменные экземпляров) и реализации методов.
  
• Класс описывает тип объекта.
  
• Классы организованы в иерархию классов.
  
• Каждый объект класса наследует все свойства своего суперкласса в иерархии классов.
  

Используя это сводное описание ОО-компонентов, сравните их с описанием ER-компонентов (табл. П.З).

Таблица 11.3. Сравнение компонентов 00- и ER-моделей

11.4.1. Схемы объектов:

графическое представление объектов

Графически объект представляется в виде прямоугольника с именами переменных экземпляра. Вообще говоря, представление объекта соответствует всем объектам данного класса. Поэтому термины объект и класс на иллюстрациях часто взаимоза­меняемы. Помня об этом, исследуем графическое представление класса Person, представленное на рис. 11.14. В этом случае для переменных экземпляров NAME (имя), ADDRESS (адрес), DOB (дата рождения) и SEX (пол) используются базовый тип данных string, а для переменной экземпляра AGE (возраст) используется базо­вый тип integer.



Рис. 11.14. Представление для всех объектов класса Person

Теперь рассмотрим состояние экземпляра объекта Person (рис. 11.15). Обратите внимание, что переменную экземпляра объекта AGE можно рассматривать как производный (derived) атрибут. Производные атрибуты могут быть реализованы с помо­щью методов. Например, для класса Person мы можем создать метод с названием Age. Этот метод возвращает разницу (в годах) между текущей датой и днем рожде­ния (DOB) для данного экземпляра объекта. Поскольку методы могут создавать зна­чения производных атрибутов, методы предоставляют дополнительное преимущест­во инкапсуляции и наследования.



Рис. 11.15. Состояние экземпляра объекта Person

Необходимо помнить, что среда 00 позволяет создавать абстрактные типы данных (АТД) из основных типов. Например, NAME, ADDRESS и DOB являются сложными атрибутами, которые можно реализовать при помощи АТД. Для иллюстрации этого мы определили на рис. 11.16 Name, Address и DOB как абстрактные типы данных.



Рис. 11.16. Определение трех абстрактных типов данных

На рис. 11.16 обратите внимание, что класс Person теперь содержит атрибуты, кото­рые указывают на объекты других классов или абстрактные типы данных. Новые типы данных для каждой переменной экземпляра класса Person представлены на рис. 11.17.

Пространство объектов (object space), или схема объектов (object schema), использует­ся для представления состояния объекта в данный момент времени.




Рис 1.17. Представление объектов для экземпляров класса Person с абстрактными типами данных



Рис. 11.18. Состояние объекта для экземпляра класса Person, использующего абстрактные типы данных

Состояние объекта для экземпляра класса Person представлено на рис. П. 18. Здесь обратите внимание на использование идентификаторов объектов (OID) для ссылки на другие объекты. Например, в атрибутах NAME, ADDRESS и DOB теперь содер­жится OID экземпляра соответствующего класса или абстрактного типа данных вместо базового значения. Использование идентификатора OID для ссылки на объект позволяет избежать проблемы связности данных, которая может возникать в реля­ционных системах, если значение первичного ключа изменялось конечным пользо­вателем во время изменения состояния объекта.

Для иллюстрации этого факта в дальнейшем мы будем использовать приложение учета арендной собственности, с помощью которого будем отслеживать арендуемые помещения и проживающих в них лиц. В данном случае два человека, живущих по одному адресу, будут, скорее всего, ссылаться на один и тот же экземпляр объекта Address (рис. 11.19). Это условие иногда называют совместным использованием адре­суемых объектов (referential object sharing). Изменение в экземпляре объекта Address будет отражено в обоих экземплярах Person.

На рис. 11.19 представлено состояние двух различных экземпляров объектов класса Person; оба экземпляра объекта ссылаются на один и тот же экземпляр объекта Address. Обратите внимание, что рис. 11.19 отображает четыре разных класса АТД: Person (два экземпляра), Name (два экземпляра), Address и DOB (два экземпляра).



Рис. 11.19. Совместное использование объектов

11.4.2. Связи "класс-подкласс"

Вы помните, что класс наследует свойства своего суперкласса в иерархии? Это свой­ство приводит к использованию выражения "является" для описания связи между

классами в иерархии. То есть сотрудник является персоной и студент является пер­соной. Эта идея настолько важна, что требует более подробной иллюстрации иерар­хии класса (рис. 11.20).



Рис. 11.20. Иерархия классов

В иерархии, представленной на рис. II.20, объект Employee описывается семью ат­рибутами, представленными на рис. II.21. Номер социального страхования (SS#) записывается как базовый тип string, a SALARY (зарплата) — как базовый тип integer. Имя, адрес, дата рождения, пол и возраст — все наследуется от суперкласса

Person.



Рис. 11.21. Представление объекта Person

Этот пример основан на том факте, что ООМД поддерживает связь "класс-подкласс", для которой используются необходимые ограничения по целостности данных. Обратите внимание, что связь между суперклассом и подклассом относится к типу 1:М. То есть если мы имеем дело с единичным наследованием, то каждый суперкласс может иметь несколько подклассов, но каждый подкласс связан только с одним суперклассом.


11.4.3. Межобъектная связь "атрибут-класс"

Кроме поддержки связи "класс-подкласс", модель ООМД поддерживает связь "атрибут-класс". Эта связь (называемая также межобъектной связью — interobject ] relationship) создается в том случае, когда атрибуты объекта ссылаются на др; объект этого же или другого класса.

Межобъектная связь отличается от связи "класс-подкласс", которую мы только что изучили. Чтобы продемонстрировать эту разницу, исследуем иерархию класса для торгового предприятия EDLP (Every Day Low Prices, Ежедневное снижение цен). представленную на рис. 11.22.



Рис. 11.22. Иерархия классов для торгового предприятия EDPL

Обратите внимание, что все классы основаны на суперклассе Root Object. В иерар­хии имеются классы Manufacturer (изготовитель), Item (предмет), Person (персона) и Facility (подразделение). Класс Facility содержит подклассы Warehouse (склады) и Store (магазины). Класс Person содержит подкласс Employee (сотрудники), в кото­ром в свою очередь содержатся подклассы Manager (руководство), Clerk (чинов­ники), Secretary (секретари), Cashier (кассиры) и Stocker (кладовщики). Впослед­ствии мы будем использовать простую иерархию классов, представленную на рис. 11.22, для иллюстрации связей 1:М и M:N.

Представление связи 1:М

На основе данной иерархии классов (см. рис. 11.22) между Employee и Facility есть связь 1:М: каждый сотрудник работает в одном подразделении, но в каждом подразделении работает несколько сотрудников. На рис. 11.23 показано, как можно представить связь.




Рис. 11.23. Представление связи 1:М

Если внимательно посмотреть на связь между Employee и Facility, представленную на рис. 11.23, то можно заметить, что объект Facility включен в объект Employee и наоборот, объект Employee также включен в объект Facility. Для тщательного изуче­ния связей мы будем использовать следующие графические средства:

• чтобы подчеркнуть связи, связанные классы заключаются в прямоугольники;
  
• прямоугольник с двойной линией на правой стороне указывает на обязательную
  

связь;

• связность обозначается меткой у каждого прямоугольника. В данном случае сле­дом за Facility в объекте Employee записана единица, "1", указывающая, что каж­дый сотрудник работает только в одном подразделении. "М" рядом с Employee в объекте Facility указывает на то, что в каждом подразделении работает много со­трудников.
  

Обратите внимание, что для представления обязательной сущности и обозначения связности связи (1:М) используется ER-нотация. Это сделано для согласования с ранее приведенными в книге диаграммами.

Вместо того чтобы включить прямоугольник объекта в класс, мы предпочитаем ис­пользовать имена, описывающие свойства класса, которые мы моделируем. Это осо­бенно важно, когда два класса входят более чем в одну связь; в таких случаях лучше записывать имена атрибутов над прямоугольниками, изображающими класс, а в прямоугольнике указывать атрибут, с помощью которого можно ссылаться на этот пасс. Например, мы можем представить две связи между Employee и Facility с по­мощью WORKS_AT (работает в) и WORKERS (служащие), как показано на

рис. 11.24. Обратите внимание, что имеются две связи: связь 1:М, основанная на бизнес-правиле "в каждом подразделении работает множество сотрудников и каж­дый сотрудник работает только в одном подразделении" и связь 1:1, основанная на бизнес правиле "каждым подразделением руководит только один сотрудник, и каж­дый руководитель управляет только одним подразделением".



Рис. 11.24. Представление связей 1:1 и 1:М

Из рис. 11.24 следует, что связи представлены в обоих взаимодействующих классах. Это позволяет при необходимости инвертировать связь. Например, объект Facility внутри объекта Employee выражает отношение "руководит". В этом случае объект Facility необязателен и имеет максимальную связность 1. Объекты Employee и Facility представляют собой примеры сложных (compound) объектов. Другой тип связи (1:М) можно проиллюстрировать связью между сотрудниками и их иждивен­цами. Чтобы установить такую связь, мы, прежде всего, создадим подкласс Dependent (иждивенцы) на основе суперкласса Person. Обратите внимание, что мы не можем создать подкласс Dependent на основе класса Employee и его суперкласса, поскольку эта иерархия класса представляет связь "является". Другими словами, ка­ждый Manager (руководитель) является сотрудником (Employee), каждый Employee является Person (персоной), каждый иждивенец является Person (персоной) и каж­дая персона (Person) является объектом (Object) в нашем пространстве объектов -но каждый иждивенец (Dependent) не является сотрудником (Employee). На рис. 11.25 показано корректное представление связи между Employee и Dependent.

На рис. 11.25 обратите внимание, что объект Dependent необязателен для объекта Employee, и объект Dependent связан с объектом Employee связью 1:М. Однако объ­ект Employee обязателен для объекта Dependent. В объектно-ориентированной модем

данных исчезает понятие слабой сущности, поскольку каждый объект идентифициру­ется своим уникальным OID.



Рис. 11.25. Связь Employee-Dependent

Представление связи M:N

На основе иерархии классов упомянутого выше торгового предприятия EDLP тип связи M:N можно продемонстрировать на примере связи между Manufacturer и Item, как это показано на рис. 11.26. Здесь представлено условие, при котором каждый предмет (Item) может производиться многими производителями (Manufacturer), и каждый производитель (Manufacturer) может выпускать множество предметов (Item). Поэтому рис. 11.26 представляет собой концептуальное представление связи M:N между Item и Manufacturer. В этом представлении Item и Manufacturer являются сложными (compound) объектами.

Также отметим, что на атрибут CONTACT (контакты) в классе Manufacturer на рис. 11.26 ссылается только один экземпляр класса Person. Здесь может возникнуть небольшое недоразумение: по всей видимости, у каждого контактного лица (персоны) имеется телефон, но мы не включили атрибут "номер телефона" в класс Person. В данном случае проектировщик может добавить этот атрибут, чтобы он был доступен всем подклассам класса Person.

Представление связи M:N с классом пересечения

Предположим, что мы добавили к только что исследованному классу Item условие, позволяющее отслеживать дополнительную информацию по каждому предмету (Item). Например, представим связь между Item и Facility таким образом, что в каж­дом подразделении (Facility) может находиться несколько предметов (Item) и каж­дый предмет может находиться в нескольких подразделениях. Кроме того, нам не­обходимо отслеживать количество и местоположение (проход и ряд на складе, например) каждого предмета в каждом подразделении. Это условие представлено на рис. 11.27. Правая





Рис. 11.27. Представление связи M:N с ассоциированными атрибутами




скобка (]) на рис. 11.27 указывает, что заключенные в нее атрибу­ты рассматриваются как логическая единица. Поэтому каждый экземпляр Item мо­жет содержать несколько вхождений Facility, каждое из которых сопровождается соответствующими значениями атрибутов AISLE (проход), ROW (ряд) и QTY_ON_HAND (имеющееся количество). Верно и обратное для каждого экземп­ляра Facility. Объекты Item и Facility в данном отношении являются смешанными (hybrid) с повторяющимися группами атрибутов. Отметим: семантика требует, что для определения прохода, ряда и количества каждого предмета необходимо в первую очередь обращаться к объектам Item и Facility.

Чтобы это описание связи M:N больше соответствовало реляционному представле­нию, необходимо определить класс пересечения — мост (intersection class) для соеди­нения Facility и Item и хранения связанных с ними атрибутов. В данном случае мы можем создать класс ассоциативного объекта Stockedltem (хранимые предметы) для размещения в нем экземпляров объектов Facility и Item и значений каждого из ат­рибутов ASILE, ROW и QTYONHAND. Такой класс эквивалентен конструкции lnterclass_Connection семантической модели данных. На рис. 11.28 показано, как представляются экземпляры объектов Item, Facility и Stocked_Item.



Рис. 11.28. Представление связи M:N с классом пересечения

Изучив представление основных ОО-отношений, мы можем представить простран­ство объектов в том виде, как это показано на рис. 11.29.

На рис. П.29 много важной для проектирования информации; необходимо обратить особое внимание на следующее:

• экземпляр ассоциативного объекта Stockedltem содержит в себе ссылки на эк­земпляры каждого связанного с ним класса (Item и Facility). Класс пересечения
  Stocked_Item необходим, только если нужно отслеживать дополнительную ин­
  формацию, о которой мы говорили выше;
  
• в экземпляре объекта Item в этой схеме содержится набор экземпляров объекта Stocked_Item, каждый из которых содержит экземпляр объекта Facility. Инверсия этого отношения также верна: экземпляр объекта Facility содержит набор экзем­пляров объекта Stocked_Item, каждый из которых содержит экземпляр объекта Item. Необходимо понимать, что эти две связи представляют два разных вида од­ной и той же схемы объекта;
  
• при ссылках на объекты для получения доступа к объектам и включения их в
  пространство объекта используется OID;
  
• значения внутри квадратных скобок ([ и ]) представляют собой 01D экземпляра объекта некоторого класса. Классы "набор из" представляют собой класс объек­тов, в которых каждый экземпляр объекта содержит набор объектов некоторого класса. Например, Z3402 и Z45621 представляют собой ссылки на объекты, кото­рые состоят из набора Manufacturer (производители) и набора Stockedltem (хранимые предметы) соответственно;
  

Рис. 11.29. Представление пространства объектов

• в реляционной модели таблица ITEM не содержит каких-либо данных, связан­ных с Manufacturer или Stocked_Item в своей структуре. Здесь для представления информации (составной) о ITEM, Stockedltem и Facility мы должны выполнить реляционный оператор JOIN. В ООМД нет необходимости использовать опера­тор JOIN, чтобы комбинировать данные из разных объектов, поскольку объект ITEM содержит в себе ссылки на связанные с ним объекты; эти ссылки автома­тически вводятся в пространство объекта при получении доступа к объекту ITEM.
  

11.4.4. Позднее и раннее связывание: предназначение и использование

Возможность размещения в атрибуте других объектов, определяющих в разное время различные типы данных (или классы), — очень привлекательное свойство ООМД. При этом данный объект может содержать числовое значение данной переменной экземпляра, а следующий объект (того же класса) может содержать строковое значе­ние этой же переменной экземпляра. Это свойство достигается с помощью позднего связывания. Позднее связывание (late binding) атрибута с типом данных неизвестно до момента выполнения (прогона). Поэтому два различных экземпляра объекта одного и того же класса могут содержать значения различных типов данных для одного и того же атрибута.

В противоположность ООМД, где имеется возможность позднего связывания, в тра­диционных СУБД требуется, чтобы базовый тип данных был определен для каждого атрибута при его создании. Предположим, что нам необходимо определить сущ­ность INVENTORY (склад) со следующими атрибутами: ITEM_TYPE (тип), DESCRIPTION (описание), VENDOR (поставщик), WEIGHT (вес) и PRICE (стоимость). В традиционных СУБД вы создаете таблицу с именем INVENTORY и присваиваете тип данных каждому атрибуту, как это показано на рис. 11.30.



Рис. 11.30. Таблица INVENTORY с предопределенными (базовыми) типами данных

Из предыдущих глав вам известно, что при работе с традиционными СУБД проек­тировщик должен определить тип данных для каждого атрибута во время определения структуры таблицы. Такой подход определения типа данных называется ранним связыванием (early binding). Раннее связывание позволяет проверять тип данных каж­дого значения атрибута во время компиляции и определения таблиц. Например, атрибут ITEMTYPE на рис. 11.30 ограничен числовым значением. Точно так же

атрибут VENDOR может содержать только числовые значения, чтобы соответство­вать первичному ключу некоторой строки в таблице VENDOR, которые тоже огра­ничиваются числовыми значениями.

Теперь взглянем на рис. 11.31, чтобы узнать, как в ООМД решается задача раннего связывания. Как и в традиционных СУБД, модель ООМД допускает определение типов данных на этапе проектирования. Однако в отличие от традиционных СУБД, в ООМД пользователю разрешается определять абстрактные типы данных (АТД). В данном примере, где представлено раннее связывание, абстрактные типы данных Inv_type, String_of_characters, Vendor, Weight и Money ассоциированы с переменны­ми экземпляра на этапе их определения. Поэтому проектировщик может определить необходимые операции для каждого типа данных. Например, тип данных Weigh! может иметь методы для вывода веса предмета в фунтах, килограммах и т. д. Точно так же тип данных Money может обладать методами, возвращающими стоимость в цифрах и символах для пересчета в доллары США ($), евро (€) или английские фун­ты (£). Следует помнить, что абстрактные типы данных реализуются через классы.



Рис. 11.31. Класс INVENTORY с ранним связыванием

В средах с поздним связыванием тип данных атрибута объекта до его использования неизвестен. Поэтому любой атрибут может иметь любой тип присваиваемого ему значения. С помощью представленных ранее базовых типов данных на рис. П.32 показаны атрибуты (переменные экземпляра) INV_TYPE, DESCRIPTION, VENDOR, WEIGHT и PRICE без предварительного определения типа данных. По­скольку для переменных экземпляра класса типы данных заранее не определяются, два разных объекта класса INVENTORY могут иметь разные типы данных атрибута. Например, атрибуту INV_TYPE может быть присвоено символьное (строковое) зна­чение в одном экземпляре и численное значение в другом. Позднее связывание также играет важную роль в полиморфизме и позволяет объектам выбирать реализа­цию метода, которую необходимо использовать во время выполнения.



Рис. 11.32. Класс INVENTORY модели ООМД с поздним связыванием

11.4.5. Поддержка контроля версий

Контроль версий (versioning) представляет собой функциональную возможность моде­ли ООМД, позволяющую отслеживать историю изменений состояния объекта. Кон­троль версий — весьма мощное и полезное свойство, особенно в среде автоматизи­рованного проектирования (CAD, Computer Aided Design). Например, инженер с помощью системы CAD может загружать компоненты проекта на свою рабочую станцию, вносить некоторые изменения и видеть, как эти изменения влияют на взаимодействие компонентов. Если внесенные изменения не дают ожидаемого ре­зультата, инженер может отменить все действия и восстановить компоненты в их оригинальное состояние. Возможность контроля версий является одной из причин, по которой ООСУБД играют ведущую роль в системах CAD/САМ (системы автома­тизированного проектирования и изготовления).

11.5. ООМД и прежние модели данных: сходство и различие

Несмотря на то что ООМД внешне очень похожа на реляционную модель или ER-модель, она по своей основе сильно отличается от них. Далее приводится подробная сводка всех основных свойств модели ООМД, представленных в этой главе.

11.5.1. Объект, сущность и кортеж

Концепция объекта в ООМД расширяет прежнее понятие сущности (entity) или кор­тежа (tuple) из других моделей данных. Хотя объект ООМД очень напоминает сущ­ность и кортеж в ER-модели и реляционной схеме, все же объект ООМД обладает

важными дополнительными свойствами, такими как поведение, наследование и инкапсуляция. Эти замечательные свойства ООМД делают ОО-моделирование более приближенным к реальной действительности, чем ER-моделирование и реляционное моделирование. Фактически ER-моделирование и реляционные модели час вынуждают проектировщика создавать новые искусственные сущности для то: чтобы выразить объекты реального мира. Например, в ER-модели счет-факт} обычно представляется двумя отдельными сущностями; вторая сущность (LINE строка) обычно является слабой, поскольку зависит от первой (INVOICE — счет) ее первичный ключ частично производится из сущности INVOICE (рис. П.33).



Рис. 11.33. Представление счета-фактуры в ER-модели

На рис. II.33 видно, что при ER-подходе к моделированию реальной сущности "счет-фактура" требуется использование двух различных сущностей. Такая искусст­венная конструкция продиктована ограничениями на наследование в реляционной модели. Искусственное представление ER-модели приводит к дополнительным не­производительным издержкам в основной системе. В отличие от этого объект INVOICE в ООМД напрямую моделируется как объект в пространстве объекта или в схеме объекта.

11.5.2. Класс, набор сущностей и таблица

Понятие класс можно увязать с понятиями набор сущностей и таблица в ER-модели и реляционной модели соответственно. Однако класс представляет собой более мощное понятие, позволяющее описывать не только структуру данных, но и пове­дение объектов класса. Класс также позволяет определить и реализовать в модели ООМД абстрактные типы данных (АТД). АТД являются мощным средством модели­рования, поскольку они позволяют конечным пользователям создавать новые типы данных и использовать их как традиционные типы данных в среде БД. Таким обра­зом, АТД усиливают семантическое содержимое моделируемых объектов.

11.5.3. Инкапсуляция и наследование

Абстрактные типы данных (АТД) предоставляют нам и две другие ОО-возможности, не поддерживаемые предыдущими моделями — инкапсуляцию и наследование. Классы организуются в иерархии классов. Объект, принадлежащий классу, наследу­ет все свойства его суперкласса. Инкапсуляция означает, что представление данных и реализация методов скрыты от других объектов и от конечного пользователя. В модели ООМД только методы могут получать доступ к переменным экземпляра. В отличие от этого к компонентам данных или полям в традиционных системах можно получить прямой доступ из внешней среды.

В традиционных моделях отсутствуют методы, составляющие основу ООМД. Наибо­лее близкое понятие к методам представляют собой триггеры и хранимые процедуры в базах данных SQL. Однако поскольку в триггерах не используются преимущества инкапсуляции и наследования, свойственные методам ООМД, триггеры не могут обеспечить тех же функциональных возможностей.

11.5.4. Идентификатор объекта (OID)

Идентификатор объекта (OID) не поддерживается ни в ER-моделировании, ни в реляционных моделях. Хотя пользователи БД могут возразить, что Sequences в Oracle и AutoNumber в MS Access предоставляют возможность идентификации, однако это справедливо только в рамках уникальной идентификации элементов данных. К тому же в отличие от объектной модели, в которой связи явно не выражены, реляцион­ная модель использует связи, основанные на значениях, например:

SELECT *

FROM INVOICE, INV_LINE

WHERE INVOICE.INV_ID » INV_LINE.INV_ID;

Иерархические модели и модели CODASIL поддерживают некоторые формы иден­тификации, которые можно считать похожими на OID, что является аргументом в пользу исследователей, утверждающих, что развитие 00 является шагом назад к старым системам указателей. Поэтому они считают, что ОО-системы возвращают нас к сложному моделированию и реализации, типичным для иерархических и сете­вых моделей.

11.5.5. Связи

Основное свойство любой модели данных основано на представлении связей (relationships) между компонентами данных. В ООМД есть связи двух типов: ссылки между классами или наследование в иерархии классов. ER- и реляционные модели используют связи на основе значений. Это означает, что связи между сущностями устанавливаются через общие значения в одном или нескольких атрибутах сущности (концептуально это очень просто представить и отобразить!). В отличие от этого в ООМД для связей между объектами используется подход, основанный на иденти­фикации (OID), поэтому связи не зависят от состояния объекта (это свойство уп­рощает работу с объектами БД и пользоватьскими приложениями, но за это удобст­во приходится платить повышенной концептуальной сложностью).