Понятие класса и объекта. Что может быть объектом. Атрибут и операции. Объектно-ориентированные технологии проектирования прикладных программных систем

ER -диаграммы

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

В примере менеджера турфирмы имеются 5 основных объектов:

Туристы

Путевки

Отношения между этими объектами могут быть определены простыми терминами:

Каждый турист может купить одну или несколько (много) путевок.

Каждой путевке соответствует ее оплата (оплат может быть и несколько, если путевка, например, продана в кредит).

Каждый тур может иметь несколько сезонов.

Путевка продается на один сезон одного тура.

Эти объекты и отношения могут быть представлены ER- диаграммой, как показано на рис 2.

Рис. 2. ER-диаграмма для приложения БД менеджера турфирмы

Объекты, атрибуты и ключи

Далее модель развивается путем определения атрибутов для каждого объекта. Атрибуты объекта - это элементы данных, относящиеся к определенному объекту, которые должны сохраняться. Анализируем составленный словарь данных, выделяем в нем объекты и их атрибуты, расширяем словарь при необходимости. Атрибуты для каждого объекта в рассматриваемом примере представлены в таблице 2.

Таблица 2. Объекты и атрибуты БД

Объект	Туристы	Путевки	Туры	Сезоны	Оплаты
			Название	Дата начала	Дата оплаты
				Дата конца
	Отчество		Информация
Атрибуты
Атрибуты

Следует обратить внимание, что несколько элементов отсутствуют. Опущена регистрационная информация, упомянутая в функциональной спецификации. Как ее учесть, вы подумаете самостоятельно и доработаете предложенный пример. Но более важно то, что пока отсутствуют атрибуты, необходимые для связи объектов друг с другом. Эти элементы данных в ER-модели не представляются, так как не являются, собственно, «натуральными» атрибутами объектов. Они обрабатываются по-другому и будут учтены в реляционной модели данных.

Реляционная модель характеризуется использованием ключей и отношений. Существует отличие в контексте реляционной базы данных терминов relation (отношение) и relationship (схема данных). Отношение рассматривается как неупорядоченная, двумерная таблица с несвязанными строками. Схема данных формируется между отношениями (таблицами) через общие атрибуты, которые являются ключами.

Существует несколько типов ключей, и они иногда отличаются только с точки зрения их взаимосвязи с другими атрибутами и отношениями. Первичный ключ уникально идентифицирует строку в отношении (таблице), и каждое отношение может иметь только один первичный ключ, даже если больше чем один атрибут является уникальным. В некоторых случаях требуется более одного атрибута для идентификации строк в отношении. Совокупность этих атрибутов называется составным ключом. В других случаях первичный ключ должен быть специально создан (сгенерирован). Например, в отношение «Туристы» имеет смысл добавить уникальный идентификатор туриста (код туриста) в виде первичного ключа этого отношения для организации связей с другими отношениями БД.

Другой тип ключа, называемый внешним ключом, существует только в терминах схемы данных между двумя отношениями. Внешний ключ в отношении - это атрибут, который является первичным ключом (или частью первичного ключа) в другом отношении. Это - распределенный атрибут, который формирует схему данных между двумя отношениями в БД.

Для проектируемой БД расширим атрибуты объектов кодовыми полями в качестве первичных ключей и используем эти коды в отношениях БД для ссылки на объекты БД следующим образом (табл. 3).

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

Таблица 3. Объекты и атрибуты БД с расширенными кодовыми полями

Объект	Туристы	Путевки	Туры	Сезоны	Оплаты
Атрибуты	Код туриста	Код путевки		Код сезона	Код оплаты
		Код туриста	Название	Дата начала	Дата оплаты
		Код сезона		Дата конца
	Отчество		Информация		Код путевки

Нормализация

Функциональные зависимости проявляются, когда значение одного атрибута может быть определено из значения другого атрибута. Атрибут, который может быть определен, называется функционально зависимым от атрибута, который является детерминантом. Следовательно, по определению, все неключевые (без ключа) атрибуты будут функционально зависеть от первичного ключа в каждом отношении (так как первичный ключ уникально определяет каждую строку). Когда один атрибут отношения уникально не определяет другой атрибут, но ограничивает его набором предопределенных значений, это называется многозначной зависимостью. Частичная зависимость имеет место, когда атрибут отношения функционально зависит от одного атрибута составного ключа. Транзитивные зависимости наблюдаются, когда неключевой атрибут функционально зависит от одного или нескольких других неключевых атрибутов в отношении.

Процесс нормализации состоит в пошаговом построении БД в нормальной форме (НФ).

1. Первая нормальная форма (1НФ) очень проста. Все таблицы БД должны удовлетворять единственному требованию - каждая ячейка в таблицах должна содержать атомарное значение, другими словами, хранимое значение в рамках предметной области приложения БД не должно иметь внутренней структуры, элементы которой могут потребоваться приложению.

