- •Системный анализ и проектирование компьютерных информационных систем
- •1Введение в системный анализ
- •1.1Системный анализ как научная дисциплина
- •1.2Компьютерная техника и системный анализ
- •1.3Система и ее свойства
- •Свойства системы
- •1.3.1Структура и иерархия систем
- •1.3.2Модульное строение системы
- •1.3.3Состояние системы и процессы в системе
- •1.3.4Целенаправленные системы и управление
- •Управление системами
- •1.4Принципы системного подхода
- •Принцип конечной цели
- •Принцип единства и связи
- •Принцип модульного построения
- •Принцип иерархии
- •Принцип функциональности
- •Принцип развития
- •Принцип децентрализации
- •Принцип неопределенности
- •Дополнительные принципы системного подхода
- •Практическое использование принципов системного подхода
- •2Информационные системы. Жизненный цикл информационной системы
- •2.1Определение информационной системы
- •Информация, данные, знания
- •Информационная система
- •2.2Классификация информационных систем
- •Классификация по типу хранимых данных
- •Классификация по степени автоматизации информационных процессов
- •Классификация по характеру обработки данных
- •Классификация по сфере применения
- •Классификация по уровню управления
- •Классификация по способу организации
- •2.3Жизненный цикл информационной системы
- •2.3.1Системный анализ
- •Определение требований
- •Оценка осуществимости
- •Оценка риска
- •Построение логической модели
- •Построение прототипа
- •2.3.2Проектирование
- •2.3.3Реализация
- •2.3.4Тестирование
- •2.3.5Эксплуатация
- •2.4Модели жизненного цикла информационной системы
- •2.4.1Каскадная модель жизненного цикла информационной системы
- •Основные достоинства каскадной модели
- •Недостатки каскадной модели
- •2.4.2Спиральная модель жизненного цикла информационной системы
- •Преимущества спиральной модели
- •3Методологии и технологии проектирования информационных систем
- •3.1Общие требования к методологиям и технологиям
- •Технологическую операцию проектирования представим:
- •3.2Стандарты организации жизненного цикла информационных систем
- •Стандарт проектирования должен устанавливать:
- •Стандарт оформления проектной документации должен устанавливать:
- •Стандарт интерфейса пользователя должен устанавливать:
- •3.3Методология быстрой разработки приложений rad
- •Фаза анализа и планирования требований
- •Фаза проектирования
- •Фаза построения
- •Фаза внедрения
- •Особенности и ограничения применения методологии rad.
- •Основные принципы методологии rad:
- •3.4Структурный подход к проектированию информационных систем
- •Структурный подход
- •Структурный анализ
- •Средства структурного анализа
- •4Методология функционального моделирования sadt (стандарт idef0)
- •4.1Анализ предметной области и принципы функционального моделирования по методологии sadt (стандарт оформления idef0)
- •Субъект моделирования
- •Цель моделирования
- •Точка зрения на модель
- •Модели as-is и то-ве
- •Принципы моделирования
- •4.2Состав функциональной модели sadt Типы диаграмм sadt-модели
- •Контекстная диаграмма
- •Диаграммы декомпозиции
- •Диаграммы дерева узлов
- •4.3Элементы контекстной диаграммы модели sadt Работа
- •Граничные стрелки
- •Контекстная диаграмма
- •4.4Элементы диаграммы декомпозиции модели sadt Работы
- •Миграция граничных стрелок и icom-коды
- •Внутренние стрелки
- •Разветвляющиеся и сливающиеся стрелки
- •4.5Иерархия диаграмм модели и диаграмма дерева узлов Иерархия диаграмм и контроль граничных стрелок
- •Туннелирование стрелок
- •Нумерация блоков и диаграмм
- •Диаграмма дерева узлов
- •4.6Рекомендации по рисованию диаграмм
- •4.7Проверка достоверности модели sadt
- •4.8Пример моделирования информационной системы с помощью методологии sadt (стандарт idef0)
- •Определение предметной области
- •Выбор цели
- •Выбор точки зрения
- •Построение контекстной диаграммы
- •Построение диаграммы декомпозиции а0
- •Выбор блока для декомпозиции следующего уровня
- •Построение диаграммы декомпозиции а2
- •Построение диаграммы декомпозиции а1
- •Окончание декомпозиции
- •Построение диаграммы дерева узлов
- •5Методологии получения количественных оценок функциональных моделей
- •5.1Цели проведения функционально-стоимостного анализа
- •5.2Построение фса-модели на базе idef0-модели
- •5.3Пример проведения функционально-стоимостного анализа с помощью методологии фса
- •6Методология последовательного выполнения процессов workflow (стандарт idef3)
- •6.1Базовые элементы модели idef3
- •Единицы работы
- •Перекрестки
- •Объект ссылки
- •6.2Иерархия диаграмм модели idef3 Контекстная диаграмма
- •Диаграммы декомпозиции
- •Нумерация работ и диаграмм
- •6.3Временные диаграммы активизации работ
- •6.4Пример применения методологии последовательного выполнения работ idef3
- •7Методология моделирования диаграмм потоков данных dfd
- •7.1Базовые элементы модели dfd
- •Процессы
- •Внешние сущности
- •Хранилища данных
- •Потоки данных
- •7.2Иерархия диаграмм потоков данных dfd к онтекстная диаграмма
- •Диаграмма декомпозиции
- •Нумерация работ и диаграмм
- •8Моделирование данных
- •8.12.1. Управление данными как ресурсами
- •8.22.2. Концепция трех схем
- •8.32.3. Цели моделирования данных
- •8.42.4. Idef1x-подход
- •8.53. Синтаксис и семантика idef1x
- •1. Сущности
- •8.5.13.1. Сущности
- •8.5.23.2. Отношения связи
- •8.5.33.3. Отношения категоризации
- •8.5.43.4. Неспецифические отношения
- •8.5.53.5. Атрибуты
- •8.5.63.6. Первичные и альтернативные ключи
- •8.5.73.7. Внешние ключи
- •8.64. Процедуры моделирования
- •8.6.14.1. Стадия 0 - начало работы над проектом
- •4.1.1. Определение цели моделирования
- •4.1.2. Разработка плана моделирования
- •4.1.3. Организационная структура коллектива разработчиков
- •4.1.4. Сбор исходной информации
- •4.1.5. Авторские соглашения
- •8.6.24.2. Стадия 1 - определение сущностей
- •4.2.1. Идентификация сущностей
- •4.2.2. Определение сущностей
- •8.6.34.3. Стадия 2 - определение отношений
- •4.3.1. Установление связанных сущностей
- •4.3.2. Определение отношений
- •4.3.3. Построение диаграмм уровней сущностей
- •8.6.44.4. Стадия 3 - определения ключей
- •4.4.1. Разрешение неспецифических отношений
- •4.4.2. Изображение функциональных точек зрения
- •4.4.3. Определение ключевых атрибутов
- •4.4.4. Миграция ключей
- •4.4.5. Проверка правильности ключей и отношений
- •4.4.6. Определение ключевых атрибутов
- •4.4.7. Изображение результатов стадии 3
- •8.6.54.5. Стадия 4 - определение атрибутов
- •4.5.1. Идентификация неключевых атрибутов
- •4.5.2. Определение владельцев атрибутов
- •4.5.3. Определение атрибутов
- •4.5.4. Детализация модели
- •4.5.5. Представление результатов стадии 4
- •8.75. Документирование и верификация
- •8.7.15.1. Введение
- •8.7.25.2. Idef1x-папка
- •8.7.35.3. Стандартные бланки
- •8.7.45.4. Процедура сквозного анализа idef-модели
- •8.8Приложение а
- •8.9Инфологическое проектирование
- •8.9.1Сущности и атрибуты
- •1.2.2. Связи
- •1.2.3. Формализация связей
- •1.2.4.Развитые элементы er-модели
- •9Сравнение существующих методик
- •Объектно-ориентированная методика
8.5.73.7. Внешние ключи
Семантика внешних ключей
Если между двумя сущностями имеется специфическое отношение связи или категоризации, то атрибуты, входящие в первичный ключ родительской или общей сущности, наследуются в качестве атрибутов сущностью-потомком или категорией сущностью соответственно. Эти наследуемые атрибуты называются внешними ключами. Например, если существует отношение между сущностью ПРОЕКТ как родителем и сущностью ЗАДАНИЕ как потомком, то атрибуты первичного ключа сущности ПРОЕКТ будут наследуемыми атрибутами сущности ЗАДАНИЕ. Например, если атрибут ПРОЕКТ_ID являлся первичным ключом сущности ПРОЕКТ, то ПРОЕКТ_ID будет также наследуемым атрибутом или внешним ключом сущности ЗАДАНИЕ.
Наследуемый атрибут может использоваться в сущности в качестве. части или целого первичного ключа, альтернативного ключа или неключевого атрибута. Если все атрибуты первичных ключей сущности-родителя наследуются в качесте части первичного ключа сущности-потомка, то отношение, через которое эти атрибуты были унаследованы; называется идентифицирующим отношением. Если какой-нибудь из наследуемых атрибутов не является частью первичного ключа, то отношение называется неидентифицирующим отношением (см. раздел 3.2). Например, если задания имеют номера, уникальные только в пределах своего проекта, то для определения первичного ключа ЗАДАНИЯ необходимо соединить наследуемый атрибут ПРОЕКТ_ID с собственным атрибутом НОМЕР_ЗАДАНИЯ. Сущность ПРОЕКТ будет обладать идентифицирующим отношением с сущностью ЗАДАНИЕ. Если, с другой стороны, атрибут НОМЕР_ЗАДАНИЯ всегда уникален (даже для разных проектов), то наследуемый атрибут ПРОЕКТ_ID будет неключевым атрибутом сущности ЗАДАНИЕ. В этом случае сущность ПРОЕКТ будет обладать неидентифицирующим отношением с сущностью ЗАДАНИЕ.
В отношении категоризации и общая сущность, и сущности-категории изображают один и тот же предмет реального мира. Поэтому для всех сущностей-категорий первичный ключ наследуется через отношение категоризации из первичного ключа общей сущности. Например, ШТАТНЫЙ_СЛУЖАЩИЙ и СЛУЖАЩИЙ_ПОЧАСОВИК являются сущностями-категориями, а СЛУЖАЩИЙ является общей сущностью. Если атрибут НОМЕР_СЛУЖАЩЕГО является первичным ключом для сущности СЛУЖАЩИЙ, то он будет также первичным ключом для сущностей ШТАТНЫЙ_СЛУЖАЩИЙ и СЛУЖАЩИЙ_ПОЧАСОВИК.
В некоторых случаях сущность-потомок может иметь несколько отношений с одной и той же сущностью-родителем. Первичный ключ сущности-родителя появится для каждого отношения в качестве наследуемых атрибутов в сущности-потомке. Для данного экземпляра сущности-потомка значения наследуемых атрибутов могут быть различными для различных отношений, т.е. может быть ссылка на два разных экземпляра сущности-родителя. Например, спецификация некоторого устройства может изображаться двумя сущностями: ДЕТАЛЬ и УЗЕЛ. Сущность ДЕТАЛЬ в качестве сущности-родителя обладает двойным отношением с сущностью УЗЕЛ. Одна и та же деталь может служить как компонентой, из которой производится узел (т.е. деталь может быть компонентой одного или многих узлов), так и иногда быть узлом, в который собираются компоненты (т.е. деталь может быть узлом для одной или более деталей-компонент). Если НОМЕР-ДЕТАЛИ является первичным ключом для сущности ДЕТАЛЬ, то НОМЕР-ДЕТАЛИ дважды появляется в сущности УЗЕЛ в качестве наследуемого атрибута.
Когда отдельный атрибут наследуется более одного раза, для каждого случая должно назначаться имя роли. В предыдущем примере имена ролей НОМЕР_КОМПОНЕНТЫ и НОМЕР_УЗЛА могут назначаться для различения двух наследуемых атрибутов НОМЕР_ДЕТАЛИ. Имена ролей могут использоваться и при единственном появлении наследуемого атрибута для более точного выражения его смысла в контексте сущности-потомка, но это не является обязательным.
Синтаксис внешних ключей
Внешний ключ изображается с помощью помещения внутрь блока сущности имен наследуемых атрибутов, после которых следуют буквы FK в скобках (FK), см рис.3-9.
Рис. 3-9. Примеры синтаксиса внешних ключей
Если наследуемый атрибут принадлежит первичному ключу сущности-потомка, то он помещается выше горизонтальной линии, а сущность изображается с закругленными углами для указания на то, что идентификатор (первичный ключ) сущности зависит от атрибута, наследуемого через отношение. Если наследуемый атрибут не принадлежит первичному ключу сущности-потомка, то он изображается ниже линии. Наследуемые атрибуты могут быть также частью альтернативного ключа.
Имена ролей, как и имена атрибутов, являются грамматическими оборотами существительного. За именем роли следует имя наследуемого атрибута, отделенное точкой (см.рис.3-10).
Рис. 3-10. Синтаксис имени роли
Правила внешних ключей
Каждая сущность должна содержать отдельный внешний ключ для каждого специфического отношения связи или категоризации, в котором эта сущность является сущностью-потомком или сущностью-категорией.
Первичный ключ общей сущности должен наследоваться в качестве первичного ключа для каждой сущности-категории.
Сущность не должна содержать двух полных внешних ключей, которые идентифицируют один и тот же экземпляр одной и той же родительской или общей сущности для каждого экземпляра сущности-потомка или сущности-категории (в противном случае существует только одно отношение и необходим только один внешний ключ).
Каждый наследуемый атрибут сущности-потомка или сущности-категории должен представлять атрибут из первичного ключа связанной родительской или общей сущности. Наоборот, каждый атрибут первичного ключа родительской или общей сущности должен быть наследуемым атрибутом в связанной сущности-потомке или сущности-категории.
Каждое присвоенное наследуемому атрибуту имя роли должно быть уникальным, а одному и тому же имени должен соответствовать один и тот же смысл. Кроме того, один и тот же смысл не может соответствовать различным именам, если только эти имена не являются псевдонимами.
Один наследуемый атрибут может быть частью более чем одного внешнего ключа, если этот атрибут всегда имеет одно и то же значение для всех внешних ключей в любом данном экземпляре сущностей.
