Секция управления.

Команды выбираются из ОП блоками и заносятся в буфера команд.

5. Параллельное выполнение программ.

Все основные операции, выполняемые процессором - обращение в память, обработка команд и выполнение инструкций - являются конвейерными.

II. Массивно-параллельные компьютеры с распределенной памятью. Объединяется несколько серийных микропроцессоров, каждый со своей локальной памятью, посредством некоторой коммуникационной среды.

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

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

Но эта архитектура имеет 2 существенных недостатка:

• требуется быстродействующее коммуникационное оборудование, обеспечивающее среду передачи сообщений;

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

Последнее обстоятельство и мешает широкому внедрению подобных архитектур.

К данному классу можно отнести компьютеры Intel Paragon, IBM SP1, Parsytec, IBM SP2 и CRAY T3D.

Компьютеры Cray T3D и T3E используют единое адресное пространство (общая виртуальная память). По аппаратному прерыванию особого случая адресации ОС выполняет пересылку страницы с одного узла на другой. У каждого МП своя локальная память, но единое виртуальное адресное пространство.

Рис. 11.1.  Структура супер-ЭВМ Cray T3D

Факторы, снижающие производительность параллельных компьютеров:

1. Закон Амдала.

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

Таблица 11.1.
Число ПЭ	Доля последовательных вычислений
	50%	25%	10%	5%	2%
2	1,33	1,60	1,82	1,90	1,96
8	1,78	2,91	4,71	5,93	7,02
32	1,94	3,66	7,80	12,55	19,75
512	1,99	3,97	9,83	19,28	45,63
2048	2,00	3,99	9,96	19,82	48,83

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

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

3. Возможность асинхронной посылки сообщений и вычислений.

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

4. Неравномерная загрузка всех процессорных элементов.

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

5. Время ожидания прихода сообщения.

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

6. Реальная производительность одного процессора.

III. Параллельные компьютеры с общей памятью (SMP). Вся оперативная память разделяется между несколькими одинаковыми процессорами. Это снимает проблемы предыдущего класса, но добавляет новые - число процессоров, имеющих доступ к общей памяти, нельзя сделать большим. В данное направление входят многие современные многопроцессорные SMP-компьютеры или, например, отдельные узлы компьютеров HP Exemplar и Sun StarFire.

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

IV. Кластерная архитектура. По такому принципу построены CRAY SV1, HP Exemplar, Sun StarFire, NEC SX-5, последние модели IBM SP2 и другие.

Кластерная архитектура представляет собой комбинации предыдущих трех. Из нескольких процессоров (традиционных или векторно-конвейерных) и общей для них памяти формируется вычислительный узел. Если полученной вычислительной мощности не достаточно, то объединяется несколько узлов высокоскоростными каналами. Часто создаются из общедоступных компьютеров на базе Intel и недорогих Ethernet-сетей под управлением операционной системы Linux.

Технологии параллельного программирования

Средства программирования: параллельные расширения и диалекты языков - Fortran, C/C++, ADA и др.

Самым крупным достижением в деле создания программного обеспечения была стандартизация интерфейса передачи сообщений MPI (Message Passing Interface). Набор функций этого интерфейса вобрал в себя лучшие черты своих предшественников. Основные достоинства MPI:

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

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

• передача типизированных сообщений;

• построение библиотек - MPICH, LAM MPI;

• наличие вариантов для языков программирования C/C++, Fortran;

• поддерживает коллективные операции: широковещательную передачу, разборку/сборку, операции редукции;

• совместимость с многопоточностью.

Оценки производительности супер-ЭВМ

Большинство оценочных характеристик производительности супер-ЭВМ связано с вычислениями над вещественными числами. К ним относится пиковая производительность (ПП), измеряемая в млн. операций с плавающей точкой, которые компьютер теоретически может выполнить за 1 с (MFLOPS).

ПП - величина, практически не достижимая. Это связано с проблемами заполнения функциональных конвейерных устройств. Чем больше конвейер, тем больше надо "инициализационного" времени для того, чтобы его заполнить. Такие конвейеры эффективны при работе с длинными векторами. Поэтому для оценки векторных супер-ЭВМ было введено такое понятие, как длина полупроизводительности - длина вектора, при которой достигается половина пиковой производительности.

Более реальные оценки производительности базируются на временах выполнения различных тестов. Самыми хорошими тестами являются реальные задачи пользователя. Однако такие оценки, во-первых, весьма специфичны, а во-вторых, часто вообще недоступны или отсутствуют. Поэтому обычно применяются более универсальные тесты.

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

Наиболее популярным тестом производительности является Linpack, который представляет собой решение системы N линейных уравнений методом Гаусса. Так как известно, сколько операций с вещественными числами нужно проделать для решения системы, то, зная время расчета, можно вычислить выполняемое в секунду количество операций.

Имеется несколько модификаций этих тестов. Обычно фирмы-производители компьютеров приводят результаты при N = 100.

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

Другой стандартный тест относится к случаю N = 1000, предполагающему использование длинных векторов. Эти тесты могут выполняться на компьютерах при разном числе процессоров, давая также оценки качества распараллеливания.

Для MPP-систем более интересным является тест Linpack-parallel, в котором производительность измеряется при больших N и большом количестве процессоров. Здесь лидером является 6768-процессорный Intel Paragon (281 GFLOPS при N = 128600). Что касается производительности процессоров, то при N = 100 лидирует Cray T916 (522 MFLOPS), при N = 1000 и по пиковой производительности - Hitachi S3800 (соответственно 6431 и 8000 MFLOPS). Для сравнения, процессор в AlphaServer 8400 имеет 140 MFLOPS при N =100 и 411 MFLOPS при N = 1000.

Для высокопараллельных суперкомпьютеров в последнее время все больше используются тесты NAS parallel benchmark, которые особенно хороши для задач вычислительной газо- и гидродинамики. Их недостатком является фиксация алгоритма решения, а не текста программы.

14 ноября 2005 года была опубликована 26-я редакция списка 500 наиболее мощных компьютеров мира Top500.

На первом месте в 26-й редакции списка остался прототип будущего суперкомпьютера IBM BlueGene/L, число процессоров которого увеличилось до 131072, а производительность на Linpack - до 280.6 Tflop/s.

На втором месте осталась другая инсталляция суперкомпьютера IBM BlueGene/L, установленная в Thomas J. Watson Research Center, на основе 40960 процессоров с производительностью на Linpack 91.29 Tflop/s.

На третье место в новой редакции списка вышел суперкомпьютер ASC Purple производства IBM на основе 10240 процессоров p5 575 1.9 ГГц с производительностью на Linpack 63.39 Tflop/s.

На 5-ом месте оказался суперкомпьютер Thunderbird производства Dell на основе 8000 процессоров PowerEdge 1850 3.6 ГГц с производительностью на Linpack 38.27 Tflop/s. На 6-ом месте - суперкомпьютер Red Storm производства Cray на основе технологии XT3 с производительностью на Linpack 36.19 Tflop/s.

Суперкомпьютер Earth Simulator, долгое время возглавлявший список, оказался в новой редакции уже на 7-м месте.

Суперкомпьютер Earth Simulator предназначен для моделирования климатических изменений на основе данных, которые поступают со спутников. Система базируется на 5120 таких процессорах, объединенных в 640 узлов SX-6 (по 8 процессоров в каждом). Суперкомпьютер работает под управлением ОС SUPER-UX. В числе средств разработки установлены компиляторы языков C/C++, Fortran 90 и HPF, а также средства автоматической векторизации, реализация интерфейса MPI-2 и математическая библиотека ASL/ES. Вся машина занимает площадь трех теннисных кортов (50x65 м) и использует несколько километров кабеля.

На 10-м месте в списке оказался суперкомпьютер Jaguar, построенный по технологии Cray XT3 с производительностью на Linpack 20.527 Tflop/s.

Полгода назад для попадания в первую десятку списка требовалась производительность 15.25 Tflop/s. Суммарная производительность систем в списке выросла за полгода с 1.69 Pflop/s до 2.30 PFlop/s.

Общее число кластеров в списке еще увеличилось и составляет уже 360 систем (по сравнению с 304 в июне), таким образом, кластерная архитектура остается наиболее популярной при проектировании мощнейшихсуперкомпьютеров. В качестве коммуникационной технологии 249 кластеров используется Gigabit Ethernet, в 70 случаях - Myrinet.

По количеству установленных систем, вошедших в список, IBM (219) продолжает доминировать, на втором месте по-прежнему Hewlett-Packard (169).

С 56-го на 69-е место в новой редакции списка опустился российский суперкомпьютер MVS-15000BM производства IBM, установленный в Межведомственном суперкомпьютерном центре РАН и построенный на основе 924 процессоров PowerPC970 2.2 ГГц, объединенных коммуникационной сетью Myrinet, с производительностью на тесте Linpack 5.355 Tflop/s.

С 174-го на 330-е место в новой редакции списка опустился белорусский суперкомпьютер SKIF K-1000, построенный на основе 576 процессоров AMD Opteron 2.2 ГГц и коммуникационной технологии Infiniband, с производительностью на Linpack 2.032 Tflop/s.

9.2 Основні характеристики паралельних алгоритмів: ступінь паралелізму, прискорення, ефективність. Закон Амдала.

Определение 5. Ускорением параллельного алгоритма называется отношение:

.

Для задачи сложения векторов следовало бы ожидать, что , т.е. ускорение максимально. Заметим, однако, что в оп­ределении  подразумеваются действительные времена вы­числений. Это делает определение более реалистичным, но за­трудняет его использование в том случае, если требуемые вре­мена неизвестны. Рассмотрим сложение n чисел с помощью алгоритма сдваивания в системе из n/2 процессоров с локальной памятью. Пусть а1 и а2 хранятся в памяти процессора 1, a3 и а4 – в памяти процессора 2 и т. д. Прежде, чем можно будет выполнять сложения второго этапа, необходимо передать число а3+a4 процессору 1, число а7+a8 – процессору 3 и т.д. Аналогичные переносы данных требуются на каждом этапе, что, конечно, увеличивает общее время выполнения алгоритма. Предположим, что для одного сложения нужно время t, а для переноса одного числа - время at; обычно a больше единицы. Игнорируя прочие издержки, имеем для алгоритма сложения (с учетом равенства р=n/2)

.

Заметим, что в данном случае ускорение есть средняя степень параллелизма, деленная на 1+a. Если a - величина, близкая к единице, т.е. на обмены затрачивается примерно столько же времени, сколько на арифметику, то ускорение уменьшится приблизительно вдвое по сравнению с идеальной ситуацией, когда a=0. С другой стороны, если a велико, скажем, a=10, то время на обмены доминирует над временем вычислений; соответственно падает ускорение. Ускорение позволяет сравнивать поведение данного алгоритма для одного и p процессоров.

С ускорением связана эффективность параллельного алгоритма.

Определение 6. Эффективностью параллельного алгорит­ма называется величина: .

Поскольку . Если алгоритм достигает максимального ускорения ( ), то .

Определение 3. Степенью параллелизма численного алгоритма называется число его операций, которые можно вы­полнять параллельно.

Проиллюстрируем это определение несколькими примерами и по ходу дела уточним его. Начнем с задачи сложения двух векторов а и b. Сложения независимы и могут выполняться параллельно. Таким образом, степень параллелизма этого алгоритма равна n. Отметим, что понятие степени параллелизма не связано с числом процессоров нашей системы, оно является характеристикой параллелизма, внутренне присущего алгоритму. Разумеется, от числа процес­соров зависит время, необходимое для завершения вычислений. Например, если n= 1000 и число процессоров p также равно 1000, то все суммы условно можно вычислить за один временной шаг, однако при p = 10 потребуется 100 временных шагов.

Рассмотрим теперь задачу сложения n чисел . Обычный последовательный алгоритм: – непригоден для параллельных вычислений. Однако в самой задаче заключен немалый параллелизм. На рис. 54 показано, как можно осуществить суммирование восьми чисел в три этапа. Задача суммирования разделена на меньшие подзадачи, которые могут решаться независимо. Граф на рис. 54 называется графом сдваивания. В частности, та же идея применима к вычисле­нию произведения nчисел , достаточно заменить на рис. 54 знак + на знак *. Точно так же, чтобы найти максимальное из nчисел , можно заменить знак операции сложения символом max; например, вместо на рис. 54 стояло бы , и т. д. Заметим, что граф на рис. 54 представляет собой двоичное дерево, поэтому операцию, вы­полняемую с помощью графа сдваивания, иногда называют операцией на дереве.

Для чисел алгоритм сдваивания состоит из этапов; на первом этапе выполняются n/2 сложений, на втором - n/4, и т. д., пока на последнем этапе не будет выполнено единственное сложение. Очевидно, что на первом этапе степень параллелизма равна n/2, на втором - n/4, и т. д.

Определение 4. Средней степенью параллелизма числен­ного алгоритма называется отношение общего числа операций алгоритма к числу его этапов.

Рис. 54. Схема алгоритма сдваивания

Для алгоритма сдваивания средняя степень параллелизма равна , тогда как при сложении двух n-векторов средняя степень параллелизма равна n, т. е. совпадает со степенью параллелизма. Этот последний алгоритм обладает «идеальным» параллелизмом, в то время как для алгоритма сдваивания средняя степень параллелизма в раз меньше идеальной. И все же алгоритм сдваивания можно считать хорошо параллелизуемым, особенно по сравнению с последовательным алгоритмом, для которого средняя степень параллелизма равна .

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

