Лекции по Базам данных. лекции. Развитие технологий обработки данных

• Название: Развитие технологий обработки данных
• Анкор: Лекции по Базам данных
• Дата: 16.02.2023
• Размер: 0.53 Mb.
• Имя файла: лекции.docx
• Тип: Документы; #940385
• страница: 15 из 22

Основные этапы построения.

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

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

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

      присвоить этой сущности имя;

      выявить атрибуты сущности и присвоить им имя;

      определить уникальный идентификатор сущности.

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

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

      то, как экземпляр одной сущности связан с экземпляром другой сущности;

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

Далее необходимо присвоить связям имена и определить тип связей.

На втором этапе построенные локальные модели объединяются в обобщенную концептуальную модель.

Моделирование локальных представлений.

Построенная модель должна удовлетворять ряду требований:

      адекватно отражать представление пользователя о данных;

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

      представлять данные с минимальным дублированием.

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

Вариативность моделирования обусловливается неоднозначностью выбора сущностей, атрибутов и связей. В одном варианте можно что-то взять за сущность, в другом варианте это же можно взять за атрибут (несколько атрибутов), в третьем варианте это можно определить как связь. Так, например, ранее мы определили сущность ФАКУЛЬТЕТ с атрибутами «номер факультета», «название факультета». Введем сущность КАФЕДРА с атрибутами «номер кафедры», «название кафедры». Между этими сущностями есть связь «факультет состоит из кафедр». Возможен другой вариант, в котором вышеуказанная связь представляется через атрибуты сущности (у сущности ФАКУЛЬТЕТ введем дополнительные атрибуты, представляющие номера и названия всех кафедр этого факультета).

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

      устраняются расплывчатые наименования (все наименования должны однозначно пониматься каждым пользователем);

      устраняются синонимы (различные наименования одного и того же понятия);

      устраняются омонимы (одно и то же наименование разных понятий).

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

Объединение локальных моделей.

На этапе объединения построенные ранее модели локальных представлений отдельных пользователей (или групп пользователей) объединяются в единую концептуальную модель. Объединение локальных моделей производится следующими путями:

      слияние идентичных элементов;

      установление связей между наборами сущностей разных моделей;

      введение новых агрегированных элементов для представления связей между элементами разных моделей;

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

Рассмотрим каждый из этих путей.

Слияние идентичных элементов.

Два или более элементов модели идентичны, если они имеют одинаковое смысловое значение.

Объединение моделей с идентичными элементами осуществляется путем «слияния» этих элементов в один. Два набора сущностей СПЕЦИАЛЬНОСТЬ в модели 1 и 2 имеют одинаковое смысловое значение (Рис. 5.5.), и могут быть заменены одним набором сущностей (Рис. 5.6.).



Рисунок 5.5 – Модели с идентичным элементом



Рисунок 5.6 – Объединенная модель

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

Введение агрегированных элементов.

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



Рисунок 5.7. – Локальные представления

Объединяя локальные представления, устанавливаем новые связи (Рис. 5.8).



Рисунок 5.8 – Объединение локальных представлений

Показателем «зрелости» модели является возможность ответа на запросы пользователей, и установление связей преследует именно эту цель. Нетрудно видеть, что какие бы связи в рассматриваемой модели ни вводились, невозможно ответить на запрос «какую оценку получил студент А по дисциплине В». В таком случае необходимо использовать принцип агрегации – необходимую связь между элементами модели ввести как некоторый новый элемент. В данном примере можно определить этот новый агрегированный элемент как ЭКЗАМЕН СТУДЕНТА (Рис. 5.9).



Рисунок 5.9 – Агрегированный элемент

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

Обобщение подобных типов сущностей.

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



Рисунок 5.10 – Модели с подобным элементом

Два набора сущностей CПЕЦИАЛЬНОСТИ ФАКУЛЬТЕТА ВМК и СПЕЦИАЛЬНОСТИ ЭКОНОМИЧЕСКОГО ФАКУЛЬТЕТА в моделях 1 и 2 имеют одинаковое смысловое значение и могут быть заменены одним набором сущностей с добавлением нового атрибута – название факультета (Рис. 5.11).



Рисунок 5.11 – Пример обобщенной сущности

Отметим, что в данном случае подобным образом можно слить и все остальные сущности локальных моделей факультетов, так как сущности СТУДЕНТЫ ЭКОНОМИЧЕСКОГО ФАКУЛЬТЕТА и СТУДЕНТЫ ВМК также имеют одинаковое смысловое значение и их также можно объединить. Однако в общем случае каждая локальная модель может содержать сущности и связи, которых нет в других локальных моделях.

Рассмотрим другой пример. Предположим, что мы храним данные о студентах (фамилия, имя, отчество, курс, группа) и о преподавателях (фамилия, имя, отчество, кафедра, должность). Соответственно, в предметной области выделяем две сущности – СТУДЕНТ и ПРЕПОДАВАТЕЛЬ.

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



Рисунок 5.12 – Пример обобщенной сущности

У студента атрибут «Место работы (учебы)» будет принимать значение соответствующее атрибутам «Курс. Группа», у преподавателя – название кафедры. Обобщенная модель представлена на рисунке 5.13.



