WWW.DOC.KNIGI-X.RU
БЕСПЛАТНАЯ  ИНТЕРНЕТ  БИБЛИОТЕКА - Различные документы
 


«БЕЗОПАСНОСТЬ СИСТЕМ БАЗ ДАННЫХ тема № 4 Лекция 4. Нормализация базы данных В данной лекции рассмотрим суть нормализации, зачем она нужна и как ...»

БЕЗОПАСНОСТЬ

СИСТЕМ БАЗ ДАННЫХ

тема № 4

Лекция 4. Нормализация базы данных

В данной лекции рассмотрим суть нормализации, зачем она нужна и

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

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

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

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

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

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

Термин нормализация обязан своим появлением пионерам технологии баз данных: Э. Кодду, Д. Бойсу, Р. Фагину, П. Чену, Р.Баркеру, которые определили различные нормальные формы (Normal Form) отношений.

В последнее время более тщательное исследование данного вопроса можно найти в работах: Д. Ульмана, Г. Молина, Д. Уидома, Д. Кренке, а также российских ученых С. Глушакова, Д. Ломотько, Э. Фуфаева, Н. Соловьева и др.

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

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

Классы отношений стали называть нормальными формами. В зависимости от © к.п.н. Тагиров В.К., к.п.н., доцент Тагирова Л.Ф. Страница 2 своей структуры, отношение может быть в первой, во второй или в какой-либо другой нормальной форме.

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

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

состав пользователей данных;

обеспечение целостности данных (особенно важно в многопользовательских информационных системах);

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

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

Классы нормальных форм

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

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

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

© к.п.н. Тагиров В.К., к.п.н., доцент Тагирова Л.Ф. Страница 3 Таким образом, информация о фамилии, имени и отчестве студента дублируется. При этом возникают проблемы, например связанные с тем, что при изменении фамилии студента возникает необходимость ее изменения в обоих отношениях. Из вышесказанного следует простейший вывод - хорошая структура БД содержит по одному элементу информации и только в одном месте, что и позволяет избежать избыточность.

Рисунок 4.1 – Схема связей базы данных «Учебный процесс»

–  –  –

• 1НФ - первая нормальная форма (First Normal Form – 1NF);

• 2НФ - вторая нормальная форма (Second Normal Form – 2NF);

• 3НФ - третья нормальная форма (Third Normal Form – 3NF);

• НФБК - нормальная форма Бойса-Кодда (Brice – Codd Normal Form BCNF):

• 4НФ - четвертая нормальная форма (Fourth Normal Form – 4NF);

• 5НФ или НФПС - пятая нормальная форма или нормальная форма проекции-соединения (Fifth Normal Form – 5NF или PJ/NF);

• ДКНФ – доменно-ключевая нормальная форма (Domain/Key Normal Form, DK/NF).

© к.п.н. Тагиров В.К., к.п.н., доцент Тагирова Л.Ф. Страница 4 Функциональные зависимости Чтобы понять, что такое нормализация, мы предварительно должны уяснить некоторые термины и определения, и прежде всего: функциональная зависимость и ключ.

Функциональная зависимость (functional depedencu) — это связь между атрибутами. Предположим, что если мы знаем значение одного атрибута, то можем вычислить (или найти) значение другого атрибута. Например, если нам известен номер студента, то мы можем определить его успеваемость (оценки по предметам обучения). В таком случае мы можем сказать, что атрибут ОЦЕНКА функционально зависит от атрибута НОМЕР СТУДЕНТА.

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

Арифметические уравнения тоже выражают функциональные зависимости.

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

Стоимость = Цена * Количество В этом случае мы могли бы сказать, что атрибут СТОИМОСТЬ функционально зависит от атрибутов ЦЕНА и КОЛИЧЕСТВО. В электронных таблицах это легко и однозначно решается.

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

Функциональные зависимости обозначаются следующим образом:

НОМЕР СТУДЕНТА СПЕЦИАЛЬНОСТЬ

НОМЕР ГРУППЫ КОЛИЧЕСТВО СТУДЕНТОВ

Первое выражение читается так: «атрибут НОМЕР СТУДЕНТА функционально определяет атрибут СПЕЦИАЛЬНОСТЬ», «атрибут НОМЕР СТУДЕНТА определяет атрибут СПЕЦИАЛЬНОСТЬ» или «атрибут СПЕЦИАЛЬНОСТЬ зависит от атрибута НОМЕР СТУДЕНТА». Атрибуты по правую сторону от стрелки называются детерминантами (determinants).

