Главная Вопрос-ответ

Основные положения реляционной модели БД. Основные классы субд

Этой статьей мы начинаем новый цикл, посвященный базам данных, современным технологиям доступа к данным и их обработки. На протяжении данного цикла мы планируем рассмотреть наиболее популярные настольные и серверные системы управления базами данных (СУБД), механизмы доступа к данным (OLD DB, ADO, BDE и др.) и утилиты для работы с базами данных (средства администрирования, генераторы отчетов, средства графического представления данных). Кроме того, мы планируем уделить внимание методам публикации данных в Internet, а также таким популярным способам обработки и хранения данных, как OLAP (On-Line Analytical Processing), и созданию хранилищ данных (Data Warehousing).

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

Основные концепции реляционных баз данных

Начнем с основных понятий СУБД и краткого введения в теорию реляционных баз данных - наиболее популярного сейчас способа хранения данных.

Реляционная модель данных

Реляционная модель данных была предложена Е.Ф.Коддом (Dr. E.F.Codd), известным исследователем в области баз данных, в 1969 году, когда он был сотрудником фирмы IBM. Впервые основные концепции этой модели были опубликованы в 1970 г. «A Relational Model of Data for Large Shared Data Banks», CACM, 1970, 13 N 6).

Реляционная база данных представляет собой хранилище данных, содержащее набор двухмерных таблиц. Набор средств для управления подобным хранилищем называется реляционной системой управления базами данных (РСУБД) . РСУБД может содержать утилиты, приложения, сервисы, библиотеки, средства создания приложений и другие компоненты.

Любая таблица реляционной базы данных состоит из строк (называемых также записями ) и столбцов (называемых также полями ). В данном цикле мы будем использовать обе пары терминов.

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

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

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

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

Поскольку последовательность колонок в таблице несущественна, обращение к ним производится по имени, и эти имена для данной таблицы уникальны (но не обязаны быть уникальными для всей базы данных).

Итак, теперь мы знаем, что реляционные базы данных состоят из таблиц. Для иллюстрации некоторых теоретических положений и для создания примеров нам необходимо выбрать какую-нибудь базу данных. Чтобы не «изобретать колесо», мы воспользуемся базой данных NorthWind, входящей в комплект поставки Microsoft SQL Server и Microsoft Access.

Теперь давайте рассмотрим связи между таблицами.

Ключи и связи

Давайте взглянем на фрагмент таблицы Customers (клиенты) из базы данных NorthWind (мы удалили из нее поля, несущественные для иллюстрации связей между таблицами).

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

Если первичный ключ состоит из более чем одной колонки, он называется составным первичным ключом (composite primary key ).

Типичная база данных обычно состоит из нескольких связанных таблиц. Фрагмент таблицы Orders (заказы).

Поле CustomerID этой таблицы содержит идентификатор клиента, разместившего данный заказ. Если нам нужно узнать, как называется компания, разместившая заказ, мы должны поискать это же значение идентификатора клиента в поле CustomerID таблицы Customers и в найденной строке прочесть значение поля CompanyName. Иными словами, нам нужно связать две таблицы, Customers и Orders, по полю CustomerID. Колонка, указывающая на запись в другой таблице, связанную с данной записью, называется внешним ключом (foreign key ). Как видим, в случае таблицы Orders внешним ключом является колонка CustomerID (рис. 1).

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

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

Если каждый клиент в таблице Customers может разместить только один заказ, говорят, что эти две таблицы связаны соотношением один-к-одному (one-to-one relationship ). Если же каждый клиент в таблице Customers может разместить ноль, один или много заказов, говорят, что эти две таблицы связаны соотношением один-ко-многим (one-to-many relationship ) или соотношением master-detail . Подобные соотношения между таблицами используются наиболее часто. В этом случае таблица, содержащая внешний ключ, называется detail-таблицей , а таблица, содержащая первичный ключ, определяющий возможные значения внешнего ключа, называется master-таблицей .

Группа связанных таблиц называется схемой базы данных (database schema ). Информация о таблицах, их колонках (имена, тип данных, длина поля), первичных и внешних ключах, а также иных объектах базы данных, называется метаданными (metadata ).

Любые манипуляции с данными в базах данных, такие как выбор, вставка, удаление, обновление данных, изменение или выбор метаданных, называются запросом к базе данных (query ). Обычно запросы формулируются на каком-либо языке, который может быть как стандартным для разных СУБД, так и зависящим от конкретной СУБД.

