Этапы проектирования инфологической структуры базы данных

Требования к базам данных

Проектирования, создания, эксплуатации.

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

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

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

Хорошо спроектированная база данных:

ü удовлетворяет всем требованиям пользователей к содержимому базы
данных.

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

ü гарантирует непротиворечивость и целостность данных.

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

ü обеспечивает естественное, легкое для восприятия структурирование
информации.

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

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

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

1. Анализ предметной области и определение информационных
потребностей к базе данных.

2. Выбор информационных объектов и атрибутов (характеристик), которые однозначно их определяют;

3. Установление объектам и атрибутам соответствующие им таблицы и столбцы (поля).

4. Определение атрибутов, которые уникальным образом идентифицируют
каждый объект - ключевых полей.

5. Формирование связей между объектами (таблицами и столбцами),

6. Установление правил, поддерживающих целостность данных.

7. Нормализация таблиц.

8. Планирование вопросов надёжности и секретности информации.

Подробнее о каждом этапе.

1.

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

Все требования заказчика - техническое задание на проектирование БД - рекомендуется на этом этапе задокументировать и скрепить подписями.

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

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

Какой ассортимент товаров?

Какой прейскурант товаров?

Каковы ежедневные продажи всего магазина?

Сколько товаров находится в магазине (на складе и в торговом зале)?

Продажи какого товара приносят наибольшую выручку магазину?

Сколько продавцов работает в магазине?

Каков их средний возраст?

Какова выручка каждого продавца от продаж?

Какова ежедневная выручка от продаж всех продавцов?

В какой день была максимальная выручка?

Фамилии лучших продавцов, выручка которых больше средней? и т.д.

G Примечание.

Не ленитесь составлять примерный вопросник при проектировании БД - он вам ещё дважды понадобится - при выборе информационных объектов и составлении запросов.

2.

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

При формировании модели базы данных следует учесть:

ü функциональную деятельность предметной области;

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

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

Например, процесс "продажа товаров" идентифицирует такие объекты как ТОВАРЫ, ПРОДАВЦЫ, ПРОДАЖИ.

ü определение характеристик (атрибутов) этих объектов;

Например, объект ПРОДАВЦЫ может включать такие атрибуты как Идентификатор (табельный номер) продавца, Фамилия, Имя, Отчество, Дата рождения, Адрес, Категория, Зарплата и т.д.

ü определение взаимосвязей между объектами.

Например, каким образом объекты ТОВАРЫ, ПРОДАВЦЫ взаимодействуют друг с другом? Продавец продаёт много товаров, а один вид товара может быть продан разными продавцами.

При выборе информационных объектов необходимо работать с техническим заданием к БД (требования заказчика) и отвечать на следующие вопросы:

• На какие группы можно разбить данные, подлежащие хранению в БД?

• Какое имя можно присвоить каждой группе?

• Какие характеристики каждой группы нужно выделить?

• Какие данные нужны для получения и представления требуемой информации?

3.

На следующем этапе каждому информационному объекту с определёнными атрибутами ставится в соответствие одна или несколько таблиц со столбцами, отражающими свойства (атрибуты) этого объекта. Каждый атрибут должен появляться только один раз; следует решить, какая таблица будет являться владельцем какого набора столбцов (атрибутов).

Пример. В ходе анализа работы магазина можно выделить данные,

относящиеся к группе «Товары»: а также данные группы «Продавцы»:

- название товара, - фамилия, имя, отчество,

- цена за единицу товара, - дата рождения,

Таким образом, выделили два информационных объекта:

«Товары» и «Продавцы» с соответствующими характеристиками.

4.

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

Например:

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

2) можно ввести специальное поле для ключа (код товара, код продавца).

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

«Товары»:

Код товара	Название	Цена
	Системный блок	1000р.
	Монитор	800р.
	Клавиатура	100р.
	Мышь	50р.

«Продавцы»:

Код продавца	ФИО	Дата рождения
	Петрова Е.П.	12.05.1980
	Сидоров К.З.	01.05.1985
	Иванов Т.П.	31.12.1982
	Крутова А.Г.	12.07.1995

Рис.5. Пример рабочего бланка.

5.

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

Пример. Связь ПРОДАВЦЫ и ТОВАРЫ характеризуется как «многие ко многим», так как каждый продавец может продать несколько видов товаров, а товар определенного вида может быть продан несколькими продавцами.

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

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

Пример. Дополнительной, связующей таблицей в нашем примере может быть таблица ПРОДАЖИ, так как продавец связывается с товаром именно в рабочем процессе, называемом продажей товара.

Таблица ПРОДАЖИ отражает рабочий процесс в предметной области Магазин и потому является фактически основной (иногда называют рабочей), а таблицы ПРОДАВЦЫ и ТОВАРЫ – справочными, содержащими уточняющие сведения о продавцах и товарах.

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

Рис.6. Инфологическая модель базы данных «Магазин»

6.

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

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

• определение типа данных, • установка значений по умолчанию,

• задание размера данных, • определение ограничений

• определение формата данных, целостности,

• создание ключевых полей, • определение проверочных условий.

7.

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

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

• устранения логических ошибок;

• удаления избыточного дублирования данных,

• группирования информации в логически связанных единицах.

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

Справка для более подробного изучения нормализации.

Лежащая в основе нормализации математическая теория довольно сложна. В логическом проектировании наиболее эффективная структура данных представляется в виде Нормальных Форм (НФ). Существует несколько видов нормальных форм: первая нормальная форма (1НФ), вторая нормальная форма (2НФ), третья нормальная форма (ЗНФ), нормальная форма Бойса-Кодда (НФБК), четвертая нормальная форма (4НФ), пятая нормальная форма (ЗНФ). С практической точки зрения достаточно трех первых форм. Поэтому мы ограничимся изучением процесса приведения отношений к первым трем формам.

Этот процесс включает:

1) устранение повторяющихся записей и повторяющихся групп записей для одного значения первичного ключа - приведение к 1НФ;

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

3) удаление транзитивно зависимых атрибутов - приведение к ЗНФ.

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

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

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

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

Правила нормализации таблицы

1. Каждое поле любой таблицы должно быть уникальным (не должно быть повторяющихся полей).

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

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

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

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

8.

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

Для этого необходимо ответить на следующие вопросы:

· кто будет иметь права (и какие) на использование базы данных;

· кто будет иметь права на модификацию, вставку и удаление данных;

· нужно ли делать различие в правах доступа;

· каким образом обеспечить общий режим защиты информации и т.п.

Обычно эти задачи решаются совместно с системным администратором БД.

Дата добавления: 2015-05-09