Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 6)

Связи администратора банка данных. В процессе своей деятельности администратор БнД взаимодействует с другими категориями пользователей банка данных, а также и с «внешними» специалистами, не являющимися пользователями БнД (рис. 1.11).

Рис. 1.11. Взаимодействие АБнД с другими категориями пользователей

Прежде всего, если банк данных создается для информационного обслуживания какого-либо предприятия или организации, необходимы контакты с администрацией этой организации. Как указывалось выше, внедрение БнД приводит к большим изменениям не только системы обработки данных, но и всей системы управления организацией. Естественно, что такие большие проекты не могут быть выполнены без активного участия и поддержки руководителей организации. Руководство организации должно быть ознакомлено с возможностями, предоставляемыми БнД, проинформировано об их преимуществах и недостатках, а также о проблемах, вызываемых созданием и функционированием БнД.

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

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

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

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

Если банк данных функционирует в составе какой-либо автоматизированной информационной системы (например, в АСУ), то АБД должен работать в контакте со специалистами по обработке данных в этой системе.

Администраторы БнД взаимодействуют также с внешними по отношению к нему группами специалистов, и, прежде всего поставщиками СУБД и ППП, администраторами других БнД.

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

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

Средства администрирования включены в состав всех СУБД. Особенно развиты эти средства в корпоративных СУБД. Кроме того, появился целый класс специализированного программного обеспечения - средства DBA (DataBase Administration - администрирование базы данных).

Типичными функциями средств DBA являются:

1. Мониторинг работы БД, реакция на нештатные ситуации:

• слежение за использованием ресурсов, выдача статистики;

• обнаружение и исправление возникающих неполадок.

2. Наблюдение за объектами БД, анализ, сопоставление характеристик:

• планирование необходимых вычислительных мощностей;

• задание пороговых значений для слежения за нужными объектами.

3. Оптимизация хранения данных, оптимизация работы сервера:

• анализ свободного пространства, устранение дефрагментации;

• наблюдение за параметрами, влияющими на производительность БнД.

4. Сопровождение БД, файлов, табличных пространств, откатных сегментов:

• перенос таблицы на новое пространство, в другую СУБД, на другой компьютер;

• перенос содержимого базы данных в другую СУБД.

1.2.7. Взаимодействие компонентов БнД

На рис. 1.12 представлена упрощенная схема взаимодействия компонентов БнД в процессе создания и эксплуатации системы. Создание БД начинается с проектирования БД и ее описания на ЯОД (1). На этапе проектирования структуры БД могут использоваться как методики ручного проектирования, так и CASE-средства, автоматически генерирующие описания БД. Полученные описания должны быть введены в БнД и запомнены в соответствии с требованиями конкретной СУБД (2,3). После того как описание базы данных сохранено, в базу данных могут вводиться данные (4). При этом СУБД использует метаинформацию, зафиксированную в словаре данных. Заполненная БД может использоваться для извлечения из нее нужной пользователям информации (5). При формулировании запросов используется информация, содержащаяся в схемах и подсхемах. В результате выполнения запроса выходные данные в том или ином виде выдаются пользователю (6). Кроме собственно затребованных данных при выполнении операций с БнД часто выдается диагностическая информация (7). Для обеспечения надежности функционирования БнД необходимо выполнять соответствующие процедуры, в частности осуществлять журнализацию (8) выполняемых действий с БД, регулярно архивировать данные (9).

1.3. Классификация банков данных

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

Рис. 1.12. Схема взаимодействия компонентов БнД

Рис. 1.13. Классификация БнД

1.3.1. Классификация баз данных

Центральным компонентом банка данных является база данных, и большинство классификационных признаков относятся именно к ней. По форме представления информации различают визуальные и аудиосистемы, а также системы мультимедиа. Эта классификация показывает, в каком виде информация хранится в БД и выдается из баз данных пользователям - в виде изображения, звука или имеется возможность использования разных форм отображения информации. Понятие «изображение» здесь используется в широком смысле. Это может быть символьный текст, неподвижное графическое изображение (рисунки, чертежи и т.п.), фотографии, географические карты, движущиеся изображения. Классификация способов представления информации являет собой самостоятельную проблему и здесь не рассматривается.

По характеру организации данных БД могут быть разделены на неструктурированные, частично структурированные и структурированные. Этот классификационный признак относится к информации, представленной в символьном виде. К неструктурированным БД могут быть отнесены базы, организованные в виде семантических сетей. Частично структурированными можно считать базы данных в виде обычного текста или гипертекстовые системы. Структурированные БД требуют предварительного проектирования и описания структуры БД. Только после этого базы данных такого типа могут быть заполнены данными.

