Хранение информации

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

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

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

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

Хранилище данных (ХД, используют также термины Data Warehouse, «склад данных», «информационное хранилище») — это база, хранящая данные, агрегированные по многим измерениям. Основные отличия ХД от БД: агрегирование данных; данные из ХД никогда не удаляются; пополнение ХД происходит на периодической основе; формирование новых агрегатов данных, зависящих от старых — автоматическое; доступ к ХД осуществляется на основе многомерного куба или гиперкуба.

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

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

Каждый из участников действия (пользователь, группа пользователей, «физическая память») имеет свое представление об информации

По отношению к пользователям применяют трехуровневое представление для описания предметной области: концептуальное, логическое и внутреннее (физическое).

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

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

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

Иерархическая модель является разновидностью сетевой, являющейся совокупностью деревьев (лесом).

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

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

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

по способу хранения информации:

• интегрированные;

• распределенные;

по типу пользователя

• монопользовательские;

• многопользовательские;

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

• прикладные;

• предметные.

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

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

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

1.Копируемые данные. Одинаковые копии данных хранятся в различных местах использования, так как это дешевле передачи данных. Модификация данных контролируется централизованно.

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

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

4.Секционированные данные. На различных объектах используются одинаковые структуры, но хранятся разные данные.

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

6.Несовместимые данные. Независимые базы данных, спроектированные без координации, требующие объединения.

Важное влияние на процесс создания БД оказывает внутреннее содержание информации. Существует два направления:

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

• предметные БД, ориентированные на конкретный класс данных, например, предметная БД «Материалы», которая может быть использована для различных приложений.

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

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

Основные стандарты СУБД:

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

• универсальность (по отношению к концептуальному и логическому уровням, типу ЭВМ);

• совместимость, неизбыточность;

• безопасность и целостность данных;

• актуальность и управляемость.

Существуют два основных направления реализации СУБД: программное и аппаратное.

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

· описание данных на концептуальном и логическом уровнях;

· загрузку данных;

· хранение данных;

· поиск и ответ на запрос (транзакцию);

· внесение изменений;

· обеспечение безопасности и целостности.

· обеспечивает пользователя следующими языковыми средствами:

o языком описания данных (ЯОД);

o языком манипулирования данными (ЯМД);

o прикладным (встроенным) языком данных (ПЯД, ВЯД).

Аппаратная реализация предусматривает использование так называемых машин баз данных (МБД). Их появление вызвано возросшими объемами информации и требованиями к скорости доступа. Слово «машина» в термине МБД означает вспомогательный периферийный процессор. Термин «компьютер БД» — автономный процессор баз данных или процессор, поддерживающий СУБД.

Основные направления МБД:

• параллельная обработка;

• распределенная логика;

• ассоциативные ЗУ;

• конвейерные ЗУ;

• фильтры данных и др.

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

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

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

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

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

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

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

Модели приложений могут быть классифицированы следующим образом:

1. Приложения, использующие единственный файл.

2. Приложения, использующие несколько файлов, в том числе:

• допускающие независимую параллельную обработку;

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

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

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

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

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

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

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

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