Cтраница 2
Вторая группа персонала администрирования данными - администратор базы данных - ответственна за представление базы данных в среде хранения, за эффективную и надежную эксплуатацию системы базы данных. В ее задачу входит настройка организации базы данных в среде хранения с целью повышения эффективности функционирования системы. [16]
Объем памяти S ( n) - объем памяти, необходимой для представления структурированной базы данных. [17]
Языковые средства СУБД используются для выполнения двух основных функций - для описания представления базы данных на управляемых уровнях системной архитектуры и для инициирования выполнения операций манипулирования данными. [18]
Теперь, когда вы познакомились с иерархической структурой IMS и запомнили большинство терминов, которые мы собираемся использовать, интересно рассмотреть представление базы данных DL / 1 с различных точек зрения. После этого вам будет показано определение структуры базы данных. [19]
Поскольку все уровни предлагаемой архитектурной модели должны отражать разные точки зрения на одну и ту же единственную базу данных, материализованную в среде хранения, необходимо в составе СУБД иметь такие механизмы, которые обеспечивали бы соответствие между представлениями базы данных на разных уровнях. Именно функциональные возможности этих механизмов обеспечивают абстракцию данных в системе, определяют ту степень свободы, которая предоставляется на связанных ими уровнях для выбора представления базы данных, и тем самым - достижимую в системе степень независимости данных. [20]
Легко заметить, что, говоря о способах работы с базами данных, мы ничего не сказали об использовании формул, более сложных преобразований баз посредством так называемых фильтров, связях баз данных с расширенными таблицами и текстовыми фреймами, с другими популярными формами представления баз данных. Важность таких операций несомненна, однако сравнительно элементарный уровень изложения и стремление как-то ограничить объем излагаемого материала вынуждают авторов предложить читателю самостоятельно обратиться к клавише F1 ( ПОМОЩЬ) и другим литературным источникам. [21]
Механизмы междууровневого отображения данных в СУБД обеспечивают отображение моделей данных смежных архитектурных уровней системы. Каждому объекту представления базы данных на одном из этих смежных уровней они ставят в соответствие объект или некоторую продуцируемую конструкцию из объектов представления базы данных другого уровня. Аналогичным образом эти механизмы поддерживают и отображение операций над объектами данных. [22]
Современная концепция представления базы данных заключается во введении между физическим уровнем представления данных и внешним уровнем представления данных пользователем ( логическим уровнем) еще одного промежуточного уровня - концептуальной схемы базы данных. При этом один из указанных выше способов представления структур данных на концептуальном уровне и определяет тип СУБД в целом. Концептуальный уровень характеризует обобщенное представление всех внешних моделей пользователей. [23]
Некоторым недостатком схемы рис. 8.8 6 является ее сложность. Фактически осуществляется лишь представление базы данных в виде изображения, но для этого требуются шесть отдельных шагов и построение промежуточной структуры данных. Разумеется, желательно было бы сократить количество шагов в этом процессе. При внимательном рассмотрении процесса можно убедиться, что некоторые шаги являются излишними. [24]
Другая проблема связана с разрешением пользователю обновлять его представление базы данных. Если представление пользователя основано на простой подсхеме, которая, как в Кодасиле, всего лишь уменьшает количество доступных пользователю типов записей и полей, и если пользователь меняет только поля, а не структуры, больших трудностей не возникает. [25]
Сгенерированный модуль DBD для языка BETA СУБД ОКА помещается затем в один из разделов библиотеки ОКА DBD LIB. Кроме того, система генерирует карты DD, связанные с набором данных, использующиеся для представления базы данных в системе ОКА. [26]
Вторая неприятная в этом отношении сторона состоит в том, что при автоматической генерации фрагмента структуры базы данных выбранные формы ввода-вывода однозначно определяют структуру данных в базе данных. Такая жесткость противоречит современным архитектурным концепциям, допускающим благодаря механизмам междууровневого отображения данных некоторую степень свободы между представлениями базы данных на внешнем и концептуальном уровне системы базы данных. [27]
Механизмы междууровневого отображения данных в СУБД обеспечивают отображение моделей данных смежных архитектурных уровней системы. Каждому объекту представления базы данных на одном из этих смежных уровней они ставят в соответствие объект или некоторую продуцируемую конструкцию из объектов представления базы данных другого уровня. Аналогичным образом эти механизмы поддерживают и отображение операций над объектами данных. [28]
Поскольку все уровни предлагаемой архитектурной модели должны отражать разные точки зрения на одну и ту же единственную базу данных, материализованную в среде хранения, необходимо в составе СУБД иметь такие механизмы, которые обеспечивали бы соответствие между представлениями базы данных на разных уровнях. Именно функциональные возможности этих механизмов обеспечивают абстракцию данных в системе, определяют ту степень свободы, которая предоставляется на связанных ими уровнях для выбора представления базы данных, и тем самым - достижимую в системе степень независимости данных. [29]
Концептуальный уровень архитектуры ANSI / SPARC служит для поддержки единого взгляда на базу данных, общего для всех ее приложений и в этом смысле независимого от них. Именно в среду концептуального уровня при проектировании базы данных отображается инфологическая модель предметной области системы базы данных. Представление базы данных на концептуальном уровне называется концептуальной базой данных, а описание такого представления - концептуальной схемой базы данных. [30]