Ссылочная целостность

Выше мы уже говорили о том, что первичный ключ любой таблицы должен содержать уникальные непустые значения для данной таблицы. Это утверждение является одним из правил ссылочной целостности (referential integrity ). Некоторые (но далеко не все) СУБД могут контролировать уникальность первичных ключей. Если СУБД контролирует уникальность первичных ключей, то при попытке присвоить первичному ключу значение, уже имеющееся в другой записи, СУБД сгенерирует диагностическое сообщение, обычно содержащее словосочетание primary key violation . Это сообщение в дальнейшем может быть передано в приложение, с помощью которого конечный пользователь манипулирует данными.

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

Большинство современных СУБД, например Microsoft Access 97, Microsoft Access 2000 и Microsoft SQL Server 7.0, способны контролировать соблюдение правил ссылочной целостности, если таковые описаны в базе данных. Для этой цели подобные СУБД используют различные объекты баз данных (мы обсудим их чуть позже). В этом случае все попытки нарушить правила ссылочной целостности будут подавляться с одновременной генерацией диагностических сообщений или исключений (database exceptions ).

Введение в нормализацию данных

Процесс проектирования данных представляет собой определение метаданных в соответствии с задачами информационной системы, в которой будет использоваться будущая база данных. Подробности о том, как производить анализ предметной области, создавать диаграммы «сущность-связь» (ERD - entity-relationship diagrams ) и модели данных, выходят за рамки данного цикла. Интересующиеся этими вопросами могут обратиться, например, к книге К.Дж.Дейта «Введение в системы баз данных» («Диалектика», Киев, 1998).

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

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

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

Первая нормальная форма

Проиллюстрируем процесс нормализации на примере, использующем данные из базы NorthWind. Предположим, что мы регистрируем все заказанные продукты в следующей таблице . Структура этой таблицы имеет вид (рис. 2).

Чтобы таблица соответствовала первой нормальной форме, все значения ее полей должны быть атомарными, и

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

Тем не менее эта таблица содержит избыточные данные, например, одни и те же сведения о клиенте повторяются в записи о каждом заказанном продукте. Результатом избыточности данных являются аномалии модификации данных- проблемы, возникающие при добавлении, изменении или удалении записей. Например, при редактировании данных в таблице OrderedProducts могут возникнуть следующие проблемы:

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

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

Вторая нормальная форма

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

Таблица OrderedProducts находится в первой, но не во второй нормальной форме, так как поля CustomerID, Address и OrderDate зависят только от поля OrderID, являющегося частью составного первичного ключа (OrderID, ProductID).

Чтобы перейти от первой нормальной формы ко второй, нужно выполнить следующие шаги:

Определить, на какие части можно разбить первичный ключ, так чтобы некоторые из неключевых полей зависели от одной из этих частей (эти части не обязаны состоять из одной колонки! ).
Создать новую таблицу для каждой такой части ключа и группы зависящих от нее полей и переместить их в эту таблицу. Часть бывшего первичного ключа станет при этом первичным ключом новой таблицы.
Удалить из исходной таблицы поля, перемещенные в другие таблицы, кроме тех их них, которые станут внешними ключами.

Например, для приведения таблицы OrderedProducts ко второй нормальной форме, нужно переместить поля CustomerID, Address и OrderDate в новую таблицу (назовем ее OrdersInfo), при этом поле OrderID станет первичным ключом новой таблицы (рис. 3).

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

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

Устранить эти аномалии можно путем перехода к третьей нормальной форме .

Третья нормальная форма

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

Таблица OrderDetails уже находится в третьей нормальной форме. Неключевое поле Quantity полностью зависит от составного первичного ключа (OrderID, ProductID). Однако таблица OrdersInfo в третьей нормальной форме не находится, так как содержит зависимость между неключевыми полями (она называется транзитивной зависимостью - transitivedependency ) - поле Address зависит от поля CustomerID.

Чтобы перейти от второй нормальной формы к третьей, нужно выполнить следующие шаги:

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

Для приведения таблицы OrdersInfo к третьей нормальной форме создадим новую таблицу Customers и переместим в нее поля CustomerID и Address. Поле Address из исходной таблицы удалим, а поле CustomerID оставим - теперь это внешний ключ (рис. 4).

