ПИ_Конспекты
.docxФорма представления информации в рамках реляционной модели
Одной из проблем с которой сталкиваются разработчики баз данных является проблема оценки. Существуют много способов для группировки данных. Ряд из них может привести к проблемам. Например, крайне нежелательной является такая компоновка данных которая в последствии может привести к расщеплению записи на 2 части. Данные сгруппированы неплохо если каждая таблица представлена в 3 нормальной форме (3=2+ что-то, 2= 1 + что-то). Существуют и иные способы представления информации. Нормальная форма бойса-кодда, 4 нормальная форма, 5 нормальная форма, 6 нормальная форма. Схема ношения находится в 1 нормальной форме если для каждого атрибута в этой схеме значение в домене соот. этому атрибуту являются атомарными, то есть не явл. ни списками, ни множествами простых или сложных значений. Значение атомарное в одном приложении может быть не атомарным в другом. Будем считать, что значение не атомарно если в приложении предполагается его использование по частям. Определение атомарности видимо является задачей разработчиков прикладной базы данных. Контр-пример: Пример отношения который не является отношением первой нормальной формой. Пуст необходимо хранить ФИО, Дату рождения и инфо о родителях, составим инфо так, как это показано на рис 4.3.2. Скорее всего инфо л родителях явл. вспомогательной инфо и по частям использоваться не будет. Определение второй нормальной формы связано с понятием функциональной зависимости. Атрибут В схемы некоторого отношения функционально зависит от атрибута А той же схемы, если в любой момент времени любому значению атрибута А соответствует не более чем одно значение атрибута В. Атрибут или набор атрибутов В схемы некоторого отношения называется полностью зависимым от другого набора атрибутов А той же схемы, если В функционально зависит от всего множества А, но не зависит ни от какого подмножества А. Пусть необходимо обеспечить учет сотрудников гос предприятия, а сотрудник определяется ФИО и занимаемой должностью. Пусть инфо моделируется отношением представленном на рисунке 4.3.5. Целесообразнее представить информацию как на рис 4.3.7. На ри 4.3.7 ФИО будет первичный ключ, а позиция внешний ключ. Более эффективным кажется. Понятие 3 нормальной формы связано с понятием транзитивной зависимости. Все базы находятся в 3 нормальной форме, если все таблицы находятся в 3 нормальной форме. У каждой базы данных есть свои ограничения, налагаемые на хранимую в ней информацию. Например: Зарплата не может быть отрицательной, фамилия не может содержать цифр, и тд. Такие ограничения называются правилами целостности. 2 следующих правила целостности актуальны для всех реляционных баз данных. –Целостность по ключу – ни одно значение атрибута, входящего в первичный или альтернативный ключ отношения не может быть неопределенным. – Целостность по внешнему ключу
4 ТЕМА – ФУНКЦИОНАЛЬНОЕ МОДЕЛИРОВАНИЕ
В процессе создания автоматизированной системы ее приходится многократно описывать в технической, проектной документации. Такое описание осуществляется с разных точек зрения и с раздельных ракурсов. Для описания используют функциональное моделирование. В процессе совершенствования подходов проектирования получили распространение семейство методологий IDEF и DFD. IDEF – стандарты США. К семейству IDEF относят следующие методологии: IDEF 0(методология функц. модел. на основе граф языка IDEF 0, благодаря которой изучаемая система предстает в виде набора взаимосвязанных функций). Функц. Модел. Означает что описываемая система представляется в виде графа, вершинам которого соответствуют функции системы, а ребрам – потоки ресурсов и информации; IDEF 1 (Методология автоматизированных потоков протекающая внутри объекта автоматизации); IDEF 1X (Методология сущности отношения (entity relationship) – это и есть реляционная модель данных); IDEF 2 (методология моделирования процесса развития системы (в связи со сложностями анализа динамических систем, от этой методологии практически отказались)); IDEF 3 (Методология документирования технологических процессов на предприятиях(С помощью нее можно описать последовательность операций такого процесса)); BPwin (Она удачно дополняет модель IDEF 0); IDEF 4(методология объектного ориентирования); IDEF 5 (методология исследования сложных систем посредствам их представления в виде некоторого словаря терминов и правил)
Методологию IDEF 0 можно считать следующим этапом развития хорошо известного языка описания систем – Structured Analysis and Design Technique (SADT). IDEF берется от ICAM Definition. В процессе автоматизации военных операций участники столкнулись с необходимостью наличия эффективных методов анализа процессов взаимодействия в промышленных системах. При этом кроме усовершенствованного набора функций для описания бизнес процесса, одним из требований к инструментарию было наличие эффективных механизмов взаимодействия всех аналитиков и специалистов, занятых в рамках проекта. Диаграммы потоков данных (DFD – Data Flono Diagrams) были разработаны американскими специалистами – Крисом Гейном и Тришем Сарсоном для проведения структурного анализа и проектирования. DFD диаграммы отражают потоки данных от внешней сущности систем, движения данных от одного процесса данных к другому, а так же логические хранилища информации системы.
На рынке ПО существует большое количество программных пакетов – кейс средств, которые служат для автоматизации проектирования и разработки АЭС. Ширукую известность получили: Erwin (Реляционная модель данных); BPwin; Microsoft office; Visio Professional; Rational Rose; Silow Run; Oracle Designer и др.
Методология IDEF 0
В соответсвии с этой методологией объект исследования представляет собой совокупность иерархически и взаимосвязанных диаграмм. Каждая диаграмма является единицей описания системы и располагается на отдельном листе. Информация представляется в виде графического языка, в основе которого лежат 4 понятия:
1.Функциональный блок (Функц. Блоки обозн. Поименованные процессы, функции или задачи которые происходят в течении определенного времени и имеют четко распознаваемые результаты. Все функц. блоки должны быть названы, определены и иметь свой идентификационный номер. Изображается в виде прямоугольника, каждая из сторон которого имеет собственное назначение);
2.Интерфейсная дуга (Их так же называют потоками и стрелками. Они отображают объекты сисемы которая обрабатывается функц. блоком или оказывает иное влияние на функц. Отображенное таким функц. Блоком. Это либо осязаемые объекты, либо объекты информации. Графическим отображением интер. дуги является функц. Стрелка. Каждая интер. Дуга должна иметь собственное наименование, которое должно быть выражено существительным. В зависимости от стороны функц. блока она носит название входящей, исходящей, направляющей или дуги механизма. Источником каждой дуги могут быть функц. блоки или диаграммы. При этом источником может быть правая сторона блока, а приемником любая из 3 оставшихся сторон) Управляющая дуга отображает законы, правила, стандарты которыми необходимо руководствоваться в процессе работы над представленным функц. блоком. Каждый блок должен иметь хотя бы одну стрелку направления. Стрелка упраления рисуется входящей в верхнюю грань блока. Управление влияет на процесс, но не преобразуется процессом. Если необходимо изменить процедуру или стратегию, то такая процедура или стратегия будет для блока уже входом. Стрелка входа рисуется как входящая в левую грань блока. Допускается что блок может не иметь стрелку входа. Стрелки входа и выхода должны быть строго определены для подчеркивания того что объект действительно был изменен для данной функции процесса. Зачастую сложно определить, являются данные входом или управлением. В таком случае следует определить, изменяются ли данные. Если изменяются – это вход.
(На SQL написать систему автоматизации предприятия)
Выходящая дуга обозн. Материал или инфо которая возникает в процессе работы. Каждый блок должен иметь хотя бы одну стрелку выхода. Дуга механизма обозначает ресурсы, которые выполняют работу. Каждый блок должен иметь хотя бы одну стрелку управления и выхода. Различают 5 типов связи блоков. 1 – Связь по входу (Стрелка выхода одного блока направляется на вход другого). 2 – Связь по управлению (Выход одного блока направляется на управление другого) 3 – обратная связь по ходу (выход следующего блока направ. на вход предыдущему. Используется для описания циклов) 4 – Обратная связь по управлению (выход на вход) 5 – Связь выход на механизм (). В каждой грани блока может связано несколько стрелок. Явные, разветвляющиеся и сливающиеся. Существует определенное правило наименования для таких стрелок. Пример на разветвляющихся: Если стрелка именована до разветвления, а после не именована, подразумевается, что все ветви имеют одинаковое именование. Если стрелка именована до разв. а после … ПОХУЙ не успел. Недопустима ситуация когда стрелка изначально не именована, а потом .. хуй его знает. Для сливающихся стрелок аналогично. В процессе автоматизации предприятия выделяют потоки материальных ценностей, финансовые потоки, потоки документов, потоки информации, потоки ресурсов. При этом входящими и исходящими дугами могут отображаться все виды перечисленных объектов. Управляющими только относ. к потокам документов и информации. А дуговыми механизмами только потоки ресурсов.
Понятие Декомпозиции. Применяется в процессе разбиения сложного процесса на составляющие компоненты. Уровень детализации зависит от разработчика. Декомпозиция позволяет представить реляционную сист. в виде иерархически структурированных диаграмм, что делает ее менее перегруженной. IDEF 0 всегда начинается с представлении системы как в виде единого целого. Диаграмма с одним блоком называется контекстной диаграммой. Такая диаграмма должна содержать определение субъекта моделирования, цель моделирования и точку зрения на модель. Под субъектом моделирования понимается сама система. При этом необходимо установить, что входит в систему, а что лежит за ее пределами. То есть что будет рассматриваться как компоненты системы, а что как внешнее воздействие. При определении субъекта моделирования необходимо учитывать ширину и глубину проекта. Ширина – определение границ модели. Что будет рассматриваться внутри, а что снаружи. Глубина – на каком уровне детализации модель является завершенной. Цель разработки определяет области в исследуемой системе на которых необходимо фокусироваться в первую очередь. Например: Если мы построим функциональную модель с целью автоматизации предприятия, такая модель будет сильно отличаться от модели того же предприятия, построенной с целью автоматизации финансовых и материальных потоков. Несмотря на то что различные специалисты будут создавать будущую систему, нужно указать с позиции какого сотрудника мы смотрим на систему. После того как создали контекстную диаграмму и тд. Начинаем детализировать этот блок. В процессе декомпозиции функц блок контекстной диаграммы детализируется на диаграмме второго уровня.
!!!Важно отметить – в случае декомпозиции блока, все дуги должны фиксироваться на дочерней диаграмме. Этим достигается структурная целостность IDEF модели. !!! (Пиздец как важно, кста. Ковтун такую ошибку заметит – уебет)
Блоки на диаграммах располагаются обычно от верхнего левого угла к правому нижнему. Такой порядок называется порядком доминирования. Согласно этому принципу в верхнем левом углу помещается блок, соответствующий самому важному или выполняемому по времени первому процессу. Такое размещение облегчает чтение диаграммы.
Часто бывают случаи когда отдельные дуги не имеет смысла рассматривать в дочерних чет там. Для упрощения чтения предназначен принцип Туннелирования. (дальше объяснения на пушкинских метафорах). В свою очередь такое же обозначение вокруг конца дуги в непосредственной близости от блока приемника означает (то ли -тот факт-, то ли –инфаркт-), что в дочерней диаграмме данная дуга отображаться не будет.
ФИНИТА ЛЯ КОМЕДИА, а нет..
А, да