2. Вторая нормальная форма (2НФ) создается тогда, когда удалены все частичные зависимости из отношений БД. Если в отношениях не имеется никаких составных ключей, то этот уровень нормализации легко достигается.

3. Третья нормальная форма (3НФ) БД требует удаления всех транзитивных зависимостей.

4. Четвертая нормальная форма (4НФ) создается при удалении всех многозначных зависимостей.

БД нашего примера находится в 1НФ, так как все поля таблиц БД атомарные по своему содержанию. Наша БД также находится и во 2НФ, так как мы искусственно ввели в каждую таблицу уникальные коды для каждого объекта (Код Туриста, Код Путевки и т. д.), за счет чего и добились 2НФ для каждой из таблиц БД и всей базы данных в целом. Осталось разобраться с третьей и четвертой нормальными формами.

Обратите внимание, что они существуют только относительно различных видов зависимостей атрибутов БД. Есть зависимости - нужно стоить НФ БД, нет зависимостей - БД и так находится в НФ. Но последний вариант практически не встречается в реальных приложениях.

Итак, какие же транзитивные и многозначные зависимости присутствуют в нашем примере БД менеджера турфирмы?

Давайте проанализируем отношение «Туристы». Рассмотрим зависимости между атрибутами «Код туриста», «Фамилия», «Имя», «Отчество» и «Паспорт» (рис. 3). Каждый турист, представленный в отношении сочетанием «Фамилия- Имя-Отчество», имеет на время поездки только один паспорт, при этом полные тезки должны иметь разные номера паспортов. Поэтому атрибуты «Фамилия- Имя-Отчество» и «Паспорт» образуют в отношении туристы составной ключ.

Рис. 3. Пример транзитивной зависимости

Как видно из рисунка, атрибут «Паспорт» транзитивно зависит от ключа «Код туриста». Поэтому, чтобы исключить данную транзитивную зависимость, разобьем составной ключ отношения и само отношение на 2 по связям «один-к-одному». В первое отношение, оставим ему имя «Туристы», включаются атрибуты «Код туриста» и «Фамилия», «Имя», «Отчество». Второе отношение, назовем его «Информация о туристах», образуют атрибуты «Код туриста» и все оставшиеся атрибуты отношения «Туристы»: «Паспорт», «Телефон», «Город», «Страна», «Индекс». Эти два новых отношения уже не имеют транзитивной зависимости и находятся в 3НФ.

Многозначные зависимости в нашей упрощенной БД отсутствуют. Для примера предположим, что для каждого туриста должны храниться несколько контактных телефонов (домашний, рабочий, сотовый и пр., что весьма характерно на практике), а не один, как в примере. Получаем многозначную зависимость ключа - «Код туриста» и атрибутов «Тип телефона» и «Телефон», в этой ситуации ключ перестает быть ключом. Что делать? Проблема решается также путем разбиения схемы отношения на 2 новые схемы. Одна из них должна представлять информацию о телефонах (отношение «Телефоны»), а вторая о туристах (отношение «Туристы»), которые связываются по полю «Код туриста». «Код туриста» в отношении «Туристы» будет первичным ключом, а в отношении «Телефоны» - внешним.

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

Если значение описательного атрибута меняется, это говорит о том, что данный аспект экземпляра объекта изменен, но объект остался прежним.

Указывающие атрибуты используются для задания имени или обозначения экземпляра.

Указывающие атрибуты используются как идентификаторы объекта.

Вспомогательные атрибуты используются для связи экземпляра одного объекта с экземпляром другого объекта. Например, экземпляра объекта «Микросхема» с экземпляром «Схема электрическая принципиальная».

Если значение вспомогательного атрибута изменяется, то это говорит о том, что теперь другие экземпляры объекта связаны между собой.

Описание атрибутов

Для описательных атрибутов описание устанавливает реальную характеристику, абстрагируемую как атрибут.

В этом случае описание дается в виде:

Перечислением всех возможных значений, которые атрибут может принимать;

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

Определением диапазона возможных значений.

Описание значений указывающего атрибута определяет форму указания и в какой степени этот атрибут может использоваться как идентификатор.

Описание вспомогательного атрибута должно содержать описание реального отношения, определяемое атрибутом.

Правила атрибутов

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

1-е правило атрибута

Один экземпляр объекта имеет одно единственное значение для каждого атрибута в любое данное время.

2-е правило атрибута

Атрибут не должен иметь никакой внутренней структуры. Все атрибуты простые.

3-е правило атрибута

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

Связи между объектами

Связи – это абстракция набора отношений, которые систематически возникают между различными видами предметов в реальном мире.

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

Пример: схема включает элементы – элементы входят в состав схемы.

Связь графически представляется линией между соотносимыми элементами.

Пример: возьмем экономический объект:

Связи непосредственного отношения разделяются на:

Безусловные связи

Условные связи

Среди безусловных связей выделяются 3 фундаментальных типа связей. Это связи:

«Один к одному» – связь, при которой один экземпляр одного объекта связан с одним экземпляром другого объекта

