По мощностиВ настоящее время наибольшее распространение получили реляционные СУБД трех групп: I. Мощные крупные коммерческие СУБД, ориентированные на хранение огромных объемов информации (от гигабайт). Наиболее известными СУБД в этой группе являются: Oracle (Oracle Corp.), Ingres (Computer Associates International), Sybase SQL server (Sybase Inc.). II. Мобильные компактные свободно распространяемые СУБД, использование которых оправдано и для БД объемом всего лишь в десятки килобайт. К наиболее популярным СУБД этой группы относятся: PostgreSQL (организации PostgreSQL), mySQL (T.C.X. DataKonsult AB), Microsoft SQL Server (Microsoft). III. Настольные персональные СУБД, ориентированные на простые варианты построения БД, решение менее сложных задач, на персональные компьютеры и, на меньшие объемы и сравнительно простую структуру данных. К настольным СУБД относятся: Access, входящая в состав пакета Microsoft Office и рассчитанная на одного пользователя; Visual FoxPro. СУБД первых двух групп построены по принципу «клиент-сервер».
Обычно современная СУБД содержит следующие компоненты (рис. 6.2):
Рисунок 6.2 Схема СУБД · ядро (часто его называют Data Base Engine), которое отвечает за управление данными во внешней и оперативной памяти и журнализации; · процессор языка запросов (компилятор языка БД, обычно SQL), обеспечивающий оптимизацию запросов на извлечение и изменение данных и создание машинно-независимого внутреннего кода; · подсистему поддержки времени выполнения, которая интерпретирует программы манипуляции данными, создающие пользовательский интерфейс с СУБД; · набор утилит. В некоторых системах эти части выделяются явно, в других - нет, но логически такое разделение можно провести во всех СУБД. Ядро СУБД отвечает за управление данными во внешней памяти, управление буферами оперативной памяти, управление транзакциями и журнализацию. Соответственно, можно выделить такие компоненты ядра (по крайней мере, логически, хотя в некоторых системах эти компоненты выделяются явно), как менеджер данных, менеджер буферов, менеджер транзакций и менеджер журнала. Функции этих компонентов взаимосвязаны, и для обеспечения корректной работы СУБД все эти компоненты должны взаимодействовать по тщательно продуманным и проверенным протоколам. Ядро СУБД обладает собственным интерфейсом, не доступным пользователям напрямую и используемым в программах, производимых компилятором SQL (или в подсистеме поддержки выполнения таких программ) и утилитах БД. Ядро СУБД является основной резидентной частью СУБД. При использовании архитектуры «клиент-сервер» ядро является основной составляющей серверной части системы. Основной функцией компилятора языка БД является компиляция операторов языка БД в некоторую выполняемую программу. Серьезной проблемой реляционных СУБД является то, что языки этих систем (а это, как правило, SQL) являются непроцедурными, т.е. в операторе такого языка специфицируется некоторое действие над БД, но эта спецификация не является процедурой, а лишь описывает в некоторой форме условия совершения желаемого действия. Поэтому компилятор должен решить, каким образом выполнять оператор языка прежде, чем произвести программу. Применяются достаточно сложные методы оптимизации операторов. Результатом компиляции является выполняемая программа, представляемая в некоторых системах в машинных кодах, но более часто в выполняемом внутреннем машинно-независимом коде. В последнем случае реальное выполнение оператора производится с привлечением подсистемы поддержки времени выполнения, представляющей собой, по сути дела, интерпретатор этого внутреннего языка. Наконец, в отдельные утилиты БД обычно выделяют такие процедуры, которые слишком накладно выполнять с использованием языка БД, например, загрузка и выгрузка БД, сбор статистики, глобальная проверка целостности БД и т.д. Утилиты программируются с использованием интерфейса ядра СУБД, а иногда даже с проникновением внутрь ядра.
Получение = Менеджер ресурсов Хранение = Менеджер хранения Обработка = обработка Транзакций + обработка Запросов
Менеджер транзакций = менеджер протоколирования и восстановления + менеджер параллельных заданий (планировщик заданий) Обработку запросов осуществляет процессор запросов, представленный в СУБД двумя компонентами - компилятор запросов и исполняющая машина
Компилятор запросов транслирует запрос во внутренний формат системы – план запроса (анализатор (древовидная структуру данных) ® препроцессор (дерево алгебраических операторов) ® оптимизатор (эффективная последовательность фактических операций над фактическими данными)) Исполняющая машина (несет ответственность за выполнение каждой из операций, предусмотренных планом запроса) направляет запрос на получение данных менеджеру ресурсов, который осведомлен об особенностях размещение информации в файлах (часто хранимых на устройствах внешней памяти). Далее запрос пересылается менеджеру буферов, который ответственен за разбиение свободной оперативной памяти на блоки для переноса в них информации. Менеджер хранения данных определяет положение файлов на диске.
Обычной практикой при обработке данных является оформление операций над БД в виде транзакций. С целью удовлетворения требования долговечности (устойчивости) каждое изменение в БД фиксируется в специальных файлах (протоколах), которые изначально сохраняются в буфере. Менеджер протоколирования взаимодействует с менеджером буферов, чтобы убедиться, что содержимое буфера сохранено на диске. Менеджер восстановления в случае возникновения системных сбоев способен считать протокол изменений и привести БД в согласованное (устойчивое) состояние. Транзакции должны выполняться изолированно друг от друга, но в реальных системах одновременно могут быть задействованы несколько процессов транзакций. Менеджер параллельных заданий должен обеспечить такой режим работы системы, чтобы результат выполнения пересекающихся во времени транзакций был таким же, как если бы транзакции инициировались, выполнялись и завершались в строгой очередности. Это достигается установлением блокировки на соответствующие фрагменты содержимого БД. Признаки блокировок хранятся в таблице блокировок. Менеджер параллельных заданий запрещает управляющей машине обращаться к заблокированным порциям данных. Возможна ситуация, когда ни одна из транзакций не в состоянии продолжать работу в связи с тем, что необходимый ей ресурс блокирован (ситуация взаимоблокировок). Менеджер транзакций вмешивается в ситуацию и прерывает (откатывает назад) работу одной или нескольких транзакций, чтобы позволить остальным продолжать работу.
2 Нормализация таблиц в реляционной модели БД Проектирование схемы БД должно решать задачи минимизации дублирования данных и упрощения процедур их обработки и обновления. При неправильно спроектированной схеме БД могут возникнуть аномалии выполнения операций включения, удаления и модификации данных. Эти аномалии обусловлены отсутствием средств явного представления типов множественных связей между объектами ПО и неразвитостью средств описания ограничений целостности на уровне реляционной модели данных. Аномалии модификации данных В качестве примера возьмём отношение со следующими атрибутами (ключевые атрибуты выделены подчёркиванием): ПОСТАВКИ (Номер поставки, Название товара, Цена товара, Количество, Дата поставки, Название поставщика, Адрес поставщика) Различают три вида аномалий: аномалии обновления, удаления и добавления. Аномалия обновления может возникнуть в том случае, когда информация дублируется. Другие аномалии возникают тогда, когда две и более независимые сущности объединены в одно отношение. Например: 1. Аномалия обновления: в отношении ПОСТАВКИ она может возникнуть, если у какого-либо поставщика изменился адрес. Изменения должны быть внесены во все кортежи, соответствующие поставкам этого поставщика; в противном случае данные будут противоречивы. 2. Аномалия удаления: при удалении записей обо всех поставках одного поставщика все данные о поставщике будут утеряны. 3. Аномалия добавления: в нашем примере она возникнет, если с поставщиком заключен договор, но поставок от него еще не было. Информация о таком поставщике не может быть внесена в отношение ПОСТАВКИ, т.к. для него не определён ключ (номер поставки и название товара) и другие обязательные поля. Для решения проблемы аномалии модификации данных при проектировании РБД проводится нормализация отношений. Нормализация отношений В рамках реляционной модели данных Э.Ф. Коддом был разработан аппарат нормализации отношений и предложен механизм, позволяющий любое отношение преобразовать к третьей нормальной форме. Нормализация схемы отношения выполняется путём декомпозиции схемы.
Нормализация – процесс проверки и реорганизации сущностей и атрибутов с целью удовлетворения требований к реляционной модели данных. (требования см в вопросе.Реляционная модель организации данных. Ее достоинства и недостатки) В теории реляционных баз данных обычно выделяется следующая последовательность нормальных форм:
Основные свойства нормальных форм:
Результат нормализации – информация о каждом факте хранится в одном месте. Процесс нормализации - последовательное приведение структуры данных к нормальным формам. Нормальная форма – формализованные требования к организации данных.
|
