Организация и обработка внутримашинной информационной базы

В соответствии с ГОСТ 24.205—80 внутримашинной информационной базой (ИБ) называют совокупность всех данных на машинных носителях, сгруппированных по определенному признаку. В составе внутримашинной ИБ могут выделяться: база данных; база документальной информации; база знаний.

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

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

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

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

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

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

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

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

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

Базы данных могут организовываться как файловые системы. Тогда основным средством их организации являются определенные системы, а основным средством обработки — программы, написанные на алгоритмических языках типа КОБОЛ, ПЛ/1, ПАСКАЛЬ, СИ и др. Для более широких приложений используют связную совокупность файлов, для создания и ведения которых дополнительно к операционным системам разрабатывают специальные программные средства, называемые системами управления базами данных (СУБД). В этом случае обработку БД ведут либо средствами СУБД, например, используя язык запросов, либо программами, написанными на указанных алгоритмических языках с применением средств СУБД в виде языка манипулирования данными[3].

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

Для создания и ведения базы знаний разрабатывают и используют специальные программные системы, например, экспертные. Обработку баз знаний выполняют либо средствами этих систем, либо программами, написанными на специальных языках, например ПРОЛОГ, на основе «правил логического вывода», составляемых пользователем.

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

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

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

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

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

Тема №3. Модели данных

 

3.1. Понятие модели данных.

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

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

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

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

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

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

Понятие модели данных

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

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

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

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

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

- сетевая,

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

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

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

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

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

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

 

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

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

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

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

 

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

Рис 3.2.  Пример типа «дерево»

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

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

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

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

Рис. 3.3. Данные в иерархической базе

 

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

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

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

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

- поиск указанного экземпляра БД (например, дерева со значением 10 в поле Отд_номер);

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

- переход от одной записи к другой внутри дерева (например, к следующей запи­си типа Сотрудники);

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

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

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

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

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

 

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

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

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

 

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

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

Пример схемы простейшей сетевой БД показан на рисунке 3.5. Типы связей здесь обо­значены надписями на соединяющих типы записей линиях.

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

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

Рис. 3.5. Пример схемы сетевой БД

 

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

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

- переход от потомка к предку;

- создание новой записи;

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

а)

Модель	Месяц	Объем
«Жигули»	июнь	12
«Жигули»	июль	24
«Жигули»	август	5
«Москвич»	июнь	2
«Москвич»	июль	18
«Волга»	июль	19

 

б)

Модель	Июнь	Июль	Август
«Жигули»	12	24	5
«Москвич»	2	18	No
«Волга»	No	19	No

Рис. 3.6. Реляционное и многомерное представление данных

 

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

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

Ячейка (Cell) или показатель — это поле, значение которого однозначно определя­ется фиксированным набором измерений. Тип поля чаще всего определен как цифровой.

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

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

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

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

«Срез» (Slice) представляет собой подмножество гиперкуба, полученное в результате фиксации одного или нескольких измерений. Формирование «срезов»- выполняется для ограничения используемых пользователем значений, так как все значения гиперкуба прак­тически никогда одновременно не используются. Например, если ограничить значения измерения Модель автомобиля в гиперкубе (рисунке 3.7) маркой «Жигули», то получится двухмерная таблица продаж этой марки автомобиля различными менеджерами по годам.

 

Рис. 3.7. Пример трехмерной модели

 

 Операция «вращение» (Rotate) применяется при двухмерном представлении данных. Суть ее заключается в изменении порядка измерений при визуальном представлении данных. Так, «вращение» двумерной таблицы, показанной на рисунке 3.6, приведет к изме­нению ее вида таким образом, что по оси Х будет марка автомобиля, а по оси Y — время.

Для иллюстрации смысла операции «агрегация» предположим, что у нас имеется гиперкуб, в котором помимо измерений гиперкуба, приведенного на рисунке 3.7, имеются еще измерения: Подразделение, Регион, Фирма, Страна. Заметим, что в этом случае в гиперкубе существует иерархия (снизу вверх) отношений между измерениями: Менеджер, Подразделение, Регион, Фирма, Страна.

Пусть в описанном гиперкубе определено, насколько успешно в 1995 году менеджер Петров продавал автомобили «Жигули» и «Волга». Тогда, поднимаясь на уровень выше по иерархии, с помощью операции «агрегация» можно выяснить, как выглядит соотно­шение продаж этих же моделей на уровне подразделения, где работает Петров.

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

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