«Один ко многим» – связь, при которой один экземпляр некоторого объекта связан с одним или более экземплярами другого объекта, при этом каждый экземпляр другого объекта связан только с одним экземпляром первого объекта

«Многие ко многим» – связь, при которой один экземпляр некоторого объекта связан с одним или более экземплярами другого объекта и каждый экземпляр другого объекта связан с одним или более экземплярами первого.

2-й тип связи отношений – условные связи.

У условной связи могут существовать такие экземпляры объекта, которые не принимают участие в связи.

Например:

Все связи требуют описания. Описание включает:

Идентификатор связи

Формулировку имен связи с точки зрения участвующих объектов

Вид связи (ее множественность и условность)

Формулировку того, как связь была формализована (почему мы эту связь вводим)

Формализация связи (ее определение) состоит а том, чтобы установить связи экземпляров объекта. Делается это с помощью вспомогательных средств.

Если в объекте есть вспомогательные атрибуты, то говорят, что связь формализована.

Для формализации связи «один ко многим» вспомогательный атрибут устанавливается на стороне «много».

Если у нас существует связь «многие ко многим», чтобы не нарушить 3-е правило атрибутов создают вспомогательный (ассоциативный) объект, который содержит ссылки на идентификаторе каждого участвующего экземпляра.

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

Если в информационных моделях существует наследование, то существуют подтипы и супертипы.

Супертип – это родительский объект.

Подтип – это порожденный объект.

ER-диаграммы

Логическая модель

В примере менеджера турфирмы имеются 5 основных объектов:

Туристы

Путевки

Отношения между этими объектами могут быть определены простыми терминами:

Каждый турист может купить одну или несколько (много) путевок.

Каждый тур может иметь несколько сезонов.

Путевка продается на один сезон одного тура.

Эти объекты и отношения могут быть представлены ER- диаграммой, как показано на рис 2.

Рисунок 3.2. ER-диаграмма для приложения БД менеджера турфирмы

Таблица 3.2. Объекты и атрибуты БД

Таблица 3.3. Объекты и атрибуты БД с расширенными кодовыми полями

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

У хранимого бизнес-объекта могут быть и хранимые, и нехранимые атрибуты. Хранимые атрибуты бизнес-объекта связаны со столбцами таблицы или производной таблицы базы данных. Все атрибуты нехранимых бизнес-объектов - это нехранимые атрибуты.

В дополнение к основной информации о типах данных продукт хранит дополнительные метаданные, связанные с атрибутами бизнес-объекта. Например, у атрибута может быть домен, пользовательский класс или значение по умолчанию; можно указать, что атрибут - это обязательный атрибут.

Ограничения атрибутов

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

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

Некоторые ограничения зависят от того, разрешен ли текстовый поиск объекта или поиск по типу данных. Правила, управляющие изменениями, зависят от атрибута. Например, у данных некоторых типов есть заданное значение по длине, масштабу, датам или целым числам. Данные в поле Записка - это обычные данные типа ALN, и это поле не содержит ограниченных значений.

Для управления ограничениями атрибутов можно выполнить следующие действия:

Просматривать ограничения для атрибутов текущего объекта
Ограничивать атрибуты объекта
Удалять ограничения для атрибутов объекта

2.1.2. Атрибуты объектов

Атрибут - это значение, характеризующее объект в его классе. Примеры атрибутов: категория, баланс, кредит (атрибуты объектов класса счет); имя, возраст, вес (атрибуты объектов класса человек) и т.д.

Среди атрибутов различаются постоянные атрибуты (константы) и переменные атрибуты . Постоянные атрибуты характеризуют объект в его классе (например, номер счета, категория, имя человека и т.п.). Текущие значения переменных атрибутов характеризуют текущее состояние объекта (например, баланс счета, возраст человека и т.п.); изменяя значения этих атрибутов, мы изменяем состояние объекта.

Атрибуты перечисляются во второй части прямоугольника, изображающего класс (см. рисунок 2.1). Иногда указывается тип атрибутов (ведь каждый атрибут - это некоторое значение) и начальное значение переменных атрибутов (совокупность начальных значений этих атрибутов задает начальное состояние объекта).

Следует отметить, что, говоря об объектах и их классах, мы не подразумеваем никакого объектно-ориентированного языка программирования. Это, в частности, выражается в том, что на данном этапе разработки программной системы следует рассматривать только такие атрибуты, которые имеют смысл в реальности (все атрибуты объектов класса счет - рисунок 2.1 - обладают этим свойством). Атрибуты связаны с особенностями общей реализации. Например, если известно, что будет использоваться база данных, в которой каждый объект имеет уникальный идентификатор, то включать этот идентификатор в число атрибутов объекта на данном этапе не следует. Дело в том, что, вводя такие атрибуты, мы ограничиваем возможности реализации системы. Так, вводя в качестве атрибута уникальный идентификатор объекта в базе данных, мы уже в самом начале проектирования отказываемся от использования СУБД, которые такой идентификатор не поддерживают.