Модели и методы хранения и поиска данных

Глава 3 Организация хранения и поиска информации

В результате освоения данной темы студент должен:

знать:

- классификацию моделей и методов хранения и поиска данных;

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

- основы построения и функционирования информационно-поисковых систем;

- основы построения баз данных;

уметь:

- работать с информацией в информационно-поисковых системах;

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

- владеть основными методами, способами и средствами получения, хранения, переработки информации, способность работать с компьютером как средством управления информацией, способность работать с информацией в глобальных компьютерных сетях (ОК-13);

- владеть основными методами, способами и средствами получения, хранения, переработки информации, навыками работы с компьютером как средством управления информацией (ОК-17);

- работать с информацией в глобальных компьютерных сетях и корпоративных информационных системах (ОК-18);

- осуществлять сбор, анализ и обработку данных, необходимых для решения поставленных экономических задач (ПК-4);

- способность, используя отечественные и зарубежные источники информации, собрать необходимые данные проанализировать их и подготовить информационный обзор и/или аналитический отчет (ПК-9);

- способность использовать для решения аналитических и исследовательских задач современные технические средства и информационные технологии (ПК-10);

- владеть методами и программными средствами обработки деловой информации, способностью взаимодействовать со службами информационных технологий и эффективно использовать корпоративные информационные системы (ПК-34);

владеть:

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

- навыками работы с информацией в информационно-поисковых системах;

Модели и методы хранения и поиска данных

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

иерархическая,

сетевая,

реляционная.

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

постреляционная,

многомерная,

объектно-ориентированная.

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

В некоторых СУБД поддерживаются одновременно несколько моделей данных.

Иерархическая модель.

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

Рис. 3.1. Представление связей в иерархической модели.

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

Тип «дерево» схож с типами данных «структура» языков программирования ПЛ/1 и С и «запись» языка Паскаль. В них допускается вложенность типов, каждый из которых находится на некотором уровне.

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

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

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

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

Для организации физического размещения иерархических данных в памяти ЭВМ могут использоваться следующие группы методов:

представление линейным списком с последовательным распределением памяти (адресная арифметика, левосписковые структуры),

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

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

поиск указанного экземпляра БД,

переход от одного дерева к другому,

переход от одной записи к другой внутри дерева,

вставка новой записи в указанную позицию,

удаление текущей записи и т. д.

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

К достоинствам иерархической модели данных относятся эффективное использование памяти ЭВМ и неплохие показатели времени выполнения основных операций над данными. Иерархическая модель данных удобна для работы с иерархически упорядоченной информацией.

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

Сетевая модель.

Сетевая модель данных позволяет отображать разнообразные взаимосвязи элементов данных в виде произвольного графа, обобщая тем самым иерархическую модель данных (рис. 3.2). Наиболее полно концепция сетевых БД впервые была изложена в Предложениях группы КОДАСИЛ (KODASYL).

DY HosGy4/d6AxweH174nH7mcf5Y4H7/FDc660x11fT3RoU48R/ZvjBF3TIhOnoR6qC6gwso4V0YRmW K1Bi+D0cxTlfxaCzVP+vkH0DAAD//wMAUEsBAi0AFAAGAAgAAAAhALaDOJL+AAAA4QEAABMAAAAA AAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAOP0h/9YAAACU AQAACwAAAAAAAAAAAAAAAAAvAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAla6DowoCAADM AwAADgAAAAAAAAAAAAAAAAAuAgAAZHJzL2Uyb0RvYy54bWxQSwECLQAUAAYACAAAACEAED/d3t8A AAAKAQAADwAAAAAAAAAAAAAAAABkBAAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA8wAAAHAF AAAAAA== " strokeweight=".25pt"/>

Рис. 3.2 Представление связей в сетевой модели

Для описания схемы сетевой БД используется две группы типов: «запись» и «связь». Тип «связь» определяется для двух типов «запись»: предка и потомка. Переменные типа «связь» являются экземплярами связей.

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

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

Физическое размещение данных в базах сетевого типа может быть организовано практически теми же методами, что и в иерархических базах данных.

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