Зако́н Амдала (англ. Amdahl's law, иногда также Закон Амдаля-Уэра) — иллюстрирует ограничение роста производительности вычислительной системы с увеличением количества вычислителей. Джин Амдал сформулировал закон в 1967 году, обнаружив простое по существу, но непреодолимое по содержанию ограничение на рост производительности при распараллеливании вычислений: «В случае, когда задача разделяется на несколько частей, суммарное время её выполнения на параллельной системе не может быть меньше времени выполнения самого длинного фрагмента». Согласно этому закону, ускорение выполнения программы за счёт распараллеливания её инструкций на множестве вычислителей ограничено временем, необходимым для выполнения её последовательных инструкций.

Математическое выражение

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

Иллюстрация

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

Из таблицы видно, что только алгоритм, вовсе не содержащий последовательных вычислений ( ), позволяет получить линейный прирост производительности с ростом количества вычислителей в системе. Если доля последовательных вычислений в алгоритме равна 25 %, то увеличение числа процессоров до 10 дает ускорение в 3,077 раза, а увеличение числа процессоров до 1000 даст ускорение в 3,988 раза.

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

Идейное значение

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

Более того, если учесть время, необходимое для передачи данных между узлами вычислительной системы, то зависимость времени вычислений от числа узлов будет иметь максимум. Это накладывает ограничение на масштабируемость вычислительной системы, то есть означает, что с определенного момента добавление новых узлов в систему будет увеличивать время расчёта задачи.

9.3 Метод логарифмічного здвоєння та рекурсивного подвоєння.

Степенью параллелизма численного алгоритма называется число его операций, которые можно вы­полнять параллельно.

В данном случае – 7 операций, 3 этапа. 7/3≈2.33

Если n – целая степень двойки, то алгоритм имеет a=log(n) этапов.

Функция степени параллелизма: q=n-1/log(n)

Проиллюстрируем это определение несколькими примерами и по ходу дела уточним его. Начнем с задачи сложения двух векторов а и b. Сложения a_i+b_i (i=1,…,n) независимы и могут выполняться параллельно. Таким образом, степень параллелизма этого алгоритма равна n. Разумеется, от числа процес­соров зависит время, необходимое для завершения вычислений. Например, если n= 1000 и число процессоров p также равно 1000, то все суммы условно можно вычислить за один временной шаг, однако при p = 10 потребуется 100 временных шагов.

Для n=2^q чисел алгоритм сдваивания состоит из q=log₂n этапов; на первом этапе выполняются n/2 сложений, на втором – n/4, и т. д., пока на последнем этапе не будет выполнено единственное сложение. Очевидно, что на первом этапе степень параллелизма равна n/2, на втором - n/4, и т. д.

Средней степенью параллелизма числен­ного алгоритма называется отношение общего числа операций алгоритма к числу его этапов. n-1/logn

Алгоритм рекурсивного удвоения

Пусть нужно сложить 8 чисел. Введем такие обозначения:

9.4 Методи паралельного множення матриць. §34. Алгоритм умножения матриц

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

Для простоты возьмем квадратные матрицы и размерности .

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

Приведем алгоритм:

Шаг 1: на

Шаг 2: на (причем циклы по индексам расположены в следующей последовательности

Шаг 3:

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

Возможные способы хранения исходных матриц порождают другие алгоритмы. Например, матрица распределена по процессорам слоистым образом по строкам, а матрица - целиком, или распределена по процессорам слоистым образом по столбцам, а - целиком. Алгоритмы при этом схожи с рассмотренными выше.

Возможно также построение алгоритмов, которые основаны на блочном распределении матриц и по процессорам.

Если разбиения обеих матриц на блоки согласованы, то

,

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

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

9.5 Стандарт mpi, основні функції для організації паралельних програм: ініціалізації та завершення паралельної програми, визначення рангу процесу, визначення загального числа процесів.

MPI (Message Passing Interface) – интерфейс передачи сообщений, был разработан в 1994 году MPI1; MPI2 1998; mpich 1.2.4 (под Linux).

Mpich 1.2.5 (аналог под Windows).

SPMD – на всех параллельных узлах работает одна и та же программа.

MPMD – на каждом узле работает своя программа и данные разные.

Основные понятия положения MPI

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

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

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

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

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

6. Для одной области взаимодействия может существовать несколько коммуникаторов.

7. Один коммуникатор создается системой MPI автоматически. Он охватывает все процессы принадлежащие приложению и имеет имя по умолчанию: MPI_COMM_WORLD.

Program

mpirun – np8 program – запуск

Для того чтобы библиотеки стали доступны, первой в программе должна быть выполнена функция:

MPI_Init(&argc,&argv);

Для завершения работы приложения необходимо выполнить функцию:

MPI_Finalize();

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

MPI_Comm_size(comm,& size);

Часто процессам необходимо знать свой номер:

MPI_Comm_rank(comm, & rank);

MPI_Send(buf,count,datatype,dest,tag,comm); - посылка сообщений

MPI_Recv(buf,count,datatype,source,tag,comm,& status);

buf – адрес буфера (имя массива).

datatype – тип данных приема и передачи сообщений.

count – количества данных типа datatype передачи (приема) сообщений.

dest – номер процесса посылки сообщения.

source – номер процесса откуда пришло сообщение.

tag – номер сообщения.

comm – коммуникатор.

status – информационная структура.

#include ”mpi.h”

int main(args,*argv[])

{int myrank,size;

char message[25];

MPI_Status;

MPI_Init(& argc,&argv);

MPI_Comm_Size(MPI_COMM_WORLD,&size);

MPI_Comm_rank(MPI_COMM_WORLD,&myrank);

printf(“I’m %d from %d\n”,myrank,size);

if(myrank==1)

{strcpy(message,”Fist program”);

MPI_Send(message,25,MPI_CHAR,0,100,MPI_COMM_WORLD);

if(myrank==0)

{MPI_Recv(message,25,MPI_CHAR,1,100,MPI_COMM_WORLD,& status);

printf(“%s”,message);

}

MPI_Finalyze();

return 0;

}

mpirun –np2 myprogram – запуск программы.

Определение количества процессов в выполняемой параллельной программе осуществляется при помощи функции:

int MPI_Comm_size ( MPI_Comm comm, int *size ).

Для определения ранга процесса используется функция:

int MPI_Comm_rank ( MPI_Comm comm, int *rank ).

Как правило, вызов функций MPI_Comm_size и MPI_Comm_rank выполняется сразу после MPI_Init:

#include "mpi.h"

int main ( int argc, char *argv[] ) {

int ProcNum, ProcRank;

<программный код без использования MPI функций>

MPI_Init ( &agrc, &argv );

MPI_Comm_size ( MPI_COMM_WORLD, &ProcNum);

MPI_Comm_rank ( MPI_COMM_WORLD, &ProcRank);

<программный код с использованием MPI функций >

MPI_Finalize();

<программный код без использования MPI функций >

return 0;

}

int MPI_Comm_size( MPI_Comm comm, int* size)

Определение общего числа параллельных процессов в группе comm.

• comm - идентификатор группы

• OUT size - размер группы

9.6 Функції двохточкового обміну.

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

Двухточечный буферизованный обмен

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

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

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

Двухточечные неблокирующие обмены

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

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

1. Инициализация обмена.

2. Проверка завершения обмена.

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

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

Подпрограмма MPI_Wait блокирует работу процесса до завершения приема или передачи сообщения. ФункцииMPI_Wait и MPI_Test можно использовать для завершения операций

9.7 Функції колективного обміну: розподілення, широкомовної розсилки, збору, зведення, сканування.

Основные особенности и отличия от коммуникаций типа "точка-точка":

• на прием и/или передачу работают одновременно ВСЕ задачи-абоненты указываемого коммуникатора;

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

• как правило, значения ВСЕХ параметров (за исключением адресов буферов) должны быть идентичными во всех задачах;

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

MPI_Bcast рассылает содержимое буфера из задачи, имеющей в указанной области связи номер root, во все остальные:

MPI_Bcast( buf, count, dataType, rootRank, communicator );

Она эквивалентна по результату (но не по внутреннему устройству) следующему фрагменту:

MPI_Comm_size( communicator, &commSize );

MPI_Comm_rank( communicator, &myRank );

if( myRank == rootRank )

for( i=0; i<commSize; i++ )

MPI_Send( buf, count, dataType, i,

tempMsgTag, communicator );

MPI_Recv( buf, count, dataType, rootRank, tempMsgTag,

communicator, &status );

MPI_Gather ("совок") собирает в приемный буфер задачи root передающие буфера остальных задач. Ее аналог:

MPI_Send( sendBuf, sendCount, sendType, rootRank, ... );

if( myRank == rootRank ) {

MPI_Type_extent( recvType, &elemSize );

for( i=0; i<commSize; i++ )

MPI_Recv( ((char*))recvBuf) + (i * recvCount * elemSize),

recvCount, recvType, i, ... );

}

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

Векторный вариант "совка" - MPI_Gatherv - позволяет задавать РАЗНОЕ количество отправляемых данных в разных задачах-отправителях. Соответственно, на приемной стороне задается массив позиций в приемном буфере, по которым следует размещать поступающие данные, и максимальные длины порций данных от всех задач. Оба массива содержат позиции/длины НЕ в байтах, а в количестве ячеек типа recvCount. Ее аналог:

MPI_Send( sendBuf, sendCount, sendType, rootRank, ... );

if( myRank == rootRank ) {

MPI_Type_extent( recvType, &elemSize );

for( i=0; i<commSize; i++ )

MPI_Recv( ((char*))recvBuf) + displs[i] * recvCounts[i]

* elemSize, recvCounts[i], recvType, i, ... );

}

MPI_Scatter ("разбрызгиватель") : выполняет обратную "совку" операцию - части передающего буфера из задачи root распределяются по приемным буферам всех задач. Ее аналог:

if( myRank == rootRank ) {

MPI_Type_extent( recvType, &elemSize );

for( i=0; i<commSize; i++ )

MPI_Send( ((char*)sendBuf) + i*sendCount*elemSize,

sendCount, sendType, i, ... );

}

MPI_Recv( recvBuf, recvCount, recvType, rootRank, ... );

И ее векторный вариант - MPI_Scatterv, рассылающая части неодинаковой длины в приемные буфера неодинаковой длины.

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

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

Помните, что коллективные функции несовместимы с "точка-точка": недопустимым, например, является вызов в одной из принимающих широковещательное сообщение задач MPI_Recv вместо MPI_Bcast.

Організація баз даних

10.1 Архітектура субд. Функції субд.

СУБД должна предоставлять доступ к данным любым пользователям, включая и тех, которые практически не имеют и (или) не хотят иметь представления о:

• физическом размещении в памяти данных и их описаний;

• механизмах поиска запрашиваемых данных;

• проблемах, возникающих при одновременном запросе одних и тех же данных многими пользователями (прикладными программами);

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

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

и множестве других функций СУБД.

При выполнении основных из этих функций СУБД должна использовать различные описания данных. А как создавать эти описания?

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

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

Рис. 1.3. Уровни моделей данных

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

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

Так как указанный доступ осуществляется с помощью конкретной СУБД, то модели должны быть описаны на языке описания данных этой СУБД. Такое описание, создаваемое АБД по инфологической модели данных, называют даталогической моделью данных.

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

2.1. Основные функции субд

Более точно, к числу функций СУБД принято относить следующие:

2.1.1. Непосредственное управление данными во внешней памяти

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

2.1.2. Управление буферами оперативной памяти

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

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

2.1.3. Управление транзакциями

Транзакция - это последовательность операций над БД, рассматриваемых СУБД как единое целое. Либо транзакция успешно выполняется, и СУБД фиксирует (COMMIT) изменения БД, произведенные этой транзакцией, во внешней памяти, либо ни одно из этих изменений никак не отражается на состоянии БД. Понятие транзакции необходимо для поддержания логической целостности БД. Если вспомнить наш пример информационной системы с файлами СОТРУДНИКИ и ОТДЕЛЫ, то единственным способом не нарушить целостность БД при выполнении операции приема на работу нового сотрудника является объединение элементарных операций над файлами СОТРУДНИКИ и ОТДЕЛЫ в одну транзакцию. Таким образом, поддержание механизма транзакций является обязательным условием даже однопользовательских СУБД (если, конечно, такая система заслуживает названия СУБД). Но понятие транзакции гораздо более важно в многопользовательских СУБД.

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

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

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

2.1.4. Журнализация

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

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

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

Во всех случаях придерживаются стратегии "упреждающей" записи в журнал (так называемого протокола Write Ahead Log - WAL). Грубо говоря, эта стратегия заключается в том, что запись об изменении любого объекта БД должна попасть во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части БД. Известно, что если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановления БД после любого сбоя.

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

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

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

2.1.5. Поддержка языков бд

Для работы с базами данных используются специальные языки, в целом называемые языками баз данных. В ранних СУБД поддерживалось несколько специализированных по своим функциям языков. Чаще всего выделялись два языка - язык определения схемы БД (SDL - Schema Definition Language) и язык манипулирования данными (DML - Data Manipulation Language). SDL служил главным образом для определения логической структуры БД, т.е. той структуры БД, какой она представляется пользователям. DML содержал набор операторов манипулирования данными, т.е. операторов, позволяющих заносить данные в БД, удалять, модифицировать или выбирать существующие данные. Мы рассмотрим более подробно языки ранних СУБД в следующей лекции.

В современных СУБД обычно поддерживается единый интегрированный язык, содержащий все необходимые средства для работы с БД, начиная от ее создания, и обеспечивающий базовый пользовательский интерфейс с базами данных. Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык SQL (Structured Query Language). В нескольких лекциях этого курса язык SQL будет рассматриваться достаточно подробно, а пока мы перечислим основные функции реляционной СУБД, поддерживаемые на "языковом" уровне (т.е. функции, поддерживаемые при реализации интерфейса SQL).

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

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

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

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

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

10.2 Реляційна модель та її характеристики.

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

Реляционная модель данных – это модель, в которой все данные представлены в виде таблиц, а все операции над данными сводятся к операциям над таблицами

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

Свойства отношений

• Отношение имеет уникальное имя.

• Каждый атрибут имеет уникальное имя.

• Атрибуты расположены в произвольном порядке.

• Каждый атрибут является уникальным.

• Значение каждого атрибута атомарно.

• Каждый кортеж является уникальным, т.е. нет одинаковых кортежей.

• Кортежи не упорядочены.

• Каждое отношение имеет хотя бы один ключ.

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

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

Каждый атрибут определен только на одном домене, но на одном домене могут быть определены несколько атрибутов.

Атомарное значение - наименьшее неделимое значение данных, хранимое в отношении.

Кортеж – строка в отношении. Кортеж состоит из набора заполненных атрибутов.

Тело отношения - совокупность кортежей.

Степень отношения- количество атрибутов отношения.

Кардинальность- количество кортежей отношения.

Ключ – минимальный набор атрибутов, который однозначно идентифицирует каждый кортеж отношения

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

Первичный ключ – любой из потенциальных ключей (лучше несоставной и целочисленный)

Внешний ключ – набор атрибутов одного отношения, которые являются ключом другого отношения.

С помощью внешних ключей устанавливаются связи между отношениями

Свойства ключей:

- Уникальность – в произвольный момент времени не существует двух различных кортежей с одинаковыми значениями ключей.

- Минимальность - исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся.

Сущность - это какой-нибудь отдельный предмет, информацию о котором нужно хранить в БД. Тип сущности представляет собой множество объектов реального мира с одинаковыми св-ми. Каждый тип сущностей идентифицируется именем и списком свойств.

Связь - ассоциирование двух или больше сущностей. [связи -1:1(друг к другу), 1:М (один ко многим), М:М(много ко многим].

Функциональная зависимость описывает связь между атрибутами отношения.

Частичной функциональной зависимостью наз-ся зависимость А®В, если в А - такой атрибут при исключении которого зависимость сохраняется.

Зависимость между атрибутами А и В называется транзитивной, если существуют зависимости А ®В и В® С, тогда зависимость А ® С является транзитивной.

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

Таблица находится в 1НФ, если на пересечении каждого строке и каждого столбца находится только одно значение соответствующего атрибута.

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

Таблица отвечает 3НФ, если она отвечает 1НФ и 2НФ и не имеет атрибутов, которые не входят в первичный ключ и находятся в транзитивные зависимости от первичного ключа.

10.3 Потенційні, первинні та зовнішні ключі.

Ключ – минимальный набор атрибутов, который однозначно идентифицирует каждый кортеж отношения

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

Первичный ключ – любой из потенциальных ключей (лучше несоставной и целочисленный)

Внешний ключ – набор атрибутов одного отношения, которые являются ключом другого отношения.

С помощью внешних ключей устанавливаются связи между отношениями

Ключ отношения Отдел N_отдела является внешним ключом отношения Служащий, для которого первичным ключом является N_служащего

Пример 2 Многократное использование внешних ключей позволяет устранить избыточность данных

Свойства ключей:

• Уникальность – в произвольный момент времени не существует двух различных кортежей с одинаковыми значениями ключей.

• Минимальность - исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся.

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

Противоречивость данных- несоответствие данных состоянию и ограничениям предметной области.

Поддержка целостности включает в себя:

- Структурную целостность – схема базы данных может состоять только из нормализованных таблиц.

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

- Ссылочною целостность- если в отношении есть внешний ключ, то он не может указывать на несуществующую строку

Корпоративные ограничения целостности – дополнительные правила ограничения целостности, определяемые пользователем или администратором базы данных

Например:

- В отделе не может работать больше 10 человек.

- Абитуриент не может быть старше 35 лет.

- В одном кабинете не может работать. одновременно два врача.

- Один преподаватель не может читать лекцию одновременно в двух аудиториях.

10.4 Цілісність реляційних даних. Целостность реляционных данных

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

Явные ограничения задаются семантикой предметной области. Они описывают области допустимых значений атрибутов, соотношение между атрибутами, динамику их изменения и т. д. Внутренние ограничения свойственны собственно модели данных. Они накладываются на структуру отношений, на связи, на допустимые значения наборов данных, заложенные в выбранной модели данных. Способы реализации внутренних ограничений целостности зависят от СУБД.

В РМД существует два вида внутренних ограничений целостности.

1. Целостность по существованию – потенциальный ключ отношения не может иметь пустого значения (NULL).

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

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

Противоречивость данных- несоответствие данных состоянию и ограничениям предметной области.

Поддержка целостности включает в себя:

- Структурную целостность – схема базы данных может состоять только из нормализованных таблиц.

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

- Ссылочною целостность- если в отношении есть внешний ключ, то он не может указывать на несуществующую строку

Корпоративные ограничения целостности – дополнительные правила ограничения целостности, определяемые пользователем или администратором базы данных

Например:

- В отделе не может работать больше 10 человек.

- Абитуриент не может быть старше 35 лет.

- В одном кабинете не может работать. одновременно два врача.

- Один преподаватель не может читать лекцию одновременно в двух аудиториях.

10.5 Операції реляційної алгебри.

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

Реляционная алгебра, предложенная Коддом состоит из 8 операторов:

- Операции над множествами: объединение (union), пересечение (intersection), вычитание (difference);

- Операции удаления частей отношения: выборка(selection), проекция (projection);

- Операции сочетания кортежей двух отношений: декартово произведение (Cartesian product), соединение (join)

- Операция переименования атрибутов, или отношения целиком (renaming).

Выражения реляционной алгебры называются запросами.

Выборка s_{предикат}(R) дает в результате отношение, содержащее все кортежи, удовлетворяющие некоторому условию. Схемы итогового и исходного отношения не изменяются. Порядок следования атрибутов сохраняется.

Пример использования операции выборки

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

арендная плата больше 100 грн в месяц

s_{платня>100}(Недвижимость)

Проекция П_атр1, _атр2(R) - отношение, содержащее только некоторые атрибуты отношения R, после извлечения указанных атрибутов и исключения из результата строк- дубликатов.

Пример применения операции проекции

П_{фамилия, телефон}

(Студенты)

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

_RxS

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

R S RÈS

Пересечение возвращает отношение, все кортежи которого принадлежат одновременно двум отношениям R и S

R Ç S= R –(R – S)

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

Вычитание возвращает отношение, все кортежи которого принадлежат только первому из двух отношений R и S

R – S

Вычитаемые отношения должны иметь схемы с идентичным набором атрибутов, следующих в одном порядке и имеющем совпадающие домены

Операции соединения

Соединение двух отношений формирует такое отношение, все кортежи которого удовлетворяют определенному критерию.

Различают:1)Тета-соединение; 2)Естественное соединение; 3)Внешнее соединение

4)Полусоединение

Естественное соединение предусматривает включение в итоговое отношение тех кортежей отношений R и S, которые совпадают в атрибутах, общих для схем R и S.

Тета соединение определяет отношение, которое содержит все кортежи из декартового произведения отношений R и S, удовлетворяющие некоторому условию f

R><_f S=s_f (RxS)

Соединение по эквивалентности: условие f содержит только знак равенства

Последовательность выполнения

1. Вычисляется декартово произведение R и S

2. Из результата выбираются только те кортежи, которые удовлетворяют заданному условию.

Схема итогового отношения представляет собой объединение схем отношений R и S. При необходимости имена атрибутов снабжаются префиксом-именем отношения

Пример выполнения тета-соединения

Левое внешнее соединение –соединение, при котором кортежи отношения R, не имеющие совпадающих значений в общих столбцах отношения S также включаются в результирующее отношение R É< S

Переименование атрибутов

Для переименования отношения R используется оператор r_{S(A1,A2,… An)}(R)

Итоговое отношение обладает теми же кортежами, что и R, но получает имя S, а его атрибуты имена А1, А2,… Аn. Если необходимо переименовать только отношение, r_S(R)

Пример выполнения операции переименования отношения

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

10.6 Основні поняття sql: прості запити, склеювання таблиць; умови відбору рядків таблиць; агрегатні функції, запити з групуванням, складні запити. Sql. Простые запросы

Начало формы

Запросы

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

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

Все запросы в SQL состоят из одиночной команды. Структура этой команды обманчиво проста, потому что вы должны расширять ее так чтобы выполнить высоко сложные оценки и обработки данных. Эта команда называется - SELECT(ВЫБОР).

В общем случае, команда SELECT начинается с ключевого слова SELECT, сопровождаемого пробелом. После этого должен следовать список имен столбцов которые вы хотите видеть, отделяемые запятыми. Если вы хотите видеть все столбцы таблицы, вы можете заменить этот список звездочкой (*). Ключевое слово FROM следующее далее, сопровождается пробелом и именем таблицы запрос к которой делается. В заключение, точка с запя- той ( ; ) должна использоваться чтобы закончить запрос и указать что команда готова к выполнению.

В упрощенном виде можно команду SELECT описать как

SELECT * |[<поле>[, ...]] FROM <таблица> [WHERE <условие> [ORDER BY <поле>]]

Реляционный оператор - математический символ который указывает на определенный тип сравнения между двумя значениями. Реляционные операторы которыми располагает SQL :

= Равный к

> Больше чем

< Меньше чем

>= Больше чем или равно

<= Меньше чем или равно

<> Не равно

Операторы Буля и как они работают:

• AND берет два Буля ( в форме A AND B) как аргументы и оценивает их по отношению к истине, верны ли они оба.

• OR берет два Буля ( в форме A OR B) как аргументы и оценивает на правильность, верен ли один из них.

• NOT берет одиночный Булев ( в форме NOT A) как аргументы и заменяет его значение с неверного на верное или верное на неверное.

Конец формы

IN, BETWEEN, LIKE

Оператор IN определяет набор значений в которое данное значение может или не может быть включено. Если вы хотите найти всех продавцов, которые размещены в Barcelona или в London, вы должны использовать следующий запрос:

SELECT * FROM Salespeople WHERE city = 'Barcelona' OR city = 'London';

Имеется и более простой способ получить ту же информацию:

SELECT * FROM Salespeople WHERE city IN ( 'Barcelona', 'London' );

Оператор BETWEEN похож на оператор IN. В отличии от определения по номерам из набора, как это делает IN, BETWEEN определяет диапазон, значения которого должны уменьшаться что делает предикат верным. Вы должны ввести ключевое слово BETWEEN с начальным значением, ключевое AND и конечное значение. В отличие от IN, BETWEEN чувствителен к по- рядку, и первое значение в предложении должно быть первым по алфавитному или числовому порядку. Следующий пример будет извлекать из

таблицы Продавцов всех продавцов с комиссионными между .10 и .12:

SELECT * FROM Salespeople WHERE comm BETWEEN .10 AND .12;

Для включенного оператора BETWEEN, значение совпадающее с любым из двух значений границы ( в этом случае, .10 и .12 ) заставляет предикат быть верным.

LIKE применим только к полям типа CHAR или VARCHAR, с которыми он используется чтобы находить подстроки. Т.е. он ищет поле символа чтобы видеть, совпадает ли с условием часть его строки. В качестве условия он использует групповые символы(wildcards) - специальные символы которые могут соответствовать чему-нибудь.

Имеются два типа групповых символов используемых с LIKE:

• символ подчеркивания ( _ ) замещает любой одиночный символ. Напри мер, 'b_t' будет соответствовать словам 'bat' или 'bit', но не будет соответствовать 'brat'.

• знак процента (%) замещает последовательность любого числа символов (включая символы нуля). Например '%p%t' будет соответствовать словам 'put', 'posit', или 'opt', но не 'spite'.

