77. Каноническое проектирование ис и особенности его содержания.

Каноническое проектирование отражает особенности руч­ной технологии индивидуального (оригинального) проектирова­ния, осуществляемого на уровне исполнителей без использова­ния каких-либо средств автоматизации. Как правило, каноническое проектирование применяется для небольших ло­кальных ИС.

В основе канонического проектирования лежит каскадная модель жизненного цикла ИС. Каноническое проектирование делится на четыре стадии в соответствии с жизненным циклом ИС:

1) Предпроектная стадия. Основное назначение заключается в обосновании экономической целесообразно­сти создания ИС и формулировании требований к ней.

Этапы:

- сбор материалов обследования (проектировщики получают материалы обследования, которые должны содержать полную и достоверную информацию с описание предметной области);

- анализ материалов обследования, разработка технико-экономического обосно­вания (ТЭО) и технического задания (ТЗ) (на данном этапе проектировщики получают количественные и качественные характеристики информационных потоков, описание их структуру и места обработки, описание объемов выполняемых операций, их трудоемкость).

На основе всех материалов формируются 2 документа:

1. ТЭО – содержит расчеты и обоснование необходимости разработки ИС.

2. ТЗ – содержит требования к создаваемой системе и ее отдельным компонентам.

- Третий этап (необязательный) – создание эскизного проекта. Необходим для сложных ИС. На основании сформированных ранее требований разработать предварительные решения по ИС в целом и по отдельным ее обеспечениям.

2) Стадия проектирования. Этапы:

1.Техническое проектирование. На данном этапе выполняются работы по логической разработке проекта и выбору наилучших вариантов проектных решений. В результате данного этапа получаем документ – технический проект.

2.Рабочее проектирование. Происходит физическая реализация всех предложенных решений. На выходе получаем рабочий проект – это разработанная готовая ИС + вся необходимая документация.

После завершения этой стадии формируется документ – Технический проект (ТП). Это техническая документация, содержащая общесистемные проектные решения, и алгоритмы решения отдельных задач

3) Стадия внедрения. Этапы:

1.Подготовка объекта к внедрению. На данном этапе осуществляется комплекс работ по подготовке предприятия к внедрению разработанной ИС.

2.Опытное внедрение. Проверяется работоспособность системы обычно на реальных данных. Промежуточный документ – акты опытного внедрения.

3.Сдача в промышленную эксплуатацию. На выходе финальный акт о сдаче в промышленную эксплуатацию.

Итог: доработанный техно-рабочий проект и акт сдачи-приемки.

Сам процесс внедрения может осуществляться с использованием следующих методов:

- последовательный (последовательно внедряется одна подсистема за другой). Плюсы – улучшенный контроль ошибок. Минусы – время внедрения сильно увеличивается => увеличивается стоимость проекта.

- параллельный (все подсистемы внедряются сразу). Плюсы: уменьшение времени внедрения. Минусы: контроль ошибок ухудшится.

-смешанный (последовательно-параллельный) в начале несколько подсистем внедряются последовательно, потом, накопив опыт, остальные внедряются параллельно.

4) Стадия эксплуатации и сопровождения.

Этапы (выполняются одновременно):

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

2. Сопровождение ИС (выполняются следующие работы: ликвидация последствий сбоев в работе системы, исправление ошибок, которые не были выявлены)

3. Модернизация ИС (проект дорабатывается; доработка может происходить как по составу функциональной архитектуры, так и по системной).

Дисциплина «Базы данных»

78. Инфологическое проектирование базы данных. Модель «сущность-связь». Графовая форма представления схемы базы данных.

Инфологическая модель применяется на втором этапе проектирования БД (алгоритмическом), то есть после словесного описания предметной области, то есть после этапа постановки задачи.

Следовательно, инфологическая модель должна включать такое формализованное описание предметной области, которое будет «читабельно» не только для специалистов по базам данных, но и сторонних людей. И это описание должно быть настолько емким, чтобы можно было оценить глубину и корректность проработки проекта БД, и конечно, как говорилось раньше, оно не должно быть привязано к конкретной СУБД. Выбор СУБД — это отдельная задача, для корректного ее решения необходимо иметь проект, который не привязан ни к какой конкретной СУБД.

Инфологическое проектирование прежде всего связано с попыткой представления семантики, то есть смыслового содержания, предметной области в модели БД. Реляционная модель данных в силу своей простоты и лаконичности не позволяет отобразить семантику, то есть смысл предметной области оставется за рамками реляционной модели. Ранние теоретико-графовые модели в большей степени, чем реляционная модель, отображали семантику предметной области. Они в явном виде определяли иерархические связи между объектами предметной области.

"Модель Сущность-Связь Модель «СС»  – это неформальная модель предметной области, которая используется на этапе инфологического проектирования БД. Эта модель позволяет отразить объекты предметной области и взаимоотношения объектов. Модель может быть использована для общения с будущими пользователями, для сбора информации о предметной области, для проектирования БД. Основное назначение неформальной модели «СС» – семантическое описание предметной области и представление информации для обоснования выбора видов модели и структур данных, которые будут использоваться в системе. Существует несколько подходов к построению модели «СС». Общим для всех подходов является использование 3-х конструктивных элементов: сущность, атрибут, связь. Составляющая «время» в явном виде отсутствует, но ее можно отразить с помощью атрибутов (напр. «дата рождения»).

