Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
ПрИС - кратко 2010.docx
Скачиваний:
4
Добавлен:
16.07.2019
Размер:
171.29 Кб
Скачать

6 Проектирование ис - выжимки

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

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

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

Факты могут храниться в БД системы, если они нужны по требованиям задачи для сокращения объема хранимых по  данных, для обеспечения контроля правильности/выбора из списков, для уменьшения списков выбора,  для автоматической подстановки вводимых данных, чтобы не повторять расчет.

Подфакт (ПФ) факта Ф - это самостоятельный факт, подразумеваемый в Ф. ПФ содержит только часть параметров Ф. С точки зрения математической логики ПФ - следствие Ф. ПФ не имеет значения для ER-модели и отбрасывается, если его не требуется хранить, или  один ПФ может использоваться только в одном Ф (соотношение Ф и ПФ - один-к-одному( )).

Прием: Для выделения ПФ надо о каждом параметре факта Ф задать вопрос: «Почему здесь написано именно это? Что хотел этим сказать писавший?» Ответ сформулировать как факт, имеющий самостоятельное значение (который понятен и может использоваться независимо от исходного Ф). Пример: Ф: «22.01.09 Иванову выдано 3 м кабеля по 35 р.». Зададим вопрос о единице измерения: «Почему здесь написано именно «м»? Что этим хотели сказать?» Ответ: имели в виду, что «кабель измеряется в м». Это и есть искомый ПФ.

Проверка: если при выделении ПФ отброшен параметр П, то это значит: «системе важно знать ПФ, все равно, каков П». В предыдущем примере: «Важно знать, что «кабель измеряется в м», все равно, какова цена». В то же время: «Важно знать, что «выдано 3 м кабеля», все равно кому (или когда, или по какой цене)» - очевидно неверно, значит ПФ «выдано 3 м кабеля» - неправильный.

Тривиальный ПФ (ТПФ) - это ПФ, имеющий вид: «значениеПараметра - это наименованиеПараметра». Например: «м - это единица измерения». ТПФ можно не упоминать в проекте, а отражать в ER "на лету", при отражении Ф. NB: если наименование параметра - это роль, то ее надо заменить сущностью, которая эту роль играет. Например, вместо «ООО “Альфа” - это поставщик» надо писать: «ООО “Альфа” - это контрагент (или организация)»

Ситуации использования системы (Use Case, прецеденты). Работа системы описывается путем разбора на конкретных примерах – ситуациях. Каждая ситуация соответствует одному сеансу связи пользователя (не обязательно человека) с информационной системой, одному обращению пользователя к системе. Обычно ей соответствует форма ввода и соответствующий пункт главного меню. В ФМП для описания ситуации просто перечисляют факты: Созданные в ситуации (обычно сообщенные системе пользователем), прочтенные из БД, удаленные из БД, скорректированные. Дополнительно указывается, откуда системой получены числа и другие данные для заполнения параметров: введены пользователем, вычислены по формуле, прочтены из БД, как параметр факта, являются константами

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

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

Правила чтения кардинальности (читаемый элемент обведен красным пунктиром ):

(1,3 - проверка множественности, 2,4 - обязательности)

 – читаемый элемент

        – его «расшифровка»

название

одно А может быть связано с несколькими В

"множественный" конец (метелка)

одно А может быть связано с нулем В

"необязательный" конец (нолик)

одно А может быть связано максимум с одним В

"единичный" конец (палец)

одно А может быть связано минимум с одним В

"обязательный" конец

Обратите внимание: начинаем читать контрольную фразу всегда с сущности на противоположном от проверяемого конце (потому, что читаемый символ относится к сущности, возле которой нарисован!). К ней всегда относится слово «одно»! (см. строчки 2, 3 и 4).

Однозначной (множественной, обязательной) связью сущности А называется ее связь, второй конец которой – единичный (множественный, обязательный)

Ключ сущности – это набор атрибутов и/или (однозначных) связей, зная которые можно однозначно найти экземпляр сущности. Атрибуты, входящие в ключ, подчеркиваются, а связи – помечаются стрелкой.

