Инкубатор:ПРОЕКТИРОВАНИЕ БАЗ ДАННЫХ НА ОСНОВЕ ПРИНЦИПОВ НОРМАЛИЗАЦИИ

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску


ПРОЕКТИРОВАНИЕ БАЗ ДАННЫХ НА ОСНОВЕ ПРИНЦИПОВ НОРМАЛИЗАЦИИ



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

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

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

  • первая нормальная форма (1 нф, 1 Normal Form, INF);
  • вторая нормальная форма (2 нф, 2 NF);
  • третья нормальная форма (3 нф, 3 NF);

нормальная форма Бойса — Кодда (BCNF);

  • четвертая нормальная форма (4 нф, 4 NF);
  • пятая нормальная форма, или нормальная форма проекции- соединения (5 нф, 5 NF, или PJ/NF).

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

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

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

2.Пример неизбыточного дублирования Пример избыточного дублирования данных

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

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

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

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

4.15

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

Пример удаления данных в таблице с избыточным дублированием (рис. 4.16) Гб4.jpg


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

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

4.17


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

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

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

4.18

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


4.Таблица, соответствующая 1 нф

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

4.19

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



5.Таблица, соответствующая 2 нф

На рис. 4.20 таблица не соответствует 3 нф, потому что значение поля «Классный руководитель» зависит от номера группы (если студент перейдет в другую группу, то за изменением номера группы последует замена и классного руководителя). Наименование специальности зависит от шифра, и наоборот. Для того чтобы привести таблицу в соответствие третьей нормальной форме, следует разбить ее на несколько таблиц.

4.20

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





6.Структура базы данных после приведения к 3 нф

4.21


Таблица Студенты

Таблица Группы

4.21

Таблица Специальности


Классификация CASE -технологий[править | править код]

Все современные CASE -средства могут быть классифицированы в основном по типам и по категориям. Классификация по типам отражает функциональную ориентацию CASE-средств. Классификация по категориям определяет степень интегрированности по выполняемым функциям.

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

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

Рассмотрим классификацию CASE -средств по наиболее часто используемым признакам

По ориентации на этапы жизненного цикла выделяют следующие основные типы САБЕ-средств:

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

По функциональной полноте CASE -системы и средства можно условно разделить на следующие типы:

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

По типу используемых моделей CASE -системы условно можно разделить на три основные разновидности:

  • структурные. Исторически первые структурные CASE -системы основаны на методах структурного и модульного программирования, структурного анализа и синтеза;
  • объектно-ориентированные. Объектно-ориентированные методы и CASE -системы получили массовое использование с начала 1990-х гг. Они позволяют сократить сроки разработки, а также повысить надежность и эффективность функционирования *информационных систем;
  • комбинированные. Комбинированные инструментальные средства поддерживают одновременно структурные и объектно- ориентированные методы.

По степени независимости от СУБД САБЕ-системы можно разделить на две группы:

1.независимые системы — поставляются в виде автономных систем, не входящих в состав конкретной СУБД;

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

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

Обзор CASE-систем[править | править код]

AllFusion ERwin Data Modeler. Данное CASE-средство предназначено для проектирования и документирования баз данных. Оно позволяет создавать, документировать и сопровождать базы данных, хранилища и витрины данных. Модели данных помогают визуализировать структуру данных, обеспечивая эффективный процесс организации, управления и администрирования таких аспектов деятельности предприятия, как уровень сложности данных, технологий баз данных и среды развертывания. AllFusion ERwin Data Modeler предназначен для всех компаний,

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

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

Power Designer компании Sybase. В состав Power Designer входят следующие модули: Process Analyst, Data Analyst, Application Modeler.

Process Analyst — средство для функционального моделирования, поддерживает нотацию Йордона де Марко, Гейна-Сарсона и несколько других. Имеется возможность описать элементы данных (имена, типы, форматы), связанные с потоками данных и хранилищами данных. Эти элементы передаются на следующий этап проектирования, причем хранилища данных могут быть автоматически преобразованы в сущности.

Data Analyst — инструмент для построения модели «сущность-связь», автоматической генерации на ее основе реляционной структуры. Исходные данные для модели «сущность-связь» могут быть получены из DFD-моделей, созданных в модуле Process Analyst. В ER-диаграммах допускаются только бинарные связи, задание атрибутов у связей не поддерживается. Поддерживаются диалекты языка SQL примерно для 30 реляционных СУБД, при этом могут быть сгенерированы таблицы, представления, индексы, триггеры и т. д. В результате порождается SQL-сценарий (последовательность команд CREATE), выполнение которого создает спроектированную схему базы данных. Имеется также возможность установить соединение с СУБД через интерфейс ODBC. Другие возможности: автоматическая проверка правильности модели, расчет размера базы данных, реинжиниринг (построение модельных диаграмм для уже существующих баз данных) и т. д.

Application Modeler — инструмент для автоматической генерации прототипов программ обработки данных на основе реляционных моделей, построенных в Data Analyst. Может быть получен код для Visual Basic, Delphi, а также для таких систем разработки в архитектуре «клиент-сервер» как PowerBuilder, Uniface, Progress и др. Генерация кода осуществляется на основе шаблонов, соответственно управлять генерацией можно за счет изменения соответствующего шаблона.

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

Пакет Design/IDEF (Meta Software Согр.). Данная графическая среда предназначена для проектирования и моделирования сложных систем широкого назначения. Она поддерживающая методологии описания и моделирования системных функций (IDEF0/SADT), структур и потоков данных в системе (IDEF1, IDEF1X, ER) и поведения системы (IDEF/CPN). Пакет Design/IDEF был использован для создания проектов сложнейших систем, связанных с автоматизацией и компьютеризацией производства, управлением и контролем, телекоммуникациями и аэрокосмонавтикой.

