Лекция Введение в бд и субд. Модели данных 2 Лекция Инфологическая модель «Сущность-связь» icon

Лекция Введение в бд и субд. Модели данных 2 Лекция Инфологическая модель «Сущность-связь»


Смотрите также:
Лекция №07 Модели данных...
Лекция №07 Модели данных...
Лекция Введение...
Ы включенные в пособие Разделы не вошедшие в пособие Тип пособия...
Инфологическая модель данных "Сущность-связь"...
Лекция №5 диаграммы «сущность-связь» Диаграммы "сущность-связь" (erd)...
Учебно-методический комплекс дисциплины «Информационные системы» Специальность...
Системы управления базами данных (субд). Функции субд базы данных (БД)...
Лекция 1) гис как специализированная информационная система. Структура информационных систем...
Лекция №1: Стандарты языка sql...
Лекция База данных. Понятие сущностей и связей...
Программа междисциплинарного вступительного экзамена для поступающих в магистратуру по...



Загрузка...
страницы:   1   2   3   4   5   6   7   8   9   10   11
скачать


Лекции по дисциплине

Инструментальные программные средства”



Лекция 1. Введение в БД и СУБД. Модели данных 2

Лекция 2. Инфологическая модель «Сущность-связь» 14

Лекция 3. Нормализация 24

Лекция 4. Целостность реляционных данных 40

Лекция 5. Основы SQL: запросы к базе данных 50

Лекция 6. Табличный процессор Microsoft Excel. Назначение и интерфейс 55

Лекция 7. Построение графиков и основы статистического анализа в Excel 65

Лекция 8. Основы работы в системе MathCAD. 92

Лекция 9. Программирование в Mathcad, Интерполяция и регрессия, функции сглаживания данных и предсказания. 104



^

Лекция 1. Введение в БД и СУБД. Модели данных




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

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

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

Второе направление – это хранение и обработка данных. Целью любой информационной системы является хранение и обработка данных о каких-либо объектах реального мира.

Давайте рассмотрим такие важные для нас понятия как «данные» и «информация». Несмотря на огромное количество определений для этих понятий остановимся на следующих определениях.

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

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

^ В широком смысле слова термин «база данных» (БД) – это совокупность сведений о конкретных объектах.

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

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

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

^ Файлы, снабженные описанием хранимых в них данных и находящиеся под управлением СУБД, стали называть БД.


Домашнее задание - перечислить функции СУБД


Функции СУБД

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

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

Защита от отказов и восстановление (журнализация)

Обеспечение различных уровней доступа к данным
^

Модели данных


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

  • инфологические,

  • даталогические,

  • физические.
    1. Инфологическая модель данных [1]


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

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

или по-другому

Инфологическая модель данных - обобщенное, непривязанное к каким-либо СУБД описание предметной области.

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

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

      1. ^

        Семантические сети [2]


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



Рис. 1. Пример семантической сети


На этом примере видно, что между объектами Поставщик и Поставка определено отношение "агент", между объектами Изделие и Поставка определено отношение "объект" и т.д.

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

Агент - это то, что (тот, кто) вызывает действие. Агент часто является подлежащим в предложении, например, "Робби ударил мяч".

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

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

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

Пункт отправления и пункт назначения - это отправная и конечная позиции при перемещении агента или объекта: "Робби перешел из комнаты в библиотеку".

Траектория - перемещение от пункта отправления к пункту назначения: "Они прошли через дверь по ступенькам на лестницу".

Средство доставки - то в чем или на чем происходит перемещение: "Он всегда едет домой на метро".

Местоположение - то место, где произошло (происходит, будет происходить) действие, например, "Он работал за столом".

Потребитель - то лицо, для которого выполняется действие: "Робби собрал кубики для Суззи".

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

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

Наиболее типичный способ вывода в семантических сетях (СС) - это способ сопоставления частей сетевой структуры. Это видно на следующем простом примере, представленном на рис. 2.


Рис. 2. Процедура сопоставления в СС


Куб Cube принадлежит миру BlockWorld.

Куб Cube_001 есть разновидность куба Cube.

Легко сделать вывод:

Куб Cube_001 есть часть мира BlockWorld.


