Конспект лекций по дисциплине «Управление данными» Шахты 2010

Вид материала

Конспект

Содержание Зависимость соединения без потерь Целостность объектов Целостность приложений Выбор СУБД. Конструирование физических объектов базы данных

Подобный материал:

• Конспект лекций 2010 г. Батычко Вл. Т. Муниципальное право. Конспект лекций. 2010, 2365.6kb.
• Конспект лекций 2010 г. Батычко В. Т. Уголовное право. Общая часть. Конспект лекций., 3144.81kb.
• Конспект лекций для студентов специальности 080504 Государственное и муниципальное, 962.37kb.
• Конспект лекций для студентов ссузов Кемерово 2010, 1664.44kb.
• Конспект лекций по дисциплине «Маркетинг», 487.79kb.
• Конспект лекций для студентов специальности 080110 «Экономика и бухгалтерский учет, 1420.65kb.
• Конспект лекций по курсу «управление качеством», 1487.57kb.
• Конспект лекций по курсу «управление качеством», 1507.97kb.
• Конспект лекций по дисциплине «Стратегическое управление», 960.8kb.
• В. Ф. Панин Конспект лекций по учебной дисциплине "Теоретические основы защиты окружающей, 1559.17kb.

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

Отношение Преподаватели: Отношение Дисциплины: Отношение ВидыЗанятий:

КодПреп	Преподаватель		КодДисц	Дисциплина		КодПреп	КодДисц	Вид
01	А		БД	Базы данных		01	БД	Лек
02	Б		УД	Управление данными		01	БД	Лаб
						01	УД	Лек
						02	УД	Лаб

Отношение Занятия:

Курс	Группа	Дата	Пара	Ауд	КодПреп	КодДисц	Вид
3	18	01.09.06	1	306	01	БД	Лек
3	18	01.09.06	2	311	02	БД	Лаб
3	7	02.09.06	1	438	01	УД	Лек
3	7	02.09.06	2	438	02	УД	Лаб
3	7а	02.09.06	1	311	01	УД	Лек

Отношение находится в третьей нормальной форме (3НФ), если оно находится в 2НФ и в нем отсутствуют функциональные зависимости между неключевыми атрибутами или, иначе, в нем отсутствуют транзитивные зависимости. Если для атрибутов А, В и С некоторого отношения существуют зависимости А  В и В  С, то атрибут С транзитивно зависит от А. Если в отношении имеются транзитивно-зависимые атрибуты, то они должны быть удалены и помещены в новое отношение вместе с копией их детерминанта. Например, в отношении Посещаемость атрибуты Ф, И, О транзитивно, через атрибут НомЗач зависят от первичного ключа – совокупности атрибутов Курс, Группа, Дата, Пара и Ауд:

Курс	Группа	Дата	Пара	Ауд	КодПреп	КодДисц	Вид	НомЗач	Ф	И	О
3	18	01.09.06	1	306	01	БД	Лек	17100	А
3	18	01.09.06	2	311	02	БД	Лаб	17100	А
3	7	02.09.06	1	438	01	УД	Лек	14200	И
3	7	02.09.06	2	438	02	УД	Лаб	14201	П
3	7а	02.09.06	1	311	01	УД	Лек	15150	С

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

Отношение находится в четвертой нормальной форме, если оно находится в НФБК и в нем от­сутствуют многозначные зависимости. Многозначная зависимость представляет такую зависимость между атрибутами А, В и С, что А  В и А  С, но В  С и С  В. Нормализация отношения НФБК в отношения 4НФ заключается в выделении в новые отношения атрибутов, участвующих в многозначной зависимости вместе с копией одного или нескольких детерминантов. Для нашего примера многозначная зависимость теоретически может возникнуть, например, если одну дисциплину и вид занятий ведет несколько преподавателей одновременно.

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

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

Целостность объектов предполагает выполнение следующих правил:

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

Проверка этих ограничений реализуется средствами СУБД.

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

1. Обязательность значений атрибута;
   
2. Соответствие диапазону значений;
   
3. Соответствие множеству значений;
   
4. Соответствие типу и размеру данных;
   
5. Соответствие шаблону;
   
6. Выполнение делового регламента.
   

Ссылочная целостность обеспечивается выполнением ограничений внешнего клю­ча дочерней схемы отношения, логически связанного с родительским ключом схемы-предка. В ка­честве родительского ключа выбирается первичный ключ либо вторичный ключ из числа потенци­альных. Основное требование к родительскому ключу – уникальность его значений, для этого клю­ча допускаются неопределенные значения типа NULL. Ограничение внешнего ключа заключается в том, что каждое его значение должно совпадать с одним из значений родительского ключа либо может принимать неопределенное значение.

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

1. Включение нового кортежа в дочернее отношение допускается только, если отношение-предок содержит значения родительского ключа, совпадающее со значением внешнего ключа для вводимого кортежа.

2. Удаление кортежа из дочернего отношения не приводит к нарушению ссылочной целостности.

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

4. При включении нового кортежа в родительское отношение никаких проверок не производится.

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

5-1. Каскадное удаление кортежей дочернего отношения, внешний ключ которых совпадает со значением удаляемого роди­тельского ключа.

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

5.3. Установка внешнего ключа в неопределенное значение. При удалении кортежа из ро­дительского отношения во всех ссылающихся на него кортежах дочернего отношения атрибут внешнего ключа устанавливается в неопределенное значение NULL.

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

6. Обновление кортежа родительского отношения. В этом случае возможно применение всех правил, которые были сформулированы для выполнения операции удаления кортежа из родитель­ского отношения.

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


Выбор СУБД.

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

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

Для каждого из перечисленных параметров, наряду с ко­личественной оценкой, вводится весовой коэффициент, а рейтинг конкурирую­щей СУБД определяется суммированием произведения оценки на значение весо­вого коэффициента.

В качестве платформы для реализации корпоративных приложений реко­мендуется применять промышленные СУБД, которые характеризуются высокой степенью масштабируемости, наличием механизма обработки транзакций, пол­ной поддержкой стандарта SQL


Конструирование физических объектов базы данных


Проектирование физической модели данных представляет отображение логической модели данных в среду выбранной СУБД. Исходными данными для проектирования фи­зической модели данных являются: логическая модель данных с комплектом со­проводительной документации, функциональные и технические характеристики выбранной СУБД, требования к производительности системы. Основными задачами, решаемыми на этапе проектирования физической модели данных, являются:

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

Большинство этапов физического проектирования реализуется с учетом возможностей выбранной СУБД.

Первой задачей физического проектирования баз данных является приня­тие решения о целесообразности денормализации таблиц. Денормализация – процесс целенаправленного введения избыточности в базы данных, позволяющий улучшить производительность системы. Увеличение избыточности данных приводит к уменьшению количества операций соединения таблиц в процессе выполнения SQL-запросов и, как следст­вие, улучшает реактивность информационной системы. Однако, при этом увеличиваются затраты на обновление данных, уменьшается гибкость системы и усложня­ется ее реализация. Поэтому денормализацию целесообразно производить только для таблиц, к которым осуществляются очень частые обращения на выборку данных, и редкие – на изменение. Основными видами денормализации являются: нисходящая, восходящая и внутритабличная.

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

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

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

В процессе решения задач «создание таблиц, определение свойств ключей и атрибутов» и «связывание таблиц, определение требований целостности» необходимо определить тин и размер данных для атрибутов таблицы, предложить процедуры реализации ограничений первичных и внешних ключей, обязательности значений атрибутов. В качестве исходных данных ис­пользуется логическая модель данных, в которой атрибутам назначены опреде­ленные домены. Основная проблема описания атрибутов при создании таблиц состоит в корректном сопоставлении доменов типам и размерам данных, поддер­живаемых используемой СУБД, а так же наличием в ней тех или иных средств поддержки ограничений целостности.

При реализации ограничений предметной области необходимо предусмотреть средства для проверки значений в атрибутах таблиц, имеющих ограниченное множество значений: пол человека может быть только «мужской» или «женский», оценка – 2, 3, 4 или 5 и т.д. В качестве таких средств могут быть использованы правила или специально созданные функции, триггеры, хранимые процедуры. Если СУБД не поддерживает те или иные из указанных средств, то такие ограничения приходится реализовать на уровне приложения, обслуживающего базу данных.

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

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

• транзакции, наиболее важные для работы организации;

• периоды времени на протяжении суток/недель, в которые нагрузка БД возрастает до максимума (называемые периодами пиковой нагрузки).

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

Во многих случаях проанализировать все ожидаемые транзакции просто невозможно, поэтому необходимо тем или иным образом выбрать наиболее важные. Существует эмпирическое правило, согласно которому выполнение около 20% наиболее активных запросов пользователей создает примерно 80% нагрузки на базу данных (правило Парето). Для определения того, какие из транзакций подлежат детальному анализу, строится таблица соответствия, состоящая из отношений, доступ к которым происходит при выполнении каждой транзакции. Например, в таблице приведено соответствие количества транзакций в единицу времени и отношений для типичных операций ввода, обновления, удаления и выборки.

Отношение	Транзакция
Операции «со студентами»	Операции с «занятиями»	Операции с «прогулами»
Чт	Доб	Уд	Изм	Чт	Доб	Уд	Изм	Чт	Доб	Уд	Изм
Студенты	2	1	0	0	0	0	0	0	50	25	0	0
Занятия	0	0	0	0	2	5	1	1	50	25	0	0
Прогулы	0	0	0	0	0	0	1	1	50	25	2	2

Таблица показывает, что операции с отношениями «Студенты» и «Занятия» редки и независимы друг от друга. Доступ к отношению «Прогулы» выполняется очень часто, и при этом обязательно используются другие отношения. Поэтому, задача обеспечения эффективного доступа к этому отношению может оказаться очень важной с точки зрения обеспечения высокой производительности системы.

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

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