Главная страница

курсовая. СОДЕРЖАНИЕ. Инструментальное программное обеспечение. История


Скачать 1.22 Mb.
НазваниеИнструментальное программное обеспечение. История
Анкоркурсовая
Дата04.09.2022
Размер1.22 Mb.
Формат файлаpdf
Имя файлаСОДЕРЖАНИЕ.pdf
ТипЛекция
#662092
страница5 из 6
1   2   3   4   5   6
ТЕМА:Описание функциональности разработки: нотация IDEF3.
Этот метод предназначен для моделирования последовательности
выполнения действий и взаимозависимости между ними в рамках процессов. Модели IDEF3 могут использоваться для детализации функциональных блоков IDEF0, не имеющих диаграмм декомпозиции.
Нотация IDEF3 использует категорию Сценариев (Scenario) для упрощения структуры описаний сложного многоэтапного процесса. IDEF3 осуществляет реализацию следующей информации о процессе:
·объекты, участвующие в описании операции;
·функции, которые выполняют эти объекты;
·взаимосвязь между процессами;

·состояния и изменения, которым подвергаются объекты;
·время выполнения и контрольные точки синхронизации работ;
·ресурсы, необходимые для выполнения работ.
Существует два типа диаграмм в стандарте IDEF3:
1. PFDD - диаграммы описания последовательности этапов процесса.
2. OSTN - диаграммы состояния объекта и его изменений в процессе.
На рис. 10 изображена диаграмма PFDD, показывающая процессы создания программного обеспечения. Прямоугольники на диаграмме PFDD называются функциональными элементами или элементами поведения (UOB) и обозначают событие, стадию процесса или принятие решения (рис. 11).
Каждый UOB имеет конкретное имя (функция, процесс, действие, акт, событие, сценарий, процедура, операция, решение), отображаемое в глагольном наклонении и уникальный номер (номер действия обычно предваряется номером его родителя, например, 1.1.). В правом нижнем углу
UOB элемента располагается ссылка на какие-либо элементы функциональной модели IDEF0 или на отделы, конкретных исполнителей, выполняющие конкретный процесс.
Рис. 10. PFDD-диаграмма создания электронной программы.
Рис. 11. Функциональный элемент (UOB).
Стрелки или линии являются отображением хода выполнения операций между UOB-блоками в ходе процесса (рис. 12). а) б) в)

Рис. 12. Стрелки для отображения хода выполнения операции
Линии в нотации IDEF3 бывают следующих видов:
1. Временное предшествование или старшая (Temporal precedence, рис. 12, а) - сплошная линия, связывающая UOB. Рисуется слева направо или сверху вниз. Исходное действие должно завершиться, прежде чем конечное действие сможет начаться.
2. Нечеткое отношение (Relationship link, рис. 12, б) - пунктирная линия, использующаяся для изображения связей между UOB в том случае, если конечное действие сможет начаться и даже завершиться до того момента, когда завершится исходное действие.
3. Объектный поток (Object flow, рис. 12, в) - стрелка с двумя наконечниками используется для описания того факта, что объект (деталь) используется в двух или более единицах работы, например, когда объект порождается в одной работе и используется в другой (т.е. выход исходного действия является входом конечного действия). Исходное действие должно завершиться, прежде чем конечное действие сможет начаться. Наименования потоковых связей должны чётко идентифицировать объект, который передается с их помощью.
Все связи в IDEF3 являются однонаправленными.
Завершение одного действия может инициировать начало выполнения сразу нескольких других действий, или наоборот, определенное действие может требовать завершения нескольких других действий до начала своего выполнения (ветвление процесса). Ветвление процесса отражается с помощью специальных блоков, называемых перекрестками. Каждый перекресток (Junction) имеет свой определенный идентификационный номер
(на рис. 10 J1 - перекресток). Перекресток не может использоваться одновременно для слияния и для разветвления. При вводе перекрестка в диаграмму необходимо указать тип перекрестка. Типы перекрестков представлены в таблице 2.
Таблица 2. Описание типов перекрестков.
Обозн ачение
Наименова ние
Смысл для стрелок слияния
Смыл для стрелок разветвления

