
- •В данном файле представлены следующие лекции по дисциплине базы данных: 3, 4, 6, 8-15
- •6. Основные области внешней памяти
- •7. Хранение таблиц
- •8.Управление буферами
- •9. Структура встроенного языка
- •10. Общая характеристика языка sql
- •13. Проблема параллелизма
- •14. Блокирование информационных объектов базы данных
- •18. Хранилища данных
- •19. Медиаторы
- •Лекция 9 20. Olap - системы
- •Многомерное представление данных в виде куба
- •«Разрезание» куба
- •22. Некоторые особенности субд oracle
- •23. Краткая характеристика настольной субд Access 2002
- •24. Использование языка qbe в субд Acces
- •25. Использование внешних данных в бд Access
- •26. Использование гиперссылок в бд Access
- •27. Публикация бд Access в интернете
- •28. Совместное использование баз данных Access
- •29. Проблемы внедрения баз данных
- •30. Администрирование баз данных
22. Некоторые особенности субд oracle
Основным средством управления всей инфраструктурой ORACLE, включая базы данных, сервер приложения и все приложения является Oracle Enterprise Manager (EM).
ЕМ – это программный продукт, предлагаемый ORACLE в качестве дополнения к основной СУБД, чтобы облегчить администрирование ее среды.
Однако ЕМ может использоваться не только администраторами баз данных, но и многими разработчиками, работающими с ORACLE, независимо от того используют ли они традиционную среду разработки клиент/ сервер или Web.
Набор инструментов ЕМ очень широк: от автономной консоли до средств полномасштабного мониторинга и контроля полной среды ORACLE.
Ниже рассматриваются основные средства администрирования БД с помощью автономной консоли.
Введение в консоль
ЕМ спроектирована так, что все ее функциональные возможности и инструменты доступны из одной точки: консоли.
Когда консоль запускается, у администратора есть выбор: запустить ее в автономном режиме или подключиться к серверу управления ORACLE. Если выбрать автономный режим, будут потеряны многие функциональные возможности, связанные со средой управления.
Ниже рассматривается автономный режим, вполне достаточный для выполнения самых основных работ как, например, создание основных информационных объектов. На рис.22.1 представлен вид консоли в автономном режиме.
Рис.22.1 Вид консоли при работе в автономном режиме
Консоль ЕМ использует концепцию “главное-подробности”. В этом интерфейсе список целевых объектов дерева навигатора выводится в левой стороне окна, а более подробное описание выбранных целевых объектов – в правой стороне. Описание может изменяться в зависимости от типа выбранного пользователем объекта. На рис.22.2 представлен вид навигатора и описание БД с именем МЕА1.
Рис.22.2 Вид консоли при выборе в качестве целевого объекта базы данных
На левой стороне консоли расположены кнопки для вызова целого ряда инструментов и возможностей.
При выборе на дереве навигатора объекта Schema дерево принимает следующий вид (рис.22.3).
Рис.22.3 а Вид дерева навигатора при выборе Schema
Рис.22.3 б Продолжение рисунка дерева
Из представленного рис. видно, что на дереве навигатора отображается список схем.
Создание табличной области
Табличная область - это логическая структура данных, которой соответствуют один или более физических файлов данных (рис.22.4 ).
Рис.22.4 Соотношение табличных областей файлом данных
В каждой табличной области могут содержаться таблицы, индексы, представления и некоторые другие объекты. Одна БД может содержать целое множество табличных областей.
Для создания табличной области необходимо нажатием кнопки Create (третья кнопка сверху в виде зеленого куба) открыть список возможностей и выбрать пункт Tablespace (рис.22.5).
Рис.22.5 Список инструментов и возможностей для операции Create
После выбора этого пункта появится окно (рис. 22.6), в котором требуется указать имя создаваемой табличной области, после чего закончить операцию нажатием кнопки Create. В результате табличная область будет создана. Заметим, что в этом же окне отмечается файл, в котором она будет располагаться физически.
Рис. 22.6 Задание имени табличной области
Создание схем
Связанные объекты базы данных организуются в схему базы данных. К примеру, принято организовывать все таблицы, индексы, представления и другие объекты базы данных, необходимые для работы приложения, в одну схему базы данных. При этом становится понятным назначение конкретного объекта (таблицы, представления или другого объекта) для обеспечения функционирования соответствующего приложения. На рис. 22.7 приведена схема базы данных.
Рис.22.7 Схема базы данных
Важно понимать, что схемы физически не организуют места хранения объектов баз данных; связанные объекты организуются только логически.
Иными словами, логическая организация объектов баз данных внутри схем предназначена исключительно для использования преимуществ организации объектов и не имеет ничего общего с физической дисковой памятью, применяемой для хранения объектов баз данных.
Логическая организация, предлагаемая схемами, имеет практическую пользу. Для примера рассмотрим базу данных Oracle с двумя схемами, S1 и S2. В каждой из схем содержится таблица, называемая Т1. Хотя таблицы называются одинаково, каждая из них идентифицируется однозначно, так как они находятся в различных схемах баз данных. Используя стандартную уточняющую запись через точку, можно определить полные имена таблиц как S1.T1 и S2.T1.
Для пояснения различий между логической и физической организациями можно воспользоваться принципами размещения файлов на диске операционной системой. Компоновка каталогов и файлов в графической программе управления файлами, например, в Microsoft Windows Explorer, совсем не обязательно соответствует физическому местонахождению каталогов и файлов на конкретном диске. Каталоги файлов представляют логическую организацию файлов операционной системы. Базовая операционная система решает, где физически хранить блоки каждого файла, независимо от логической организации каталогов этих файлов.
В Oracle понятие схемы базы данных непосредственно связано с понятием пользователя базы данных. Другими словами, между схемой базы данных Oracle и учетными сведениями пользователя установлено взаимно-однозначное соответствие, так что пользователь и соответствующая ему схема имеют , одно и то же имя. В результате люди, работающие с Oracle, часто не видят различий между пользователями и схемами. Например, обычно вместо "схема SCOTT содержит таблицы ЕМР и DEPT" говорится "пользователь SCOTT является владельцем таблиц ЕМР и DEPT". Хотя в данном случае эти два предложения содержательно эквивалентны.
Замечание: в системах реляционных баз данных, отличных от
Oracle, пользователи и схемы могут быть абсолютно различными
понятиями.
Связь понятий схемы и пользователя находит свое отражение уже в самом начале операции создания схемы: после нажатия кнопки Create нужно развернуть список возможностей и выбрать пункт User (рис.22.8 ).
Рис.22.8 Начальные действия при создании схемы
После этого задается имя пользователя (оно же будет и именем схемы), пароль, имя табличной области и пр. (рис.22.9 ).
Рис.22.9 Задание имени пользователя/схемы
Задаются возможности и ресурсы пользователя (рис.22.10 )
Рис.22.10 Задание возможностей и ресурсов пользователя
Далее указываются возможности по использованию табличной области (рис.22.11) после чего операция завершается (Create) (рис.22.12 ) .
Рис.22.11 Задание возможности по использованию табличной области
Рис.22.12 Завершение работы по определению пользователя/схемы
Однако после создания схемы в дереве навигатора она не видна (рис.22.13 ) до тех пор, пока в не будет создан первый объект.
Рис.22.13 Отсутствие схемы в дереве навигатора сразу после его создания
Создание таблиц
Используя кнопку Create, вызвать список возможностей Create и выбрать пункт Table (рис.22.14).
Рис.22.14 Начальные действия при создании таблицы
Далее раскроется окно, в котором необходимо определить названия столбцов таблицы и их типы данных (рис.22.15).
Рис. 22.15 Вид окна для описания столбцов таблицы
Если необходимо задать первичный или внешний ключ, ограничения целостности, то следует перейти к следующему шагу, в противном случае можно закончить описание таблицы, нажав кнопку Готово. Для простоты ограничимся этим шагом.
После создания в схеме первой таблицы имя созданной схемы появляется в дереве навигатора. Выбрав имя схемы, можно увидеть состав ее таблиц (рис. 22.16).
Рис.22.16 Состав таблиц выбранной схемы
Просмотр и заполнение таблиц
Для работы на дереве навигатора выбирается нужная таблица. В результате открывается окно с описанием ее структуры. В качестве примера здесь используется таблица РУКОВодители, содержащая два столбца (рис.22.17 ).
Рис.22.17 Структура таблицы РУКОВ
Для перехода в режим просмотра/ редактирования нужно в меню выбрать Object/viewEdit Contens (рис.22.18).
Рис.22.18. Переход в режим просмотра/ редактирования таблицы
Далее раскрывается окно с пустыми (или ранее заполненными ) столбцами. С клавиатуры вносятся необходимые данные. В конце заполнения таблицы, чтобы зафиксировать внесенные изменения, требуется нажать кнопку Apply. После этого кнопка “погаснет”.
Рис.22.19 Заполненная таблица РУКОВ
Следует обратить внимание на полное название таблицы: “имя схемы”.”имя таблицы”. Отсюда становится понятно, что в разных схемах могут содержаться таблицы с одинаковыми названиями. Справа от названия таблицы указано имя пользователя и имя базы данных.
Для дальнейшей работы нам потребуется еще одна таблица. Создадим (аналогично предыдущей) таблицу СОТРУДники со следующей структурой и содержанием (рис.22.20, 22.21).
Рис.22.20 Структура таблицы СОТРУД
Рис.22.21 Содержание таблицы СОТРУД
Установление связей между таблицами
Рассмотрим установление связей между таблицами РУКОВодители и СОТРУДники. Для этого надо установить ключи: первичный ключ в таблице РУКОВодители и внешний ключ в таблице СОТРУДники.
Сначала установим первичный ключ в таблице РУКОВодители. Откроем для просмотра структуру этой таблицы (рис см выше) и выберем закладку Constraints (рис.22.22).
Рис. 22.22 Окно Constraint on the Table
В появившемся окне надо ввести имя (любое; например, PK_POLE1), в качестве типа указать PRIMARY (т.к. данная таблица является родительской и у нее должен быть первичный ключ), затем необходимо указать точное имя поля первичного ключа (в нашем случае ТАБ_НОМ_РУК). Нажать кнопки Applay и ОК (рис.22.23 ).
Рис.22.23 Определение первичного ключа в таблице
После этого появится окно с деревом навигатора (рис.22.24). На правой половине окна будут указаны все объекты схемы, таблицы которой используются для установления связи. Обратим внимание на то, что кроме таблиц появился индекс с именем PK_POLE1. Появление индекса легко объяснимо, т.к. для поля первичного ключа индекс строится всегда.
Рис.22.24 Состав схемы после установления первичного ключа
в таблице РУКОВ
Далее необходимо установить внешний ключ в таблице СОТРУДники. Откроем ее окно Constraint и заполним, как показано на рис. 22.25 .
Рис.22.25 Определение внешнего ключа в таблице
После нажатия кнопок Applay и ОК будет создан внешний ключ и установлена связь с родительской таблицей РУКОВодители. Однако никаких графических отображений и записей о наличии связи не будет.
Создание запросов
Создадим запрос на выборку данных из двух таблиц: “Кто из сотрудников является подчиненным руководителя Иванова ?”. Тем самым “убьем двух зайцев”: посмотрим, как создаются запросы, и проверим наличие связи между таблицами.
Запрос можно создать только на SQL. Для этого раскроем целый ряд кнопок для выбора инструментов Database Tools и воспользуемся первой кнопкой справа (рис.22.26).
Рис.22.26 Инструменты Database Tools
В результате нажатия указанной кнопки будет вызвано окно SQL Scratchpad, в котором необходимо ввести запрос на SQL. После его исполнения ниже будет отображен результат (рис.22.27), подтверждающий правильность всей ранее выполненной работы.
Рис.22.27 Запрос на SQL и результат его исполнения
Краткое резюме
Средства администрирования ЕМ имеют множество отличий от аналогичных средств других систем, например, от Access.
В ЕМ большое значение имеет понятие схемы базы данных, принадлежащей конкретному пользователю. Причем понятие схемы идентично понятию пользователя. Для одной базы данных может быть создано множество схем.
Схема привязывается к конкретной табличной области, которых в базе данных может быть создано множество.
Схема может включать в себя связанные или несвязанные таблицы, индексы и представления.
Таблицы, принадлежащие разным схемам, не могут быть связаны между собой.
Установление связей между таблицами выполняется автоматически в результате задания первичных и внешних ключей. При этом тип связи определяется автоматически самой системой, а не пользователем.
Задание первичного ключа в таблице ведет к автоматическому созданию индекса (что вполне естественно) и отображению этого индекса в составе схемы.
Факт наличия связи между таблицами формально никак не отображается.
Отсутствуют средства графического отображения схемы.
Запросы к таблицам схемы могут быть сформированы только на языке SQL. Средства QBE (формирования запросов по образцу) отсутствуют.
Операция просмотра/редактирования содержимого таблиц выполнена очень примитивно, без каких либо возможностей автоматизации и уменьшения трудоемкости.
Однако следует иметь в виду, что указанные особенности и недостатки не могут служить мерилом оценки ЕМ в целом, так как нами рассмотрена только часть возможностей администрирования. За бортом осталось множество возможностей по формированию заданий, событий, сбора статистики и оптимизации работы системы.
Лекция 11