Файл: итог.doc

Экзаменационный билет № 13

Утверждаю

Проректор по учебной работе

_____________ С.В. Михайлов

" " мая 2014 г.

Кафедра бизнес-информатики

Итоговый междисциплинарный экзамен по специальности «Прикладная информатика в экономике». Специализации «Информационные системы в банковском деле»

1. Каноническое проектирование ИС (ГОСТ 34.601-90).

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

Стадии и этапы создания ИС, выполняемые организациями-участниками, прописываются в договорах и технических заданиях на выполнение работ. Перечень стадий и этапов ЖЦ по ГОСТ 34.601-90, а также комментарии по выполнению работ приведен ниже.

Стадия 1. Формирование требований к ИС

На начальной стадии проектирования выделяют следующие этапы работ:

• обследование объекта и обоснование необходимости создания ИС;

• формирование требований пользователей к ИС;

• оформление отчета о выполненной работе и тактико- технического задания на разработку.

Комментарии:

Oбследование – это изучение и диагностический анализ организационной структуры предприятия, его деятельности и существующей системы обработки информации. Материалы, полученные в результате обследования, используются для:

• обоснования разработки и поэтапного внедрения систем;

• составления технического задания на разработку систем;

• разработки технического и рабочего проектов систем.

• изучение объекта автоматизации;

• проведение необходимых научно-исследовательских работ;

• разработка вариантов концепции ИС, удовлетворяющих требованиям пользователей;

• оформление отчета и утверждение концепции.

Комментарии:

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

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

• получения сравнительных характеристик предполагаемых к использованию аппаратных платформ, операционных систем, СУБД, иного окружения;

• разработки плана работ по обеспечению надежности информационной системы и ее тестирования.

Стадия 3. Техническое задание

• разработка и утверждение технического задания на создание ИС.

Комментарии:

На этапе разработка и утверждение технического задания на создание ИС проводят разработку, оформление, согласование и утверждение технического задания на АС и, при необходимости, технических заданий на части АС.

Техническое задание - это документ, определяющий цели, требования и основные исходные данные, необходимые для разработки автоматизированной системы управления.

В соответствии с ГОСТ 34.601-90 порядок разработки, состав, структура и оформление технического задания регламентируется ГОСТ 34.602-89.

Цель, которая достигается при подготовке правильно составленного технического задания очень проста. Это однозначное распределение сфер ответственности между Заказчиком и Исполнителем. ТЗ – это тот документ, который становиться основой при принятии решения о закрытии проекта и о размере и порядке расчета Заказчика и Исполнителя. Если ТЗ составлено правильно, то стороны могут формально подходить к вопросу сдачи-приемки работ. В противном случае характерна ситуация, когда одна из сторон, как правило этой стороной является Исполнитель, оказывается не в состоянии отстоять свои интересы. Для того, чтобы заявленная цель была реализована и до начала работ по реализации были однозначно определены критерии по которым будет осуществляться приемка ИС, при разработке технического задания необходимо решить следующие задачи (Error: Reference source not found):

• установить общую цель создания ИС, определить состав подсистем и функциональных задач;

• разработать и обосновать требования, предъявляемые к подсистемам;

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

• установить общие требования к проектируемой системе;

• определить перечень задач создания системы и исполнителей;

• определить этапы создания системы и сроки их выполнения;

• провести предварительный расчет затрат на создание системы и определить уровень экономической эффективности ее внедрения.

Стадия 4. Эскизный проект

• разработка предварительных проектных решений по системе и ее частям;

• разработка эскизной документации на ИС и ее части.

Комментарии:

На этапе разработка предварительных проектных решений по системе и ее частям определяются функции АС; функции подсистем, их цели и эффекты; состав комплексов задач и отдельных задач; концепции информационной базы, ее укрупненная структура; функции системы управления базой данных; состав вычислительной системы; функции и параметры основных программных средств

Эскизный проект предусматривает разработку предварительных проектных решений по системе и ее частям. Содержание эскизного проекта задается в ТЗ на систему. Как правило, на этапе эскизного проектирования определяются:

• функции ИС;

• функции подсистем, их цели и ожидаемый эффект от внедрения;

• состав комплексов задач и отдельных задач;

• концепция информационной базы и ее укрупненная структура;

• функции системы управления базой данных;

• состав вычислительной системы и других технических средств;