Еще один пример поиска в СС. Представим вопрос "какой объект находится на желтом блоке?" в виде подсети, изображенной на рис. 3. Произведем сопоставление вопроса с сетью, представленной на рис. 4. В результате сопоставления получается ответ - "Пирамида".


Рис. 3. Вопрос в виде CC


Рис. 4. Процедура сопоставления в СС




    1. ^

      Даталогическая модель


Инфологическая модель должна быть отображена в даталогическую модель, «понятную» СУБД.

Даталогическая модель – описание на языке конкретной СУБД.

      1. ^

        Иерархическая модель


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

Количество деревьев в БД определяется количеством корней деревьев. К каждой записи БД существует единственный путь от корневой записи.

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

Еще один пример – это система доменных имен в Интернете.

Типичным представителем СУБД (наиболее известным и распространенным), основанной на иерархической модели, является Information Management System (IMS) фирмы IBM. Первая версия появилась в 1968 г.



Рис. 5 Пример иерархической модели


Здесь Отдел является предком для Начальник и Сотрудники, а Начальник и Сотрудники - потомки Отдел. Между типами записи поддерживаются связи.

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



Рис. 6 Пример иерархической модели


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


      1. ^

        Сетевая модель [3, 4]


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

Сетевой подход к организации данных является расширением иерархического.

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



Рис. 7. Схема сетевой модели


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

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

Типичным представителем является Integrated Database Management System (IDMS) компании Cullinet Software, Inc., предназначенная для использования на машинах основного класса фирмы IBM под управлением большинства операционных систем. Архитектура системы основана на предложениях Data Base Task Group (DBTG), Комитета по языкам программирования Conference on Data Systems Languages (CODASYL), организации, ответственной за определение языка программирования Кобол. Отчет DBTG был опубликован в 1971 г., а в 70-х годах появилось несколько систем, среди которых IDMS.
^

СУБД на основе инвертированных файлов [5]


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

К числу наиболее известных и типичных представителей таких систем относятся Datacom/DB компании Applied Data Research, Inc. (ADR), ориентированная на использование на машинах основного класса фирмы IBM, и Adabas компании Software AG.

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

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

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

  2. Физическая упорядоченность строк всех таблиц может определяться и для всей БД (так делается, например, в Datacom/DB).

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

Поддерживаются два класса операторов:

  1. Операторы, устанавливающие адрес записи, среди которых:

    1. прямые поисковые операторы (например, найти первую запись таблицы по некоторому пути доступа);

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

  2. Операторы над адресуемыми записями

Типичный набор операторов:

  • LOCATE FIRST - найти первую запись таблицы T в физическом порядке; возвращает адрес записи;

  • LOCATE FIRST WITH SEARCH KEY EQUAL - найти первую запись таблицы T с заданным значением ключа поиска K; возвращает адрес записи;

  • LOCATE NEXT - найти первую запись, следующую за записью с заданным адресом в заданном пути доступа; возвращает адрес записи;

  • LOCATE NEXT WITH SEARCH KEY EQUAL - найти cледующую запись таблицы T в порядке пути поиска с заданным значением K; должно быть соответствие между используемым способом сканирования и ключом K; возвращает адрес записи;

  • LOCATE FIRST WITH SEARCH KEY GREATER - найти первую запись таблицы T в порядке ключа поиска K cо значением ключевого поля, большим заданного значения K; возвращает адрес записи;

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

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

  • DELETE - удалить запись с указанным адресом;

  • STORE - включить запись в указанную таблицу; операция генерирует адрес записи.

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

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

Пример


      1. ^

        Реляционная модель


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

Эта модель данных будет подобно рассмотрена позже.


Задание. Подготовить доклады на тему «Объектно-ориентированная модель данных» и «документно-ориентированная модель данных».

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


Задание. Назовите примеры СУБД, построенных на основе иерархических, сетевых, реляционных, документно-ориентированных, объектно-ориентированных моделей данных.
  1. ^

    Физическая модель [3]


На основе даталогической модели строится физическая модель.

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

Пример. В частности для реляционной БД она уже учитывает:

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

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

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

Архитектура БД

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

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

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

