Ответы 09.04. ответы_8_раздел. 8 Раздел. Базы данных Этапы проектирования базы данных
 Скачать 1.99 Mb.
|
1 2 1. Этапы проектирования базы данных. Перед созданием базы данных разработчик должен определить, из каких таблиц должна состоять база данных, какие данные нужно поместить в каждую таблицу, как связать таблицы. Эти вопросы решаются на этапе проектирования базы данных. В результате проектирования должна быть определена логическая структура базы данных, то есть состав реляционных таблиц, их структура и межтабличные связи. Перед созданием базы данных необходимо располагать описанием выбранной предметной области, которое должно охватывать реальные объекты и процессы, определить все необходимые источники информации для удовлетворения предполагаемых запросов пользователей и определить потребности в обработке данных. На основе такого описания на этапе проектирования базы данных определяются состав и структура данных предметной области, которые должны находиться в БД и обеспечивать выполнение необходимых запросов и задач пользователей. Структура данных предметной области может отображаться информационно-логической моделью. На основе этой модели легко создается реляционная база данных. Можно выделить пять основных этапов проектирования БД: 1. Сбор сведений и системный анализ предметной области. 2. Инфологическое проектирование. 3. Выбор СУБД. 4. Даталогическое проектирование. 5. Физическое проектирование. Сбор сведений и системный анализ предметной области - это первый и важнейший этап при проектировании БД. В нем необходимо провести подробное словесное описание объектов предметной области и реальных связей, присутствующих между реальными объектами. Желательно чтобы в описании определялись взаимосвязи между объектами предметной области. В общем случае выделяют два подхода к выбору состава и структуры предметной области: · Функциональный подход – применяется тогда, когда заранее известны функции некоторой группы лиц и комплексы задач, для обслуживания которых создается эта БД, т.е. четко выделяется минимальный необходимый набор объектов предметной области под описание. · Предметный подход – когда информационные потребности заказчиков БД четко не фиксируются и могут быть многоаспектными и динамичными. В данном случае минимальный набор объектов предметной области выделить сложно. В описание предметной области включаются такие объекты и взаимосвязи, которые наиболее характерны и существенны для нее. При этом БД становится предметной, и подходит для решения множества задач (что кажется наиболее заманчивым). Однако трудность всеобщего охвата предметной области и невозможность конкретизации потребностей пользователей приводит к избыточно сложной схеме БД, которая для некоторых задач будет неэффективной. Рекомендуется использовать компромиссный вариант, который, с одной стороны, ориентирован на конкретные задачи, а с другой стороны, учитывает возможность расширения приложения. Системный анализ должен заканчиваться подробным описанием информации об объектах предметной области, которая должна храниться в БД, формулировкой конкретных задач, которые будут решаться с использованием данной БД с кратким описанием алгоритмов их решения, описанием выходных и входных документов при работе с БД. Инфологическое проектирование – частично формализованное описание объектов предметной области в терминах некоторой семантической модели. Инфологическая модель должна включать такое формализованное описание предметной области, которое легко будет восприниматься не только специалистами в области БД. Описание должно быть настолько емким, чтобы можно было оценить глубину и корректность проработки проекта БД. На сегодняшний день наиболее широкое распространение получила модель Чена «Сущность-связь» (Entity Relationship), она стала фактическим стандартом в инфологическом моделировании, и получило название ER – модель. Выбор СУБД(система управления базами данных) осуществляется на основе различных требований к БД и, соответственно, возможностей СУБД, а также в зависимости от имеющегося опыта разработчиков. Даталогическое проектирование есть описание БД в терминах принятой даталогической модели данных. В реляционных БД даталогическое или логическое проектирование приводит к разработке схемы БД, т.е. совокупности схем отношений, которые адекватно моделируют объекты предметной области и семантические связи между объектами. Основой анализа корректности схемы являются функциональные зависимости между атрибутами БД. В некоторых случаях между атрибутами отношений могут появиться нежелательные зависимости, которые вызывают побочные эффекты и аномалии при модификации БД. Под модификацией понимают внесение новых данных в БД, удаление данных из БД, а также обновление значений некоторых атрибутов. Для ликвидации возможных аномалий предполагается проведение нормализации отношений БД. Этап логического проектирования не заключается только в проектировании схемы отношений. В результате выполнения этого этапа, как правило, должны быть получены следующие результирующие документы: · Описание концептуальной схемы БД в терминах выбранной СУБД. · Описание внешних моделей в терминах выбранной СУБД. · Описание декларативных правил поддержки целостности БД. · Разработка процедур поддержки семантической целостности БД. Физическое проектирование заключается в увязке логической структуры БД и физической среды хранения с целью наиболее эффективного размещения данных, т.е. отображение логической структуры БД в структуру хранения. Решается вопрос размещения хранимых данных в пространстве памяти, выбора эффективных методов доступа к различным компонентам «физической» БД, решаются вопросы обеспечения безопасности и сохранности данных. Ограничения, имеющиеся в логической модели данных, реализуются различными средствами СУБД, например, при помощи индексов, декларативных ограничений целостности, триггеров, хранимых процедур. При этом опять-таки решения, принятые на уровне логического моделирования определяют некоторые границы, в пределах которых можно развивать физическую модель данных. Точно также, в пределах этих границ можно принимать различные решения. Например, отношения, содержащиеся в логической модели данных, должны быть преобразованы в таблицы, но для каждой таблицы можно дополнительно объявить различные индексы, повышающие скорость обращения к данным. Кроме того, для повышения производительности могут использоваться возможности параллельной обработки данных. В результате БД может размещаться на нескольких сетевых компьютерах. С другой стороны могут использоваться преимущества многопроцессорных систем. Для обеспечения безопасности и сохранности данных решаются вопросы способы восстановления после сбоев, резервного копирования информации, настройка систем защиты под выбранную политику безопасности и т.д. Необходимо отметить, что некоторые современные реляционные СУБД в основном используют физические структуры и методы доступа, опирающиеся на технологию проектирования файла, что по существу практически снимает вопрос о физическом проектировании. Таким образом, ясно, что решения, принятые на каждом этапе моделирования и разработки базы данных, будут сказываться на дальнейших этапах. Поэтому особую роль играет принятие правильных решений на ранних этапах моделирования. 2. ER – модель. Имеется целый ряд методик создания информационно-логических моделей. Одна из наиболее популярных в настоящее время методик при разработке моделей использует ER (Entity-Relationship). ER-модель представляет собой схему, составными элементами которой являются: Сущность — это реальный, либо воображаемый объект, информацию о котором необходимо хранить в базе данных. На диаграмме ER-модели сущность изображается в виде прямоугольника, содержащего имя сущности. Связь — отображаемая графически на диаграмме ассоциация между двумя (чаще всего) сущностями, или между одной и той же сущностью (рекурсивная связь). Связь изображается ромбом, на котором выделяются два конца, по одному на каждую сущность. Для каждой стороны этой связи устанавливаются: 1) Степень связи — сколько экземпляров данной сущности связывается, 2) Обязательность связи — обязательно ли данная сущность должна участвовать в связи. Атрибут – свойство сущности. Различают: 1) Идентифицирующие и описательные атрибуты. Идентифицирующие позволяют отличить один экземпляр сущности от другого. Описательные атрибуты заключают в себе интересующие нас свойства сущности. 2) Составные и простые атрибуты. Простой атрибут имеет неделимое значение. Составной атрибут является комбинацией нескольких элементов, возможно, принадлежащих разным типам данных (ФИО, адрес и др.). 3) Однозначные и многозначные атрибуты (могут иметь соответственно одно или много значений для каждого экземпляра сущности). Например, дата рождения – это однозначный атрибут, а номер телефона – многозначный. 4) Основные и производные атрибуты. Значение основного атрибута не зависит от других атрибутов; значение производного атрибута вычисляется на основе значений других атрибутов. Например, возраст вычисляется на основе даты рождения и текущей даты. 5) Обязательные и необязательные (первые должны быть указаны при размещении данных в БД, вторые могут не указываться). Для каждого атрибута необходимо определить название, указать тип данных и описать ограничения целостности – множество значений, которые может принимать данный атрибут 3. Пример описания предметной области и соответствия ER-модели. Пусть необходимо хранить информацию о клиентах и их заказах. Построим диаграмму  Рис.1 Заметим, что со стороны сущности «ЗАКАЗ» связь обозначена дополнительным прямоугольником — это обозначение того, что каждому экземпляру сущности «ЗАКАЗ» соответствует экземпляр сущности «КЛИЕНТ» (для клиента же наличие заказа не обязательно). Степень «M» означает, что для каждого экземпляра сущности «КЛИЕНТ» могут существовать несколько экземпляров сущности «ЗАКАЗ» (но не наоборот, поскольку для каждого заказа всегда только один заказчик — ставим степень «1») Отношение (обычно оно соответствует таблице в базе данных) не следует путать с сущностью. Сущность переходит в отношение путем выделения её из ER-диаграммы. 4. Использование диаграмм сущность-связь (ER-диаграмм) в процессе проектирования баз данных. Этапы проектирования Концептуальное проектирование Строится ER-диаграмма, включающая в себя все сущности и связи. Мы получаем концептуальную (инфологическую) модель. Следует понимать, что такая модель может далеко не соответствовать реляционной структуре проектируемой базы данных. Допустим, нужно построить базу данных, в которой будет необходимо хранить полную информацию о заказах, клиентах, сотрудниках. Для каждого заказа есть список элементов этого заказа (несколько изделий), каждому из которых сопоставлен список израсходованных материалов, и произведенных операций. У меня получилась следующая диаграмма.  рис.2 Логическое проектирование Строится набор предварительных отношений с указанием первичного ключа для каждого отношения. Составляется список атрибутов, затем эти атрибуты распределяются по отношениям. Необходимо, чтобы все отношения оставались в НФБК. Переход к реляционной структуре (построение набора отношений) производится по следующим правилам: Если степень бинарной связи равна 1:1 и класс принадлежности обеих сущностей обязательный, то требуется только одно отношение. Первичным ключом этого отношения может быть ключ любой из этих двух сущностей. В этом случае гарантируется однократное появление каждого значения ключа в любом экземпляре отношения. Если степень бинарной связи равна 1:1 и класс одной из сущностей необязательный, то необходимо построение двух отношений, под каждую сущность необходимо выделение одного отношения. Ключ сущности, для которого класс принадлежности является необязательным, добавляется в качестве атрибута в отношение, выделенное для сущности с обязательным классом принадлежности. Если степень бинарной связи равна 1:1 и класс принадлежности ни одной из сущностей не является необязательным, то используется три отношения — по одному для каждой сущности — ключи которых служат в качестве первичных в соответствующих отношениях и одного для связи. Отношение, выделенное для связи, будет иметь по одному ключу сущности от каждой сущности. Если степень бинарной связи равна 1: М и класс принадлежности М-связной сущности обязательный, то достаточно использовать два отношения: по одному на каждую сущность, при условии, что ключ сущности служит в качестве первичного ключа для соответствующего отношения. Ключ же односвязной сущности должен быть добавлен как атрибут в отношение, отводимое М-связной сущности. Если степень бинарной связи равна 1: М и класс принадлежности М-связной сущности необязателен, то необходимо использовать три отношения: по одному на сущность и одно для связи. Связь должна иметь среди своих атрибутов ключ сущности от каждой сущности. Если степень бинарной связи равна М: М, то для хранения данных необходимо три отношения: по одному на сущность и одно для связи. Ключи сущности входят в связь. Если одна из сущностей вырождена, то — два отношения (т.е. достаточно будет двух таблиц). В случае трехсторонней связи необходимо использовать четыре отношения: по одному на сущность и одно для связи. Отношение, порождаемое связью, имеет в себе среди атрибутов ключи сущности от каждой сущности. Воспользуемся правилами, сведем данные в таблицу.
Табл. 1 Распределив атрибуты по полученным отношениям, получим (в списке полей на первом месте — первичный ключ, остальные, помеченные «#», являются внешними ключами):
Табл. 2 5. Реляционная модель данных. Реляционная модель данных - созданная Эдгаром Коддом логическая модель данных, описывающая: структуры данных в виде (изменяющихся во времени) наборов отношений; теоретико-множественные операции над данными: объединение, пересечение разность и декартово произведение; специальные реляционные операции: селекция, проекция, соединение и деление; специальные правила, обеспечивающие целостность данных. Реляционная модель данных - это способ рассмотрения данных, то есть предписание для способа представления данных (посредством таблиц) и для способа работы с таким представлением (посредством операторов). Она связана с тремя аспектами данных: структурой (объекты), целостностью и обработкой данных (операторы). Цели создания реляционной модели данных: обеспечение более высокой степени независимости от данных; создание прочного фундамента для решения семантических вопросов и проблем непротиворечивости и избыточности данных; засширение языков управления данными за счёт включения операций над множествами. 6. Структуры данных реляционной модели. Реляционная модель данных предусматривает структуру данных, обязательными объектами которой являются: отношение; атрибут; домен; кортеж; степень; кардинальность; первичный ключ. Отношение - это плоская (двумерная) таблица, состоящая из столбцов и строк: Атрибут - это поименованный столбец отношения. Домен - это набор допустимых значений для одного или нескольких атрибутов. Кортеж - это строка отношения. Степень определяется количеством атрибутов, которое оно содержит Кардинальность - это количество кортежей, которое содержит отношение. Первичный ключ - это уникальный идентификатор для таблицы. Соответствие между формальными терминами реляционной модели данных и неформальными: отношение (формальный термин) - таблица (неформальный термин); атрибут - столбец; кортеж - строка или запись; степень - количество столбцов; кардинальное число - количество строк; первичный ключ - уникальный идентификатор; домен - общая совокупность допустимых значений. 7. Использование отношений для представления данных Отношение R на множестве доменов D1, D2, …, Dn - это подмножество декартова произведения этих доменов: R ⊆ D1 × D2 × … × Dn Пример 1. Определены домены: D1 - множество фамилий преподавателей, D2 - множество аудиторий, D3 - множество учебных групп, D4 - множество учебных дисциплин. Записать отношения: 1) закрепление преподавателей за учебными курсами; 2) расписание занятий в группах. Решение. 1) закрепление преподавателей за учебными курсами: R ⊆ D1 × D4. Это отношение определяет множество преподавателей, ведущих множество учебных дисциплин. 2) расписание занятий в группах: R ⊆ D2 × D3 × D4. Это отношение определяет множество аудиторий, в которых проводятся занятия по множеству учебных дисциплин для множества учебных групп. Свойства отношений: уникальное имя отношения; уникальное имя атрибута; нет одинаковых кортежей; кортежи не упорядочены сверху вниз; атрибуты не упорядочены слева направо; все значения атрибутов атомарные (нормализованное отношение). Таким образом, реляционная база данных - это набор нормализованных отношений. Для того, чтобы перейти к видам отношений, введём понятие переменной отношения. Переменная отношения - это именованный объект, значение которого может изменяться с течением времени. Переменная отношения в разное время - это различные таблицы базы данных, у которых разные строки, но одинаковые столбцы. Виды отношений: именованное отношение; базовое отношение; производное отношение; выражаемое отношение; представление (view); снимки (snapshot); результат запроса; промежуточный результат. Именованное отношение - это переменная отношения, определённая в СУБД (системе управления базами данных) посредством оператора CREATE (CREATE TABLE, CREATE BASE RELATION, CREATE VIEW, CREATE SNAPSHOT). Базовое отношение - это именованное отношение, которое не является производным. Существование базового отношения не зависит от существования других отношений. Производное отношение - это отношение, которое определено через другие именованные отношения. Производное отношение зависит от существования других - базовых - отношений. Выражаемое отношение - это отношение, которое можно получить из набора именованных отношений посредством некоторого реляционного выражения. Каждое именованное отношение является выражаемым отношений, но не наоборот. Примеры выражаемых отношений - базовые отношения, представления, снимки, промежуточные и окончательные результаты. Множество всех выражаемых отношений - это множество всех базовых и всех производных отношений. Представление - это именованное производное отношение. Представлены в базе данных в виде определения. Представление не хранится в физической памяти системы управления базой данных (СУБД), а формируется с использованием других именованных отношений. Снимки (snapshot) - это то же, что и представление, но с физическим сохранением и с периодическим обновлением. Результат запроса - это неименованное производное отношение. СУБД не обеспечивает постоянного существования результатов запросов. Для сохранения результата запроса его можно присвоить какому-либо именованному отношению. Промежуточный результат - это неименованное производное отношение, являющееся результатом подзапроса, вложенного в бОльшее выражение. 8. Ограничения модели. Появление реляционных СУБД стало важным шагом вперед по сравнению с иерархическими и сетевыми СУБД, в этих системах стали использоваться непроцедурные языки манипулирования данными и была достигнута значительная степень независимости данных от обрабатывающих программ. В то же время, выяснился ряд недостатков реляционых систем. Во-первых, сама реляционная модель ограничена в представлении данных: Реляционная модель данных не допускает естественного представления данных со сложной (иерархической) структурой, поскольку в ее рамках возможно моделирование лишь с помощью плоских отношений (таблиц). Все отношения принадлежат одному уровню, многие значимые связи между данными либо теряются, либо их поддержку приходится осуществлять в рамках конкретной прикладной программы. По определению в реляционной модели поля кортежа могут содержать лишь атомарные значения. Однако, в таких приложениях как САПР (системы автоматизироваанного проектирования), ГИС (геоинформационные системы), искусственный интеллект системы оперируют со сложно - структурированными объектами. Кроме того, даже в том случае, когда сложный объект удается "уложить" в реляционную базу данных, его данные распределяются, как правило, по многим таблицам. Соответственно, извлечение каждого такого объекта требует выполнения многих операций соединения (join), что значительно замедляет работу СУБД. Обойти это и предыдущее ограничения можно было бы в том случае, если бы реляционная модель допускала возможность определения новых типов данных определение наборов операций, связанных с данными определенного типа Во-вторых, имеются определенные недостатки и в релизации тех возможностей, которые прямо не предусматриваются реляционной моделью, но стали непременным атрибутом всех современных СУБД: Цикл существования реляционной базы данных состоит в переходе от одного целостного состояния к другому. Однако, нельзя избежать такой ситуации, когда пользователь вводити данные, формально удовлетворяющие ограничениям целостности, но не соответствующие реальному состоянию предметной области. В этом случае предыдущее "истинное" значение данных будет утеряно. Реляционная СУБД выполняет над данными не только те действия, которые задает пользователь, но и дополнительные операции в соотвествии с правилами, заложенными в базу данных. Этот механизм реализуется с помощью триггеров, однако аппарат триггеров весьма сложен в отладке и полностью не реализован ни в одной системе. 9. Методы проектирования реляционных баз данных. Методы проектирования БД Целью проектирования БД является адекватное отображение в базе данных сути предметной области, рассматриваемой с точки зрения решения задачи автоматизации. В теории баз данных существует ряд методов разработки моделей БД, отображающих разные уровни её архитектуры. Распространены два основных подхода к проектированию баз данных: "нисходящий" и "восходящий". Известен также подход "смешанной стратегии" — сначала «восходящий» и «нисходящий» методы используются для разных частей модели, после чего все подготовленные фрагменты собираются в единое целое. Рассмотрим на рисунке отличие этих методов Метод восходящего проектирования БД При «восходящем» подходе осуществляют структурное проектирование снизу—вверх. Этот процесс называют процессом синтеза, попыткой получения целого, адекватно отображающего описание предметной области, на основе описания составляющих его частей. Этапы проектирования БД методом «восходящего» проектирования представлены на рисунке 2.  ДЛМ – даталогическая модель; НФ – нормальная форма; ИЛМ – информационно—логическая модель предметной области; МБД – модель БД.Рисунок 2 — Этапы проектирования БД методом «восходящего» проектирования Работа для реляционной БД начинается с определения свойств объектов (атрибутов сущностей) предметной области, которые на основе анализа существующих между ними связей группируются в реляционные отношения (таблицы), отображающие эти объекты (в том случае, если мы проектируем структуру реляционной БД). Как правило, получают 2 — 3 реляционных отношения, связанных между собой. Избыточность данных в ненормализованной схеме – повторение данных в БД. Для того чтобы полученная структура БД (ДЛМ) не обладала различными аномалиями при добавлении, обновлении или удалении данных вследствие их избыточности, необходимо осуществить проверку каждой полученной схемы отношения, как минимум, на соответствие 3НФ. Если схемы отношений не соответствуют этому условию, а они, как правило, не соответствуют, необходимо проводить процесс нормализации. Значительный объем мероприятий по нормализации схем реляционных отношений даже дал второе название методу «восходящего» проектирования. Этот метод часто называют методом «нормализации». Основы теории нормализации создал Э. Кодд. Нормализация – это процесс проектирования в терминах реляционной модели данных методом последовательных приближений к удовлетворительному набору схем. Совокупность схем отношений называется схемой реляционной БД. Нормализация исключает избыточность и аномалии в БД. Пример Схема1 (Код автора, ФИО автора, Код книги, Название книги, Код издательства, Название издательства, Дата издания) Повторение данных об издательсве (назвнаие), ФИО автора, если у него несколько книг и другое Аномалии в ненормализованной схеме отношения: а) обновления – противоречивость данных, вызванная их избыточностью и частичным обновлением. б) аномалия удаления – непреднамеренная потеря данных, вызванная удалением других данных в) аномалия ввода – невозможность ввести данные в таблицу, вызванная отсутствием других данных. Нисходящее проектирование БД При «нисходящем» проектировании осуществляется структурное проектирование сверху—вниз («нисходящее» проектирование). Такое проектирование называют анализом – происходит изучение целого (описания предметной области), затем разделение целого на составные части и затем следует последовательное изучение этих частей. Этапы проектирования БД методом «нисходящего» проектирования представлены на рисунке.  Пр Обл. – предметная область; ИЛМ – информационно—логическая модель предметной области; ДЛМ – даталогическая модель; НФ – нормальная форма; ФМ – физическая модель БД. Рисунок — Этапы проектирования БД методом «нисходящего» проектирования Для отображения метода использованы следующие обозначения: в кругах описаны названия этапов проектирования, в прямоугольниках – результаты. Проектирование начинается с анализа предметной области и формирования описания внешнего уровня БД, объединяющего представления всех пользователей разрабатываемой БД, выявления классов объектов (сущностей) предметной области, связей между ними. На основе описания внешнего уровня строится концептуальная информационно—логическая модель предметной области (ИЛМ), затем на её основе получают даталогическую модель (ДЛМ) базы данных. ДЛМ является основой для следующего этапа проектирования БД – этапа формирования физической модели базы данных. Такой подход к проектированию БД называют также концептуальным или концептуальным проектированием. В концептуальном подходе к проектированию БД выделяют следующие три сферы: — реальный мир или объектную систему; — информационную сферу; — даталогическую сферу. 10. Нормализация отношений. Нормализация – это процесс проектирования в терминах реляционной модели данных методом последовательных приближений к удовлетворительному набору схем. Совокупность схем отношений называется схемой реляционной БД. Нормализация исключает избыточность и аномалии в БД. Нормальная форма - свойство отношения в реляционной модели данных, характеризующее его с точки зрения избыточности, которая потенциально может привести к логически ошибочным результатам выборки или изменения данных. Нормальная форма определяется как совокупность требований, которым должно удовлетворять отношение. Процесс преобразования отношений базы данных (БД) к виду, отвечающему нормальным формам, называется нормализацией. Нормализация предназначена для приведения структуры БД к виду, обеспечивающему минимальную логическую избыточность, и не имеет целью уменьшение или увеличение производительности работы или же уменьшение или увеличение физического объёма базы данных. Конечной целью нормализации является уменьшение потенциальной противоречивости хранимой в базе данных информации. Общее назначение процесса нормализации: исключение некоторых типов избыточности; устранение некоторых аномалий обновления; разработка проекта базы данных, который является достаточно «качественным» представлением реального мира, интуитивно понятен и может служить хорошей основой для последующего расширения; упрощение процедуры применения необходимых ограничений целостности. 11. Обоснованность использования нормальных форм. Процесс уменьшения избыточности информации в БД называется нормализацией отношений (таблиц). Нормализация отношений БД представляет собой процесс реорганизации данных путем ликвидации повторяющихся групп и иных противоречий с целью приведения таблиц к виду, позволяющему осуществлять корректное редактирование данных. Это комплекс ограничений на формирование таблиц, который позволяет устранить дублирование данных, обеспечивает их непротиворечивость и уменьшает трудоёмкость ввода и корректировки базы данных. В теории реляционных баз данных обычно выделяется следующая последовательность нормальных форм: первая нормальная форма (1NF); вторая нормальная форма (2NF); третья нормальная форма (3NF); нормальная форма Бойса-Кодда (BCNF); четвертая нормальная форма (4NF); пятая нормальная форма, или нормальная форма проекции-соединения (5NF или PJ/NF). Основные свойства нормальных форм: каждая следующая нормальная форма в некотором смысле лучше предыдущей; при переходе к следующей нормальной форме свойства предыдущих нормальных свойств сохраняются. В основе процесса проектирования лежит метод нормализации, декомпозиция отношения, находящегося в предыдущей нормальной форме, в два или более отношения, удовлетворяющих требованиям следующей нормальной формы. Наиболее важные на практике нормальные формы отношений основываются на фундаментальном в теории реляционных баз данных понятии функциональной зависимости. Для дальнейшего изложения нам потребуются несколько определений. Определение 1. Функциональная зависимость В отношении R атрибут Y функционально зависит от атрибута X (X и Y могут быть составными) в том и только в том случае, если каждому значению X соответствует в точности одно значение Y: R.X (r) R.Y. Определение 2. Полная функциональная зависимость Функциональная зависимость R.X (r) R.Y называется полной, если атрибут Y не зависит функционально от любого точного подмножества X. Определение 3.Транзитивная функциональная зависимость Функциональная зависимость R.X -> R.Y называется транзитивной, если существует такой атрибут Z, что имеются функциональные зависимости R.X -> R.Z и R.Z -> R.Y и отсутствует функциональная зависимость R.Z --> R.X. (При отсутствии последнего требования мы имели бы "неинтересные" транзитивные зависимости в любом отношении, обладающем несколькими ключами.) Определение 4. Неключевой атрибут Неключевым атрибутом называется любой атрибут отношения, не входящий в состав первичного ключа (в частности, первичного). Определение 5. Взаимно независимые атрибуты Два или более атрибута взаимно независимы, если ни один из этих атрибутов не является функционально зависимым от других. 12. Пример нормализации отношений. Разберем на примере создание базы данных с помощью нормализации. Дан документ «Накладная» (рисунок 16), необходимо создать базу данных, приведенную к 3НФ. Для создания таблицы, приведенной к первой нормальной форме, необходимо 1. Определить поле, которое можно назначить первичным ключом. Если такого поля нет, то добавить новое уникальное ключевое поле. 2. Определить группы повторяющихся полей. 3. Вынести группы повторяющихся полей в отдельные таблицы, в основной таблице остается одно поле для организации связи между таблицами. 4. Назначить первичные ключи в новых таблицах. (В качестве ключевых полей можно использовать поля таблицы или добавить новое поле. Если ключевое поле имеет большой размер, предпочтительней добавлять новое поле.) 5. Определить тип отношения между таблицами.
Рисунок 16 - Исходные документы для создания базы данных Разделим семантически неделимые поля, например «Адрес», выделив из него поле «Город». Исключая повторяющиеся группы, выделим поле «Название товара». В качестве идентификатора добавим поля «Код товара» и «Код покупателя». На рисунке 17 представлена база данных, приведенная к 1НФ. Для приведения к 2НФ необходимо: 1) вынести все частично зависимые поля в отдельную таблицу; 2) определить ключевые поля; 3) установить отношения между таблицами.  Рисунок 17 - База данных, приведенная к 1НФ На рисунке 18 представлена база данных, приведения к 2 НФ.
Рисунок 18 - База данных, приведенная к 2НФ Определим поля «Код товара», «Код покупателя», «Дата» и «Номер накладной» как ключевые. Выделим в отдельные таблицы информацию, связанную с товаром, покупателями и накладными. Определим связь 1:1 между таблицами ПОКУПАТЕЛИ и НАКЛАДНЫЕ, и связь 1:М между таблицами НАКЛАДНЫЕ и ОТПУСК_ТОВАРА_СО_СКЛАДА, ТОВАР и ОТПУСК_ТОВАРА_СО_СКЛАДА Для приведения к 3НФ необходимо из таблиц исключить поля, которые не зависят от ключа. Исключаем вычисляемые поля «Стоимость» и «Итог». На рисунке 19 представлена база данных, приведенная к 3НФ.  Рисунок 19 - База данных, приведенная к 3НФ 13. Язык манипулирования данными для реляционной модели (DDL). Для манипулирования данными в реляционной модели используются два формальных аппарата: - реляционная алгебра, основанная на теории множеств; - реляционное исчисление, базирующееся на исчислении предикатов первого порядка. Механизмы реляционной алгебры и реляционного исчисления эквивалентны, т.е. для любого допустимого выражения реляционной алгебры можно построить эквивалентную формулу реляционного исчисления и наоборот Отличаются два этих формальных аппарата уровнем процедурности. Выражения реляционной алгебры строятся на основе алгебраических операций (высокого уровня), и подобно тому, как интерпретируются арифметические и логические выражения, выражение реляционной алгебры также имеет процедурную интерпретацию. Другими словами, запрос, представленный на языке реляционной алгебры, может быть реализован как последовательность элементарных алгебраических операций с учетом их старшинства и возможного наличия скобок. Для формулы реляционного исчисления однозначная интерпретация (соответствующая однозначная последовательность действий), вообще говоря, отсутствует. Формула только устанавливает условия, которым должны удовлетворять кортежи результирующего отношения. Поэтому языки реляционного исчисления являются более непроцедурными или декларативными. Операции, реализуемые с помощью указанных аппаратов, обладают важным свойством: они замкнуты на множестве отношений. Это означает, что выражения реляционной алгебры и формулы реляционного исчисления определяются над отношениями реляционных БД и результатом вычисления также являются отношения. В результате любое выражение или формула могут интерпретироваться как отношение, что позволяет использовать их в других выражениях или формулах. Как мы увидим, алгебра и исчисление обладают большой выразительной мощностью, очень сложные запросы к базе данных могут быть выражены с помощью одного выражения реляционной алгебры или одной формулы реляционного исчисления. Именно по этой причине такие механизмы включены в реляционную модель данных. Конкретный язык манипулирования реляционными БД называется реляционно полным, если любой запрос, выражаемый с помощью одной операции реляционной алгебры или одной формулы реляционного исчисления, может быть выражен с помощью одного оператора этого языка. Заметим, что крайне редко алгебра или исчисление принимаются в качестве полной основы какого-либо языка БД. Обычно (как, например, в случае языка SQL) язык основывается на некоторой смеси алгебраических и логических конструкций. Тем не менее знание алгебраических и логических основ языков баз данных часто бывает полезно на практике. Structured Query Language (SQL) — язык структурированных запросов, с помощью него пишутся специальные запросы (SQL инструкции) к базе данных с целью получения этих данных из базы и для манипулирования этими данными. С точки зрения реализации язык SQL представляет собой набор операторов, которые делятся на определенные группы и у каждой группы есть свое назначение. В сокращенном виде эти группы называются DDL, DML, DCL и TCL. 1 2 |