• функции и параметры основных программных средств.

По результатам проделанной работы оформляется, согласовывается и утверждается документация в объеме, необходимом для описания полной совокупности принятых проектных решений и достаточном для дальнейшего выполнения работ по созданию системы. В соответствии с РД 50.34.698-90 документация стадии эскизного проектирования оформляется по ГОСТ 2.106

Выполнение стадии эскизного проектирования не является строго обязательной. Если основные проектные решения определены ранее или достаточно очевидны для конкретной ИС и объекта автоматизации, то эта стадия может быть исключена из общей последовательности работ.

Если говорить о современной практике проектов комплексной автоматизации, когда речь идет о внедрении типовых систем по типовым схемам, стадия эскизного проектирования практически всегда опускается.

Стадия 5. Технический проект

• разработка проектных решений по системе и ее частям;

• разработка документации на ИС и ее части;

• разработка и оформление документации на поставку комплектующих изделий;

• разработка заданий на проектирование в смежных частях проекта.

Комментарии:

Если техническое задание регламентирует взаимодействие между Заказчиком системы и Исполнителем, то технический проект – это документ определяющий порядок взаимодействия между участниками проекта: проектировщиками и программистами.

На основе технического задания (и эскизного проекта ) разрабатывается технический проект ИС (Error: Reference source not found). Технический проект системы - это техническая документация, содержащая общесистемные проектные решения, алгоритмы решения задач, а также оценку экономической эффективности автоматизированной системы управления и перечень мероприятий по подготовке объекта к внедрению.

Стадия 6. Рабочая документация

• разработка рабочей документации на ИС и ее части;

• разработка и адаптация программ.

Комментарии:

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

Стадия 7. Ввод в действие

• подготовка объекта автоматизации;

• подготовка персонала;

• комплектация ИС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями);

• строительно-монтажные работы;

• пусконаладочные работы;

• проведение предварительных испытаний;

• проведение опытной эксплуатации;

• проведение приемочных испытаний.

2. Сетевое программирование: основные принципы, технологии, особенности реализации в современных языках программирования.

Расширяемый язык разметки (eXtensible Markup Language–XML) предоставляет способ описания структурированных данных. В отличие от HTML-тэгов, которые применяются в основном для управления отображением данных, XML-тэги используются для определения структуры и типов самих данных.

XML — это простой, независимый от платформы и широко принятый стандарт. Преимущество языка XML по сравнению с HTML заключается в том, что он отделяет интерфейс пользователя от структурированных данных.

Перечислим некоторые преимущества XML по сравнению с другими форматами в отношении хранения информации:

• XML-форматы основываются на тексте, что облегчает их чтение, документирование и в некоторых случаях отладку.

• Документы XML могут использовать большую часть инфраструктуры, созданной для HTML, включая протокол http, что позволяет передавать XML через брандмауэр.

• XML-разбор хорошо описан и широко реализован, что делает возможным извлечение информации из документов XML в различных средах.

• XML создан на основе Юникода, что упрощает создание интернациональных документов.

Однако XML подходит не в каждой ситуации.

На платформе .NET язык XML применяется для повышения производительности, совместимости с открытыми стандартами и интеграции с ADO .NET.

Язык XML является форматом устойчивого хранения объекта DataSet, то есть, при сохранении на жестком диске объекта DataSet используется универсальный формат XML, а не двоичный или какой-то другой специализированный формат. Аналогично, при обмене объектами DataSet между разными процессами или компьютерами данные передаются в потоке формата XML.

XML-схемы

XML схема представляет собой документ, который используются для определения и проверки содержимого и структуры данных XML так же, как и схема базы данных — для определения и проверки правильности таблиц, столбцов и типов данных, формирующих базу данных.

XML-схема определяет и описывает отдельные типы данных XML, используя язык определения схем XML (XSD). Элементы XML-схемы (элементы, атрибуты, типы и группы) используются для определения допустимой структуры, допустимого содержимого и отношений данных XML определенных типов.

3. В проект Магазины, созданный на платформе Countur добавить сценарий обновления OLAP-куба, изменить исходный набор данных и продемонстрировать работу сценария. Прокомментировать полученные результаты.

Экзаменационный билет № 14

Утверждаю

Проректор по учебной работе

_____________ С.В. Михайлов

" " мая 2014 г.

Кафедра бизнес-информатики