Сущность – собирательное понятие, некоторая абстракция реально существующего объекта, процесса, явления о кот. необходимо хранить информацию в системе. В моделях предметной области «СС» каждая сущность является узловой точкой сбора информации. Различают 2 понятия: тип сущности, экземпляр сущности. Тип сущности определяет набор однородных объектов. За типом скрываются экземпляры сущности, т.е. конкретные объекты в наборе. Каждый рассматриваемый тип сущности поименован. Для идентификации конкретных экземпляров сущностей используются специальные атрибуты – идентификаторы. Это может быть один или несколько атрибутов.

Атрибут – поименованная характеристика сущности, которая принимает значение из некоторого множества значений (домена). В модели атрибут выступает в качестве средства, с помощью которого моделируются свойства сущностей. Чтобы задать атрибут, необходимо: - присвоить ему наименование; - привести смысловое описание; - определить множество возможных значений; - указать, для чего он используется. Для идентификации экземпляров сущности используются т.н. ключевые атрибуты, которые на схеме подчеркиваются. Иногда атрибуты показывают характер связи (напр., родство - отец).

Связи выступают в модели в качестве средства, с помощью которого представляются отношения между сущностями, имеющими место в предметной области. («отношение» - математич. термин). Различают типы связей и экземпляры связей. На рисунках типы связей обозначаются ромбами, ромб соединяется с соответствующими сущностями дугами. Экземпляр связи будет характеризовать конкретную связь между конкретными экземплярами сущностей.

Различают бинарные связи, тернарные связи (3 сущности), в общем случае n-арные связи. Чаще всего встречаются бинарные связи. В используемой нотации для бинарных связей необходимо на схемах выставлять стрелки на концах дуг и указывать коэффициенты, характеризующие отношение, а для многомерных связей стрелки и коэффициенты не ставятся. Типы бинарных связей: 1:1; 1:M; M:1; M:N. Связи могут иметь свой атрибут. Тогда связь выполняет как бы функцию сущности, т.е. тип отношения рассматривается как тип сущности. Напр.: возьмем отношение ДЕТАЛЬ_Х_РАЗМЕЩЕ-НА_НА_СКЛАДЕ_Y, оно же может рассматриваться как тип сущности, о которой мы хотим хранить к.-л. информацию (количество деталей на складе).

Информацию о проекте следует оформлять составлением спецификаций по сущностям, атрибутам и отношениям (связям) с использованием графических диаграмм. При этом используют следующие обозначения: сущности – прямоугольниками; атрибуты – овалами, при этом соединяют их с соответствующими сущностями ненаправленными дугами,  идентифицирующие атрибуты подчеркиваются; связи – ромбами, при этом соединяют их соответствующими типами сущностей ненаправленными ребрами за исключением бинарных связей, которые представляются направленными ребрами.

Правила при моделировании:

1. Используются только 3 типа конструктивных элементов (сущность, атрибут, связь);

2. В отдельном проектном представлении каждый элемент проекта моделируется только одним конструктивным элементом.

При моделировании предметной области проектировщик:

- разбивает ее на ряд локальных областей;

- моделирует каждое локальное представление (по 6-7 сущностей);

- объединяет локальные представления.

 

Графовая форма представления схемы БД

 

Структура данных может быть описана: 1. В виде исходного текста на ЯОД; 2. В графовой форме; 3. В табличной форме.

При графовой форме агрегаты атрибутов изображаются вершинами графа, а связи между ними соответствуют дугам. Если вернуться к модели «СС», в вершинах – сущности, по КОДАСИЛ – группы. Соглашения:

1. тип записи (группы) изображается прямоугольником, над верх. лев. углом кот. ставится название. Внутри прямоугольника могут быть имена элементов данных, агрегированных в группу;

2. набор (групповое отношение) обозначается стрелками от группы-владельца к группе-члену набора с указанием имени отношения и коэффициента;

3. конкретный экземпляр типа записи (группы) может быть идентифицирован в БД с помощью первичного ключа (не избыточной совокупности элементов данных). Эта последовательность элементов подчеркивается.

  

79. Реляционная, иерархическая и сетевая модели представления данных. Датологическое проектирование базы данных.