В основе концепции клиент-сервер лежит идея о том, что помимо хранения файлов БД, центральный сервер должен выполнять основную часть обработки данных. Пользователи обращаются к серверу с помощью специального языка структурированных запросов (SQL, Structed Query Language), на которм описывается список задач, выполняемых сервером. Запросы принимаются сервером и порождают процессы обработки данных. В ответ пользователь получает уже отработанный набор данных. Технология клиент-сервер позволяет избежать передачи по сети огромных объемов информации, переложив всю обработку на центральный сервер. Такой подход также позволяет избежать конфликтов при редактировании одних и тех же данных множеством пользователей.

^ Трехуровневая архитектура («Тонкий клиент» - сервер приложений - сервер базы данных)функционирует в Интранет- и Интернет-сетях..

Клиентская часть ("тонкий клиент"), взаимодействующая с пользователем, представляет собой HTML-страницу в Web-браузере либо Windows-приложение, взаимодействующее с Web-сервисами. Вся программная логика вынесена на сервер приложений, который обеспечивает формирование запросов к базе данных, передаваемых на выполнение серверу баз данных. Сервер приложений может быть Web-сервером или специализированной программой (см. рис. 8).


Рис. 8. Схема работы с БД в трехуровневой архитектуре

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


Список литературы

  1. В.В. Кириллов Основы проектирования реляционных баз данных Учебное пособие Санкт-Петербургский Государственный институт точной механики и оптики

  2. http://www.intuit.ru/department/human/isrob/2/4.html

  3. Е. Мамаев MS SQL Server 2000

  4. http://www.intuit.ru/department/database/basedbw/2/2.html

  5. Основы современных баз данных С.Д. Кузнецов, информационно-аналитические материалы Центра Информационных Технологий


^

Лекция 2. Инфологическая модель «Сущность-связь»




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

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

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


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

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

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

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

^ Сущность (Entity) - реальный либо воображаемый объект, имеющий существенное значение для рассматриваемой предметной области, информация о котором подлежит хранению (рис. 1).



Рис. 1. Графическое изображение сущности

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

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

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

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

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

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




Рис. 2. Сущности.


Следующим шагом моделирования является идентификация связей.

^ Связь (Relationship) - поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области. Связь - это ассоциация между сущностями, при которой, как правило, каждый экземпляр одной сущности, называемой родительской сущностью, ассоциирован с произвольным (в том числе нулевым) количеством экземпляров второй сущности, называемой сущностью-потомком, а каждый экземпляр сущности-потомка ассоциирован в точности с одним экземпляром сущности-родителя. Таким образом, экземпляр сущности-потомка может существовать только при существовании сущности родителя.

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

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

  • продавец может получить вознаграждение за 1 или более контрактов;

  • контракт должен быть инициирован ровно одним продавцом.

Степень связи и обязательность графически изображаются следующим образом (рис. 3).



Рис. 3. Типы связей

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



Рис. 4

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



Рис. 5

Последним шагом моделирования является идентификация атрибутов.

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

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

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



Рис. 6 Обязательные и необязательные атрибуты




Рис. 7 Идентификация сущностей

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

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

С учетом имеющейся информации дополним построенную ранее диаграмму (рис. 8).

Помимо перечисленных основных конструкций модель данных может содержать ряд дополнительных.

^ Подтипы и супертипы: одна сущность является обобщающим понятием для группы подобных сущностей (рис. 9).

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



Рис. 8



Рис. 9. Подтипы и супертипы



Рис. 10. Взаимно исключающие связи

Рекурсивная связь: сущность может быть связана сама с собой (рис. 11).



Рис. 11. Рекурсивная связь


^

Методология IDEF1




Метод IDEF1, разработанный Т.Рэмей (T.Ramey), также основан на подходе П.Чена и позволяет построить модель данных, эквивалентную реляционной модели в третьей нормальной форме. В настоящее время на основе совершенствования методологии IDEF1 создана ее новая версия - методология IDEF1X. IDEF1X разработана с учетом таких требований, как простота изучения и возможность автоматизации. IDEF1X-диаграммы используются рядом распространенных CASE-средств (в частности, ERwin, Design/IDEF).

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



Рис. 12. Сущности


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

