Базы данных и знаний. Управление базами и защита информации учебное п

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

Для ведения баз данных раздельно от прикладных программ требуется некоторое расширение обобщенных методов доступа. Это расширение называют «системой управления базами данных»

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

В этой связи мы можем сформулировать ряд требований, которым должна удовлетворять СУБД. К ним, в частности, относятся:

эффективное выполнение одной и той же СУБД различных функций предметной области;

минимизация избыточности хранимых данных;

предоставление для процессов принятия решений непротиворечивой информации;

обеспечение управления безопасностью;

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

простая физическая реорганизация базы данных;

возможностьцентрализованногоуправлениябазойданных;

упрощение процедуры эксплуатации ЭВМ.

11

1.1.Администратор базы данных

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

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

Администрирование базы данных предполагает обслуживание пользователей базы данных. Можно провести аналогию между АБД и ревизором предприятия. Ревизор защищает ресур-

12

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

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

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

13

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

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

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

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

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

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

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

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

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

14

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

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

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

Взаключение назовем причины, порождающие необходи-

мость обеспечения независимости данных :

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

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

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

15

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

1.3. Виды моделей баз данных

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

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

16

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

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

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

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

ренней моделью.

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

Одна из главных функций администрации базы данных состоит в разработке концептуальной модели (или модели предметной области). Компонентами модели являются объекты

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

17

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

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

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

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

18

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

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

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

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

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

1.4. Жизненный цикл системы с базой данных

Основныеэтапы жизненного цикла системы сбазой данных:

1.Проектирование базы данных.

2.Материализация базы данных.

19

3.Конвертирование существующих наборов данных и прикладных программ во вновь созданную базу данных.

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

5.Эксплуатация.

6.Развитие, совершенствование и сопровождение.

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

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

План проектирования системы служит основой гарантии правильной разработки системы с базой данных. Этот план определяет направление развития предметной области, а потому он должен быть полным и охватывать все системы. Как и всякий перспективный план, его необходимо детализировать на первый год, дать поквартальное разбиение на два-три.

20