Физические модели данных
план-конспект урока

Лекция

ТЕМА: Физические модели данных

Основные вопросы, рассматриваемые на лекции:

1. Физические модели данных.

2. Методы хранения данных.

3. Файл-ориентированная организация данных.

4. Страничная организация данных.

5. Методы доступа к данным. Индексы.

6. Хэширование.

7. Работа с внешними данными с помощью технологии ODBC.

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

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

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

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

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

Рассмотрим примерную логическую схему «страничной» организации хранения данных (рис.).

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

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

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

Все страницы данных имеют одинаковую структуру, включающую:

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

· содержание – строки данных (последовательность кодов), каждая из которых имеет уникальный идентификатор в рамках всей базы данных, который состоит из номера страницы и номера строки на странице;

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

5. Записи файла (логического, то есть файла, с которым работает прикладная программа) идентифицируются с помощью уникальной последовательности символов или некоторого числа – первичного ключа. Таким ключом обычно является значение поля, расположенное в каждой записи в одной и той же позиции. Иногда, чтобы обеспечить уникальность ключа, в нем объединяют несколько полей. Такой ключ называют составным.

Основную проблему при организации доступа к данным можно сформулировать следующим образом: как по первичному ключу определить местоположение записи с данным ключом? Как надо организовать набор записей, чтобы поиск потребовал как можно меньше затрат?

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

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

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

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

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

· Для сохранения записи в СУБД сначала вычисляется хэш-адрес новой записи, а затем диспетчер файлов помещает эту запись по вычисленному адресу.

· Для извлечения нужной записи по заданному значению хэш-поля в СУБД сначала вычисляется хэш-адрес, а затем диспетчеру файлов посылается запрос для извлечения записи по вычисленному адресу.

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

7. Одним из основных достоинств современных СУБД считается возможность работы с самыми разнообразными данными других баз, электронных таблиц или текстовых файлов. Если «заглянуть внутрь» таких СУБД, то можно обнаружить, что они используют для чтения, вставки, обновления и удаления данных язык, называемый SQL (Structured Query Language – Структурированный язык запросов). Язык SQL появился в результате выполнения корпорацией IBM исследовательского проекта по реляционным базам данных в 1970-х годах. Американским национальным институтом стандартов (ANSI) и Международной организацией стандартов (ISO) он был утвержден в качестве официального стандарта для реляционных баз данных.

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

Для решения этой проблемы более 30 влиятельных компаний по разработке программного и аппаратного обеспечения, включая Microsoft Corporation, сформировали специальную группу – SQL Access Group. Перед этой группой была поставлена задача – разработать такой вариант базового языка SQL, который эти фирмы могли бы использовать, чтобы их продукты могли «разговаривать» друг с другом. В результате совместной деятельности был разработан Common Language Interface (Стандартный интерфейс языка, CLI) для всех основных вариантов языка SQL. Фирмы этой группы взяли на себя обязательства встроить в свои программные продукты такие средства, которые позволяли бы любому приложению с помощью этого CLI иметь доступ к их базам данных. В начале 1992 г. около десятка этих фирм уже продемонстрировали результаты своей деятельности в этом направлении.

Очень важный шаг к созданию переносимых приложений обработки данных сделала фирма Microsoft в 1992 году. Microsoft формализовала интерфейс CLI для рабочих станций и объявила, что все ее программные продукты – в особенности те, которые предназначены для работы в операционной среде Microsoft Windows, будут использовать этот интерфейс для доступа к базам данных SQL. Этот формализованный интерфейс получил название Open Database Connectivity (ODBC, Открытый доступ к данным). Архитектура ODBC приведена на рис.

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

· приложения становятся привязанными к платформе MS Windows;

· увеличивается время обработки запросов (как следствие введения дополнительного программного слоя);

· необходима предварительная инсталляция драйвера ODBC и настройка ODBC (указание драйвера, сетевого пути к серверу, базы

данных и т.д.) на каждом рабочем месте.