Типы атрибутов объекта. Объекты, атрибуты и ключи. Определение состава множества

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

Государственное образовательное учреждение высшего профессионального образования

Российский экономический университет имени Г.В. Плеханова

Уфимский институт (филиал)

Факультет экономики и менеджмента

Курс 2

Специальность 230700.62 Прикладная информатика

Габбасов Тимур Айдарович

Курсовая работа

По дисциплине: «Программная инженерия»

На тему: «Понятие класса и объекта. Что может быть объектом. Атрибут и операции»

Руководитель: Садртдинов Ф.А.

Уфа 2014

Введение ……………………………………………………………………….3

1.Понятие объекта в программировании …………………………………4

2.Определение класса ………………………………………………………..6

2.1.Атрибуты классов ………………………………………………………..7

2.2.Операции ………………………………………………………………….8

2.3.Зависимости между классами, объектами …………………………..11

Заключение ………………………………………………………………….15

Список используемой литературы……………………………………….17

Введение

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

Предмет исследования - понятие класса и объекта.

Объект исследования - объект и класс, и их взаимосвязь с атрибутом и операциями.

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

Задачи:

1.Изучить понятия объект и класс.

2.Привести примеры
3.Изучить понятия атрибут и операция.

4.Указать роль в концепции объектно-ориентированного программирования.

1.Понятие объекта в программировании

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

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

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

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

Приведем общие признаки объектов.

Объект распознаваем, т.е. имеет некоторые, возможно не четко очерченные, границы.

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

Объект проявляет свои свойства при взаимодействии с другими объектами. Это свойство иногда называют поведением объекта.

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

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

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

Свойства объекта позволяют отличить понятие “объект” от некоторым образом противоположного ему понятия “класс”.

2.Определение класса

В класс объединяются объекты с одинаковыми свойствами и методами.

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

Использование иерархии классов вводит необходимость абстракции. Классы становятся более абстрактными по мере продвижения вверх по иерархии.

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

Класс - это абстрактное понятие, сравнимое с понятием категория в его обычном смысле.

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

Это можно пояснить на примере музыкальных инструментов. Музыкальные инструменты делятся на следующие категории: духовые, ударные и струнные.

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

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

Рис 2.1 Рис.2.2

2.1.Атрибуты классов

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

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

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

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

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

2.2.Операция

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

Рис3.1

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

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

Каждой операции соответствует метод - реализация этой операции для объектов данного класса. Таким образом, операция - это спецификация метода, метод - реализация операции. Например, в классе файл может быть определена операция печать (print). Эта операция может быть реализована разными методами: (а) печать двоичного файла; (б) печать текстового файла и др. Логически эти методы выполняют одну и ту же операцию, хотя реализуются они разными фрагментами кода.

Каждая операция имеет один неявный аргумент - объект к которому она применяется. Кроме того, операция может иметь и другие аргументы (параметры). Эти дополнительные аргументы параметризуют операцию, но не связаны с выбором метода. Метод связан только с классом и объектом (некоторые объектно-ориентированные языки, например C++, допускают одну и ту же операцию с разным числом аргументов, причем используя то или иное число аргументов, мы практически выбираем один из методов, связанных с такой операцией; на этапе предварительного проектирования системы удобнее считать эти операции различными, давая им разные имена, чтобы не усложнять проектирование).

Операция (и реализующие ее методы) определяется своей сигнатурой, которая включает, помимо имени операции, типы (классы) всех ее аргументов и тип (класс) результата (возвращаемого значения). Все методы, реализующие операцию должны иметь такую же сигнатуру, что и реализуемая ими операция.

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

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

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

Рис 3.2 Открытые и закрытые атрибуты и операции

Запросы без аргументов (за исключением неявного аргумента - объекта, к которому применяется операция) могут рассматриваться как производные атрибуты. Значения производных атрибутов зависят от значений основных атрибутов. В этом их отличие от основных атрибутов, значения которых независимы. Следовательно, значения основных атрибутов объекта определяют как его состояние, так и значения его производных атрибутов. Так, например, длина, ширина и высота комнаты - ее основные атрибуты, а площадь и кубатура - производные атрибуты; такой атрибут как кубатура нужен для того, чтобы не вычислять кубатуру комнаты всякий раз, когда понадобится ее значение.

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

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

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

Рис. 2.5. Возможные классы для системы AMT (банковское обслуживание)

2.3.Зависимости между классами, объектами

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

Между объектами можно устанавливать зависимости по данным. Эти зависимости выражают связи или отношения между классами указанных объектов. Примеры таких зависимостей изображены на рисунке 3.6 (первые две зависимости - бинарные, третья зависимость - тренарная). Зависимость изображается линией, соединяющей классы над которой надписано имя этой зависимости, или указаны роли объектов (классов) в этой зависимости (указание ролей - наиболее удобный способ идентификации зависимости).

