Главная » SQL, Базы данных » ДОСТУП К БАЗЕ ДАННЫХ КРАТКИЙ ОБЗОР

0

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

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

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

3.            Наконец, диспетчер диска определяет физическое местонахождение желаемой страницы на дис ке и выдает необходимый запрос на выполнение операции ввода-вывода на диске.

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

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

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

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

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

■       Необходимо подчеркнуть, что физическая последовательность часто оказывается, по меньшей мере, вполне приемлемой для использования в качестве пути доступа к какому-то конкретному файлу. Иногда такой путь доступа может даже оказаться оптимальным (особенно если файл невелик). Но гораздо чаще встречается ситуация, когда требуется какой-то лучший способ доступа. А как было указано в разделе Г.1, для обеспечения такого "лучшего способа доступа" применяется чрезвычайно разнообразный набор методов.

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

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

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

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

Источник: Дейт К. Дж., Введение в системы баз данных, 8-е издание.: Пер. с англ. — М.: Издательский дом «Вильямс», 2005. — 1328 с.: ил. — Парал. тит. англ.

По теме:

  • Комментарии