Обозначения: (П) – простой атрибут; (С) – составной/сложный атрибут; (О) – однозначный атрибут; (М) – многозначный атрибут; (В) – вычисляемый/производный атрибут.

В колонке 3 таблицы 4.3 приведены все атрибуты сущностей, приведенных в колонке 2 этой таблицы.

Рассмотрим атрибуты сущности «Проект дома». В качестве атрибутов данной сущности предлагается принять следующие параметры/характеристики:

• №_проекта;

• ФИО_архитектора;

• Дата_создания;

• Стоимость_проекта.

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

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

• принимает не очень большие числовые или длинные текстовые значения;

• вероятность изменения значения минимальна;

• вероятность потери уникальности минимальна.

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

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

В колонке 7 таблицы 4.3 приводятся комментарии к атрибутам, актуальные с точки зрения разработчика модели, а также все значения атрибутов, которые относятся к так называемому «перечисляемому типу» атрибутов. Например, это может быть атрибут, характеризующий дни передачи некоторой информации/отчета. И вот именно эти дни длжны быть вписаны в колонке 7 для данного атрибута.

Все имена атрибутов всех сущностей целесообразно занести в специальную таблицу имен атрибутов (таблица 4.4).

Таблица 4.4.

Имена атрибутов сущностей

№	Атрибуты	№	Атрибуты	№	Атрибуты
1	№_проекта	8	Характеристики	15	ФИО_хозяина
2	ФИО_архитектора	9	Табельный_номер	16	Фундамент
3	Дата_создания	10	ФИО	17	Стены
4	Стоимость_проекта	11	Профессия	18	Крыша
5	Код_материала	12	Стаж_работы	19	Вид
6	Название	13	Адрес	20	Дата_сдачи
7	Вид_материала	14	Адрес_дома

---

Рассмотрим миграцию ключей между сущностями модели. Как отмечалось в п. 2.5.2 миграция ключей имеет место между сущностями, связанными отношением «родитель-потомок», и сущностями, связанными отношением категоризации.

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

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

Завершающим действием стадии определения атрибутов сущностей модели является формирование матрицы «Сущность – атрибут» (таблица 4.5).

4.5. Проверка правильности назначения атрибутов

Проверка правильности назначения атрибутов сущностей модели проводится с помощью правил приведенных в п.п. 2.5.3, 2.6.4 в два этапа – сначала проверяются ключевые атрибуты (ключи), а затем проверяются неключевые атрибуты.

Проведем проверку первичных ключевых атрибутов всех сущностей разрабатываемой модели:

• сущность «Проект дома» - первичный ключ «№_проекта»;

• сущность «Дом» - первичный ключ «Адрес_дома»;

• сущность «Материалы» - первичный ключ «Код_материала»;

• сущность «Строители» - первичный ключ «Табельный номер».

Сущность «Проект дома» - первичный ключ «№_проекта».

1. Нельзя использовать синтаксис неспецифических отношений.

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

2. Миграция ключей от родительских (или общих) сущностей к сущностям-потомкам (или сущностям-категориям) является обязательной.

Данный первичный ключ мигрирует к сущности – потомку – сущность «Дом» и включен в группу неключевых атрибутов этой сузности. Таким образом, данное требование выполнено.

3. Запрещается использовать атрибуты, которые могут принимать более одного значения для данного экземпляра сущности в одно и то же время (правило неповторяемости).

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

---

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

Атрибут «№_проекта» не обращается в ноль, т.е. для любого экземпляра сущности «Дом» данный атрибут всегда принимает фиксированное и уникальное значение. Правило выполняется.

5. Сущности с составными ключами не могут быть разбиты на несколько сущностей с более простыми ключами (правило наименьшего ключа).

Поскольку ключевой атрибут «№_проекта» является простым, то данное требование автоматически выполняется.

6. Необходимо объявлять об имеющихся между двумя сущностями двойных путях отношений.

Для всех сущностей модели двойные пути отсутствуют.

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

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

В рассматриваемом примере отсутствуют ситуации, соответствующие требованиям 4, 5, 6, как для ключевых, так и для неключевых атрибутов. Примеры разрешения возможных ситуаций с указанными правилами приведены в п.п. 2.5.3, 2.6.3.

---

Таблица 4.5.

Сущности		Атрибуты (имена атрибутов приведены в таблице 3.4)
		1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20
1	Проект_дома	О К	О	О	О
2	Материалы					О К	О	О	О
3	Строители									О К	О	О	О	О
4	Дом	I				I				I					О К	О	О	О	О	О	О

Обозначения: «О» = владелец, «К» = первичный ключ, «I» = наследуемый атрибут (внешний ключ).

---

Таблица 4.6.

№	Атрибут	Номер правила проверки корректности атрибутов
		1	2	3	4	5	6
1	№_проекта	+	+	+	+	+	+
2	ФИО_архитектора	+	+	+	+	+	+
3	Дата_создания	+	+	+	+	+	+
4	Стоимость_проекта	+	+	+	+	+	+

Диаграмма разработанной в среде Design/IDEF 3.X модели в стандарте IDEF1X приведена на рис. 4.4.

Рис. 4.4

При выполнении курсовой работы необходимо в приложении привести все рассуждения, на основании которых осуществлялось заполнение таблицы 4.6. Непосредственно в тексте пояснительной записки курсовой работы приводится только таблица 4.6.

Ниже приведен отчет по модели в стандарте IDEF1X, построенной в среде DESIGN/IDEF.

IDEF1X Report for: D:\****\_24C8~1\DESIGN~1\idef37\IDEF37\KURS1X.IDD

{ENTITY, 1, ПРОЕКТ-ДОМА, INDEPENDENT, {№_проекта}, {ФИО_архитектора,Дата_создания,Стоимость_проекта}}

{ENTITY, 2, МАТЕРИАЛЫ, INDEPENDENT, {Код_материала}, {Название,Вид_материала,Характеристики}}

{ENTITY, 3, ДОМ, INDEPENDENT, {Адрес_дома}, {Фундамент,Стены,Крыша,Вид,Дата_сдачи,№_проекта (FK),Код_материала (FK),ФИО_владельца,Табельный-номер (FK)}}

{ENTITY, 4, СТРОИТЕЛЬ, INDEPENDENT, {Табельный-номер}, {ФИО,Стаж_работы,Адрес}}

{ENTITY, 5, КАМЕНЩИК, DEPENDENT, {Табельный-номер (FK)}, {}}

{ENTITY, 6, КРОВЕЛЬЩИК, DEPENDENT, {Табельный-номер (FK)}, {}}

{ENTITY, 7, ПЛОТНИК, DEPENDENT, {Табельный-номер (FK)}, {}}

{ENTITY, 8, МАСТЕР-ПО-ОТДЕЛКЕ, DEPENDENT, {Табельный-номер (FK)}, {}}

{CATEGORIZATION, 1, Профессия, PARTIAL, {4}, {8,7,6,5}

{RELATION, 1, Используется для, IDENTIFYING, 1, 3, ZOM}

{RELATION, 2, Используется, NON-IDENTIFYING, 2, 3, ZOM}

{RELATION, 3, Строит, NON-IDENTIFYING, 4, 3, ZOM}

---

Смотрите также файлы

• Лекции по программной инженерии.pdf

• Отчет по практике в филиале РОСГОССТРАХ.docx

• Описание виртуального предприятия Вращивание рыбы.docx

• Планирование материальных потребностей предприятия MRP.pdf

• Методические указания по курсовой_проект_бакалавры.docx