Итак, после приведения исходной таблицы к третьей нормальной форме таблиц стало три - Customers, Orders и OrderDetails.

Преимущества нормализации

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

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

Изменение адреса клиента или даты регистрации заказа теперь требует изменения только одной записи.

Как проектируют базы данных

Обычно современные СУБД содержат средства, позволяющие создавать таблицы и ключи. Существуют и утилиты, поставляемые отдельно от СУБД (и даже обслуживающие несколько различных СУБД одновременно), позволяющие создавать таблицы, ключи и связи.

Еще один способ создать таблицы, ключи и связи в базе данных - это написание так называемого DDL-сценария (DDL - Data Definition Language; о нем мы поговорим чуть позже).

Наконец, есть еще один способ, который становится все более и более популярным, - это использование специальных средств, называемых CASE-средствами (CASE означает Computer-Aided System Engineering). Существует несколько типов CASE-средств, но для создания баз данных чаще всего используются инструменты для создания диаграмм «сущность-связь» (entity-relationship diagrams, E/R diagrams). С помощью этих инструментов создается так называемая логическая модель данных, описывающая факты и объекты, подлежащие регистрации в ней (в таких моделях прототипы таблиц называются сущностями (entities), а поля - их атрибутами (attributes). После установления связей между сущностями, определения атрибутов и проведения нормализации, создается так называемая физическая модель данных для конкретной СУБД, в которой определяются все таблицы, поля и другие объекты базы данных. После этого можно сгенерировать либо саму базу данных, либо DDL-сценарий для ее создания.

Список наиболее популярных в настоящее время CASE-средств .

Таблицы и поля

Таблицы поддерживаются всеми реляционными СУБД, и в их полях могут храниться данные разных типов. Наиболее часто встречающиеся типы данных .

Индексы

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

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

Предположим, в какой-то момент времени записи в таблице Customers хранились в таком порядке .

Допустим, нам нужно получить эти данные упорядоченными по полю CustomerID. Опустив технические детали, мы можем сказать, что индекс по этому полю - это последовательность номеров записей, в соответствии с которой их нужно выводить, то есть:

1,6,4,2,5,3

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

5,4,1,6,2,3

Хранение индексов требует существенно меньше места, чем хранение по-разному отсортированных версий самой таблицы.

Если нам нужно найти данные о клиентах, у которых CustomerID начинается с символов «BO», мы можем найти с помощью индекса местоположение этих записей (в данном случае 2 и 5 (очевидно, что в индексе номера этих записей идут подряд), а затем прочесть именно вторую и пятую записи, вместо того чтобы просматривать всю таблицу. Таким образом, использование индексов снижает время выборки данных.

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

Ограничения и правила

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

Помимо ограничений, связанных с установкой диапазона изменения данных, существуют также ссылочные ограничения (referential constraints, например связь master-detail между таблицами Customers и Orders может быть реализована как ограничение, содержащее требование, чтобы значение поля CustomerId (внешний ключ) в таблице Orders было равно одному из уже имеющихся значений поля CustomerId таблицы Customers.

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

Представления

Практически все реляционные СУБД поддерживают представления (views). Этот объект представляет собой виртуальную таблицу, предоставляющую данные из одной или нескольких реальных таблиц. Реально он не содержит никаких данных, а только описывает их источник.

Нередко такие объекты создаются для хранения в базах данных сложных запросов. Фактически view - это хранимый запрос.

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

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

Триггеры и хранимые процедуры

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

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

Хранимые процедуры обычно используются при выполнении часто встречающихся задач (например, сведение бухгалтерского баланса). Они могут иметь аргументы, возвращать значения, коды ошибок и иногда наборы строк и колонок (такой набор данных иногда называется термином dataset). Однако последний тип процедур поддерживается не всеми СУБД.

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

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

Объекты для генерации первичных ключей

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

В разных СУБД для генерации ключей используются разные объекты. Некоторые из таких объектов хранят целое число и правила, по которым генерируется следующее за ним значение, -обычно это выполняется с помощью триггеров. Такие объекты поддерживаются, например, в Oracle (в этом случае они называются последовательностями - sequences) и в IB Database (в этом случае они называются генераторами - generators).

Некоторые СУБД поддерживают специальные типы полей для первичных ключей. При добавлении записей такие поля заполняются автоматически последовательными значениями (обычно целыми). В случае Microsoft Access и Microsoft SQL Server такие поля называются Identity fields, а в случае Corel Paradox - автоинкрементными полями (Autoincrement fields).

Пользователи и роли

Предотвращение несанкционированного доступа к данным является серьезной проблемой, которая решается разными способами. Самый простой - это парольная защита либо всей таблицы, либо некоторых ее полей (такой механизм поддерживается, например, в Corel Paradox).

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

Некоторые СУБД, в основном серверные, поддерживают не только список пользователей, но и роли (roles). Роль - это набор привилегий. Если конкретный пользователь получает одну или несколько ролей, а вместе с ними - и все привилегии, определенные для данной роли.

Запросы к базам данных

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

Один из способов манипуляции данными называется «queries by example» (QBE) - запрос по образцу. QBE представляет собой средство для визуального связывания таблиц и выбора полей, которые следует отобразить в результате запроса.

В большинстве СУБД (за исключением некоторых настольных) визуальное построение запроса с помощью QBE приводит к генерации текста запроса с помощью специального языка запросов SQL (Structured Query Language). Можно также написать запрос непосредственно на языке SQL.

Курсоры

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

Большинство современных СУБД поддерживают так называемые двунаправленные курсоры (bi-directional cursors), позволяющие перемещаться по результирующему набору данных как вперед, так и назад. Однако некоторые СУБД поддерживают только однонаправленные курсоры, позволяющие перемещаться по набору данных только вперед.

Язык SQL

Structured Query Language (SQL) - это непроцедурный язык, используемый для формулировки запросов к базам данных в большинстве современных СУБД и в настоящий момент являющийся индустриальным стандартом.

Непроцедурность языка означает, что на нем можно указать, что нужно сделать с базой данных, но нельзя описать алгоритм этого процесса. Все алгоритмы обработки SQL-запросов генерируются самой СУБД и не зависят от пользователя. Язык SQL состоит из набора операторов, которые можно разделить на несколько категорий:

Data Definition Language (DDL) - язык определения данных, позволяющий создавать, удалять и изменять объекты в базах данных
Data Manipulation Language (DML) - язык управления данными, позволяющий модифицировать, добавлять и удалять данные в имеющихся объектах базы данных
Data Control Languages (DCL) - язык, используемый для управления пользовательскими привилегиями
Transaction Control Language (TCL) - язык для управления изменениями, сделанными группами операторов
Cursor Control Language (CCL) - операторы для определения курсора, подготовки операторов SQL к выполнению и некоторых других операций.

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

Функции, определяемые пользователем

Некоторые СУБД позволяют использовать функции, определяемые пользователем (UDF-User-Defined Functions). Эти функции, как правило, хранятся во внешних библиотеках и должны быть зарегистрированы в базе данных, после чего их можно использовать в запросах, триггерах и хранимых процедурах.

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

Транзакции

Транзакция (Transaction) - это группа операций над данными, которые либо выполняются все вместе, либо все вместе отменяются.

Завершение (Commit) транзакции означает, что все операции, входящие в состав транзакции, успешно завершены, и результат их работы сохранен в базе данных.

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

Транзакция может состоять из нескольких вложенных транзакций.

Некоторые СУБД поддерживают двухфазное завершение транзакций (two-phase commit) - процесс, позволяющий осуществлять транзакции над несколькими базами данных, относящихся к одной и той же СУБД.

Для поддержки распределенных транзакций (то есть транзакций над базами данных, управляемых разными СУБД), существуют специальные средства, называемые мониторами транзакций (transaction monitors).

Заключение

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

В следующей статье мы познакомим наших читателей с наиболее популярными настольными СУБД: dBase, Paradox, Access, Visual FoxPro, Works и обсудим их основные возможности.

КомпьютерПресс 3"2000

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

База данных - это организованная структура, предназначенная для хранения информации.

СУБД - инструментальное программное обеспечение, предназначенное для организации ведения БД.

По виду модели БД разделяются:

Иерархические БД

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

Сетевые СУБД

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

Реляционные СУБД

Реляционные СУБД являются в настоящий момент самыми распространенными. Реляционная модель ориентирована на организацию данных в виде двумерных таблиц. Реляционная таблица представляет собой двумерный массив и обладает следующими свойствами:

Каждый элемент таблицы - один элемент данных;

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

Каждый столбец имеет уникальное имя.

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

Объектно-ориентированные

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

Многомерные

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

9. Языки программирования. Машинный код. Трансляторы. Двоичное кодирование информации.

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

Машинный код процессора

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

Уровни языков программирования

Если язык программирования ориентирован на конкретный тип процессора и учитывает его особенности, то он называется языком программирования низкого уровня . Имеется в виду, что операторы языка близки к машинному коду и ориентированы на конкретные команды процессора.

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

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

Популярными на сегодня являются языки программирования:

Pascal (Паскаль), создан в конце 70-х годов основоположником множества идей современного программирования Никлаусом Виртом и имеет возможности, позволяющие успешно применять его при создании крупных проектов.

Basic (Бейсик), д ля этого языка имеются и компиляторы, и интерпретаторы, а по популярности он занимает первое место в мире. Он создавался в 60-х годах в качестве учебного языка и очень прост в изучении. Его современная модификация Visual Basic, совместимая с Microsoft office, позволяет расширять возможности пакетов Excel и Access.

С (Си), Данный язык был создан в лаборатории Bell и первоначально не рассматривался как массовый. Он планировался для замены ассемблера, чтобы иметь возможность создавать столь же эффективные и компактные программы, и в то же время не зависеть от конкретного типа процессора. На этом языке в 70-е годы написано множество прикладных и системных программ и ряд известных операционных систем (Unix).

Некоторые языки, например, Java и C#, находятся между компилируемыми и интерпретируемыми. А именно, программа компилируется не в машинный язык, а в машинно-независимый код низкого уровня, байт-код. Далее байт-код выполняется виртуальной машиной. Для выполнения байт-кода обычно используется интерпретация, хотя отдельные его части для ускорения работы программы могут быть транслированы в машинный код непосредственно во время выполнения программы по технологии компиляции «на лету» (Just-in-time compilation, JIT). Для Java байт-код исполняется виртуальной машиной Java (Java Virtual Machine, JVM), для C# - Common Language Runtime.

Структура реляционной БД.

Типы БД.

Основные возможности СУБД.

Понятие базы данных, СУБД.

План

ТЕРМИНЫ : база данных, система управления базами данных (СУБД),

реляционная БД, запись БД, поле БД, ключевое поле БД, таблица БД, запрос БД, форма БД, отчёт БД, макрос БД, модуль БД.

Одной из основных сфер использования компьютера в современном информационном обществе является хранение и обработка больших объёмов информации.

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

Далее на примере одной из самых распространенных систем управления базами данных - Microsoft Access входит в состав популярного пакета Microsoft Office - мы познакомимся с основными типами данных, способами создания баз данных и с приемами работы с базами данных.

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

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

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

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

Основные возможности СУБД:

ü Обновление, пополнение и расширение БД.

ü Высокая надёжность хранения информации.

ü Вывод полной и достоверной информации на запросы.

ü Средства защиты информации в БД.

БД бывают фактографическими и документальными .

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

Для хранения БД может использоваться как один компьютер, так и множество взаимосвязанных компьютеров.

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

Известны три основных типа организации данных в БД и связей между ними:

· иерархический (в виде дерева),

· сетевой,

· реляционной .

В иерархической БД существует упорядоченность элементов в записи, один элемент считается главным, остальные – подчинёнными. Поиск какого-либо элемента данных в такой системе может оказаться трудоёмким из-за необходимости последовательно проходить несколько иерархических уровней.

Пример : иерархическую БД образует каталог файлов, хранимый на диске.

Такой же БД является родовое генеалогическое древо.

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

Реляционными БД (от англ. relation – «отношение») называются БД, содержащие информацию в виде прямоугольных таблиц. Согласно этому подходу, такая таблица называется отношением. Каждая строка таблицы содержит информацию об одном отдельном объекте описываемой в БД предметной области, а каждый столбец – определённые характеристики (свойства, атрибуты) этих объектов. Реляционная база данных, по сути, представляет собой двумерную таблицу . В реляционной БД используются четыре основных типов полей:

· Числовой,

· Символьный (слова, тексты, коды и т.д.),

· Дата (календарные даты в форме «день/месяц/год»),

· Логический (принимает два значения: «да» - «нет» или «истина» - «ложь»).

Окно базы данных содержит следующие элементы:

ü Кнопки : «СОЗДАТЬ» , «ОТКРЫТЬ» , «КОНСТРУКТОР» и т. д. Кнопки открывают объект в определенном окне или режиме.

ü Кнопки объектов . (Корешки выбора объектов, ярлычки.) «Таблица» , «Форма» и т. д. Кнопки объектов выводят список объектов, которые могут быть открыты или закрыты.

ü Список объектов. Выводит список объектов, выбираемых пользователем. В нашем варианте список пока пуст.

Основные объекты баз данных:

· Таблица – это объект, предназначенный для хранения данных в виде записей (строк) и полей (столбцов). Обычно каждая таблица используется для хранения сведений по одному конкретному вопросу.

· Форма – это объект Microsoft Access, предназначенный, в основном, для ввода данных. В форме можно разместить элементы управления, применяемые для ввода, изображения и изменения данных в полях таблицы.

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

· Отчет – объект базы данных Microsoft Access, предназначенный для печати данных.

· Макросы – автоматизируют стандартные действия.

· Модули – автоматизируют сложные операции, которые нельзя описать макросами.

Постреляционные СУБД. Объектные СУБД. Недостатки реляционных СУБД. Основные концепции объектно-ориентированных СУБД.

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

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

В качестве других недостатков реляционных СУБД отмечаются следующие:

· негибкость структуры для развивающихся БД,

· затруднения в построении концептуальной модели для объектов с многочисленными связями “многие – ко – многим”,

· неестественность табличного представления для разреженных массивов данных.

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

1. Абстракция: Каждая реальная "вещь", которая хранится в БД, является членом какого-либо класса. Класс определяется как совокупность свойств, методов, общедоступных и частных структур данных, а также программы, применимых к объектам (экземплярам) данного класса. Классы представляют собой ни что иное, как абстрактные типы данных. Методы - это процедуры, которые вызываются для того, чтобы произвести какие-либо действия с объектом (например, напечатать себя или скопировать себя). Свойства - это значения данных, связанные с каждым объектом класса, характеризующие его тем или иным образом (например, цвет, возраст).

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

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

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

5. Сообщения : Взаимодействие с объектами осуществляется путем посылки сообщений с возможностью получения ответов.

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

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

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

СУБД - это программное обеспечение, с помощью которого пользователи могут определять, создавать и поддерживать БД, осуществлять к ней контролирующий доступ.

Объектно-реляционными СУБД являются, к примеру, Oracle Database и PostgreSQL; разница между объектно-реляционными и объектными СУБД: первые являют собой надстройку над реляционной схемой, вторые же изначально объектно-ориентированы.

Доступ к объекту в реляционных СУБД.1) СУБД определяет страницу во внешнем устройстве хранения, содержащую требуемую запись. Используя механизмы индекса или выполняя полный просмотр таблиц. Затем СУБД считывает эту страницу из внешнего устройства хранения и копирует ее в КЕШ 2.СУБД последовательно переносит данные из КЕШа в пространство памяти приложения. При этом может понадобится выполнить преобразования типов данных SQL в типы данных приложения. Приложение может обновлять значения полей в своем пространстве памяти. 3. модифицированные приложением поля данных средствами языка SQL переносится назад в КЕШ СУБД, в процессе чего может опять потребоваться выполнить преобразование типов данных. 4. СУБД сохраняет обновленную страницу на внешнем устройстве хранения переписывая ее из КЕШа.

Доступ к объекту в ООСУБД. 1. ООСУБД наход ит на внешнем уст-ве хранения страницу, содержащую требуемый объект, используя его индекс если это необходимо. Затем ООСУБД считывает из внешнего устр-ва хранения требуемую страницу и копирует ее в КЕШ страниц приложения, находящийся в пределах памяти, отведенной приложению. 2. ООСУБД м ожет выполнить несколько преобразований: 1. подстановку ссылок (указателей) одного объекта на другой. 2. введение в состав данных объекта информации, которая необходима для обеспечения соответствия требованиям, предъявляемым со стороны языка программирования. 3. Изменение формата представления данных созданных на разных аппаратных платформах или языках программирования. 3. Приложение осуществляет доступ к объекту и обновляет его по мере необходимости. 4. Когда приложению потребуется сделать внесенные изменения пермонентными или выгрузить на время стр. из КЕШа на диск, то перед копированием стр. на внешнее уст-во хранения ООСУБД должна выполнить обратные преобразования аналогичные описанным выше.

Билет №27

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

Деловая активность предприятия обычно характеризуется интенсивностью использования инвестированного (внутреннего) капитала. В производстве капитал находится в постоянном движении, переходя из одной стадии кругооборота в другую: т. е. реализуется технология Д®Т®…®П®…Т®Д". Деньги, товар

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

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

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

Наличие двух уровней системы:

уровня непосредственного управления данными во внешней памяти (а также обычно управления буферами оперативной памяти, управления транзакциями и журнализацией изменений БД),

языкового уровня (например уровня, реализующего язык SQL).

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

Поддержка отношений-каталогов (справочников). Информация, связанная с именованием объектов базы данных и их конкретными свойствами (например, структура ключа индекса), поддерживается подсистемой языкового уровня. С точки зрения структур внешней памяти, отношение-каталог ничем не отличается от обычного отношения базы данных.

Регулярность структур данных . Поскольку основным объектом реляционной модели данных является плоская (в 1НФ) таблица, главный набор объектов внешней памяти может иметь очень простую регулярную структуру. При этом необходимо обеспечить возможность эффективного выполнения операторов языкового уровня как над одним отношением (простые операции селекции и проекции), так и над несколькими отношениями (наиболее распространена и трудоемка операция соединения нескольких отношений). Для этого во внешней памяти должны поддерживаться дополнительные индексы.

Для выполнения требования надежного хранения баз данных необходимо поддерживать избыточность хранения данных, что обычно реализуется в виде журнала изменений базы данных.

Соответственно, возникают следующие разновидности объектов во внешней памяти базы данных:

строки отношений - основная часть базы данных, большей частью непосредственно видимая пользователям;

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

журнальная информация , поддерживаемая для удовлетворения потребности в надежном хранении данных;

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

· внутренние каталоги (справочники), описывающие физические свойства объектов базы данных, например число атрибутов отношения, их размер и, возможно, типы данных;

· описание индексов, определенных для данного отношения;

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

Базовые структуры памяти

Структура и типы страниц

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

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

Выделяют четыре типа страниц:

· страницы данных,

· страницы индексов,

· страницы blob-объектов,

· битовые страницы.

Страница данных . Основная единица осуществления операций обмена. Структура страницы данных представлена на рис. 32.

Рис. 32. Структура страницы данных

Заголовок страницы включает внутрисистемную информацию, используемую СУБД в механизме управления страницами.

Данные на странице представляются в виде строк . Каждая строка соответствует некоторому кортежу отображаемого отношения.

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

Страница индексов. Страницы индексов предназначены для хранения индексных структур, используемых СУБД в реализации методов доступа, и организованы в виде В-деревьев.

Страница blob . Страницы blob (B inary L arge Ob ject) предназначены для хранения слабоструктурированной информации, содержащей тексты большого объема, графическую информацию, двоичные коды. Эти данные рассматриваются как потоки байтов произвольного размера, а в страницах данных формируются ссылки на эти страницы. Данные таких типов в ранних СУБД относились к типу MEMO.

Битовая страница . Битовые страницы содержат описатели других типов страниц. Описатель страницы включает две составляющих – тип страницы и ее состояние (свободна /занята ).

Табличные пространства

Общим для СУБД является понятие пространства (для некоторых СУБД табличное пространство ). В табличных пространствах размещены различные логические структуры данных, такие как таблицы и индексы, временные таблицы и словарь данных. Группировка хранимых данных по пространствам производится по ряду признаков: частота изменения данных, характер работы с данными (преимущественно чтение или запись и т.п.), скорость роста объема данных, важность и т.п. Таким образом, например, только читаемые таблицы помещаются в одно пространство, для которого установлены одни параметры хранения, таблицы транзакций размещаются в пространстве с другими параметрами и т.д. (рис. 33).

Рис.33. Физическое размещение данных по устройствам

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

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

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

Пусть, например, для таблицы Person создаются два раздела part1 и part2 , каждый из которых размещен в своем табличном пространстве (tblspace1 и tblspace2 ). Записи со значением поля Num от 1 до 499 будут располагаться в первом разделе, а записи с номерами от 500 до 1000 - во втором (рис. 34.).

Тогда при запросе:

SELECT FIO FROM person WHERE Num BETWEEN 10 AND 40

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

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

Рис. 34. Пример кластеризации записей

Статьи по теме