Как уже говорилось, если номер студента определяет специальность, то каждому номеру студента соответствует только одна специальность. Между тем, одной и той же специальности может соответствовать более одного номера студента. Пусть студент под номером 12 специализируется на бухгалтерском учете. Тогда для любого отношения, где присутствуют столбцы НОМЕР СТУДЕНТА и СПЕЦИАЛЬНОСТЬ, выполнится условие: если НОМЕР СТУДЕНТА=12, то СПЕЦИАЛЬНОСТЬ = Бух.учет. Обратное утверждение будет неверным: если СПЕЦИАЛЬНОСТЬ = Бух.учет, то атрибут НОМЕР СТУДЕНТА может принимать различные значения, так как на Бух.учете может специализироваться много студентов. Следовательно, мы можем сказать, что связь атрибутов НОМЕР СТУДЕНТА и СПЕЦИАЛЬНОСТЬ имеет вид М:1.

В общем случае можно утверждать, что если А определяет В, связь межк.п.н. Тагиров В.К., к.п.н., доцент Тагирова Л.Ф. Страница 5 ду значениями А и В имеет вид М:1.

В функциональные зависимости могут быть вовлечены группы атрибутов.

Рассмотрим отношение УСПЕВАЕМОСТЬ (НОМЕР СТУДЕНТА, ДИСЦИПЛИНА, ОЦЕНКА). Комбинация номера студента и дисциплины определяет оценку.

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

(НОМЕР СТУДЕНТА, ДИСЦИПЛИНА) ОЦЕНКА

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

В общем виде формализация этой функциональной зависимости имеет вид:

Если Х (У, Z), то X У и X Z.

Например, если НОМЕР СТУДЕНТА (ИМЯ СТУДЕНТА, ФАМИЛИЯ

СТУДЕНТА), то НОМЕР СТУДЕНТА ИМЯ СТУДЕНТА и НОМЕР

СТУДЕНТА ФАМИЛИЯ СТУДЕНТА.

Если (X, У) Z, то в общем случае неверно, что X У или X Z.

Следовательно, если (НОМЕР СТУДЕНТА, ДИСЦИПЛИНА) ОЦЕНКА, то ни номер студента, ни дисциплина как таковые оценку не определяют.

При описании нормальных форм используются следующие понятия:

«функциональная зависимость между полями»; «полная функциональная зависимость между полями»; «многозначная функциональная зависимость между полями»; «транзитивная функциональная зависимость между полями»; «взаимная независимость между полями».

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

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

Многозначная функциональная зависимость между полями определяется следующим образом. Поле А многозначно определяет поле В, если для каждого значения поля А существует «хорошо определенное множество» соответствующих значений поля В. Например, если рассматривать таблицу успеваемости учащихся в школе, включающую в себя поля «ПРЕДМЕТ» (поле А) и «ОЦЕНКА» (поле В), то поле В имеет «хорошо определенное множество» допустимых значений: 1, 2, 3, 4, 5, т.е. для каждого значения поля «ПРЕДМЕТ»

существует многозначное «хорошо определенное множество» значений поля «ОЦЕНКА».

Транзитивная функциональная зависимость между полями А и С существует в том случае, если поле С функционально зависит от поля В, а поле В функционально зависит от поля А, при этом не существует функциональной зак.п.н. Тагиров В.К., к.п.н., доцент Тагирова Л.Ф. Страница 6 висимости поля А от поля В.

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

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

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

–  –  –

Рисунок 4.2 - Отношение СТУДЕНТ Ключи могут также составляться из нескольких атрибутов.

Например, если студентам разрешено одновременно посещать более одной группы, то один и тот же номер студента может появиться в разных строках таблицы, поэтому атрибут НОМЕР СТУДЕНТА не будет уникальным образом определять строку.

Для этого потребуется какое-то сочетание атрибутов; возможно, это будет комбинация (НОМЕР СТУДЕНТА, НОМЕР ГРУППЫ).

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

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

–  –  –

© к.п.н. Тагиров В.К., к.п.н., доцент Тагирова Л.Ф. Страница 8 Функциональные зависимости, ключи и уникальность У многих студентов возникает путаница с понятиями функциональной зависимости, ключа и уникальности. Чтобы избежать этой путаницы, уясните себе следующее: детерминант функциональной зависимости может в отношении быть уникальным или неуникальным. Если нам известно, что А определяет В и что А и В находятся в одном и том же отношении, мы все равно не знаем, является ли А уникальным в этом отношении. Мы знаем только то, что А определяет В.

