Итак, перечислим основные отличия между моделью "сущность-отношение" и соответствующей моделью типов (классов):
•    Диаграмма не просто описывает данные, но и отображает методы, которые инкапсулированы в эти данные. Например, указывается, что метод класса Student предназначен для записи (Book) студента на конкретный курс (название которого передается как аргумент — Course). Что интересно: среди методов класса Course также есть запись студента. Это достигается с помощью передачи объекта класса Student в качестве аргумента.
•    Типы данных здесь гораздо разнообразнее и сложнее, чем в модели "сущность-отношение". Например, у нас есть тип, который предназначен для хранения имени лица и который, вероятно, будет содержать подтипы для фамилии, имени и должности. Это гораздо больше, чем можно сделать с традиционными доменами.
•    Это лишь одно представление модели типов. Tutor, который входит в класс Course, может быть полноправным объектом. Классы иногда включают другие классы. Week Map, содержащий перечень часовых интервалов на неделю, также может быть моделью. Week Map используется для указания занятий, которые посещает студент-заочник, и недельного расписания курса. Хотелось бы иметь метод, позволяющий путем логического умножения двух таких Week Map определить, может ли студент-заочник посещать данный курс.
•    PartTime и FullTime — это подтипы класса Student. Они наследуют все свойства и методы данного класса и, кроме того, имеют собственные свойства и методы. Одной из наиболее важных задач в ООАП является организация иерархий классов. К сожалению, OracleS не поддерживает принцип наследования.
Из этой модели видно, что можно породить и структуру класса, и устойчивую структуру базы данных. Методы инкапсулированы в свои классы и будут реализованы как инкапсулированные функции и процедуры. Встроенные или вложенные объекты (например, Tutor в нашем примере) могут быть реализованы как ссылки. Отношение "многие ко многим" между студентами и курсами у нас в примере довольно интересно. Мы могли бы пройти по реляционному маршруту и ввести промежуточную сущность (intersection entity), назвав ее Course Booking. Другой вариант — создать массив VARRAY для ссылок на класс Course в нашем объекте Students и массив VARRAY для ссылок на Students в объекте Courses. Эта реализация была бы очень интересной — при условии, что мы смогли бы обеспечить синхронизацию двух вышеупомянутых составляющих.
В данном разделе вводятся некоторые понятия объектного моделирования. Конечно, это обширный предмет, о котором написано много хороших книг. Мы не рекомендуем его использовать, и поэтому не слишком углубляемся в него. Если вы создадите прекрасную чисто объектно-ориентированную модель, то, вероятно, будете сильно разочарованы, обнаружив, что не можете реализовать основную ее часть в OracleS!
2. Методы проектирования для OracleS	25