Асинхронн ое
И
(asynchronous
AND)
Все предшествующие процессы должны быть завершены
Все следующие процессы должны быть запущены
Cинхронно е И (synchronous
AND)
Все предшествующие процессы завершены одновременно
Все следующие процессы запускаются одновременно
Асинхронн ое
ИЛИ
(asynchronous
OR)
Один или несколько предшествующих процессов должны быть завершены
Один или несколько следующих процессов должны быть запущены
Синхронно е
ИЛИ
(synchronous OR)
Один или несколько предшествующих процессов завершаются одновременно
Один или несколько следующих процессов запускаются одновременно
Исключаю щее ИЛИ(XOR, exclusive OR)
Только один предшествующий процесс завершен
Только один следующий процесс запускается
Пояснение: Перекресток "Исключающий ИЛИ" обозначает, что
после завершения работы "A" (рис. 13), начинает выполняться только одна
из трех расположенных параллельно работ B, С или D в зависимости от
условий 1, 2 и 3. Перекресток "И" обозначает, что после завершения работы
"A", начинают выполняться одновременно три параллельно расположенные
работы B, С и D. Перекресток "ИЛИ" обозначает, что после завершения
работы "A", может запуститься любая комбинация трех параллельно
расположенных работ B, С и D. Например может запуститься только одна
из них, могут запуститься три работы, а также могут запуститься
двойные комбинации В и С, либо C и D, либо B и D. Перекресток
"Исключающий ИЛИ" является самым неопределенным, так как
предполагает несколько возможных сценариев реализации бизнес-процесса и
применяется для описания слабо формализованных ситуаций.

Рис. 13. Применение перекрестков "Исключающий ИЛИ", "И" и "ИЛИ"
- схемы расхождения.
4
Рис. 14. Применение перекрестков "Исключающий ИЛИ", "И" и "ИЛИ"
- схемы схождения.
Сценарий, отображаемый на диаграмме (рис. 10), можно описать в следующем виде. Программный код, подготовленный к компиляции, компилируется в компиляторе программ. В процессе компиляции создается исполнительный файл программы. После этого, производится тестирование программы, после которой начинается этап проверки программного продукта.
Если тест подтверждает недостаточное качество программы, то она заново
пропускается через этап создания программного кода. Если программа успешно проходит контроль качества, то она отправляется пользователю.
Метод IDEF3 позволяет декомпозировать действие несколько раз, что обеспечивает документирование альтернативных потоков процесса в одной модели.
Каждый функциональный блок UOB может иметь последовательность декомпозиций. Номера UOB дочерних диаграмм имеют сквозную нумерацию, т.е., если родительский UOB имеет номер "1", то блоки UOB на его декомпозиции будут соответственно иметь номера "1.1", "1.2" и т.д.
Если диаграммы PFDD представляют технологический процесс "С точки зрения наблюдателя", то другой класс диаграмм IDEF3 - OSTN позволяет рассматривать тот же самый процесс "С точки зрения объекта". На рис. 15 представлено отображение процесса создания электронной программы с точки зрения OSTN диаграммы. Состояния объекта (в нашем случае электронной программы) и изменение состояния являются ключевыми понятиями OSTN диаграммы. Состояния объекта отображаются окружностями, а их изменения направленными линиями. Каждая линия имеет ссылку на соответствующий функциональный блок UOB, в результате которого произошло отображаемое ей изменение состояния объекта.
Рис. 15. Пример OSTN-диаграммы создания электронной программы.
На схеме бизнес-процесса также можно использовать такой элемент как "объект- ссылка", который связывается с работами и перекрестками.
Ссылки обеспечивают более полное понимание, дополнительный смысл и упрощение описания процесса. Ссылки позволяют:

·обращаться к ранее определенному действию;
·организовывать циклы;
·уточнять работу перекрестков;
·связывать элементы диаграммы с каким-либо внешним объектом;
·комментировать различные элементы диаграммы.
Ссылка изображается в виде прямоугольника. В верхней его части указывается тип ссылки и ее имя.
Рис. 16. Ссылки
Ссылки могут быть различного типа. Список типов ссылок приведен в таблице 3.
Таблица 3. Типы ссылок.
Тип ссылки
Назначение
OBJEC
T
Описывает участие важного объекта в действии.
GOTO
Позволяет применять на диаграмме циклический переход. В том случае, когда все действия цикла находятся в рамках одной диаграммы, цикл можно изобразить стрелкой, которая будет указывать на начало цикла. Тогда ссылка будет связана с перекрестком, управляющим циклом.
UOB
Предназначена для многократного вызова какого-либо действия в рамках одной модели