Итоговый междисциплинарный экзамен по специальности «Прикладная информатика в экономике». Специализации «Информационные системы в банковском деле»

1. Мультипрограммирование в современных операционных системах.

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

В зависимости от выбранного критерия эффективности операционные системы делятся на системы пакетной обработки, системы разделения времени и системы реального времени.

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

Достигается это за счет минимизация простоев всех устройств компьютера и прежде всего центрального процессора.

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

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

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

В системах разделения времени критерий эффективности – повышение удобства работы пользователей, которые могут интерактивно работать одновременно с несколькими приложениями на одной машине.

Для этого каждому приложению попеременно выделяется одинаковый квант времени. Таким образом, пользователи, запустившие программы на выполнение, получают возможность поддерживать с ними диалог. Если квант времени выбран небольшим, то у всех пользователей складывается впечатление, что каждый из них единолично использует машину.

Такие системы обладают меньшей пропускной способностью, чем системы с пакетной обработкой и применяются для многотерминальных или многооконных компьютеров, то есть в большинстве универсальных ОС.

В системах реального времени критерий эффективности – реактивность системы, то есть ее способность выдерживать заранее заданные интервалы времени между запуском программы и получением результата.

В таких системах мультипрограммная смесь представляет собой фиксированный набор заранее разработанных программ, а выбор программы на выполнение осуществляется по прерываниям или в соответствие с расписанием плановых работ.

Операционные системы реального времени применяются в специализированных компьютерах, например, управляющих каким-то технологическим процессом.

2. Задачи кластеризации. Постановка задачи, базовые алгоритмы решения, достоинства и недостатки. Применение задачи кластеризации в банковской сфере.

Кластеризация - Разбиение множества документов к некоторой категории

Методы:

Декомпозиция (разделение, k-клатеризация)

В этих методах изначально каждый объект связан только с одной группой-кластером

Иерархическая кластеризация

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

• Классификация – это отнесение объекта к одному из заранее известных классов (множеств, типов и т.д.)

• Кластеризация – это разделение множества исходных объектов на классы (кластеры), число которых заранее не определено.

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

Постановка задачи кластеризации сложна и неоднозначна, так как:

• оптимальное количество кластеров в общем случае неизвестно;

• выбор меры «похожести» или близости свойств объектов между собой, как и критерия качества кластеризации, часто носит субъективный характер

Цели:

• Изучение данных. Разбиение множества объектов на группы помогает выявить

  • внутренние закономерности, увеличить наглядность представления данных,

  • выдвинуть новые гипотезы, понять, насколько информативны свойства объектов.

• Облегчение анализа.

  • При помощи кластеризации можно упростить дальнейшую

  • обработку данных и построение моделей: каждый кластер обрабатывается индивидуально, и модель создается для каждого кластера в отдельности.

  • В этом смысле кластеризация может рассматриваться как подготовительный этап перед решением других задач Data Mining: классификации, регрессии, ассоциации, последовательных шаблонов.

• Сжатие данных.

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

• Прогнозирование.

  • Кластеры используются не только для компактного представления

имеющихся объектов, но и для распознавания новых. Каждый новый объект относится к тому кластеру, присоединение к которому наилучшим образом удовлетворяет критерию качества кластеризации. Значит, можно прогнозировать поведение объекта, предположив, что оно будет схожим с поведением других объектов кластера.

• Обнаружение аномалий.

  • Кластеризация применяется для выделения нетипичных объектов. Эту задачу также называют обнаружением аномалий (outlier detection).

  • Интерес здесь представляют кластеры (группы), в которые попадает крайне мало, скажем один-три, объектов

Цель кластеризации – построить оптимальное разбиение объектов на группы:

• разбить N объектов на k кластеров;

Алгоритмы:

• Иерархические алгоритмы

• Минимальное покрывающее дерево

• k-Means алгоритм (алгоритм k-средних)

• Метод ближайшего соседа

• Алгоритмы нечеткой кластеризации

• Применение нейронных сетей

• Генетические алгоритмы

• Метод закалки

Применение:

• Анализ данных (Data mining)

  • Упрощение работы с информацией

  • Визуализация данных

• Группировка и распознавание объектов

  • Распознавание образов

  • Группировка объектов

• Извлечение и поиск информации

  • Построение удобных классификаторов