Связь может дополнительно определяться с помощью указания степени или мощности (количества экземпляров сущности-потомка, которое может существовать для каждого экземпляра сущности-родителя). В IDEF1X могут быть выражены следующие мощности связей:

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

  • каждый экземпляр сущности-родителя должен иметь не менее одного связанного с ним экземпляра сущности-потомка;

  • каждый экземпляр сущности-родителя должен иметь не более одного связанного с ним экземпляра сущности-потомка;

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

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

Связь изображается линией, проводимой между сущностью-родителем и сущностью-потомком с точкой на конце линии у сущности-потомка. Мощность связи обозначается как показано на рис. 13 (мощность по умолчанию - N).



Рис. 13. Мощность связи

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



Рис. 14. Идентифицирующая связь

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



Рис. 15. Неидентифицирующая связь

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



Рис. 16. Атрибуты и первичные ключи

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



Рис. 17. Примеры внешних ключей


ER-диаграмма должна подчиняться следующим правилам:

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

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

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

  • имя связи должно быть уникально, если для нее генерируется таблица БД;

  • каждый атрибут должен иметь определение типа данных;

  • сущность в необязательной связи должна иметь ключевой атрибут. То же самое относится к сильной сущности в слабой связи, супертипу в связи "супертип-подтип" и необязательной сущности в обязательной (полной) связи;

  • подтип в связи "супертип-подтип" не может иметь ключевой атрибут;

  • в ассоциативной или слабой связи может быть только одна ассоциативная (слабая) сущность;

  • связь не может быть одновременно обязательной, "супертип-подтип" или ассоциативной.


^

Лекция 3. Нормализация

Введение


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

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


Пример

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

  1. Сотрудники организации выполняют проекты.

  2. Проекты состоят из нескольких заданий.

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

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

  5. Над каждым заданием в проекте работает ровно один сотрудник.

  6. Каждый сотрудник числится в одном отделе.

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

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

  1. О каждом сотруднике необходимо хранить табельный номер и фамилию. Табельный номер является уникальным для каждого сотрудника.

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

  3. Каждый проект имеет номер и наименование. Номер проекта является уникальным.

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



^ 1НФ (Первая Нормальная Форма)

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

  • В отношении нет одинаковых кортежей.

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

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

  • Все значения атрибутов атомарны.



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

СОТРУДНИКИ_ОТДЕЛЫ_ПРОЕКТЫ (Н_СОТР, ^ ФАМ, Н_ОТД, ТЕЛ, Н_ПРО, ПРОЕКТ, Н_ЗАДАН)

где

Н_СОТР - табельный номер сотрудника,

ФАМ - фамилия сотрудника,

Н_ОТД - номер отдела, в котором числится сотрудник,

ТЕЛ - телефон сотрудника,

Н_ПРО - номер проекта, над которым работает сотрудник,

ПРОЕКТ - наименование проекта, над которым работает сотрудник,

Н_ЗАДАН - номер задания, над которым работает сотрудник.

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

В текущий момент состояние предметной области отражается следующими фактами:

  • Сотрудник Иванов, работающий в 1 отделе, выполняет в первом проекте "Космос" задание 1 и во втором проекте "Климат" задание 1.

  • Сотрудник Петров, работающий в 1 отделе, выполняет в первом проекте "Космос" задание 2.

  • Сотрудник Сидоров, работающий во 2 отделе, выполняет в первом проекте "Космос" задание 3 и во втором проекте "Климат" задание 2.

Это состояние отражается в таблице 1 (курсивом выделены ключевые атрибуты):


Таблица 1. Отношение СОТРУДНИКИ_ОТДЕЛЫ_ПРОЕКТЫ

Н_СОТР

ФАМ

Н_ОТД

ТЕЛ

Н_ПРО

ПРОЕКТ

Н_ЗАДАН

1

Иванов

1

11-22-33

1

Космос

1

1

Иванов

1

11-22-33

2

Климат

1

2

Петров

1

11-22-33

1

Космос

2

3

Сидоров

2

33-22-11

1

Космос

3

3

Сидоров

2

33-22-11

2

Климат

2




    1. ^

      Аномалии обновления


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

Исторически эти проблемы получили название аномалии обновления.

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

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

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

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

  • аномалии вставки (INSERT),

  • аномалии обновления (UPDATE),

  • аномалии удаления (DELETE).