NOTE
Позволяет прокомментировать присутствие какого-либо элемента на диаграмме.
ELAB
(elaboration)
Применяется для уточнения использования ветвления стрелок на перекрестках.
Примеры использования ссылок различного типа приведены на рис. 17.
Рис. 17. Примеры использования ссылок различного типа
Таким образом, можно сделать следующие выводы по практическому использованию: применение универсальных графических языков моделирования IDEF0, IDEF3 и DFD обеспечивает логическую целостность и полноту описания, необходимую для достижения точных и непротиворечивых результатов на этапе анализа.
По диаграммам делаем следующий вывод: наиболее существенное различие между разновидностями структурного анализа заключается в их функциональности.
Модели SADT (IDEF0) наиболее удобны при построении функциональных моделей. Они наглядно отражают функциональную структуру объекта: производимые действия, связи между этими действиями.
Таким образом, четко прослеживается логика и взаимодействие процессов организации. Главным достоинством нотации является возможность получить полную информацию о каждой работе, благодаря ее жестко регламентированной структуре. С ее помощью можно выявить все недостатки, касающиеся как самого процесса, так и то, с помощью чего он реализуется: дублирование функций, отсутствие механизмов, регламентирующих данный процесс, отсутствие контрольных переходов и т.д.

DFD позволяет проанализировать информационное пространство системы и используется для описания документооборота и обработки информации. Поэтому, диаграммы DFD применяют в качестве дополнения модели бизнес-процессов, выполненной в IDEF0.
IDEF3 хорошо приспособлен для сбора данных, требующихся для проведения анализа системы с точки зрения рассогласования/согласования процессов во времени.
Нельзя говорить о достоинствах и недостатках отдельных нотаций.
Возможны ситуации, при которых анализ IDEF0 не обнаружил недостатков в деятельности организации с точки зрения технологического или производственного процесса, однако это не является гарантией отсутствия ошибок. Поэтому в следующем этапе анализа необходимо перейти к исследованию информационных потоков с помощью DFD и затем объединить эти пространства с помощью последней нотации - IDEF3.
Сегодня для описания функциональности разработки предлагаются различные инструменты. Например:
· CASE-средствоAllFusion Process Modeler (BPwin) компании
Computer Associates. AllFusion Process Modeler нарядус ERwin Data Modeler
(ERwin), входитвсоставпакетапрограммныхсредств AllFusion Modeling Suite.
Основным преимуществом данного инструмента является присутствие нотаций IDEF и DFD, которые распространены в российских компаниях и принята в России на уровне стандарта, а также связь с продуктом Erwin, используемым для проектирования структур данных.
·
CASE-средствоSilverrunамериканскойфирмыСomputer
Systems
Advisers, Inc. (CSA) используется для анализа и проектирования ИС бизнес- класса [22] и ориентировано в большей степени на спиральную модель ЖЦ.
Оно применимо для поддержки любой методологии, основанной на раздельном построении функциональной и информационной моделей
(диаграмм потоков данных и диаграмм "сущность-связь").
· CASE.Аналитик 1.1 является практически единственным в настоящее время конкурентоспособным отечественным
CASE-средством функционального моделирования. Его основные функции: o построение и редактирование DFD; o анализ диаграмм и проектных спецификаций на полноту и непротиворечивость; o получение разнообразных отчетов по проекту;
o генерация макетов документов в соответствии с требованиями ГОСТ
19.ХХХ и 34.ХХХ.
· Также существует множество программ для рисования различных диаграмм, например, MS Visio или Dia.
Лекция 8
ТЕМА:Проектирование с использованием метода «сущность-
связь».
В реальном проектировании структуры базы данных применяется так называемое, семантическое моделирование. Семантическое моделирование представляет собой моделирование структуры данных, опираясь на смысл этих данных. В качестве инструмента семантического моделирования используются различные варианты диаграмм сущность-связь (ER - Entity-
Relationship), которые могут быть относительно легко отображены в любую систему баз данных.
Первый вариант модели сущность-связь был предложен в 1976 г.
Питером Пин-Шэн Ченом. В дальнейшем многими авторами были разработаны свои варианты подобных моделей (нотация Мартина, нотация
IDEF1X, нотация Баркера и др.). Кроме того, различные CASE-средства используют несколько отличающиеся друг от друга нотации ERD. Одна из наиболее распространенных нотаций предложена Баркером и используется в
Oracle Designer. В CASE-средстве SilverRun используется один из вариантов нотации Чена. CASE-средства ERwin, ER / Studio, Design / IDEF используют методологию IDEF1Х. По сути, все варианты диаграмм сущность-связь исходят из одной идеи - рисунок всегда нагляднее текстового описания. Все такие диаграммы используют графическое изображение сущностей предметной области, их свойств (атрибутов), и взаимосвязей между сущностями.
Мы опишем работу с ER-диаграммами близко к нотации Баркера, как довольно легкой в понимании основных идей.
Основные понятия ER-диаграмм
Определение 1.Сущность (Entity)- это реальный или представляемый объект, имеющий существенное значение для рассматриваемой предметной области, информация о котором должна сохраняться и быть доступна.