Давайте найдем всех заказчиков чьи имена начинаются с B:

SELECT FROM Customers WHERE cname LIKE 'B%';

Агрегатные функции, группировка данных

Для группировки данных в запросе select используется конструкция group by, в которой должны быть перечислены те же столбцы, что и после select. Ниже приведен пример вывода данных по группам для таблицы bills.

-- таблица счетов

create table bills(

id integer,

d date, -- дата счета

summ double precision ,-- сумма счета

constraint pk_bills primary key (id)

);

-- вставка данных

insert into bills

values(1, date '2008-01-01', 5.5);

insert into bills

values(2, date '2008-02-01', 3.14);

insert into bills

values(3, date '2008-03-01', 10.14);

insert into bills

values(4, date '2008-01-01', 7.2);

insert into bills

values(5, date '2008-02-01', 6.4);

insert into bills

values(6, date '2008-03-01', 2.5);

commit;

-- вывод данных по группам

select t.d, t.summ from bills t

group by t.d, t.summ

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

• avg([DISTINCT|ALL] column) - среднее значение по указанному столбцу;

• count(*|[DISTINCT|ALL] соlumn) - количество элементов в выборке или в группе определяемой указанным столбцом;

• sum([DISTINCT | ALL] соlumn) - сумма значений указанного столбца;

• max(соlumn) - максимальное значение в столбце;

• min(соlumn) - минимальное значение в столбце.

Ключевое слово DISTINCT позволяет игнорировать повторные значения в столбце, ALL обрабатывает все значения в столбце (по умолчанию), * позволяет включить в обработку поля с null значением. В MySQL между именем функции и скобкой не должно быть пробелов. Ниже приведен пример использования агрегатных функций в качестве выбираемых данных. Если агрегатная функция используется в выборке без group by, то она применяется ко всем записям выборки, иначе для каждой группы в отдельности. И в любом случае в перечислении select нельзя смешивать групповые столбцы с не групповыми.

-- статистические данные по всем месяцам

select count(*) as "число записей",

max(t.summ) as "макс. сумма",

min(t.summ) as "мин. сумма",

avg(t.summ) as "средняя сумма",

sum(t.summ) as "общая сумма"

from bills t;

-- статистические данные по каждому месяцу

select t.d as "месяц", count(1) as "число записей",

max(t.summ) as "макс. сумма",

min(t.summ) as "мин. сумма",

avg(t.summ) as "средняя сумма",

sum(t.summ) as "общая сумма"

from bills t

group by t.d

Агрегатные функции можно использовать в выражениях условия в конструкции having для отбора группы.

-- отбираем группы у которых общая сумма больше 12

select t.d as "месяц", count(*) as "число записей",

max(t.summ) as "макс. сумма",

min(t.summ) as "мин. сумма",

avg(t.summ) as "средняя сумма",

sum(t.summ) as "общая сумма"

from bills t

group by t.d

having sum(t.summ)>12

Запрос с группировкой

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

Для решения поставленной задачи добавьте в новый запрос таблицы Заказано (Order Details), Заказы (Orders) и Клиенты (Customers). Конструктор запросов автоматически проставит постоянные связи, существующие между этими таблицами на уровне базы данных. В бланк запроса перенесите поле Название (CompanyName) из таблицы Клиенты (Customers) и полеКодЗаказа (OrderlD) из таблицы Заказы (Orders). В определения следующих двух полей бланка запросов введите одну и ту же строку:  ССиr([Цена]*[Количество]*(1-[Скидкa])/100)*100 (CCur([UnitPrice]*[Quantity]*(1-[Discount])/100)*100).  Последним добавьте поле Дата Размещения (OrderDate) из таблицы Заказы (Orders). Для того чтобы воспользоваться возможностями группировки, нужно нажать на панели инструментов кнопку Групповые операции (Totals) (кнопка с изображением греческой буквы  ). В бланке запроса появится строка с названием Групповая операция (Total), для каждого поля в котором указано значение Группировка (Group By). Измените эти значения для второго поля на значение Count, для третьего — на Avg, для четвертого — на Sum, после чего присвойте полям новые имена — Количество заказов, Средняя стоимость и Полная стоимость. Для поля ДатаРазмещения (OrderDate) значение группировка (Group By) необходимо заменить на Условие (Where) (после чего конструктор автоматически снимет флажок Вывод на экран (Show)) и в строке Условие отбора (Criteria) ввести следующую строку: Between #01.01.98# And #31.12.98#. Последнее, что нужно сделать — указать для поля Полная стоимость порядок сортировки по убыванию (Descending). На этом разработку своеобразного хит-парада клиентов можно считать завершенной. Получившийся запрос представлен на рис. 4.31 (в режиме конструктора (Design View)), рис. 4.32 (в режиме таблицы (Datasheet View)) и рис. 4.33 (SQL-оператор (SQL View)).

Пояснения

1. Операция Группировка (Group By) предназначена для объединения записей, имеющих одинаковые значения в группируемых полях, в одну запись. Для полей, у которых указана статистическая функция (Sum, Count и т.д.), производятся соответствующие вычисления. В нашем примере операция группировка (GroupBy) указана для поля Название (CompanyName). Это значит, что из всех записей таблицы Клиенты (Customers), удовлетворяющих условию по нолю ДатаРазмещения (OrderDate), в результирующий набор данных войдет только одна запись для каждого клиента. При этом поле Количество заказов будет содержать количество записей, соответствующих конкретному клиенту в таблице Заказы (Orders). Например, если для какого-либо из клиентов в течение 1998 года было выписано 12 счетов, то в поле Количество заказов, соответствующих данному клиенту, будет отображено значение 12. Точно так же в полях Средняя стоимость и Полная стоимость — будут вычислены среднее значение и сумма стоимости всех заказов по каждому клиенту. Описание статистических функций SQL приведено в таблице 4.6.

2. В таблице 4.5 перечислены все возможные значения свойства групповые операции (Group By).

Таблица 4.5.  Возможные значения свойства  Групповые операции (Group By).
Функция	Комментарии
Группировка	Указывается для полей, по совпадающим значениям которых происходит объединение записей в одну.
Выражение	Указывается для вычисляемых полей.
Условие	Указывается для полей, которые не должны попасть в результирующий набор данных, но по которым проверяется условие. Условие для такого поля проверяется до выполнения операции группирования. Если для поля ввести условие и в поле Групповые операции указать группировка (Group By), то условие будет проверяться уже после группировки. Для первого случая в операторе SQL используется предложение WHERE, a для второго — HAVING.

Таблица 4.6. Статистические функции.
Функция	Описание
Sum	Возвращает сумму значении, содержащихся в заданном поле запроса в записях, группируемых в одну. Синтаксис:  Sum(выражение).  Аргумент выражение может содержать либо название поля, либо выражение, выполняющее какие-либо вычисления. Выражение может включать имена полей, константы и функции. Функции могут быть определяемыми пользователем (в модуле), но не могут быть другими статистическими функциями. Функция Sum пропускает записи со значением Null в данном поле.
Avg	Вычисляет арифметическое среднее набора чисел, содержащихся в указанном поле запроса в записях, входящих в одну группировку. Синтаксис: Avg(выражение). Замечания относительно аргумента выражение и полей со значением Null те же что и для функции Sum.
Min, Max	Возвращают соответственно минимальное и максимальное значения из набора значений, содержащихся в указанном поле запроса в пределах одной группировки. Синтаксис: Min(выражение), Мах(выражение).  Замечания — те же.
Count	Возвращает количество записей, объединяемых в одну при группировке. Синтаксис: Count(выражение). Выражение может быть таким же, как и для выше описанных статистических функций. Функция Count, так же как и остальные функции, не подсчитывает записи, содержащиеNull в полях, указанных в выражении. Поэтому, чтобы избежать глупых ошибок, нужно указывать либо обязательные для ввода поля (которые гарантированно будут содержать какое-либо значение — например, первичный ключ), либо подстановочный знак звездочки (например, Count(*)).
StDev	Вычисляет величину смещенного стандартного отклонения по набору значений, содержащихся в указанном поле запроса для каждой группировки. Синтаксис: StDev(выpaжeнue). Замечания по поводу выражения и полей со значением Null те же, что и для функции Sum. Кроме того, если группировка содержит меньше двух записей, то функция возвращает значение Null, что означает невозможность вычисления стандартного отклонения. Стандартное отклонение (среднеквадратичное отклонение) — параметр, который указывает величину разброса функции распределения около среднего значения. Он равен квадратному корню из момента для квадрата отклонении от среднего. Более подробную информацию можно получить в справочной системе Microsoft Access.
Var	Возвращает значение смещенной дисперсии, вычисляемой по набору значений, содержащихся в указанном поле запроса для каждой группировки. Синтаксис: Var(выражение). Замечания по поводу выражения и полей со значением Null те же, что и для функции Sum. Если группировка содержит меньше двух записей, функция возвращает значениеNull, что означает невозможность вычисления дисперсии. Дисперсия — квадрат значения среднеквадратичного отклонения, мера отличия значении в группе от среднего
First, Last	Возвращают значение поля соответственно из первой и последней записи набора записей в пределах каждой группировки. Синтаксис: First(выражение), Last(выражение). Выражение — такое же, как и для остальных статистических функций. Поскольку записи обычно возвращаются без какого-либо специального порядка (кроме случаев, когда запрос содержит предложение ORDER BY), эти функции возвращают случайные данные.

3. Следует обратить внимание на то, что хотя для полей Средняя стоимость и Полная стоимость были указаны групповые операции Avg и Sum соответственно, после сохранения запроса конструктор подставил названия этих функций непосредственно в определение полей (см. рис. 4.31), а значение групповой операции изменил на Выражение (Expression). В то же самое время, поле Количество заказов осталось без изменений, поскольку в качестве выражения для функции Count указано просто имя соответствующего поля таблицы.

4. При вычислении полей Средняя стоимость и Полная стоимость использовалась функция CCur, являющаяся одной из функций преобразования типов (Type Conversion Functions). Хотя чаще эти функции используются при программировании на Visual Basic, в запросах тоже иногда приходится их использовать. Чаще всего эти функции используются в вычисляемых полях запросов. Например, если из таблицы в запрос добавить поля Количество и Стоимость, а потом добавить вычисляемое поле Цена:[Стоимость]/[Количество], то в результирующем наборе данных в этом поле появятся значения, содержащие огромное количество знаков дробной части. Ниже, в таблице 4.7 приведено краткое описание функций преобразования типов. За более полной информацией следует обратиться к справочной системе Microsoft Access.

Таблица 4.7. Функции преобразования типов
Функция	Возвращаемое значение
CBool(выражение)	Логическое значение Истина (True) или Ложь (False).
CByte(выражение)	Значение байта (от 0 до 255).
CCur( выражение)	Значение денежного типа (Currency).
CDate(выражение)	Значение типа дата/время (Date/Time).
Cdbl(выражение)	Значение типа двойное с плавающей точкой (Double).
CDec(выражение)	Значение типа действительное (Decimal).
CInt(выражение)	Значение целого типа (Integer).
CLng(выражение)	Значение типа длинное целое (Long).
Csng(выражение)	Значение типа одинарное с плавающей точкой (Single).
Cstr(выражение)	Значение текстового типа (String).
CVar(выражени е)	Значение типа Variant. Переменные типа Variant могут содержать значения любого типа. Этот тип данных используется, в основном, при программировании на языке Visual Basic и будет описан позже.

ЗАМЕЧАНИЕ

Для представления различных значений в удобном виде используется функция Format.

Сложные запросы

Начало формы

Объединение таблиц

Объединение таблиц

Одна из наиболее важных особенностей запросов SQL - это их способность определять связи между многочисленными таблицами и выводить информацию из них в терминах этих связей, всю внутри одной команды. Этот вид операции называется - объединением, которое является одним из видов операций в реляционных базах данных. Используя объединения, мы непосредственно связываем информацию с любым номером таблицы, и таким образом способны создавать связи между сравнимыми фрагментами данных. При объединении, таблицы представленные списком в предложении FROM запроса, отделяются запятыми. Предикат запроса может ссылаться к любому столбцу любой связанной таблицы и, следовательно, может использоваться для связи между ими. Обычно, предикат сравнивает значения в столбцах различных таблиц чтобы определить, удовлетворяет ли WHERE установленному условию.

Имена таблиц и столбцов

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

Salers.snum

Salers.city

Orders.odate

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

Создание обьединения

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

SELECT Customers.cname, Salespeople.sname,

Salespeople.city

FROM Salespeople, Customers

WHERE Salespeople.city = Customers.city;

Что SQL в основном делает в объединении - так это исследует каждую комбинацию строк двух или более возможных таблиц, и проверяет эти комбинации по их предикатам. В предыдущем примере, требовалась строка продавца Peel из таблицы Продавцов и объединение ее с каждой строкой таблицы Пользователей, по одной в каждый момент времени. Если комбинация производит значение которое делает предикат верным, и если поле city из строк таблиц Заказчика равно London, то Peel - это то запрашиваемое значение которое комбинация выберет для вывода. То же самое будет затем выполнено для каждого продавца в таблице Продавцов ( у некоторых из которых не было никаких заказчиков в этих городах).

Объединение таблиц через справочную целостность

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

SELECT Orders.odate, Salespeople.sname

FROM Orders, Salespeople

WHERE Salespeople.snum = Orders.snum;

Объединения таблиц по равенству значений в столбцах и другие виды объединений

Объединения которые используют предикаты основанные на равенствах называются - объединениями по равенству. Все наши примеры в этой главе до настоящего времени, относились именно к этой категории, потому что все условия в предложениях WHERE базировались на математических выражениях использующих знак равно ( = ). Строки 'city = 'London' и 'Salespeople.snum = Orders.snum ' - примеры таких типов равенств найденных в предикатах. Объединения по равенству - это вероятно наиболее общий вид объединения, но имеются и другие. Вы можете, фактически, использовать любой из реляционных операторов в обьединении.

SELECT sname, cname FROM Salespeople, Customers

WHERE sname < cname AND rating < 200;

Объединение более двух таблиц

SELECT onum, cname, Orders.cnum, Orders.snum

FROM Salespeople, Customers,Orders

WHERE Customers.city < > Salespeople.city

AND Orders.cnum = Customers.cnum

AND Orders.snum = Salespeople.snum;

Объединение таблицы с собой псевдонимы

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

SELECT first.cname, second.cname, first.rating

FROM Customers first, Customers second

WHERE first.rating = second.rating;

Конец формы

10.7 Інфологічна, логічна або концептуальна модель даних. Основные этапы проектирования баз данных Концептуальное (инфологическое) проектирование

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

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

Чаще всего концептуальная модель базы данных включает в себя:

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

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

Логическое (даталогическое) проектирование

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

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

На этапе логического проектирования учитывается специфика конкретной модели данных, но может не учитываться специфика конкретной СУБД.

Физическое проектирование

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

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

Логическая модель данных является начальным прототипом будущей базы данных. Логическая модель строится в терминах информационных единиц, но без привязки к конкретной СУБД. Более того, логическая модель данных необязательно должна быть выражена средствами именно реляционной модели данных. Основным средством разработки логической модели данных в настоящий момент являются различные варианты ER-диаграмм (Entity-Relationship, диаграммы сущность-связь). Одну и ту же ER-модель можно преобразовать как в реляционную модель данных, так и в модель данных для иерархических и сетевых СУБД, или в постреляционную модель данных. Однако, т.к. мы рассматриваем именно реляционные СУБД, то можно считать, что логическая модель данных для нас формулируется в терминах реляционной модели данных.

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

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

Концептуальные модели данных. Модель «сущность-связь». Сущности, атрибуты, связи. Сущности-связи и мощности связей. Примеры.