Рисунок 5.13 – Обобщенная модель

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

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

 

Нормальные формы отношений

Первая нормальная форма

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

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

В этом определении утверждается только то, что любое нормализованное отношение находится в первой нормальной форме (1НФ). Однако отношение, которое находится только в 1НФ (т.е. не находится ни во второй, ни в третьей нормальной форме) обладает структурой, по некоторым причинам не совсем желательной. Например, допустим, что информация о студентах и оценках содержится не в 2-х отношениях Students и Marks а в одном, назовем его SМ.

SМ{StNo, CityNo, GrNo, SubjNo, DocNo, Mark}

РRIMАRY КЕY (StNo, GrNo, SubjNo, DocNo).

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



Рисунок 0.1 – Диаграмма функциональных зависимостей отношения SМ

Особо отметим, что диаграммы ФЗ отношения SM «сложнее», чем диаграммы ФЗ отношений Students и Мarks, из которых оно образовано. В диаграммах ФЗ отношений Students и Мarks все стрелки берут начало только от первичных ключей, тогда как в диаграмме ФЗ отношения SМ появляются дополнительные стрелки. На рисунке 6.2 приведена таблица данных для отношения SМ.

Тем не менее, что отношение SM, как и Students и Мarks находится в 1-й НФ. Очевидно, оно обладает избыточностью, так как (в данном случае) в каждом кортеже для студента Иванова указан его номер «1», код его группы – «1» и код города, в котором он проживает – «1». Аналогичная ситуация с другими студентами.



Рисунок 0.2. – Данные отношения SМ

Избыточность в отношении SМ приводит к разным аномалиям обновления, (это обозначение связано с историческими причинами) т.е. к сложностям при совершении операций обновления типа INSERТ (вставка), DELЕТЕ (удаление) и UPDАТЕ (обновление). Как пример рассмотрим избыточность типа студент - код города студента, соответствующую функциональной зависимости StNo СityNo, и приведенные ниже проблемы с операциями обновления.

Операция вставки (INSЕRТ). Не допускается ввод данных о студенте, проживающем в некотором городе, без указания хотя бы одной, полученной им оценки. Втаблице SМ нет данных о студенте Сидорове из г. Видное в связи с тем, что до тех пор, пока этот студент не получит оценку по какой-либо дисциплине, для него не задано значение первичного ключа.

Операция удаления (DELЕТЕ). Если удалить единственный кортеж отношения SМ для некоторого студента, будет удалена не только информация о соответствующей оценке, но и информация о студенте и городе, в котором он проживает. Например, если в отношении SМ удалить кортеж со значением Петров атрибута StName, будет потеряна вся информация об этом студенте.

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

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

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

Studеnts{StNо, GrNо, StNamе, СityNо} и Маrks{StNо, SubjNо, DocNо, Маrk}

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

Операция вставки (INSЕRТ). При помощи вставки соответствующего кортежа в отношение Studеnts можно включить информацию о студенте и городе, в котором он проживает, даже если он в настоящий момент не получил ни одной оценки.

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

Операция модификации (UPDАТЕ). Поскольку существует только один кортеж для данного студента в отношении Studеnts (атрибут StNо является первичным ключом для такого отношения), в переработанной структуре фамилия студента и информация о городе, в котором он проживает, появляется всего один раз, т.е., избыточность данных StNо-StNаmе-StСity устранена. Благодаря этому появилась возможность один раз изменить в соответствующем кортеже отношения Studеnts название города для какого-либо студента.

Вторая нормальная форма

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

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

Оба отношения, Studеnts и Мarks находятся во второй нормальной форме с первичными ключами StNp и {StNо, SubjNо, DосNо} т.е, отношение SM не находится в ней. Любое отношение, которое находится в 1НФ и не находится в 2НФ, возможно свести к эквивалентному набору отношений, находящихся в 2НФ.

Например, предположим, что информация о коде города, названии города и области, в которой этот город находится, представлены в одной таблице СNR{СitуNо, СityNаme, RgNо, RgNаmе}(Рис. 6.3).



Рисунок 0.3 – Данные отношения СNR

Диаграмма ФЗ отношения СNR выглядит следующим образом – рисунок 6.4.



Рисунок 0.4 – Функциональные зависимости в отношении СNR

На рисунке 6.3 видно, что диаграмма ФЗ «сложнее» диаграмм ФЗ отношений Сitiеs и Rеgiоns. Несмотря на то, что отношение СNR находится в 2НФ, оно обладает некоторой избыточностью, связанной с наличием транзитивной ФЗ между атрибутами СityNо и RgNаmе. Транзитивная зависимость приводит к следующим аномалиям обновления.

Операция вставки (INSЕRТ). Нельзя включить данные о некоторой области. Так, например, нельзя указать, что существует Тульская область, до ввода данных о городе, находящемся в данной области, – например о Новомосковске.

Операция удаления (DЕLЕТЕ). При удалении из отношения СNR последнего кортежа для некоторого города будет удалена не только информация о данном городе, но также информация о том, в какой области этот город находился. Например, при удалении из отношения СNR кортежа для города Новомосковск автоматически удалится информация о Тульской области.

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