Каждая сущность должна иметь уникальное наименование, выраженное существительным в единственном числе. Примерами сущностей могут быть такие классы объектов как "Поставщик", "Сотрудник",
"Накладная". Каждая сущность в модели изображается в виде прямоугольника с наименованием (рис.1). При этом имя сущности – это имя типа, а не некоторого конкретного экземпляра этого типа.
Рис. 1. Обозначение сущности.
Для сущностей различают тип сущности и экземпляр. Тип характеризуется именем и списком свойств, а экземпляр – конкретными значениями свойств.
Определение 2. Экземпляр сущности- это конкретный представитель данной сущности.
Например, представителем сущности "Сотрудник" может быть "Сотрудник Иванов".
Каждый экземпляр сущности должен быть отличим от любого другого экземпляра той же сущности, т.е. сущности должны иметь некоторые свойства, уникальные для каждого экземпляра этой сущности (это требование в некотором роде аналогично требованию отсутствия кортежей- дубликатов в реляционных таблицах).
Типы сущностей можно классифицировать как сильные и слабые.
Сильные сущности существуют сами по себе, а существование слабых сущностей зависит от существования сильных. Например, читатель библиотеки – сильная сущность, а абонемент этого читателя – слабая, которая зависит от наличия соответствующего читателя. Слабые сущности называют подчинёнными (дочерними), а сильные – базовыми (основными, родительскими).
Также сущности разделяют на независимыеизависимые.Сущность является независимой, если каждый экземпляр ее может быть однозначно идентифицирован без определения его отношений с другими сущностями.
Независимая сущность изображается прямоугольником с четко выраженными углами. Сущность является зависимой, если однозначная идентификация экземпляра сущности зависит от его отношения к другой сущности. Зависимая сущность изображается прямоугольником со скругленными углами.

Сущности бывают как физически существующие (например,
СОТРУДНИК или АВТОМОБИЛЬ), так и абстрактные (например, ЭКЗАМЕН или ДИАГНОЗ).
Каждая сущность может обладать любым количеством связей с другими сущностями модели.
Определение 3. Атрибут сущности- это именованная характеристика, являющаяся некоторым значимым для рассматриваемой предметной области свойством сущности.
Наименование атрибута должно быть выражено существительным в единственном числе (возможно, с характеризующими прилагательными).
Примерами атрибутов сущности "Сотрудник" могут быть такие атрибуты как "Табельный номер", "Фамилия", "Имя", "Отчество",
"Должность", "Зарплата" и т.п.
Атрибуты изображаются в пределах прямоугольника определяющего сущность, причем каждый атрибут занимает отдельную строку, и отделяются от названия сущности линией (рис. 2).
Рис. 2. Указание атрибутов сущности.
Рядом с именем атрибута можно приводить примеры значений данного атрибута.
Различают:
1.
Идентифицирующие
и
описательные
атрибуты.
Идентифицирующие атрибуты имеют уникальное значение для сущностей данного типа и являются потенциальными ключами. Они позволяют однозначно распознавать экземпляры сущности. Из потенциальных ключей выбирается один первичный ключ. В качестве первичного ключа обычно выбирается потенциальный ключ, по которому чаще происходит обращение к экземплярам сущности. Кроме того, ПК должен включать в свой состав минимально необходимое для идентификации количество атрибутов.
Остальные атрибуты называются описательными и заключают в себе интересующие свойства сущности.