Рис. 3.6. Зависимости между классами

Зависимости между классами являются двусторонними: все классы в зависимости равноправны. Это так даже в тех случаях, когда имя зависимости как бы вносит направление в эту зависимость. Так, в первом примере на рисунке 3.6 имя зависимости «имеет столицу» предполагает, что зависимость направлена от класса страна к классу город (двусторонность зависимости вроде бы пропала); но следует иметь в виду, что эта зависимость двусторонняя в том смысле, что одновременно с ней существует и обратная зависимость является столицей. Точно таким же образом, во втором примере на рисунке 3.6 можно рассматривать пару зависимостей владеет-принадлежит. Подобных недоразумений можно избежать, если идентифицировать зависимости не по именам, а по наименованиям ролей классов, составляющих зависимость.

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

Дальнейшие примеры зависимостей между классами приведены на рисунке 3.7. Первый пример показывает зависимость между клиентом банка и его счетами. Клиент банка может иметь одновременно несколько счетов в этом банке, либо вовсе не иметь счета (когда он впервые становится клиентом банка). Таким образом, нужно изобразить зависимость между клиентом и несколькими счетами, что и сделано на рисунке 3.7. Второй пример показывает зависимость между пересекающимися кривыми (в частности, прямыми) линиями. Можно рассматривать 2, 3, и более таких линий, причем они могут иметь несколько точек пересечения. Наконец, третий пример показывает необязательную (optional) зависимость: компьютер может иметь, а может и не иметь мышь.

Зависимостям между классами соответствуют зависимости между объектами этих классов. На рисунке 3.8 показаны зависимости между объектами для первого примера рисунка 2.6; на рисунке 3.9 показаны зависимости между объектами для примеров, изображенных на рисунке 3.7.

Рис. 3.7. Дальнейшие примеры зависимостей. Обозначения

Рис. 3.8. Зависимости между объектами

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

При проектировании системы удобнее оперировать не объектами, а классами.

Рис. 3.9. Более сложные зависимости между объектами

Понятие зависимости перенесено в объектно-ориентированную технологию проектирования программных систем из технологии проектирования (и моделирования) баз данных, где зависимости используются с давних пор. Языки программирования, как правило, не поддерживают явного описания зависимостей. Тем не менее описание зависимостей очень полезно при разработке программных систем. Технология OMT использует зависимости при интерпретации диаграмм, описывающих систему.

Заключение

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

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

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

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

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

Третий этап заключается в объектной декомпозиции как выделении подтипов или подобъектов и их составляющих для каждого из типов объектов.

Четвертый этап представляет собой композиционную иерархизацию объектов как выделение родовидовых и композиционных отношений над объектами.

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

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

Список литературы:

1. М. Уэйт, С. Прата, Д. Мартин Язык Си: Пер с англ.-М.: Мир, 2007.-463 с.,ил.

2. Уинер Р. Язык Турбо Си: Пер с англ.-М.: Мир, 2010.-384 с., ил.

3. Берри Р., Микинз Б. Язык Си: введение для программистов: Пер. с англ.-М.:Финансы и статистика, 2007.-с.,ил.

4. TURBO C++. Borland International. Inc. 2010.

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

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

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

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

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

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

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

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

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

Математикам лень объяснять на языке обывателя, что такое действительное число. Обывателю трудно читать значки, написанные математиком, потому что их смысл для него не понятен. В итоге есть разрыв между теорией и практикой. В теории математики прекрасно знают, что такое типы объектов и что такое атрибуты, но, спускаясь к практике, мы видим, что мало, кто из практиков понимает, что это такое. Существует множество интуитивных понятий, но каждое из них скорее похоже на религиозную догму, нежели на знание. В данной статье я попытался ликвидировать пробел между математиками и прикладниками, объясняя основы теории множеств простым языком, без сложных значков. Например, вы знакомы с определением понятия атрибут? Я выстрадал его самостоятельно, потому что не мог найти формального его определения. И лишь потом Игорь Катричек прислал мне ссылку на книгу Е.Киндлера «Языки моделирования» (1979 год, перевод 1985 год), в которой дано определение атрибута:

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

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

Множества в математике и физике

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

Например, математическое множество не существует во времени, как и операции над ним. Это значит, что нельзя сказать, что состав множества меняется во времени.

