• Какими ресурсами управляет внутренний уровень архитектуры бд?

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

Механизмы среды хранения БД в СУБД служат для управления двумя группами ресурсов системы – это ресурсами хранимых данных и ресурсами пространства памяти среды хранения.

Механизмы среды хранения должны выполнять целый ряд операций:

- определение места размещения новых данных в пространстве памяти на МД;

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

- формирование и разрушение связей с другими данными;

- удаление хранимых данных с освобождением занимаемой ими памяти;

- поиск данных в пространстве памяти по заданным их атрибутам или по «адресу»;

- выборка хранимых данных для обработки.

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

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

Каждой хранимой записи в пространстве памяти ставится в соответствие ее адрес, определяющий место размещения записи. Существуют два вида адресации хранимых записей – прямая (непосредственная) и косвенная.

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

Часть пространства каждой страницы отводится для индекса страницы. Число статей в нем одинаково для всех страниц. Адресом записи в пространстве памяти на МД служит номер этой записи в области. С помощью простых операций можно по номеру записи определить номер нужной страницы и номер в индексе этой страницы. Найденный индекс будет содержать указатель на соответствующую запись – непосредственный адрес ее местоположения. Если запись после ее модификации не вмещается на прежнее место, то она помещается на специально отведенные в данной области памяти страницы переполнения, и соответствующий индекс по-прежнему указывает новое место ее размещения. Номер записи сохраняется, а меняется в индексе только адрес нового места размещения.

• Какими важнейшими характеристиками должны обладать СУБД для разработки информационной системы? Основная цель логического проекти­ро­­вания БД. Главная задача физического проектирования БД.

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

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

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

- тип модели данных, которую поддерживает данная СУБД, ее адекватность потребностям рассматриваемой предметной области;

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

- аппаратно-программная платформа;

- характеристики производительности системы;

- наличие в данной СУБД средств разработки приложений;

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

- степень оснащенности системы инструментарием для АБД;

- удобство и надежность СУБД в эксплуатации.

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

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