2. Составные и простые атрибуты. Простой атрибут состоит из одного компонента, его значение неделимо. Составной атрибут является комбинацией нескольких компонентов, возможно, принадлежащих разным типам данных (например, ФИО или адрес). Решение о том, использовать составной атрибут или разбивать его на компоненты, зависит от характера его обработки и формата пользовательского представления этого атрибута.
3.
Однозначные
и
многозначные
атрибуты.Могут иметь соответственно одно или много значений для каждого экземпляра сущности.
На диаграмме изображаются с двойным подчеркиванием.
4. Основные и производные атрибуты.Значение основного атрибута не зависит от других атрибутов. Значение производного атрибута вычисляется на основе значений других атрибутов (например, возраст студента вычисляется на основе даты его рождения и текущей даты).
Спецификация атрибута состоит из его названия, указания типа данных и описания ограничений целостности – множества значений (или домена), которые может принимать данный атрибут.
Атрибут может быть либо обязательным, либо необязательным.
Обязательность означает, что атрибут не может принимать неопределенных значений (Null). Обязательный атрибут помечается звездочкой, а необязательный - кружком (рис. 3).
Рис. 3. Указание обязательных и необязательных атрибутов сущности.
Определение 4.Ключ сущности- это неизбыточный набор атрибутов, значения которых в совокупности являются уникальными для каждого экземпляра сущности. Неизбыточность заключается в том, что при удалении любого атрибута из ключа нарушается его уникальность.
Сущность может иметь несколько различных ключей. Различают
первичный, альтернативный и внешнийключи.
Первичный ключ (Primary Key) -это атрибут или группа атрибутов, используемых для однозначной идентификации экземпляра сущности. На диаграмме атрибуты первичного ключа размещаются первыми в списке атрибутов и подчеркиваются или предваряются # (рис. 4):

Рис. 4. Указание ключевого атрибута.
Альтернативный ключ (Alternate Key)-потенциальный ключ, не ставший первичным. На диаграмме альтернативный ключ обозначается AK n.
m, где n - порядковый номер ключа, m - порядковый номер атрибута в ключе.
Внешние
ключи
(Foreign
Key)создаются, когда сущности соединяются связью при построениифизических ER-диаграмм. Происходит миграция атрибутов первичного ключа родительской сущности в дочернюю сущность. Появившийся таким образом в дочерней сущности атрибут будет являться внешним ключом. (Из родительской сущности атрибут не исчезает, а просто копируется в дочерней сущности). Внешний ключ обозначается ВК.
Первичный ключ может бытьабсолютный или относительный. Если все атрибуты, составляющие первичный ключ, принадлежат сущности, то он является абсолютным. Если один или более атрибутов первичного ключа принадлежат другой сущности, то он является относительным. Когда первичный ключ является относительным, сущность определяется как
зависимая сущность, поскольку ее идентификатор зависит от другой сущности. В примере на рисунке 5 первичный ключ сущности Компания является относительным. Он включает первичный ключ сущности Список компаний.
Рис. 5. Относительный первичный ключ.
Определение 5. Связь- это графически изображаемая ассоциация, устанавливаемая между двумя сущностями, значимая для рассматриваемой предметной области.
Эта ассоциация всегда является бинарной и может существовать между двумя разными сущностями или между сущностью и ей же самой
(рекурсивная связь).
Определение связи в методе Баркера несколько отличается от данного
Ченом.

