Технология проектирования и администрирования баз данных и систем данных-Конспект

Администрирование базы данных предполагает обслуживание пользователей базы данных. Можно провести аналогию между АБД и ревизором предприятия. Ревизор защищает ресурсы предприятия, которые называются «деньгами», а АБД – ресурсы, которые называются «данными». Во многих организациях АБД рассматривают только как квалифицированного технического специалиста. Это не соответствует целям администрирования. Уровень АБД в иерархии организации должен быть достаточно высоким, чтобы он мог определять структуру данных и право доступа к ним и нести за это ответственность. АБД обязан хорошо представлять себе, как работает предприятие и как оно использует данные. Хотя от АБД и требуется техническая компетентность, не менее важным является понимание им предметной области, а также умение общаться с людьми и подчинять альтернативы стандартным процедурам. В противном случае АБД не сможет эффективно выполнять свои функции.

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

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

1.6. Независимость данных

Прикладному программисту для организации доступа к данным при использовании обычных наборов данных необходимо знать ответы на следующие вопросы:

•Каков формат данных?

•Где они располагаются?

•Как к ним обратиться?

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

элементов.

С совершенствованием архитектуры ЭВМ и ростом эффективности программного и аппаратного обеспечения, должны претерпевать изменения и методы доступа, и способы хранения данных. Если же методы доступа и способы хранения будут заложены в логике прикладной программы, то программистам придется приложить гораздо большие усилия на поддержание и обновление программ, что приведет к дополнительным ошибкам и расходу ресурсов. С другой стороны, пользователей базы данных (прикладных программистов и пользователей терминалов) следует ориентировать на информационное содержание данных и не посвящать в детали их представления и расположения. Таким образом, можно использовать базу данных и не знать внутреннее представление данных. Этим и достигается их

независимость.

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

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

Изменения метода хранения, путей доступа, формата элементов данных и связей между элементами, представляющими объекты предметной области, должны касаться в основном только СУБД. Вопрос состоит в том, когда, где, почему и кто должен определять для СУБД эти изменения. Кто должен их контролировать? Ответственность за решение этих проблем возлагается на АБД.

В заключение назовем причины, порождающие необходимость обеспечения независимости данных [2]:

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

2.Поставщик оборудования и программного обеспечения обработки данных должен вводить новую технологию, не требуя перепрограммирования прикладных программ клиента.

3.Необходимо обеспечить разделение данных, предоставляя их поразному организованными различным прикладным программам.

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

5.С целью обеспечения защиты и целостности базы данных требуется

ввести необходимую для АБД централизацию управления.

1.6.1. Два уровня независимости данных

Процесс проектирования базы данных начинается с установления концептуальных требований ряда пользователей (рис. 1.5).

Рис. 1.5

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

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

•Концептуальная модель. Концептуальные требования отдельных пользователей объединяются в единое «обобщенное представление», называемое концептуальной моделью.

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

• Внутренняя модель. Физическая модель, учитывающая распределение данных, методы доступа и способы индексирования, называется внутренней моделью.

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

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

1.6.2.Способы достижения независимости данных

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

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

Степень независимости данных определяется тщательностью проектирования базы данных. Всесторонний анализ объектов предметной области и их взаимосвязей минимизирует влияние изменения требований к данным в одной программе на другие программы. В этом и состоит всеобъемлющая независимость данных.

Управленческим инструментарием разработки при проектировании базы данных является словарь данных.

1.7. Словарь данных

Словарь данных – это централизованное хранилище сведений об объектах, составляющих их элементах данных, взаимосвязях между объектами, их

источниках, значениях, использовании и форматах представления.

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

Преимущества использования СД – в эффективном накоплении, определении и управлении суммарным ресурсом данных предметной области СД призван помогать пользователю в выполнении следующих функций:

установлении связи с другими пользователями;

осуществлении простого и эффективного управления элементами данных при вводе в систему новых элементов или изменении описания существующих;

уменьшении избыточности и противоречивости данных;