В отношении СОТРУДНИКИ_ОТДЕЛЫ_ПРОЕКТЫ можно привести примеры следующих аномалий:
      1. ^

        Аномалии вставки (INSERT)


В отношение СОТРУДНИКИ_ОТДЕЛЫ_ПРОЕКТЫ нельзя вставить данные о сотруднике, который пока не участвует ни в одном проекте. Действительно, если, например, во втором отделе появляется новый сотрудник, скажем, Пушников, и он пока не участвует ни в одном проекте, то мы должны вставить в отношение кортеж (4, Пушников, 2, 33-22-11, null, null, null). Это сделать невозможно, т.к. атрибут Н_ПРО (номер проекта) входит в состав потенциального ключа, и, следовательно, не может содержать null-значений.

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

^ Причина аномалии - хранение в одном отношении разнородной информации (и о сотрудниках, и о проектах, и о работах по проекту).

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


      1. ^

        Аномалии обновления (UPDATE)


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

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

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


      1. ^

        Аномалии удаления (DELETE)


При удалении некоторых данных может произойти потеря другой информации. Например, если закрыть проект "Космос" и удалить все строки, в которых он встречается, то будут потеряны все данные о сотруднике Петрове. Если удалить сотрудника Сидорова, то будет потеряна информация о том, что в отделе номер 2 находится телефон 33-22-11. Если по проекту временно прекращены работы, то при удалении данных о работах по этому проекту будут удалены и данные о самом проекте (наименование проекта). При этом если был сотрудник, который работал только над этим проектом, то будут потеряны и данные об этом сотруднике.

^ Причина аномалии - хранение в одном отношении разнородной информации (и о сотрудниках, и о проектах, и о работах по проекту).

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


^

Функциональные зависимости


Отношение СОТРУДНИКИ_ОТДЕЛЫ_ПРОЕКТЫ находится в 1НФ, при этом, как было показано выше, логическая модель данных не адекватна модели предметной области. Таким образом, первой нормальной формы недостаточно для правильного моделирования данных.
    1. ^

      Определение функциональной зависимости


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

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

.

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

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

Пример 1. В отношении СОТРУДНИКИ_ОТДЕЛЫ_ПРОЕКТЫ можно привести следующие примеры функциональных зависимостей:

Зависимость атрибутов, характеризующих сотрудника от табельного номера сотрудника:

Н_СОТР ^ ФАМ

Н_СОТР Н_ОТД

Н_СОТР ТЕЛ

Зависимость наименования проекта от номера проекта:

Н_ПРО ПРОЕКТ

Зависимость номера телефона от номера отдела:

^ Н_ОТД ТЕЛ

Зависимость атрибутов от ключа отношения:

{Н_СОТР, Н_ПРО} ФАМ

{Н_СОТР, Н_ПРО} Н_ОТД

{Н_СОТР, Н_ПРО} ТЕЛ

{Н_СОТР, Н_ПРО} ПРОЕКТ

{Н_СОТР, Н_ПРО} Н_ЗАДАН

Замечание. Приведенные функциональные зависимости не выведены из внешнего вида отношения, приведенного в таблице 1. Эти зависимости отражают взаимосвязи, обнаруженные между объектами предметной области и являются дополнительными ограничениями, определяемыми предметной областью. Таким образом, функциональная зависимость - семантическое понятие. Она возникает, когда по значениям одних данных в предметной области можно определить значения других данных. Например, зная табельный номер сотрудника, можно определить его фамилию, по номеру отдела можно определить телефона. Функциональная зависимость задает дополнительные ограничения на данные, которые могут храниться в отношениях. Для корректности базы данных (адекватности предметной области) необходимо при выполнении операций модификации базы данных проверять все ограничения, определенные функциональными зависимостями.
    1. ^

      Функциональные зависимости отношений и математическое понятие функциональной зависимости


Функциональная зависимость атрибутов отношения напоминает понятие функциональной зависимости в математике. Но это не одно и то же. Для сравнения напомним математическое понятие функциональной зависимости.

Функциональная зависимость (функция) - это тройка объектов , где

- множество (область определения),

- множество (множество значений),