Начальной стадией проектирования системы баз данных является построение семантической модели предметной области, которая базируется на анализе свойств и природы объектов предметной области и информационных потребностей будущих пользователей разрабатываемой системы. Эту стадию принято называть концептуальным проектированием системы, а ее результат – концептуальной моделью предметной области (объектом моделирования здесь является предметная область будущей системы). Такие модели обобщенно представляют информационные потребности пользователей создаваемой системы в части использования хранимых данных и по существу являются средством коммуникации как разработчиков, так и пользователей на разных стадиях жизненного цикла базы данных. Назначение концептуальных моделей определяет и некоторые специфические требования к средствам их представления. Помимо упомянутой независимости от среды (оборудования) и требования адекватности отражения предметной области отметим следующие: • формализованность, обеспечивающую возможность автоматизированной обработки, в том числе, например, автоматический контроль непротиворечивости; • дружественность, обеспечивающую возможность использования наглядных графических средств отображения и обработки их пользователем. К концептуальным моделям относятся различные компоненты, по-разному и разными средствами отражающие предметную область. Помимо наиболее известного описания объектов и связей между ними (модель «сущность-связь») к концептуальному уровню описания предметной области можно отнести следующие компоненты: • систему атрибутов и средств описания предметной области. Например, логические (автоматические) связи между показателями или лингвистические свойства языка (синонимию, синтаксис и т.д.), используемую для вербального представления объектов; • ограничения целостности, определяющие допустимость значения отдельных полей и взаимосвязей как на уровне семантики содержимого БД, так и ее физической структуры (отдельных файлов данных и взаимосвязей между ними); • описание информационных потребностей пользователей, например, в виде типовых запросов, отражающих процедурные особенности обращения к данным. Одной из наиболее популярных средств формализованного представления предметной области систем, ориентированных на обработку фактографической информации, является модель «сущность-связь», которая положена в основу значительного количества коммерческих CASE-продуктов, поддерживающих полный цикл разработки систем баз данных или отдельные его стадии. При этом многие из них не только поддерживают стадию концептуального проектирования предметной области разрабатываемой системы, но и позволяют осуществить на основе построенной их средствами модели стадию логического проектирования путем автоматической генерации концептуальной схемы базы данных для выбранной СУБД, например, схемы базы данных для какого-либо SQL-севера или объектной СУБД. Моделирование предметной области в этом случае базируется на использовании графических диаграмм, включающих сравнительно небольшое число компонентов, и самое важное – технологию построения таких диаграмм. Семантическую основу ER-модели составляют следующие предположения: • та часть реального мира (совокупность взаимосвязанных объектов), сведения о которых должны быть помещены в базу данных, может быть представлена как совокупность сущностей; • сущности можно классифицировать по типам сущностей: каждый экземпляр сущности (представляющий некоторый объект) может быть отнесен к классу – типу сущностей, каждый экземпляр которого обладает общими для них и отличающими их от сущностей других классов свойствами; • систематизация представления, основанная на классах, в общем случае предполагает иерархическую зависимость типов: сущность А является подтипом сущности В, если каждый экземпляр типа А является экземпляром сущности типа В; • взаимосвязи объектов могут быть представлены как связи – сущности, которые служат для фиксирования (представления) взаимосвязанности двух или нескольких сущностей. Здесь следует еще раз подчеркнуть информационную природу понятия сущность и его соотношение с материальными или воображаемыми объектами предметной области. Любой объект предметной области обладает свойствами, часть из которых выделяется как характеристические – значимые с точки зрения прикладной задачи. При этом, например, в процессе анализа и систематизации предметной области обычно выделяются классы – совокупность объектов, обладающих одинаковым набором свойств, задаваемых в виде наборов атрибутов (значения атрибутов для объектов одного класса, естественно, могут различаться). Соответственно, на уровне представления предметной области (т.е. ее концептуальной модели) объекту, рассматриваемому как понятие (объект в сознании человека), соответствует понятие сущность; объекту как части материального мира (и существующему независимо от сознания человека) соответствует понятие экземпляр сущности; классу объектов соответствует понятие тип сущности. В дальнейшем, поскольку в концептуальной модели рассматриваются не отдельные экземпляры объектов, а классы, мы не будем различать соответствующие понятия этих двух уровней, т.е. будем предполагать тождественность понятий объект и сущность, свойство объекта и свойство сущности. ER-модель, как описание предметной области, должна определить объекты и взаимосвязи между ними, т.е. установить связи следующих двух типов. 1. Связи между объектами и наборами характеристических свойств, и таким образом определить сами объекты. 2. Связи между объектами, задающие характер и функциональную природу их взаимосвязанности. Сущность. Сущность, с помощью которой моделируется класс однотипных объектов, определяется как «предмет, который может быть четко идентифицирован». Также как каждый объект уникально характеризуется набором значений свойств, сущность должна определяться таким набором атрибутов, который позволял бы различать отдельные экземпляры сущностей. Каждый экземпляр сущности должен быть отличим от любого другого экземпляра той же сущности (это требование аналогично требованию отсутствия кортежей-дубликатов в реляционных таблицах). Например, для однозначной идентификации каждого экземпляра сущности «Сотрудник» вводится атрибут «Табельный номер», который вследствие своей природы будет всегда иметь уникальное значение в рамках предприятия. То есть, уникальным идентификатором сущности может являться атрибут, комбинация атрибутов, комбинация связей или комбинация связей и атрибутов, однозначно отличающая любой экземпляр сущности от других экземпляров сущности того же типа. Сущность имеет имя, уникальное в пределах модели. При этом имя сущности – это имя типа, а не некоторого конкретного экземпляра. Сущности подразделяются на сильные и слабые. Сущность является слабой, если ее существование зависит от другой сущности – сильной по отношению к ней. Например, сущность «Подчиненный» является слабой по отношению к сущности «Сотрудник»: если будет удалена запись, соответствующая некоторому сотруднику, имеющему подчиненных, то сведения о подчиненных также должны быть удалены. Свойства. Природа свойства, как и характер связи свойства с сущностью (объектом), может быть различной. Рассмотрим основные виды свойств. Свойство может быть множественным или единичным – т.е. атрибут, задающий свойство, может одновременно иметь несколько значений или, соответственно, только одно. Например, сотрудник может иметь несколько специальностей, но единственное значение – «Табельный номер». Свойство может быть простым (не подлежащим дальнейшему делению с точки зрения прикладных задач) или составным – если его значение составляется из значений простых свойств. Например, свойство «Год рождения» является простым, а свойство «Адрес» - составным, так как включает значения простых свойств «Город», «Улица», «Дом». В некоторых случаях полезно различать базовые и производные свойства. Например, «Поставщик» может иметь свойство «Общее количество поставляемых деталей», которое вычисляется суммированием количества деталей, поставляемых им по проекту. Если наличие некоторого свойства для всех экземпляров сущности не является обязательным, то такое свойство называется условным. Например, не все сотрудники обладают свойством «ученая степень». Значения свойств могут быть постоянными – статистическими или динамическими, т.е. меняться со временем. Например, свойство «табельный номер» является статическим, а «Адрес» - динамическим. Свойство может быть неопределенным, если оно является динамическим, но его текущее значение еще не задано. Свойство может рассматриваться как ключевое, если его значение уникально и, возможно, в определенном контексте, однозначно идентифицирует сущность. Например, подчиненный некоторого определенного сотрудника. Атрибут - в базах данных - имя или структура поля записи. Атрибут характеризует размер или тип информации, содержащейся в поле. Связи. Кроме связи между объектом и его свойствами, концептуальная модель отражает связи между объектами разных классов. Связь определяется как «ассоциация, объединяющая несколько сущностей». Эта ассоциация всегда может существовать между разными сущностями или между сущностью и ею же самой (рекурсивная связь). Как и сущность, связь является типовым понятием, т.е. все экземпляры связываемых сущностей подчиняются правилам связывания типов.  Сущности, объединяемые связями, называются участниками. Степень связи определяется количеством участников связи. Если каждый экземпляр сущности участвует, по крайней мере, в одном экземпляре связи, то такое участие этой сущности называется полным (или обязательным); в противном случае – неполным (или необязательным). Количественный характер участия сущностей (один или многие) задается типом связи (или мощностью связи). Возможны следующие типы: «один к одному» (1:1), «один ко многим» (1:М), «многие к одному» (М:1), «многие ко многим» (М:М).

10.8 Функціональні залежності. 1, 2 та 3 нормальні форми відношень.

8 Нормалізація відношень. 1 та 2 нормальні форми.

Нормализация – процесс разбиения отношения на несколько новых с целью устранения избыточности информации и аномалий обновления.

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

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

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

Потенциальный ключ [ключевой атрибут], состоящий из нескольких атрибутов, называется составным.

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

Первая нормальная форма (1НФ): каждая ячейка отношения содержит только атомарные значения атрибута

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

Приведение отношения к 1НФ:

Устранить повторяющиеся группы:

1 способ- ввести дубликаты неповторяющихся записей в пустые ячейки

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

Вторая нормальная форма (2НФ): отношение находится в 1НФ и все атрибуты полностью зависят от ключевых атрибутов

Приведение отношения к 2НФ:

Из отношения удаляются функционально-зависимые атрибуты и переносятся в новое отношение вместе с копией детерминантов. В новом отношении детерминанты становятся ключами

Пример. Таблица в 1-й нормальной форме:

Агентство недвижимости

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

Приведение этой таблицы ко второй нормальной форме.

Код клиента, код недвижимости → начало аренды, конец аренды [первичный ключ].

Код клиента → клиент [частичная зависимость].

Код недвижимости → адрес, плата, код владельца, владелец [частичная зависимость].

Код клиента, начало аренды → код недвижимости, адрес, конец аренды, код владельца, владелец [потенциальный ключ].

Код недвижимости, начало аренды → код клиента, конец аренды [потенциальный ключ].

Код владельца → владелец [транзитивная зависимость].

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

Клиент (код клиента, клиент)

Недвижимость (код клиента, код недвижимости, начало аренды, конец аренды)

Владелец (код недвижимости, адрес, …)

9 Нормалізація відношень. 3 нормальна форма та нормальна форма Бойса-Кодда. Навести приклади

Нормализация – процесс разбиения отношения на несколько новых с целью устранения избыточности информации и аномалий обновления.

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

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

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

Потенциальный ключ [ключевой атрибут], состоящий из нескольких атрибутов, называется составным.

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

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

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

Третья нормальная форма (3НФ):отношение находится в 1НФ и 2НФ, и в отношении нет неключевых атрибутов, находящихся в транзитивной зависимости от атрибутов первичного ключа

Приведение отношения к 3НФ: из отношения удаляются транзитивно-зависимые атрибуты и переносятся в новое отношение вместе с копией детерминантов. В новом отношении детерминанты становятся ключами.

Нормальная форма Бойса-Кодда (НФБК): отношение находится в НФБК тогда и только тогда, когда детерминанты всех функциональных зависимостей являются потенциальными ключами.

Отличие 3НФ и НФБК

В 3НФ допускается зависимость ключевого атрибута А от неключевого атрибута В. В НФБК все детерминанты должны быть потенциальными ключами.

НФБК применяется для отношений:

• с составными ключами

• потенциальные ключи имеют совместно- используемый атрибут

Приведение отношения к 3НФ:

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

При этом детерминанты отношений становятся потенциальными ключами

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

Собеседование с клиентом

Собеседование (КодКлиента, Дата, время, КодСотр, Комната) Функциональные зависимости отношения Собеседование

1ФЗ: КодКлиента, Дата® Сотрудник, Время, Комната(Первичный ключ)

2ФЗ: Сотрудник, Дата, Время ® КодКлиента (Потенциальный ключ)

3ФЗ: Комната, Дата, Время ® КодКлиента, Сотрудник (Потенциальный ключ)

4ФЗ: Сотрудник, Дата ® Комната (Зависимость между неключевыми атрибутами)

Атрибуты Сотрудник, Дата не являются потенциальным ключом, поэтому функционально-зависимые атрибуты Сотрудник, Дата ® Комната выносятся в отдельное отношение, причем детерминант Сотрудник, Дата становится ключом нового отношения.

Для соответствия НФБК отношение Собеседование с клиентом декомпозируется на два отношения:

Собеседование ( КодКлиента, Дата, Сотрудник, Время)

Занятость комнаты (Сотрудник, Дата, Комната)

Нормальные формы er-диаграмм

Как и в случае схем реляционных баз данных, для ER-диаграмм вводится понятие нормальных форм, причем их смысл очень близко соответствует смыслу нормальных форм отношений. Заметим, что определения нормальных форм ER-диаграмм делают более понятным смысл нормализации схем отношений. Мы приведем только очень краткие и неформальные определения трех первых нормальных форм. Конечно, можно было бы ввести дальнейшие нормальные формы ER-диаграмм, аналогичные нормальной форме Бойса-Кодда, 4NF и 5NF, но на практике к такой нормализации обычно не прибегают, а общие идеи после ознакомления с лекцией 8 должны быть понятны и так.

Первая нормальная форма er-диаграммы

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

На рис. 9.9 (a) показана диаграмма, в которой тип сущности   АЭРОДРОМ не удовлетворяет требованию первой нормальной формы. Здесь для нас несущественны атрибуты сущности   АВИАРЕМОНТНОЕ ПРЕДПРИЯТИЕ, но сущность   АЭРОДРОМ помимоатрибутов, отражающих собственные характеристики аэродромов (длина взлетно-посадочной полосы, число ангаров и т.д.) содержит атрибут, множественное значение которого характеризует самолеты, приписанные к этому аэродрому. Очевидно, что самолеты нуждаются в ремонте, т. е. должны обслуживаться некоторым авиаремонтным предприятием. Но поскольку самолеты являются частью сущности   АЭРОДРОМ, единственным способом фиксации этого факта на диаграмме является проведение связи "многие ко многим" между типами сущности   АЭРОДРОМ и АВИАРЕМОНТНОЕ ПРЕДПРИЯТИЕ. Таким образом выражается то соображение, что для ремонта разных самолетов, приписанных к одному аэродрому, могут использоваться разные транспортные предприятия, и каждое транспортное предприятие может обслуживать несколько аэродромов.

Рис. 9.9.  Пример приведения ER-диаграммы к первой нормальной форме

Чем плоха эта ситуация? Прежде всего, тем, что скрывается тот факт, что авиаремонтное предприятие ремонтирует самолеты, а не аэродромы. Наша же связь на самом деле означает, что любой аэродром из группы аэродромов обслуживается любым авиаремонтным предприятием из группы таких предприятий. Проблема состоит именно в том, что значением атрибута " самолеты " является множество экземпляров типа сущности   САМОЛЕТ, и этот тип сущности сам обладаетатрибутами и связями.

Ситуацию исправляет ER-диаграмма, показанная на рис. 9.9 (b). Здесь мы выделили тип сущности   САМОЛЕТ. Связь между сущностями   АЭРОДРОМ и САМОЛЕТпоказывает, что к одному аэродрому приписывается несколько самолетов. Связь между сущностями   САМОЛЕТ и АВИАРЕМОНТНОЕ ПРЕДПРИЯТИЕ означает, что каждый самолет из группы самолетов (группу самолетов могут составлять, например, все самолеты одного типа) обслуживается любым транспортным предприятием из некоторой группы таких предприятий. ER-диаграмма на рис. 9.9 (b) находится в первой нормальной форме и, как мы видим, лучше отображает реальную ситуацию.

Вторая нормальная форма er-диаграммы

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

На рис. 9.10 (a) показана диаграмма, на которой тип сущности   ЭЛЕМЕНТ РАСПИСАНИЯ не удовлетворяет требованиям второй нормальной формы. На этой диаграмме у сущности   ЭЛЕМЕНТ РАСПИСАНИЯ имеются следующие свойства. Элементы расписания предназначены для сохранения данных о рейсах самолетов, вылетающих в течение дня. Некоторыми важными характеристиками рейса являются номер рейса, аэропорт вылета, аэропорт назначения, дата и время вылета, бортовой номер самолета, тип самолета. Если говорить про российские авиационные компании, то (1) у каждого рейса имеется заранее приписанный ему номер (уникальный среди всех других имеющихся номеров рейсов), (2) не все рейсы совершаются каждый день, поэтому характеристикой конкретного рейса является дата и время его совершения, (3) бортовой номер самолета определяется парой <номер рейса, дата-время вылета>. Имеется связь "многие к одному" между сущностями   ЭЛЕМЕНТ РАСПИСАНИЯ и ГОРОД. Экземпляры типа сущности   ГОРОД характеризуют город, в который прибывает данный рейс.

Рис. 9.10.  Пример приведения ER-диаграммы ко второй нормальной форме

Уникальным идентификатором типа сущности   ЭЛЕМЕНТ РАСПИСАНИЯ является пара атрибутов   <номер рейса, дата-время вылета>. Если вернуться к терминам функциональных зависимостей, то между атрибутами этой сущности имеются следующие FD:

• {номер рейса, дата-время вылета}->бортовой номер самолета;

• номер рейса -> аэропорт вылета;

• номер рейса -> аэропорт назначения;

• бортовой номер самолета -> тип самолета.

Кроме того, очевидно, что каждый экземпляр связи с сущностью   ГОРОД также определяется значением атрибута   номер рейса. Налицо нарушение требованиявторой нормальной формы. Мы получаем не только избыточное хранение значений атрибутов   аэропорт вылета и аэропорт назначения в каждом экземпляре типа сущности   ЭЛЕМЕНТ РАСПИСАНИЯ с одним и тем же значением номера рейса. Искажается и затемняется смысл связи с сущностью   ГОРОД. Можно подумать, что в разные дни один и тот же рейс прибывает в разные города.

На рис. 9.10 (b) показан нормализованный вариант диаграммы, в котором все сущности находятся во второй нормальной форме. Теперь имеются три типа сущности: РЕЙС с атрибутами   номер рейса, аэропорт вылета, аэропорт назначения, ЭЛЕМЕНТ РАСПИСАНИЯ с атрибутами   дата-время вылета, бортовой номер самолета, тип самолета и ГОРОД. Уникальным идентификатором сущности РЕЙС является атрибут   номер рейса, уникальный идентификатор   ЭЛЕМЕНТ РАСПИСАНИЯсостоит из атрибута   дата вылета и конца связи   КОГДА, НА ЧЕМ. Мы видим, что ни в одном типе сущности больше нет атрибутов, определяемых частьюуникального идентификатора. Свойства второй нормальной формы удовлетворяются, и мы имеем более качественную диаграмму.

Третья нормальная форма er-диаграммы

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

Взглянем еще раз на тип сущности   ЭЛЕМЕНТ РАСПИСАНИЯ на рис. 9.10 (b). Конечно, каждый день каждый рейс выполняется только одним самолетом, поэтомубортовой номер самолета полностью зависит от уникального идентификатора. Но бортовой номер является уникальной характеристикой каждого самолета, и от этой характеристики зависят все остальные характеристики, в частности тип самолета. Другими словами, между уникальным идентификатором и другимиатрибутами   типа сущности   ЭЛЕМЕНТ РАСПИСАНИЯ имеются следующие функциональные зависимости:

{КОГДА, НА ЧЕМ, дата-время вылета}->бортовой номер самолета

{КОГДА, НА ЧЕМ, дата-время вылета}->тип самолета

бортовой номер самолета->тип самолета

Как видно, имеется транзитивная FD { КОГДА, НА ЧЕМ, дата вылета }   тип самолета, и наличие этой FD вызывает нарушение требования третьей нормальной формы. На самом деле, тип сущности   ЭЛЕМЕНТ РАСПИСАНИЯ на рис. 9.10 (b) включает в себя (по крайней мере, частично) тип сущности   САМОЛЕТ. Это вызывает избыточность хранения и затуманивает смысл диаграммы. На рис. 9.11 показан нормализованный вариант диаграммы, в котором все сущности находятся в третьей нормальной форме.

Рис. 9.11.  Пример приведения ER-диаграммы к третьей нормальной форме

Семантическая модель Entity-Relationship (Сущность-Связь)

В этой лекции мы кратко рассмотрим некоторые черты одной из наиболее популярных семантических моделей данных –модель "Сущность-Связь" (часто ее называют кратко ER-моделью от Entity-Relationship ).

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

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

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

На использовании разных вариантов ER-модели основано большинство современных подходов к проектированию баз данных (главным образом, реляционных). Модель была предложена Питером Ченом (Peter Chen) в 1976 г. Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов. Простота и наглядность представления концептуальных схем баз данных в ER-модели привели к ее широкому распространению в CASE-системах, поддерживающих автоматизированное проектирование реляционных баз данных. Среди множества разновидностей ER-моделей одна из наиболее популярных и развитых применялась в системе CASE компании Oracle. Мы обсудим некоторый упрощенный вариант этой модели. Если говорить более точно, сосредоточимся на ее структурной и целостной частях.

Основные понятия er-модели

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

Рис. 9.1.  Пример типа сущности

На рис. 9.1 изображена сущность   АЭРОПОРТ с примерными экземплярами "Шереметьево" и "Хитроу". Эта примитивная диаграмма тем не менее несет важную информацию. Во-первых, она показывает, что в базе данных будут содержаться однотипные структуры данных ( экземпляры сущности ), описывающие аэропорты. Во-вторых, поскольку в жизни существует несколько точек зрения на аэропорты (например, точка зрения пилота, точка зрения пассажира, точка зрения администратора) и этим точкам зрения соответствуют разные структуры данных, то приведенные примеры аэропортов позволяют несколько сузить допустимый набор точек зрения. В нашем случае приведены примеры международных аэропортов, так что, скорее всего, имеется точка зрения пассажира или пилота международных авиарейсов.

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

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

Связь представляется в виде ненаправленной линии, соединяющей две сущности или ведущей от сущности к ней же самой. При этом в месте "стыковки" связи ссущностью используются:

• трехточечный вход в прямоугольник сущности, если для этой сущности в связи могут (или должны) использоваться много ( many ) экземпляров сущности ;

• одноточечный вход, если в связи может (или должен) участвовать только один экземпляр сущности.

Обязательный конец связи изображается сплошной линией, а необязательный – прерывистой линией.

Связь между сущностями   БИЛЕТ и ПАССАЖИР, показанная на рис. 9.2, связывает билеты и пассажиров. Конец связи с именем "для" позволяет связывать с одним пассажиром более одного билета, причем каждый билет должен быть связан с каким-либо пассажиром. Конец связи с именем "имеет" показывает, что каждый билет может принадлежать только одному пассажиру, причем пассажир не обязан иметь хотя бы один билет.

Рис. 9.2.  Пример типа связи

Лаконичная устная трактовка изображенной диаграммы состоит в следующем:

• каждый БИЛЕТ предназначен для одного и только одного ПАССАЖИРА ;

• каждый ПАССАЖИР может иметь один или более БИЛЕТОВ или не иметь вовсе.

На следующем примере (рис. 9.3) изображена рекурсивная связь, связывающая сущность   МУЖЧИНА с ней же самой. Конец связи с именем " сын " определяет тот факт, что несколько людей могут быть сыновьями одного отца. Конец связи с именем " отец " означает, что не у каждого мужчины должны быть сыновья.

