книги / Структурный подход к организации баз данных

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

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

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

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

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

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

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

Подробнее задачи АБД рассматриваются в гл. 2.

1.5. НЕЗАВИСИМОСТЬ ДАННЫХ

1.5.1. Что означает «независимость данных»?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.6. СЛОВАРЬ ДАННЫХ

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

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

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

• установлении связи с другими пользователями; ■* осуществлении простого и эффективного управления элементами дан­

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

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

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

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

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

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

1.7. ПРИНЦИПЫ ПРОЕКТИРОВАНИЯ БАЗЫ ДАННЫХ И ДОСТИЖЕНИЯ ТРЕБУЕМЫХ ЭКСПЛУАТАЦИОННЫХ ХАРАКТЕРИСТИК

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

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

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

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

приемлемое время, т. е, заданным требованиям производительности.

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

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

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

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

• Данные до включения в базу данных должны проверяться на достоверность.

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

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

Ч А С Т Ь 1

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

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

Г л а в а 2

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

2.1.ФУНКЦИЯ АДМИНИСТРИРОВАНИЯ БАЗЫ ДАННЫХ

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

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

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

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

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

В крупной фирме АБД отчитывался перед управляющим техническими службами, а управляющий техническими службами — перед управля­ ющим обработкой данных. На одном из первых совещаний по разработке базы данных присутствовали кроме АБД эти управляющие, управляющие разработкой прикладных программ и управляющие объединением пользо­ вателей. На совещании предпринимались попытки разрешить противо­ речия между отделами. Предложениям, выдвигавшимся АБД, внимание не уделялось, поскольку его служебное положение было ниже, чем у остальных участников совещания. В результате весь; проект оказался под угрозой из-за того, что АБД не был наделен полномочиями, доста­ точными для разрешения противоречий между конфликтующими сторона­ ми и достижения компромисса.

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

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

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

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

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