- правило, согласно которому каждому элементу ставится в соответствие один и только один элемент (правило функциональной зависимости).

Функциональная зависимость обычно обозначается как или .

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

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

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

  • В качестве множества значений выступает домен, на котором определен атрибут (или декартово произведение доменов)

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

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

Например, атрибут ^ ФАМ функционально зависит от атрибута Н_СОТР. Предположим, что сейчас сотрудник с табельным номером 1 имеет фамилию Иванов, т.е. при значении детерминанта равного 1, значение зависимого аргумента равно "Иванов". Но сотрудник может сменить фамилию, например на "Сидоров". Теперь при том же значении детерминанта, равного 1, значение зависимого аргумента равно "Сидоров".

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

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

2НФ (Вторая Нормальная Форма)

    1. Определение


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

Замечание. Если потенциальный ключ отношения является простым, то отношение автоматически находится в 2НФ.

Отношение СОТРУДНИКИ_ОТДЕЛЫ_ПРОЕКТЫ не находится в 2НФ, т.к. есть атрибуты, зависящие от части сложного ключа:

Зависимость атрибутов, характеризующих сотрудника от табельного номера сотрудника является зависимостью от части сложного ключа:

Н_СОТР ^ ФАМ

Н_СОТР
Н_ОТД

Н_СОТР ТЕЛ

Зависимость наименования проекта от номера проекта является зависимостью от части сложного ключа:

Н_ПРО ^ ПРОЕКТ

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

Отношение СОТРУДНИКИ_ОТДЕЛЫ_ПРОЕКТЫ декомпозируем на три отношения - СОТРУДНИКИ_ОТДЕЛЫ, ПРОЕКТЫ, ЗАДАНИЯ.

Отношение СОТРУДНИКИ_ОТДЕЛЫ (Н_СОТР, ^ ФАМ, Н_ОТД, ТЕЛ):

Функциональные зависимости:

Зависимость атрибутов, характеризующих сотрудника от табельного номера сотрудника:

Н_СОТР ^ ФАМ

Н_СОТР Н_ОТД

Н_СОТР ТЕЛ

Зависимость номера телефона от номера отдела:

^ Н_ОТД ТЕЛ

Таблица 2. Отношение СОТРУДНИКИ_ОТДЕЛЫ

Н_СОТР

ФАМ

Н_ОТД

ТЕЛ

1

Иванов

1

11-22-33

2

Петров

1

11-22-33

3

Сидоров

2

33-22-11



Отношение ^ ПРОЕКТЫ (Н_ПРО, ПРОЕКТ):

Функциональные зависимости:

Н_ПРО ПРОЕКТ

Таблица 3. Отношение ПРОЕКТЫ

Н_ПРО

ПРОЕКТ

1

Космос

2

Климат



Отношение ^ ЗАДАНИЯ (Н_СОТР, Н_ПРО, Н_ЗАДАН):

Функциональные зависимости:

(Н_СОТР, Н_ПРО) Н_ЗАДАН


Таблица 4. Отношения ЗАДАНИЯ

Н_СОТР

Н_ПРО

Н_ЗАДАН

1

1

1

1

2

1

2

1

2

3

1

3

3

2

2


    1. ^

      Анализ декомпозированных отношений


Отношения, полученные в результате декомпозиции, находятся в 2НФ. Действительно, отношения СОТРУДНИКИ_ОТДЕЛЫ и ПРОЕКТЫ имеют простые ключи, следовательно, автоматически находятся в 2НФ, отношение ЗАДАНИЯ имеет сложный ключ, но единственный неключевой атрибут Н_ЗАДАН функционально зависит от всего ключа {Н_СОТР, Н_ПРО}.

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

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

Если по проекту временно прекращены работы, но требуется, чтобы сам проект сохранился, то для этого проекта удаляются соответствующие кортежи в отношении ЗАДАНИЯ, а данные о самом проекте и данные о сотрудниках, участвовавших в проекте, остаются в отношениях ПРОЕКТЫ и СОТРУДНИКИ_ОТДЕЛЫ.

Тем не менее, часть аномалий разрешить не удалось.


      1. ^

        Оставшиеся аномалии вставки (INSERT)


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

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

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


      1. ^

        Оставшиеся аномалии обновления (UPDATE)


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

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

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


      1. ^

        Оставшиеся аномалии удаления (DELETE)