Рис. 9.3.  Пример рекурсивного типа связи

Лаконичная устная трактовка изображенной диаграммы состоит в следующем:

• каждый МУЖЧИНА является сыном одного и только одного МУЖЧИНЫ ;

• каждый МУЖЧИНА может являться отцом одного или более МУЖЧИН.

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

Пример типа сущности   ЧЕЛОВЕК с указанными атрибутами показан на рис. 9.4. С технической точки зрения атрибуты   типа сущности в ER-модели похожи наатрибуты отношения в реляционной модели данных. И в том, и в другом случаях введение именованных атрибутов вводит некоторую типовую структуру данных, имя которой совпадает с именем типа сущности в случае ER-модели или с именем переменной отношения в случае реляционной модели. Этой типовой структуре должны следовать все экземпляры типа сущности или все кортежи отношения. Но имеется и важное отличие. Напомним, что в реляционной модели данных атрибутопределяется как упорядоченная пара <имя_атрибута, имя_домена> (или <имя_атрибута, имя_базового_типа_данных>, если понятие домена не поддерживается). Заголовок отношения, определяемый как множество таких пар, представляет собой полный аналог структурного типа данных в языках программирования.

Рис. 9.4.  Пример типа сущности с атрибутами

При определении атрибутов   типа сущности в ER-модели указание домена атрибута не является обязательным, хотя это и возможно (см. ниже). Обсудим, чем вызвана эта возможность "ослабленного" определения атрибутов. Прежде всего, как отмечалось в разделе "Введение", семантические модели данных используются для построения концептуальных схем БД, и эти схемы преобразуются в реляционные схемы БД, которые поддерживаются той или иной СУБД. Несмотря на то что в настоящее время типовые возможности РСУБД в основном стандартизованы (на основе стандарта языка SQL), детали базового набора типов данных и средств определения доменов в разных системах могут различаться. Поскольку производители CASE-средств проектирования реляционных БД стремятся не связывать обеспечиваемые ими возможности семантического моделирования с конкретной реализацией СУБД, они стимулируют откладывание строгого определения типоватрибутов до стадии полного определения реляционной схемы.

Кроме того, напомним, что при определении атрибута отношения допускается использование имен атрибутов, совпадающих с именами своих доменов (это два разных пространства имен, и наличие одинаковых имен у атрибутов и доменов не вызывает коллизий). Поэтому при определении атрибутов   типов сущности можно так подбирать их имена, что они в дальнейшем будут подсказывать, какие домены у этих атрибутов имеются в виду. Пониманию предполагаемой сути доменов способствует и возможность указания примеров значений атрибутов. Например, на рис. 9.4 имеется атрибут   год рождения, в качестве примерного значения которого указано " 1976 ". Это подсказывает, что в реляционной схеме при определении соответствующего атрибута наиболее естественным базовым типом данных будет темпоральный тип " ДАТА ", значения которого задают дату с точностью до года.

Уникальные идентификаторы типов сущности

Как отмечалось выше, при определении типа сущности необходимо гарантировать, что каждый экземпляр сущности является отличимым от любого другого экземпляра той же сущности. Поскольку сущность является абстракцией реального или представляемого объекта внешнего мира, это требование нужно иметь в виду уже при выборе кандидата в типы сущности. Например, предположим, что проектируется база данных для поддержки работы книжного склада. На складе могут храниться произвольные части тиража любого издания любой книги. Может ли в этом случае индивидуальная книга являться прообразом типа сущности? Утверждается, что нет, поскольку отсутствует возможность различения книг одного издания. Для книжного склада прообразом типа сущности будет набор одноименных книг одного автора, вышедших в одном издании. Одним из атрибутов этого типа сущности будет число книг в наборе. Но когда книга поступает в библиотеку и ей присваивается уникальный библиотечный номер, она становится разумным прообразом типа сущности. Плохо устроены библиотеки, в которых не различаются индивидуальные книги (даже одноименные книги одного автора, вышедшие в одном издании).

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

Приведем несколько примеров. На рис. 9.5 показан тип сущности   КНИГА, пригодный для использования в базе данных книжного склада. При издании любой книги в любом издательстве (кроме пиратских, которыми мы для простоты пренебрежем) ей присваивается уникальный номер – ISBN. Понятно, что значение атрибута   isbn будет уникально идентифицировать партию книг на складе. Кроме того, конечно, в качестве уникального идентификатора годится и комбинация атрибутов   <автор, название, номер издания, издательство, год издания>.

Рис. 9.5.  Тип сущности, экземпляры которого идентифицируются атрибутами

На рис. 9.6 диаграмма включает два связанных типа сущности. У каждого взрослого человека имеется один и только один паспорт (мы снова не берем в расчет особый случай, когда у одного человека имеется несколько паспортов), и каждый паспорт может принадлежать только одному взрослому человеку (некоторые уже готовые паспорта могут быть еще никому не выданы). Тогда связь человека с его паспортом ( конец связи   ИМЕЕТ ) уникально идентифицирует взрослого человека, т. е., грубо говоря, паспорт определяет взрослого человека. Поскольку могут существовать паспорта, еще не выданные какому-либо человеку, этасвязь не является уникальным идентификатором сущности   ПАСПОРТ.

Рис. 9.6.  Тип сущности, экземпляры которого идентифицируются связью

На рис. 9.7 диаграмма включает три связанных типа сущности. Профессора обладают знаниями в нескольких учебных дисциплинах. Преподавание каждой дисциплины доступно нескольким профессорам. Другими словами, между сущностями   ПРОФЕССОР и ДИСЦИПЛИНА определена связь "многие ко многим". Каждый профессор может готовить курсы по любой доступной ему дисциплине. Каждой дисциплине может быть посвящено несколько учебных курсов. Но каждый профессор может готовить только один курс по любой доступной ему дисциплине, и каждый курс может быть посвящен только одной дисциплине. Тем самым, каждый экземпляр типа сущности   КУРС уникально идентифицируется экземпляром сущности   ПРОФЕССОР и экземпляром сущности   ДИСЦИПЛИНА, т. е. паройсвязей с именами концов   ГОТОВИТСЯ и ПОСВЯЩЕН на стороне сущности   КУРС. Заметим, что сущности   ПРОФЕССОР и ДИСЦИПЛИНА   связями не идентифицируются.

Рис. 9.7.  Тип сущности, экземпляры которого идентифицируются комбинацией связей

Наконец, на рис. 9.8 приведен пример типа сущности, уникальный идентификатор которого является комбинацией атрибутов и связей. Это несколько уточненный вариант сущности с рекурсивной связью с рис. 9.3. У каждого человека могут быть дети, и у каждого человека имеется отец. Тогда, если предположить, что близнецам, появившимся на свет одновременно, не дают одинаковых имен, то уникальным идентификатором типа сущности   ЧЕЛОВЕК может быть комбинацияатрибутов   <дата рождения, ФИО> и связь с именем конца   РЕБЕНОК.

Рис. 9.8.  Тип сущности, экземпляры которого идентифицируются комбинацией атрибутов и свіязей

Нормальные формы er-диаграмм

Как и в случае схем реляционных баз данных, для ER-диаграмм вводится понятие нормальных форм, причем их смысл очень близко соответствует смыслу нормальных форм отношений. Заметим, что определения нормальных форм ER-диаграмм делают более понятным смысл нормализации схем отношений. Мы приведем только очень краткие и неформальные определения трех первых нормальных форм. Конечно, можно было бы ввести дальнейшие нормальные формы ER-диаграмм, аналогичные нормальной форме Бойса-Кодда, 4NF и 5NF, но на практике к такой нормализации обычно не прибегают, а общие идеи после ознакомления с лекцией 8 должны быть понятны и так.

Первая нормальная форма er-диаграммы

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

На рис. 9.9 (a) показана диаграмма, в которой тип сущности   АЭРОДРОМ не удовлетворяет требованию первой нормальной формы. Здесь для нас несущественны атрибуты сущности   АВИАРЕМОНТНОЕ ПРЕДПРИЯТИЕ, но сущность   АЭРОДРОМ помимоатрибутов, отражающих собственные характеристики аэродромов (длина взлетно-посадочной полосы, число ангаров и т.д.) содержит атрибут, множественное значение которого характеризует самолеты, приписанные к этому аэродрому. Очевидно, что самолеты нуждаются в ремонте, т. е. должны обслуживаться некоторым авиаремонтным предприятием. Но поскольку самолеты являются частью сущности   АЭРОДРОМ, единственным способом фиксации этого факта на диаграмме является проведение связи "многие ко многим" между типами сущности   АЭРОДРОМ и АВИАРЕМОНТНОЕ ПРЕДПРИЯТИЕ. Таким образом выражается то соображение, что для ремонта разных самолетов, приписанных к одному аэродрому, могут использоваться разные транспортные предприятия, и каждое транспортное предприятие может обслуживать несколько аэродромов.

Рис. 9.9.  Пример приведения ER-диаграммы к первой нормальной форме

Чем плоха эта ситуация? Прежде всего, тем, что скрывается тот факт, что авиаремонтное предприятие ремонтирует самолеты, а не аэродромы. Наша же связь на самом деле означает, что любой аэродром из группы аэродромов обслуживается любым авиаремонтным предприятием из группы таких предприятий. Проблема состоит именно в том, что значением атрибута " самолеты " является множество экземпляров типа сущности   САМОЛЕТ, и этот тип сущности сам обладаетатрибутами и связями.

Ситуацию исправляет ER-диаграмма, показанная на рис. 9.9 (b). Здесь мы выделили тип сущности   САМОЛЕТ. Связь между сущностями   АЭРОДРОМ и САМОЛЕТпоказывает, что к одному аэродрому приписывается несколько самолетов. Связь между сущностями   САМОЛЕТ и АВИАРЕМОНТНОЕ ПРЕДПРИЯТИЕ означает, что каждый самолет из группы самолетов (группу самолетов могут составлять, например, все самолеты одного типа) обслуживается любым транспортным предприятием из некоторой группы таких предприятий. ER-диаграмма на рис. 9.9 (b) находится в первой нормальной форме и, как мы видим, лучше отображает реальную ситуацию.

Вторая нормальная форма er-диаграммы

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

На рис. 9.10 (a) показана диаграмма, на которой тип сущности   ЭЛЕМЕНТ РАСПИСАНИЯ не удовлетворяет требованиям второй нормальной формы. На этой диаграмме у сущности   ЭЛЕМЕНТ РАСПИСАНИЯ имеются следующие свойства. Элементы расписания предназначены для сохранения данных о рейсах самолетов, вылетающих в течение дня. Некоторыми важными характеристиками рейса являются номер рейса, аэропорт вылета, аэропорт назначения, дата и время вылета, бортовой номер самолета, тип самолета. Если говорить про российские авиационные компании, то (1) у каждого рейса имеется заранее приписанный ему номер (уникальный среди всех других имеющихся номеров рейсов), (2) не все рейсы совершаются каждый день, поэтому характеристикой конкретного рейса является дата и время его совершения, (3) бортовой номер самолета определяется парой <номер рейса, дата-время вылета>. Имеется связь "многие к одному" между сущностями   ЭЛЕМЕНТ РАСПИСАНИЯ и ГОРОД. Экземпляры типа сущности   ГОРОД характеризуют город, в который прибывает данный рейс.

Рис. 9.10.  Пример приведения ER-диаграммы ко второй нормальной форме

Уникальным идентификатором типа сущности   ЭЛЕМЕНТ РАСПИСАНИЯ является пара атрибутов   <номер рейса, дата-время вылета>. Если вернуться к терминам функциональных зависимостей, то между атрибутами этой сущности имеются следующие FD:

• {номер рейса, дата-время вылета}->бортовой номер самолета;

• номер рейса -> аэропорт вылета;

• номер рейса -> аэропорт назначения;

• бортовой номер самолета -> тип самолета.

Кроме того, очевидно, что каждый экземпляр связи с сущностью   ГОРОД также определяется значением атрибута   номер рейса. Налицо нарушение требованиявторой нормальной формы. Мы получаем не только избыточное хранение значений атрибутов   аэропорт вылета и аэропорт назначения в каждом экземпляре типа сущности   ЭЛЕМЕНТ РАСПИСАНИЯ с одним и тем же значением номера рейса. Искажается и затемняется смысл связи с сущностью   ГОРОД. Можно подумать, что в разные дни один и тот же рейс прибывает в разные города.

На рис. 9.10 (b) показан нормализованный вариант диаграммы, в котором все сущности находятся во второй нормальной форме. Теперь имеются три типа сущности: РЕЙС с атрибутами   номер рейса, аэропорт вылета, аэропорт назначения, ЭЛЕМЕНТ РАСПИСАНИЯ с атрибутами   дата-время вылета, бортовой номер самолета, тип самолета и ГОРОД. Уникальным идентификатором сущности РЕЙС является атрибут   номер рейса, уникальный идентификатор   ЭЛЕМЕНТ РАСПИСАНИЯсостоит из атрибута   дата вылета и конца связи   КОГДА, НА ЧЕМ. Мы видим, что ни в одном типе сущности больше нет атрибутов, определяемых частьюуникального идентификатора. Свойства второй нормальной формы удовлетворяются, и мы имеем более качественную диаграмму.

Третья нормальная форма er-диаграммы

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

Взглянем еще раз на тип сущности   ЭЛЕМЕНТ РАСПИСАНИЯ на рис. 9.10 (b). Конечно, каждый день каждый рейс выполняется только одним самолетом, поэтомубортовой номер самолета полностью зависит от уникального идентификатора. Но бортовой номер является уникальной характеристикой каждого самолета, и от этой характеристики зависят все остальные характеристики, в частности тип самолета. Другими словами, между уникальным идентификатором и другимиатрибутами   типа сущности   ЭЛЕМЕНТ РАСПИСАНИЯ имеются следующие функциональные зависимости:

{КОГДА, НА ЧЕМ, дата-время вылета}->бортовой номер самолета

{КОГДА, НА ЧЕМ, дата-время вылета}->тип самолета

бортовой номер самолета->тип самолета

Как видно, имеется транзитивная FD { КОГДА, НА ЧЕМ, дата вылета }   тип самолета, и наличие этой FD вызывает нарушение требования третьей нормальной формы. На самом деле, тип сущности   ЭЛЕМЕНТ РАСПИСАНИЯ на рис. 9.10 (b) включает в себя (по крайней мере, частично) тип сущности   САМОЛЕТ. Это вызывает избыточность хранения и затуманивает смысл диаграммы. На рис. 9.11 показан нормализованный вариант диаграммы, в котором все сущности находятся в третьей нормальной форме.

Рис. 9.11.  Пример приведения ER-диаграммы к третьей нормальной форме

10.9 Багатозначні залежності та залежності з’єднання. 4 та 5 нормальні форми відношень.

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

В отношении R(A,B,C) атрибут B многозначно зависит от атрибута A (имеет место многозначная зависимость атрибута B от атрибута A) тогда и только тогда, когда множество значений B для каждой пары значений (A, C) зависит только от A (не зависит от B). Обозначение: A=>B.

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

Видно, что данное определение подразумевает также независимость C от B (так как должны быть все возможные комбинации B,C), что означает многозначную зависимость C от A в рассматриваемом отношении R.

Таким образом, многозначные зависимости всегда встречаются парами (формально C может быть пустым атрибутом), и для записи таких пар используется обозначение: A=>B | С.

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

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

Группа->Студент | День Очевидно, что множество студентов и множество учебных дней никак между собой не связаны, а определяются только значением Группы.

В отношении R многозначная зависимость A=>B называется тривиальной, если B входит в состав A или R = (А,B). Иначе зависимость называется нетривиальной.

Так, тривиальной являются многозначные зависимости: а) Группа=>Студент в отношении Список (Студент, Группа) : Список=(Студент, Группа); б) Группа, Студент => Студент (Студент входит в [Группа, Студент])

9.3. Зависимости проекции/соединения и пятая нормальная форма

Приведение отношения к 4NF предполагает его декомпозицию без потерь на две проекции (как и в случае 2NF, 3NF и BCNF). Однако бывают (хотя и нечасто) случаи, когда декомпозиция без потерь на две проекции невозможна, но можно произвести декомпозицию без потерь на большее число проекций. Будем называть n-декомпозируемым отношением отношение, которое может быть декомпозировано без потерь на n проекций. До сих пор мы имели дело с 2-декомпозируемыми отношениями.

9.3.1. N-декомпозируемые отношения

Начнем с еще одного определения.

В переменной отношения R с атрибутами (возможно, составными) A и B MVD A B называетсятривиальной, если либо A B, либо A UNION B совпадает с заголовком отношения R.

Тривиальная MVD всегда удовлетворяется. При A B она вырождается в тривиальную FD. В случае A UNION B = H_R требования многозначной зависимости соблюдаются очевидным образом.

Для примера n-декомпозируемого отношения при n > 2 рассмотрим пятый вариант переменной отношения СЛУЖ_ПРО_ЗАДАН, в которой имеется единственно возможный ключ {СЛУ_НОМ, ПРО_НОМ, СЛУ_ЗАДАН} и отсутствуют нетривиальные MVD. Пример значения переменной отношения приведен нарис. 9.3.

Как показано на рис. 9.3, результат естественного соединения проекций СЛУЖ_ПРО_НОМ и ПРО_НОМ_ЗАДАНпочти совпадает с телом исходного отношения СЛУЖ_ПРО_ЗАДАН, но в нем присутствует один лишний кортеж, который исчезнет после выполнения заключительного естественного соединения с проекциейСЛУЖ_ЗАДАНИЕ. Читателям предлагается убедиться, что исходное отношение будет восстановлено при любом порядке естественного соединения трех проекций.

9.3.2. Зависимость проекции/соединения

Утверждение о том, что значение отношения СЛУЖ_ПРО_ЗАДАН восстанавливается без потерь путем естественного соединения его проекций СЛУЖ_ПРО_НОМ, ПРО_НОМ_ЗАДАН и СЛУЖ_ЗАДАНИЕ эквивалентно следующему утверждению (B_СПЗ, B_СПН, B_ПНЗ и B_СЗ обозначают тела значений переменных отношенийСЛУЖ_ПРО_ЗАДАН, СЛУЖ_ПРО_НОМ, ПРО_НОМ_ЗАДАН и СЛУЖ_ЗАДАНИЕ соответственно):

IF ({сн, пн} B_СПН AND {пн, сз} B_СПЗ AND {сн, сз} B_СЗ)

THEN {сн, пн, сз} B_СПЗ

Чтобы возможность восстановления без потерь отношения СЛУЖ_ПРО_ЗАДАН путем естественного соединения его проекций СЛУЖ_ПРО_НОМ, ПРО_НОМ_ЗАДАН и СЛУЖ_ЗАДАНИЕ существовала при любом допустимом значении переменной отношения СЛУЖ_ПРО_ЗАДАН, должно поддерживаться следующее ограничение:

IF ({сн₁, пн₁, сз₂} B_СПЗ AND {сн₂, пн₁, сз₁} B_СПЗ

AND {сн₁, пн₂, сз₁} B_СПЗ)

THEN {сн₁, пн₁, сз₁} B_СПЗ

Это обычное ограничение реального мира, которое для отношения СЛУЖ_ПРО_ЗАДАН может быть сформулировано на естественном языке следующим образом:

Если служащий с номером сн участвует в проекте пн, и в проекте пн выполняется задание сз, и служащий с номером сн выполняет задание сз, то служащий с номером сн выполняет задание сз в проекте пн.

В общем виде такое ограничение называется зависимостью проекции/соединения. Вот формальное определение.

Пусть задана переменная отношения R, и A, B, …, Z являются произвольными подмножествами заголовка R (составными, перекрывающимися атрибутами). В переменной отношения R удовлетворяетсязависимость проекции/соединения (Project-Join Dependency – PJD) *( A, B, …, Z) тогда и только тогда, когда любое допустимое значение r переменной отношения R можно получить путем естественного соединения проекций этого значения на атрибуты A, B, …, Z.

  Рис. 9.3.  Возможное значение переменной отношения СЛУЖ_ПРО_ЗАДАН (пятый вариант), результаты проекций и результат частичного естественного соединения

9.3.3. Аномалии, вызываемые наличием зависимости проекции/соединения

В переменной отношения СЛУЖ_ПРО_ЗАДАН выполняется PJD *({СЛУ_НОМ, ПРО_НОМ}, {ПРО_НОМ, СЛУ_ЗАДАН}, {СЛУ_НОМ, СЛУ_ЗАДАН}). Наличие такой PJD обеспечивает возможность декомпозиции отношения на три проекции, но возникает вопрос, зачем это нужно? Чем плохо исходное отношениеСЛУЖ_ПРО_ЗАДАН? Ответ обычный: этому отношению свойственны аномалии обновления. Для примера предположим, что значением СЛУЖ_ПРО_ЗАДАН является отношение, показанное на рис. 9.4.

• Добавление кортежей. Если к ТСПЗ1 (рис. 9.4) добавляется кортеж <2941, 1, A>, то должен быть добавлен и кортеж <2934, 1, A>. Действительно, в теле отношения появятся кортежи <2934, 1, B>, <2941, 1, A> и <2934, 2, A>. Ограничение целостности требует включения и кортежа <2934, 1, A>. Интересно, что добавление кортежа <2934, 1, A> не нарушает ограничение целостности и, тем самым, не требует добавления кортежа <2941, 1, A>.

  Рис. 9.4.  Иллюстрации аномалий обновления в отношении СЛУЖ_ПРО_ЗАДАН при наличии зависимости соединения

• Удаление кортежа. Если из ТСПЗ2 удаляется кортеж <2934, 1, A>, то должен быть удален и кортеж<2941, 1, A>, поскольку в соответствии с ограничением целостности наличие второго кортежа означает наличие первого. Интересно, что удаление кортежа <2941, 1, A> не нарушает ограничения целостности и не требует дополнительных удалений.

9.3.4. Устранение аномалий обновления в 3-декомпозиции

После выполнения декомпозиции трудности с обновлением автоматически снимаются. Действительно, декомпозируем отношение СЛУЖ_ПРО_ЗАДАН на три отношения: СЛУЖ_ПРО_НОМ {СЛУ_НОМ, ПРО_НОМ},СЛУЖ_ЗАДАНИЕ {СЛУ_НОМ, СЛУ_ЗАДАН} и ПРО_НОМ_ЗАДАН {ПРО_НОМ, СЛУ_ЗАДАН}. Результат декомпозиции значения переменной отношения СЛУЖ_ПРО_ЗАДАН с телом B_СПЗ1 показан в верхней части рис. 9.5.

Теперь если мы хотим добавить данные о служащем с номером 2941, выполняющем задание A в проекте1, то, естественно, вставим кортеж <2941, 1> в отношение СОТР-ПРО_НОМ, кортеж <2941, A> в отношениеСОТР-ЗАДАНИЕ и кортеж <1, A> в отношение ПРО_НОМ-ЗАДАН. Результат этих операций показан в средней части рис. 9.5.

Но если выполнить естественное соединение декомпозированных отношений с телами, полученными после добавления данных о служащем с номером 2941, выполняющем задание A в проекте 1, то будет получено значение-отношение с заголовком отношения СЛУЖ_ПРО_ЗАДАН и телом B_СПЗ2 (нижняя часть рис. 9.5). Тем самым, проведенная декомпозиция позволила избежать сложностей при выполнении добавления кортежей с получением корректных результатов.

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

2.5.5. Пятая нормальная форма

Подойдем к обсуждению понятия "многозначная зависимость" с другой стороны. Чисто формально, отношение, представленное на рис. 33, имеет две многозначные зависимости:

Дисциплина  Преподаватель и Дисциплина  Вид_работы.

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

Любая дисциплина, считается освоенной студентом, если он выполнил все Виды_работ, предписанные для данной дисциплины учебным планом. Например, чтобы "закрыть" дисциплину "Базы данных", необходимо пройти следующие виды занятий и испытаний (Виды_работ): {лекции, практика, зачет, курсовой проект, экзамен}, которые обязательны для этой дисциплины, вне зависимости от преподавателей, ведущих данную дисциплину.

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

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

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

Поясним сказанное на примере. Пусть имеется отношение ТЕХНОЛОГИЧЕСКАЯ_КАРТА (Деталь, Материал, Технология), состояние которого имеет вид, показанный на рис. 34.

Рис. 34. Состояние отношения ТЕХНОЛОГИЧЕСКАЯ_КАРТА

Пусть, далее, заданы следующие "вариантные" зависимости (для обозначения таких зависимостей будет использоваться обозначение  ):

Деталь   Материал, Деталь   Технология, Материал   Технология.

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

Используя эти три "вариантные" зависимости, можно однозначно построить отношение: ТЕХНОЛОГИЧЕСКАЯ_КАРТА (Деталь, Материал, Технология) из следующих его проекций (рис. 35 - 37):

Следующее предложение реляционной алгебры [30]:

ТЕХНОЛОГИЧЕСКАЯ_КАРТА(Деталь, Материал, Технология) = (ДЕТАЛЬ_МАТЕРИАЛ [Деталь=Деталь] ДЕТАЛЬ_ТЕХНОЛОГИЯ) [(Материал=Материал) AND (Технология=Технология)] МАТЕРИАЛ_ТЕХНОЛОГИЯ

восстанавливает исходное отношение ТЕХНОЛОГИЧЕСКАЯ_КАРТА (рис. 34). Следует отметить, что приведенное предложение должно быть зафиксировано в системе (в схеме базы данных), т. к. оно описывает существующее в предметной области ограничение и указывает, каким образом могут быть соединены отношения.

При реализации данного утверждения, система, выполняя соединение ТЕХНОЛОГИЧЕСКАЯ_КАРТА(Деталь, Материал, Технология) = ДЕТАЛЬ_МАТЕРИАЛ [Деталь=Деталь] ДЕТАЛЬ_ТЕХНОЛОГИЯ, получит в промежуточном отношении ТЕХНОЛОГИЧЕСКАЯ_КАРТА_R лишние строки t2 и t3 (рис. 38), запрещенные многозначной зависимостью Материал Технология (рис. 36).

Рис. 38. Состояние отношения ТЕХНОЛОГИЧЕСКАЯ_КАРТА_R

Строки t2 и t3 из отношения ТЕХНОЛОГИЧЕСКАЯ_КАРТА_R исключаются частью предложения: ТЕХНОЛОГИЧЕСКАЯ_КАРТА_R [(Материал=Материал) AND (Технология=Технология)] МАТЕРИАЛ_ТЕХНОЛОГИЯ

Если рассмотренное утверждение реляционной алгебры выполняется всегда (для всех допустимых значений отношения ТЕХНОЛОГИЧЕСКАЯ_КАРТА), то тем самым формируется независимое от времени ограничение, присущее отношению ТЕХНОЛОГИЧЕСКАЯ_КАРТА, которое должно быть отображено в схеме базы данных. К сожалению, стандарт SQL не содержит правил поддержания подобных ограничений.

Отметим, что также явно должно быть указано ограничение для соединения отношений ДЕТАЛЬ_МАТЕРИАЛ(Деталь, Материал) и МАТЕРИАЛ_ТЕХНОЛОГИЯ(Материал,Технология), иначе без такого ограничения из базы данных может быть получена информация, не соответствующая действительности. В частности, результатом запроса

SELECT * FROM ДЕТАЛЬ_МАТЕРИАЛ, МАТЕРИАЛ_ТЕХНОЛОГИЯ WHERE ДЕТАЛЬ_МАТЕРИАЛ.Деталь = МАТЕРИАЛ_ТЕХНОЛОГИЯ.Деталь;

будет отношение, показанное на рис. 39.

Рис. 39. Ловушка соединения отношений ДЕТАЛЬ_МАТЕРИАЛ и МАТЕРИАЛ_ТЕХНОЛОГИЯ

В полученном отношении присутствуют кортежи t2 и t5, которые отсутствуют в правильном ответе (рис. 34). Заметьте, что запрос на языке SQL синтаксически не противоречит правилам языка. Поэтому пользователь вправе считать, что выданный результат соответствует действительности.

Подобная проблема может возникнуть при запросе к базе данных к отношениям, представленным на рис. 36 и 37.

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

Отношения: ДЕТАЛЬ_МАТЕРИАЛ(Деталь, Материал), МАТЕРИАЛ_ТЕХНОЛОГИЯ(Материал, Технология), ДЕТАЛЬ_ТЕХНОЛОГИЯ(Деталь, Технология), Правила восстановления: ТЕХНОЛОГИЧЕСКАЯ_КАРТА (Деталь, Материал, Технология)= (ДЕТАЛЬ_МАТЕРИАЛ [Деталь=Деталь] ДЕТАЛЬ_ТЕХНОЛОГИЯ) [(Материал=Материал) AND (Технология=Технология)] МАТЕРИАЛ_ТЕХНОЛОГИЯ, ТЕХНОЛОГИЧЕСКАЯ_КАРТА (Деталь, Материал, Технология)= (ДЕТАЛЬ_ТЕХНОЛОГИЯ [Технология=Технология] МАТЕРИАЛ_ТЕХНОЛОГИЯ) [(Деталь=Деталь) AND (Материал=Материал)] ДЕТАЛЬ_МАТЕРИАЛ, ТЕХНОЛОГИЧЕСКАЯ_КАРТА (Деталь, Материал, Технология)= (ДЕТАЛЬ_МАТЕРИАЛ [Материал=Материал] МАТЕРИАЛ_ТЕХНОЛОГИЯ) [(Деталь=Деталь) AND (Технология=Технология)] ДЕТАЛЬ_ТЕХНОЛОГИЯ.  Рис. 40. Схема базы данных и правила восстановления исходного отношения

Заметим, что если исходное отношение ТЕХНОЛОГИЧЕСКАЯ_КАРТА (рис. 34) не разбивать на проекции, то возможны аномалии при модификации отношения. Это несложно доказать, в силу чего такое доказательство оставляется читателю в качестве упражнения.

Рассмотрим еще один случай зависимости соединения.

Пусть имеются три проекции (рис. 41) некоторого исходного отношения R (рис. 42):

Рис. 41. Состояния проекций отношения R

Тогда, если правило восстановления исходного отношения R(A, B, C) записано формулой:

R=(R1 [A=A] R2) if [B=B AND C=C] R3,

то в результирующее отношение должны попасть такие кортежи из R1 и R2 по операции эквисоединения на атрибуте A, у которых проекции по атрибутам В и C есть в отношении R3.

Истинный результат R, получаемый после удаления ложных выборок из эквисоединения R' показан на рис. 42.

Рис. 42. Эквисоединение R' (знак "-" указывает ложные выборки) и истинное отношение R

Истинный результат также будет получен, если использовать правило R = (R2 [C=C] R3) if [B=B AND.C=C] R1 или R = (R1 [B=B] R3) if [A=A AND C=C] R2

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

Определение [3]. Пусть R является отношением, а X, Y, ..., Z - произвольные подмножества атрибутов A_R отношения R. Отношение R удовлетворяет зависимости соединения:

 (X, Y, ..., Z)

в том и только том случае, когда R восстанавливается без потерь, путем соединения своих проекций c подмножествами атрибутов X, Y, ..., Z.

Определение. Пятая нормальная форма.

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

Существует и другое определение 5НФ, принадлежащее Фэйджину [3]: Отношение R находится в 5НФ тогда и только тогда, когда каждая зависимость соединения подразумевается потенциальными ключами отношения.

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

В заключение рассмотрения 5НФ проанализируем процесс модификации данных для схемы, представленной на рис. 40. Пусть пользователь решил добавить в отношение RДМ = ДЕТАЛЬ_МАТЕРИАЛ (рис. 35) последнюю строку, такую, что состояние отношения R_ДМ приняло вид R1_ДМ (рис. 43):

Рис. 43. Cостояние R_{1 ДМ} отношения ДЕТАЛЬ_МАТЕРИАЛ (рис. 35)

Правомерно ли появление шестой строки в таблице на рис. 43? Или, другими словами, правомерно ли существование исходного отношения R (рис. 44), дающего такую проекцию?

Рис. 44. Состояние отношения ТЕХНОЛОГИЧЕСКАЯ_КАРТА, дающее проекцию, представленную на рис. 43

Если описание схемы базы данных (см. ниже), представленное на рис. 40, остается в силе, то первое, что сделает система контроля ввода данных, это проверит, не нарушается реляционный ключ в отношении R_{1 ДМ} (рис. 43) и содержатся ли в соответствующих доменах введенные значения строки (по определению все атрибуты рассматриваемых отношений являются внешними ключами). Считаем, что в нашем примере указанных противоречий нет, т.е. в системе определены базовые таблицы для объектов ДЕТАЛЬ, МАТЕРИАЛ и ТЕХНОЛОГИЯ, где атрибуты Деталь, Материал и Технология объявлены первичными ключами.

Далее необходимо проверить формульные ограничения, указанные на рис. 40, т.е. проанализировать отношения R_МТ = МАТЕРИАЛ_ТЕХНОЛОГИЯ (рис. 36) и R_ДТ = ДЕТАЛЬ_ТЕХНОЛОГИЯ (рис. 37). Нетрудно убедиться, что никаких противоречий система не обнаружит, т.к. значения <Д1, T1> (технология Т1 используется при изготовлении детали Д1) и <М3, Т1> (технология Т1 использует материал М3) уже присутствуют в R_МТ (рис. 36) и R_ДТ (рис. 37).

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

В частности, технологический поцесс Т1 изготовления детали Д1 из материала М3 может нигде и не использоваться, поэтому его присутствие в базе данных может привести к неверным ответам, например на запрос о существовании такой детали.

После введения понятий зависимостей, ключа и нормальных форм можно пополнить понятие схемы R одношения R, определив ее как пятерку, состоящую из имени Rотношения R, множества атрибутов A_R отношения R, среди которых выделено подмножество K_R, составляющее главный ключ отношения, множества зависимостей F_R, определенных на булеане B(A_R) множества атрибутов и множество правил ограничений соединения P_R отношения R, т.е.

R = {R, A_R, K_R, F_R, P_R}.

В ряде случаев схему R отношения R упрощенно можно рассматривать и как "пустое" состояние (или R₀) этого отношения, т.е. просто, как запись отношения, не содержащего в себе никаких кортежей:

R(A₁, A₂, . . . , A_n).

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

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

Пусть R₁, R₁, . . . , R_n – множество схем нормализованных отношений, образующих базу данных R. Тогда схема R базы данных R будет представлять собой пятерку:

R = {{R₁, R₂, . . . , R_n}, {A_R1, A_R2, . . . , A_Rn}, {K_R1, K_R2, . . . , K_Rn}, {F_R1, F_R2, . . . , F_Rn}∪ FL, {P_R1, P_R2, . . . , P_Rn}},

где FL – множество зависисмостей исходных отношений, которые могут быть "потеряны" при их нормализации (см. выше п. 2.5.3)

Строго говоря, для определения FL необходимо оперировать исходными (возможно, ненормализованными) отношениями.

4.5. Нормальные формы

В п. 4.4 было дано определение первой нормальной формы (1НФ). Приведем здесь более строгое ее определение, а также определения других нормальных форм.

Из таблиц, рассмотренных в п. 4, не удовлетворяет этим требованиям (т.е. не находится в 1НФ) только таблица рис. 4.1.

Кроме таблицы рис. 4.1 не удовлетворяет этим требованиям только таблица 4.2.

Как обосновано ниже (пример 4.2) она имеет составной первичный ключ

Блюдо, Дата_Р, Продукт, Поставщик, Город, Дата_П

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

Ко второй нормальной форме приведены почти все таблицы рис. 4.3 кроме таблицы Поставщики, в которой Страна зависит только от поля Город, который является частью первичного ключа (Поставщик, Город). Последнее обстоятельство приводит к проблемам при:

• включении данных (пока не появится поставщик из Вильнюса, нельзя зафиксировать, что этот город Литвы),

• удалении данных (исключение поставщика может привести к потере информации о местонахождении города),

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

Разбивая эту таблицу на две таблицы Поставщики и Города (рис. 3.2), можно исключить указанные аномалии.

Что же касается таблиц рис. 4.4, то ввод в них отсутствующих в предметной области цифровых первичных и внешних ключей формально затрудняет процедуру выявления функциональных связей между этими ключами и остальными полями. Действительно, легко установить связь между атрибутом Блюдо и Вид (блюда): Харчо – Суп, Лобио – Закуска и т.п., но нет прямой зависимости между полями БЛ и Вид (блюда), если не помнить, что значение БЛ соответствует номеру блюда.

Для упрощения нормализации подобных таблиц целесообразно использовать следующую рекомендацию.

При использовании этой рекомендации таблицы рис. 4.4 временно превращаются в таблицы рис. 4.3, а после выполнения нормализации и восстановления полей БЛ, ПР и ПОС – в нормализованные таблицы рис. 3.2.

После разделения таблицы Поставщики рис. 4.3 на две части все таблицы этого проекта удовлетворяют определению 2НФ, а так как в них нет неключевых полей, функционально зависящих друг от друга, то все они находятся в 3НФ.

Как ни странно, этого нельзя сказать об аналогичных таблицах рис 4.4. Если забыть рекомендацию о подмене на время нормализации ключей БЛ, ПР и ПОС на Блюдо, Продукт и (Поставщик, Город), то среди этих таблиц появятся две, не удовлетворяющие определению 3НФ. Действительно, так как после ввода первичных ключей БЛ и ПР поля Блюдо и Продукт стали неключевыми – появились несуществовавшие ранее функциональные зависимости между неключевыми полями:

Блюдо->Вид и Продукт->Калорийность.

Следовательно, для приведения таблиц Блюда и Продукты рис. 4.4 к 3НФ их надо разбить на

Блюда(БЛ, Блюдо),

Вид_блюда(БЛ, Вид);

Продукты(ПР, Продукт);

Калор_прод(ПР,Калорийносить),

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

Столкнувшись с подобными несуразностями, которые могут возникать не только из-за введения кодированных первичных ключей, теоретики реляционных систем Кодд и Бойс обосновали и предложили более строгое определение для 3НФ, которое учитывает, что в таблице может быть несколько возможных ключей.

В соответствие с этой формулировкой таблицы Блюда и Продукты рис. 4.4, имеющие по паре возможных ключей (БЛ и Блюдо) и (ПР и Продукт) находятся в НФБК или в 3НФ.

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

Например, естественным соединением (см. п. 3.3) таблиц рис. 4.3 можно образовать исходную таблицу, приведенную на рис. 4.2. Ту же таблицу можно получить композицией таблиц рис. 3.2. Следовательно, таблицы рис. 4.3, 4.4 и 3.2 являются полными декомпозициями таблицы Питание рис. 4.2.