3. Информационная технология разработки оптимального варианта плана проекта в программной среде MS Project на подготовленном примере.

Экзаменационный билет № 15

Утверждаю

Проректор по учебной работе

_____________ С.В. Михайлов

" " мая 2014 г.

Кафедра бизнес-информатики

Итоговый междисциплинарный экзамен по специальности «Прикладная информатика в экономике». Специализации «Информационные системы в банковском деле»

1. Проектирование реляционных баз данных. Теория нормализации.

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

• словесное описание информационных объектов предметной области;

• проектирование инфологической модели предметной области — частично формализованное описание объектов предметной области в терминах некоторой инфологической модели, например в терминах ER (Entity RelationShip)-модели;

• даталогическое или логическое проектирование БД, т. е. описание БД в терминах принятой даталогической модели данных;

• физическое проектирование БД, т. е. выбор эффективного размещения БД на внешних носителях для обеспечения наиболее эффективной работы приложения.

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

Корректной схемой БД называется схема БД, в которой отсутствуют нежелательные функциональные зависимости.

Процесс разработки корректной схемы реляционной БД называется логическим проектированием БД. 

Проектирование схемы БД может быть выполнено двумя путями:

• путем декомпозиции (разбиения), когда исходное множество отношений, входящих в схему БД заменяется другим множеством отношений (число их при этом возрастает), являющихся проекциями исходных отношений;

• путем синтеза, т. е. компоновки из заданных исходных элементарных зависимостей схемы БД. 

В теории реляционных баз данных выделяют 6 нормальных форм, которые имеют специальные названия:

• первая нормальная форма (1NF);

• вторая нормальная форма (2NF);

• третья нормальная форма (3NF);

• нормальная форма Бойса–Кодда (BCNF);

• четвертая нормальная форма (4NF);

• пятая нормальная форма, или форма проекции-соединения (5NF или PJNF).

Функциональной зависимостью набора атрибутов В отношения R от набора атрибутов A того же отношения, обозначаемой как

R.A -> R.B или A -> B,

называется такое соотношение проекций R[A] и R[B], при котором в каждый момент времени любому элементу проекции R[A] соответствует только один элемент проекции R[B], входящий вместе с ним в какой либо кортеж отношения R. Функциональная зависимость R.A -> R.B называется полной, если набор атрибутов B функционально зависит от A и не зависит функционально от любого подмножества A, т. е. R.A -> R.B называется полной, если  , что читается следующим образом: для любого A1, являющегося подмножеством А, R.B функционально не зависит от R.A1, в противном случае зависимость R.A -> R.B называется неполной.

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

Соответственно ненормализованные отношения, могут интерпретироваться как таблицы с неравномерным заполнением, например таблица «Расписание», которая имеет следующий вид:

                                                                                                       Расписание

Для приведения отношения «Расписание» к 1-й нормальной форме необходимо дополнить каждую строку фамилией преподавателя.

                                                                                                       Расписание

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

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

R<ФИО, Номер зач.кн., Группа, Дисциплина, оценка>

Первичным ключом отношения является набор из двух атрибутов <Номер зачетной книжки, Дисциплина>. Однако если мы проанализируем функциональные зависимости, то увидим, что такие атрибуты, как «ФИО», «Группа» зависят только от части первичного ключа, а именно от атрибута «Номер зач. кн.». И в этом случае мы имеем неполные функциональные зависимости

Номер зач. кн.-> Группа

Номер зач. кн.->ФИО

И в этом случае для приведения ко 2-й нормальной форме надо разбить исходное отношение на 2 со следующими схемами:

R1<ФИО,Номер.зач.кн.,Группа>

R2<Номер зач.кн.,Дисциплина,Оценка>

3. Отношение находится в 3-й нормальной форме тогда и только тогда, когда оно находится во 2-й нормальной форме и не содержит транзитивных зависимостей.

Рассмотрим отношение, соответствующее описанию студента в некотором вузе.

R<ФИО,Номер.зач.кн.,Группа,Факультет,Специальность,Выпускающая кафедра>.

Первичным ключом отношения является номер зачетной книжки, поэтому резонно предположить, что существуют следующие функциональные зависимости:

Номер.зач.кн. -> ФИО

Номер.зач.кн. -> Группа

Номер.зач.кн. -> Факультет

Номер.зач.кн. -> Специальность

Номер.зач.кн. -> Выпускающая кафедра

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

