Программирование баз данных MS SQL Server (1084479), страница 80
Текст из файла (страница 80)
Рис. В.19. Диалоговое оюю ТаЫеэ апсг' Со(игппз Рис В.20. Диалогоеое окно с оиределением связи 316 Глава 8 Закончив выполнение указанных действий, щелкните на кнопке ОК и ознакомьтесь с новой линией связи, появившейся на диаграмме. Описание полученных результатов Во многом аналогично тому, что происходит при выполнении операции добавления таблицы, описанной в предыдущем разделе, при внесении указанных изменений в программном обеспечении 5Я1. Вегчег формируется сценарий 8111.. В текущем практическом занятии рассматривалось только создание на диаграмме новой связи. Перетащив курсор мыши над этой связью, можно обнаружить всплывающую подсказк), которая содержит имя связи и указывает, к чему она относится (рис.
8.21). ::. т срчьь Й.Вм..о . з ),~чччч ври р О 1:)6чьУМР Р Р1 ,'Цич ° кв еоь хз П Рис. 8.21. Всплывающая подсказка, относящаяся к связи Обфатите внимание на то, что на 1рис. 8. 21 )рядом с именами обеих пшблии покозаньр звез- дочки. Дело в том, что внесенные изменения были лишь добавлены к списку изменений, от- носящемуся к данной диас)рампе, а в физическую базу данных они будут внесены только после щелчка па кнопке Заве для сох)ранения диаераммьр л р чае отмены действия ограничения внешнего ключа способ отображения этой линии изменяется. Информацию о том, как р 822 д „„„ можно отменить действие ограничений, см.
в главе 7. Но такую же операцию отмены можно выполнить с помощью диалога ющая опьиененнозсу ваго окна Йе!а1юпэййр, установив значение по в разворачиваю- ое)заничению щемся списке, который относится к полю Еп1огсе Роге!Вп Кеу Сопэ1га!п1. После выполнения этого действия линия связи изменяется (рис. 8.22), свидетельствуя о том, что действие ограничения отменено. При изучении диаграмм "сущность — связь", относящихся к фактически эксплуатируемым базам данных, следует всегда обращать внимание на линии связи, обозначающие отмененные ограничения. Возможно, что ограничение отменено не случайно, р „° рр Нормализация н другие важные проблемы проектирования 317 Денормализация Деиормализация — это процесс, противоположный нормализации.
Хотя задача денормализации является достаточно сложной, в настоящем разделе описанию этой темы будет отведено довольно мало места, однако прежде всего следует отметить, что иногда денормализация действительно является оправданной, но это не означает, что нужно отказаться от нормализации данных. Как было указано выше в настоящей главе, иногда проектировщики баз данных слишком злоупотребляют нормализацией данных. Для них целью становится решение самой этой задачи как таковой, поэтому нормализация данных осуществляется исключительно ради нормализации, а не для усовершенствования структуры базы данных. Ниже приведен ряд соображений по этому поводу.
О Если включение в таблицу вычисляемого столбца или сохранение вней некоторых производных данных позволяет повысить эффективность формирования отчетов, то следует, безусловно, воспользоваться такой возможностью. Но при этом не следует забывать, что преимущества такого решения должны перевешивать недостатки. (Например, необходимо определить, не случится ли так, что "итоговые" данные когда-либо перестанут соответствовать данным, на основе которых они получены. Как узнать, что этого не произошло, и как исправить положение, если такое случилось)) Иногда благодаря включению в таблицу лишь одного денормализованного столбца (или нескольких таких столбцов) удается избежать необходимости применения соединений для выборки информации или значительно сократить количество таких соединений.
Нужно научиться распознавать подобные ситуации; фактически они возникают довольно часто. Самому автору встречались такие ситуации, в которых в результате добавления одного столбца к часто применяемой базовой таблице появилась возможность перейти от использования соединения девяти таблиц к соединению всего лишь трех таблиц и таким образом сократить продолжительность выполнения запроса примерно на 90%.
О Если ведется накопление исторических данных, которые в основном остаются неизменными и используются лишь для формирования отчетов, то проблемы обеспечения целостности данных становятся гораздо менее значимыми. После того как данные проверены и записаны в область памяти, допускающую только чтение, можно на полном основании быть уверенным в том, что при работе с этими данными не придется сталкиваться с проблемами нарушения синхронизации, для решения которых главным образом и предназначены методы нормализации данных.
С того момента как данные становятся историческими, может оказаться гораздо удобнее (и быстрее) просто уменьшить количество уровней в структуре представления данных (осуществить денормализацию). Это позволяет значительно сократить количество таблиц, применяемых для хранения данных, и ускорить работу с ними. Чем меньше таблиц приходится применять для создания соединений, тем охотнее рядовые пользователи будут заниматься составлением собственных отчетов. Это позволяет все больше и больше улучшать подготовку сообщества пользователей в области применения тех инструментальных средств, которые для них предназначены.
В конечном итоге начинает увеличиваться количество пользователей, обращающихся к администратору базы данных за разрешением 318 Глава 8 на предоставление непосредственного доступа к базе данных в целях получения собственных специализированных отчетов. Дело в том, что для многих пользователей база данных с высокой степенью нормализации выглядит как лабиринт и становится фактически неприменимой, а после некоторой денормализации данных работа основной массы сотрудников предприятия значительно упрощается. Несмотря на все сказанное в этом разделе, если есть основания полагать, что из-за низкой степени нормализации база данных будет иметь низкую производительность, то следует обеспечить ее нормализацию, ведь реляционные системы создаются именно с этой целью.
А если применяемая степень нормализации является слишком высокой, это лишь означает, что улучшается поддержка целостности данных и достигается высокая производительность в транзакционной среде. Методы повышения производительности, не связанные с нормализацией В настоящем разделе приведены основные рекомендации по проектированию, позволяющие повысить производительность базы данных, которые не связаны с применением нормализации. Лишь немногие из этих рекомендаций могут рассматриваться как четкие и однозначные правила. Скорее их можно трактовать как информацию к размышлению. При этом наиболее важное соображение заключается в том, что, несмотря на столь важную роль нормализации с точки зрения проектирования базы данных, это — не единственный метод усовершенствования структуры базы данных.
Неуклонное стремление к упрощению Безусловно, время от времени разработчики в результате неустанных поисков обнаруживают новые, более эффективные способы организации работы. Некоторые выдвигаемые при этом идеи действительно являются невероятно восхитительными и чрезвычайно полезными. Встречаются и другие открытия, которые также великолепны, но не очень полезны. Однако не менее часто возникают предложения, которые, возможно, и носят отпечаток новизны, но не становятся практически применимыми лишь благодаря этому. По мнению автора, не нужно подавлять в себе творческое начало и стремиться всегда использовать лишь давно сложившиеся методы. Не следует только забывать, что тщательно проверенные и признанные правильными подходы применяются снова и снова по одной причине — они обычно оправдываются.
В версии ЯО1. Бегчег 2005 предложено очень много мощных и гибких новых дополнений. Эта версия программного продукта позволяет реализовывать сложные правила работы с данными и даже сложные типы данных (с помощью управляемых кодом функций и типов данных) Поэтому стало еще труднее удержаться от соблазна увлечься новинками и реализовать на их основе более сложное решение по сравнению с минимально необходимым. Старайтесь избегать использования таких подходов, в результате осуществления которых база данных становится сложнее по сравнению с тем, что действительно требуется. Минималистский подход обычно (хотя и не всегда) приводит к созданию базы данных, которой не только проще управлять, но проще добиться от нее высокой производительности.
Нормализация н другие важные проблемы проектирования 319 Правильный выбор типов данных Основным принципом выбора наиболее подходящего типа данных является такая рекомендация, что следует всегда выбирать минимально допустимый тип данных. Иными слонами, выбирайте необходимые типы данных, но только самые необходимые. Например, если в базе данных требуется хранить данные о месяцах (представленные в виде числа от 1 до 12), то для этого достаточно предусмотреть один байт, воспользовавшись типом данных скпукпс. Тем не менее автору регулярно приходится встречать такие базы данных, в которых поле, предназначенное для хранения только номера месяца, объявляется с типом данных кпс (для которого требуется 4 байта).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
