Проектирование схемы приложения. Эффективное использование синонимов в схеме приложения

Проектирование схемы приложения

·  Планирование для схемы приложения таблиц и ограничений целостности

·  Использование в схемах приложения представлений и синонимов.

·  Управление таблицами, представлениями и синонимами приложения.

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

• Планирование в схеме приложения таблиц базы данных

• Задание правил целостности и определение в приложении отношений таблиц

• Эффективное использование представлений в приложении

• Создание таблиц и представлений и управление ими

Проектирование схемы приложения

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

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

Проектирование таблиц и нормализация

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

Один из аспектов нормализации вы можете быстро понять, изучив простой пример, в котором используется таблица CUSTOMER. На рис. 15.1 представлены два способа, с помощью которых вы можете создать таблицу CUSTOMER. Заме­тим, что первая версия имеет атрибут NAME, содержащий конкатенированные значения имени и фамилии покупателя. Разбив столбец NAME (содержащий отно­шение к себе) на простую структуру (со столбцом для имени FIRST и фамилии LAST каждого покупателя), вы можете нормализовать таблицу CUSTOMER до степени, показанной во второй версии.

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

SELECT... FROM customer ORDER BY last

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

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

Совет

В большинстве случаев при проектировании базы дан­ных вам следует стараться устранить избыточность данных. Однако в некоторых ситуациях вы можете за­метно улучшить производительность приложений, це­ленаправленно создавая избыточность данных. Это связано с тем, что, если при проектировании базы дан­ных объединить атрибуты в некоторых таблицах в еди­ное целое (как в первой версии таблицы ORDERS на рис. 15.2), устраняется необходимость выполнять в приложениях операцию объединения с использовани­ем связанных, но отдельно хранящихся таблиц. Улуч­шая производительность приложения, это приводит к дополнительным затратам памяти на диске. При проек­тировании схемы нужно добиваться необходимого компромисса между избыточностью данных и норма­лизацией таблиц.

Другим вопросом нормализации является определение отношений между раз­личными атрибутами схемы. Например, таблицы ORDERS и ITEM на рис. 15.3 связаны через поле ID. Так как каждому заказу может соответствовать несколько видов товаров, это отношение является отношением "один ко многим". Такой процесс четкой идентификации отношений таблиц является основой для определе­ния в базе данных первичных ключей и правил ссылочной целостности.

Определение отношений в схеме можно представить в виде простых диаграмм. Рис. 15.3 показывает диаграмму отношений для базы данных, используемой в дан­ной книге.