Мне самому это кажется контринтуитивным и неочевидным требованием, но без него мы не сможем проводить операции над множествами и делать сравнения. Это значит, что, если мы хотим описать множество песчинок в куче песка, то у нас есть два способа это сделать: для каждого нового состава песчинок вводить новое множество, или рассмотреть множество темпоральных частей песчинок в исследуемой куче. Под темпоральной частью песчинки понимается временна я часть песчинки, которая имеет атрибут: начало и конец, моделирующие присутствие данной песчинки в куче. Это множество темпоральных частей еще называют 4D-представление, выполненное в 4D парадигме. Состав песчинок на конкретный момент можно получить из этого множества путем временно го среза: выбрать только те темпоральные части песчинок, которые «актуальны» на данный момент времени, то есть те, которые появились в куче раньше, а ушли из кучи позже выбранного момента времени.

Так моделируется состав реальных «физических» множеств. Но для текущей статьи такое представление будет достаточно сложным, и я вернусь к обычному представлению простых множеств «замороженных» во времени, то есть таких, которые существуют «вне времени».

Определение состава множества

Множество– это многое, мыслимое как целое, где многое – это состав множества. Рассмотрим способы определения состава множества. Как мы знаем, что состав множества может быть задан двумя способами:

Непосредственным перечислением объектов, выбранных из какого-то множества.
Правилами идентификации объектов, выбранных из какого-то множества.

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

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

Первый способ определения состава – это перечисление
Второй способ – задание условия идентификации.

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

Первый способ основан на серии высказываний:

Тарелка входит в состав множества А
Маркер входит в состав множества А
Больше никто не входит в состав множества А

Второй способ – это высказывание в предикатах:

Тот и только тот объект из находящихся в комнате, который имеет желтый стикер, входит в состав множества А.

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

В обсуждении было предложено само вхождение во множество при помощи перечисления тоже сделать атрибутом: «входит в состав множества А». Таким образом, те объекты, которые входят во множество А, имеют значение этого атрибута «да». Затем было предложено на основании этого атрибута сделать признак для отбора в состав того же самого множества А: те объекты, которые имеют значение «да», входят в состав множества А. Автор этой затеи не заметил, что в результате логического вывода из этих двух высказываний мы получаем две тавтологии:

В состав множества А входят те и только те объекты, которые входят в состав множества А и

Объект входит в состав множества А тогда и только тогда, когда он входит в состав множества А.

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

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

Кстати, в свое время был длительный спор об определении того, что такое функция. Этот спор возник по причине того, что не могли принять решение о том, какие правила идентификации считать корректными, а какие – нет. В итоге была принята идея Дирихле о том, что любые правила будут считаться корректными. Именно поэтому я не буду замахиваться на классификацию всех правил, но рассмотрю лишь несколько, которые в данном контексте нам понадобятся.

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

Определение состава подмножества

Давайте посмотрим, как мы определяем состав множества африканских слонов. Я насчитал четыре разных способа это сделать.

Можно определить их путем перечисления.
Можно приклеить стикер к слонам, и сказать, что те слоны, у которых есть приклеенный стикер, считаются африканскими. Это определение состава множества через атрибут. Атрибутом будет считаться наличие или отсутствие стикера.
Можно определить состав через пересечение двух множеств: множества слонов и множества животных, обитающих в Африке.
Можно ввести понятие типа «африканские слоны».

Используя в нашей работе OWL, мы имеем возможность реализовать три описанных выше способа задания подмножества:

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

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

Моделирование подмножества при помощи типа

Для определения типа «африканский слон» нам понадобятся:

Группа объектов, из которой мы выбираем объекты для под-типа. В данном случае эта группы имеет название – это группа слонов.
Уникальное свойство, котором объекты типа отличаются от остальных объектов группы: проживают в Африке.
Уникальное название для объектов данного типа

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

Итого, чтобы дать определение типа, надо:

Указать над-множество объектов.
Указать отличительные особенности (дифференциальные свойства) объектов данного типа от объектов группы.
Указать название объектов данного типа

Дополнительно можно указать:

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

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

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

Понятие тип

Итак, с точки зрения теории множеств:

Тип – это способ выделения подмножества из над-множества и присвоение нового имени объектам этого подмножества

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

Разница между типом объектов и множеством объектов

Из обсуждений статьи я понял, что есть люди, которые считают, что тип объектов и множество объектов – это то ли связанные понятия, то ли одно и тоже. Попробую объяснить, почему это не так. Тип - это одновременно и правило идентификации объектов, и название этих объектов. То есть тип служит одновременно и специализации (или выделению) подмножества из множества, и дает новое название специализированным объектам.

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

Понятно, что правило, задающее множество не есть само множество.

Мне кажется, что из всего сказанного ясно, чем понятие «тип объектов» отличается от понятия «множество объектов».

Моделирование однотипных объектов

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

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

Жизненный цикл объекта

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

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

Процесс объективации и деобъективации выглядит так:

Объективация

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