определении степени влияния изменений в элементах данных на всю базу данных;

централизации управления элементами данных с целью упрощения проектирования базы данных и ее расширения.

Идеальный СД содержит также сведения и о других категориях данных,

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

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

1.8. Принципы проектирования базы данных и достижения требуемых эксплуатационных характеристик

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

При рассмотрении требований конечных пользователей необходимо принимать во внимание следующее:

•База данных должна удовлетворять актуальным информационным потребностям.

•База данных должна удовлетворять актуальным требованиям за приемлемое время, т. е. заданным требованиям производительности.

•База данных должна удовлетворять выявленным и вновь возникающим

требованиям конечных пользователей.

•База данных должна легко расширяться при реорганизации и расширении предметной области.

•База данных должна легко изменяться при изменении программной и аппаратной среды.

•Загруженные в базу данных корректные данные должны оставаться корректными.

•Доступ к данным, размещаемым в базе данных, должны иметь только лица

ссоответствующими полномочиями.

Этапы проектирования базы данных с учетом рассмотренных выше аспектов представлены на рис. 1.6.

Рис. 1.6

2. АДМИНИСТРИРОВАНИЕ БАЗЫ ДАННЫХ

Переход при обработке информации на технологию баз данных и расширение существующей базы данных связаны со значительными финансовыми затратами, что предопределяет необходимость тщательного планирования и управления этим процессом. Кроме того, день ото дня растет количество данных, конвертируемых в базу данных, и усложняются прикладные программы. Все это требует наличия централизованного управления на каждом этапе жизненного цикла системы с базой данных [4].

2.1.Функция администрирования базы данных

Всовременных условиях количество хранимых предприятием данных возрастает почти в геометрической прогрессии. Процесс принятия управленческих решений зависит от объема и качества информации. Поэтому одним из наиболее значимых ресурсов любого предприятия является информация, которую можно выделить из базы данных. Чтобы предоставить определенную информацию в определенное время лицам, которым разрешен доступ к ней, необходимо обеспечить соответствующий уровень проектирования, обработки и ведения базы данных. Ответственность за это несет администратор базы данных (АБД) и его (ее) группа. Функция АБД может относиться и к людям, и к процедурам. Поэтому термин «АБД» будем относить и к человеку, и к функции.

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

2.1.1. Обязанности АБД

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

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

•определении элементов данных и объектов предметной области;

•присвоении различных имен, которые будут использоваться для обращения к элементам одного и того же типа;

•установлении взаимосвязей между элементами данных;

•выпуске текстового описания элементов данных;

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

•определении путей применения элементов данных в целях управления и планирования, т. е. на распределении функций между персоналом.

Рис. 2.1

В следующих разделах описываются потоки информации между АБД и каждой из перечисленных на рис. 2.1 групп.

2.1.2. АБД и администрация предприятия

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

Администрация предприятия --> АБД

•Высшие приоритеты предметной области, если не непосредственно от руководства, то по крайней мере в еженедельных сводках новостей, протоколах совещаний и по другим каналам.

•Сроки создания новой или расширения старой базы данных.

•Бюджетные ограничения проекта (включая людские ресурсы, программное обеспечение, аппаратные средства).

•Обязательства перед другими фирмами (например, по доступности информации, требованиям к производительности).

•Перспективные планы, например предполагаемые изменения, которые

могут оказать влияние на базу данных.

• Возможности изменения структуры предприятия.

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

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

АБД --> администрации предприятия

•Оценку сроков разработки на начальном этапе.

•Потребность в людских ресурсах (штат подчиненных АБД).

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

врамках выполнения своих функций.)

•Участие в обсуждении и утверждении бюджета.

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

•Описание средств защиты и контроля доступа к легко искажаемой информации.

•Потребности в памяти (объем и размещение, особенно в случае запроса новых аппаратных средств для базы данных).

2.1.3. АБД и пользователи

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

Пользователи->АБД

•Требования прикладных программ к данным.

•Приоритеты различных прикладных программ при работе с базой данных.

•Права владения данными.

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