14.Информационные системы, основанные на бд и субд. Физическая организация базы данных; хешированные, индексные файлы; защита баз данных; целостность и сохранность баз данных.

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

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

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

При запоминании новой записи:

• определение места размещения новой записи в пространстве памяти;

• выделение необходимого ресурса памяти;

• запоминание этой записи (сохранение в памяти);

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

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

При поиске записи:

• поиск места размещения записи в пространстве памяти по заданным значениям атрибутов;

• выборка записи для обработки в оперативную память (в буфер данных).

При изменении атрибутов записи:

• поиск записи и считывание её в ОП;

• изменение значений атрибута (атрибутов) записи;

• сохранение записи на диск.

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

При удалении записи:

• удаление записи с освобождением памяти (физическое удаление) или без освобождения (логическое удаление);

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

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

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

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

Хранимые записи одного типа состоят из фиксированной совокупности полей и могут иметь формат фиксированной или переменной длины.

• Хранимая запись состоит из двух частей:

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

• Информационная часть. Содержит значения элементов данных.

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

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

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

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

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

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

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

Более популярный альтернативный метод основан на перемешивании на основе остатка от деления.

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

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

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

Использование метода хеширования для извлечения записей основано на полностью известном значении хеш-поля.

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

- открытую адресацию;

- несвязанную область переполнения;

- связанную область переполнения;

- многократное хеширование.

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

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

В отличие от хеширования:

а) индексирование не требует физической упорядоченности записей в файле данных;

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

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

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

Файл данных может иметь один первичный индекс и несколько вторичных индексов.

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

Защита БД

Защита от несанкционированного доступа:

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

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

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

• Использование пароля. Простым способом защиты является установка пароля для открытия БД. Может быть установлен единый пароль для всех пользователей, или для каждого пользователя личный, в таком случае для каждого пользователя могут быть определены объекты, доступ к которым он получает.

• Запрещение репликации БД. Репликация позволяет пользователям создавать копию общей БД, которая может быть использована для нелегального распространения реплицированных данных.

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

Целостность и сохранность БД

Любое хранимое в БД значение любого семантически значимого атрибута в любой момент времени должно быть истинным значением характеристики соответствующего объекта ПО.

Текущее состояние БД является целостным, если возможна осмысленная интерпретация его в терминах ПО.

Существуют ограничения целостности (ОЦ) данных.

Внешние ОЦ – это обусловленные требованиями конкретной ПО правила, соблюдение которых обеспечивает интерпретируемость хранимых данных.

Все БД, основанные на РМД, кроме специфических правил (внешних ОЦ), подчиняются еще общим правилам целостности. Эти правила называются внутренними ОЦ РМД.

Выделяют три разновидности внутренних ОЦ:

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

• целостность сущности. Правило целостности сущности: ни один компонент первичного ключа отношения не может принимать неопределенное значение.

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