Группа -> Факультет

Группа -> Специальность

Группа -> Выпускающая кафедра

Выпускающая кафедра -> Факультет

И эти зависимости образуют транзитивные группы зависимостей. Чтобы избежать этого, мы можем предложить следующий набор отношений:

R1<Номер.зач.кн.,ФИО,Специальность,Группа>

R2<Группа,Выпускающая кафедра)>

R3(Выпускащая кафедра,Факультет)

4. Отношение находится в нормальной форме Бойса–Кодда, если оно находится в 3-й нормальной форме и каждый детерминант отношения является возможным ключом отношения.

Отношение, которое моделирует сдачу текущей сессии имеет следующую структуру:

<ФИО, Номер зач.кн., Идентификатор студента, Дисциплина, Дата, Оценка>

Если считать, что «Номер зач. кн.» и «Идентификатор студента» однозначно характеризуют его, то мы имеем два возможных ключа:

Идентификатор студента, Дисциплина

Номер зач.кн., Дисциплина

Кроме того, у нас существует 2 тривиальные функциональные зависимости:

Номер зач.кн.-> ФИО

Идентификатор-> ФИО

Значит это отношение находится в 3-й нормальной форме, но не находится в форме Бойса–Кодда. Для того, чтобы привести это отношение к нормальной форме Бойса–Кодда необходимо провести его декомпозицию следующим образом:

R1<Номер зач.кн.,ФИО>

R2<Идентификатор, Номер зач.кн.>

R3<Идентификатор, Дисциплина, Дата, Оценка>

Нормальные формы высших порядков связаны с наличием многозначных зависимостей. Многозначные зависимости, обозначаемые как A->>B, — это устойчивые соотношения между значениями атрибутов A и B, когда одному значению атрибута A соответствует некоторое устойчивое множество значений атрибута B. 

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

Имеем отношение «Планирование занятий»

В этом отношении 2 многозначных функциональных зависимости:

Группа ->> Предмет

Предмет->> Номер лабораторной работы.

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

Теперь в каждом отношении у нас присутствует только одна многозначная зависимость, поэтому можно утверждать, что отношение находится в 4-й нормальной форме.

Декомпозиция отношения R на проекции R1=R[X,Y] и R2=R[X,Z] будет декомпозицией без потерь тогда и только тогда, когда имеется многозначная зависимость X->>Y|Z.

5. Отношение R находится в 4-й нормальной форме тогда и только тогда, когда отношение находится в нормальной форме Бойса–Кодда и не содержит нетривиальных многозначных зависимостей.

Функциональные и многозначные зависимости позволяют произвести декомпозицию исходного отношения без потерь на две проекции. Можно, однако, привести примеры отношений, которые нельзя декомпозировать без потерь ни на какие две проекции. Рассмотрим следующее отношение R.

Как легко заметить, отношение R не восстанавливается ни по одному из попарных соединений R₁JOIN R₂, R₁JOIN R₃ или R₂JOIN R₃. Действительно, соединение R₁JOIN R₂ имеет следующий вид.

Можно предположить, что отношение R удовлетворяет следующей зависимости соединения: *(XY,XZ,YZ).

6. Отношение R не находится в 5-й нормальной форме, если в отношении найдется нетривиальная зависимость соединения.

Отношение R находится в 5-й нормальной форме тогда и только тогда, когда любая имеющаяся зависимость соединения является тривиальной.

В нашем случае набор из трех проекций и соответствует 5-й нормальной форме отношения R.

2. Нотация DFD. Виды нотаций DFD. Синтаксис DFD.

ОПР.: В DFD (Data Flow Diagram), модель системы определяется как иерархия диаграмм потоков данных, описывающих процессы преобразования информации от момента ее ввода в систему до выдачи конечному пользователю. Диаграммы верхних уровней иерархии - контекстные диаграммы, задают границы модели, определяя её окружение (внешние входы и выходы) и основные рассматриваемые процессы. Контекстные диаграммы детализируются при помощи диаграмм следующих уровней.

Первым шагом при построении иерархии DFD, также как и в SADT является построение контекстных диаграмм. Обычно при проектировании относительно простых ИС строится единственная контекстная диаграмма со звездообразной топологией, в центре которой находится так называемый главный процесс, соединенный с приемниками и источниками информации, посредством которых с системой взаимодействуют пользователи и другие внешние системы.

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