Деобъективация

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

Примеры из практики:

Объективация:

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

Деобъективация:

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

Требования к моделлеру, моделирующего типы

Сформулируем требования к моделлеру, который предназначен для моделирования типов:

Необходимо уметь моделировать однотипные объекты, состав атрибутов которых не совпадает

Необходимо уметь моделировать правила, которые выделяют объекты в один тип

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

Необходимо уметь моделировать разные точки зрения на один и тот же объект

Необходимо уметь моделировать жизненный цикл объекта

Необходимо уметь моделировать изменение нашего представления об объекте с течением времени.

Как в ИТ отрасли реализовать эти требования без обращения к структуре БД? Как, не обращаясь к структуре данных, учитывать разные точки зрения, добавлять новые типы объектов, уточнять тип объектов, переклассифицировать объекты в случае необходимости?

Моделирование объектов при помощи OWL

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

Добавление нового множества объектов в OWL ничем не отличается от добавления нового объекта.
Можно потребовать, что, если тип объекта известен, то модель объекта создается с заданными, наперед известными атрибутами. При этом после создания атрибуты могут как добавляться, так и удаляться. Пример: создавая модель заявки, мы можем потребовать указать значения атрибутов (номер заявки, дата заявки, заявитель, адресат). Надо только помнить, что эти атрибуты в OWL существуют отдельно от типов объектов. И один атрибут может быть использован при моделировании объектов разных множеств. Это принципиальное отличие от распространенных языков программирования, где атрибут существует только в рамках одного типа объектов. Другой атрибут в другом типе, пусть и называемый так же, будет другим атрибутом.
Можно потребовать наоборот: определять подмножество моделируемого объекта на основе атрибутов модели объекта и его принадлежности к над-множеству. Для этого в правиле будет записано, что если модель объекта, относящегося к определенному над-множеству, содержит такие-то атрибуты и их значения удовлетворяют определенным правилам, то объект автоматически будет отнесен к определенному подмножеству. Так при помощи правил будет реализована, так называемая, «утиная классификация». Например, если в модели заявки есть значение атрибута «Телефонный номер», а «Подключение» - это значение атрибута «Тип выполняемых работ», то заявка автоматически будет классифицирована как заявка на подключение телефонного номера.

Разделения множества на подмножества

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

Разделение множества на подмножества можно провести разными способами.

Можно разделить множество на непересекающиеся подмножества, распределив объекты по подмножествам путем их перечисления. Создать семь подмножеств и перечислить объекты, которые принадлежат каждому из подмножеств.
Для каждого подмножества можно придумать свой подтип. Тогда все множество можно разделить на семь подмножеств, введя семь подтипов: «Тип красных объектов», «Тип желтых объектов» и т. д. Каждый объект можно отнести к одному из перечисленных типов и сказать, например, так: объект относится к типу красных объектов.
Можно разделить надмножество при помощи атрибута и его значений. Например, можно ввести атрибут «Цвет» и семь его значений: «Красный», «Желтый» и тд. Тогда название цвета станет прилагательным для объекта и будет звучать так: красный объект, желтый объект и тд.

Первый способ в OWL реализован при помощи создания семи разных классов и указания объектов, которые к ним относятся.

Второй способ может быть реализован тремя разными способами:

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

Третий способ разделения множества на подмножества в ИС моделируется двумя способами:

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

Видно, что разделение при помощи типов и атрибутов моделируется в двух случаях одинаковым способом, но имеет разные названия. И действительно, обладание значением атрибута в OWL моделируется таким триплетом:

#объект #атрибут #значение

Принадлежность классу - таким:

#объект rdf:type #класс

То есть можно сказать, что принадлежность классу просто выражается при помощи специального служебного атрибута, определенного в стандарте - rdf:type.

Понятие атрибут

Сформулируем утверждение:

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

Моделирование подмножеств при помощи атрибута

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

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

Если подмножеств много (в пределе бесконечно, например, когда каждое из множеств группирует объекты одинаковой длины), то формально остаются:

третий способ моделирования типа и
второй способ моделирования атрибута.

Однако, я писал ранее, что каждому типу нужно дать название. Если подмножеств много (бесконечно), то дать имя каждому из них нереально. Поэтому мы не моделируем такое деление при помощи типов. Мы моделируем такое деление только при помощи атрибута, областью значений которого будет одно из распространенных множеств: множество вещественных чисел, множество, моделирующее временную шкалу, множество натуральных чисел, множество строк конечной длины и тд. Узнаете типы данных?

О том, как вводится функция на множестве подмножеств и не только про это, можно почитать

ER-диаграммы

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

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

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

Туристы

Путевки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ER -диаграммы

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

Туристы

Путевки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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