поиск записи в БД,

переход от предка к первому потомку,

переход от потомка к предку,

создание новой записи,

удаление текущей записи,

обновление текущей записи,

включение записи в связь,

исключение записи из связи,

изменение связей и т. д.

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

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

Реляционная модель.

Реляционная модель данных предложена сотрудником фирмы IBM Эдгаром Коддом и основывается на понятии отношение (relation).

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

Таблица имеет строки (записи) и столбцы (колонки). Каждая строка таблицы имеет одинаковую структуру и состоит из полей. Строкам таблицы соответствуют кортежи, а столбцам – атрибуты отношения.

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

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

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

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

Постреляционная модель.

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

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

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

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

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

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

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

Недостатком постреляционной модели является сложность решения проблемы обеспечения целостности и непротиворечивости хранимых данных.

Многомерная модель.

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

Толчком послужила в 1993 году программная статья одного из основоположников реляционного подхода Э. Кодда. В ней сформулированы 12 основных требований к системам класса OLAP (OnLine Analytical Processing – оперативная аналитическая обработка), важнейшие из которых связаны с возможностями концептуального представления и обработки многомерных данных. Многомерные системы позволяют оперативно обрабатывать информацию для проведения анализа и принятия решения.

В развитии концепций ИС можно выделить следующие два направления:

системы оперативной (транзакционной) обработки;

системы аналитической обработки (системы поддержки принятия решений).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Операции «агрегация» (Drill Up) и «детализация» (Drill Down) означают соответственно переход к более общему и к более детальному представлению информации пользователю из гиперкуба.

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

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

Объектно-ориентированная модель.

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

Стандартизованная объектно-ориентированной модель описана в рекомендациях стандарта ODMG-93 (Object Database Management Group - группа управления объектно-ориентированными базами данных). Реализовать в полном объеме рекомендации ODMG-93 пока не удается. Для иллюстрации ключевых идей рассмотрим несколько упрощенную модель объектно-ориентированной БД.

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

Значением свойства типа string является строка символов. Значение свойства типа class есть объект, являющийся экземпляром соответствующего класса. Каждый объект-экземпляр класса считается потомком объекта, в котором он определен как свойство. Объект-экземпляр класса принадлежит своему классу и имеет одного родителя. Родовые отношения в БД образуют связную иерархию объектов.

Логическая структура объектно-ориентированной БД внешне похожа на структуру иерархической БД. Основное отличие между ними состоит в методах манипулирования данными.

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

Ограниченно могут применяться операции, подобные командам SQL (например, для создания БД).

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

Рассмотрим кратко понятия инкапсуляции, наследования и полиморфизма применительно к объектно-ориентированной модели БД.

Инкапсуляция ограничивает область видимости имени свойства пределами того объекта, в котором оно определено.

Наследование, наоборот, распространяет область видимости свойства на всех потомков объекта.

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

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

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

Типы данных.

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

числовые. Примеры значений данных: 0.43, 328, 2Е+5;

символьные (алфавитно-цифровые). Примеры значений данных: «пятница», «строка», «программист»;

даты, задаваемые с помощью специального типа «Дата» или как обычные символьные данные. Примеры значений данных: 1.12.97, 23/2/1999.

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

временные и дата-временные, предназначенные для хранения информации о времени и/или дате. Примеры значений данных: 31.01.85 (дата), 9:10:03 (время), 6.03.1960 12:00 (дата и время);

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

двоичные, предназначенные для хранения графических объектов, аудио- и видеоинформации, пространственной, хронологической и другой специальной информации. Например, в MS Access таким типом является тип данных « Поле объекта OLE», который позволяет хранить в БД графические данные в формате BMP (Bitmap) и автоматически их отображать при работе с БД;

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

В современных СУБД с различными моделями данных могут использоваться все перечисленные типы данных.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Процесс прохождения пользовательского запроса

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

последующая реорганизация и расширение БД;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

объем, содержание, сроки, исполнителей и порядок выпол-нения работ по созданию и внедрению БД,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

контроль правильности эксплуатации БД ее пользователями в процессе последующем применении,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Поиск по сайту: