авторефераты диссертаций БЕСПЛАТНАЯ БИБЛИОТЕКА РОССИИ

КОНФЕРЕНЦИИ, КНИГИ, ПОСОБИЯ, НАУЧНЫЕ ИЗДАНИЯ

<< ГЛАВНАЯ
АГРОИНЖЕНЕРИЯ
АСТРОНОМИЯ
БЕЗОПАСНОСТЬ
БИОЛОГИЯ
ЗЕМЛЯ
ИНФОРМАТИКА
ИСКУССТВОВЕДЕНИЕ
ИСТОРИЯ
КУЛЬТУРОЛОГИЯ
МАШИНОСТРОЕНИЕ
МЕДИЦИНА
МЕТАЛЛУРГИЯ
МЕХАНИКА
ПЕДАГОГИКА
ПОЛИТИКА
ПРИБОРОСТРОЕНИЕ
ПРОДОВОЛЬСТВИЕ
ПСИХОЛОГИЯ
РАДИОТЕХНИКА
СЕЛЬСКОЕ ХОЗЯЙСТВО
СОЦИОЛОГИЯ
СТРОИТЕЛЬСТВО
ТЕХНИЧЕСКИЕ НАУКИ
ТРАНСПОРТ
ФАРМАЦЕВТИКА
ФИЗИКА
ФИЗИОЛОГИЯ
ФИЛОЛОГИЯ
ФИЛОСОФИЯ
ХИМИЯ
ЭКОНОМИКА
ЭЛЕКТРОТЕХНИКА
ЭНЕРГЕТИКА
ЮРИСПРУДЕНЦИЯ
ЯЗЫКОЗНАНИЕ
РАЗНОЕ
КОНТАКТЫ


Pages:     | 1 |   ...   | 19 | 20 || 22 | 23 |   ...   | 33 |

«Е.Мамаев MS SQL SERVER 2000 Книга посвящена одной из самых мощных и популярных современных систем управления базами данных - Microsoft SQL Server 2000. ...»

-- [ Страница 21 ] --

В качестве иллюстрации процесса установки и использования резервного серве ра приведем примерную последовательность команд Transact-SQL, с помощью которой реализуются все три рассмотренные фазы.

USE master GO RESTORE DATABASE MyNwind FROM MyNwind_l WITH STANDBY = 'c:\undo.ldf GO — Применение первого архива журнала транзакций.

RESTORE LOG MyNwind F O MyNwind_logl RM WITH STANDBY = ' c : \ u n d o. l d f GO — Применение второго архива журнала транзакций.

RESTORE LOG MyNwind F O MyNwind_log2 \ RM WITH STANDBY = ' c : \ u n d o. l d f GO -T Эта операция повторяется для каждого архива — журнала транзакций, созданного на основном сервере.

— Произошел сбой основного сервера. Создается резервная — копия журнала транзакций на основном сервере:

BACKUP LOG MyNwind ТО MyNwind_log WITH NOJTRUNCATE GO — Применение последнего созданного архива журнала транзакций — на резервном сервере. Все созданные ранее архивы — журнала транзакций должны быть применены.

RESTORE LOG MyNwind FROM MyNwind_log3,.....

WITH STANDBY = 'c:\undp.ldf' GO ' ' " "' " '. ' ' ' ' • • ' ' - ' • Глава 16. Создание отказоустойчивой системы -- Реконструкция (водстановление) баз данных резервного сервера, — после чего они будут доступны для обычной работы.

RESTORE DATABASE MyNwind WITH RECOVERY GO Технология кластеризации Рассмотренная в предыдущем разделе технология использования резервного сервера позволяет очень быстро восстановить нормальную работу пользователей в случае повреждения базы данных или самого сервера. Однако описанная тех нология имеет существенные недостатки:

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

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

Хотя целью технологии резервного сервера является обеспечение максимально быстрого восстановления работы пользователей, все же на переключение ре зервного сервера в стандартный режим понадобится некоторое время. И пусть это время не слишком велико, все же в некоторых случаях и небольшие простои могут привести к серьезным убыткам. Решением описанных проблем может быть применение кластерных систем (failover support).

В основе технологии кластеризации лежит идея о полном дублировании сете вого сервера. Дублирование сервера обеспечивается на уровне операционной системы. Поддержка кластера реализована только в редакции Enterprise Edition операционной системы Windows NT Server, которую и надо использовать для создания кластера серверов баз данных на основе SQL Server 2000. В операци онных системах семейства Windows 2000 поддержка кластера имеется только в Windows 2000 Advanced Server и Windows 2000 DNA. Помимо операционной системы, ограничение на создание кластера выдвигает и сам SQL Server 2000.

Только редакция Enterprise Edition поддерживает работу в кластере.

,( Замечание ) При создании кластера должны использоваться компьютеры с одинаковыми харак теристиками — объемом оперативной памяти, типов процессоров и т. д.

При создании кластера в SQL Server 7.0 можно было использовать только два сервера. В SQL Server 2000 количество серверов, которые допустимо включать в кластер, увеличилось до четырех. Тем не менее, для простоты изложения мы будем рассматривать кластер, состоящий из двух узлов. Серверы, из которых состоит кластер, объединяются в один виртуальный сервер (virtual server). Серве ры кластера называются узлами (nodes). Контроль узлов кластера осуществляет Часть III. Администрирование ел с помощью службы операционной системы Clustering Service. Пользователи видят только виртуальный сервер и не видят отдельные серверы, входящие в его состав. Типичная структура кластерной системы приведена на рис. 16.1.

( Замечание ) Создание виртуального сервера на уровне SQL Server 2000 осуществляется с ис пользованием мастера установки.

Windows NT Server ЕЕ Рис. 1 6. 1. Общая структура кластерных систем Служба поддержки кластера производит мониторинг работы узлов и при выходе из строя одного из них переносит нагрузку на оставшийся сервер. В нормаль ном режиме задачи обрабатываются обоими серверами. Однако этот процесс отличается от распараллеливания задач при работе SQL Server 2000 на много процессорных системах. В кластере задачи не делятся, а дублируются.

( Замечание ) В кластере могут использоваться многопроцессорные системы. Необходимо, чтобы на узлах работало одинаковое количество процессоров идентичных марок. Общее количество процессоров в кластере может достигать 64.

Хотя задачи дублируются и выполняются на обоих узлах, эти узлы используют общий диск. Один из серверов, называемый основным сервером (primary server), принимает все запросы пользователей, выполняет их и осуществляет всю работу с общим диском. Служба Clustering Services отображает процессы, выполняемые на основном сервере, на другой сервер кластера, который называется вторичным сервером (secondary server). В момент выхода из строя основного сервера на вто ричном имеется вся информация о процессах, выполняемых на основном сер вере. Служба поддержки кластера отключает основной сервер и переносит все запросы пользователей на дополнительный, тем самым делая его основным сер вером. Если же из строя выходит дополнительный сервер, то обработку запро сов продолжает основной. ;

Глава Ш. Создание отказоустойчивой системы 777_ Благодаря такому подходу пользователи могут не обращать внимание на крах сервера и продолжать работу в обычном режиме. Никаких дополнительных дей ствий предпринимать не нужно. Пользователи вообще могут не подозревать, что их задачи выполняет другой сервер. Чтобы добиться подобной функционально сти, серверы должны иметь одинаковые сетевые имена и адреса. В нормальном режиме такая ситуация невозможна. Решение этой задачи ложится на 'службу кластеризации, которая реагирует на единственное сетевое имя и сетевой адрес.

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

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

Типы конфигурации кластеров Для кластеров поддерживается два типа конфигурации:

• Конфигурация "активный-пассивный" (active/passive failover configuration). При работе кластера по этой схеме (рис. 16.2) на основе двух узлов создается один виртуальный сервер, использующий единственный общий диск. Недостатком этого типа кластера является простой дополнительного сервера, который не используется до тех пор, пока основной сервер не выйдет из строя.

Рис. 16.2. Конфигурация "активный-пассивный" П Конфигурация "активный-активный" (active/active failover configuration). Этот тип конфигурации (рис. 16.3) обеспечивает поддержку двух виртуальных сер веров, созданных с использованием двух узлов. Каждый из узлов являетсй основным сервером одного из виртуальных серверов и в то же время допол*:

нительным для другого виртуального сервера. В итоге получаются два Вирту 778 Часть III. Администрирование альных сервера. При этом для каждого из виртуальных серверов использует ся отдельный дисковый накопитель. Преимущество этого типа конфигурации в том, что каждый из узлов кластера загружен работой. Однако в случае вы хода из строя одного из серверов на оставшийся сервер ложится двойная нагрузка. Поэтому узлы в кластерах "активный-активный" должны иметь достаточный запас производительности, чтобы выдержать нагрузку и не вый ти из строя.

Глава 16. Создание отказоустойчивой системы время существует шесть видов ^дисковых массивов, в соответствии с которыми определены шесть основных уровней массивов RAID:

П RAID 0 — чередующийся набор дисков (Striping Set).

О RAID I — зеркальный набор дисков (Mirror Set).

• RAID 2 — набор дисков, в котором применяется чередование данных с ин формацией четности, которая может быть использована для восстановления поврежденных данных. Информация для восстановления получается приме нением операции XOR для всех соответствующих блоков. Недостатком систе мы является низкая производительность при записи и чтении больших бло ков данных.

О RAID 3 — этот уровень отличается от RAID 2 тем, что используемая для вос становления служебная информация всегда хранится на отдельном диске.

Этот диск иногда называется "диском четности". Уровень RAID 3 дает неко торое повышение производительности по сравнению с RAID 2.

• RAID 4 — принципы работы дисковых массивов этого уровня такие же, как и для RAID 3. Единственное отличие в том, что увеличен минимальный раз мер блока, который считывается за одну операцию ввода/вывода.

• RAID 5 — чередующийся набор дисков с контролем четности (Striping Set with Parity).

Производительность дисковых массивов RAID 2, RAID 3 и RAID 4 не высока.

Поэтому в Windows NT эти уровни не применяются. Обычно используются уровни RAID О, RAID 1 и RAID 5. Они обеспечивают в той или иной мере вы сокую производительность в сочетании с большой надежностью систем.

Массивы дисков RAID могут быть реализованы двумя способами:

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

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

780 Часть III. Администрирование Замечание Мы не будем рассматривать создание дисковых массивов RAID при использовании программной реализации, т. к. эта операция не относится непосредственно к SQL Server 2000. Для получения информации по созданию массивов RAID следует обра титься к документации операционной системы.

При использовании RAID-массивов для хранения файлов SQL Server 2000 вся работа по поддержанию файлов ложится на операционную систему. Система хранения SQL Server 2000 обращается к файлам, хранящимся в массивах RAID, точно так же, как, например, к файлам, хранящимся на отдельном диске с фай ловой системой FAT.

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

Зеркальное отображение и дублирование дисков Некоторые данные настолько важны, что их потеря может привести к самым тяжелым последствиям. Кроме того, иногда необходимо обеспечить максималь ную надежность работы операционной системы. Система должна остаться рабо тоспособной даже в случае физического повреждения жесткого диска. Для удов летворения подобных требований и был разработан уровень RAID 1, который может быть реализован в двух вариантах:

• зеркальное отображение дисков;

• дублирование дисков.

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

Затем выполняется связывание второго диска с первым. При этом на нем созда ется точная копия раздела первого диска. Полученный диск называется теневым (shadow disk). Впоследствии, когда будет осуществляться изменение данных на оригинальном диске, все изменения будут в точности отображаться на теневом диске. То есть в каждый момент времени будут иметься две идентичных копии данных. В случае выхода из строя любого из дисков можно будет продолжить работу с оставшимся. Недостаток зеркального набора заключается в том, что при выходе из строя контроллера оба диска окажутся недоступными. Кроме того, подключение обоих дисков к одному контроллеру снижает скорость запи си, но при этом повышается скорость чтения данных. Последнее связано с тем, что считывание может производиться с двух дисков одновременно.

Глава 16. Создание отказоустойчивой системы 781_ Более надежным является дублирование дисков. Для реализации такого подхода также необходимы два диска, но подключены они должны быть к разным кон троллерам. При выходе из строя одного из контроллеров или дисков эксплуата ция системы все равно может быть продолжена. Кроме того, при дублировании дисков исключаются потери в скорости записи.

Массивы RAID 1 позволяют производить замену вышедших из строя дисков.

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

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

Чередование дисков Уровни RAID 0 и RAID 5 позволяют создать чередующийся набор дисков (striping disk set). Набор с чередованием представляет собой совокупность множества фи зических дисков, объединенных в единый виртуальный том. Для создания чере дующегося набора могут быть использованы диски различных моделей и разме ров, подключенные к разным дисковым контроллерам. Но на всех физических дисках всегда используется одинаковое количество пространства. Максимально возможный размер чередующегося набора равен размеру самого маленького дис ка, умноженному на количество дисков в наборе. Пространство физического дис ка, используемое для построения чередующегося набора, называется слоем.

Каждый из слоев разбивается на блоки размером 64 Кбайт. Блоки нумеруются последовательно от начала слоя. Эти блоки объединяются в полосы. Каждая по лоса содержит по одному блоку каждого слоя. Причем номера блоков в полосе совпадают. Полосы нумеруются в соответствии с номерами блоков, входящих в нее. Например, если полоса содержит все блоки с номером 5, то номер полосы также будет равен 5.

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

Мы рассмотрели общую технологию работы чередующихся наборов дисков. Но разница между уровнями RAID 0 и RAID 5 все же значительна.

782 Часть III. Администрирование Массивы RAID 0 являются "чистыми" чередующимися наборами. Для реализа ции RAID 0 можно использовать от 2 до 32 дисков. Этот уровень обеспечивает максимальную производительность, но не возможность восстановления данных в случае повреждения. Строго говоря, технология RAID описывает избыточные дисковые системы, устойчивые к частичному или полному повреждению одного из дисков или контроллеров.

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

Независимо от того, сколько дисков составляют массив RAID 5, для хранения информации о контроле четности отводится место, равное размеру одного слоя набора. Поэтому непроизводственные потери дискового пространства обратно пропорциональны увеличению количества дисков в массиве. Например, при подключении трех дисков теряется примерно 33% дискового пространства. Если же использовать десять дисков, то потери составят всего 10%.

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

Уровень RAID 5 наряду с высокой производительностью также обеспечивает высокую степень надежности. Кроме того, при использовании дисков SCSI до пускается горячая замена поврежденных кластеров. Это означает, что если опе рационная система не может правильно записать данные в тот или иной кла стер, то он будет автоматически помечен как сбойный, а данные будут записаны в рабочий кластер. Можно с уверенностью сказать, что дисковые массивы RAID 5 являются лучшим решением для обеспечения надежности данных наря ду с эффективным использованием дискового пространства и достижением при этом максимальной скорости операций дискового ввода/вывода.

Все вышесказанное о преимуществах массивов RAID 5 может быть с успехом применено к SQL Server 2000. Расположение файлов баз данных на виртуальных томах RAID 5 позволяет автоматически использовать все преимущества наборов дисков с контролем четности.

ЧАСТЬ IV.

РАЗРАБОТКА И СОПРОВОЖДЕНИЕ БАЗ ДАННЫХ Глава 17. Введение в проектирование баз данных Глава 18. Архитектура баз данных Глава 19. Транзакции и блокировки Глава 20. Работа с базой данных Глава 21. Работа с таблицами Глава 22. Использование представлений Глава 23. Индексы Глава 24. Статистика 2 6 Зах. Глава Введение в проектирование баз данных Прежде чем можно будет работать с данными, необходимо создать структуры, в которых они будут храниться. Разработка структуры базы данных — это первая задача, которая стоит перед администратором после установки SQL Server 2000.

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

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

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

По принципам обработки базы данных классифицируются следующим образом:

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

Централизованные базы данных с распределенным доступом являются наи 26* 786 Часть IV. Разработка и сопровождение баз данных более используемыми в настоящее время. Для этой технологии возможны два способа обработки данных:

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

Клиент-сервер. В основе этой концепции лежит идея о том, что помимо • хранения файлов базы данных, центральный сервер должен выполнять и основную часть обработки данных. Пользователи обращаются к централь ному серверу с помощью специального языка структурированных запросов (SQL, Structured Query Language), на котором описывается список задач, выполняемых сервером. Запросы пользователей принимаются сервером и порождают на нем процессы обработки данных. В ответ пользователь по лучает уже обработанный набор данных. Между клиентом и сервером пе редается не весь набор данных, как это происходит в технологии файл сервер, а только данные, которые действительно необходимы пользовате лю. Запрос пользователя длиной всего в несколько строк способен поро дить процесс обработки данных, затрагивающий множество таблиц и миллионы строк. В ответ клиент может получить лишь несколько чисел.

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

Глава 17. Введение в проектирование баз данных • Распределенная база данных. Базы данных этого типа располагаются на не скольких компьютерах. Информация на этих компьютерах может пересекать ся и даже дублироваться. Для управления подобными базами данных предна значена система управления распределенными базами данных (СУРБД).

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

