если значения нескольких полей, возможно, придется писать многократно – выделяй их в отдельную сущность (и оставляй в старой связь к новой).
Исключение из этого правила: если новая сущность содержит только ключевые атрибуты, то мы не получим выигрыша. Однако даже в этом случае может быть лучше поступить по правилу: 1. у сущности с течением времени могут появиться еще атрибуты, 2. отдельный список можно использовать для хранения списка разрешенных значений (и выбора из него).
Списки дел. Это - ситуации, вызываемые по инициативе не пользователя, а системы. Служат для «склеивания» нескольких сеансов связи пользователя с системой в один. Нужны, если известно, что некоторое по смыслу единое действие невозможно провести за один сеанс. Например, нужно подождать некоторого внешнего события, или действие должен продолжить другой человек. Служат напоминанием пользователю и позволяют полностью восстановить контекст прерванного сеанса (набор форм, текущие записи, положение курсора и т.п.) Обычно связаны с прохождением некоторого информационного объекта (документа) через несколько ситуаций. Этот же механизм можно использовать для запоминания прерванных по желанию пользователя сеансов и восстановления их. Каждый пункт списка дел запускает определенную ситуацию при согласии пользователя (+нужна функциональность будильника: «напомнить в определенное время», «отложить на время», «пометить как сделанное (т.е. удалить из списка)», «показывать только при определенном условии», «автоматически удалить при определенном условии» …)
Пример: автоматизируемый вид деятельности – «добавление в прайс новой услуги». Информационный объект – «услуга».
Ситуации, через которые он проходит:
1. «ввод услуги в анкету», состояние объекта – «предлагаемая в анкете», список дел для занимающегося анкетированием: «бланки анкет изменились - перепечатать перед использованием», Запускает ситуацию «печать бланков».
2. «ввод результата анкетирования», возможное изменение состояния объекта – «популярная у клиентов – кандидат на добавление в прайс», список дел для директора: «клиенты хотят новую услугу – добавлять?», запускает ситуацию «рассмотрение директором новой услуги»
3. «рассмотрение директором новой услуги», возможное изменение состояния объекта – «добавляемая в прайс», список дел для бухгалтера: «составить смету на новую услугу», запускает ситуацию «составление сметы на новую услугу».
4. «составление сметы на новую услугу», возможное изменение состояния объекта – «смета готова», список дел для директора: «посмотрите смету на новую услугу», запускает ситуацию «утверждение сметы директором».
5. «утверждение сметы директором», возможное изменение состояния объекта – «смета утверждена», список дел для снабженца: «заключить договор на поставку материалов на услугу», запускает ситуацию «ввод заключенного договора» (снабженец откладывает этот пункт, пока не заключит договор).
6. «ввод заключенного договора», возможное изменение состояния объекта – «договоры заключены», список дел для снабженца: «сообщить, поставлен ли материал на услугу» (начинает показываться при наступлении срока поставки, автоматически уничтожается при вводе информации о поставленных материалах), запускает ситуацию «ввод информации о поставленных материалах» или «ввод заключенного договора» (чтобы заключить новый договор, если долго не поставляют).
7. «ввод информации о поставленных материалах», возможное изменение состояния объекта – «материалы поставлены», список дел для отдела сбыта: «включить услугу в прайс», запускает ситуацию «корректировка прайса».
Виды описания ИС: функции и потоки данных (DFD), статический портрет - структуры данных (ER), динамика - последовательности событий (STD) и обмен сообщениями (MSC).
Функциональное описание - DFD диаграмма. Состоит из процессов, хранилищ и потоков данных между ними. Говорит о том, какие данные циркулируют в системе и как они преобразуются друг в друга. То, что преобразует данные, называется процессами. Они отражаются на DFD-диаграмме в виде кругов с названием процесса внутри. Потоки данных – стрелки. На стрелках – краткое пояснение сущности передаваемых данных. Описание проводится иерархически: процессы – черные ящики, внутренность которых раскрывается в DFD-диаграммах следующих уровней. Проверка делается по процессам (для указанного процесса должно хватать перечисленных входящих в него данных; выходящие стрелки должны перечислять все получаемые от процесса результаты) Хранилища нужны для синхронизации разновременных процессов. Т.е. если заведомо известно, что процесс-потребитель и процесс-источник данных происходят в разное время, между ними помещают хранилище. Входы/выходы системы – "внешние сущности" – изображаются квадратами ("директор", "клиент" и т.п.)
Карты обмена сообщениями (MSC). Показывают порядок и временную последовательность обмена сообщениями между участниками ситуации. Состоят из «линий жизни» (вертикальные линии) участников ситуации (процессов или внешних сущностей) и сообщений между ними (стрелки между линиями). То, что происходит, позже рисуется ниже.
Диаграммы состояний и переходов (STD). Показывают состояния информационного объекта (кружки с названиями), возможные переходы между ними (стрелки) и их условия (над стрелками). Начальное состояние изображается
Дополнительные пояснения
Пример правильного фрагмента описания ИС (наименования опущены):
В ситуации «расчет заработной платы» система создает факты вида:
§ В июне 2003 г Иванов Иван Иванович заработал 500 р. 00 коп.
Для создания этого факта ИС учитывала, что:
§ Иванов Иван Иванович имеет табельный номер 243
§ 20.06.03 работник с табельным номером 243 выполнил работу "изготовление стула" в объеме 5шт.
§ Тариф на выполнение 1 шт. работы "изготовление стула" равен 100 р.
Примеры ошибочных фактов:
§ Накладные подписывает главный бухгалтер.
Нет переменных частей. Такие факты в БД не хранятся!
§ Клиент получил определенный материал.
В факте записываются конкретные значения (взятые из гипотетической ситуации), а не их описания. (Что на самом деле будет написано на месте слова "клиент"? ФИО? Код? Расчетный счет? Или слова «наш работник», «VIP клиент» - для определения размера скидки?)
§ 20.06.03 работник с табельным номером 243 выполнил работы "изготовление стула" и "ремонт рамы ".
Перечисление должно быть оформлено как список. Правильно:
20.06.03 работник с табельным номером 243 выполнил работы:
§ "изготовление стула"
§ "ремонт рамы ".
20.06.03 отсутствовали работники Иванов, Сидоров, Гречаник.
Нарушено правило "один параметр содержит ровно одно данное". Правильно:
20.06.03 отсутствовали работники:
§ Иванов
§ Сидоров
§ Гречаник
§ Иванов Иван Иванович получил 43 кг цемента.
Когда таких фактов будет много, невозможно будет определить, когда это произошло, по какому документу и т.п.