Иерархическая–первая из реализованных в СУБД моделей данных, представляет собой связный граф типа дерева, вершины которого расположены на разных иеpаpхических уровнях. Уровень вершины - расстояние до коня. Структурная диаграмма иерархической БД представляет собой упорядоченное дерево в котором определено относительное расположение вершин и дуги, соответствующие функциональным связям, всегда направлены от корня к листья дерева. Корень - вершина в которую не входит ни одна дуга. Поиск информации производится сверху-вниз. Обратный поиск затруднен или вообще не возможен.  Сетевая модель данных: - появилась как развитие иерархической. В сетевой в модели данные представляются с помощью записей и связей. Связи используются для представления типов связей между записями. Связи должны быть функциональными. Запись этой модели в отличие от иерархической может иметь множество как подчиненных ей записей, так и записей которым она подчинена. Запись, от которой идет дуга, называется запись-владелец, а к которой идет дуга запись-член. Сегодня наиболее распространенными являются СУБД, основанные на реляционной модели данных. Реляционные системы далеко не сразу полу. В реляционной базе данные организованы в виде таблиц. Основные свойства: отсутствуют одинаковые строки, порядок строк не существенен, порядок столбцов не существенен, все значения нельзя разбить без потери информации. Примерами реляционных БД могут быть: FoxPro, Clipper, Access и пр.

Иерархическая и сетевая модели данных стали применяться в системах управления базами данных в начале 60-х годов. В начале 70-х годов была предложена реляционная модель данных. Эти три модели различаются в основном способами представления взаимосвязей между объектами.

Рис.2.3 Схема иерархической модели данных.

Недостатки: из нижних уровней иерархии нельзя направить информационный поиск по вышележащим узлам.  Иерархическая модель

Иерархическая модель данных строится по принципу иерархии типов объектов, то есть один тип объекта является главным, а остальные, находящиеся на низших уровнях иерархии, - подчиненными (рис. 2.3). Между главным и подчиненными объектами устанавливается взаимосвязь «один ко многим». 

Сетевая модель

В сетевой модели данных понятия главного и подчиненных объектов несколько расширены. Любой объект может быть и главным и подчиненным (в сетевой модели главный объект  обозначается термином «владелец набора», а подчиненный - термином «член набора»). Один и  тот же объект может одновременно выступать и в роли владельца, и в роли члена набора. Это означает, что каждый объект может участвовать в любом числе взаимосвязей. Схема сетевой модели приведена на рис. 2.4.  Рис.2.4. Схема сетевой модели данных.   Реляционная модель

В реляционной модели данных (ввел в 1970 г. Э. Ф. Кодд.) объекты и взаимосвязи между ними представляются с помощью таблиц, как это показано на рис. 2.5.

Рис.2.5. Схема иерархической модели данных

Взаимосвязи также рассматриваются в качестве объектов. Каждая таблица  представляет один объект и состоит из строк и столбцов. В реляционной базе данных каждая таблица должна иметь первичный ключ (ключевой элемент) - поле или комбинацию полей, которые единственным образом идентифицируют каждую строку в таблице. Благодаря своей простоте и естественности представления реляционная модель получила наибольшее распространение в СУБД  для персональных компьютеров.

Признаки, позволяющие считать таблицу отношением

·В таблице нет строк с совпадающими ключами (строки уникальны).

·В каждой строке содержатся значения одного и того же набора атрибутов.

·Отношения неразложимы (не могут быть элементами другого отношения).

Достоинства реляционных моделей данных.

• ·Упрощение схемы данных для пользователя.

• ·Улучшение логической и физической независимости.

• ·Оптимизация доступа к БД.

• ·Улучшение целостности и защиты данных.

• ·Возможности различных применений.

• ·Обеспечение методологического подхода.

Недостатком реляционной модели данных является избыточность по полям (из-за создания связей).

80. Понятие СУБД. Назначение и архитектура.

Системы управления базами данных (СУБД) используются для упорядоченного хранения и обработки больших объемов информации. В процессе упорядочения информации СУБД генерируют базы данных, а в процессе обработки сортируют информацию и осуществляют ее поиск.

Информация в базах данных структурирована на отдельные записи, которыми называют группу связанных между собой элементов данных. Характер связи между записями определяет два основных типа организации баз данных: иерархический и реляционный.

В иерархической базе данных записи упорядочиваются в определенную последовательность, как ступеньки лестницы, и поиск данных может осуществляться последовательным «спуском» со ступени на ступень. Иерархическая база данных по своей структуре соответствует структуре иерархической файловой системы.

Реляционная база данных, по сути, представляет собой двумерную таблицу. Под записью здесь понимается строка двумерной таблицы, элементы которой образуют столбцы таблицы. В зависимости от типа данных столбцы могут быть числовые, текстовые или содержать дату. Строки таблицы нумеруются.

Работа с СУБД начинается с создания структуры базы данных, т. е. с определения:

• количества столбцов;

• названий столбцов;

• типов столбцов (текст/число/дата);

• ширины столбцов.

В созданную «пустую» базу данных необходимо занести записи и при необходимости их редактировать. Обычно предусмотрены следующие режимы:

• добавление записи;

• удаление записи; • редактирование записи.

Занесенную в базу данных информацию можно обрабатывать, а именно — осуществлять следующие операции:

• сортировка по любому столбцу (по возрастанию/ убыванию чисел, символьных строк, дат);

• поиск по любому столбцу с различными условиями (равно, больше, меньше и т. д.).

Дисциплина «Информационная безопасность»