Банки и базы данных

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

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

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

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

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

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

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

Одними из первых СУБД являются следующие системы: iMS (IBM, 1968 г.), IDMS (Cullinet, 197l“г.), ADABAS (Software AG, 1969 г.) и ИНЭС (ВНИИСИ АН СССР, 1976 г.). Количество современных систем управления базами данных исчисляется тысячами.

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

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

В любой БД (в массиве информации) реализуется определенная организация данных. Под организацией данных понимается совокупность методов и средств представления информации в ЭВМ. Различают физическую и логическую организацию данных.

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

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

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

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

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

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

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

В процессе научных исследований, посвященных тому, как именно должна быть устроена СУБД, предлагались различные способы реализации. Самым жизнеспособным из них оказалась предложенная Американским национальным институтом стандартов ANSI (American National Standards Institute) трехуровневая система организации БД, изображенная на рис. 3.4.

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

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

Рис. 3.4. Трехуровневая модель системы управления базой данных

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

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

Выделение концептуального уровня позволило разработать аппарат централизованного управления базой данных.

По способу доступа СУБД делятся на файл-серверные, клиент-серверные и встраиваемые.

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

Клиент-серверная СУБД позволяет обмениваться клиенту и серверу минимально необходимыми объемами информации. При этом основная вычислительная нагрузка ложится на сервер. В большинстве случаев клиент-серверная СУБД гораздо менее требовательна к пропускной способности компьютерной сети, чем файл-серверная СУБД. Так, при выполнении операции поиска в базе данных по заданным пользователем параметрам нет необходимости получать на компьютер клиента весь массив данных: клиент передает параметры запроса серверу, а сервер производит поиск по полученному запросу в базе данных (Firebird, Interbase, IBMDB2, MS SQL Server, Svbase, Oracle, Postgre SQL, MySQL, ЛИНТЕР, MDBS).

Встраиваемая СУБД – библиотека программ, которая позволяет унифицированным образом хранить большие объемы данных на локальной ЭВМ (Open Edge, SQLite, Berkeley DB, один из вариантов Firebird, один из вариантов MySQL, SavZigzag, Microsoft SQL Server Compact, ЛИНТЕР).

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

1. Пользователь посылает СУБД запрос на получение данных из БД.

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

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

4. СУБД запрашивают информацию о части концептуальной модели.

5. СУБД получает информацию о запрошенной части концептуальной модели.

6. СУБД запрашивает информацию о местоположении данных на физическом уровне (файлы или физические адреса).

7. В СУБД возвращается информация о местоположении данных в терминах операционной системы.

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

Рис. 3.3. Схема прохождения запроса к БД

9. Операционная система осуществляет перекачку информации из устройств хранения и пересылает ее в системный буфер.

10. Операционная система оповещает СУБД об окончании пересылки.

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

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

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

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

• существенное упрощение автоматизации процесса ведения информационной базы (заполнения, изменения содержания и изменения структуры, стирания данных и др.);

• легкую реализацию обработки данных на современных ЭВМ.

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

Для создания БД ИС необходимо изучить ее жизненный цикл (ЖЦ).

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

Каждый жизненный цикл может быть разделен по времени на отдельные стадии:

• предварительное планирование БД;

• проверка реализуемости БД;

• определение требований к БД;

• проектирование БД;

• реализация БД;

• эксплуатация БД.

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

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

1. Технологическая осуществимость. Она включает оценку наличия технических средств и программного обеспечения для работы БД. Иначе говоря, она отвечает на вопрос: "Есть ли технология, необходимая для реализации требуемой БД?"

2. Операционная осуществимость. Она включает оценку требований к квалификации и опыту управленческого персонала, работающего с этой БД. Иначе говоря, она отвечает на вопрос: "Есть ли в системе управления персонал и средства, необходимые для успешного создания БД?"

3. Экономическая целесообразность. Она включает оценку затрат на создание БД и их приемлемый уровень. Иначе говоря, она отвечает на вопрос: "Окупится ли создание и применение БД?"

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

После определения требований к БД наступает стадия проектирования БД.

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

Наконец, наступает стадия эксплуатации, т.е. непосредственного использования БД по назначению. На этой стадии выполняются этапы:

• сопровождение в процессе применения БД;

• поВперед реорганизация и расширение БД;

• снятие БД с эксплуатации.

В сопровождение баз данных входят мероприятия по улучшению работы баз данных в составе ИС.

В процессе сопровождения в базы данных вносятся различные изменения:

• исправления ошибок, не требующие изменения технического задания и документации;

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

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

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

Модернизация баз данных носит название реорганизации базы данных. В реорганизацию баз данных входят:

• реструктуризация баз данных;

• реформатизация баз данных.

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

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

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

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

Заказчик определяет:

• объем, ОГЛАВЛЕНИЕ, сроки, исполнителей и порядок выполнения работ по созданию и внедрению БД;

• критерии эффективности.

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

Исполнитель осуществляет:

• проведение исследования процесса управления (информационное обследование системы управления);

• подготовку проектов технических заданий (ТЗ), необходимых для разработки БД;

• подготовку перечней программных комплексов, использующих эту БД;

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

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

• оформление необходимой документации на БД;

• участие в подготовке материалов для последующей модернизации БД;

• сопровождение БД на этапах последующей ее эксплуатации;

• проведение модернизации БД на этапах последующей ее эксплуатации;

• доработки БД по замечаниям, возникшим в процессе эксплуатации.

Таким образом, при создании и внедрении БД четко разграничиваются функции и задачи заказчика и разработчика системы.

Конечный пользователь БД будет непосредственно пользоваться БД. Конечный пользователь осуществляет:

• практическое выполнение манипуляций с БД;

• постоянное поддержание БД в готовности к применению;

• обобщение опыта эксплуатации БД.

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

Администратор БД осуществляет:

• участие в проведении исследования процесса управления (информационное обследование системы управления);

• участие в подготовке проектов технических заданий (ТЗ), необходимых для разработки БД;

• участие в подготовке перечней программных комплексов, использующих эту БД;

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

• участие в отладке структуры и программ управления БД и их экспериментальной проверки;

• практическое выполнение манипуляций с БД;

• постоянное поддержание БД в готовности к применению;

• поддержание в использовании (доступе) конечными пользователями БД служебной дисциплины и конфиденциальности используемой информации;

• участие в обобщении опыта эксплуатации БД;

• участие в организации обучения пользователей применению на практике БД;

• контроль правильности эксплуатации БД ее пользователями в процессе ее применения;

• участие в подготовке материалов для последующей модернизации БД;

• проведение модернизации БД на этапах последующей ее эксплуатации.

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

• она должна адекватно отражать моделируемую предметную область (иметь взаимосвязанность данных);

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

• она должна иметь возможности расширения для учета информации прикладных задач управления, вновь появившихся в процессе эксплуатации ИУС (независимость данных);

• она должна иметь возможность восстанавливать информацию после возможных сбоев (восстанавливаемость данных);

• она должна предусматривать возможность защиты информации и поддержания ее целостности (защита данных);

• она должна обеспечить доступ к данным в режиме реального времени (быстродействие);

• она должна иметь приемлемую стоимость.

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

1. Интеграция данных.

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

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

2. Независимость программ от данных.

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

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

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

3. Неизбыточность данных.

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

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

4. Непротиворечивость данных.

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

5. Связность данных.

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