Определение 5.1. Связь- это ассоциация между сущностями, при которой, как правило, каждый экземпляр одной сущности, называемой
родительской сущностью, ассоциирован с произвольным (в том числе и нулевым) количеством экземпляров второй сущности, называемой
сущностью-потомком, а каждый экземпляр сущности-потомка ассоциирован в точности с одним экземпляром сущности-родителя. Таким образом, экземпляр сущности-потомка может существовать только при существовании сущности-родителя.
Связи позволяют по одной сущности находить другие сущности, связанные с нею.
В любой связи выделяются два конца (в соответствии с существующей парой связываемых сущностей), на каждом из которых указывается:
· имя конца связи,
· тип конца связи (сколько экземпляров данной сущности связывается),
· обязательность связи (т.е. любой ли экземпляр данной сущности должен участвовать в данной связи).
Связь представляется в виде линии, связывающей две сущности или ведущей от сущности к ней же самой. При этом в месте "стыковки" связи с сущностью используется трехточечный вход в прямоугольник сущности, если для этой сущности в связи могут использоваться много (many) экземпляров сущности, и одноточечный вход, если в связи может участвовать только один экземпляр сущности. Обязательный конец связи изображается сплошной линией, а необязательный – прерывистой линией
(рис. 6).
Рис. 6. Изображение связи между сущностями.
Наименование связи обычно выражается в неопределенной глагольной форме: "иметь", "принадлежать" и т.п. Каждое из наименований относится к своему концу связи. Иногда наименования не пишутся ввиду их очевидности.
Имя каждой связи между двумя сущностями должно быть уникальным, но имена связей в модели не обязаны быть уникальными. Имя связи всегда формируется с точки зрения родителя, так что может быть образовано
предложение соединением имени сущности-родителя, имени связи, выражения степени и имени сущности-потомка.
Каждая связь может иметь один из следующих типов связи (рис. 7):
Рис. 7. Типы связей и их изображение на диаграмме.
Связь типа один-к-одному означает, что один экземпляр первой сущности (левой) связан с одним экземпляром второй сущности (правой).
Связь один-к-одному чаще всего свидетельствует о том, что на самом деле мы имеем всего одну сущность, неправильно разделенную на две.
Связь типа один-ко-многим означает, что один экземпляр первой сущности (левой) связан с несколькими экземплярами второй сущности
(правой). Это наиболее часто используемый тип связи. Левая сущность (со стороны "один") называется родительской, правая (со стороны "много") -
дочерней. Характерный пример такой связи приведен на рис. 6.
Связь типа много-ко-многим означает, что каждый экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности, и каждый экземпляр второй сущности может быть связан с несколькими экземплярами первой сущности. Тип связи много-ко-многим является
временным типом связи, допустимым на ранних этапах разработки модели.
В дальнейшем этот тип связи должен быть заменен двумя связями типа один-
ко-многим путем создания промежуточной сущности.
Каждая связь может иметь одну из двух модальностейсвязи (рис. 8):
Рис. 8. Модальность связи и ее изображение на диаграмме.
Модальность "может" означает, что экземпляр одной сущности
может быть связан с одним или несколькими экземплярами другой сущности, а может быть и не связан ни с одним экземпляром.

Модальность "должен" означает, что экземпляр одной сущности
обязан быть связан не менее чем с однимэкземпляром другой сущности.
Связь может иметь разную модальность с разных концов (как на рис. 6).
Тип связи в совокупности с модальностью называют еще
кардинальностью связи (табл. 1):
Таблица 1. Кардинальность связи.
Обозначение
Кардинал ьность
0,1 1,1 0,N
1,N
Описанный графический синтаксис позволяет однозначно читать диаграммы, пользуясь следующей схемой построения фраз:
<Каждый экземпляр
СУЩНОСТИ
1><МОДАЛЬНОСТЬ
СВЯЗИ><НАИМЕНОВАНИЕ
СВЯЗИ><ТИП
СВЯЗИ><экземпляр
СУЩНОСТИ 2>.
Каждая связь может быть прочитана как слева направо, так и справа налево. Связь на рис. 6 читается так:
Слева направо: "каждый сотрудник может иметь несколько детей".
Справа налево: "Каждый ребенок обязан принадлежать ровно одному сотруднику".
На следующем примере (рис. 9) изображена рекурсивная связь, связывающая сущность ЧЕЛОВЕК с ней же самой. Конец связи с именем "являться сыном" определяет тот факт, что один человек может быть сыном не более чем одному отцу. Конец связи с именем "являться отцом" означает, что один человек может являться отцом для одного или более ЛЮДЕЙ (т.е не каждый человек имеет детей).