• наличие большого количества внешних сущностей (десять и более);

• распределенная природа системы;

• многофункциональность системы с уже сложившейся или выявленной группировкой функций в отдельные подсистемы.

Для сложных ИС строится иерархия контекстных диаграмм. При этом контекстная диаграмма верхнего уровня содержит не единственный главный процесс, а набор подсистем, соединенных потоками данных. Контекстные диаграммы следующего уровня детализируют контекст и структуру подсистем.

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

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

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

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

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

Миниспецификация является конечной вершиной иерархии DFD. Решение о завершении детализации процесса и использовании миниспецификации принимается аналитиком исходя из следующих критериев:

• наличия у процесса относительно небольшого количества входных и выходных потоков данных (2-3 потока);

• возможности описания преобразования данных процессом в виде последовательного алгоритма;

• выполнения процессом единственной логической функции преобразования входной информации в выходную;

• возможности описания логики процесса при помощи миниспецификации небольшого объема (не более 20-30 строк).

Синтаксис DFD включает четыре основных элемента:

• поток данных;

• процесс;

• хранилище;

• внешняя сущность.

Рассмотрим эти элементы подробнее.

Поток данных

ОПР.: Поток данных соединяет выход объекта (или процесса) с входом другого объекта (или процесса). Он представляет промежуточные данные вычислений. Поток данных изображается в виде стрелки между производителем и потребителем данных, помеченной именами соответствующих данных. Упрощенно можно считать, что потоки данных являются механизмами, использующимися для моделирования передачи информации (или физических компонент) из одной части системы в другую.

Потоки на диаграммах изображаются стрелками (обычно именованными), ориентация которых указывает направление движения информации (Error: Reference source not found).

ОПР.: Процесс преобразует значения данных.

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

Назначение процесса состоит в продуцировании выходных потоков из входных в соответствии с действием, задаваемым именем процесса. Это имя должно содержать глагол в неопределенной форме с последующим дополнением (например, «выдать пропуск»). Кроме того, каждый процесс должен иметь уникальный номер для ссылок на него внутри диаграммы. Этот номер может использоваться совместно с номером диаграммы для получения уникального индекса процесса во всей модели.

ОПР. 1: Накопители данных предназначены для изображения неких абстрактных устройств для хранения информации, которую можно туда в любой момент времени поместить или извлечь, безотносительно к их конкретной физической реализации. Накопители данных являются неким прообразом базы данных информационной системы организации.

ОПР. 2: ХРАНИЛИЩЕ (НАКОПИТЕЛЬ) ДАННЫХ позволяет на определенных участках определять данные, которые будут сохраняться в памяти между процессами. Фактически хранилище представляет "срезы" потоков данных во времени. Информация, которую оно содержит, может использоваться в любое время после ее определения, при этом данные могут выбираться в любом порядке. Имя хранилища должно идентифицировать его содержимое и быть существительным. В случае, когда поток данных входит или выходит в/из хранилища, и его структура соответствует структуре хранилища, он должен иметь то же самое имя, которое нет необходимости отражать на диаграмме.

ОПР. 1: ВНЕШНЯЯ СУЩНОСТЬ (или ТЕРМИНАТОР) представляет сущность вне контекста системы, являющуюся источником или приемником системных данных. Ее имя должно содержать существительное. Предполагается, что объекты, представленные такими узлами, не должны участвовать ни в какой обработке.

ОПР. 2: Под внешней сущностью (External Entity) понимается материальный объект, являющийся источником или приемником информации.

В качестве внешней сущности на DFD диаграмме могут выступать заказчики, поставщики, клиенты, склад, банк и другие.

3. На томе NTFS создать папку anonym, в которую все пользователи могут положить файл, но не могут ее просматривать, полный доступ к папке имеет только пользователь boss. Продемонстрировать на рабочей станции.

Создать 2х пользователей (панель управления- администрирование- пользователи на локальном компьютере ). Добавить пользователя boss и добавить его в администраторы. На рабочей станции нужно создать на диске С папку. И зайти в свойства папки. И там во вкладке безопасность. Для пользователей установить галочку только ЗАПИСь. Если этого сделать нельзя. То нужно нажать на кнопку дополнительно. И там внизу поставлена галочка. Её нужно убрать.

Далее зайти под двумя этими пользователями и проверить.