Например, в отношении СТУДЕНТ (рисунок 4.2) атрибут НОМЕР ГРУППЫ функционально определяет атрибут СПЕЦИАЛЬНОСТЬ, однако номер конкретной группы может, тем не менее, фигурировать в нескольких строках отношения.

Функциональная зависимость говорит только о том, что везде, где атрибуту НОМЕР ГРУППЫ соответствует атрибут СПЕЦИАЛЬНОСТЬ, конкретному значению атрибута НОМЕР ГРУППЫ всегда соответствует одно и то же значение атрибута СПЕЦИАЛЬНОСТЬ. То есть, студент, посещающий группу № 41 всегда обучается по специальности ПОВТАС, независимо от того, сколько раз группа № 41 фигурирует в таблице.

В отличие от детерминантов, ключи всегда являются уникальными. Ключ функционально определяет целую строку. Если бы значения ключей дублировались, дублировался бы и весь кортеж. Но это недопустимо, поскольку по определению, строки в отношении должны быть уникальными. Таким образом, когда мы говорим, что атрибут (или комбинация атрибутов) является ключом, мы знаем, что этот атрибут или комбинация будут уникальными. Например, если сочетание (НОМЕР СТУДЕНТА, НОМЕР ГРУППЫ) является ключом, то сочетание (10, Специальность) может и должно появиться в таблице только один раз.

Аномалии модификации

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

Рассмотрим опять отношение СТУДЕНТ (рисунок 4.2). Если мы удалим строку, где записаны данные о студенте с номером 40, мы потеряем не только информацию о группе № 44 но и тот факт, что студенты могли бы обучаться по специальности «Сетевые информационные технологии». Это называется аномалией удаления (delete anomaly) - то есть, удаляя факты, относящиеся к одной сущности (студент с номером 40 обучается по специальности СИТ), мы непроизвольно удаляем факты, относящиеся к другой сущности (в группе №44 обучек.п.н. Тагиров В.К., к.п.н., доцент Тагирова Л.Ф. Страница 9 ние производится по специальности СИТ). Выполнив одну операцию удаления, мы теряем информацию о двух сущностях.

На примере того же самого отношения можно продемонстрировать аномалию вставки (insertions anomaly). Предположим, мы хотим записать в базу данных тот факт, что студент группы №44 обучается по экономической специальности, однако мы не можем ввести эти данные в отношение СТУДЕНТ, пока хотя бы один студент не запишет в группу № 44 по новой специальности. Это ограничение выглядит глупо. Почему для того, чтобы указать новую специальность, требуется ждать, когда кто-нибудь запишется в эту группу? Это ограничение называется аномалией вставки. Суть его в том, что мы не можем записать в таблицу некоторый факт об одной сущности, не указав дополнительно некоторый факт о другой сущности.

Отношение, показанное на рисунке 4.2 может быть использовано в приложениях баз данных, но оно имеет явные проблемы. Мы можем устранить как аномалию удаления, так и аномалию вставки, разделив отношение СТУДЕНТ на два отношения, каждое из которых будет содержать информацию на определенную тему. Например, в одно отношение мы поместим атрибуты НОМЕР СТУДЕНТА и НОМЕР ГРУППЫ (назовем это отношение СТУДЕНТГРУППА), а в другое - атрибуты НОМЕР ГРУППЫ и СПЕЦИАЛЬНОСТЬ (назовем это отношение ГРУППА - СПЕЦИАЛЬНОСТЬ).

Эти два новых отношения с данными из нашего примера изображены на рисунке 4.5.

СТУДЕНТ-ГРУППА ГРУППА - СПЕЦИАЛЬНОСТЬ

ПОВТАС АСОИУ СИТ Рисунок 4.5 - Разбиение отношения СТУДЕНТ на два отношения Теперь, если мы удалим запись о студенте с номером 10 из таблицы СТУДЕНТ-ГРУППА, мы уже не потеряем тот факт, что группа № 41 обучается по специальности ПОВТАС. Более того, мы можем добавить в таблицу ГРУППА - СПЕЦИАЛЬНОСТЬ нового студента по новой специальности, не дожидаясь, пока кто-либо запишется в эту группу. Таким образом, аномалии удаления и вставки устранены.

