Проектирование бд.

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

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

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

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

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

4. оценка физической модели БД.

5. реализация БД.

Первый этап включает в себя:

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

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

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

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

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

Процедуры хранения данных в БД должны подчиняться следующим основным принципам:

• целостность и непротиворечивость данных, под которыми понимаются:

• физическая сохранность данных;

• предотвращение неверного использования данных;

• поддержка допустимых сочетаний их значений;

• защита от структурных искажений и несанкционированного доступа;

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

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

Следующий этап, нормализация модели, является основой построения оптимальной реляционной БД.

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

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

Введение нормализации таблиц при разработке информационной модели обеспечивает минимальный объем физической БД (записанной на каком-либо носителе) и ее максимальное быстродействие. Нормализация модели выполняется в несколько этапов.

Этапы нормализации:

1. Если данные о предметной области занести в одну двумерную таблицу, в которой все поля являются простыми, то такая таблица будет представлять собой первую нормальную форму (1НФ) реляционной модели данных (РМД).

Пример. Возьмем предметную область "Поставка товара". Пусть таблица (отношение C), соответствующая первой нормальной форме РМД, содержит следующие атрибуты (Поставщик, Товар, Город, Факс, Телефон, Стоимость транспортировки, Объем поставки). Составной ключ <Поставщик+Товар> однозначно идентифицирует строки таблицы (записи). Имеется зависимость атрибутов < Город, Факс, Телефон, Стоимость транспортировки> от части ключа <Поставщик>. Это ведет к дублированию данных, если Поставщик поставляет не один Товар. В этом случае возникает проблема контроля избыточных данных, так как изменение любого из указанных атрибутов придется производить во всех кортежах для данного Поставщика.

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

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

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

Пример. Исключив зависимые атрибуты из отношения С, получим отношение D (Поставщик, Товар, Объем поставки). Отношение Е (Поставщик, Город, Факс, Телефон, Стоимость транспортировки) получим, объединив часть ключа и зависимые от него атрибуты.

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

Пример. В отношении Е атрибут<Стоимость транспортировки> зависит от ключа не прямо, так как зависит от атрибута <Город>. Эта зависимость транзитивная. Выделив эти атрибуты в отдельное отношение из отношения Е, получим два новых отношения F (Город, Стоимость транспортировки) и G (Поставщик, Город, Факс Телефон) вместо отношения Е. Заменив Е отношениями F и G, совершили приведение отношения, находящегося в 2НФ в третью нормальную форму (3НФ).

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

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