Представление - база - данные
Cтраница 3
С каждым архитектурным уровнем СУБД связана некоторая модель данных. Языковые средства этой модели данных, которые могут и не быть доступными пользователям и системному персоналу, позволяют настраивать уровневые механизмы и управлять их функционированием. В частности, язык определения данных позволяет определить представление базы данных, ассоциируемое с этим уровнем архитектуры, а операторы языка манипулирования данными дают возможность выполнять различные операции над объектами этого представления. [31]
Фрейм-технология отображения предметной области дает структуру полного описания объектов данного типа и определяет подход сверху вниз к структуризации данных. В базе метаданных ( 15 ] отражается подход снизу вверх - от структур минимальных суждений об объектах и их свойствах в форме отображающего элемента до агрегированных структур. Сочетание обоих подходов позволяет наиболее рационально определить структуры, описывающие предметную область, на всех уровнях представления базы данных. [32]
ИС, реализующие аналитические методы анализа и обработки данных, классифицируются по способу представления данных. Производители ИС этого типа единодушны в том, что способ представления данных, принятый в реляционных СУБД, плохо подходит для решения аналитических задач как с точки зрения пользователя ( данные представляются в неудобном виде, плохо соответствующем решаемым задачам), так и с точки зрения эффективности обработки. Данные для пользователя удобно представлять в многоразмерных базах данных ( гиперкубах), где в качестве размерностей выступают такие интересующие руководителей атрибуты, как время, цена, географический регион и т.п. В связи с тем, что представление базы данных в многоразмерном виде на физическом уровне требует значительных затрат памяти, производители инструментальных средств для создания систем СППР используют различные способы для работы с данными. [33]
При создании программных конструкций для работы с репозиторием важно знать, что это ограничивает вашу область действия. Создание общих программ - чрезвычайно длительный процесс и может быть напрасной тратой времени, если вы никогда не используете обобщенный раздел. Предположим, что выполняется согласующий отчет для создания перекрестных ссылок между репозиторием и словарем данных Oracle, причем в результирующем отчете отражается число различий между свойствами Not Null базы данных и описаниями репозитория для некоторых представлений. Описание представления базы данных может быть основано на таблицах, ограничения Not Null которых неверны. Необходима утилита для просмотра значений Not Null словаря данных вместе со значениями Not Null репозитория. Такая утилита может быть формой для систематического отображения этих свойств, помогающего выявить неверные значения. [34]
Механизмы внутреннего уровня архитектуры служат для поддержки представления базы данных в среде хранения - внутренней или хранимой базы данных. Это - единственный архитектурный уровень, где база данных в действительности представлена полностью в материализованном виде. На всех остальных уровнях в процессе выполнения различных операций над базой данных появляются и исчезают лишь отдельные экземпляры или множества экземпляров ее объектов. Описание представления базы данных на внутреннем уровне архитектуры называется внутренней схемой, или схемой хранения. [35]
Наконец, будут введены функции возможных расширений в качестве инструмента для сравнения различных обобщений реляционной алгебры, связанных с введением неопределенностей. Эта проблема связана с возможностью представления базы данных как единого семантического целого. Будут введены W-функции) в качестве инструмента для работы с базой данных, как с единым целым. [36]
Наконец, будут введены функции возможных расширений в качестве инструмента для сравнения различных обобщений реляционной алгебры, связанных с введением неопределенностей. Эта проблема связана с возможностью представления базы данных как единого семантического целого. Будут введены W-функции х) в качестве инструмента для работы с базой данных, как с единым целым. [37]
Отложенное вычисление позволяет программисту упростить конструирование выражений благодаря назначению временных имен важным их частям. Однако более существенно то, что отложенное вычисление предоставляет элементарную возможность для определения представлений. Благодаря определению имен отношений как выражений с отложенным вычислением программист может использовать эти имена так, как будто определяемые отношения действительно существуют. Таким образом, множество определяемых отношений образует представление базы данных. [38]
 |
Образование вторичной базы данных. [39] |
В некоторых случаях сегмент-цель находится в середине дерева, описанного на языке DL / 1, и тогда он рассматривается как корневой сегмент вторичной базы данных. Нижними сегментами вторичной базы данных по отношению к корневому сегменту являются сегменты, расположенные ниже его по уровню в исходной базе данных, а также те сегменты, которые находились выше его по дереву. Последние помещаются в самую левую ветвь вторичной базы данных. Пример такой базы данных показан на рис. 12.14. Сегменты вторичной базы данных представляются прикладной программе в обычном порядке ( сверху-вниз, слева-направо), который был показан на рис. 12.5. Таким образом, вторичный индекс может быть использован для изменения обработки или последовательности представления базы данных, если в этом возникает необходимость. [40]
БОЛЬНИЦА, не показаны в явном виде, так как иначе схема оказалась бы безнадежно запутанной. Можно, конечно, попробовать показать множество экземпляров на любом уровне иерархии. Очевидно, что для любой базы данных обычного объема на диаграмме невозможно показать все множество экземпляров типов сегментов. Вот почему для представления базы данных обычно используется простая иерархическая схема, подобная приведенной на рис. 2.2. Возможность существования множества экземпляров каждого сегмента принимается без доказательства. [41]
Поэтому создание первого дерева завершено. Оно имеет корень ИГРОКИ и сыновей ИП и ИКС. Существует одна входящая дуга из типа записи ИКС, который уже был помещен в иерархию. Поэтому задаем в качестве сына для типа КОМАНДЫ тип виртуальных записей указатель на ИКС и переходим к третьему дереву. Оно состоит из корня ПОЗИЦИИ с типом виртуальной записи ИП в качестве сына. Полная иерархия показана на рис. 3.9. Заметим, что такая иерархия является плохим способом представления бейсбольной базы данных, поскольку те виды запросов, которые легко формулируются в базирующихся на иерархии языках манипулирования данными, не включают некоторых естественных запросов. Позднее мы поясним это замечание и покажем лучшее иерархическое представление. [42]
Страницы: 1 2 3