Файл: 15.docx

Экзаменационный билет № 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 и добавить его в администраторы. На рабочей станции нужно создать на диске С папку. И зайти в свойства папки. И там во вкладке безопасность. Для пользователей установить галочку только ЗАПИСь. Если этого сделать нельзя. То нужно нажать на кнопку дополнительно. И там внизу поставлена галочка. Её нужно убрать.

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