Структурированные БД, в свою очередь, по типу используемой модели делятся на иерархические, сетевые, реляционные, смешанные и мультимодельные.

Классификация по типу модели распространяется не только на базы данных, но и на СУБД.

В структурированных БД обычно различают несколько уровней информационных единиц (ИЕ), входящих одна в другую. Число этих уровней может быть различным даже для систем, относящихся к одному и тому же классу. Большинство структурированных систем поддерживают уровень поля, записи и файла. Эти информационные единицы могут называться в разных системах по-разному, но суть остается одной и той же, а именно: полю соответствует наименьшая семантическая единица информации; совокупность полей или иных, более сложных информационных единиц, если они допустимы в конкретной СУБД, образует запись, а множество однотипных записей представляет файл базы данных. В последнее время большинство СУБД в явном виде поддерживают и уровень базы данных как совокупности взаимосвязанных файлов БД.

В иерархических (рис. 1.14) и сетевых (рис. 1.15) моделях между информационными единицами (записями разных файлов) могут задаваться связи. Как видно из приведенных схем, графическое представление иерархической модели представляет собой граф типа «дерево». В такой модели имеется одна вершина - корень дерева, являющаяся входом в структуру. Каждая вершина, отличная от корня, может иметь только одну исходную вершину и в общем случае сколько угодно порожденных вершин.

Графическое представление сетевой модели представляет собой граф типа «сеть». Входом в такую структуру может являться любая вершина. Каждая вершина может иметь как несколько порожденных, так и несколько исходных вершин. Между парой вершин может быть объявлено несколько связей. Подавляющее большинство СУБД поддерживает простые сетевые структуры, т.е. между каждой парой типов записей поддерживается отношение 1:М (один ко многим). Направление и характер связи в сетевых моделях не являются очевидными, как в случае иерархической модели, поэтому при изображении структуры БД направление связи должно быть указано.

Рис. 1.14. Схема иерархической модели

Рис. 1.15. Схема сетевой модели с однотипными файлами

В сетевой модели с однотипными файлами (см. рис. 1.15) каждый файл может служить входом в структуру. Пара связанных файлов называется набором. В наборе тот файл, от которого идет связь, называется владельцем набора, а файл, к которому направлена эта связь, - членом набора. Файл, который в одном наборе является членом, в другом может быть владельцем. Другими словами, тип файла жестко не зафиксирован.

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

Рис. 1.16. Схема сетевой модели с разнотипными файлами: Г - главный файл; 3 – зависимый

Связи в иерархических и сетевых моделях описываются при проектировании БД. Чаще всего эти связи при хранении данных в БД передаются посредством адресных указателей. Иерархические и сетевые модели БД не накладывают ограничений на тип внутризаписной структуры. В принципе она может быть любой: как простой линейной (т.е. состоять только из простых полей, следующих в записи последовательно друг за другом), так и сложной иерархической, включающей в себя различные составные единицы информации (векторы, повторяющиеся группы и т.п.). Конкретные же СУБД накладывают ограничения на допустимые в них информационные единицы, характер связей между ними, порядок их расположения в записи, а также часто имеют и различные количественные ограничения.

Отдельное место среди структурированных систем занимают системы, построенные на использовании инвертированных файлов. Особенность организации данных в них состоит в том, что собственно хранимые данные и информация о связях между информационными единицами логически и физически отделены друг от друга. Основные данные в этих системах хранятся в файлах, записи которых могут иметь сложную структуру. Вся управляющая информация сосредоточена в ассоциаторе. Логическая связь между файлами устанавливается посредством компонента ассоциатора, называемого сетью связи. На рис. 1.17 схематически представлен принцип установления связей в таких системах. Реально связи устанавливаются не непосредственно с элементами связи, как это изображено на рисунке, а через преобразователь адреса. В системах, построенных на инвертированных файлах, можно передавать связь типа М: М (многие ко многим) между записями файлов, что не позволяют никакие другие системы. Отделение ассоциативной информации от собственно хранимых данных позволяет изменять связи, не изменяя при этом самих файлов.

Рис. 1.17. Схема организации данных в системах, основанных на инвертированных файлах

В реляционных моделях (в отличие от иерархических и сетевых) связи между записями разных таблиц БД определяются динамически в момент выполнения запроса. Эти связи устанавливаются по равенству значений соответствующих полей (полей связи), содержащихся в каждом из связанных файлов/таблиц (рис. 1.18).

Характеристики

Список файлов книги