Рисунок 9. Пример рекурсивной связи.
Более сложные элементы ER-модели
Ранее были представлены только основные и наиболее очевидные понятия ER-модели данных. К числу более сложных элементов модели относятся следующие:
· Подтипы и супертипы сущностей. Как в языках программирования с развитыми типовыми системами (например, в языках объектно- ориентированного программирования), вводится возможность наследования типа сущности, исходя из одного или нескольких супертипов. Интересные нюансы связаны с необходимостью графического изображения этого механизма.
· Уточняемые степени связи. Иногда бывает полезно определить возможное количество экземпляров сущности, участвующих в данной связи
(например, служащему разрешается участвовать не более, чем в трех проектах одновременно). Для выражения этого семантического ограничения разрешается указывать на конце связи ее максимальную или обязательную степень.
· Каскадные удаления экземпляров сущностей. Некоторые связи бывают настолько сильными (конечно, в случае связи "один-ко-многим"), что при удалении опорного экземпляра сущности (соответствующего концу связи "один") нужно удалить и все экземпляры сущности, соответствующие концу связи "многие". Соответствующее требование "каскадного удаления" можно сформулировать при определении сущности.
· Домены. Как и в случае реляционной модели данных бывает полезна возможность определения потенциально допустимого множества значений атрибута сущности (домена).
Эти и другие более сложные элементы модели данных "Сущность-
Связи" делают ее существенно более мощной, но одновременно несколько усложняют ее использование.
Разработка ER- моделей.
Семантическое моделирование начинается с разбивки предметной области на ряд локальных областей, каждая из которых (в идеале) включает в
себя информацию, достаточную для обеспечения запросов отдельной группы будущих пользователей или решения отдельной задачи (подзадачи). Каждое локальное представление моделируется отдельно, затем они объединяются.
Выбор локального представления зависит от масштабов предметной области. Обычно она разбивается на локальные области таким образом, чтобы каждая из них соответствовала отдельному внешнему приложению и содержала 6-7 сущностей.
Разработка ERD включает следующие основные этапы:
· Идентификация сущностей, их атрибутов, а также первичных и альтернативных ключей.
· Идентификация отношений между сущностями и указание типов отношений.
· Разрешение неспецифических отношений (отношений многие-ко- многим).
Процесс выделения сущностей, атрибутов и связей является итерационным. Разработав первый приближенный вариант диаграмм, мы уточняем их, опрашивая экспертов предметной области. При этом документацией, в которой фиксируются результаты бесед, являются сами
ER-диаграммы.
Как и в реляционных схемах баз данных, в ER -диаграммах вводится понятие нормальных форм, причем их смысл очень близко соответствует смыслу реляционных нормальных форм. Приведем только краткие и неформальные определения трех первых нормальных форм.
В первой нормальной форме ER-схемы устраняются повторяющиеся атрибуты или группы атрибутов, т.е. производится выявление неявных сущностей, "замаскированных" под атрибуты.
Во второй нормальной формеустраняются атрибуты, зависящие только от части уникального идентификатора. Эта часть уникального идентификатора определяет отдельную сущность.
В третьей нормальной форме устраняются атрибуты, зависящие от атрибутов, не входящих в уникальный идентификатор. Эти атрибуты являются основой отдельной сущности.
После того, как созданы локальные представления, выполняется их объединение. При небольшом количестве локальных областей (не более пяти)
они объединяются за один шаг. В противном случае обычно выполняют бинарное объединение в несколько этапов.
При объединении проектировщик может формировать конструкции, производные по отношению к тем, которые были использованы в локальных представлениях. Такой подход может преследовать следующие цели:
· объединение в единое целое фрагментарных представлений о различных свойствах одного и того же объекта;
· введение абстрактных понятий, удобных для решения задач системы, установление их связи с конкретными понятиями, использованными в модели;
· образование классов и подклассов подобных объектов (например, класс "изделие" и подклассы типов изделий, производимых на предприятии).
На этапе объединения необходимо выявить и устранить все противоречия. Например, одинаковые названия семантически различных объектов или связей или несогласованные ограничения целостности на одни и те же атрибуты в разных приложениях. Устранение противоречий вызывает необходимость возврата к этапу моделирования локальных представлений с целью внесения в них соответствующих изменений.
По завершении объединения результаты проектирования являют собой концептуальную инфологическую модель предметной области. Модели локальных представлений – это внешние инфологические модели.
Концептуальные и физические ER-диаграммы.
Различают
концептуальные и
физические
ER-диаграммы.
Концептуальные диаграммы не учитывают особенностей конкретных СУБД.
Физические диаграммы строятся по концептуальным и представляют собой прообраз конкретной базы данных. Сущности, определенные в концептуальной диаграмме становятся таблицами, атрибуты становятся колонками таблиц (при этом учитываются допустимые для данной СУБД типы данных и наименования столбцов), связи реализуются путем миграции ключевых атрибутов родительских сущностей и создания внешних ключей.
При правильном определении сущностей, полученные таблицы будут сразу находиться в 3НФ.

Лекция 9.
1   2   3   4   5   6


написать администратору сайта