Как найти ключ сущности S: выбрать множество кандидатов (атрибутов и однозначных связей). Про каждого кандидата К спросить: «Может ли так быть, что у 2х S все кандидаты кроме К одинаковые, а К – разный?» Если нет - выбрасываем К из кандидатов. Кандидаты, оставшиеся в конце, составляют ключ.

Дополнительно надо задать вопрос: «Могут ли у 2х S все кандидаты быть одинаковыми?». Если да, то у сущности нет смыслового ключа и нужен формальный.

Формальный ключ (ФК) или код - ключ, не имеющий смысла с точки зрения пользователя. ФК надо избегать, кроме случаев, когда: смысловой ключ (СК) ОЧЕНЬ длинен, СК содержит множественную связь, смысловых атрибутов недостаточно для однозначной идентификации экземпляра,  СК содержит рекурсивную связь.

Наследование-классификация. Если у сущностей В, C,... есть общие атрибуты или связи, то рекомендуется выделить общую часть описания в сущность А и связать ее с В, C,... связью "наследует": . Эта связь читается «В является А». Она называется также "классификация", т.к. в обратную сторону читается "А бывает В или С":

означает, что сущность В имеет кроме атрибутов в1 и в2 еще и атрибуты а1 и а2.

означает, "работник бывает конюхом или плотником"

Общие правила для ER-модели:

  • В ER-модели показывается только то, что хранится в базе данных (никаких связей типа "бухгалтерия отвечает за прием накладных…" и т.п.)

  • Того, что в заголовке сущности, должно быть много! (сущность "человек" – значит много человеков, сущность "директор" – значит много директоров…)

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

Правила именования: Сущности именуются существительными в единственном числе. Слов, подразумевающих множество, (журнал, список, набор, …) тоже избегать. Для указания разного уровня абстрактности использовать слова "тип", "вид" и т.п. ("машина" и "тип машины"). В названии атрибута имя сущности подразумевается и, следовательно, не пишется. Для параллельных связей роли обязательны.

Единичные факты (т.е. присутствующие в БД в 1 экземпляре) представляются в проекте по особому: всем их параметрам даются уникальные во всей ИС имена и каждому параметру сопоставляется факт вида: «параметр равен значение» Все эти факты имеют одну структуру и => представляются в БД одной таблицей (называемой например «характеристика системы»).

Правила представления набора фактов в ER-модели (только неединичных, единичные см. выше).

В ER представляются только хранимые факты и только хранимые параметры!

  1. Перед фактом в ER надо представить его подфакты (в том числе – тривиальные).

  2. Каждый факт Ф представляется в ER всегда НОВОЙ сущностью Ф.

Далее будем отождествлять сущности и представляемые ими факты.

Наименование сущности давать ТОЛЬКО ПОСЛЕ проверки кардинальностей! (в п. 9)

До тех пор именовать сущность «рассматриваемый факт».

  1. Если в Ф есть списки (т.е. перечисления), то создать по одной сущности ЭСi для каждого списка (не элемента!). Каждая сущность представляет элементы одного списка (именовать до проверки «элемент списка такого-то»). Связями Ф ЭСi (или ЭСi ЭСj) показать, что во что входит: множественный конец - что входит, единичный - во что (например: факт - 1, элементов списка - много).

Проверить только обязательность множественного конца .

  1. Соединить Ф с его подфактами связью ПФ Ф (NB ! единичный конец указывает подфакт!). Проверить кардинальность, кроме единичного конца.

  2. Соединить связями « » Ф с другими фактами (Ф1), имеющими с ним общие (не по имени, а по значению!) параметры: Ф Ф1 или Ф1 Ф.

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

  1. Общие параметры фактов Ф Ф1, связанных связью 1-ко-многим, на множественном конце (в сущности Ф) не отображаются. (Они "переносятся" по связи.)

  2. Остальные параметры отображаются атрибутами сущности Ф.

NB! Если параметр записан в элементе списка, то представлять его в сущности ЭСi вместо Ф.

  1. После представления в ER всех параметров Ф надо проверить кардинальность всех связей. Не проверяется кардинальность единичного конца, указывающего на ПФ («указательный палец»). Множественность конца, обращенного к Ф, и обязательности обоих концов проверяются.

  2. После добавления каждого факта в ER-модель необходимо провести оптимизацию.

  3. Дать название неименованным сущностям.