( Замечание J Microsoft SQL Server 2000 обеспечивает построение централизованных баз данных с использованием технологии клиент-сервер. Однако с помощью SQL Server 2000 мо жет быть организована и распределенная база данных, расположенная на множест ве сетевых серверов. С помощью распределенных запросов (distributed query) поль зователи могут в одном запросе обращаться ко множеству источников данных.

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

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

В терминологии баз данных описываемые объекты часто называют сущностями (entity), а сами данные — атрибутами (attribute). Объект (или сущность) — это нечто, существующее в реальном мире и различимое, что имеет название и име ется способ отличать один подобный объект от другого. Сущностью может яв ляться ВУЗ, студент, ручка, аудитория и т. д. Кроме того, помимо физического предмета сущностью могут являтьсд и абстрактные вещи, которые, тем не ме нее, могут быть описаны: лекция, телевизионная передача, правовые нормы, правила поведения и т. д. Группа всех подобных объектов образует набор объек тов. Набором объектов для объекта "сотрудник" будут являться все сотрудники, работающие на предприятии.

Атрибут — это некоторый показатель, характеризующий объект и принимаю щий для каждого конкретного объекта индивидуальное значение (текстовое, числовое и т. п.). Если в качестве объекта рассмотреть сотрудника предприятия, то этот объект будет иметь атрибуты имени, фамилии и отчества, принимающие текстовые значения, числовой атрибут номера подразделения, в котором он ра ботает, атрибут даты рождения, имеющий тип, описывающий дату и время, и 788 Часть IV. Разработка и сопровождение баз данных многие другие атрибуты. Атрибут может являться также и набором объектов.

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

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

• уникальное в пределах отношения имя (name);

• тип данных, которые будут храниться в поле (числовой, символьный, логиче ский и т. д.);

• максимальная длина (или размер), который могут иметь данные, хранящиеся в поле;

• дополнительные характеристики (например, для числовых данных — точ ность, для символьных — формат, и т. д.).

Множество логически связанных полей образуют запись (record). Запись является ничем иным, как строкой таблицы. Экземпляр записи — это отдельная реализа ция записи, содержащая конкретные значения ее полей. Множество экземпляров записи одной структуры образуют таблицу (table). При описании таблицы указы вается последовательность расположения полей и их основные характеристики (имя, длина и точность). Количество записей в таблице может меняться.

Модели данных Мы уже рассмотрели классификацию баз данных по принципам обработки дан ных. В этом разделе будет приведена классификация данных по используемой модели (или структуре) данных. Модель данных (data model) — это совокупность структур данных и операций их обработки. Модель данных включает в себя структуры данных, операции их обработки и ограничения целостности. С по мощью модели данных можно легко изобразить структуру объектов и связи, ус тановленные между ними.

За все время использования компьютеров для обработки данных было разрабо тано множество различных моделей данных. Однако обычно говорят лишь о трех основных моделях:

• Иерархическая модель данных. Эта модель данных представляет собой сово купность связанных элементов, образующих иерархическую структуру. Свя занные объекты образуют перевернутый граф (перевернутое дерево). К ос новным понятиям иерархической модели данных относятся уровень, элемент (или узел) и связь. Узлом называется совокупность атрибутов данных, описы вающих некоторый объект. Каждый узел связан с одним узлом более высо кого уровня и с любым количеством (в т. ч. и с нулем) узлов нижнего уров ня. Исключением является узел самого высокого уровня, который не связан Глава 17. Введение в проектирование баз данных ни с одним узлом более высокого уровня. Этот узел называется корнем дере ва. Подчиненные узлы располагаются на втором, третьем и т. д. уровнях. Ко личество деревьев в базе данных определяется количеством корней деревьев.

К каждой записи базы данных существует единственный путь от корневой записи. Примером иерархической модели данных может служить адрес. Дей ствительно, на первом уровне (в корне дерева) лежит планета Земля, на вто ром уровне — страна, на третьем — регион (штат, республика, край, район и т. п.), затем город, улица, дом и квартира. Один и тот же город не может принадлежать двум странам или районам. Другим примером иерархической модели является пространство доменных имен в Интернете — система DNS.

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

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

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

Система управления базами данных Microsoft SQL Server 2000, как и большая часть других современных СУБД, предназначена для работы именно с реляци онными базами данных. SQL Server 2000 обеспечивает построение централизо ванных баз данных с помощью технологии клиент-сервер.

Реляционная модель данных Датой рождения реляционной теории баз данных можно считать 6 июня 1970 г., когда сотрудник фирмы IBM, доктор Э. Кодд, опубликовал статью "Реляционная модель данных для больших коллективных банков" ("A relational Model of Data for Large Shared Data Banks"). Именно в этой статье был впервые использован термин 790 Часть IV. Разработка и сопровождение баз данных "реляционная модель данных". Однако первые работы на эту тему появились еще в конце 60-х годов. В них обсуждалась возможность использования при проекти ровании баз данных так называемых табличных даталогических моделей, обеспе чивающих привычные и естественные способы представления данных.

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

Будучи математиком по образованию, Э. Кодд предложил использовать для об работки данных аппарат теории множеств, а конкретно — объединение, пересе чение, разность, декартово произведение и др. Он доказал, что любой набор данных может быть представлен в виде простых двумерных таблиц, называемых в математике "отношением". В английском варианте "отношение" пишется как "relation". От этого слова и произошло название "реляционная модель данных".

Разработанная Коддом теория реляционных баз данных описывает правила эф фективной организации данных и управления ими.

( Замечание ) Отношение является ни чем иным, как обычной таблицей или сущностью.

Каждая реляционная таблица представляет собой двумерный массив и обладает следующими свойствами:

• любой элемент таблицы является минимальным элементом данных;

П элементы в пределах одного столбца имеют одинаковый тип (числовой, сим вольный и т. д.);

• все столбцы одной таблицы должны иметь уникальное имя;

• в таблице отсутствуют совпадающие строки;

О порядок следования строк и столбцов в таблице может быть произвольным.

( Замечание ^ Описание столбцов, которое составляет разработчик, называется макетом таблицы.

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

Таблица 17.1. Пример реляционной таблицы № дела Фамилия Имя Отчество Дата рожд. № подр.

18735 Мамаев Евгений Владимирович 13.08.78 18745 Лисицын Константин Владимирович 22.03.77 18543 Сипкин Павел Анатольевич 17.11.76 18545 Сергей Мамаев 21.09.80 Владимирович 18732 Шкарина Лилия Николаевна 07.10. Глава 17. Введение в проектирование баз данных 791_ Как видно, каждый из атрибутов расположен в отдельном столбце, а каждая стро ка содержит набор атрибутов, описывающих конкретный экземпляр объекта. Од ним из принципов реляционной теории является требование к минимальности элементов таблицы. Это означает, что каждое поле таблицы должно являться от дельным атомарным значением для конкретной предметной области. Это атомар ное значение не должно разделяться на более простые составляющие.

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

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

Кроме того, при практической работе в SQL Server 2000 часто фигурируют свои понятия. Все это не способствует лучшему пониманию баз данных. В табл. 17. приведено соответствие описания объектов в терминах разных областей.

Таблица 17.2. Терминология баз данных Теория БД Реляционные БД SQL Server Сущность (Entity) Отношение (Relation) Таблица (Table) Кортеж (Tuple) Запись (Record) Строка (Row) Атрибут (Attribute) Поле (Field) Столбец, колонка (Column) Замечание Хотя в каждой из представленных областей имеются свои термины, все же часто при описании объектов одной области используются термины другой области. Например, при описании реляционной модели часто применяются термины "атрибут" и "кортеж".

В SQL Server 2000 используются термины, несколько отличающиеся от стандартных терминов теории реляционных баз данных. Однако во многих СУБД, таких как dBase, FoxPro, Access и др., существуют термины таблица, запись и поле.

Помимо понятия атрибут, при описании данных используется понятие домена (domain). Домен — это множество атомарных значений одного типа. В общем виде домен определяется заданием набора значений некоторого типа. Все зна чения атрибутов, входящих в домен, должны входить в заданный набор. По другому можно сказать, что все значения атрибута образуют домен. В табл. 17. можно выделить домены имен, фамилий, дат рождения и т. д. Домен фамилий включает 4 значения: Мамаев, Лисицын, Сипкин и Шкарина. Домен дат рожде ния включает 5 значений.

792 Часть IV. Разработка и сопровождение баз данных Замечание Помимо того, что домен содержит множество атомарных значений одного типа, эти значения должны быть объединены на логическом уровне. Например, атрибуты имени и фамилии имеют одинаковый тип (символьный) и предназначены для описания чело века. Однако вряд ли имеет смысл объединять имена и фамилии в один набор.

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

~) (ч Замечание Часто совместно с термином атрибут (а иногда и вместо него) применяется сочета ние "домен атрибута". Домен атрибута — это множество значений данного атрибута.

Примером домена атрибута "Город" при описании адреса является множество всех возможных городов. В самой же таблице не всегда упоминаются все значения атри бута домена.

( Замечание ^ В большинстве современных систем управления реляционными базами данных, в т. ч. и в Microsoft SQL Server 2000, понятие домена не реализовано.

Доступ к конкретному элементу отношения может быть получен с указанием адреса этого элемента в формате A [ I, J ], где А — элемент данных, i — строка отношения, j — номер атрибута отношения.

Количество атрибутов в отношении определяет порядок (или степень) этого от ношения. Отношение степени один называют унарным, степени два — бинар ным, степени три — тернарным, а степени п — п-арным. Порядок отношения, приведенного в табл. 17.1, равен 6.

Множество всех значений A[i, j] при постоянном i и всех возможных j образует кортеж, или попросту строку таблицы, Множество всех кортежей отношения об разует тело отношения. Количество кортежей отношения задает его мощность (или кардинальное число). Количество кортежей в теле отношения может со време нем меняться, а следовательно, будет изменяться и мощность отношения.

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

Как уже говорилось, реляционные таблицы связываются друг с другом. Чтобы иметь возможность связать таблицы, необходимо иметь какой-то идентифика Глава 17. Введение в проектирование баз данных 793_ тор, который позволял бы уникально идентифицировать любую строку таблицы.

Таким идентификатором является ключ (key). Ключом называется множество атрибутов, задание значений которых позволяет однозначно определить значе ния остальных атрибутов таблицы. В качестве ключа для отношения, приведен ного в табл. 17.1, может выступать атрибут "№ дела" или набор атрибутов "Фамилия", "Имя" и "Отчество". В первом случае в качестве ключа выступает единственный атрибут — "№ дела". Во втором случае ключ является сложным и состоит из трех атрибутов.

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

Множество атрибутов отношения является возможным ключом отношения тогда и только тогда, когда выполняется два независимых от времени условия:

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

• Минимальность. Ни один из атрибутов не может быть исключен из ключа без нарушения уникальности возможного ключа. Это означает, что в ключ раз решается вносить только минимальный набор атрибутов, который позволяет идентифицировать каждую строку отношения. То есть нет необходимости помещать в ключ и номер личного дела, и номер паспорта. По любому из этих атрибутов можно однозначно идентифицировать каждую строку табли цы. При создании возможного ключа на основе атрибутов "Фамилия", "Имя" и "Отчество" исключение любого из атрибутов резко снижает уникальность ключа. Кроме того, не стоит вносить в возможный ключ повторяющийся ат рибут, не увеличивающий уникальности ключа. То есть нельзя включать до полнительно к номеру личного дела еще и фамилию служащего. Номер лич ного дела и так обеспечивает уникальность, а фамилия лишь увеличивает размер ключа и снижает производительность.

( Замечание ^ При создании ключа в SQL Server 2000 требование уникальности должно соблю даться всегда и обеспечивается самой системой. Соблюдение требования мини мальности лежит на пользователе. SQL Server 2000 не выполняет никаких проверок на то, что атрибуты, входящие в ключ, являются минимальным набором. То есть Часть IV. Разработка и сопровождение баз данных пользователь может создавать ключи на основе любого набора атрибутов, нарушая требование минимальности.

С Замечание J Любое отношение имеет по крайней мере один возможный ключ, состоящий из всех его атрибутов. Это следует из определения отношения, в котором говорится, что в любой момент времени в нем не может быть двух одинаковых кортежей.

Один из возможных ключей отношения может быть выбран в качестве первич ного ключа. Остальные возможные ключи, если они есть, принимаются за аль тернативные. Если в отношении, приведенном в табл. 17.1, выбрать в качестве первичного ключа номер личного дела, то комбинация атрибутов "Фамилия", "Имя" и "Отчество" будет являться возможным ключом.

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

Теоретические аспекты, разработанные доктором Коддом, легли в основу по строения многих современных систем управления базами данных, разработки сопутствующих программных и языковых средств, обладающих высокой произ водительностью и удобностью в использовании. К настоящему времени реляци онная модель баз данных является практически монополистом на рынке баз данных, вытеснив все другие модели. Это произошло благодаря удобству, на глядности и эффективности реляционных баз данных. Поэтому нет ничего уди вительного, что Microsoft SQL Server 2000 разрабатывался именно как система управления реляционными базами данных. Конечно, немалая часть соблюдения требований реляционной теории баз данных лежит на разработчике. Например, как уже говорилось ранее, соблюдение требования минимальности ключа лежит на разработчике.

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

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

При проектировании баз данных могут применяться различные подходы. Ос новная цель проектирования баз данных — это сокращение избыточности хра Глава 17. Введение в проектирование баз данных нимых данных, а следовательно, экономия используемых ресурсов (оперативной и дисковой памяти), уменьшение затрат на обновление избыточных копий дан ных, а также снижение вероятности нарушений целостности данных.

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

( Замечание } Не нужно путать отношения (relationship) между таблицами, определяющие прави ла связывания данных, с термином отношение (relation), обозначающим таблицу.

Если последний используется в теории реляционных баз данных при описании сущ ности, то первый— при практическом проектировании баз данных. Оба термина (relationship и relation) переводятся с английского одинаково — отношение. Отсюда и пошла путаница.

В комплекте с SQL Server 2000 поставляются две базы данных — Pubs и North Wind. Они создаются автоматически во время установки SQL Server 2000, и на их примере можно рассмотреть структуру обычной реляционной базы данных. В SQL Server 2000 имеется удобное средство просмотра структуры таблиц и отно шений между ними — диаграмма (Diagram). Вы можете включить в диаграмму любое количество таблиц и работать только с теми, которые вам необходимы.

Для работы с диаграммами необходимо в Enterprise Manager открыть нужную базу данных и в ее структуре выбрать папку Diagram. В правой части Enterprise Manager отобразиться список уже созданных диаграмм.

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

Требования к проектированию реляционных баз данных в самом общем виде можно свести к нескольким правилам. Рассмотрим их.

• Каждая таблица в базе данных имеет уникальное имя в пределах этой базы данных. Это позволяет уникально идентифицировать данные в таблице.

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

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

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


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

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

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

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

Таблица 17.3. Пример макета таблицы Глава 17. Введение в проектирование баз данных ( Замечание } Набор колонок в макете таблицы зависит от конкретной системы, в которой созда ется таблица. Кроме того, даже в пределах одной системы не всегда необходимо указывать все параметры. Например, в SQL Server 2000 не обязательно определять значение по умолчанию или возможность хранения в столбце значений N u l l. При составлении макета таблицы эти параметры можно опускать. Приведенный макет таблицы создан для SQL Server 2000.

Макет таблицы позволяет наглядно представить, какое количество столбцов имеется в таблице и какие данные должны храниться в каждом столбце. При создании таблиц в SQL Server 2000 с помощью Enterprise Manager их структура представляется также в виде макета. Это позволяет легко и наглядно изменять структуру таблицы. Более подробно создание таблиц будет рассмотрено в главе 3.

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

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

Нормализация — это процесс приведения структур данных в состояние, обеспе чивающее лучшие условия выборки, включения, изменения и удаления данных.

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

Прежде чем приступить к описанию нормализации, нужно сказать об универ сальном отношении. Таблица, в которую включены все интересующие атрибу ты, называется универсальным отношением. При использовании универсального отношения база данных будет состоять из единственной таблицы, в которой станет располагаться вся информация. Количество атрибутов в таком отноше Часть IV. Разработка и сопровождение баз данных нии может быть очень большим. В табл. 17.4 приведен пример универсального отношения, содержащего информацию о посещении студентами факультатив ных занятий.

Таблица 17.4. Универсальное отношение Преподаватель Кол-во Студент Группа Курс Макс, Факультатив часов студентов нит Лисицын К. В. 15 Шкарина 36 нит 36 Шкарина Салихов Т. Г 27- нит Шкарина 10 18 Гольцов В. Г.

Швец 44 8 Лисицын К. В. 15 НИТ в науке Еремина 38 8 27-2 Комп. Англ. Салихов Т. Г.

Еремина Удодов Д. В.

38 8 27-2 Комп. Англ.

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

П Избыточность. Информация во многих столбцах многократно повторяется.

Чем больше данных будет храниться в базе данных, тем больше информации дублируется и тем выше непроизводительные затраты.

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

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

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

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

При описании нормальных форм существуют несколько понятий:

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

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

• Многозначная функциональная зависимость. Поле А однозначно определяет поле в, если для каждого значения поля А существует хорошо определенное множество соответствующих значений поля в. Например, если рассматривать таблицу с описанием сотрудников и поле "Образование", то это поле имеет хорошо определенное множество допустимых значений (высшее, среднее, незаконченное среднее и т. д.).

• Транзитивная функциональная зависимость между полями А и с наблюдается в том случае, если поле в функционально зависит от поля А И поле с функ ционально зависит от поля в. В то же время не существует функциональной зависимости поля А ОТ ПОЛЯ В.

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

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

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

• Первая нормальная форма (INF, First Normal Form). Считается, что таблица находится в первой нормальной форме, если ни одно поле строки не содер жит более одного значения и любое ключевое поле не пусто. То есть ни один элемент таблицы не является, в свою очередь, таблицей и не содержит слож ных данных. Не трудно заметить, что это требование перекликается с опре делением отношения, в котором говорится, что любой столбец состоит из атомарных значений, которые не могут быть разложены на более мелкие со ставляющие. То есть любая таблица в реляционной базе данных автоматиче ски находится в первой нормальной форме.


О Вторая нормальная форма (2NF, Second Normal Form). Таблица находится во второй нормальной форме тогда и только тогда, когда она удовлетворяет тре бованиям первой нормальной формы и все ее поля, не входящие в первич ный ключ, связаны полной функциональной зависимостью с первичным ключом. То есть необходимо, чтобы только первичный ключ однозначно идентифицировал значения в любом столбце и в то же время значения в 800 Часть IV. Разработка и сопровождение баз данных столбцах не зависели ни от какой части составного ключа. Если первичный ключ состоит из одного столбца, то это требование удовлетворяется автома тически. Если же первичный ключ состоит из двух и более столбцов, то таб лица необязательно будет находиться во второй нормальной форме. В этом случае таблица должна быть разбита на две или более таблиц таким образом, чтобы первичный ключ однозначно идентифицировал значение в любом столбце. Бывают ситуации, когда в таблице имеется поле, не зависящее от первичного ключа. В этом случае необходимо добавить в первичный ключ дополнительный столбец. Если таких столбцов нет, то в таблицу вставляется новый столбец.

(~ Замечание ^ Обычно в реляционных таблицах имеется отдельный столбец, который служит пер вичныу ключом. В этом столбце хранится идентификационный номер строки в таб лице. С его помощью можно связывать данные в разных таблицах. В SQL Server 2000 имеются средства, обеспечивающие автоматическое генерирование значений для столбцов, используемых в качестве первичного ключа. Для этого не обходимо для столбца с целочисленным типом данных установить ограничение це лостности IDENTITY.

• Третья нормальная форма (3NF, Third Normal Form). Таблица находится в третьей нормальной форме тогда и только тогда, когда она удовлетворяет требованиям второй нормальной формы и ни одно из ее неключевых полей не зависит функционально от любого неключевого поля. Любое неключевое поле должно зависеть только от значения первичного ключа и не зависеть от любого другого неключевого атрибута. То есть каждое неключевое поле не транзитивно зависит от первичного ключа. Для устранения транзитивной за висимости между неключевыми полями выполняется расщепление исходной таблицы. В результате часть полей удаляется из исходной таблицы и включа ется в состав других (возможно вновь созданных) таблиц.

О Нормальная форма Бойса-Кодда (BCNF, Brice-Codd Normal Form). Таблица находится в нормальной форме Бойса-Кодда тогда и только тогда, когда она находится в третьей нормальной форме и любая функциональная зависи мость между ее полями сводится к полной функциональной зависимости от возможного ключа.

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

П Четвертая нормальная форма (4NF, Fourth Normal Form). Четвертая нор мальная форма является частным случаем пятой нормальной формы, когда полная декомпозиция должна быть соединением двух проекций. Для пони мания определения необходимо объяснить, что такое полная декомпозиция.

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

Другими словами, проекция таблицы — это ее копия, не включающая один или более столбцов.

( Замечание ^ Весьма трудно найти таблицу, которая находилась бы в четвертой нормальной форме и не находилась бы в пятой нормальной форме.

• Пятая нормальная форма или нормальная форма проекции-соединения (5NF, Fifth Normal Form или PJ/NF). Таблица находится в пятой нормальной фор ме, если в каждой ее полной декомпозиции все проекции содержат возмож ный ключ. Если в таблице не имеется ни одной полной декомпозиции, то она также находится в пятой нормальной форме.

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

Связывание таблиц После нормализации таблиц может быть получен набор из множества таблиц.

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

Первичный и внешний ключи Связывание строк таблиц реляционной базы данных выполняется с помощью первичного (primary) и внешнего (foreign) ключей. Разработчик базы данных дол жен определить правила связывания данных в разных таблицах, выделив в них одну или более колонок в качестве первичного или внешнего ключа. Напом ним, что первичный ключ позволяет однозначно идентифицировать любую строку таблицы. При выборе столбцов, которые будут входить в состав первич ного ключа, необходимо следовать требованиям уникальности и минимальности, 802 Часть IV. Разработка и сопровождение баз данных описанным ранее в этой главе. В принципе, при создании первичного ключа в SQL Server 2000 пользователь может выбрать любой набор столбцов. Единствен ное ограничение — совокупность значений выбранных столбцов должна быть уникальна для каждой строки.

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

В качестве первичного ключа могут быть использованы как уже имеющиеся столбцы таблицы, так и новые столбцы, специально созданные для этих це лей. Хотя в качестве первичного ключа можно выбрать один или более атри бутов описываемого в таблице объекта, все же на практике часто создают спе циально выделенный новый столбец. Использование существующих атрибутов связано с определенными сложностями. Например, на первый взгляд кажется, что номер паспорта — хороший пример первичного ключа. Однако при свя зывании строк в разных таблицах необходимо будет каждый раз указывать этот номер. При этом длина ключа может быть сравнительно большой. Кроме того, человек может поменять паспорт, и тогда необходимо будет изменить данные во всех связанных таблицах. Использование специальных столбцов снимает эти проблемы.

( Замечание ^ Как уже говорилось, SQL Server 2000 может автоматически обеспечивать уникаль ные значения для первичного ключа в новых строках таблицы. Для этого в столбце, имеющем целочисленный тип данных, устанавливается ограничение целостности IDENTITY. Такой столбец может с успехом выступать в качестве первичного ключа.

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

В отличие от первичного ключа, внешний ключ не должен быть уникальным.

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

Глава 17. Введение в проектирование баз данных (~ Замечание } В SQL Server 2000 внешний ключ (FOREIGN KEY) является просто ограничением целостности, автоматически определяющим возможные значения в поле подчинен ной таблицы в зависимости от значений соответствующего первичного ключа глав ной таблицы. Внешний ключ может связываться как со столбцом, для которого уста новлено ограничение целостности UNIQUE ИЛИ PRIMARY KEY, так и с любым другим столбцом того же типа данных.

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

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

При попытке изменения (командой UPDATE) значения первичного ключа в глав ной таблице ядро SQL Server 2000 может вести себя следующим образом:

П Установление (Relation). Когда значение первичного ключа главной таблицы изменяется, то SQL Server 2000 автоматически устанавливает значения внеш них ключей во всех связанных строках в неопределенное значение (NULL).

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

О Ограничение (Restrict). В этом режиме SQL Server 2000 будет отвергать по пытки изменения значения первичного ключа, если в зависимой таблице имеется хоть одна строка, связанная с изменяемой строкой главной таблицы.

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

П Каскадирование (Cascading). Это самый удобный и гибкий режим, обеспечи вающий автоматическое соблюдение целостности данных. При изменении значения первичного ключа в главной таблице SQL Server 2000 будет автома тически изменять значения всех связанных внешних ключей во всех строках 804 Часть IV. Разработка и сопровождение баз данных зависимых таблиц. Эти изменения окажутся незаметны для пользователей.

Все имеющиеся связи будут автоматически сохранены.

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

Возможны следующие варианты поведения SQL Server 2000 при удалении строк из главной таблицы:

• Установление (Relation). При удалении первичного ключа SQL Server будет автоматически устанавливать для всех связанных внешних ключей не определенное значение (NULL). Впоследствии такие строки могут быть удале ны вручную или связаны с другим первичным ключом.

• Ограничение (Restrict). Перед тем, как станет возможным удаление строки в главной таблице, ни в одной зависимой таблице не должно быть строки, имеющей то же значение внешнего ключа, что и первичный ключ удаляемой строки. Пользователь обязан либо удалить такие строки из зависимой табли цы, либо установить для них значение внешнего ключа в неопределенное значение (NULL), либо связать его с любым другим первичным ключом глав ной таблицы.

• Каскадирование (Cascading). В этом режиме система станет автоматически удалять все связанные строки из зависимых таблиц. Этот метод требует от пользователя минимального количества усилий.

Замечание Следует осторожно использовать режим Cascading, т. к. случайное удаление строки главной таблицы может повлечь за собой удаление цепочки строк в зависимых таб лицах. Более безопасным методом удаления является использование режима Rela tion — по крайней мере, сами данные останутся. При необходимости можно будет удалить несвязанные строки вручную.

Типы связей между таблицами При связывании строк главной и зависимой таблицы возможны самые разные сочетания. Тип связи определяет количественные правила сопоставления строк главной и зависимой таблицы. Существуют следующие виды связей:

О Один-к-одному (One-to-one). При установке отношения "один-к-одному" (1:1) каждой строке главной таблицы соответствует единственная (или ни одной) строка зависимой таблицы. С другой стороны, каждая строка зависи мой таблицы должна быть связана только с одной строкой главной таблицы.

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

Глава 17. Введение в проектирование баз данных П Один-ко-многим (One-to-many). При использовании связи "один-ко-многим" (1:п) каждой строке главной таблицы соответствует ноль, одна или более строк зависимой таблицы. С другой стороны, каждая строка зависимой таб лицы должна быть связана только с одной строкой главной таблицы. Приме ром такой связи может являться связь человека с его детьми. Частным случа ем связи "один-ко-многим" является связь "один-к-одному".

О Много-ко-многим (Many-to-many). Этот тип связи предполагает, что любой строке главной таблицы может соответствовать ноль, одна или множество строк зависимой таблицы. При этом каждая строка зависимой таблицы мо жет быть связана с одной или более строк главной таблицы. Примером такой связи может являться использование файлов сотрудниками. Каждый файл может использоваться множеством сотрудников, в то же время каждый со трудник может работать со множеством файлов.

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

Описанные типы связей скорее относятся к области теории, чем непосредст венно к SQL Server 2000. Ядро SQL Server 2000 поддерживает только отношения "один-ко-многим". Реализация остальных двух типов отношения лежит на поль зователе. Создать связь "один-к-одному" достаточно просто. Для этого доста точно установить в зависимой таблице на столбец с внешним ключом ограниче ние целостности UNIQUE. После этого система не даст создать в зависимой таблице двух строк с одинаковым значением внешнего ключа. Встроенная связь "один-к-одному" в SQL Server 2000 не реализована.

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

( Замечание ^ Примером связи "много-ко-многим" является связь между таблицами a u t h o r s и t i t l e s базы данных Pubs, которая реализуется с помощью вспомогательной таб лицы t i t l e a u t h o r............

Глава Архитектура баз данных Структурой хранения данных в SQL Server 2000 является база данных (database).

Вся работа SQL Server 2000 сводится к управлению базами данных (БД). Даже системные данные сервера, отвечающие за его функционирование, также хранятся в базах данных. Базу данных SQL Server 2000 можно рассматривать с двух сторон:

физической и логической. При работе с любой базой данных SQL Server 2000 — пользовательской или системной — действуют одни и те же механизмы.

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

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

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

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

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



Pages:     | 1 |   ...   | 19 | 20 || 22 | 23 |   ...   | 33 |
 





 
© 2013 www.libed.ru - «Бесплатная библиотека научно-практических конференций»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.