Теперь можно дать определения высших нормальных форм. И сначала будет дано определение для последней из предложенных – 5НФ.

Четвертая нормальная форма (4НФ) является частным случаем 5НФ, когда полная декомпозиция должна быть соединением ровно двух проекций. Весьма не просто подобрать реальную таблицу, которая находилась бы в 4НФ, но не была бы в 5НФ.

10.10 Проектування бд методом сутність-зв’язок. Er-діаграми. Моделирование методом "сущность-связь" Основные понятия модели "сущность-связь"

Результатом моделирования методом "сущность-связь", или ER-моделирования, является ER-модель. ER-модель представляется с помощью ER-диаграмм, которые являются графической нотацией для абстрагирования данных в виде сущностей, взаимосвязей и атрибутов. Таким образом, семантика предметной областипредставляется в ER-модели в терминах субъективных средств описания – сущностей, атрибутов, идентификаторов сущностей, супертипов, подтипов и т.д.

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

Сущность описывается с помощью данных, именуемых свойствами или атрибутами (attributes) сущности. Как правило, атрибуты являются определениями в высказывании о сущности и обозначаются именами существительными естественного языка.

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

Одним из основных компьютерных способов распознавания сущностей в ИС является присвоение сущностям идентификаторов (Entity identifier). Частоидентификатор сущности называют ключом. Задача выбора идентификатора сущности является семантически субъективной задачей. Поскольку сущность определяется набором своих атрибутов, для каждой сущности целесообразно выделить такое подмножество атрибутов, которое однозначно идентифицирует данную сущность.

Некоторые сущности имеют естественные идентификаторы. Например, естественным идентификатором счета-фактуры является его номер. Идентификаторы сущности могут быть составными — состоящими из нескольких атрибутов, и атомарными — состоящими из одного атрибута сущности.

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

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

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

Каждый атрибут имеет домен (domain). Домен — это выражение, которое определяет значения, разрешенные для данного атрибута. Иными словами, домен— это область значений атрибута. Для каждого атрибута сущности должен быть определен домен. На уровне логического моделирования данных назначениедомена атрибуту носит общий характер. Например, атрибут текстовый, числовой, бинарный, дата или "не определен". В последнем случае аналитик должен дать описание домена. На последующих стадиях тип домена конкретизируется, смысл понятия домена в физической модели ХД уже, чем его может понимать аналитик. Это связано с тем, что в рамках физической модели домен реализуется посредством механизма ограничения домена, а СУБД не понимает неопределенных доменов.

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

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

Связи характеризуются степенью связи и классом принадлежности сущности к связи. Степень (мощность) связи – это отношение числа сущностей, участвующих в образовании связи. Например, "один к одному", "один ко многим", "многие ко многим". На уровне логической модели допускается неопределенная или неразрешенная связь. Класс принадлежности сущности — это характер участия сущности в связи. Различают обязательные и необязательныеклассы принадлежности сущности к связи. Обязательным является такой класс принадлежности, когда экземпляры сущности участвуют в установлении связи в обязательном порядке. В противном случае сущность принадлежит к необязательному классу принадлежности. Для необязательного класса принадлежности сущности степень связи может быть равна нулю, т.е. экземпляр сущности можно связать с 0, 1 или несколькими экземплярами другой сущности. Для обязательного класса принадлежности степень связи не может равняться нулю.

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

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

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

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

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

Пример. Сущность "автомобиль" можно разбить на следующие подтипы: автомобили с приводом на два колеса, автомобили с приводом на четыре колеса, автомобили с переключаемым приводом.

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

Для этого необходимо предпринять следующие действия:

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

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

Графическая нотация модели: диаграммы "сущность-связь"

Типичной формой документирования логической модели предметной области при ER-моделировании являются диаграммы "сущность-связь", или ER-диаграммы (Entity Relationship Diagram). ER-диаграмма позволяет графически представить все элементы логической модели согласно простым, интуитивно понятным, но строго определенным правилам — нотациям.

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

• Integration DEFinition for Information Modeling (IDEF1X). Эта нотация была разработана для армии США и стала федеральным стандартом США. Кроме того, она является стандартом в ряде международных организаций (НАТО, Международный валютный фонд и др.).

• Information Engineering (IE). Нотация, разработанная Мартином (Martin), Финкельштейном (Finkelstein) и другими авторами, используется преимущественно в промышленности.

Построение ER-диаграмм, как правило, ведется с использованием CASE-средств. В данной лекции во всех примерах, если это не оговорено особо, будет использоваться нотация MS Office Visio 2007.

Сущность на ER-диаграмме представляется прямоугольником с именем в верхней части (рис. 6.3).

Рис. 6.3.  Представление сущности "Сотрудник" на ER-диаграмме

В прямоугольнике перечисляются атрибуты сущности, при этом атрибуты, составляющие уникальный идентификатор сущности, подчеркиваются (рис. 6.4).

Рис. 6.4.  Представление сущности "Сотрудник" с атрибутами и уникальным идентификатором сущности

Каждый экземпляр сущности должен быть уникальным и отличаться от других атрибутов. Одним из основных компьютерных способов распознавания сущностей в ИС является присвоение сущностям идентификаторов (entity identifier). Поскольку сущность определяется набором своих атрибутов, для каждой сущности целесообразно выделить такое подмножество атрибутов, которое однозначно идентифицирует данную сущность. Часто идентификатор сущности называют первичным ключом (primary key).

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

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

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

Рассмотрим кандидатов на первичный ключ сущности "сотрудник" (рис. 6.5).

Рис. 6.5.  Определение первичного ключа для сущности "сотрудник"

Здесь можно выделить следующие потенциальные ключи.

1. Табельный номер.

2. Номер паспорта.

3. Фамилия + Имя + Отчество.

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

Уникальность. Два экземпляра не должны иметь одинаковых значений возможного ключа. Потенциальный ключ ( Фамилия + Имя + Отчество ) является плохим кандидатом, поскольку в организации могут работать полные тезки.

Компактность. Сложный возможный ключ не должен содержать ни одного атрибута, удаление которого не приводило бы к утрате уникальности. Для обеспечения уникальности ключа ( Фамилия + Имя + Отчество ) дополним его атрибутами Дата рождения и Цвет глаз. Если бизнес-правила говорят, что сочетания атрибутовФамилия + Имя + Отчество + Дата рождения достаточно для однозначной идентификации сотрудника, то Цвет глаз оказывается лишним, т. е. ключ Фамилия + Имя + Отчество + Дата рождения + Цвет глаз не является компактным.

При выборе первичного ключа предпочтение должно отдаваться более простым ключам, т. е. ключам, содержащим меньшее количество атрибутов. В примере ключи № 1 и № 2 предпочтительней ключа № 3.

Атрибуты ключа не должны содержать нулевых значений. Если допускается, что сотрудник может не иметь паспорта или вместо паспорта иметь какое-либо другое удостоверение личности, то ключ № 2 не подойдет на роль первичного ключа. Если для обеспечения уникальности необходимо дополнить потенциальный ключ дополнительными атрибутами, то они не должны содержать нулевых значений. При дополнении ключа № 3 атрибутом Дата рождения нужно убедиться в том, что даты рождения известны для всех сотрудников.

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

Каждая сущность должна иметь, по крайней мере, один потенциальный ключ. Многие сущности имеют только один потенциальный ключ. Такой ключ становится первичным. Некоторые сущности могут иметь более одного возможного ключа. Тогда один из них становится первичным, а остальные – альтернативными ключами.Альтернативный ключ (Alternate Key) – это потенциальный ключ, не ставший первичным.

Некоторые сущности имеют естественные (натуральные) ключи. Например, естественным идентификатором счета-фактуры является его номер. В противном случае проектировщик может создать суррогатный ключ (Surrogate Key) – атрибут, значение которого создается искусственно и не имеет отношения к предметной области. При моделировании структур данных для ХД суррогатные ключи во многих ситуациях являются более предпочтительными.

Домены назначаются аналитиками и фиксируются в специальном документе — словаре данных (Data Dictionary). При создании логической модели домены могут быть специфицированы в сущностях на ER-диаграмме.

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

На уровне логического моделирования данных назначение домена атрибуту носит общий характер. Например, атрибут текстовый, числовой, бинарный, дата или "не определен". В последнем случае аналитик должен дать описание домена. На последующих стадиях тип домена конкретизируется, смысл понятия домена в физической модели ХД уже, чем его может понимать аналитик. Это связано с тем, что в рамках физической модели домен реализуется посредством механизма ограничения домена, СУБД не понимает неопределенных доменов.

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

• для реализации реляционного ХД требуется использовать реляционную или объектно-реляционную СУБД, например, MS SQL Server 2008;

• в большинстве реляционных СУБД в качестве языка манипулирования и описания данных используется SQL, поддерживающий определенные стандарты, например, ANSI SQL-92.

Отношение (связь) сущностей на ER-диаграмме изображается линией, соединяющей эти сущности. Отношение читается вдоль линии либо слева направо, либо справа налево. На рис. 6.6 представлено следующее отношение: каждая специальность по образованию должна быть зарегистрирована за определенным физическим лицом (персоной), физическое лицо может иметь одну или более специальностей по образованию.

Рис. 6.6.  Представление отношения между двумя сущностями на ER-диаграмме

В MS Office Visio имя связи, степень связи (мощность) и класс принадлежности сущности к связи определяется на вкладке "Свойства базы данных", как показано на рис. 6.7. Стрелка на линии связи указывает на родительскую таблицу.

Рис. 6.7.  Определение мощности связи отношения между сущностями "Сотрудник" и "Образование"

При выделении связей акцент делается на выявление их характеристик. Связь представляет собой взаимоотношение между двумя или более сущностями. Каждая связь реализуется через значения атрибутов сущностей, например, экземпляр сущности "Сотрудник" (рис. 6.6) связан с экземпляром сущности "Образование" по одинаковым значениям атрибутов Табельный номер. Другими словами, при создании связи в одной из сущностей, называемой дочерней сущностью, создается новый атрибут, называемый внешним ключом (Foreign Key, FK) (на рис. 6.6 это атрибут Табельный номер ). Иногда атрибуты внешнего ключа обозначаются символом (FK) после своего имени.

Связь является логическим соотношением между сущностями. Каждая связь должна именоваться глаголом или глагольной фразой Имя связи (Verb Phrase) – фраза, характеризующая отношение между родительской и дочерней сущностями. Имя связи выражает некоторое ограничение или бизнес-правило и облегчает чтение диаграммы. На рис. 6.8 показано присвоение связи имени.

Рис. 6.8.  Именование связи между сущностями "Сотрудник" и "Образование"

Существуют различные типы связей: идентифицирующая связь (identifying relationship) "один ко многим", связь "многие ко многим" и неидентифицирующая связь (non-identifying relationship) "один ко многим". С типами связей связывают и различные типы сущностей.

Различают два типа сущностей: зависимые (Dependent entity) и независимые (Independent entity). Тип сущности определяется ее связью с другими сущностями. Идентифицирующая связь устанавливается между независимой (родительский конец связи) и зависимой (дочерний конец связи) сущностями.

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

Если модель создается при помощи CASE-средств, то при генерации схемы БД атрибуты первичного ключа получат признак NOT NULL, что означает невозможность внесения записи в таблицу "Сотрудники" без информации о табельном номере сотрудника.

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

увеличить изображениеНеидентифицирующая связь

Экземпляр сущности "Сотрудник" может существовать безотносительно к какому-либо экземпляру сущности "Отдел", т. е. сотрудник может работать в организации и не числиться в каком-либо отделе.

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

Связь "многие ко многим" (many-to-many relationship) может быть создана только на уровне логической модели. На рис. 6.10 показан пример определения связи "многие ко многим". Врач может принимать много пациентов, пациент может лечиться у нескольких врачей. Такая связь обозначается сплошной линией с двумя стрелочками на концах.

Связь "многие ко многим" должна именоваться двумя фразами – в обе стороны (в примере "принимает/лечится"). Это облегчает чтение диаграммы. Связь на рис. 6.10 следует читать так: Врач <принимает> Пациента, Пациент <лечится> у Врача.

Рис. 6.10.  Связь "многие ко многим"

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

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

Ассоциативная – сущность, связанная с несколькими родительскими сущностями. Такая сущность содержит информацию о связях сущностей.

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

Категориальная – дочерняя сущность в иерархии наследования.

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

Обычно иерархию наследования создают, когда несколько сущностей имеют общие по смыслу атрибуты либо когда сущности имеют общие по смыслу связи (например, если бы "Штатный сотрудник" и "Совместитель" имели сходную по смыслу связь "работает в" с сущностью "Организация"), либо когда это диктуется бизнес-правилами.

Для каждой категории можно указать дискриминатор (discriminator) – атрибут родового предка, который показывает, как отличить одну категориальную сущность от другой (атрибут Тип на рис. 6.11).

Рис. 6.11.  Иерархия наследования. Неполная категория

Иерархии категорий делятся на 2 типа – полные и неполные. В полной иерархии категорий (Complete subtype relationship) одному экземпляру родового предка (сущность "Сотрудник", рис. 6.12) обязательно соответствует экземпляр в каком-либо потомке, т. е. в этом примере служащий обязательно является либо совместителем, либо консультантом, либо постоянным сотрудником.

Если категория еще не выстроена полностью и в родовом предке могут существовать экземпляры, которые не имеют соответствующих экземпляров в потомках, то такая категория будет неполной (Incomplete subtype relationship). На рис. 6.11 показана неполная категория – сотрудник может быть не только постоянным или совместителем, но и консультантом, однако сущность "Консультант" еще не внесена в иерархию наследования.

На рис. 6.12 показан пример полной категории.

Рис. 6.12.  Иерархия наследования. Полная категория

Полная категория помечается символом , неполная – .

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

Рассмотрим возможные стадии построения иерархии наследования.

1. Определение сущностей с общими (по определению) атрибутами.

Предположим, в процессе проектирования созданы сущности "Штатный сотрудник" и "Совместитель" (рис. 6.13). Можно заметить, что часть атрибутов у этих сущностей ( Фамилия, Имя, Отчество, Дата рождения, Должность ) имеет одинаковый смысл.

Рис. 6.13.  Сущности с общими по смыслу атрибутами

2. Перенос общих атрибутов в сущность – родовой предок. В случае обнаружения совпадающих по смыслу атрибутов следует создать новую сущность "Сотрудник" – родовой предок, и перенести в нее общие атрибуты ( Фамилия, Имя, Отчество, Дата рождения, Должность ).

3. Создание неполной структуры категорий. Создается категориальная связь от новой сущности – родового предка к старым сущностям-потомкам. Новая сущность дополняется атрибутом – дискриминатором категории ( Тип ) (см. рис. 6.11).

4. Создание полной структуры категорий. Проводится дополнительный поиск сущностей, имеющих общие по смыслу атрибуты с родовым предком. В примере это сущность "Консультант" (рис. 6.14).

Рис. 6.14.  Дополнительная сущность с общими по смыслу атрибутами

Общие атрибуты переносятся в родового предка, и категория преобразуется в полную. Сущность "Консультант" не имеет атрибута Должность, поэтому в родовом предке значение этого атрибута в случае консультанта будет NULL. В зависимости от бизнес-правил атрибут Должность может быть перенесен обратно из родового предка в сущности-потомки "Штатный сотрудник" и "Совместитель".

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

Нормализация модели "сущность-связь"

Имеются 3 подуровня логического уровня модели данных, отличающихся по глубине представления информации о данных:

• диаграмма "сущность-связь" (Entity Relationship Diagram, ERD);

• модель данных, основанная на ключах (Key Based model, KB);

• полная атрибутивная модель (Fully Attributed model, FA).

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

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

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

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

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

Процесс нормализации сводится к последовательному приведению структуры данных к нормальным формам – формализованным требованиям к организации данных. Известно 6 нормальных форм:

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

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

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

• нормальная форма Бойса-Кодда (усиленная 3NF);

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

• пятая нормальная форма (5NF).

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

Нормальные формы основаны на понятии функциональной зависимости (в дальнейшем будет использоваться термин "зависимость"). Приведем формальное определение для функциональной зависимости.

Функциональная зависимость (FD). Атрибут B сущности E функционально зависит от атрибута A сущности E тогда и только тогда, когда каждое значение A в E связало с ним точно одно значение B в E, т. е. A однозначно определяет B.

Полная функциональная зависимость. Атрибут B сущности E полностью функционально зависит от ряда атрибутов A сущности E тогда и только тогда, когда B функционально зависит от A и не зависит ни от какого подмножества атрибутов A.

Рис. 6.15.  Ненормализованная сущность "Сотрудник"

На рис. 6.15 в сущности "Сотрудник" значения атрибутов Фамилия, Имя и Отчество однозначно определяются значением атрибута Табельный номер, т. е. атрибутыФамилия, Имя и Отчество зависят от атрибута Табельный номер.

Функциональные зависимости определяются бизнес-правилами предметной области. Так, если оклад сотрудника определяется только должностью, то атрибутОклад зависит от атрибута Должность ; если оклад зависит еще, например, от стажа, то такой зависимости нет. В нижеследующих примерах будем считать для определенности, что такая зависимость есть.

Рассмотрим нормальные формы.

Первая нормальная форма (1NF) Сущность находится в первой нормальной форме тогда и только тогда, когда все атрибуты содержат атомарные значения.

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

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

Для приведения сущности к первой нормальной форме следует:

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

• создать новую сущность;

• перенести в нее все "повторяющиеся" атрибуты;

• выбрать возможный ключ для нового PK (или создать новый PK);

• установить идентифицирующую связь от прежней сущности к новой, PK прежней сущности станет внешним ключом (FK) для новой сущности.

На рис. 6.16 показана сущность "Сотрудник", приведенная к первой нормальной форме.

Рис. 6.16.  Сущность "Сотрудник", приведенная к первой нормальной форме

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

Рис. 6.17.  Сущность "Проект"

Предположим, что сущность "Проект" содержит информацию о проекте, которым руководит сотрудник, причем информация содержится как непосредственно о проекте, так и о руководителе проекта (рис. 6.17). Атрибуты Фамилия, Имя, Отчество и Должность зависят только от атрибута табельный номер руководителя, но вовсе не от атрибута Наименование проекта. Другими словами, имеется зависимость только от части ключа.

Для приведения сущности ко второй нормальной форме следует:

• выделить атрибуты, которые зависят только от части первичного ключа, создать новую сущность;

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

• установить идентифицирующую связь от прежней сущности к новой (рис. 6.18).

Рис. 6.18.  Сущность "Проект", приведенная ко второй нормальной форме

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

• обновления (UPDATE). Происходит дублирование данных о сотруднике, если он руководит несколькими проектами. Если данные о сотруднике изменяются, необходимо менять несколько записей (по числу ведомых проектов);

• вставки (INSERT). Невозможно ввести данные о сотруднике, если он в данный момент не руководит проектами;

• удаления (DELETE). Если сотрудник временно прекращает руководство проектами, данные о нем теряются.

На рис. 6.18 показана сущность "Проект", приведенная ко второй нормальной форме.

Третья нормальная форма (3NF). Сущность находится в третьей нормальной форме, если она находится во второй нормальной форме и никакой неключевой атрибут не зависит от другого неключевого атрибута (не должно быть взаимозависимости между неключевыми атрибутами).

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

Для приведения сущности к третьей нормальной форме следует:

• создать новую сущность и перенести в нее атрибуты с одной и той же зависимостью от неключевого атрибута;

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

• установить неидентифицирующую связь от новой сущности к старой (рис. 6.19).

Рис. 6.19.  Сущность "Сотрудник", приведенная к третьей нормальной форме

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

Третья нормальная форма также позволяет избежать ряда аномалий.

• Обновление (UPDATE). Происходит дублирование данных об окладе, если должность занимают несколько сотрудников. Если оклад, соответствующий должности, меняется, необходимо менять несколько записей (по числу сотрудников на одной должности).

• Вставка (INSERT). Невозможно ввести данные об окладе, соответствующем должности, если в данный момент нет сотрудника, занимающего эту должность.

• Удаление (DELETE). В случае удаления из таблицы сотрудника, занимающего уникальную должность, данные об окладе теряются.

Четвертая нормальная форма (4NF) требует отсутствия многозначных зависимостей между атрибутами.

В примере на рис. 6.20 (слева) преподаватель читает лекции по нескольким предметам и курирует несколько групп студентов. Одна группа студентов может изучать несколько предметов, одному предмету могут обучаться несколько групп студентов. Имеется многозначная зависимость между атрибутами Предмет иГруппа. При этом возможна аномалия: если у преподавателя появляется новая группа, приходится добавлять несколько записей, по числу читаемых предметов.

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

Рис. 6.20.  Иллюстрация четвертой нормальной формы

Резюме

Метод моделирования "сущность-связь" был предложен С. Ченом в 1976 году. Ряд исследователей разработали несколько графических нотаций для представления элементов модели. Проектировщик ХД может выбрать графическую нотацию по своему вкусу.

Применение метода моделирования "сущность-связь" помогает проектировщикам создать логическую модель предметной области, не зависимую от программно-аппаратной реализации. Этот метод используется как при моделировании предметных областей OLTP-систем, так и при моделировании предметных областей BI-систем. Знание этого метода помогает проектировщику ХД быстрее установить логические связи между моделями БД OLTP-систем масштаба организации и моделями ХД BI-систем.

Независимо от выбранной нотации, действия проектировщика ХД при ER-моделировании сводятся к следующему алгоритму.

Для каждой сущности предметной области базы данных необходимо:

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

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

• определить возможные ключи, в частности, рассмотрев уникальный идентификатор сущности ;

• выполнить нормализацию сущности;

• назначить первичные ключи новых, полученных в результате нормализации сущностей;

• сформировать бизнес-правила поддержки целостности сущности.

Для каждой связи между сущностями необходимо:

• определить мощность связи;

• определить обязательность вхождения сущности в связь;

• разрешить связи "многие ко многим";

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

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

• сформировать бизнес-правила поддержки целостности связей;

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

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

Захист інформації в комп’ютерних системах

11.1 Властивості інформації. Класифікація загроз інформації.

Безопасность информации – такое состояние всех компонент компьютерной системы (КС), при котором обеспечивается защита информации от возможных угроз на требуемом уровне.

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

Свойства информации:

• Целостность – состоит в том, что информация не может быть модифицирована неавторизованным пользователем или процессом.

• Конфиденциальность – состоит в том, что информация не может быть получена неавторизованным пользователем или процессом.

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

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

По цели воздействия различают три основных типа угроз:

• Угрозы нарушения конфиденциальности информации – направлены на разглашение конфиденциальной или секретной информации. Имеет место всякий раз, когда получен несанкционированный доступ к некоторой закрытой информации, хранящейся в КС или передаваемой от одной системы к другой;

• Угрозы нарушения целостности информации – направлены на ее изменение или искажение, приводящее к нарушению ее качества или полному уничтожению. Эта угроза актуальна для систем передачи информации – компьютерных сетей и систем телекоммуникаций;

• Угрозы нарушения работоспособности системы (отказы в обслуживании) – направлены на создание таких ситуаций, когда определенные преднамеренные действия либо снижают работоспособность КС, либо блокируют доступ к некоторым ее ресурсам.

Опасные воздействия на КС делятся на случайные и преднамеренные.

Случайные угрозы не связаны с преднамеренными действиями злоумышленников и реализуются в случайные моменты времени:

• Стихийные бедствия и аварии

• Сбои и отказы технических средств

• Ошибки при разработке КС

• Алгоритмические и программные ошибки

• Ошибки пользователей и обслуживающего персонала

Преднамеренные угрозы (класс постоянно пополняется):

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

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

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

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

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

11.2 Рівні захисту інформації в комп’ютерних мережах.

Уровни защиты информации:

- нормативный (законодательный);

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

- физический;

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

- технический уровень;

Объединяет различные устройства защиты информации.

- организационный уровень;

Сост. док-ты, которые регламентируют использование всех других средств.

- программный уровень;

Объединяет способы защиты информации, которая обрабатывается в компьютерных системах.

- криптографический уровень;

Различные уровни защиты часто объединяются с техническим.

11.3 Законодавчий рівень захисту інформації.

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

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

Защита авторских прав на ПО обеспечивается федеральным законодательством об авторских правах.

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

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

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

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

(коротко о законе – перевод Рута&Плай)

ЗАКОН УКРАИНЫ О защите информации в автоматизированных системах (/г. Киев, 5 июля 1994 года N 80/94-ВР. Вводится в действие Постановлением ВР N 81/94-ВР от 05.07.94/)

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

Действие Закона распространяется на любую информацию, которая обрабатывается в автоматизированных системах (АСС).

Раздел 1. ОБЩИЕ ПОЛОЖЕНИЯ. (Статья 1. Определения терминов. Статья 2. Объекты защиты. Статья 3. Субъекты отношений. Статья 4. Право собственности на информацию во время ее обработки. Статья 5. Гарантия юридической защиты. Статья 6. Доступ к информации)

Раздел 2. ОТНОШЕНИЯ МЕЖДУ СУБЪЕКТАМИ В ПРОЦЕССЕ ОБРАБОТКИ ИНФОРМАЦИИ В АСС. (Статья 7. Отношения между собственником информации и собственником АСС. Статья 8. Отношения между собственником информации и пользователем. Статья 9. Отношения между собственником АСС и пользователем АСС.)

Раздел 3. ОБЩИЕ ТРЕБОВАНИЯ ОТНОСИТЕЛЬНО ЗАЩИТЫ ИНФОРМАЦИИ. (Статья 10. Обеспечения защиты информации в АСС. Статья 11. Установления требований и правил относительно защиты Информации. Статья 12. Условия обработки информации.)

Раздел 4. ОРГАНИЗАЦИЯ ЗАЩИТЫ ИНФОРМАЦИИ В АСС. (Статья 13. Политика в области защиты информации. Статья 14. Государственное управление защитой информации в АСС. Статья 15. Службы защиты информации в АСС. Статья 16. Финансирование работ.)

Раздел 5. ОТВЕТСТВЕННОСТЬ ЗА НАРУШЕНИЕ ЗАКОНА О ЗАЩИТЕ ИНФОРМАЦИИ. (Статья 17. Ответственность за нарушение порядка. Статья 18. Возмещения вреда.)

Раздел 6. МЕЖДУНАРОДНАЯ ДЕЯТЕЛЬНОСТЬ В ОБЛАСТИ ЗАЩИТЫ ИНФОРМАЦИИ В АСС. (Статья 19. Взаимодействие в вопросах защиты информации в АСС. Статья 20. Обеспечения информационных прав Украины.)

ЗАКОН УКРАИНЫ Об информации

Этот Закон закрепляет право граждан Украины на информацию, закладывает правовые основы информационной деятельности.

Опираясь на Декларации о государственном суверенитете Украины (55-12) и Акте провозглашения ее независимости, Закон утверждает информационный суверенитет Украины и определяет правовые формы международного сотрудничества в области информации.

ЗАКОН УКРАИНЫ О государственной тайне

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

11.4 Криптографічний захист інформації.

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

Криптография дает возможность преобразовать информацию таким образом, что ее прочтение (восстановление) возможно только при знании ключа.

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

Алфавит – конечное множество используемых для кодирования информации знаков.

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

В качестве примеров алфавитов, используемых в современных ИС можно привести следующие:

- алфавит Z₃₃ – 32 буквы русского алфавита и пробел;

- алфавит Z₂₅₆ – символы, входящие в стандартные коды ASCII и КОИ-8;

- бинарный алфавит – Z₂ = {0,1};

- восьмеричный алфавит или шестнадцатеричный алфавит;

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

Дешифрование – обратный шифрованию процесс. На основе ключа шифрованный текст преобразуется в исходный.

Ключ – информация, необходимая для беспрепятственного шифрования и дешифрования текстов.

Криптографическая система представляет собой семейство T преобразований открытого текста. Члены этого семейства индексируются, или обозначаются символом k; параметр k является ключом. Пространство ключей K – это набор возможных значений ключа. Обычно ключ представляет собой последовательный ряд букв алфавита.

Криптосистемы разделяются на симметричные и асимметричные (с открытым ключом).

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

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

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

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

- количество всех возможных ключей;

- среднее время, необходимое для криптоанализа.

Преобразование T_k определяется соответствующим алгоритмом и значением параметра k. Эффективность шифрования с целью защиты информации зависит от сохранения тайны ключа и криптостойкости шифра.

Требования к криптосистемам

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

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

- зашифрованное сообщение должно поддаваться чтению только при наличии ключа;

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

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

- знание алгоритма шифрования не должно влиять на надежность защиты;

- незначительное изменение ключа должно приводить к существенному изменению вида зашифрованного сообщения даже при использовании одного и того же ключа;

- структурные элементы алгоритма шифрования должны быть неизменными;

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

- длина шифрованного текста должна быть равной длине исходного текста;

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

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

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

11.5 Стандарти симетричного шифрування даних.

Характерной особенностью симметричной криптосистемы является применение одного и того же секретного ключа как при шифровании, так и при расшифровке сообщений.

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

Пример. Шифрующие таблицы, магические квадраты.

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

Пример. Система шифрования Цезаря.

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

Пример. Аффинная система подстановок Цезаря.

В данном преобразовании буква, соответствующая числу t, заменяется на букву, соответствующую числовому значению (at+b) mod m. Преобразование является взаимно однозначным только в том случае, если наибольший общий делитель чисел a и m, обозначаемый как НОД(a,m), равен единице, т.е. a и m должны быть взаимно простыми числами. (m=26, a=3, b=5)

Пример. Система Цезаря с ключевым словом.

Особенностью этой системы является использование ключевого слова для смещения и изменения порядка символов в алфавите подстановки.

Выберем некоторое число k, 0<=k<=25, и слово или короткую фразу в качестве ключевого слова. Желательно, чтобы все буквы ключевого слова были различными. Пусть выбраны слово DIPLOMAT в качестве ключевого слова и число к=5. Ключевое слово записывается под буквами алфавита, начина с буквы, числовой код которой совпадает с выбранным числом к:

0 1 2 3 4 5 10 15 20 25

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

D I P L O M A T

Оставшиеся буквы алфавита подстановки записываются после ключевого слова в алфавитном порядке:

0 1 2 3 4 5 10 15 20 25

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

V W X Y Z D I P L O M A T B C E F G H J K N Q R S U

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

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

Пример. Система шифрования Вижинера. (кодировочные таблицы Вижинера).

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

Пример. Гаммирование случайной двоичной последовательностью.

М-разрядная случайная двоичная последовательность — ключ шифра, известный отправителю и получателю сообщения.

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

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

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

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

11.6 Системи ідентифікації та аутентифікації користувачів.

Идентификация – процедура присвоения пользователям идентификаторов, а так же проверка предъявляемых идентификаторов по списку присвоенных.

Идентификатор – уникальный атрибут объекта.

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

Методы аутентификации:

1. Наличие у объекта компьютерной системы удостоверения, пропуска, ключа, магнитной ленты и т.п. [пропуска].

2. Знание некоторой известной только объекту и проверяющей стороне информации [пароль].

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

Хранение паролей. Пароль можно хранить: в открытом виде, в виде свертки (например в виде хеша), в зашифрованном виде.

Элемент структуры базы паролей пользователей

Номер пользователя	Идентификатор для идентификации	Идентификатор для аутентификации
1	ID1	E1
…	…	…
N	IDn	En

Протокол идентификации и аутентификации

1. Пользователь предъявляет свой идентификатор ID.

2. Если идентификатор ID не совпадает ни с одним из IDк, то идентификация отвергается.

3. Запрашивается аутентификатор K пользователя i.

4. Вычисляется Y=F(IDi, K).

5. Если Y=Ei, то прошла аутентификация.

Атаки на фиксированные пароли:

1. Повторное использование паролей:

- просмотр при введении с клавиатуры

- получение документов, содержащих пароли

- перехват паролей из каналов связи

2. Тотальный перебор паролей

3. Атаки с помощью словаря (эффективны, если пользователь сам выбирает пароль).

11.7 Парольна система. Вимоги до паролів.

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

Подсистема управления доступом СЗИ затрагивает следующие понятия:

Идентификатор доступа

Идентификация

Пароль - идентификатор субъекта доступа, который является его (субъекта) секретом. Аутентификация - проверка принадлежности субъекту доступа предъявленного им идентификатора; подтверждение подлинности.

Учетная запись - совокупность идентификатора и пароля пользователя.

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

:в открытом виде;

в виде хэш-значений (hash (англ.) - смесь, мешанина);

зашифрованными на некотором ключе.

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

ключ генерируется программно и хранится в системе, обеспечивая возможность ее автоматической перезагрузки;

ключ генерируется программно и хранится на внешнем носителе, с которого считывается при каждом запуске;

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

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

Существуют методы количественной оценки стойкости парольных систем

(формула Андерсона), где

k - количество попыток подбора пароля в минуту; M - время действия пароля в месяцах; P - вероятность подбора пароля;A¹ - мощность пространства паролей (А - мощность алфавита паролей, l - длина пароля). Таким образом, наибольшее влияние на вероятность раскрытия пароля оказывает величина l. Другие составляющие данной формулы чрезвычайно редко оказывают влияние на величину P, превышающее один порядок. Увеличение же длины пароля только на один символ значительно увеличивает требуемое злоумышленнику время для его раскрытия. Параметры Р, V, T и A¹ связаны между собой следующим соотношением [1]: , где P - вероятность подбора пароля в течение его срока действия (подбор осуществляется непрерывно в течение всего срока действия пароля);V - скорость подбора паролей (скорость обработки одной попытки регистрации проверяющей стороной либо скорость вычисления хэш-значения одного пробного пароля);T - срок действия пароля (задает промежуток времени, по истечении которого пароль должен быть сменен);A¹ - мощность пространства паролей (А - мощность алфавита паролей, l - длина пароля).

В случае, когда неизвестна точная длина искомого пароля, максимальное время подбора пароля (Т_max) будет вычисляться в соответствии со следующей формулой [3]:

Тmax

Требования к паролям:

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

Большинство СЗИ обладает следующими возможностями по увеличению эффективности парольной системы:

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

• установление максимального срока действия пароля;

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

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

• не действует на учетную запись администратора).

11.8 Методи та засоби захисту від віддалених мережевих атак.

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

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

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

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

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

Защита информации в VPN строится с использованием следующих технических приемов:

• Шифрование исходного IР-пакета, что обеспечивает секретность содержащихся в пакете данных, таких как поля IР-заголовка и поле данных;

• Цифровая подпись IР-пакетов, что обеспечивает аутентификацию пакета и источника-отправителя пакета;

• Инкапсуляция IР-пакета в новый защищенный IР—пакет с новым заголовком, содержащим IР-адрес устройства защиты, что маскирует топологию внутренней сети.

Теперь немного о принципе работы этой технологии. VPN-устройство располагается между внутренней сетью и Internet на каждом конце соединения. Когда вы передаете данные через УРЫ, они исчезают “с поверхности” в точке отправки и вновь появляются только в точке назначения. Этот процесс принято называть “туннелированием”. Как

можно догадаться из названия, это означает создание логического туннеля в сети Internet, который соединяет две крайние точки. Благодаря туннелированию частная информация становится невидимой для других пользователей IP. Прежде чем попасть в Internet - туннель, данные еще и шифруются, что обеспечивает их дополнительную защиту. Протоколы шифрования бывают разные. Все зависит от того, какой протокол туннелирования поддерживается тем или иным VPN -решением. IРsес поддерживает самый широкий спектр стандартов шифрования. Еще одной важной характеристикой VPN-решений является диапазон поддерживаемых протоколов аутентификации. Большинство популярных продуктов работают со стандартами, основанными на использовании открытого ключа, такими как Х.509. Это означает, что, усилив свою виртуальную частную сеть соответствующим протоколом аутентификации, вы сможете гарантировать, что доступ к вашим защищенным туннелям получат только известные вам люди.

В режиме построения VPN (режиме туннелирования) IРsес обеспечивает безопасность связи в Интернете «упаковкой» IР-пакета в новый IР-пакет с применением к нему различных преобразований — шифрации и электронных подписей

В зависимости от требований к IР используется два вида заголовков, и, соответственно, предоставляется два режима функциональности протокола. В одном случае ЕSР предоставляется возможность передавать зашифрованные данные, электронно подписывать передаваемые данные и включать в заголовок специальный счетчик — число, которое увеличивается на 1 в каждом новом пакете, предотвращая повторное использование данных. Таким образом, обеспечивается секретность, неизменность предаваемых данных, невозможность их повторного использования и подтверждается личность их отправителя. Причем можно использовать все эти возможности как одновременно, так и по отдельности. Во втором случае АН позволяет включать электронную подпись всего пакета и счетчик. Таким образом, гарантируется все то, что обеспечивает ЕSР, кроме секретности. Но АН обеспечивает электронную подпись всего пакета, в том числе и внешнего IР-заголовка (адреса и другие надписи на конверте), в то время как ЕР защищает только улакованный пакет. При необходимости эти два заголовка могут использоваться совместно, что применяется в случае, когда необходимо и обеспечить секретность данных, и гарантировать целостность всего пакета.

16. Критерії захищеності автоматизованих систем. Профіль захисту

Для оценки защищенности компьютерных систем (КС) в 1983 г. в США впервые были формально определены критерии оценки безопасности КС Министерства Обороны США – TCSEC – «Оранжевая Книга».

1986 г. – Европейские критерии.

1992 г. – документы Гостехкомиссии России, Федеральные критерии (заменили «Оранжевую книгу», появилось понятие «профиль»).

1993 г. – Канадские критерии.

1999 г.– единые критерии- утверждены Международной организацией по стандар-дартизации ISO в качестве международного стандарта информационной безопас-ности.

1999 г. – Украинские критерии.

Профиль состоит из трех частей:

название класса:

1. – одномашинный однопользовательский комплекс

2. – локализованный многомашинный многопользовательский комплекс

3. – распределенный многомашинный многопользовательский комплекс

виды угроз, от которых обеспечивается защита:

К – конфиденциальность, Ц – целостность, Д – доступность

номер профиля – 1.К.1={НР-1, …, НТ-1}

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

Функциональные критерии разбиты на 4 группы:

конфиденциальность – КД – доверительная конфиденциальность (4 уровня КД-1, …, КД-4),

КА – административная (КА-1, …, КА-4),

КО – повторное использование объектов;

целостность – ЦД – доверительная целостность, ЦБ – при обмене;

доступность;

наблюдательность – НИ – идентификация и аутентификация, НР – регистрация (НР-1, …, НР‑5).