А.2.3.4. Реализация на уровне модели данных

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

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

Задача администраторов баз данных состоит в том, чтобы структурировать внутреннюю схему, создавая эффективные структуры базы данных с помощью

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

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

Автономность уровня реализации поддерживается также употреблением специфических для предприятия терминов, которые, в свою очередь, моделируются на логическом уровне спецификации проекта (см. рис. 75). Например, обозначения ОТНОШЕНИЕ и АТРИБУТ связываются с обозначениями ЗАПИСЬ и ПОЛЕ на уровне реализации. Термин ЗАПИСЬ представляет тип записи, характеризующийся определенной комбинацией атрибутов. СТРАНИЦА может содержать различные типы записей. Работа администратора базы данных заключается в том, чтобы оптимизировать базу данных путем размещения часто требующихся типов записей в непосредственной близости друг от друга.

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

Понятия «отношение» и «запись» могут не совпадать, если отношения разбиваются на несколько записей или если несколько записей объединяются в одну физическую запись.

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

Помимо обозначений ЗАПИСЬ и ПОЛЕ, которые уже имеют базовые аналоги в спецификации проекта, введем теперь категории СТРАНИЦА и ОБЛАСТЬ (см. рис. 75), составляющие дополнительные организационные элементы для оптимизации структур распределения памяти. Эти предварительные единицы являются важнейшими «кирпичиками» для организации доступа к данным во внешних устройствах хранения и для распределения физических блоков хранения.

Рис. 75.Реализация модели данных

 

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

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

Физические пути доступа описываются на уровне АССОЦИАЦИИ ЗАПИСЬ-ПОЛЕ. Они либо конкретизируют логические пути доступа, определенные на стадии спецификации проекта, либо создаются, что называется, с нуля на стадии реализации при наличии детальных сведений о параметрах производительности.

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