А.2.3.3.4. Логические пути доступа
Выполнение вложенных запросов SQL может повлечь за собой серьезные проблемы с производительностью. Чтобы повысить эффективность базы данных следует создать структуры утилит для поддержки доступа к отдельным кортежам или их группам. В частности, следует устранить необходимость последовательного поиска в таблицах.
Типичными средствами поддержки являются функции доступа к кортежам по их ключам и доступа к группе кортежей в определенной последовательности (сортировка). Это называется логическим путем доступа. Логические пути доступа для первичных ключей можно классифицировать в соответствии с последовательными организационными формами, древовидными индексами или рассредоточенными организационными формами. Пути доступа для вторичных ключей — особенно важные для реляционных баз данных — создаются при помощи инвертированных списков (индексных таблиц).
Спецификация проекта определяет, какие типы поддержки следует обеспечить для определенных атрибутов. Для описания различных типов поддержки создается класс ТИП ЛОГИЧЕСКОГО ПУТИ ДОСТУПА. Логический путь доступа характеризуется связью между атрибутом отношения и типом пути доступа. Это позволяет описать множество путей доступа для атрибута в определенном отношении, т.е. задать класс АССОЦИАЦИЯ ОТНОШЕНИЕ-АТРИБУТ (см. рис. 73).
Рис . 73. Логические пути доступа
В спецификации проекта пути доступа первоначально описываются исходя из общих предположений относительно числа кортежей в таблице и числа предполагаемых приложений таблицы. Однако после того как база данных создана и стали известны характеристики производительности и число операций базы данных, возможна дальнейшая дифференциация утилит доступа.
|
|
|
А.2.3.3.5. Схема базы данных
На заключительном этапе спецификации проекта структуры данных переводятся на язык описания данных (ЯОД) конкретной системы баз данных (ORACLE, INFORMIX, CA-INGRES), которая будет использоваться. Благодаря математическому описанию реляционных моделей и применению стандартных SQL-операторов для описания условий целостности процесс перевода схемы реляционной базы данных на ЯОД системы баз данных — всего лишь вопрос техники.
Если предприятие одновременно внедряет несколько разных систем баз данных, нейтральное описание реляционной схемы можно перенести на несколько конкретных схем СУБД (система управления базами данных). Для поставщиков программного обеспечения, предлагающих продукты для различных баз данных, эта ситуация довольно типична. Схемы содержат конкретные описания баз данных, включая условия целостности и пути доступа. Этот сценарий представлен на рис. 74, где описывается тип сложного объекта СХЕМА.
|
|
|
Рис . 74. Описание СХЕМЫ
А.2.3.4. Реализация на уровне модели данных
Мы начнем со спецификации проекта в рамках модели данных, т.е. с традиционной схемы базы данных с ее отношениями, атрибутами и условиями целостности, соответственно. Будут описаны логические пути доступа к определенным ассоциациям атрибутов с помощью предварительных концепций относительно частоты приложений и запросов.
На стадии реализации концептуальные схемы воплощаются во внутренние схемы, описывающие тот же фрагмент (<окно>) действительности, что и концептуальная схема. Семантика на этом этапе не добавляется. Напротив, внутреннюю схему можно вывести на базе концептуальной схемы, не зная семантического контекста.
Задача администраторов баз данных состоит в том, чтобы структурировать внутреннюю схему, создавая эффективные структуры базы данных с помощью
имеющихся в их распоряжении информационных технологий. Администраторам баз данных необходимо следить за профилем использования и контролировать данные, объем и время отклика различных
приложений. Однако для того, чтобы оперировать этой информацией, им необязательно знать содержание приложений.
|
|
|
Автономность уровня реализации поддерживается также употреблением специфических для предприятия терминов, которые, в свою очередь, моделируются на логическом уровне спецификации проекта (см. рис. 75). Например, обозначения ОТНОШЕНИЕ и АТРИБУТ связываются с обозначениями ЗАПИСЬ и ПОЛЕ на уровне реализации. Термин ЗАПИСЬ представляет тип записи, характеризующийся определенной комбинацией атрибутов. СТРАНИЦА может содержать различные типы записей. Работа администратора базы данных заключается в том, чтобы оптимизировать базу данных путем размещения часто требующихся типов записей в непосредственной близости друг от друга.
Уровни спецификации проекта можно отличить от уровней реализации по таким признакам (отличным от атрибутов реляционной схемы), как возможность изменения последовательности полей, их переименования и уплотнения данных, а также по наличию специфических форматов полей. Кроме того, можно создавать виртуальные поля, т.е. для полей можно описать правила преобразования, если их содержание состоит из других полей (например, поля итоговых величин).
Понятия «отношение» и «запись» могут не совпадать, если отношения разбиваются на несколько записей или если несколько записей объединяются в одну физическую запись.
|
|
|
Условия целостности и непротиворечивости, описанные на уровне спецификации проекта, теперь конкретизируются на физическом уровне в виде процедурных объектов. Дополнительные уточнения включают привязку конкретных методов физического доступа к логическим путям доступа или описание дополнительных физических путей доступа.
Помимо обозначений ЗАПИСЬ и ПОЛЕ, которые уже имеют базовые аналоги в спецификации проекта, введем теперь категории СТРАНИЦА и ОБЛАСТЬ (см. рис. 75), составляющие дополнительные организационные элементы для оптимизации структур распределения памяти. Эти предварительные единицы являются важнейшими «кирпичиками» для организации доступа к данным во внешних устройствах хранения и для распределения физических блоков хранения.
Рис. 75. Реализация модели данных
Потенциальные возможности оптимизации страниц и областей очевидны уже при рассмотрении осуществимости. Так, доступ к нескольким записям, размещенным на одной и той же странице, эффективнее, чем доступ к записям, разбросанным по разным страницам. Аналогично доступ к страницам, имеющим последовательную нумерацию, эффективнее, чем доступ к разрозненным страницам.
Язык описания хранения данных (DSDL) основан на ссылках между внутренними и внешними моделями и попутно реализует структуры распределения памяти. Физические пути доступа моделируются при помощи конкретных индексных таблиц, цепочек или кэш-функций.
Физические пути доступа описываются на уровне АССОЦИАЦИИ ЗАПИСЬ-ПОЛЕ. Они либо конкретизируют логические пути доступа, определенные на стадии спецификации проекта, либо создаются, что называется, с нуля на стадии реализации при наличии детальных сведений о параметрах производительности.
Описания на уровне физических структур данных обусловлены в первую очередь заложенной в проекте целью обеспечить независимость данных. Изменения в устройствах или системном программном обеспечении должны затрагивать только уровень реализации, но не уровень концептуальной схемы базы данных. По этой причине одна концептуальная схема базы данных со временем может вобрать в себя несколько внутренних схем баз данных. И наоборот, концептуальную схему базы данных можно обновлять, не внося изменений в ее физическую схему.
Дата добавления: 2019-02-26; просмотров: 160; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!