При удалении некоторых данных по-прежнему может произойти потеря другой информации. Например, если удалить сотрудника Сидорова, то будет потеряна информация о том, что в отделе номер 2 находится телефон 33-22-11.

^ Причина аномалии - хранение в одном отношении разнородной информации (и о сотрудниках, и об отделах).

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

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


^

3НФ (Третья Нормальная Форма)


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

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

Отношение СОТРУДНИКИ_ОТДЕЛЫ не находится в 3НФ, т.к. имеется функциональная зависимость неключевых атрибутов (зависимость номера телефона от номера отдела):

^ Н_ОТД ТЕЛ

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

Отношение СОТРУДНИКИ_ОТДЕЛЫ декомпозируем на два отношения - СОТРУДНИКИ, ОТДЕЛЫ.

Отношение СОТРУДНИКИ (Н_СОТР, ^ ФАМ, Н_ОТД):

Функциональные зависимости:

Зависимость атрибутов, характеризующих сотрудника от табельного номера сотрудника:

Н_СОТР ^ ФАМ

Н_СОТР Н_ОТД

Н_СОТР ТЕЛ

Таблица 5. Отношение СОТРУДНИКИ

Н_СОТР

ФАМ

Н_ОТД

1

Иванов

1

2

Петров

1

3

Сидоров

2

Отношение ^ ОТДЕЛЫ (Н_ОТД, ТЕЛ):

Функциональные зависимости:

Зависимость номера телефона от номера отдела:

Н_ОТД ТЕЛ

Таблица 6. Отношение ОТДЕЛЫ

Н_ОТД

ТЕЛ

1

11-22-33

2

33-22-11

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

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


    1. ^

      Алгоритм нормализации (приведение к 3НФ)


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

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

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

Исходное отношение: .

Ключ: - сложный.

Функциональные зависимости:

- зависимость всех атрибутов от ключа отношения.

- зависимость некоторых атрибутов от части сложного ключа.

Декомпозированные отношения:

- остаток от исходного отношения. Ключ .

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

^ Шаг 3 (Приведение к 3НФ). Если в некоторых отношениях обнаружена зависимость некоторых неключевых атрибутов других неключевых атрибутов, то проводим декомпозицию этих отношений следующим образом: те неключевые атрибуты, которые зависят других неключевых атрибутов выносятся в отдельное отношение. В новом отношении ключом становится детерминант функциональной зависимости:

Исходное отношение: .

Ключ: .

Функциональные зависимости:

- зависимость всех атрибутов от ключа отношения.

- зависимость некоторых неключевых атрибутов других неключевых атрибутов.

Декомпозированные отношения:

- остаток от исходного отношения. Ключ .

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

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


^

Сравнение нормализованных и ненормализованных моделей


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

Критерий

Отношения слабо нормализованы
(1НФ, 2НФ)


^ Отношения сильно нормализованы
(3НФ)


Адекватность базы данных предметной области

ХУЖЕ (-)

^ ЛУЧШЕ (+)

Легкость разработки и сопровождения базы данных

СЛОЖНЕЕ (-)

ЛЕГЧЕ (+)

Скорость выполнения вставки, обновления, удаления

^ МЕДЛЕННЕЕ (-)

БЫСТРЕЕ (+)

Скорость выполнения выборки данных

БЫСТРЕЕ (+)

^ МЕДЛЕННЕЕ (-)




оставить комментарий
страница1/11
Дата10.10.2011
Размер1,25 Mb.
ТипЛекция, Образовательные материалы
Добавить документ в свой блог или на сайт

страницы:   1   2   3   4   5   6   7   8   9   10   11
отлично
  1
Ваша оценка:
Разместите кнопку на своём сайте или блоге:
rudocs.exdat.com

Загрузка...
База данных защищена авторским правом ©exdat 2000-2017
При копировании материала укажите ссылку
обратиться к администрации
Анализ
Справочники
Сценарии
Рефераты
Курсовые работы
Авторефераты
Программы
Методички
Документы
Понятия

опубликовать
Загрузка...
Документы

Рейтинг@Mail.ru
наверх