Design/IDEF используется как составная часть в некоторых известных пакетах типа CIM (Computer Integrated Manufacturing) и CAE (Computer Aided Engineering) и принят в качестве стандарта для проектов, финансируемых американскими и европейскими спонсорами. Рассмотрим более подробно основные возможности пакета Design/IDEF.

1. Представление графики: Design/IDEF имеет быструю и высококачественную графику, включающую создание стандартных и пользовательских объектов, выравнивание и манипулирование объектами, выбор атрибутов графических объектов и текста. Дополнительно в Design/IDEF реализованы возможности, требуемые для редактирования и моделирования данных: построение связывающих линий типа «резинка», маршрутизация и сглаживание дуг и т. д.

2. Обеспечение непротиворечивости модели: Design/IDEF имеет встроенные возможности, дающие уверенность разработчику, что IDEF-модель будет точной, целостной и непротиворечивой на протяжении всего цикла ее создания. Например, при модификации текста, принадлежащего функциональному блоку или дуге в какой- то одной части модели, текст будет динамически скорректирован на всех страницах модели.

3. Поддержка Словаря Данных: Design/IDEF имеет встроенный Словарь Данных, который позволяет хранить информацию и создавать отчеты о функциях и потоках данных в IDEF-модели. Словарь дает возможность определять начальную информацию об объектах и предоставляет разнообразный набор функций сопровождения, восстановления и сохранения целостности файлов данных. Возможности словаря отличаются большой гибкостью и позволяют пользователю вводить неограниченное число параметров для каждого объекта. В сочетании с высококачественной печатью на лазерном принтере, это позволяет разработчику создавать документацию проекта, отвечающую самым высоким требованиям.

4. Генерация отчетов: Design/IDEF предоставляет возможность использовать пять видов отчетов для поддержки и анализа моделей: отчет о контроле полноты модели; отчет о функциях; отчет о дугах; отчет о ссылках; IDEF-отчет. Все отчеты могут быть показаны на экране компьютера, отредактированы и распечатаны с помощью текстового редактора. Design/IDEF

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

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

Моделирование данных (IDEF1, IDEF1X и ER — методологии) Design/IDEF дает также возможность создавать информационные модели, которые представляют как собственно данные, так и связи между ними в системе. Информация, содержащаяся в IDEF- моделях, экспортируется в любую базу данных, а сами модели могут быть экспортированы в Design/CPN — пакет динамического моделирования и анализа сложных систем.

Как CASE-пакет по разработке программного обеспечения Design/IDEF поддерживает первые стадии создания программного продукта:


  • формулировка требований и целей проекта — определение того, что

проектируемая система будет делать;

  • разработка спецификаций — формализованное описание требований;
  • создание проекта — определение подсистем и взаимодействий между

ними;

  • документирование проекта — создание базы данных проекта,

текстуальное описание составных частей проекта;

  • анализ проекта — проверка проекта на полноту и

непротиворечивость. Результатом работы пакета Design/IDEF является проект программной системы, состоящий из двух частей:

1) проекта функциональной структуры системы, содержащего иерархически связанные страницы с IDEFO-диаграммами и описывающего все модули (вплоть до элементарных функций) системы, их взаимосвязи, входные и выходные параметры;

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

Design/IDEF работает в различных операционных средах: можно строить модели на IBM PC под MS-Windows, Macintosh или под Unix X Window System и переносить диаграммы из одной операционной среды в другую.

Designer/2000 компании Oracle. Данный продукт компании Oracle наиболее полно поддерживает все этапы создания приложений обработки данных. Однако в отличие от других средств он поддерживает практически одну целевую

СУБД — Oracle Server. То же самое касается и средств создания пользовательского интерфейса. Хотя возможна генерация прототипов программ для языков Visual

Basic, C, Java, полностью все возможности Designer/2000 реализуются только при использовании его вместе со средством разработки Oracle Developer/2000.

В состав Oracle Designer/2000 включены следующие модули:

1) инструментарий анализа предметной области:

  • Process Modeler — средство анализа деловой активности организации.

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

  • Dataflow Diagrammer — в этом инструменте на базе DFD-диа- грамм

детализуются функции, описанные в Process Modeler;

  • Entity Relationships Diagrammer — инструмент моделирования данных

(диаграммы «сущность-связь», которыми оперируют функции, определенные в Dataflow Diagrammer. Используется нотация Баркера) ;

  • Matrix Diagrammer — иструмент для исследования связей между

функциями и данными;

2) генераторы структур:

  • Database Wizard — генерирует реляционные структуры из ER- диаграмм;
  • Application Wizard — генерирует иерархию программных модулей

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

  • Data Diagrammer — инструмент для доработки реляционных структур

данных на основе нотации Баркера;

  • Module Structure Diagrammer — инструмент для управления структурой

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

  • Module Data Diagrammer — средство для проектирования экранного

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

3) генераторы данных:

  • Server Generator — генерирует базу данных на основе реляционных

моделей;

4) генераторы кода на основе моделей, построенных в Module Data Diagrammer, позволяют создать исходный код для Visual Basic, С, Java а также инструментов среды Oracle Developer/2000 (Oracle Forms, Oracle Reports).

  • Preferences Navigator — средство управления предпочтениями при

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

В Oracle Designer/2000 имеется также ряд других инструментов: утилита для

интерактивного выполнения SQL-запросов, средства управления проектом и т. д.