Разбиение одного отношения на два имеет, однако, один недостаток.

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

Например, студент с номером 10 хочет записаться в группу № 45 по ускоренному обучению. Мы можем вставить соответствующую строку в отношение СТУДЕНТ- ГРУППА (строка будет содержать запись 10, 45), но следует ли это делать? Стоит ли разрешать студенту записываться в группу, которая отсутствует в отношении ГРУППА - СПЕЦИАЛЬНОСТЬ? Другими словами, должна ли система каким-либо образом препятствовать добавлению строк в таблицу © к.п.н. Тагиров В.К., к.п.н., доцент Тагирова Л.Ф. Страница 10 СТУДЕНТ-ГРУППА, если название соответствующей секции отсутствует в таблице ГРУППА - СПЕЦИАЛЬНОСТЬ? Ответ на этот вопрос содержится в требованиях пользователей. Если такое действие должно быть запрещено, данное ограничение (а это не что иное, как условия делового регламента) необходимо внести в схему базы данных. Позже, на стадии реализации, выполнение этого ограничения будет возложено на СУБД, если используемая СУБД предоставляет такую возможность. Если нет, то соблюдение ограничения должно обеспечиваться прикладными программами.

Допустим, пользователи указывают, что группы могут существовать и до того, как кто-либо в них запишется, однако студент не может записаться в группу, для которой не указана специальность (то есть в группу, данные о которой отсутствуют в таблице ГРУППА - СПЕЦИАЛЬНОСТЬ.

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

«множество значений атрибута НОМЕР ГРУППЫ в таблице СТУДЕНТГРУППЫ является подмножеством множества значений атрибута НОМЕР ГРУППЫ в таблице ГРУППА – СПЕЦИАЛЬНОСТЬ»;

«СТУДЕНТ - ГРУППА [Номер группы] является подмножеством множества ГРУППА - СПЕЦИАЛЬНОСТЬ [Номер группы]».

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

Ограничения, подобные этому, называются ограничениями ссылочной целостности (referential integrity constraints), или ограничениями целостности по внешнему ключу (inter – relation constraints)

Суть нормализации

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

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

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

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

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

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

Основные свойства НФ:

- каждая следующая НФ является в некотором смысле лучше предыдущей;

- при переходе к следующей НФ свойства предыдущих нормальных форм сохраняются.

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

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

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

Допустим, что отношение «УСПЕВАЕМОСТЬ» (рисунок 4.6) содержит всю информацию о студенческой группе и оценках.

УСПЕВАЕМОСТЬ

–  –  –

Для отношения УСПЕВАЕМОСЬ имеем в качестве первичного ключа комбинацию {NS, KP}. Кроме того, имеет место функциональная зависимость номера группы студента и его специальности, то есть NG SP. Если построить диаграмму функциональных зависимостей для этого отношения, то она будет иметь вид, представленный на рисунке 4.7.

© к.п.н. Тагиров В.К., к.п.н., доцент Тагирова Л.Ф. Страница 12 NS NG

–  –  –

Рисунок 4.7 - Диаграмма функциональных зависимостей для отношения

УСПЕВАЕМОСТЬ

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

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

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

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

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

Такая структура позволит выполнить без проблем: операцию INSERT даже при отсутствии информации о сданных экзаменах; операцию DELETE над оценками без потери информации о студенте; операцию UPDATE без необходимости исправления данных во всех кортежах, относящихся к переводимому в другую группу студенту.

–  –  –

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

Два новых отношения находятся во 2НФ с первичными ключами соответственно {NS, KP} и NS. Действительно, если над этими отношениями произвести соединение по атрибуту NS, то получим исходное отношение.

Однако в отношении СПЕЦИАЛЬНОСТЬ (рисунок 4.9) из-за функциональной зависимости NG Sp все равно могут возникнуть проблемы при манипуляции с данными.

NG

–  –  –

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

Для решения вновь возникших проблем заменим отношение СПЕЦИАЛЬНОСТЬ на две проекции – ГРУППА и СПЕЦИАЛЬНОСТЬ (рисунок 4.10).

<

–  –  –

Рисунок 4.10 - Диаграмма функциональных зависимостей отношений

ГРУППА и СПЕЦИАЛЬНОСТЬ

Действительно, путем декомпозиции была исключена "двойная" зависимость атрибута Sp от первичного ключа NS и атрибута NG.

Отношение находится в ЗНФ в том случае, если оно находится во 2НФ, неключевые атрибуты взаимно независимы (исключены так называемые транзитивные зависимости) и каждый неключевой атрибут неприводимо зависит от первичного ключа (то есть возможно изменять значение атрибутов без изменения первичного ключа и других неключевых атрибутов).

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

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

Введя данное понятие, можно дать определение НФБК.

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

Если проанализировать рассмотренные выше примеры то можно сказать, что отношение УСПЕВАЕМОСТЬ не находится в НФБК, а отношения ОЦЕНКА, ГРУППА, СПЕЦИАЛЬНОСТЬ находятся в НФБК.

Действительно, отношение УСПЕВАЕМОСТЬ содержит три детерминанта – NS, NG и {NS, KP}, из которых только {NS, KP} является потенциальным ключом. Отсюда и сделан вывод, что отношение УСПЕВАЕМОСТЬ не находится в НФБК.

Для отношений ОЦЕНКА, ГРУППА, СПЕЦИАЛЬНОСТЬ можно говорить о том, что они находятся в НФБК, поскольку в каждом из них единственный потенциальный ключ является единственным детерминантом.

Рассмотрим отношение СТУДЕНТ, показанное на рисунке 4.11, которое отображает связи между студентами, специальностями и секциями. Предположим, что студенты могут иметь несколько специальностей и изучают различные © к.п.н. Тагиров В.К., к.п.н., доцент Тагирова Л.Ф. Страница 15 типы СУБД. В таком случае единственным ключом является комбинация (НОМЕР СТУДЕНТА, СПЕЦИАЛЬНОСТЬ, СУБД). Например, студент с номером 10 специализируется на ПОВТАС и САПР и, кроме того, изучает СУБД Access и InterBasa, а студент с номером 15 специализируется только на ЛВС и занимается СУБД Oracle.

Какова связь между атрибутами НОМЕР СТУДЕНТА и СПЕЦИАЛЬНОСТЬ? Это не функциональная зависимость, поскольку у студента может быть несколько специальностей. Одному и тому же значению атрибута НОМЕР СТУДЕНТА может соответствовать много значений атрибута СПЕЦИАЛЬНОСТЬ. Помимо того, одному и тому же значению атрибута НОМЕР СТУДЕНТА может соответствовать много значений атрибута СУБД.

Такая зависимость атрибутов называется многозначной зависимостью (multi-value dependency). Многозначные зависимости приводят к аномалиям модификации.

Для начала обратим внимание на избыточность данных в отношении СТУДЕНТ (рисунок 4.11). Студенту с номером 10 посвящено четыре записи, в каждой из которых указана одна из ее специализаций и одна из изучаемых СУБД. Если бы те же данные хранились в меньшем количестве строк (скажем, было бы две строки — одна для ПОВТАС и Access, а другая - для САПР и InterBase), это дезориентировало бы пользователей. Получалось бы, что студент с номером 10 изучает Access только тогда, когда специализируется на ПОВТАС, а в InterBasa работает только тогда, когда специализируется на САПР. Но такая интерпретация нелогична. Специальности и СУБД совершенно независимы друг от друга. Поэтому, чтобы избежать таких неверных заключений, мы храним все сочетания специальностей и СУБД.

Допустим, что студент с номером 10 решил изучать СУБД SQL Server, и поэтому мы добавляем в таблицу строку [10, ПОВТАС, SQL Server], как показано на рисунке 4.12, а. В этом случае из анализа отношения можно сделать вывод, что студент 10 занимается SQL Server только как специалист ПОВТАС, но не как специалист САПР. Чтобы данные имели согласованный характер, мы должны добавить столько строк, сколько имеется специальностей, и в каждой из них указать тип СУБД SQL Server. Таким образом, мы должны добавить строку [10, САПР, SQL Server ], как показано на рисунке 4.12, 6. Это аномалия обновления: требуется слишком много модификаций, чтобы внести одно простое изменение.

СТУДЕНТ (Номер Студента, Специальность, СУБД) Ключ: (Номер Студента, Специальность, СУБД)

Многозначные зависимости:

Номер Студента Специальность Номер Студента СУБД

–  –  –

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

Другими словами, в отношении R (А, В, С) существует многозначная зависимость, если А многозначным образом определяет В и С, а сами В и С не зависят друг от друга. Как мы видели из предыдущего примера, НОМЕР СТУДЕНТА многозначно определяет атрибуты СПЕЦИАЛЬНОСТЬ и СУБД, но сами атрибуты СПЕЦИАЛЬНОСТЬ и СУБД не зависят друг от друга.

Вернемся вновь к рисунку 4.11. Обратите внимание на то, как обозначаются многозначные зависимости: Номер Студента Специальность и Номер Студента Секция. Это читается следующим образом: «атрибут НОМЕР СТУДЕНТА многозначно определяет атрибут СПЕЦИАЛЬНОСТЬ» и «атрибут НОМЕР СТУДЕНТА многозначно определяет атрибут СЕКЦИЯ». Данное отношение находится в НФБК (2НФ — поскольку его ключом является совокупность всех атрибутов, ЗНФ — так как отсутствуют транзитивные зависимости, и НФБК — поскольку нет неключевых детерминантов). Однако, как мы убедились, оно имеет аномалии: если студент берет дополнительную специальность, мы должны добавить в отношение столько строк, в скольких секциях данный студент занимается, и в каждой из этих строк указать новую специальность. То же самое справедливо и для случая, когда студент записывается в новую секцию. Если студент отказывается от одной из специальностей, мы должны удалить все строки, где указана данная специальность. Если студент занимается в четырех секциях, то название специальности будет содержаться в четырех строках, и все эти строки необходимо будет удалить.

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

© к.п.н. Тагиров В.К., к.п.н., доцент Тагирова Л.Ф. Страница 17 СТУДЕНТ (Номер Студента, Специальность, СУБД) Ключ: (Номер Студента, Специальность, СУБД)

–  –  –

Улучшенные результирующие отношения не будут иметь аномалий. Это отношения СТУДЕНТ-СПЕЦИАЛЬНОСТЬ (Номер Студента, Специальность) и СТУДЕНТ-СУБД (Номер Студента, СУБД), приведенные на рисунке 4.13.

–  –  –

Рисунок 4.13 - Устранение многозначной зависимости © к.

п.н. Тагиров В.К., к.п.н., доцент Тагирова Л.Ф. Страница 18

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

Отношение находится четвертой нормальной форме, если оно находится в НФБК и не имеет многозначных зависимостей.

Уясним 4НФ на втором примере, рассмотрим схему отношения ПРЕДМЕТЫ, приведенную на рисунке 4.14.

–  –  –

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

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

По причине сформулированных выше условий, единственным возможным ключом отношения является составной атрибут {KP, KURS, WO} и нет никаких других детерминантов. Следовательно, отношение ПРЕДМЕТЫ находится в НФБК. Но при этом оно обладает недостатками: если, например, некоторый вид отчетности добавляется к данному курсу, необходимо вставить в отношение ПРЕДМЕТЫ столько кортежей, сколько видов отчетности в нем предусмотрено.

Таким образом, в данном отношении существуют многозначные зависимости.

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

В отношении ПРЕДМЕТЫ существуют следующие две многозначные зависимости:

KP KURS KP WO

Дальнейшая нормализация отношений, подобных отношению ПРЕДМЕТЫ, основывается на проецировании без потерь. Здесь под последним понимается такой способ декомпозиции отношения, при котором исходное отношение полностью и без избыточности восстанавливается путем естественного © к.п.н. Тагиров В.К., к.п.н., доцент Тагирова Л.Ф. Страница 19 соединения полученных отношений.

Таким образом:

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

В нашем примере можно произвести декомпозицию отношения ПРЕДМЕТЫ в два отношения ПРЕДМЕТЫ-КУРСЫ и ПРЕДМЕТЫОТЧЕТНОСТЬ, как показано на рисунке 4.15.

–  –  –

Рисунок 4.15 - Декомпозиция отношения ПРЕДМЕТЫ Оба полученных отношений находятся в 4НФ и свободны от отмеченных выше проблем.

Во всех рассмотренных до этого момента примерах нормализация производилась методом декомпозиции одного отношения в два. Иногда это сделать не удается, но возможна декомпозиция в большее число отношений, каждое из которых обладает лучшими свойствами. Рассмотрим отношение ПРЕПОДАВАТЕЛЬ, структура которого приведена на рисунке 4.16.

–  –  –

Рисунок 4.16 - Структура отношения ПРЕПОДАВАТЕЛЬ Предположим, что один и тот же преподаватель может работать на разных кафедрах и проводить занятия по нескольким учебным предметам.

Первичным © к.п.н. Тагиров В.К., к.п.н., доцент Тагирова Л.Ф. Страница 20 ключом этого отношения является полная совокупность его атрибутов, то есть {KP, KK, TN}. В отношении отсутствуют функциональные и многозначные зависимости. Поэтому отношение находится в 4НФ. Однако в нем могут существовать проблемы, которые можно устранить путем декомпозиции в три отношения Введем понятие зависимости соединения. Отношение R (X, Y,..., Z) удовлетворяет зависимости соединения * (X, Y,..., Z) только в том случае, когда R восстанавливается без потерь путем соединения своих проекций на X, Y,.... Z.

Тогда:

Отношение находится в 5НФ (НФПС) только в том случае, когда любая зависимость соединения в отношении следует из существования некоторого возможного ключа в данном отношении.

Введем следующие имена составных атрибутов:

–  –  –

Предположим, что в отношении ПРЕПОДАВАТЕЛЬ существует зависимость соединения: * ( PK, РN, КN).

На примерах легко показать, что при вставках и удалениях кортежей из отношения ПРЕПОДАВАТЕЛЬ могут возникнуть проблемы. Их можно устранить путем декомпозиции исходного отношения в три новых отношения, представленных на рисунке 4.17.

–  –  –

Рисунок 4.17 - Декомпозиция отношения ПРЕПОДАВАТЕЛЬ 5НФ - это нормальная форма, которую можно получить путем декомпозиции на три и более отношений, при этом ее условия достаточно нетривиальны, и на практике 5НФ используется достаточно редко.

И, наконец, рассмотрим последнюю нормальную форму – ДКНФ.

© к.п.н. Тагиров В.К., к.п.н., доцент Тагирова Л.Ф. Страница 21 Все описанные выше нормальные формы были выделены исследователями, выявившими аномалии у некоторых отношений, которые находились в нормальной форме более низкого порядка: обнаружение аномалий модификации у отношений во второй нормальной форме привело к определению третьей нормальной формы и т. д. Хотя каждая новая нормальная форма решала часть проблем, найденных у предыдущей нормальной формы, никто не мог сказать, какие проблемы еще не выявлены. Каждый такой шаг являлся прогрессом на пути к представлению об оптимальной структуре базы данных, однако никто не мог гарантировать, что не будет ли обнаружено еще каких-либо аномалий.

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

В 1981г. Фагин опубликовал важную статью, в которой он определил доменно-ключевую нормальную форму.

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

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

Понятие ДКНФ весьма просто:

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

Рассмотрим важные термины, фигурирующие в этом определении: ограничение, ключ и домен.

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

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

© к.п.н. Тагиров В.К., к.п.н., доцент Тагирова Л.Ф. Страница 22 Ключ (Key) — это уникальный идентификатор кортежа, как мы его уже знаем.

Третий важный термин в определении ДКНФ — домен (domain). Мы уже уяснили ранее, что домен — это описание допустимых значений атрибута. Он состоит из двух частей: физического описания и семантического (логического) описания. Физическое описание — это множество значений, которые может принимать атрибут, а логическое описание — это смысл данного атрибута. Доказательство Фагина относится к обеим частям.

Говоря неформально, отношение находится в ДКНФ, если выполнение ограничений на домены и ключи приводит к выполнению всех ограничений и отношения в ДКНФ не могут иметь аномалий модификации.

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

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

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

Заключение

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

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

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

В результате будет получен набор отношений в ЗНФ.

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

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

Отношения в 4НФ разбивают на проекции с целью исключения любых зависимостей соединения, которые не обусловлены потенциальными ключами.

Таким образом будет получен набор отношений в 5НФ.

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

Вопросы для самоконтроля:

1. Какие классы нормальных форм могут быть в базах данных?

2. Объясните понятие «функциональная зависимость».

3. Какие правила формализации функциональных зависимостей вы знаете?

4. Что называется, полной функциональной зависимостью?

5. Что называется, многозначной функциональной зависимостью?

6. Что называется, транзитивной функциональной зависимостью?

7. Что называется, взаимной функциональной независимостью?

8. Поясните какие аномалии могут быть в базах данных?

9. Объясните суть нормализации.

10.Объясните требования к 1НФ.

11.Объясните требования ко 2НФ.

12.Объясните требования к 3НФ.

13.Объясните требования к НФБК.

14.Объясните требования к 4НФ.

15.Объясните требования к 5НФ.

16.Объясните требования к ДКНФ.

Похожие работы:

«СОДЕРЖАНИЕ ВВЕДЕНИЕ 1. АНАЛИЗ ТРУДА И ЗАРАБОТНОЙ ПЛАТЫ 1.1 Задачи анализа труда и заработной платы 1.2 Направления и информационное обеспечение анализа 1.3 Методика анализа фонда заработной платы 1.4 Анализ производительности труда 2. ОРГАНИЗАЦИОННО-ЭКОНОМИЧЕСКАЯ ХАРАКТЕРИСТИКА ПРЕДПРИЯТИЯ ОАО "АРНЕСТ" 2.1 Характеристика предп...»

«Самый мелкий (Северный Ледовитый) Самый теплый (Индийский) Самый вытянутый (Атлантический) Самый глубокий (Тихий) Задание 3. Подпишите материки и океаны на контурной карте. Задание 4. Найди линию экватора. Какие материки она пересекает? О чем нам говорит линия экватора. Какие материки и...»

«ФЕДЕРАЛЬНОЕ АГЕНТСТВО НАУЧНЫХ ОРГАНИЗАЦИЙ ИНСТИТУТ АРХЕОЛОГИИ И ЭТНОГРАФИИ СИБИРСКОГО ОТДЕЛЕНИЯ РОССИЙСКОЙ АКАДЕМИИ НАУК ГЕРМАНСКИЙ АРХЕОЛОГИЧЕСКИЙ ИНСТИТУТ ЕВРАЗИЙСКОЕ ОТДЕЛЕНИЕ МИНИСТЕРСТВО Н...»

«ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ "РОССИЙСКИЙ ГОСУДАРСТВЕННЫЙ СОЦИАЛЬНЫЙ УНИВЕРСИТЕТ" УТВЕРЖДАЮ И.о. проректора по научной работе _ А.Н. Малолетко ПРОГРАММА ГОСУДАРСТВЕННОГО ЭКЗАМЕНА Код п...»

«Е.В.Пацар, Алтайский государственный университет Текстовые стратегии в создании политической рекламы регионального политика Политическая реклама – одно из важнейших направлений рекламной индустрии. Уже из самого названия следует, что используется она в области политики для побуждения людей голосовать, делать свой выбор, отдавать...»

«182 Liberal Arts in Russia. 2016. Vol 5. No. 2 DOI: 10.15643/libartrus-2016.2.7 Неформальный (низовой) социальный контроль наркотизации: Контекст стигмы © А. А. Яковлева Социологический институт Российской академии наук Россия, 190005 г. Санкт-Петербург, ул. 7-ая Красноармейск...»

«Информация для клиентов 1 8 февраля 2016 г. Информация для клиентов Принят Федеральный Закон О юрисдикционных иммунитетах МОСКВА 3 ноября 2015 года Президентом Российской Федерации был подписан Алена Н. Кучер ankucher@debevoise.com Фе...»

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

«ИСКУССТВО ВОСТОЧНО-ХРИСТИАНСКОГО МИРА ИСКУССТВО ВОСТОЧНО-ХРИСТИАНСКОГО МИРА Образ священства в росписях Софии Киевской Часть II. Программа Софийского собора и древнерусские памятники XI–XII столетий* Владимир С...»

«Российская академия естественных наук Ноосферная общественная академия наук Европейская академия естественных наук Петровская академия наук и искусств Ассоциация ноосферного обществознания и образования _ Международная академия гармоничного развития человечества (Ю...»

«НАСТАВЛЕНИЯ К ПРАКТИКЕ. Я очень рад видеть вас здесь сегодня. После этой лекции мы с вами расстанемся на несколько месяцев. Потом встретимся вновь. Встречи и расставания – это природа жизни. Поэтому вы должны научитьс...»

«ГЕОФИЗИЧЕСКИЕ ИССЛЕДОВАНИЯ, 2014, том 15, № 1, с.27-52 УДК 532.68 ЭМПИРИЧЕСКИЕ ПАРАМЕТРЫ МОДЕЛИ ПРОТИВОТОЧНОЙ КАПИЛЛЯРНОЙ ПРОПИТКИ ГОРНЫХ ПОРОД 2014 г. В.Л. Барабанов Институт проблем нефти и газа РАН, г. Москва, Россия Выполнен обзор известных теоретических моделей противоточной капиллярной пропи...»







 
2017 www.doc.knigi-x.ru - «Бесплатная электронная библиотека - различные документы»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.